投稿

EOS.IO 技术白皮书 v2

佚名

2018-07-14 16:10:02

EOS.IO 软件采用了一种全新设计的区块链架构，实现了去中心化应用的横向和纵向扩展。具体方法为构建一个类操作系统的架构，开发者可以在其中搭建应用程序。EOS.IO 软件提供跨 CPU 跨集群的账户系统、身份验证、数据库、异步通信，并且支持应用程序间的调度。用以实现上述特性的技术是一种特定的区块链架构，在受管控的区块链环境中，可扩展至每秒处理百万级交易，消除用户手续费，并且允许快速和轻松地部署和维护去中心化应用。

背景

伴随着比特币的诞生，区块链技术在 2008 年问世，从那之后，企业家和开发者不断地试图将区块链技术通用化，以期在单一区块链平台上实现对去中心化应用更广泛的支持。

在众多争相实现支持可实用的去中心化应用的区块链平台当中，一些针对特定应用场景的区块链脱颖而出并被广泛使用，吸引了成千上万的用户。例如去中心化交易所 BitShares（2014）和社交媒体平台 Steem（2016）。类似的项目之所以能被众多用户接纳，是因为他们不仅提高了性能使得每秒可处理的交易量达到数千次，还将确认时间缩短至 1.5s 并且消除了交易费用，同时他们还能提供可与现有的中心化服务相媲美的用户体验。

然而更多现有的区块链平台（的使用）则需要高昂的交易费用，并且计算能力也有限，这些都是阻碍区块链技术被更广泛地接受与使用的因素。

对区块链应用的要求

要实现更广泛的应用，区块链上的应用程序需要一个足够灵活的平台，该平台要满足以下需求：

支持百万级用户

与 Ebay、Uber、AirBnB 和 Facebook 这样的企业竞争，区块链技术要能处理百万级的日活跃用户。在某些场景中，除非用户量达到一个极其庞大的数量级，否则应用并无用武之地。因此，一个可以支持相当庞大的用户量的平台是至关重要的。

免费使用

应用开发者需要足够的灵活性来为用户提供免费的服务，用户不应该因为使用平台或从平台上的服务中获益而支付费用。可免费使用的区块链平台会更受欢迎，开发者和商家也可以从中创造更多有效的盈利策略。

易于升级和 Bug 修复

基于商用区块链之上的应用需要有一定的灵活性来支持新特性的增加，因此平台本身必须支持软件和智能合约的升级。

软件只要达到一定规模，就必定会出现 bug，即便是通过了再严格的验证也不例外。因此平台必须足够鲁棒（Robust）并支持修复不可避免的 bug。

低延时

好的用户体验要求在数秒内就能收到可靠的反馈。高延时不仅会让用户心烦，还会导致建立在区块链之上的应用竞争力不如现有的中心化应用。因此，平台需要支持低延时交易。

时序性能

由于执行步骤的顺序依赖关系，一些应用不能使用并发算法来实现。例如，交易所就需要足够的时序性能来处理高交易量。因此，平台需要具备高时序性能。

并发性能

大规模的应用需要将工作量分配到多台 CPU 和计算机之上，因此，平台需要内建对并发的支持。

共识算法（BFT-DPOS）

EOS.IO 软件采用授权委托证明（DPOS）的算法，在目前已知的去中心化共识算法中，只有该算法经证明可以满足区块链上应用程序的性能要求。根据这种算法， EOS 区块链上所有代币持有者可以都通过一个持续的投票系统选择区块生产者。想参与区块生产，只要能说服代币持有人给自己投票，最终（得票最高的那些节点）被选为区块生产者。

EOS.IO 软件能够精确地每 0.5 秒产生一个区块，并且在任一时间仅有一个生产者获权生产区块。如果在预定时间内没有区块生成，则跳过该块。相应的，当跳过一个或多个块时，区块链中会存在一个大于等于 0.5 秒的时间间隔。

