账户和权限
帐户是存储在区块链中的人类可读标识符。 每个交易都根据配置的帐户权限对其权限进行评估。
每个已命名的权限都有一个阈值，必须满足该权限下签署的交易才能被视为有效的阈值。 交易
通过使用已经安装和解锁钱包的客户端来签署。 钱包是保护和利用你的密钥的软件。 这些密
钥可能授权也可能不授权区块链上的账户权限。
钱包是一个存储可能与账户有关的密匙的客户端。通常情况下，钱包有锁定和解锁两种状态并通过
一个高熵密码保护。
EOSIO/eos
库有一个名为
cleos
的命令行界面客户端，它与一个名为
keosd
的
lite客户端进行交互，并且共同展示了钱包的这种模式。
帐户是存储在区块链中的人类可读标识符。它可能属于一个个人或者组织，这取决于账户的权限配置，
需要账户才能将交易或将交易以其他方式推送到区块链。
权限确定是否授予任何给定的行为。
每个账户有两个默认的权限名称：
-
owner
owner
权力作
出任何改变的行为。 一般而言，建议所有者保持冷藏并且不与任何人共享。
owner
泄露的另一个权限。
-
active
除了默认权限之外，帐户还可拥有可用于进一步扩展帐户管理的自定义命名权限。 自定义权限非常灵活，并且
在实际应用中可以解决许多可能的用例。 这很大程度上取决于开发人员如何使用它们，以及采用什么约定（如果有的话）。
任何给定权限的权限可以分配给一个或多个
public key
或有效的
account_name
。
以下是所有上述概念的组合以及它们如何实际应用的一些例子。
这是帐户在创建后的配置，它的
owner
和
active
权限只有一个key，两个key的权重都是1并且两个权限的阀值
都是1。对于账户的默认权限配置只需要单个签名来授权操作。
@bob
@bob
| 权限 | 账户/key | 权重 | 阀值 |
|---|---|---|---|
| owner | 1 | ||
| EOS5EzTZZQQxdrDaJAPD9pDzGJZ5bj34HaAb8yuvjFHGWzqV25Dch | |||
| active | |||
| EOSh61chK8GbH4ukWcbom8HgK95AeUfP8MBPn7XRq8FeMBYYTgwmcX |
在
@bob
账户例子中， 这个表格展示了
@bob's
owner key
有一个权重为１的权限，并且
进行操作需要的权限阀值为1.
要在所有者权限下推送交易，只有
@bob
需要使用其所有者密钥对交易进行签名，以使交易符合验证条件。
将此密钥存储在钱包中，然后使用
cleos
进行处理
以下示例是名为
@multisig
的虚构帐户的权限。 在这种情况下，两个用户被授权为虚构的
@multisig
帐户的
owner
active
，三个用户被授予权重不同的自定义
publish
权限。
@multisig
@multisig
| 2 | |||
| |||
| |||
| |||
| |||
| publish | |||
| |||
| |||
| EOS7Hnv4iBWo1pcEpP8JyFYCJLRUzYcXSqt..... |
在这种情况下，需要权重阈值2来更改所有者权限级别，这意味着由于所有方都具有权重1，
因此所有用户都必须签署交易才能获得完全授权。
要发送交易需要
active
权限，阈值设置为1.这意味着只需要1个签名即可授权来自帐户
active
权限的操作。
还有一个名为
publish
的自定义命名权限。 为了这个示例，发布权限用于使用理论博客dApp将帖子发布到
@multisig
的博客。
发布权限的阈值为2，
@bob
@stacy
的权重均为2，公钥的权重为1.这意味着
@bob
@stacy
可以在没有额外签名的情况
下发布，而公钥需要额外签名才能在公共许可下进行授权操作。
因此，上述权限表意味着作为帐户所有者的
@bob
@stacy
提升了与主持人或编辑者类似的权限。 尽管这个原始示例在可扩展性方面
有特别的限制，并不一定是一个好的设计，但它充分证明了
EOS权限系统的灵活性。
此外，请注意上表中的权限是使用帐户名称和密钥设置的。乍一看这可能看起来微不足道，但它确实提出了一些额外的灵活性。
意见
-
@bob
@stacy
- 没有来自
@bob
@stacy
-
@bob
@stacy
可以在发布权限下推送一个操作，而不需要任何额外的签名。
原文链接:
https://eosfans.io/wiki/account-permission
![DB2表压缩功能[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)