EOS EOSIO DApp 개발 – '나도 백서 읽는다' 시리즈 4. Accounts

나도 백서 읽는다 시리즈는 '읽고, 읽었으면 이해할 수 있어야 한다'는 목표로 글을 쓰고 있습니다. 이 글을 통해 백서를 읽어야 하는 개발자들의 시간 낭비를 조금이라도 줄일 수 있기를 바랍니다.

Accounts

The EOS.IO software permits all accounts to be referenced by a unique human readable name of up to 12 characters in length. The name is chosen by the creator of the account. The account creator must reserve the RAM required to store the new account until the new account stakes tokens to reserve its own RAM.

EOS는 계정을 사용해. 계정은 12자 이하로, 사람이 읽을 수 있는 고유한 이름이어야 해.

계정을 생성하려면 램(RAM)이란게 필요한데 새로 생성할 계정은 아직 등록되지도 않았으니 당연히 램 같은 것을 가지고 있을리 없지. 그래서 램을 지원할 기존 계정이 필요해. 램을 지원하는 기존 계정을 계정 생성자(creator)라고 해.

생성자는 신규로 등록되는 계정이 자신의 램을 보유하기 위해 토큰을 stake할 때까지 신규 계정에 대한 램을 보유하고 있어야 해. stake 참 우리말로 옮기기 어렵네. 토큰을 걸고 그 토큰 만큼 뭔가 할 수 있는 권한을 얻는 거니 지분이나 예치의 의미에 가깝긴 한데. 명사인 경우는 그래도 괜찮은데 동사인 경우는... '걸다', '예치하다'가 적당해 보이긴 한데.

In a decentralized context, application developers will pay the nominal cost of account creation to sign up a new user. Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. The cost of funding a new blockchain account should be insignificant in comparison. Fortunately, there is no need to create accounts for users already signed up by another application.

누가 creator가 되는거야?
누군가 사용자 등록이 필요한 앱을 개발했다면, 사용자 등록을 위해서는 먼저 그 사용자 계정을 블록체인에 등록해야 겠지.
블록체인에 이미 계정이 있는 사용자라면 그 계정을 사용하면 되지만, 처음 계정을 등록하는 경우라면 먼저 계정을 등록해야겠지.
사용자에게 앱을 사용하려면 사용자 등록을 위한 비용을 지불해야 한다면, 지금까지 사용자 등록을 위해 돈을 지불해 본 적이 없는 사용자들은 황당해하겠지. 그렇게 되면 앱에 등록하는 사용자는 없고 앱은 사용자 없이 사라지겠지.
이러한 이유로 앱 개발자는 사용자를 유치하기 위해 계정 생성자가 되어 계정 생성을 위한 최소한의 비용을 지불하겠지. 많은 수의 계정이 생성된 후에 앱 서비스를 제공한다면 계정 생성 비용을 지불할 필요가 없겠지만 그 만큼 시장 선점효과는 잃겠지. 참 머리 잘쓴다.

Actions & Handlers

계정과 관련된 액션 설명이니까 계정과 관련해서만 액션을 이해하면 된다. 너무 깊게 빠지지 말자.
Each account can send structured Actions to other accounts and may define scripts to handle Actions when they are received. The EOS.IO software gives each account its own private database which can only be accessed by its own action handlers. Action handling scripts can also send Actions to other accounts. The combination of Actions and automated action handlers is how EOS.IO defines smart contracts.

한 계정에서 다른 계정들로 구조화된 액션들을 보낼 수 있어. 액션이 수신되었을 때 어떻게 액션을 핸들링(handling) 할 것인지는 스크립트로 정의되어 있어야 해.
계정은 자신의 개인 데이터베이스를 가지는데, 이 데이터베이스는 계정이 소유한 액션 핸들러(handler)에 의해서만 액세스 될 수 있어.
액션 핸들링 스크립트는 또한 다른 계정에 액션들을 보낼 수 있어.
액션들과 자동화된 액션 핸들러들의 조합으로 스마트 컨트랙트를 정의해.

To support parallel execution, each account can also define any number of scopes within their database. The block producers will schedule transaction in such a way that there is no conflict over memory access to scopes and therefore they can be executed in parallel.

병행으로 실행될 수 있도록 각각의 계정은 또한 데이터베이스내에 스코프(scope)를 정의할 수 있어. BP는 스코프에 대한 메모리 액세스가 충돌하지 않는 방법으로 케줄링 할거야.

Role Based Permission Management