使用 EOS.IO 软件，每一轮产生 126 个区块（共 21 个区块生产者，每一轮都有一个特定的生产者负责产生 6 个块，即一轮的时间为 63 秒）。在每轮开始时，根据代币持有者的投票选出 21 个不同的区块生产者。获选的生产者的生产顺序由 15 个或更多生产者一致同意决定。

如果一个生产者错过了一个块，并且在过去 24 小时均未产生任何块，则会被从生产者的名单中剔除，直至他通知区块链表明他打算再次开始生产区块。这种方式可以排除不可靠的生产者来最小化错过的区块数量，从而确保网络的顺畅运行。

正常情况下， DPOS 区块链不会产生任何分叉，因为生产者生产区块的方式是合作而非竞争。如果出现分叉，那么共识的处理方式是自动切换到最长的链上。其工作原理是，一个区块链的分叉上新区块的添加速度与在这个分叉上达成共识的生产者的多寡直接相关。换言之，生产者数量多的分叉，其增长速度要比生产者较少的分叉的增长速度更快，这是因为生产者数量多的分叉错过的区块数往往会更少。

此外，任何区块生产者都不应该在同一时刻在两个分叉上竞争出块。如果有块生产者被发现这么做，可能会被投票出局。这种双重生产会留下密码学证据，因此识别并自动清除这类区块生产者是可行的。

添加了拜占庭容错机制的 DPOS 算法需要所有生产者签名所有区块，但禁止同一个生产者签名两个时间戳或高度相同的区块。一个区块一旦被 15 个生产者签名，那么这个区块就可以被视为不可逆了。任何生产者一旦签名两个相同时间戳或相同区块高度的区块，这种不诚信行为就会留下密码学证据。在这一模型下，不可逆的共识将在 1 秒内达成。

交易确认

典型的基于 DPOS 共识算法的区块链中，区块生产者会有 100％的参与度。一笔交易在广播后的平均 0.25 秒之后，就可以 99.9% 确定这笔交易不可逆了。

而 EOS.IO 软件除了 DPOS 共识算法，还引入了了异步拜占庭容错(aBFT)，可让交易的更快达到不可逆转状态，可在 1 秒内 100% 确定交易达到了不可逆状态。

交易作为权益证明（TaPoS）

EOS.IO软件要求每一笔交易必须包括最近的一个区块头的部分哈希值。这个哈希值有两个目的：

1.防止一个交易在另一个未包含该交易的分叉上被重新广播。

2.通知整个网络，某个特定用户和他的权益存在于某个特定的分叉上。

如此一来，伪造假冒链将变得非常困难，因为伪造者无法将合法链中的交易迁移到假冒链上。

账户系统

EOS.IO 软件规定所有的账户都由一个唯一名称来标识，名称的最大长度为 12 个字符。该名称由帐户的创建者指定。帐户创建者必须使用 EOS 代币预留 RAM 用来存储新帐户，直至新帐户质押自己的代币来预留自己的 RAM。

在去中心化的背景下，应用程序开发人员在新用户注册时，会象征性地支付账户创建费用。传统企业为获取客户，已经以广告、免费服务等形式为每个用户花费了大量资金。相比之下，创建新的区块链账户所需的资金成本微不足道。不过好在如果用户在注册另一个应用程序时已经创建了帐户，那就没有必要再次创建了。

操作（Actions）和处理程序

每个帐户可以发送结构化的操作（Actions）到其他帐户，并且可以定义程序代码来处理收到后的操作。EOS.IO软件为每个帐户提供自己的私有数据库，只能由该账户的操作处理程序（Action Handler）访问。操作处理程序还可以发送操作到其他账户。操作和自动化的操作处理程序的结合合是EOS.IO定义智能合约的方式。

为支持并发执行操作，每个账户可以在其数据库内定义任意多个作用域。区块生产者通过这种方式安排事务，使得事务执行时对作用域的内存访问没有冲突，因此事务可以并发执行。

基于角色的权限管理

权限管理包括确认某项操作是否被正确授权。最简单的权限管理是检查交易是否具有所需的签名，这也意味着所需的签名是已知的。一般而言，授权涉及个人或群体，并且往往是分类的。EOS.IO 软件提供了一个声明式权限管理系统，可以对帐户进行细粒度、高级别的控制，以确定谁在何时可以做什么。

