EOS之旅（2）

正文共：6389字

预计阅读时间：16分钟

《EOS.IO白皮书》

说明：绿色底为白皮书原文，其余为EOS白皮书的解读部分。

共识算法（DPOS）

交易确认

通常DPOS区块链100%会有区块生产者参考。一个交易从广播开始后平均1.5秒就可以99.9%被认为确认了。

在一些特殊情况下例外，软件出现bug，网络拥塞，或一个恶意的区块生产者制造了两个或更多的分叉。为了确保一个交易绝对是不可逆的，一个节点可以选择等待21区块生产者中的15个给出确认。基于通常的EOS.IO软件配置，在一般情况下这需要平均45秒的时间。默认情况下，所有的节点将认为当21个生产者中有15个给出确认后这一区块就是不可逆的了。并且不管长度如何都不会切换到没有这一区块的分叉。

EOS.IO提供了一系列的接口文档，不把其中任何一个参数写死。尽多的开放参数，通过参数方便的调节系统的性能。

确认率和确认时间是一对相互矛盾的性能参数。确认率越高，确认时间就越长；所以，为了缩短确认时间，就必须降低确认率。降低确认率，并且能证明这一区块不可逆。需要做大量的测试得到一个最低的确认率。这个确认率在一般的网络环境下，可以代表99.9%的确认率。

白皮书没有告诉15/21这个确认率是如何得来的。但我相信，这个确认率一定不是BM凭空任意想像出来的，必有一定的理论依据或各种网络环境下的测试数据作支撑。

股权证明的交易（TaPoS）

EOS.IO软件需要每一个交易包含最近一个区块头的哈希值。这个哈希值有两个目的：

1、防止不包含区块引用的交易在分叉时重放发生。

2、通知网络对应的用户和他们的股份当前在某个具体的分叉上。

随着时间的推移，所有的用户直接确认区块链，在这一链条上难以伪造假的链条，因为假的链条根本无法从合法链条上迁移交易。

EOS.IO软件要求每个交易都包括最近的区块头的哈希值。

这个哈希值有两个目的：

1.防止分叉区块链上出现大量交易记录；

2.使得系统能感知到用户是否在分叉的区块链上。

总之，基于交易的权益证明，要求每个交易都包括最近的区块头的哈希。这个可以防止分叉链上出现大量交易，系统能够感知用户在分叉链上。

账户

EOS.IO软件允许所有的账户使用一个唯一的人类可读的名称来索引，长度在2到32个字符之间。这个名称由账户创建者自己选择。所有的账户必须在创建时用极少的账户余额来注资，从而覆盖存储账户信息的成本。账户名称也支持命名空间，比如@domain这个账户的拥有者是唯一可以创建@user.domain账户的人。

创建索引的主要目的是：为了提高查询的效率。

EOS创建账户索引的主要目的是：为了提高查询账户的效率。账户名称支持命名空间，这样把查询变成一个立体查询，而不是一个平面查询。

比如一个地址查询：“中国.新疆.乌鲁木齐.天山区.幸福路”。“新疆.乌鲁木齐.天山区.幸福路”只需在"中国"地区查询，不用再查询其他国家。“乌鲁木齐.天山区.幸福路”，只需在“中国.新疆”范围内查询，不用再查询中国的其他地方。“天山区.幸福路”只需在“中国.新疆.乌鲁木齐”范围内查询。“幸福路”只需在“中国.新疆.乌鲁木齐.天山区”范围内查询。这样一级一级缩小查询范围，这是一个最快的查询路径。这就是立体查询方式。

在一个去中心化的场景中，应用开发者将会为新用户注册成本买单。比起来，资助一个新的区块链账户的花费简直微不足道。值得庆幸的是，对一个已经在另一个应用注册过的用户并不需要再创建新的账户。

过去，每一个APP上都需要注册新的用户，每一个新用户都需要注册，并且不方便记忆。现在，很多的APP都在共用微信的用户账户。这样以来，为每一个用户节约了繁琐的注册时间，同时更好的保护了用户的隐私，同时方便用户记忆。

仅这个角度，腾讯微信已经成为应用APP的账户管理中心。离开了腾讯微信，很多的应用APP需要重新创建账户。

消息&处理

每个账户可以发送结构化的消息给其他账户，并且可以定义脚本来处理接收到的消息。EOS.IO软件给每个账户提供了只有自己的消息处理脚本能访问的私有数据库。消息处理脚本同样可以给其他账户发送消息。消息和自动化的消息处理的结合决定了EOS.IO如何定义智能合约的。

消息结构化可以更方便接收方处理消息，提取其中有用的信息。虽然现在已经有了人工智可以提取特征值，但在处理速度上，结构化的消息处理速度一定比自然文本的消息处理速度高出很多个数量级。所以，能结构化的消息尽量结构化，对提高处理速度有很大的贡献。

当然并不是所有的消息都能结构化。在EOS中，为什么消息可以结构化呢？因为这些消息主要是用来传递交易信息的，交易信息几乎可以用标准化的语言来表达，这样的消息很容易被结构化。