Permission management involves determining whether or not an Action is properly authorized. The simplest form of permission management is checking that a transaction has the required signatures, but this implies that required signatures are already known. Generally, authority is bound to individuals or groups of individuals and is often compartmentalized. The EOS.IO software provides a declarative permission management system that gives accounts fine grained and high-level control over who can do what and when.

권한 관리에는 액션이 적절하게 인증되었는지에 대한 결정이 포함되지. 권한은 최종적으로 앱의 기능(function)과 연결되어야 하는데 EOS에서는 기능이 액션에 해당하지. 권한 관리의 가장 간단한 형태는 트랜잭션에 필요한 서명을 체크하는 거야. 그렇게 하려면 필요한 서명을 미리 알고 있어야 하지.
일반적으로 권한은 개인이나 그룹에 설정 돼. 권한 별로 구획되는 경우가 자주 있지.
EOS는 선언적 권한 관리 시스템을 제공 해. 그렇게 함으로 계정이 더 세부적이고 높은 수준으로 '누가 무엇을 언제 할 것인가'를 제어 할 수 있도록 하지.

It is critical that authentication and permission management be standardized and separated from the business logic of the application. This enables tools to be developed to manage permissions in a general-purpose manner and also provide significant opportunities for performance optimization.

권한 관리는 앱 개발에 공통적으로 필요한 기능. 당연히 제공해 주면 좋지. 권한 관리를 표준화하고 앱의 비즈니스 로직과 분리하는 것은 중요하지.

Every account may be controlled by any weighted combination of other accounts and private keys. This creates a hierarchical authority structure that reflects how permissions are organized in reality and makes multi-user control over accounts easier than ever. Multi-user control is the single biggest contributor to security, and, when used properly, it can greatly reduce the risk of theft due to hacking.

한 계정은 다른 계정들과 키들과의 가중치 조합으로 제어될 수 있어. 뒤에 자세한 설명이 있군.
계약의 성질이 반영된 실세계 권한 관리는 권한 계층을 요구하고 다중-사용자 제어를 요구하지.
다중-사용자 제어는 보안에 대한 가장 큰 기여를 하고, 적당하게 사용되면 해킹으로 인한 도난 위험을 크게 줄일 수 있어. 큰 건 하나 했네!

Named Permission Levels
Using the EOS.IO software, accounts can define named permission levels each of which can be derived from higher level named permissions. Each named permission level defines an authority; an authority is a threshold multi-signature check consisting of keys and/or named permission levels of other accounts. For example, an account's "Friend" permission level can be set for an Action on the account to be controlled equally by any of the account's friends.

권한에 이름을 사용할꺼야. 권한은 계층적으로 작성될 수 있어. 'can be derived from higher level...'는 좀 이상한데. 파생된다는 의미를 어떻게 사용하고 있는지 명확하지 않으니 우선 넘어가자.
권한은 다수의 서명을 통해 활성화 될 수도 있어. 권한을 설정할 때 권한을 구성하는 다수의 키들과 다른 계정들의 권한들을 조합할 수 있어. 키들과 다른 계정들의 권한들 각각에 가중치를 부여하고, 가중치의 합이 설정한 임계값(threshold) 이상이면 권한이 활성화 되도록 하는 거야. 예를 들어 어떤 계정에 'Friend' 권한을 두고, 그 권한에 액션을 설정하고, 그 계정의 친구들 아무나 이 액션을 실행할 수 있게 할 수 있다.

Another example is the Steem blockchain which has three hard-coded named permission levels: owner, active, and posting. The posting permission can only perform social actions such as voting and posting, while the active permission can do everything except change the owner. The owner permission is meant for cold storage and is able to do everything. The EOS.IO software generalizes this concept by allowing each account holder to define their own hierarchy as well as the grouping of actions.

스티밋은 고정된 권한으로 'owner', 'active', 'posting'을 제공한다. posting은 투표나 글쓰기만 가능하고, active는 owner를 변경하는 것을 제외한 모든 것을 할 수 있다. owner는 모든 것을 할 수 있다.
EOS는 이런 개념을 일반화해서 액션들을 그룹화하는 것 뿐만 아니라 새로운 권한과 권한 계층을 정의할 수 있도록 한다. 멋지다~

Permission Mapping
EOS.IO software allows each account to define a mapping between a contract/action or contract of any other account and their own Named Permission Level. For example, an account holder could map the account holder's social media application to the account holder's "Friend" permission group. With this mapping, any friend could post as the account holder on the account holder's social media. Even though they would post as the account holder, they would still use their own keys to sign the Action. This means it is always possible to identify which friends used the account and in what way.