身份验证和权限管理必须标准化，并与应用程序的业务逻辑分开，这是至关重要的。这样使得开发工具能够以通用方式管理权限，并为优化性能提供巨大空间。

每个帐户都可以通过其他帐户和私钥的组合来控制。这就创建了一个分层的权限结构，真实反映了现实中权限的组织方式，并使得多用户的账户控制比以往更容易。多用户控制对提升安全性的作用是最大的。如果使用得当，会极大降低黑客攻击而造成的盗窃风险。

EOS.IO 软件允许帐户定义什么样的账户和密钥的组合可以把特定的操作发送到另一个账户。例如，可以使用一个密钥访问用户的社交媒体帐户，另一个密钥用于访问交易所。甚至可以授权其他帐户来代表本账户进行操作，而无需为其他账户分配密钥。

命名的权限级别

帐户通过使用 EOS.IO 软件，可以定义命名的权限的级别，每个权限级别可以从更高级别的命名权限中派生。每个命名权限级别定义一个权限。权限是一个多签名的阈值检查，由其他帐户的密钥和/或命名权限级别组成。例如，可以为一个帐户的某个操作设置"朋友"权限级别，该帐户的朋友对该操作具有相同等级的控制权限。

另一个例子是 Steem 区域链，它具有三个硬编码的命名的权限级别：owner， active和posting。posting 权限只能执行诸如投票和发布等社交操作，而 active 权限可以执行除更改所有者的所有操作。owner 权限应该被冷存储起来，它可以执行一切操作。EOS.IO 推广了这一理念，允许每个账户所有者自定义权限级别以及操作的分组。

权限映射

EOS.IO 软件允许每个帐户定义从合约/操作或其他账户的合约到其自己的命名的权限级别之间的映射。例如，账户持有人可将其社交媒体应用程序映射到账户所有者的"朋友"权限组。通过此映射，该账户的任何朋友都可以作为账户所有者在社交媒体发布信息。尽管这些朋友可以作为帐户所有者发布信息，但他们仍然会使用自己的密钥来签名。这就意味着，哪些朋友以何种方式使用了该帐户，始终是可以确定的。

权限映射

权限评估

当从账户 @alice 发送类型为" Action " 的操作到 @bob 时，EOS.IO 软件将首先检查 @alice 是否为 @bob.groupa.subgroup.Action 定义了权限映射。如果没有发现任何结果，那么将会检查 @bob.groupa.subgroup，然后检查 @bob.groupa，最后检查 @bob。如果没有找到进一步的匹配，则假定映射的命名权限组是 @alice.active。

一旦确定了映射的命名权限，则使用多签名阈值来验证签名，并获取命名权限相关联的权限。如果失败，那么它会遍历父类权限，最后遍历 owner 的权限，即@alice.owner。

默认权限组

EOS.IO 软件给所有账户指定了两个默认权限组。一个是"owner"权限组,可以执行任何操作。还有一个“active”权限组，除了更改“owner” 权限组之外，可以执行所有操作。所有其他权限组均由“active”组派生。

并发评估权限

权限评估过程是"只读"的，并且，对权限的更新交易直到被打包进区块后才会生效。这意味着一切交易的所有密钥和权限评估都可以并发执行。此外，这还说明快速权限验证是可行的，而且不需要启动昂贵的应用程序逻辑（并且在验证失败时会回滚应用逻辑）。最后，这意味着交易权限可以在接收到待处理的交易时进行评估，而在待处理的交易被处理时无需重新评估。

从整体来看，权限验证占交易验证中所需计算的很大一部分。让权限验证过程只读，并且可并发执行，可以显著提升性能。

当我们重放区块链的历史，试图从操作日志重新生成确定性状态时，不需要再次评估权限。交易包含在一个已知的不可逆的区块中这一客观事实，足以让其跳过权限评估的不周步骤。这极大减少了重放不断增长的区块链时消耗的计算量。

带强制延迟的操作

