(图片来自pixabay.com)
这是我重读EOS白皮书的第二部分，上一篇《重读EOS白皮书——账户与智能合约》记录我对EOS.IO的账户与智能合约的理解。这一篇主要记录我对EOS.IO的权限管理的理解。
我们都知道权限控制是非常现实的需要。在一个组织中，财务与销售人员的权限肯定是不一样的，单就财务人员来说，不同的金额需要不同的授权，普通的财务人员可以同意1000块内的支出，而涉及到百万级别的支出可能就需要CFO授权，更高的金额就需要更高的授权。
这些非常现实的需求，但现有的智能合约平台上却很难实现。在比特币以及以太坊上只有很简单的权限管理，即检查一条消息是否拥有合法的签名。即使是多重签名也是为了安全，当然也可以说是一种权限管理。
EOS.IO背后的男人，BM，在他的前一个项目，Steem中使用了一种权限管理方式。简单概述，一个账户拥有3个不同权限，它们分别是：
- owner级权限，能操作任何功能。
- active级权限，可以做除了修改owner以外的所有操作。
- post级别的权限，可以发表文章、点赞……
可以看到从 owner --> active --> post，权限的范围不断的被缩小，对于一个社交媒体平台，需要一个key用于日常的、经常的连接互联网。这三个私钥，owner适用与泠储存，而active或着post则可以用于日常活跃的连网活动。
EOS.IO在Steem的基础上扩展、泛化了这种权限管理方式。EOS.IO上将拥有onwer和active这两个默认的权限，还将允许用户声明式的管理自己的权限。EOS.IO的权限在设计上是要与业务分离的，这有利于权限管理的工具化以及EOS.IO性能的提升。如果EOS.IO的权限与业务耦合，一旦EOS.IO开发完成，EOS.链上将会非常多的应用，每个应用使用不同的权限，将会非常的不利于性能，也会到导致开发成本急剧上升，用户也会不知所措。
EOS.IO允许某账户被授权账户/keys控制，用来代表授权账户进行操作，如进行EOS投票，选见证人…….EOS.IO还将允许用户定义特定的keys/accounts执行发送特定类型的合约。如你可以创建一个用于社交媒体平台的账号，另一个用于交易所的账号。这两个账号不会相互影响，你的社交媒体账号的key被盗了，不会影响交易所的账号也不会影响主账号。这一切都要依赖于EOS.IO实现了一个账户下可以定义多个账户。然我们看下创建账号时产生的事务。
(创建账号的事务，删掉了签名等)
(currency 控制的账号)
可以看到currency@active创建了一个名为post的账号，该post账号可以被currency重置。可以通过命令查看currency控制的账户。
通观EOS.IO的白皮书，我发现可阅读是一个很重要的概念，在权限设计这一块，EOS.IO允许给自定义的权限定义一个名称，就像默认的owner、active权限一样，你可以给自己的交易所的权限定义为exchange……。既然用户可以定义自己的权限绑定到特定的合约，那最好合约有一个人类可读的名字。EOS也的确是这么做的，EOS上的合约可以使用命名空间，最高一级是账户名称最低一级是合约的动作，如@exchange.contract.withdraw。我们可以看下白皮书给的例子：
如此复杂的权限，在执行合约的时候如何验证签名是否合法、交易是否有效、是否有足够的权限呢？EOS.IO根据消息的要执行的合约动作，回溯验证是否有授权执行该合约。例如，@alice 发@bob一条@bob.groupa.subgroup.Action类型的消息，EOS.IO将会先检查@alice是否定义了映射到@bob.groupa.subgroup.Action的权限，如果没有则向上检查，检查是否有映射到@bob.groupa.subgroup的权限，最终会到达@bob。如果都没有发现有权限映射，则EOS.IO默认使用@alice的active权限来执行执行该消息（即如果不是active级别的授权，则该交易不能被执行）。
EOS.IO为了性能，加快验证权限的速度，将在一个区块中的权限都是只读的，是一样的。也就是在当前区块的事务修改用户的权限，不会影响当前区块中的该用户的其他事务的执行。即权限在区块开始时已经确定，在区块打包过程中的修改，将会在下一个区块产生作用。
EOS.IO上的应用越多，权限就会越复杂，可以预见，将会有专门的权限管理工具出现。
抛砖引玉，欢迎讨论
(如果你注册了steemit账户，请关注我)
（如果文章对你有用，请关注我的公众号）