EOS.IO软件给每个账户提供了只有自己的消息处理脚本能访问的私有数据库。不得不佩服EOS的资源分配方案。我们购买EOS代币，不是一种虚拟币，而是实实在在的EOS系统的资源。

比如你购买了1%的EOS代币，那么你就有1%的EOS系统资源。如果我们要在EOS系统上搭建应用APP，就需要购买一定EOS代币，否则我们搭建的应用APP将无法使用。EOS系统只分配给你EOS代币所对应的资源。

这种机制对于防止DOS攻击最有效。有效地解决了目前互联网DOS攻击的复杂难题，同时兼容现有互联网特点--免费。

基于角色的权限管理

权限管理涉及判定一条消息是否被正确的授权。权限管理最简单的形式就是检查一个交易包含必须的签名，但这意味着必须的签名是已知的。一般情况下，权威必然是独立的个体或者个体组成的群体，并且是被划分开的。EOS.IO软件提供了声明式的权限管理系统，通过管理谁可以在什么时间做什么来给用户细力度和高维度的控制。

有法律效应的数字签名是现在互联网上使用最广泛的签名。但在现在的互联网上，一笔业务可能存在多处的数字签名。这就增加了系统处理业务的速度。在大数据时代的今天，这样的处理速度是不可容忍的。

EOS系统是这样处理的：一个交易业务，把第一次数字签名记录下来，然后将其加入一区块中。后续再需要数字签名时，重复调取这个区块信息实现数字签名即可。这即保证了交易的真实性，也保证了交易的高效性。

授权和权限管理被标准化和脱离应用的商业逻辑上不可取的。这使得管理权限的工具得以被开发，既满足常规的需求又为性能优化提供了重要的可能性。

基于角色的权限管理思想目前已经非常成熟。我们不直接把权限赋予给用户，而是把角色来赋予给用户，因为用户拥有某一种权限是因为用户扮演着某一种角色。

比如：护士具有给病人办理入科手续、测量生命特征、校对医嘱、摆药、计各种费用、书写护理记录单、画体温单、打印医嘱单......等权限，我们并不为每一个护士分配这些权限。

而采用的是更高效的权限分配方案。创建一个“护士”角色，为这个角色分配这些复杂权限。医院里护士所从事的工作都一样，给每一个护士赋予相同的角色即可。

这样，即满足了常规的需求，又优化了性能。

每一个账户可以被任何权重组合的其他账户和私钥管控。这创建了分层级的权利结构，这反映了现实中的权限分配方式，并且让多用户共同管理资产变得从未如此简单。多用户控制是安全最大的贡献者，并且，当用户使用得当，它可以极大的消除因被黑而导致被盗窃的风险。

多用户控制是安全最大的贡献者。很多银行的后台数据库密码都是采取至少两个以上用户共同制定。单独一个人无法凭借自己的密码打开数据库，无法查询数据库的任何信息。只有两个人同时贡献自己的密码才能打开数据库。

举个例子，可以指定一个密钥给一个用户的社交媒体账号，同时另一个密钥访问交易所。甚至可以给其他账户权限来代表自己而无需分配给他们密钥。

私钥是银行账号+密码。所以私钥必须妥善保管好，建议不保存在连网的计算机上；建议不保存在QQ、微信、锤子便签等APP里；建议保存在离线的计算机里；或手抄在笔记本上。

命名的权限级别：在EOS.IO软件中，账户可以定义命名的权限级别，每一个是由更高级别的命名权限派生而来。每一个命名的权限级别定义了一个权威；一个权威是多重签名阈值校验，它包含密钥和/或其他账户的命名权限级别。打个比方，一个账户的“朋友”权限级别可以被设置为由该账户的任何一个朋友无差别的控制。

另一个例子在Steem区块链中，它包含三个硬编码的命名权限级别：拥有、活跃和发帖。发帖权限就只能进行如投票和发帖的社交活动。而活跃权限可以做除了变更拥有之外的所有的事情。拥有权限的意思是冷存储并且有能力做任何事。

在数据库中，权限级别有查询权限、部分修改权限、完全拥有权限。这种权限可以精确到每一张表。

权限级别管理是较灵活的权限分配方案，上一级的账户拥有下一级账户的所有权限，并拥有这一级别特有的权限密钥。

权限映射：EOS.IO软件允许每个账户定义从任意账户的一个命名的消息处理群组与自己的命名的权限级别之间建立映射。举个例子，一个账户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。有了这个映射，任何朋友可以以这个账户的身份在这一账户的社交媒体上发帖。尽管他们将以账户所有者的身份发帖，他们仍然使用自己的密钥来签名消息。这意味着总是可以辨识出是哪一个朋友在以何种方式使用账户。

有了这个映射，任何朋友可以在这个账户的身份在这一账户的社交媒体上发帖。并使用自己的密钥来签名消息。这个可以辨识出谁在以何种方式使用账户。避免为每一个用户单独分配权限，还能辨识出是哪一个朋友何时发出消息。