时间是关乎安全的关键因素。通常情况下，只有在私钥被盗窃者使用了之后，私钥的所有者才能知道它被盗了。当人们的应用软件需要在连网的计算机上保存密钥以供日常使用时，基于时间的安全性就显得更为重要了。EOS.IO 软件使得开发者可以指定某些操作 (Actions) 在记录到一个区块后必须至少等待一小段时间后才被应用。在此期间，操作可以取消。

当一个操作广播后，用户可以通过电子邮件或短信来接收其通知。如果他们没有给这个操作授权，那就可以使用账户恢复流程来恢复账户并撤销操作。

上述所需的操作确认延迟取决于操作的敏感程度。支付咖啡钱时可以没有任何延迟，在几秒钟内就达到不可逆，而购房时可能就需要 72 小时的结算期。转让整个帐户到新的控制权可能需要长达30天的时间。确切的延迟时间是由应用开发者和用户共同决定的。

密钥被盗后的恢复

EOS.IO 软件为用户提供了一种在密钥被盗后恢复帐户控制权的方法。帐户所有者 (owner) 可以通过过去 30 天内处于活跃状态的任何 owner 密钥，以及来自其指定的帐户恢复合作伙伴的批准来重置其帐户的 owner 密钥。没有帐户所有者的帮助，帐户恢复合作伙伴无法单独重置帐户的控制权。

黑客尝试完成恢复流程是没有意义的，因为他们已经"控制"了帐户。此外，如果他们万一真要走这个流程，恢复伙伴也会要求身份识别和多重认证（电话和电子邮件）。这会让黑客的身份受到怀疑，或让他在该流程中一无所获。

该流程与简单的多重签名协议很不一样。多重签名交易中，另一方会成为每笔交易的参与者。相比之下，在恢复流程中，合作伙伴只是参与了恢复流程，无权干预日常交易。这大大降低了所有相关人员的操作成本和法律责任。

应用的确定性并行执行

区块链共识取决于确定性 (可重复) 行为，这意味着所有并行执行必须避免使用互斥锁或者其他锁原语。如果没有锁，那么必须要有方法来保证可能被并行执行的交易不会产生非确定性结果。

EOS.IO 软件在 2018 年 6 月的发行版将会是单线程的，但是它会包含将来多线程、并行执行所需的数据结构。

在基于 EOS.IO 软件的区块链中，一旦启用并行操作，区块生产者的工作就是将操作 (Action) 投递到独立的分片 (shard) 中，以便可以进行并行评估。区块生产者的产出是将被确定性地执行的计划表，但是生成计划表的过程不需要是确定性的。这意味着区块生产者可以利用并行算法来调度交易。

部分的并行执行是说，当一个脚本生成一个新的操作时，它可能不会被立即投递，而是被安排在下一个循环中投递。无法立即分配的原因是接收者可能正在活跃地修改自己在其他分片中的状态。

最小化通信延迟

延迟时间是指一个帐户向另一个帐户发送操作并接收响应所需的时间。我们的目标是使两个账户能够在一个区块内来回交换操作，而不必为每次操作都等待 0.5 秒。为了实现这一点，EOS.IO 软件将每个区块分成多个循环 (Cycle)，每个循环又被分成多个分片，每个分片包含一组交易。每笔交易都包含一组要投递的操作。这个结构可以被可视化为一棵树，其中不同层交替地按顺序及并行地处理。

区块区域循环 (顺序) 分片 (并行) 交易 (顺序) 操作 (顺序) 接收者和被通知账户 (并行)

在一个循环内生成的交易可以在任意后续的循环或区块中被投递。区块生产者会持续给区块增加循环，直到超过最大运行时间，或者没有新生成的交易要投递。

对一个区块使用静态分析来验证给定循环内没有两个分片包含修改同一帐户的交易，这种方式是可行的。只要这一点是确定的，那么一个区块就可以通过并行运行所有的分片的方式进行处理。

只读的操作处理程序

有些帐户可能可以用"通过/未通过”的方式来处理操作，而不必修改其内部状态。如果是这种情况，只要对于特定的账户只有只读的操作处理程序被包含在某一循环内的一个或多个分片中，那么这些处理程序可以被并行执行。

