EOS暴力入门（六）| 解读EOS白皮书2.0之管理账户
image
本期是EOS入门解读最新白皮书第六篇——账户系统，而智能合约的业务逻辑便是通过账户系统来实现的。我们通过集中解读白皮书里面的概念，解释“是什么”的问题。
由于这部分白皮书内容比较晦涩，为了让更多小白看官愉快的入坑，我们在译文的后面增加了新的部分——白话解读，将运用类比现实生活等方法解读原文。
一、账户
EOS.IO软件允许使用唯一的长度为12个字符的可读名称来实现对帐户的引用。该名称由帐户的创建者命名。帐户创建者必须保留存储新帐户所需的RAM，直至新帐户存储令牌以保留其自己的RAM。
在去中心化的情况下，应用程序开发人员将支付创建帐户的名义成本，用来注册新用户。传统企业为获取每个客户，已经以广告、免费服务等形式花费了大量资金。相比之下，创建新的区块链账户所需的资金成本微不足道。并且幸运的是，如果该用户在其他应用上已经注册了，则无需再创建新账号。
白话解读：
账户的创建者可以在创造账户时输入不超过12个字符的名称，可以类比为在创建账户时输入网名“Bob”等，相比较比特币和以太坊的一大串64位地址，更方便使用。EOS.IO更显体贴，创建账号所需要的RAM资源，是由EOS代币持有者等比例持有的，且这部分花费不需要用户承当，开发人员将承当这部分的费用，如果在同一条公链上，不同的用户是可以共用一个账号的，不需要再创建新账户。
二、Actions和处理程序
每个帐户可以将结构化的Actions发送到其他帐户，并且可以定义脚本来处理收到的Action。EOS.IO软件为每个帐户提供自己的专用数据库，这个数据库只能由自己的Action处理程序访问。Action处理脚本还可以将操作发送到其他账户。Action和自动Action处理程序的组合定义了EOS.IO撰写智能合约方式。
为支持并发执行操作，每个账户同样可以在他们数据库内定义任意数量的范围。区块生产者将以这样一种方式来安排事务，这种方式对存储器访问范围没有冲突, 因此他们可以并发执行。
白话解读：
这里的"Action"与白皮书1.0中“Messages”代表的意思相同，方便理解原理大家也可以用信息来理解，类比：妈妈发送一条信息让你回家吃饭，你收到信息后自动的喊上了身边的小伙伴，让他和你一起回家吃饭。在账户中这种收到消息，自动触发将消息发给第三个账户的例子就是智能合约的一种形式。
并发执行的意思就是，多个相互独立的程序交叉执行的方式。类比：你要完成两项家务1.煮饭、2.拖地。怎么样才能最快速的完成？当然是先将米洗好放入电饭煲，在等待饭煮熟的过程中完成拖地任务。并发执行的多个程序的 起止时间是交叉重叠的，这样可以更高效的完成信息和信息处理，前提是并发执行的程序范围不能重合，你总不能在拖地的时候，把拖把放入电饭煲中洗。
三、基于角色的权限管理
权限管理涉及确认某项Action是否被正确授权。最简单形式的权限管理是检查交易是否具有所需的签名，这也意味着所需的签名为已知。一般而言，授权涉及个人或群体，并且往往是分门别类的。EOS.IO软件提供了一个声明式权限管理系统，可以对帐户进行细粒度、高级别的控制，以确定谁可以做什么和什么时候做什么。
认证和权限管理必须标准化，并与应用程序的业务逻辑分开，这是至关重要的。这使得开发工具能够以通用的方式管理权限，并为性能优化提供巨大空间。
每个帐户都可以通过其他帐户和私钥的任何加权组合来控制。这创建了一个分层的许可结构，真实反映了权限的组织方式，并使得多用户对账户的控制比以往更容易。多用户控制是提升安全性的最大贡献者。如果使用得当，会极大降低黑客攻击而造成的盗窃风险。
EOS.IO软件允许帐户定义哪些组合(其他账户与密钥的多种组合)可以将特定Action类型发送到另一个帐户。例如，一个用户的社交媒体账号有一个对应的密钥，用于访问交易所的则是另一个密钥。甚至用户可以给其他帐户授权，被授权的账户可以代表本账户进行操作，而无需分配密钥。
白话解读：
EOS.IO提供了一个声明式权限管理系统，暨账户可以分类给其他个人或群体权限，权限的范围包括可以做什么和什么时候做什么，类比：在家设立一个保安队（分类），保安队有两个人保安A和保安B。给保安A的权限是早上6：00——晚上6:00拥有大开大门的权力，给保安B的权限是晚上6:00——次日早上6:00拥有大开大门的权力。这样做的好处就是权限可以足够细化且方便控制和检查。
业务逻辑与权限管理的分开是十分有必要的，运用上面的例子：不同的业务逻辑是保安队需要到其他的地方站岗，每换一个地方都要重新分配权限是不合理的，权限的分配是可以通用的，也就是说他们依然可以按照之前的分配工作。这样就开发者就可以将注意力集中在业务逻辑上，体现了权限管理的通用性。
通过权限的分配来使其他用户共同维护一个账户，多用户控制可以提升账户的安全性，如果你是账户的唯一用户，黑客只要黑了你就可以获得账户的控制权，但是通过账户和私钥加权组合，设置权重和阀值让多个用户来控制，黑客就要黑了所有的用户才能获得账户的控制权。
这段话说明了，EOS的权限分配的组合方式可以是多重多样的，具体可以根据用途来定义。
四、命名权限级别
使用EOS.IO软件，帐户可以定义命名的权限级别，每个权限级别可以从更高级别的命名权限中派生。每个命名权限级别定义一个许可。许可是一个阈值，这个阈值是包含密钥的多重签名检查 或者 其他账户的命名权限级别。例如，帐户的“朋友”权限级别可以设置为帐户能被帐户的朋友同等控制。
另一个例子是Steem区域链，它具有三个硬编码命名的权限级别：owner， active和posting。Posting权限只能执行诸如投票和发布等社交行为，而active权限可以执行除更改所有者的所有操作。Owner权限应被冷存储，可以执行一切操作。EOS.IO软件允许每个账户所有者定义自己的权限管理以及Actions的分组，以此来扩展这一管理理念。
白话解读：
命名权限级别就是给固定的名称添加权限，也可以理解为一个分组名称，类比为：家中有主人、管家、保安。主人可以任命管家，管家可以任命保安。保安这个名称的权限仅仅为开门，而管家的权限为除了主人的行动和命令以外的所有权限，管家可以拥有保安开门的权限但保安不能拥有管家的权限，除非主人任命他为管家。在重大事务的抉择中，家里有要超过两个管家的同意才能执行的设定。这就涉及到权重和阀值的意义，不同的名称其实也就代表不同的权限等级，这样可以灵活的用于不同场景，不同用途。
阀值和权重的意义可参考下面这个Action
image.gif
Actions的执行，需要满足一个阈值。比如要完成一个转账操作，设定的许可阈值是2，则一定要达到这个阈值，才能转账。Bob、Stacy的权重都是1，因此要获得Bob和Stacy的授权才可以完成这个操作。
五、权限映射
EOS.IO软件允许每个帐户去定义一个映射，这可以是这个账户的合约/Action与他自己的命名权限级别的映射，也可以是其他账户的合约与命名权限级别的映射。例如，账户持有人可将其社交媒体应用程序映射到账户所有者的“朋友”权限组。通过此映射，账户中的任何朋友都可以作为账户所有者，在社交媒体发布信息。虽然这些朋友可以作为帐户所有者发布信息，他们仍然会使用自己的密钥来签名。这意味着可以确定哪些朋友，以何种方式使用了该帐户。
白话解读：
通过权限映射便可以实现多账户控制，让相应的账户做出合适的操作，但其他账户在执行该操作时，会留下“记录”---因为其他账户必须使用密钥来签名才能完成操作。
像管家与他所能做的事情，可以理解为账户权限与Action的映射，这个映射便决定了管家能做的事情；管家与保安的关系，可以理解为账户与账户之间权限的映射，这个映射决定了保安受管家控制，保安的权限由管家决定。管家、保安做的所有事情都会留下指纹痕迹，这个指纹痕迹便可以理解为密钥签名。
六、账户操作实际案例
我们参考EOS官方wiki的简单例子，理解整个账户的实际运作体系。
image.gif
image.gif
七、概念解析
权限（permission）：权限规定账户可以做出的行为，比如指定的两个权限owner和active，前者是账户的所有权，后者则可用来转账、为生产者投票等。
权重（weight）：在EOS里，账户有权重weight，比如bob账户的权重为1。
阀值(threshold): 交易要能被正常执行，必须满足该阈值，需要有账户对其授予正确的权限。比如阈值为2，就需要两个权重为1的账户Bob和Stacy一起授权，才能执行该权限。
许可（Authrorities）:许可决定是否给予适当的授权，所有的权限都是经过许可来授权。
钱包(Wallets)：钱包只是本地存储私钥，加验证签名，以及与节点交互的工具。没有钱包，也可以用命令行与节点交互。
八、白皮书英语原文
读白皮书，另一个目的也是学习英语，今后如果DAPP的第一波爆发，估计有不少是国外的项目，比如现在很火的eosDAC和everpedia, 因而补上英语原文。
Accounts
The EOS.IO software permits all accounts to be referenced by a unique human readable name of up to 12 characters in length. The name is chosen by the creator of the account. The account creator must reserve the RAM required to store the new account until the new account stakes tokens to reserve its own RAM.
In a decentralized context, application developers will pay the nominal cost of account creation to sign up a new user. Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. The cost of funding a new blockchain account should be insignificant in comparison. Fortunately, there is no need to create accounts for users already signed up by another application.
Actions & Handlers
Each account can send structured Actions to other accounts and may define scripts to handle Actions when they are received. The EOS.IO software gives each account its own private database which can only be accessed by its own action handlers. Action handling scripts can also send Actions to other accounts. The combination of Actions and automated action handlers is how EOS.IO defines smart contracts.
To support parallel execution, each account can also define any number of scopes within their database. The block producers will schedule transaction in such a way that there is no conflict over memory access to scopes and therefore they can be executed in parallel.
Role Based Permission Management
Permission management involves determining whether or not an Action is properly authorized. The simplest form of permission management is checking that a transaction has the required signatures, but this implies that required signatures are already known. Generally, authority is bound to individuals or groups of individuals and is often compartmentalized. The EOS.IO software provides a declarative permission management system that gives accounts fine grained and high-level control over who can do what and when.
It is critical that authentication and permission management be standardized and separated from the business logic of the application. This enables tools to be developed to manage permissions in a general-purpose manner and also provide significant opportunities for performance optimization.
Every account may be controlled by any weighted combination of other accounts and private keys. This creates a hierarchical authority structure that reflects how permissions are organized in reality and makes multi-user control over accounts easier than ever. Multi-user control is the single biggest contributor to security, and, when used properly, it can greatly reduce the risk of theft due to hacking.
EOS.IO software allows accounts to define what combination of keys and/or accounts can send a particular Action type to another account. For example, it is possible to have one key for a user's social media account and another for access to the exchange. It is even possible to give other accounts permission to act on behalf of a user's account without assigning them keys.
Named Permission Levels
image.gif
Using the EOS.IO software, accounts can define named permission levels each of which can be derived from higher level named permissions. Each named permission level defines an authority; an authority is a threshold multi-signature check consisting of keys and/or named permission levels of other accounts. For example, an account's "Friend" permission level can be set for an Action on the account to be controlled equally by any of the account's friends.
Another example is the Steem blockchain which has three hard-coded named permission levels: owner, active, and posting. The posting permission can only perform social actions such as voting and posting, while the active permission can do everything except change the owner. The owner permission is meant for cold storage and is able to do everything. The EOS.IO software generalizes this concept by allowing each account holder to define their own hierarchy as well as the grouping of actions.
Permission Mapping
EOS.IO software allows each account to define a mapping between a contract/action or contract of any other 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 Action. This means it is always possible to identify which friends used the account and in what way.
预告:下一篇是《解读EOS最新白皮书之账户权限映射》，解读白皮书针对账户的具体操作。
image.gif
关注公众号点击底部菜单栏EOS入门系统自动发送相关教程
= END =
长按识别下方二维码
即可关注IMEOS.ONE公众号
