image
image
本部分是账户体系的精华，通过本文的介绍，会明白账户的权限分配机制；以及可以恢复账户密钥的原理和操作。
一、权限评估
从@alice到@bob传递类型为“ Action ” 的操作时，EOS.IO软件将首先检查@alice是否被@ bob.groupa.subgroup. Action定义过权限映射。如果没有发现任何结果，那么将会检查@ bob.groupa.subgroup，然后检查@ bob.groupa，最后检查@bob。如果没有找到进一步的匹配，则假定的映射将是命名权限组@alice.active。
一旦识别出映射，则检查该签名的授权：是否满足多重签名的阈值以及命名权限级别相关联的授权。如果失败，那么它会遍历父类权限，最后遍历所有者的权限，即@alice.owner。
image
白话解读：
整个账户体系或者说智能合约的精华就在这个图里，为方便理解，重新构建一幅更加清晰的图。
Step1 权限分级
image
首先，Friends是个子权限，它能做的事，Family可以做，Active、Owner都可以做。
再次，Family和Lawyer是同级别的权限，若某任务被指定了lawyer权限，则Family不能处理。
Step2 权限映射
权限可以与一个合约或者Action映射，而这个合约既可以是自己账户的也可以是其他账户的。
image
通过权限映射，Family权限可以执行交易所合约的所有事情,但唯独不能取现。因为取现被授权给Lawyer，因此Family权限实际上只能执行@交易所合约/交易。
但是Active、Owner作为更高一级的权限，可以执行交易所合约的所有Actions.
Step3 算法解读示例
若@user要执行“买入”这个Action，先检查交易所合约的映射再检查是否满足权限的阈值。
检查交易所合约的映射：首先检查是否有定义”@交易所合约/交易/买入“这个映射；若没有，则再检查是否有定义@交易所合约/交易。若二者都不满足，则无法执行该Action；若满足其一，则检查“@交易所合约”映射对应的权限。
检查是否满足权限的阈值：交易所合约对应的权限是Family, 因此如果满足Family权限的阈值，即可执行；或者满足更高一级别的权限Active、Owner,也可执行“买入”这个Action。但是若该账户是Lawyer权限，则无法执行。
同理，若@user要执行“取现”这个Action,先检查是否有“@交易所合约/取现”这个映射。若没有，则无法执行（假如只有”@交易所合约“映射，只能执行@交易所合约/交易）。若有，这个映射对应的权限是Lawyer, 用户满足Lawyer、Active、Owner任意一个的权限阈值即可执行Action.
这里还可以看出，"取现"这个Action安全级别要更高，相比起“买入”只要满足两个映射的其中一个映射即可，要实现“取现”这个Action, 它必须得有“@交易所合约/取现”这个映射。
二、默认权限组&并发评估权限
默认权限组
EOS.IO技术还允许所有账户拥有一个可以完成所有操作的“owner”权限组，而一个“active”权限组除了更改所有组之外，可以执行所有操作。所有其他权限组均由“active”组派生。
并发评估权限
权限评估过程是“只读”的，并且对事务所做的权限更改直到块结束才会生效。这意味着所有事物的密钥和权限评估可以并发执行。此外，这意味着可以快速验证权限，而不需要重新启动昂贵的应用程序逻辑。最后，这意味着交易权限可以在接收到待处理的交易时进行评估，而在应用它们时无需重新评估。
从整体来看，权限验证占验证交易所需计算的很大一部分。让权限验证成为一个只读与可并发化的过程可以显著提升性能。
当我们重放区块链的历史，试图从操作日志重新生成确定性状态时，不需要再次评估权限。交易包含在一个已知的不可逆的区块中这一客观事实，足以让其跳过权限评估的不周步骤。这极大减少了重放不断增长的区块链时消耗的计算量。
白话解读：
上面提到，权限管理和程序逻辑是分开独立的，自然权限评估和程序逻辑也是可以分开的执行，让权限验证成为一个自读过程且是并发执行、跳过多余的权限评估过程，这样可以整体提高性能，显著提高tps性能。
三、强制延迟的操作
时间是安全的关键组成部分。在大多数情况下，不可能知道私钥是否被盗用，直到它被使用。
因为人们日常使用的一些应用程序需要将密钥保存在联网的电脑上，所以基于时间的安全机制更为重要。因为消息是在区块后的，所以EOS.IO软件可以使应用程序开发人员指定某些Actions在应用前必须等待一小段时间，而在此期间可以取消该操作。
当这类消息被广播时，用户可以通过电子邮件或短信收到相应通知。如果用户没有授权，那么他们可以登录帐户来还原账户数据并撤回Action。
所需的延迟取决于操作的敏感程度。支付一杯咖啡可以毫不拖延地在几秒钟内确认且不可撤回，而买房子可能需要72小时的清算周期。将整个帐户转移到新的用户可能需要30天。具体延迟取决于应用程序开发人员和用户。
白话解读：
强制延迟操作是为了保护账户安全的一项设计，开发人员通过对应用程序延迟时间的设定，可以让用户在一定时间内撤回操作，这就让误失私钥的用户，可以在账户被黑客等控制做出违背账户用户意愿的操作时，用户有一定的挽回空间。
四、被盗钥匙恢复
EOS.IO软件为用户提供了密钥被盗时恢复其帐户控制的方法。该账户的所有者可以在其他账户上重置密钥，前提是其他账户所有者的密钥在过去30天是活跃的并且获得了指定合作伙伴账户的批准。没有账户所有者的配合，帐户恢复合作伙伴无法重置帐户的控制权。
对于黑客而言，由于其已经“控制”该账户，因此尝试执行恢复过程没有任何收获。此外，如果黑客执行恢复过程，恢复伙伴可能需要身份认证和多因素认证（电话和电子邮件）。这可能会暴露黑客身份，或者黑客在恢复过程中毫无所得。
这个过程也与简单的多重签名交易有着极大的不同。通过多重签名交易，另一个实体会成为每个执行交易的一方。相比之下，通过恢复过程，恢复合作伙伴仅参与恢复过程，无权参与日常交易。这极大降低了所有参与者的成本和法律责任。
白话解读：
被盗钥匙恢复类比就是微信的密码找回，需要一定数量的好友配合发送特定的数字方可确认你账号主人的身份，从而获得修改密码的权利。而在EOS中，可指定一部分账户拥有恢复账户秘钥的权限，在账户所有者的配合下，提供这一部分好友的私钥，即可重置所有者的密钥。
五、白皮书英语原文
读白皮书，另一个目的也是学习英语，今后如果DAPP的第一波爆发，估计有不少是国外的项目，比如现在很火的eosDAC和everpedia, 因而补上英语原文。
Evaluating Permissions
When delivering an Action of type "Action", from @alice to @bob the EOS.IO software will first check to see if @alice has defined a permission mapping for @bob.groupa.subgroup.Action. If nothing is found then a mapping for @bob.groupa.subgroup then @bob.groupa, and lastly @bob will be checked. If no further match is found, then the assumed mapping will be to the named permission group @alice.active.
Once a mapping is identified then signing authority is validated using the threshold multi-signature process and the authority associated with the named permission. If that fails, then it traverses up to the parent permission and ultimately to the owner permission, @alice.owner.
image
Default Permission Groups
The EOS.IO technology also allows all accounts to have an "owner" group which can do everything, and an "active" group which can do everything except change the owner group. All other permission groups are derived from "active".
Parallel Evaluation of Permissions
The permission evaluation process is "read-only" and changes to permissions made by transactions do not take effect until the end of a block. This means that all keys and permission evaluation for all transactions can be executed in parallel. Furthermore, this means that a rapid validation of permission is possible without starting costly application logic that would have to be rolled back. Lastly, it means that transaction permissions can be evaluated as pending transactions are received and do not need to be re-evaluated as they are applied.
All things considered, permission verification represents a significant percentage of the computation required to validate transactions. Making this a read-only and trivially parallelizable process enables a dramatic increase in performance.
When replaying the blockchain to regenerate the deterministic state from the log of Actions there is no need to evaluate the permissions again. The fact that a transaction is included in a known good block is sufficient to skip this step. This dramatically reduces the computational load associated with replaying an ever growing blockchain.
Actions with Mandatory Delay
Time is a critical component of security. In most cases, it is not possible to know if a private key has been stolen until it has been used. Time based security is even more critical when people have applications that require keys be kept on computers connected to the internet for daily use. The EOS.IO software enables application developers to indicate that certain Actions must wait a minimum period of time after being included in a block before they can be applied. During this time, they can be cancelled.
Users can then receive notice via email or text message when one of these Actions is broadcast. If they did not authorize it, then they can use the account recovery process to recover their account and retract the Action.
The required delay depends upon how sensitive an operation is. Paying for a coffee might have no delay and be irreversible in seconds, while buying a house may require a 72 hour clearing period. Transferring an entire account to new control may take up to 30 days. The exact delays are chosen by application developers and users.
Recovery from Stolen Keys
The EOS.IO software provides users a way to restore control of their account when keys are stolen. An account owner can use any owner key that was active in the last 30 days along with approval from their designated account recovery partner to reset the owner key on their account. The account recovery partner cannot reset control of the account without the help of the owner.
There is nothing for the hacker to gain by attempting to go through the recovery process because they already "control" the account. Furthermore, if they did go through the process, the recovery partner would likely demand identification and multi-factor authentication (phone and email). This would likely compromise the hacker or gain the hacker nothing in the process.
This process is also very different from a simple multi-signature arrangement. With a multi-signature transaction, another entity is made a party to every transaction that is executed. By contrast, with the recovery process the recovery partner is only a party to the recovery process and has no power over the day-to-day transactions. This dramatically reduces costs and legal liabilities for everyone involved.
网友评论