多帐户的原子交易

有时候我们希望保证操作投递给多个账户并被接收是原子的。在这种情况下，两个操作会被放置在同一笔交易里，这两个帐户还会被分配到相同的分片里并按顺序处理操作。

区块链状态的部分评估

区块链扩容技术要求组件是模块化的。任何人都不应该处理所有事情，特别是在他们只需要使用一小部分链上数据的情况下。

交易所应用的开发者会运行全节点以便给用户显示交易状态。这个交易所应用不需要其他社交媒体应用相关的状态。EOS.IO 软件允许任意全节点选择要运行的任意应用的子集。如果你的应用不依赖于其他合约的状态，那么你可以安全地忽略投递给其他应用的操作。

自主最优调度

EOS.IO 软件不能强迫区块生产者投递任何操作给任何其他帐户。每个区块生产者都需要对处理交易所需的计算复杂度和时间做出主观测量。无论是用户生成的还是智能合约自动生成的交易，这一点都适用。

在一个基于 EOS.IO 软件的区块链里，在网络层面上，所有交易会根据执行的 WASM 指令数来计算带宽成本。但是使用 EOS.IO 软件的每个区块生产者都可能会使用自己的算法和标准来计算资源的使用情况。当区块生产者判定某个交易或账户会消耗过多的计算能力时，在生产自己的区块时他们会直接拒绝这个交易；但是如果其他区块生产者都认为这个交易有效，他们还是会处理该交易。

一般而言，只要有 1 个区块生产者认为某个交易有效且在资源使用限制内，那么其他所有区块生产者也会接受这个交易；但是这个交易可能需要多达 1 分钟才能找到生产者。

在某些情况下，生产者创建的区块可能包含可接受范围之外的数量级的交易。遇到这种情况，下一个区块生产者可以选择拒绝该区块，这个僵局将会被第三个生产者打破。这和过大区块导致网络传播延迟没什么区别。EOS.IO 社区会注意到这种滥用模式，并最终移除恶意生产者的投票。

这种对计算成本的主观评估使得区块链不必精确和确定地测量交易需要运行多长时间。有了这个设计就没必要精确地计算指令数，这可以在不违反共识的情况下显著增加优化性能的机会。

延迟交易

EOS.IO 软件支持延迟交易，这是一种被调度到将来执行的交易。这使得计算能够被分配到不同的分片中，并且能够创建持续调度执行连续交易并长时间运行的进程。

上下文无关的操作

上下文无关的操作是指包含仅依赖交易数据，而不依赖区块链状态的计算。比如说，签名验证这种计算，只需要交易数据和签名以确定签署交易公钥。在区块链必须执行的单个计算中，这是最昂贵的一种，然而由于这种计算是上下文无关的，所以它可以被并行执行。

上下文无关的操作和用户的其他操作类似，只是它们无需访问区块链状态来执行验证。这不仅使得 EOS.IO 软件能够并行地处理所有上下文无关的操作，比如签名验证；更重要的是，还可以实现通用签名验证。

通过支持上下文无关的操作，Sharding，Raiden，Plasma，State Channels 等扩容技术变得更加可并行和实用。这项技术的开发可以实现高效的区块链间通信和潜在的无限可扩展性。

治理（Governance）

治理是指人们在社区中的一系列管理流程，借此人们可以：

就那些软件算法无法完全捕获的集体行动的主观问题达成共识
执行他们做好的决定
通过章程修正案来修改治理规则

基于 EOS.IO 程序的区块链实现的治理过程，可以有效指导区块生产者的现有影响。先前的区块链由于缺少明确的治理过程，而依赖于临时的、不正式的治理过程，常引起争议，最终导致结果不可预测。

基于 EOS.IO 程序的区块链所认可的是权利来源于将那些权利委托给区块生产者的代币持有者。区块生产者被赋予了受限且经过验证的权限，他们可以利用这些权限，完成账户冻结，更新有缺陷的程序，或者提议对基本协议的硬分叉更改。

