EOS whitepaper walk-through: Account, Permission Levels and Permission Mapping, and Permission evaluation.

 In the last article we went over Role Based Permission Management in EOS.

In this article, we will go over how Permission levels are constructed and how to map these Permission to different accounts.

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.

This is relatively straight forward: accounts structure any combination of actions to be done under certain permission levels. The 'transfer' action and 'trade' action might be be listed under the 'Manager' Permission level.

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. 

In Steem, it is common for an application to ask the user for Posting permission level access. With this access, the applications can perform the 'posting' action that is associated with that permission level.

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.

Having a certain permission level access means you can send messages associated with that permission level. These messages have the same validity as if the owner of the account have sent them himself. However, these messages are signed with the sender's private key, thus it is possible to tell which person from the permission level sent the message.

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. 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. 

The example given above illustrates a the interaction between an example account and an example exchange contract.

On the left, the account is divide into different, hierarchical permission levels: Family, Friends and Lawyer.

The Family and Lawyer permission level is on the same hierarchy and can perform most of each other's action, except when specified.

In this case, when interacting with the exchange contract, the Family permission level can send any message to the exchange contract except @exchange.contract/WITHDRAWL, which is not mapped to that permission level but to the Lawyer permission level.

The Friends permission level is the lowest permission level in this account and can perform only few of the actions that the total account is capable.

The left illustrates the exchange contract, which is named @exchange, and has a few message handlers. The message handlers can be group together under a Named Group. Each message handler requires the incoming message to meet the permission level. 

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". 

The two default permission levels which are 'owner' and '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.

All things considered, permission verification represents a significant percentage of the computation required to validate transactions. Making this a read-only and trivially parallelizable process enables a dramatic increase in performance.

Permission evaluation is 'read-only', meaning that as transaction logic is being processed, the transaction's permission validity can be evaluated separately.

Once a block producer receives a transaction, it'll start the process of running the operations. At the same time, the transaction's permission will be checked for validity. If at the end of the block the transaction's permission is found to be meeting the standard, then the changes will not be applied.

Recall from an earlier article, accounts data regions are divided into scopes, and these scopes allows for parallel execution if they do not overlap with one another. This gives applications with many moving parts the ability to run quickly and smoothly. 

When replaying the blockchain to regenerate the deterministic state from the log of Actions there is no need to evaluate the permissions again. The fact that a transaction is included in a known good block is sufficient to skip this step. This dramatically reduces the computational load associated with replaying an ever growing blockchain. 

As stated, permission evaluation takes up a significant amount of of computational power, making this separate from blockchain validation makes running full nodes, something that large businesses will likely to do, less costly. 

In the next article, we'll go over some of the security measures in EOS blockchain that allows for account recovery, something that cannot be done in either Bitcoin or Ethereum.