계정에 권한을 설정하고 권한에 계약이나 액션을 연결한 후, 다른 계정들을 해당 권한에 매핑할 수 있어. 예를 들어 소셜 미디어 앱에 'Friend' 권한을 갖는 계정 보유자가 자신의 친구들을 'Friend' 권한에 매핑하면, 권한에 매핑된 친구는 누구라도 계정 보유자의 소셜 미디어에 글쓰기 할 수 있지. 친구들이 'Friend' 권한으로 글을 쓰긴 하지만 자신들의 키로 서명하기 때문에 누가 글을 썼는지도 알 수 있어.

Evaluating Permissions

When delivering an Action of type "Action", from @alice to @bob the EOS.IO software will first check to see if @alice has defined a permission mapping for @bob.groupa.subgroup.Action. If nothing is found then a mapping for @bob.groupa.subgroup then @bob.groupa, and lastly @bob will be checked. If no further match is found, then the assumed mapping will be to the named permission group @alice.active.

@alice로 부터 @bob에게 "Action"이 전달될 때 권한 체크는 다음과 같이 진행 돼.
먼저 @alice가 @bob.groupa.subgroup.Action에 매핑되어 있는지를 체크 해. 만약 권한 매핑이 없으면 @bob.groupa 를 체크하고 마지막에는 @bob을 체크 해. 그래도 매핑된 것이 없으면 @alice.active 권한에 매핑될 거라고 가정해.

Once a mapping is identified then signing authority is validated using the threshold multi-signature process and the authority associated with the named permission. If that fails, then it traverses up to the parent permission and ultimately to the owner permission, @alice.owner.

일단 매핑이 있으면 권한에 해당하는 서명을 검증 해. 다중-서명이 요구되는 경우 가중치와 임계값으로 권한이 활성화 될 수 있는지까지 검증해야 해. 만약 실패하면 부모 권한으로 궁극적으로는 owner까지 찾아 올라가지. 여기서는 @alice.owner까지.

아래 그림을 보고 이해해 보자. 그림 설명은 본문에 없음.

USER 계정의 권한 계층을 정의하자.
-최상위에 OWNER
-OWNER 하위에 ACTIVE
-ACTIVE 하위에 FAMILY, LAWYER
-FAMILY 하위에 FRIENDS

하위로 갈수록 권한이 제한된다고 생각하자. 즉 하위에 설정한 권한은 상위 권한에서 모두 가능하다.
@EXCHANG.CONTRACT 계약을 FRIENDS에 매핑하고, @EXCHANG.CONTRACT/WITHDRAW액션을 LAWYER에 매핑한다.

액션에 대해 세부적인 권한을 설정하면 액션에 대한 권한은 매핑된 권한(또는 그 상위)만 갖게 된다. @EXCHANG.CONTRACT/WITHDRAW는 LAWYER에 구체적으로 매핑되었으니 FRIENDS에 @EXCHANG.CONTRACT를 매핑했다고 하더라도 @EXCHANG.CONTRACT/WITHDRAW을 실행할 수 없다는 것.
@EXCHANG.CONTRACT/WITHDRAW는 LAWYER와 그 상위 권한인 ACTIVE, OWNER만 가능

오른쪽 그림은 메시지 핸들러들을 그룹화할 수 있다는 것인데 이와 관련된 내용은 다른 문서에서 본 적이 없음. 이것은 패스.

** 원래 그림은 @EXCHANG.CONTRACT를 FAMILY에 매핑하고 있는데 그림이 잘 못 된 것으로 보입니다. 이 부분은 github에 이슈로 올렸습니다.

Default Permission Groups

The EOS.IO technology also allows all accounts to have an "owner" group which can do everything, and an "active" group which can do everything except change the owner group. All other permission groups are derived from "active".

모든 계정은 owner와 active 권한을 갖지. 계정을 생성할 때 owner키와 active키를 설정해서 생성하는 이유. 추가적인 권한은 active 하위로 작성.

Parallel Evaluation of Permissions

The permission evaluation process is "read-only" and changes to permissions made by transactions do not take effect until the end of a block. This means that all keys and permission evaluation for all transactions can be executed in parallel. Furthermore, this means that a rapid validation of permission is possible without starting costly application logic that would have to be rolled back. Lastly, it means that transaction permissions can be evaluated as pending transactions are received and do not need to be re-evaluated as they are applied.