区块生产者选举是集成于 EOS.IO 程序之中的。在对区块链做任何更改之前，这些改动都必须经过这些区块生产者的批准。如果块生产者拒绝执行代币持有者所希望的改变，那么块生产者可能会被投票出局。如果区块生产者在未经代币持有者允许的情况下做了更改，那么所有的其他非生产性全节点验证器（交易所等）则能够拒绝掉这些更改。

冻结账户

有时，智能合约的行为会发生异常或者变得不可预测，不再按预期执行；或有时，应用程序或账户会发现某个行为会导致其过度消耗资源，当这些问题不可避免地发生时，区块生产者有权去纠正这些问题。

区块链上的所有区块生产者都有权去确定哪些交易会被包含进块中，这使得他们有能力冻结账户。只要 EOS.IO 软件中 21 个活跃生产者中的 15 个投票达成一致，即可授权冻结账户。如果生产者滥用该权力，那么他们则会被投票出局，被冻结的账户也将得以解冻。

更改账户代码

当所有其他办法都失效且有一个"无法停止的程序"以不可预知的方式在运行时，使用 EOS.IO 软件允许区块生产者在不使用硬分叉的情况下替换这些账户的代码。这种替换代码的的请求类似于冻结账户的过程，需要至少 15 个区块生产者投票通过。

章程（Constitution）

EOS.IO 程序允许区块链建立点对点的服务条款，或是在签署该协议的用户之间绑定合约，我们称之为"章程"。该章程规定，用户之间不能完全由代码来规定执行的义务，而是应该通过建立管辖权和法律法规以及其他相互接受的规则来帮助解决出现的争议。网络上每笔交易的广播都必须包含章程的哈希来作为签名的一部分，从而明确地将签署人绑定到合约中。

该章程还规定应考虑源代码协议的可读性。该功能用于明确区分漏洞和功能，同时引导社区界定哪些修复是合适的，哪些是不合适的。

升级协议和章程

协议的正规源代码以及章程规定，协议可以进行更新。EOS.IO 程序规定更新过程如下：

区块生产者提议对章程作出修改，并获取到 15/21 的认可。
区块生产者在连续的 30 天保持并拥有对新章程的 15/21 的认可。
所有用户都必须表明接受新章程，并以此作为对未来交易处理的条件。
区块生产者根据章程所发生的变化对源代码进行修改，并使用新章程的哈希将其提交至区块链。
区块生产者在连续的 30 天保持并拥有对新代码的 15/21 的认可。
对代码所做的更改在 7 天后生效，当源代码得到正式批准后，给予所有非生产完整节点 1 周的时间进行升级。
所有未升级到新代码的节点会自动关闭。

默认情况下，针对 EOS.IO 程序所做的配置，以及通过更新区块链来添加新功能的过程需要 2 到 3 个月的时间，而针对不需要对章程做更改的非关键性漏洞的修复更新可能需要 1 到 2 个月的时间。

紧急变更

如果软件出现了会对用户产生影响的漏洞或是安全问题，急需作出修复，则区块生产者可能会因此加快此过程。但是需要加速升级的方式，来引入新功能或者修复无害漏洞可能会与章程的规定相违背。

脚本和虚拟机

EOS.IO 软件将会是账户间传递可信消息（称之为"操作"）的最重要的平台。脚本语言和虚拟机属于具体实现，与 EOS.IO 的技术设计几乎是相互独立的。任何确定性的语言或者虚拟机，只要性能足够好，并支持沙盒运行机制，都可以和 EOS.IO 的 API 整合起来。

范式定义的操作（Actions）

任何账户间的操作都满足一定的范式，该范式也是区块链共识状态的组成部分。这一范式支持二进制格式和 JSON 格式间的无缝转换。

范式定义的数据库

数据库状态也由类似的范式定义。这一范式使得所有应用储存的数据都遵循特定的格式，既能转换为可读性很强的 JSON 格式，又能以高效的二进制格式存储与操作。

通用多索引数据库 API

