今天我们探讨EOS的权限和许可问题
1.基本概念
我们先了解下EOS.IO权限模型的三个基本概念：
- Wallets（钱包）——钱包是EOS.IO提供的用于管理密钥对的客户端，钱包支持锁定和密码解锁。
- Accounts (账户）——账户是公示在区块链上的人工易读（不是公钥或短地址！！！）的名字。
- Authorities and Permissions(权限及授权验证）——每个账户都内置owner和active权限，owner冷藏用于恢复其他权限。一般转账操作，都使用active权限就可以了。
1.1权限（Permission）定义的目标
EOSIO的账户权限定义的目标在白皮书中这样叙述:
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.
这段话明确了EOSIO允许账户持有者部分让度权限，而且权限受让者是用自己持有的密钥签名，以便明确区分授权行为是如何发生的。
2.账户(Account)如何生成
权限是建立在账户的基础之上的，那么账户又是如何产生的呢？
首先要明确的一点是：
无论账户还是权限，它们一定是通过签名交易（signed transaction）来定义并在区块链中公示的。——这是其他节点在执行合约时进行权限验证（Authorities）的基础。
来看看利用EOSIO的命令交互，如何生成一个新账户：
$ cleos create account eosio tester EOS4toFS3YXEQCkuuw1aqDLrtHim86Gz9u3hBdcBw5KNPZcursVHq EOS7d9A3uLe6As66jzN8j44TXJUqJSK3bFjjEEqR4oTvNAB3iM9SA
命令的说明及返回在这里
返回JSON文本比较长，不过读懂它的每一部分含义你也就理解了EOSIO权限模型的设计思路。这里我们先看看与本文相关的几处：
- 每个账户默认携带owner和active两个权限，分别对应一对密钥（*其中owner密钥冷藏保存，通常用active来干活，方便用owner恢复active）
- 该命令用账户eosio的active权限签名提交了一个交易
- 交易调用了内置合约eos的newaccount行为
- 命令传入的公钥分别作为新产生的tester账户的owner和active权限公钥
这里一定有人会问：那么这个最初的账户eosio是由什么账户来签名生成的呢？——它是在启动区块链时，在创世区块的配置config.ini中直接定义的。
可以查看config.ini文件
producer-name = eosio
3. Authorities （授权）和 Permissions（许可）
Authorities 决定特定message是否被正确授权。
每个账户都有两个原生具名的permissions
-
owner authority代表一个账户的所有权。只有少数transactions需要此authority，但任何需要改动owner authority的message都需要。总的来说，我们建议把owner冷储存起来，不要和任何人共享。owner可以用来恢复另一个可能已经被损害的（compromised）permission.
-
active authority可用来转账资金、给区块生产者投票及进行另一些高级的账户改动
除了原生 permissions外, 账户可有自定义的具体名称的permissions，以扩展对账户的管理功能。自定义permissions是非常灵活的，可以用于各种各样的场景。这很大程度上取决于开发者社区 Much of this is up to the developer community in how they are employed, and what conventions if any, are adopted.
任何authority的Permission都可以被分配给一个或多个公钥或一个有效的账户名。
4.utting it all Together（把他们放一起）
我们用简单的Demo来说明一下。
4.1 默认账户配置 (Single-Sig)
这是某账户创建后如何配置的例子。该账户的owner和active permissions都各自有一个key, 两个keys的权重都是1且阈值也是1。默认配置需要一个签名来授权对于原生permissions的message。
@bob account authorities
| Permission | Account | Weight | Threshold |
| Owner | 1 | ||
| EOS5EzTZZQQxdrDaJAPD9pDzGJZ5bj34HaAb8yuvjFHGWzqV25Dch | 1 | ||
| active | 1 | ||
| EOS61chK8GbH4ukWcbom8HgK95AeUfP8MBPn7XRq8FeMBYYTgwmcX | 1 |
在@bob账户这个例子中，依表格所示，@bob's的owner key的权重是1，在该authority下推送一个transaction所需要的阈值也是1。
如果需要在owner的authority下推送一个transaction，只需要@bob用它的owner key签名一个transaction，此transaction即可被认为有效。这个key将被储存在一个wallet中，并用eosc来管理。
4.2 Multi-sig 账户及自定义Permissions
下面的例子是一个虚构的名叫@multisig的账户。在此场景下，两个用户被授予owner 和 active permissions，而有三个用户加权不同地被授予自定义的publish permission。
@multisig account authorities
| Permission | Account | Weight | Threshold |
|---|---|---|---|
| owner | 2 | ||
| @bob | 1 | ||
| @stacy | 1 | ||
| active | 1 | ||
| @bob | 1 | ||
| @stacy | 1 | ||
| publish | 2 | ||
| @bob | 2 | ||
| @stacy | 2 | ||
| EOS7Hnv4iBWo1pcEpP8JyFYCJLRUzYcXSqtQBcEnysYDFTEbUpi6y | 1 |
- 在此场景下，要修改
ownerpermission的加权阈值为2，也就是说因为每方本身加权都是1, 所有用户需要都签名该transaction它才能被完全授权。 - 而要发送一个需要active authority的transaction，加权阈值是1。这意味着只需要一个具有active authority的账户签名即可授权该message。
-
还有一个叫publish的自定名称permission。这个publish permission的加权阈值是2，而@bob@* 和 @stacy的加权都是2，public key的加权是1。这样的话@bob和@stacy都不需要额外签名就可以发布，但public key 则需要一个额外签名才能使一个在public permission下的message通过授权。
上面的permissions表展现了@bob 和 @stacy作为账户的拥有者，具有类似于主席或者编辑的特权。尽管这个简单的例子也有局限性（尤其是可扩展性上），并不是一个好的设计，但它却充分展现了EOS权限系统的灵活性。
注意上面的表格中，permissions可以使用account name也可以使用一个key。乍看之下这可能不重要，但是这确实增加了灵活性。
备注
- @bob 和 @stacy可同时被显式地设置成用户的拥有者。
- @bob 和 @stacy 都有对于 publish权限的特权。
2018年7月31日整理于深圳