账户和权限
一、概述
一个账户是一个人可读的，存在区块链上的id。每笔transaction都需要在某个账户所配置的authority下评估permissions。每个被命名的permission都有一个阈值，只有满足后， 签名的transaction才能在authority下被认为有效。Transactions是通过一个加载了已解锁的钱包客户端签名的。钱包是一个保护并使用您的keys的软件。这些keys可能是也可能不是区块链上某账户的permissioned。
二、钱包
钱包是保存keys的客户端，而这些keys不一定和这些账户permissions相关。理想情况下钱包有一个上锁状态（加密）和一个解锁（解密）状态且被一个强熵的密码保护。EOSIO/eos仓库又一个叫做eosc的命令行工具，钱包就是其中一部分的功能。
三、账户
账户是一个保存在区块链上，具可读性的名字。通过permissions配置，账户可被一个体所拥有，也可为一群个体共同拥有。转账或者向区块链推送transaction都需要账户。
四、Authorities&Permissions
Authorities决定特定message是否被正确授权。
每个账户都有两个原生具名的permissions
1. Owner 代表一个账户的所有权。只有少数transactions需要此authority，但任何需要改动owner authority的message都需要。总的来说，我们建议把owner冷储存起来，不要和任何人共享。owner可以用来恢复另一个可能已经被损害的（compromised）permission.
2. active 可用来转账资金、给区块生产者投票及进行另一些高级的账户改动。
除了原生permissions外, 账户可有自定义的具名permissions，以扩展对账户的管理功能。自定义permissions是非常灵活的，可以用于各种各样的场景。
任何authority的Permission都可以被分配给一个或多个公钥或一个有效的账户名。
五、默认账户配置 (Single-Sig)
这是某账户创建后如何配置的例子。该账户的owner和active permissions都各自有一个key, 两个keys的权重都是1且阈值也是1。默认配置需要一个签名来授权对于原生permissions的message。
@bob account authorities
| Permission | Account | Weight | Threshold |
| owner | EOS5EzTZZQQxdrDaJAPD9pDzGJZ5bj34HaAb8yuvjFHGWzqV25Dch | 1 | 1 |
| active | EOS61chK8GbH4ukWcbom8HgK95AeUfP8MBPn7XRq8FeMBYYTgwmcX | 1 | 1 |
在@bob账户这个例子中，依表格所示，@bob's的owner key的权重是1，在该authority下推送一个transaction所需要的阈值也是1
。如果需要在owner的authority下推送一个transaction，只需要@bob用它的owner key签名一个transaction，此transaction即可被认为有效。这个key将被储存在一个wallet中，并用eosc来管理。
六、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。乍看之下这可能不重要，但是这确实增加了灵活性。