权限的评估环节，如果映射识别通过，则进行多签名流程验证签名，如果映射识别未通过，则通过分层机制逐级检查。这是一种很快的权限评估机制。

默认权限群组：所有其他的全新群组派生自“活动”群组。

权限的并行评估：权限评估过程是“只读”的，并且通过交易对权限的变更在一个区块结束之前不会起作用。这意味着对所有的交易对应的密钥和权限评估可以被并行执行。此外，这意味着一个快速的权限验证是可行的。它无需启动会引起回滚需要的高成本的应用逻辑。最后，这意味着交易权限可以被评估即便接收到等待的交易，并且之后无需再重新评估。

从各方面考虑，权限验证占据了验证交易计算量的很大比例。让其只读和普遍的并并处理将会使得性能有一个质的飞跃。

当从消息日志中重新生成确定性状态时不再需要的权限验证。事实是一个交易如果被包含近了一个被认为不存在问题的区块时它就有足够的理由跳过这步这将极大减少因为区块链增长拉去过去记录时的计算量。

区块链中很大一部分交易量是权限验证，所以，权限验证成为区块链处理大型交易量的瓶颈。如何提高权限验证速度，成为EOS技术专家们不得不解决的问题。

很庆幸的是，EOS采取并行验证机制。并行验证机制的前提是验证的权限信息是只读的。我们都知道，如果是对信息进行修改，并行操作很可能造成信息前后的不一致。所以，信息只读让并行验证成为可能。猜想，在EOS的后台数据库，对权限在线信息表进行了一个快照，这个快照设置为只读。快照定期与权限在线信息表进行同步。

另外，同取消重复的签名机制一样，在EOS.IO采用取消重复验证提高验证效率。

带强制性延时的消息

时间是安全中的一个关键组成部分。在大多数情况，一个私钥在没有被使用前都无从知晓它是否被偷窃。当人们有需要密钥的应用在每天联网使用的电脑上运行时，基于时间的安全会更为重要。EOS.IO软件让应用开发者可以指明消息必须在被加到一个区块之前等待最小的时间间隙。

用户可以在消息广播出去后通过邮件或者文字消息的形式收到通知。如果他们没有授权，那么他们可以使用账户恢复流程来恢复账户，并收回消息。

这个必须的延时由操作敏感性决定。为一杯咖啡付款可以没有任何的延时，几秒之内就不可逆了，而购买一个房子也许需要72小时的结算期。转移整个账户到一个新的控制可能需要长达30天。具体的延时选择由开发者和用户自己来做选择。

EOS.IO软件让应用开发者可以指明消息必须在被加到一个区块之前等待最小的时间间隙。这个时间间隙由操作敏感性决定。具体的延时选择由开发者和用户自己来做选择。这就是EOS.IO软件的开放性，很多参数的具体值留给开发者和用户自己选择，保证了系统的鲁棒性。

恢复被盗窃的密钥

EOS.IO软件提供给用户一种找回自己失窃密钥控制权的方式。一个账户的所有者可以使用过去30天任何活跃的拥有者密钥与事先指定的合作者账户给出的批准来重复自己账户的密钥。账户的恢复合作者在没有所有人帮助的情况下无法重置账户的控制权。

恢复被盗窃的密钥需要两个条件：

1、过去30天任何活跃的拥有者密钥；

2、事先指定的合作者账户给出的批准。

黑客尝试进行恢复流程是无意义的，因为他们已经“控制”了账户。此外就算他们真的进行这一流程，恢复合作者也会询问身份证明和多因素认证（手机和邮件）。这会让黑客作出让步或者无功而返。

这一流程与简单的多重签名有很大差异。在多重签名中，另一个公司要参与所有转账的执行，但在恢复流程中，它却只有在恢复时才起作用对每天的转账无从干预。这大大的降低了参与者的成本和法律责任。

在数字签名应用中，有时需要多个用户对同一个文件进行签名和认证。比如，一个公司发布的声明中涉及财务部、开发部、销售部、售后服务部等部门，需要的到这些部门签名认可，那么，就需要这些部门对这个声明文件进行签名。能够实现多个用户对同一文件进行签名的数字签名方案称作多重数字签名方案。

多重数字签名保证操作的安全性。但多重签名会影响效率，所以只对核心的、非常重要的操作进行多重数字签名。

总结一下，本文分成了两个部分，共识算法（DPOS）及EOS.IO的账户管理机制。

上一篇文章讨论了共识算法（DPOS）的核心部分。本文继续讨论共识算法（DPOS）剩下两部分：交易确认和股权证明的交易（TaPoS）。交易确认，EOS.IO在确认率和效率之间选取了一个最佳值，即15/21。股权证明通过哈希值实现，防止分叉链上出现大量交易，系统能够感知用户在分叉链上。

另一部分主要讨论的是EOS.IO的账户管理。通过角色、群组、映射提高账户管理效率，通过并行处理提高权限的评估效率；通过带强制性延时的消息，指定确认消息的最短时间。

纵观EOS.IO的这些技术，都是以提高效率和安全为核心目标。

续......