今年币圈链圈一个重大事件就是：EOS在6.1日正式发布，但是还有非常多的人从未阅读过EOS技术白皮书。在此我准备做一个通读EOS白皮书系列，主要是翻译官方原文并加入个人解释的形式展现，水平有限，欢迎大家讨论交流。
微信公众号：blockd-public
微信号：点击查看

---

命名的权限等级

使用EOS.IO软件，账户可以定义命名权限等级，每个等级都可以从高等级派生过来。每个命名权限等级定义了一个权限，一个由密钥和（或）其它账户组成的多重签名校验域值组成。例如：账户的Friend(朋友)权限等级可以设置为该账户的任何一个朋友都可以同账户持有人一样的控制该账号。

解释：EOS可以定义 固定名称的权限等级，比如：Friend,Posting，不同的名称代表着不同的等级，低等级可以从高等级派生出来。这样可以灵活的用于不同场景，不同用途。

另一个例子就是Steem区块链，它硬编码了3种命名权限等级：owner,active,posting。posting权限只能执行社交行为，如投票、发文。active权限可以做除更改所有者之外的任何权限下的事。owner权限可以冷存储且能做任何事。EOS.IO软件通过允许每个账户持有者定义他们自己的等级层次以及操作分组来概括这个概念。

解释：举了一个steem的例子，在Steemit网站，使用不同权限的密钥登录，可以做不同的操作。最基本的就是posting这个密钥，使用这个密钥就可以进行一些非敏感的操作，可以点赞可以发文章。

命名的消息处理程序组

EOS.IO 软件允许每个账户将命名自己的消息处理程序程，以及嵌套。当账户配置相应的权限等级后，可以引用这些组。

解释：消息可以分组处理。

最高等级的消息处理程序组就是账户名，最低的就是账户接到的具体消息的类型。这些组可以像这下面这样引用： **@accountname.groupa.subgroupb.MessageType**.

这种模式下，交易合约可以将订单创建和取消与充值和提现区分开。这种通过交易合约分组可以方便交易所用户

解释：通过对不同类型的消息进行分组，可以方便业务处理。

权限映射

EOS.IO 软件允许每个账户定义 任一账户的命名消息处理组 与 他们自己的命名权限等级 对应关系。 例如，账户持有人可以将 此账户的社交媒体应用 与 此账户的Friend权限组 关联。通过这个映射关系，任何一个朋友都可以像此账户一样在社交媒体上发文章。 虽然他们可以像账户持有人一样发文，但是他们依然要使用自己的密钥对消息签名。这表示总是可以确定哪个朋友以哪种方式在使用此账户。

解释：通过绑定权限关系，可以让相应的账户做出合适的操作。但是，不论什么操作，消息都会用真正操作人的密钥进行签名。所以，如果出了问题可以定位都是在搞鬼。

权限评估

当 @alice 给 @bob发了一条"Action"类型的消息, EOS.IO 软件首先会检查 @alice 是否为@bob.groupa.subgroup.Action定义对应权限关系 。如果没有找到，之后会向上@bob.groupa.subgroup继续寻找，同理继续 @bob.groupa, 最后找到 @bob 。如果最终没有找到，那么会假定映射到 @alice.active。

一旦映射关系确定之后通过签名权限通过域值多重签名过程和命名权限相关联的权限来校验签授权。如果校验失败，继续上溯到父权限，最终到用户权限@alice.owner。

解释：本人也没太看懂，建议看原文自已理解。

默认的权限组

EOS.IO软件技术同样允许所有账户拥有无限制的owner权限组，以及除了无法更改owner的active权限组。其他一切权限权限组派生自"active"

解释：EOS的默认权限组构成。

并行权限评估

权限评估过程是“只读”过程，交易造成的权限更改在区块打包完成才会生效。这意味着，所有交易的密钥与权限评估可以并行执行。此外，这意味着可以在不启动（可能造成回滚的）高成本耗资源应用逻辑就可以快速进行权限校验。最后，这还意味着在交易等待期就可以评估权限，并且交易完成之后不必在重新评估。

如果把交易验证需要考虑的事情都考虑在内，权限校验在计算量中有很大占比。通过使权限校验只读和明显地并行处理可以巨大的提升性能。

当需要从消息日志中重放区块链来再次生成确定状态时，不需要再次评估权限。一笔包含在众所周知的好区块中的事实就可以跳过这个步骤。这样可以巨大的减少重不断增加的区块链的计算负担。

解释：并行计算，提高了性能，节约了资源。这正是EOS这种要求高性能的发平台所要重点关注的地方。

---

原文如下

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 the account to be controlled equally by any of the account's friends.

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.

Named Message Handler Groups

The EOS.IO software allows each account to organize its own message handlers into named and nested groups. These named message handler groups can be referenced by other accounts when they configure their permission levels.

The highest level message handler group is the account name and the lowest level is the individual message type being received by the account. These groups can be referenced like so: @accountname.groupa.subgroupb.MessageType.

Under this model it is possible for an exchange contract to group order creation and canceling separately from deposit and withdraw. This grouping by the exchange contract is a convenience for users of the exchange.

Permission Mapping

EOS.IO software allows each account to define a mapping between a Named Message Handler Group of any 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 message. This means it is always possible to identify which friends used the account and in what way.

Evaluating Permissions

When delivering a message 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.

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

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

When replaying the blockchain to regenerate the deterministic state from the log of messages 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.