开发智能合约需要一个事先定义好的数据库来追踪、存储和查询数据。开发者们普遍需要支持数据排序或多字段索引的数据库，来保证数据的一致性。

将认证从从应用中抽离

为了最大化并行运算能力和最小化算力债（计算应用状态需要在交易日志中从头运算），EOS.IO 软件将验证逻辑分成了三部分：

验证一个操作在内部是一致的。
验证所有的前置条件是有效的。
修改应用状态。

验证操作的内部一致性是只读操作，且不需要区块链状态信息。这意味着这一操作可以最大程度地并行进行。验证前置条件的有效性（比如必要的余额）也是只读操作，因此也可以利用并行机制。只有修改应用状态这一步需要写操作，并且对每个应用必须严格按照顺序执行。

认证是用来验证操作是否可以被执行的一个只读过程。而（操作涉及的）真正的业务则是应用程序来完成的。当一个操作发生的时候，这两部分工作都需要实时计算。好消息是，一旦（包含该操作的）交易被打包进了区块链，认证操作也就不再需要重复进行了。

跨链通信

EOS.IO 的设计能促进跨链通信，实现方式是简化生成操作存在证明和顺序证明。这些证明和围绕操作传递设计的应用架构一起，使得跨链通信的细节和验证工作对应用开发者不可见，开发者看到的只是更高层次的抽象。

用于轻客户端验证的默克尔证明

如果客户端不需要处理全部交易的话，和其他区块链的结合将变得非常容易。毕竟类似交易所这样的客户端，它只关心资产的转入和转出。理想情况下，交易所的链可以用转账交易的轻量默克尔证明（来完成交易所业务），而不是完全信任某个区块生产者。每条链的区块生产者都希望和其他链同步的开销尽可能地小。

轻量客户端验证（LCV）的目标是生成相对轻量的存在证明，这些证明可以被任何关心一个轻量的数据集的客户端用来验证。在上述例子中，LCV 的目的就是为了用来证明某笔交易已经被包含进某一特定区块，而这一区块已经被某条特定的链所收录。

比特币支持交易验证的功能，这一功能基于一个假设，那就是所有的节点都可以访问到全部的区块头历史数据（区块头数据每年增加 4MB）。在每秒 10 笔交易的吞吐下，一个验证用到的存储空间约为 512 个字节。对于 10 分钟一个区块的比特币来说，这是可行的。但对于拥有 0.5 秒的出块速度的 EOS.IO 软件来说，这个机制显然不够轻量。

任何有不可逆区块头数据的用户在交易被区块记录后，都可以使用 EOS.IO 提供的轻量证明。轻量证明的哈希连接（hash-linked）结构表明，最多只要 1024 个字节，即可验证任何一笔交易的存在与否。

考虑到区块链中的区块的 id 和区块头都是可信的且不可逆的，因此证明某个区块被包含在某个区块链中也是可行的。这类证明最多只需 ceil(log2(N)) 次摘要计算即可完成，其中 N 为区块链中的区块个数。就 SHA256 这种摘要算法来说，你只需要 864 个字节就可以在一个有着 1 亿个区块的链上验证某个区块的存在。

使用合适的哈希连接（hash-linking）机制生产区块以启用上述证明，几乎不会带来什么额外开销，所以这种方式十分可行。

若要在其他链上验证证明，时间、空间和带宽上都有很多优化空间。追踪全部的区块头（每年 420MB 递增）可以将证明维持在比较小的空间占用。仅追踪最近的区块头会在最小长期存储和证明大小之间实现平衡。另外也可以采用惰性求值的方式，记录过去的证明的中间哈希值。新证明只需要包含已知的稀疏树的连接。具体选取何种方式，取决于默克尔证明引用的带有交易的外部区块的比例。

当互联和耦合程度达到一定的复杂度之后，将两条链的数据合并将更简单高效，如此一来也就不再需要默克尔证明了。因为性能的原因，跨链证明的频度当然是越小越好。

跨链通信的延迟

