一个账户是一个人可读的，存在区块链上的id。每笔transaction都需要在某个账户所配置的authority下评估permissions。每个被命名的permission都有一个阈值，只有满足后， 签名的transaction才能在authority下被认为有效。Transactions是通过一个加载了已解锁的钱包客户端签名的。钱包是一个保护并使用您的keys的软件。这些keys不一定要为区块链上某账户authority所permissioned。
1. 钱包
钱包是保存keys的客户端，而这些keys不一定和这些账户permissions相关。理想情况下钱包有一个上锁状态（加密）和一个解锁（解密）状态且被一个强熵的密码保护。EOSIO/eos仓库又一个叫做eosc的命令行工具，钱包就是其中一部分的功能。
2. 账户
账户是一个保存在区块链上，具可读性的名字。通过permissions配置，账户可被一个体所拥有，也可为一群个体共同拥有。转账或者向区块链推送transaction都需要账户。
3. Authorities 和 Permissions
Authorities 决定特定message是否被正确授权。
每个账户都有两个原生具名的permissions
-
ownerauthority代表一个账户的所有权。只有少数transactions需要此authority，但任何需要改动owner authority的message都需要。总的来说，我们建议把owner冷储存起来，不要和任何人共享。owner可以用来恢复另一个可能已经被损害的（compromised）permission. -
activeauthority可用来转账资金、给区块生产者投票及进行另一些高级的账户改动。
除了原生 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. Putting it all Together
下面是上面所提到的概念的集合及一些如何在实际中使用他们的简单例子。
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 |
在此场景下，要修改owner permission的加权阈值为2，也就是说因为每方本身加权都是1, 所有用户需要都签名该transaction它才能被完全授权。
而要发送一个需要active authority的transaction，加权阈值是1。这意味着只需要一个具有active authority的账户签名即可授权该message。
还有一个叫publish的自定名称permission。比如这个publish permission是用来通过一个理论上的博客App向@multisig的博客发布文章的。这个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权限的特权。
网友评论