권한 평가는 '읽기 전용'이야. 트랜잭션에 의한 권한 변경은 블록이 끝날 때까지 효과가 없어.
이것이 의미하는 바는 다음과 같아.
-트랜잭션을 위한 키와 권한 평가가 병행적으로 처리될 수 있음
-권한 평가를 비즈니스 로직에서 분리할 수 있음. 권한 평가에서 실패할 비즈니스 로직을 수행할 필요가 없겠지.
-트랜잭션이 보류된 경우 재기될 때 권한을 평가하면 되고, 이미 평가된 권한을 다시 평가할 필요 없다는 것

권한 검사는 트랜잭션 유효성 검사에서 많은 연산처리를 요구하기 때문에 이를 병행처리할 수 있으면 큰 성능 향상을 가져올 수 있겠지.

블록체인을 다시 구성(replay)해야 하는 경우에 당연히 권한을 평가할 필요가 없겠지.

Actions with Mandatory Delay

시간은 보안에 중요한 요소. 대부분의 경우 개인 키는 사용되기 전에는 도난 당했는지 알 수 없어. 인터넷에 연결된 컴퓨터를 사용하는 경우 시간 기반 보안은 더 중요하지.
액션은 블록에 포함된 후에 그것이 실제 적용될 때 까지 최소한의 지연 시간을 설정할 수 있어. 이 시간 동안 취소할 수 있지. 필수 지연시간을 갖도록 할 수 있어.

Users can then receive notice via email or text message when one of these Actions is broadcast. If they did not authorize it, then they can use the account recovery process to recover their account and retract the Action.

사용자는 이러한 액션이 브로드캐스트될 때 이메일이나 텍스트로 알림을 받을 수 있어. 본인이 승인한 것이 아니라면 계정 복구 절차를 사용해서 계정을 복구하고 액션을 취소할 수 있어.

The required delay depends upon how sensitive an operation is. Paying for a coffee might have no delay and be irreversible in seconds, while buying a house may require a 72 hour clearing period. Transferring an entire account to new control may take up to 30 days. The exact delays are chosen by application developers and users.

지연은 작업의 중요성에 따라 설정되겠지. 커피 한 잔 구매에 지연을 설정하지는 않을 것 같고. 집을 사는 것이라면 72시간 지연이 필요할 수도 있겠지. 전체 계좌를 제어하는 것이라면 30일 지연할 수도 있겠지. 사안에 따라서 결정할 수 있다는 것이지.

Recovery from Stolen Keys
키가 도난 당했다면?

The EOS.IO software provides users a way to restore control of their account when keys are stolen. An account owner can use any owner key that was active in the last 30 days along with approval from their designated account recovery partner to reset the owner key on their account. The account recovery partner cannot reset control of the account without the help of the owner.

키가 도난 당해도 해결 방안이 있지. 계정 복구 파트너와 협력해서 최근 30일 이내에 사용한 키를 가지고 계정의 owner키를 다시 설정할 수 있어. 이 절차는 꽤 복잡하겠네. 아직까지 이에 대한 상세한 내용을 다루는 문서를 본적은 없음. 물론 계정 복구 파트너가 자기 마음대로 이런 작업을 한다면 큰일 나겠지.

There is nothing for the hacker to gain by attempting to go through the recovery process because they already "control" the account. Furthermore, if they did go through the process, the recovery partner would likely demand identification and multi-factor authentication (phone and email). This would likely compromise the hacker or gain the hacker nothing in the process.

복구 절차에는 신분 증명이나 핸드폰이나 이메일을 통한 다차원 인증이 요구될 거야. 해커가 복구 절차를 위해 이런 일을 하지는 않겠지. 하기도 어려울거고. 해킹을 해도 얻는 게 없을 수 있다는 것이지.

This process is also very different from a simple multi-signature arrangement. With a multi-signature transaction, another entity is made a party to every transaction that is executed. By contrast, with the recovery process the recovery partner is only a party to the recovery process and has no power over the day-to-day transactions. This dramatically reduces costs and legal liabilities for everyone involved.

다중서명과 비슷할 거라고 생각할 수 있는데 달라. 계정 복구 협력자는 복구과정에만 관여하지 트랜잭션에 대해서는 어떤 것도 하지 않아.

이러한 방법은 블록체인에 참여한 모든 사람들에게 비용과 법적책임을 획기적으로 줄여줄 수 있게 해주지. 훌륭해!