当和外部区块链进行通信的时候，区块生产者必须要 100% 确认一笔交易已经被不可逆转地写入到外部区块链之后，才可以将其当作合法输入。EOS.IO 的区块链加上 DPOS 算法 0.5 秒的出块速度，结合拜占庭容错机制，使得等待上述确认的时间大约为 0.5 秒。任何区块生产者若违背上述原则，不等待确认即开始下一步操作，例如交易所在未确认的情况下就将资产冲入用户账户，随后又将资产取消的行为，都将影响区块链的共识机制。EOS.IO 软件使用 DPOS 算法结合拜占庭容错机制快速实现交易的不可逆性。

完整性证明

当外部的区块链使用默克尔证明的时候，去知晓处理的全部交易全部有效，迥异于去知晓没有交易被跳过或省略。因为想要证明"最近全部的交易都已经被知晓"是不可行的，而证明“交易历史记录里没有被跳过的交易”则很容易。EOS.IO 软件通过给发送到每个账户的每个操作一个顺序编号来实现这一点。用户可以使用这些顺序编号来验证某个特定账户的所有操作都已经被处理，并且是严格按照顺序来处理的。

隔离见证（SegWit）

隔离见证（SegWit）是指一笔交易被打包进不可变更的区块链之后，这笔交易的签名就与交易无关了。一旦交易变为不可变更状态，签名数据就可以被舍弃，其他人仍然能获得区块链当前状态。考虑到签名数据容量占据了多数交易的很大部分，隔离见证将能大幅缩减磁盘占用和数据同步时间。

隔离见证的概念对用于跨链通信的默克尔证明同样适用。一旦一个证明被接受并被不可逆地记录进区块链，那么这个证明用到的 2KB 大小的 sha256 哈希值就可以在不影响区块链状态的前提下被舍弃。值得一提的是，将隔离见证用于跨链通信节省的存储空间的是常规签名场景下的 32 倍。

隔离见证应用的另一个场景则是用于（存储） Steem 的博客文章。利用隔离见证，存储在区块链上的将只是一篇篇博客内容的 sha256 哈希值，真正的内容则存储于隔离见证数据中。区块生产者只需要依靠内容的哈希值就可以验证文章的存在。要从交易日志中恢复区块链当前状态，生产者无需存储全部的内容。这样一来，以下的证明方式变得可行：内容只要曾经有人看过即可，无需永久储存。

结束语

EOS.IO 软件的设计理念来源于已被证实的概念和最佳实践，代表了区块链技术的重大进步。作为未来全球范围区块链社会的宏伟蓝图的组成部分，EOS.IO 使得去中心化应用（dApp）的开发、部署和管理变得更加容易。

请注意：本白皮书中提及的加密代币，是指采用 EOS.IO 软件所发布的区块链上的加密代币，而非在以太坊区块链上分发的与 EOS 代币发放相关的 ERC-20 兼容代币。

免责声明：本 EOS.IO 技术白皮书 2.0 版本仅作信息提供之用。block.one 不保证白皮书中内容或结论的准确性，仅供参考。block.one 不会作出、并且明确否认所有明示的或隐含的、法定的或其他形式的声明和保证条款，包括但不限于：（i）适销性、针对特定用途的适用性、适宜性、用途、所有权和非侵权的保证；（ii）本白皮书中的内容不存在错误的保证；（iii）本白皮书内容不会侵害第三方权利的保证。block.one 及其分公司不承担因对本白皮书及本声明中所含内容的使用、参考或信任而造成的任何损失，即便已告诫过可能造成的损害。任何个人或实体由于对本白皮书及本声明所包含内容的使用、参考、或信任而造成的各种形式的任何损害、损失、负债、成本或花费，不论是直接的、间接的、作为结果的、赔偿的、偶发的、实际的、惩戒的、惩罚的，或是特殊性的，包括但不限于任何业务、收入、利润、数据、效用、商誉或其他无形损失，block.one 或其分公司在任何情况下均不为此承担责任。

本文档由汪涛，minghua，鞠禹，李晓宇，轻灵紫，陈伟桢，赵余，以及另外两位不具名人士共同翻译，终稿由汪帆审校，感谢各位。