作者：MEET.ONE 团队 支持我们，请投票给 rex.m
注：根据EOS2.0版白皮书英文翻译，如与英文版表述不一致，以英文为准。
摘要：
EOS.IO软件引入了一种新的区块链架构，意在实现去中心化应用的性能扩展。通过创建类似操作系统的结构，在此基础上可构建各种应用程序。 该软件提供帐户、身份验证、数据库、异步通信以及在数以百计的CPU或群集上的程序调度。该技术的最终形式是形成一个区块链架构体系，能支持每秒数百万次交易、免除用户费用，并允许在受控区块链的背景下，迅速、便捷地发布去中心化应用程序。
注意： 本白皮书中所提到加密令牌是指在EOS.IO 软件中EOS 令牌，而不是以太坊中的EOS 令牌。
英文版权所有© 2018 block.one
未经许可，任何人都可以使用，复制或分发本白皮书中的任何非商业和教育用途的材料（即除费用或商业用途外），前提是原始来源和适用的版权声明被引用。
免责声明： 此EOS.IO技术白皮书仅供参考。block.one不保证本白皮书的准确性或结论，本白皮书按“原样”提供。block.one不会以明示，暗示，法定或其他方式，作出明确的声明和保证，内容包括但不限于：
(i) 适销性，适用于特定用途，适用性，使用，标题或不侵权;
(ii) 本白皮书的内容没有错误;
(iii) 此类内容不会侵犯第三方权利。
block.one及其分公司对因使用，参考或依赖本白皮书或本文所含任何内容而导致的任何损害赔偿责任概不负责，即使被告知有可能发生此类损失。在任何情况下，由于使用，参考或依赖本白皮书或其所含内容而造成的无论是直接的，间接的，从属的，赔偿的，附带的，实际的，惩罚的或特殊的损害，损失，责任，任何成本或支出，block.one 及其分公司不会对任何个人或实体负责，包括但不限于业绩，收入，利润，数据，使用权，信誉损失或其他无形损失。
2.1 支持数百万用户
2.2 免费使用
2.3 轻松升级和漏洞修复
2.4 低延迟
2.5 顺序性能
2.6 并发性能
3.1 交易确认
3.2 交易证明（TaPoS）
4.1 操作和处理程序
4.2 基于角色的权限管理
4.3 强制延迟的操作
5.1 最小化通信延迟
5.2 只读消息处理
5.3 多账户原子交易
5.4 部分评估区块链状态
5.5 主观最优任务安排
5.6 延期交易
5.7 上下文无关操作
6.1 客观和主观测量
6.2 收款人支付
6.3 委派能力
6.4 将交易成本与令牌价值分开
6.5 状态存储成本
6.6 块奖励
6.7 工作者建议系统
7.1 冻结帐户
7.2 更改账户代码
7.3 宪法
7.4 升级议定书和宪法
8.1 明确的指令架构
8.2 定义数据库的架构
8.3 通用多索引数据库API
8.4 身份验证与应用程序分开
9.1 轻客户验证（LCV）Merkle证明
9.2 链间通信延迟
9.3 完整性证明
9.4 隔离见证
随着比特币的发行，区块链技术于2008年应运而生。自那时起，企业家和开发人员一直在努力推广该技术，以便在单个区块链平台上支持更广泛的应用。
虽然若干区块链平台一直在努力支持去中心化功能的应用，但诸如BitShares（去中心化交易所，2014）和Steem（社交媒体平台，2016）等已经成为成千上万日活跃用户大量使用的区块链。这一成就的实现，源于将交易处理能力提高至每秒数千笔，从而将延时降低到1.5秒，取消每笔交易费用，并提供与现有中心化服务提供的相似用户体验。
现有的区块链平台受累于高昂的费用，有限的计算能力，难以被广泛采用。
为了获得广泛的使用，应用程序需要一个足够灵活的区块链平台来满足以下需求：
2.1 支持数百万用户
某区块链应用程序若要同Ebay，Uber，AirBnB和Facebook等企业竞争，则其使用的区块链技术需能处理数千万日活用户所产生的数据。在某些情况下，若无法达到足够的临界用户量，应用程序可能无法正常工作，因此可被大量用户使用至关重要。
2.2 免费使用
应用开发人员需要灵活地为用户提供免费服务；用户不需要为使用该平台或从其服务中获益而支付费用。区块链平台只有支持用户免费使用，才可能获得更广泛的发展空间。基于此项前提，开发者和企业创建有效的盈利模式。
2.3 轻松升级和漏洞修复
基于区块链应用的企业需要灵活地通过新功能来增强应用程序。 该平台必须能支持软件和智能合约升级。
即使经过最严格的形式验证，软件依然有可能发生错误。因此平台必须足够强大，以便在发生不可避免性的错误时及时修复。
2.4 低延迟
良好的用户体验要求不超过几秒钟的可靠反馈。过长的延迟会影响用户体验，并使构建在区块链上的应用程序无法与现有的非区块链替代品匹敌。 因此平台必须能支持事务低延迟性。
2.5 顺序性能
有些应用程序的命令执行必须有先后顺序，无法用并行算法来实现。诸如交易所之类的应用，需要足够的顺序性能来处理大量数据。因此需要能够执行高速顺序性能的平台。
2.6 并发性能
大规模应用程序需要在多个CPU和计算机之间划分工作负载。
EOS.IO软件采用目前为止唯一能够符合上述性能要求的去中心化共识算法，即授权委托证明（DPOS）。根据这种算法， EOS区块链上持有令牌的人可以通过投票系统持续选择区块生产者，任何人都可以成为块生产，只要他能说服令牌持有人以获得足够投票。
EOS.IO软件能够精确到每0.5秒生产一个区块，并且仅一个生产者被授权能在给定的时间点生产该区块。如果在预定时间内没有生成，则跳过该时隙的块。当跳过一个或多个块时，区块链中会存在0.5秒或者大于0.5秒的间隔。
使用EOS.IO软件，以126轮进行生产（共21个生产者，每个生产者生产6个块）。在每轮开始时，根据令牌持有者的投票选出21个不同的块生产者。获选生产者的生产顺序由15个及以上的生产者约定的顺序安排。
如果生产者错过了一个块，并且在过去24小时均未生产任何块，则会被删除，直至其向区块链通知打算再次生产块。通过排除不可靠的生产者，使得遗漏的区块数量实现最小化，确保网络的顺畅运行。
理论上， DPOS区块链不会经历任何分叉，因为其区块生产过程中，生产者是合作而不是竞争关系。如果有分叉，共识将自动切换到最长的链上。其工作原理是，共识机制下，将新区块添加到分叉区块链中的速度是与分叉链中的生产者的占比直接相关的。换言之，拥有较多生产者的区块链分叉会比生产者少的链增长速度要快得多，因为生产者占比越高的分叉链丢失的区块会更少。
此外，任何块生产者都不应该同时在两个分叉上生产块。如果有块生产者被发现这么做，可能会被投票出局。这种双重生产留下的密码证据也可用于自动清除滥用者。
通过允许所有生产者签署所有区块，拜占庭容错机制被添加到传统的DPOS中，只要没有生产者签署具有相同时间戳或相同区块高度的两个区块。一旦15个生产者签署了一个区块，则这个块被视为不可逆转的。 如果拜占庭式的生产者签署了两个相同时间戳或相同区块高度的区块，那么系统会生成其不忠行为的密码证据。在这一模式下，不可逆的共识应在1秒内可达成。
3.1 交易确认
标准的DPOS区块链中，区块生产者将100％参与度。在广播后平均0.25秒，交易可认定为99.9％确定。
在DPOS基础上，EOS.IO中加入了异步拜占庭容错(aBFT), 可实现更快的不可逆性。 aBFT算法在1秒时间内达到不可逆性的100％确认。
3.2 交易证明（TaPoS）
EOS.IO软件要求每一交易必须包括最近的区块头的哈希值。这个哈希值有两个目的：
防止分叉区块链上出现大量重复事务； 使得系统能感知到用户是否在分叉出来的区块链上。
随着时间的推移，所有用户最终直接确认区块链，这使得伪造假冒链变得困难，伪造者无法将合法链中的交易迁移。
EOS.IO软件允许帐户可被长度多达12个字符的唯一可读名称所引用。该名称由帐户的创建者选择。帐户创建者必须保留存储新帐户所需的RAM，直至新帐户存储令牌以保留其自己的RAM。
在去中心化的情况下，应用程序开发人员将支付创建帐户的名义成本，以注册新用户。传统企业为获取每个客户，已经以广告、免费服务等形式花费了大量资金。相比之下，创建新的区块链账户所需的资金成本微不足道。并且幸运的是，没有必要为已经由另一个应用程序注册的用户创建帐户。
4.1 操作和处理程序
每个帐户可以将结构化的操作发送到其他帐户，并且可以定义脚本来处理收到的操作。EOS.IO软件为每个帐户提供自己的专用数据库，只能由自己的操作处理程序访问。操作处理脚本还可以将操作发送到其他账户。消息和自动操作处理程序的组合是EOS.IO定义智能合同的方式。
为支持并发执行操作，每个账户同样可以在数据库内定义任意数量的范围。区块生产者将以这样一种方式来安排事务，即对存储器访问范围没有冲突, 因此他们可以并发执行。
4.2 基于角色的权限管理
权限管理涉及确认某项操作是否被正确授权。最简单形式的权限管理是检查交易是否具有所需的签名，这也意味着所需的签名为已知。一般而言，授权涉及个人或群体，并且往往是分门别类的。EOS.IO软件提供了一个声明式权限管理系统，可以对帐户进行细粒度、高级别的控制，以确定谁可以做什么和什么时候做什么。
认证和权限管理必须标准化，并与应用程序的业务逻辑分开，这是至关重要的。这使得开发工具能够以通用方式管理权限，并为优化性能提供巨大空间。
每个帐户都可以通过其他帐户和私钥的任何加权组合来控制。这创建了一个分层的权限结构，真实反映了权限的组织方式，并使得多用户对账户的控制比以往更容易。多用户控制是提升安全性的最大贡献者。如果使用得当，会极大降低黑客攻击而造成的盗窃风险。EOS.IO软件允许帐户定义与其他账户和密钥的组合方式，并且把这个组合以特定类型的消息发送到另一个账户。例如，可以为用户的社交媒体帐户提供一个密钥，另一个密钥用于访问交易所。甚至用户可以给其他帐户授权，可以代表本账户进行操作，而无需分配密钥。
4.2.1 命名权限级别
使用EOS.IO软件，帐户可以定义命名的权限级别，每个权限级别可以从更高级别的命名权限中派生。每个命名权限级别定义一个权限。权限是由其他帐户的密钥和/或命名权限级别组成的多签名检查阈值。例如，帐户的“朋友”权限级别可以设置为帐户能被帐户的朋友同等控制。
另一个例子是Steem区域链，它具有三个硬编码命名的权限级别：owner， active和posting。Posting权限只能执行诸如投票和发布等社交行为，而active权限可以执行除更改所有者的所有操作。Owner权限被保留，可以执行一切操作。EOS.IO允许每个账户所有者定义自己的权限级别以及消息的分组，以此来推广这一管理理念。
4.2.2 权限映射
EOS.IO软件允许每个帐户定义任意其他帐户的合同、操作或合同与其自己的命名权限级别之间的映射。例如，账户持有人可将其社交媒体应用程序映射到账户所有者的“朋友”权限组。通过此映射，账户中的任何朋友都可以作为账户所有者，在社交媒体发布信息。即使这些朋友可以作为帐户所有者发布信息，他们仍然会使用自己的密钥来签名。这意味着可以确定哪些朋友，以何种方式使用了该帐户。
4.2.3 权限评估
从@alice到@bob传递类型为“ Action ” 的操作时，EOS.IO软件将首先检查@alice是否为@ bob.groupa.subgroup.Action定义了权限映射。如果没有发现任何结果，那么将会检查@ bob.groupa.subgroup，然后检查@ bob.groupa，最后检查@bob。如果没有找到进一步的匹配，则假定的映射将是命名权限组@alice.active。 一旦识别出映射，则使用多签名阈值和与命名权限相关联的权限来验证签名权限。如果失败，那么它会遍历父类权限，最后遍历所有者的权限，即@alice.owner。
4.2.3.1 默认权限组
EOS.IO技术还允许所有账户拥有一个可以完成所有操作的“owner”权限组，而一个“active”权限组除了更改所有组之外，可以执行所有操作。所有其他权限组均由“active”组派生。
4.2.3.2 并发评估权限
权限评估过程是“只读”的，并且对事务所做的权限更改直到块结束才会生效。这意味着所有交易的所有密钥和权限评估可以并发执行。此外，这意味着可以快速验证权限，而不需要重新启动昂贵的应用程序逻辑。最后，这意味着交易权限可以在接收到待处理的交易时进行评估，而在应用它们时无需重新评估。 从整体来看，权限验证占验证交易所需计算的很大一部分。让权限验证成为一个只读与可并发化的过程可以显著提升性能。当重播区块链以从动作日志重新生成确定性状态时，不需要再次评估权限。因为事务包含在已知的状态良好的区块中，可以让其跳过这一步骤。这极大减少了重放区块链时消耗的计算量。
4.3 强制延迟的操作
时间是安全的关键组成部分。在大多数情况下，不可能知道私钥是否被盗用，直到它被使用。基于时间的安全机制在人们使用某些应用程序时更为重要，因为这些应用程序需要将密钥保存在日常使用的联网计算机上。消息包含在区块后，EOS.IO软件支持应用程序开发人员可以指定某些消息在应用前必须等待一小段时间，在此期间可以取消该操作。
当这类消息被广播时，用户可以通过电子邮件或短信收到相应通知。如果用户没有授权，那么他们可以登录帐户来还原账户数据并撤回消息。
所需的延迟取决于操作的敏感程度。支付一杯咖啡可以毫不拖延地在几秒钟内确认且不可撤回，而买房子可能需要72小时的清算周期。将整个帐户转移到新的用户可能需要30天。具体延迟取决于应用程序开发人员和用户。
4.4 被盗钥匙恢复
EOS.IO软件为用户提供了密钥被盗时恢复其帐户控制的方法。帐户所有者可以使用过去30天内活跃的任何其批准的帐户恢复合作伙伴的密钥，重置帐户上的所有者密钥。没有账户所有者的配合，帐户恢复合作伙伴无法重置帐户的控制权。
对于黑客而言，由于其已经“控制”该账户，因此尝试执行恢复过程没有任何收获。此外，如果黑客执行恢复过程，恢复伙伴可能需要身份认证和多因素认证（电话和电子邮件）。这可能会暴露黑客身份，或者黑客在恢复过程中毫无所得。
这个过程也与简单的多重签名交易有着极大的不同。通过多签名交易，另一个实体会成为每个执行交易的一方。相比之下，通过恢复过程，恢复合作伙伴仅参与恢复过程，无权参与日常交易。这极大降低了所有参与者的成本和法律责任。
区块链共识取决于确定性（可重现）的行为。这意味着所有并发执行都不能使用互斥体或其他锁定基元。如果没有锁定，必须有一些方法来保证并发执行的帐户不会产生非确定性结果。 2018年6月发行的EOS.IO软件为单线程运行，但是它也包含未来需要的多线程并发执行的数据结构。 在基于EOS.IO软件的区块链中，一旦执行并发操作，区块生成器需要将消息传递到独立的线程中，以便进行并发评估，但是生成计划的过程无需确定。这意味着区块生成器可以利用并发算法安排交易。并发执行还意味着脚本生成新消息时，它不会立即发送，而是在下一个周期中发送。无法立即发送的原因是接收方可能会在另一个线程中主动修改自己的状态。
5.1 最小化通信延迟
延迟是指一个帐户将消息发送到另一个帐户并收到响应的时间。EOS.IO的目标是使两个帐户能够在单个区块内来回交换消息，而不必在每个消息之间等待0.5秒。为了实现这一点，EOS.IO软件将每个块分为周期（cycle）。每个周期分为线程（thread），每个线程包含交易列表。每个交易包含一组要传递的消息。该结构可以可视化为树状结构，其中各层按顺序并发处理。 区块
区域
周期（顺序）
线程（并发）
交易（顺序）
消息（顺序）
在一个周期中生成的交易可以在任何后续周期或区块中传送。区块生产者不断把周期添加到区块中，直到达到最长的执行时间，或者没有新生成的事务要交付 可以使用区块的静态分析来证明在给定周期内，两个线程内不包含修改同一个帐户的交易。只要一直保持这种静态分析机制，就可以通过并发运行所有线程来处理区块。
5.2 只读消息处理
某些帐户可能能够以通过/未通过的方式处理操作，而不必修改其内部状态。在这种情况下，只要特定账户的只读消息处理程序包含在特定周期内的一个或多个线程中，这些处理程序就可以并发执行。
5.3 多账户原子交易
有时，最好确保动作被多个账户以原子方式交付和接受。在这种情况下，两个操作都放在同一个交易中，两个账户分配至同一个线程，消息按顺序执行。
5.4 部分评估区块链状态
大规模区块链技术组件应该是模块化的。并不要求每个人都运行所有的东西，特别是当有人只需要使用一小部分应用程序的时候。
交换应用程序开发人员运行完整节点以向其用户显示交换状态。此交换应用程序不需要与社交媒体应用程序相关的状态。EOS.IO允许任何完整节点选择要运行的应用程序的任何子集，传递给其他应用的消息将被安全地忽略，因为应用的状态完全来自于传递给它的消息，而不是依靠其他应用。
5.5 主观最优任务安排
EOS.IO系统不能强制阻止区块生成者向其他账户发送的任何消息。每个区块生成者对处理交易的计算复杂度和时间复杂度都有自己的主观度量，无论该交易是由用户生成的还是由脚本自动生成的。
在推出的采用EOS.IO软件的区块链中，在网络层面，所有交易都根据执行的WASM指令数量计算带宽成本。但是，使用软件的每个区块生成者会使用他们自己的算法和度量来计算资源使用情况。当一个区块生成者发现一个交易或账户已经消耗了不成比例的计算能力时，他们会在生成自己的区块时拒绝该交易;但是，如果其他区块生成者认为其是有效的，他们仍将处理该交易。
一般来说，只要一个区块生成者认为一项交易有效，且其所消耗的资源内可控，那么所有其他区块生产者也将接受它，但交易可能需要1分钟才能找到该生产者。
在某些情况下，区块生成者可以创建一个区块，其中包括超出可接受范围之外几个数量级的交易。在这种情况下，下一个区块生产者可能会选择拒绝该区块，并且会被第三个区块生成者终结。这与一个大区快导致网络传播延迟所引发的情况没有什么不同。社区会注意到这种异常模式，并最终清理该流氓区块生成者的投票。
这种对于计算成本的主观评估使得区块链不必精确地去度量运行某一任务需要多长时间。有了这个设计，就不需要精确地数指令，这将能在不打破共识的情况下大幅增加优化机会。
5.6 延期交易
EOS.IO软件支持计划在未来执行的延期交易。 这使计算能够移动到不同的分片和/或创建持续计划持续交易的长时间运行的流程。
5.7 上下文无关操作
上下文无关操作仅涉及需要用到交易数据的计算，而不涉及区块链状态。例如，签名验证是一种仅需交易数据和签名以确定签署事务的公钥的计算。签名验证在区块链必须执行的计算中，属于最昂贵的单个计算之一，但由于此计算是上下文无关的，因此可并发执行。
上下文无关操作与其他用户操作类似，只是它们无法访问区块链状态来执行验证。这不仅使EOS.IO能够并发处理诸如签名验证等所有上下文无关操作，更重要的是可以实现通用签名验证。
通过支持上下文自由操作，诸如Sharding，Raiden，Plasma，State Channels等的可伸缩性技术变得更加可并发和实用。该种开发实现了高效的区块链间通信和潜在的无限可扩展性。
注意： 本白皮书中所提到加密令牌是指在EOS.IO 软件中EOS 令牌，而不是以太坊中的EOS 令牌。
所有的区块链都是资源受限的，并且需要一个系统来防止滥用。在EOS.IO系统中，有三大类资源被应用程序消耗： 1.带宽和日志存储（磁盘） 2.计算和计算积压（CPU） 3.状态存储器（RAM）
瞬时使用和长期使用这两类组件都会消耗带宽和计算。区块链系统将维护所有消息的日志，这些日志会被所有的完整节点下载和存储。通过日志信息，可以重构所有应用程序的状态。
计算债务是必须执行的计算，以便从操作日志中重新生成状态。如果可计债务增长量过大，那么就有必要对区块链的当前状态进行快照，并放弃区块链的历史状态。如果计算债务增长过快，区块链可能需要6个月的时间来重放1年的交易。因此，谨慎管理计算债务至关重要。
区块链存储状态是可从应用程序逻辑访问的信息。它包括诸如订单和账户余额等信息。如果应用程序从未读取该状态，则不应该存储它。例如，应用程序逻辑不会读取博客文章内容和评论，因此不应将其存储在区块链状态中。同时，发布/评论，投票数量以及其他属性的存在将作为区块链状态的一部分进行存储。
区块生成者可以发布他们可用的带宽、计算资源和状态的容量。EOS.IO系统允许每个账户在一个三天对赌合约中，消耗一定比例的可用容量。例如：假设一个基于EOS.IO系统的区块链应用启动，如果一个账户持有该区块链提供的总令牌的1%，那么这个账户就有可利用该区块链1%的状态存储容量。
在已启动的区块链中使用EOS.IO系统，带宽和计算能力将被分配到部分储备基础中，因为它们是暂时的（未使用的容量不能存储下来为将来使用）。EOS.IO系统将使用类似于Steem的算法来限制带宽使用速率。
6.1 客观和主观测量
如前所述，测量计算使用对性能和优化有重大影响，因此，所有资源使用限制最终是主观的，并且由区块生产者根据他们各自的算法和估算来执行，通常由区块生产者通过写自定义插件来执行。
虽说如此，但有些东西客观地衡量是微不足道的。交付的操作次数以及存储在内部数据库中的数据大小对于客观衡量都很便宜。EOS.IO软件使区块生产者能够在这些客观测量上应用相同的算法，但可以选择对主观度量应用更严格的主观算法。
6.2 收款人支付
传统意义上，支付办公空间，计算能力以及其它运营成本是企业的责任。客户购买了特定产品，这些产品销售收入用于支付业务成本。同样，没有网站强制其访问者在访问其网站时收取小额费用来支付管理成本。因此，去中心化的应用程序不应强迫使用区块链的用户直接支付区块链使用费用。
使用EOS.IO软件的推出区块链不要求其用户直接支付区块链使用费，因此不会限制或阻止企业制定其产品的货币化策略。
尽管接收方可以支付，但EOS.IO使发送方能够支付带宽、计算和存储费用。这使得应用程序开发人员能够选择最适合其应用程序的方法。很多情况下，发件人支付大大降低了不想实施自己的配给系统的应用程序开发人员的复杂性。应用程序开发人员可以将带宽和计算委派给用户，然后让“发件人支付”模型执行使用。从最终用户的角度来看，它是免费的，但从区块链的角度来看，它是发件人支付的。
6.3 委派能力
采用EOS.IO软件区块链上的令牌持有人，可能不需要立即消耗全部或部分可用带宽，可将这些未消耗的带宽委派或租借给其他人; 运行EOS.IO软件的区块生产者将会识别这种容量授权并分配相应带宽。
6.4 将交易成本与令牌价值分开
EOS.IO软件的主要优点之一是可用于应用程序的带宽量完全独立于令牌价格。如果应用程序所有者在使用EOS.IO程序的区块链上持有相应数量的令牌，则该应用程序可在固定状态和带宽的情况下无限期运行。这种情况下，开发商和用户不会受到令牌市场任何价格波动的影响，因此不依赖于价格反馈。换言之，采用EOS.IO软件的区块链生产商能够自然地增加带宽，计算和存储，而不受令牌价值的影响。
使用EOS.IO软件的区块链每次新产生区块时都会授予区块生产者令牌。令牌的价值将影响生产商的带宽、存储和计算量，该模型利用自然上升的令牌价值来提高网络性能。
6.5 状态存储成本
虽然可以委托带宽和计算，但应用程序存储状态需要应用程序开发人员持有令牌，直至该状态被删除。如果该状态从未被删除，那么令牌将从循环中有效移除。
6.6 块奖励
创建的令牌数量由所有块生产者公布的期望收益的平均数决定。 EOS.IO软件可能被设为强制执行生产者奖励的上限，使得令牌供应总量的年增长率不得超过5％。
6.7 工作者建议系统
除了选择区块生产者之外，根据基于EOS.IO软件的区块链，令牌持有者可以选择一些旨在让社区受益的工人建议。获胜的提案将获得高令牌通货膨胀配置百分比的令牌减去已经支付给区块生产者的令牌。这些建议将获得与每个应用程序从令牌持有者收到的投票成比例的令牌，直到他们要求执行其工作的金额为止。当选的提案可以由代币持有人的新当选提案取代。
实施工人建议的系统合同可能在2018年6月初次启动时未到位，但资金机制将会实现。它将开始积累资金，同时开始区块生产者奖励。由于工作人员建议系统将在WASM中实施，因此可以在以后不加分叉的情况下添加。
治理是人们在一个社区的过程：
1.就集体行动的主观问题达成共识，而这些问题不能完全由软件算法俘获;
2.执行他们所做的决定；
3.通过修改法则改变治理宪法本身。
基于EOS.IO软件的区块链实现了一个有效地指导区块生产者现有影响的治理过程。如果缺少明确的治理流程，之前的区块链依赖于特殊的，非正式的且往往颇具争议的治理流程，从而导致不可预测的结果。
基于EOS.IO软件的区块链认识到权力来源于令牌持有者将权力委托给区块生产者。块生产者被给予有限的检查权限来冻结帐户，更新有缺陷的应用程序，并且提出对底层协议的硬分叉改变。
嵌入到EOS.IO软件中是选择区块生产者。在对区块链进行任何更改之前，这些区块生产者必须批准该区块链。如果区块生产者拒绝代币持有者所希望的改变，那么他们可以被投票出去。如果区块生产者没有代币持有者的许可进行更改，则所有其他非生产性全节点验证器（交换等）将拒绝该更改。
7.1 冻结帐户
有时候，某个智能联络表现异常或不可预测，并且不能按预期执行; 其他时候，应用程序或帐户可能会发现一个可被利用的漏洞来消耗大量资源。当这些问题不可避免地发生时，区块生产者有权纠正这种情况。
所有区块链上的区块生产者都有权选择哪些交易包含在区块中，从而使其能够冻结账户。使用EOS.IO程序的区块链通过21个活跃生产者中的15个投票正式授权冻结账户。
如果区块生产者滥用权力，他们将被投票出局，并且被无辜冻结的帐户将被解冻。
7.2 更改账户代码
当所有其他方式失败并且“势不可挡的应用程序”以不可预知的方式发挥作用时，使用EOS.IO软件的区块链允许区块生产者替换账户的代码，而不分叉整个区块链。这类似冻结账户的过程，这个代码的替换需要选出的15/21的区块生产者投票。
7.3 宪法
EOS.IO软件允许区块链建立点对点的服务条款协议或在用户之间签署绑定合约，称其为“宪法”。 这套宪法的内容界定了用户的义务，不能完全由法规强制，并通过确立管辖权和法律选择以及其他相互接受的宪法来促进解决争端。在网络上广播的每一笔交易都必须包含宪法的哈希作为签名的一部分，从而明确约束签署人的合同。
该宪法还定义了源代码协议的人类可读的意图。此意图用于识别发生错误时的错误和功能之间的差异，并指导社区进行哪些修正是正确的或不正确的。
7.4 升级议定书和宪法
EOS.IO软件定义了以下过程，通过该过程可以更新由规范源代码及其构成定义的协议：
1.区块生产者提议修改宪法并获得15/21批准。 2.区块生产者连续30天保持15/21批准新宪法。 3.所有用户都必须使用新宪法，作为未来交易处理的条件。 4. 区块生产者通过修改源代码来反映宪法的变化，并使用新宪法的哈希将其提交给区块链。 5. 区块生产者连续30天保持15/21批准新宪法。 6. 对代码的更改7天后生效，在批准源代码后，所有非生产完整节点有1周的时间进行升级。 7. 所有未升级到新代码的节点都会自动关闭。
默认情况下，EOS.IO软件的配置，更新区块链以添加新功能的过程需要2到3个月的时间，而修复不需要修改结构的非关键性漏洞的的更新可能需要1到2个月的时间。
7.4.1 紧急变更
如需进行软件更改以修复不良或损害用户的安全漏洞，区块生产者则可能会加快此进程。 总体来说，它可能会因为引入新功能或修复无害漏洞来加快升级而违反宪法。
EOS.IO软件将首先成为协调向账户交付认证消息（称为“操作”）的平台。 脚本语言和虚拟机的细节是特定于实现的细节，这些细节大多独立于EOS.IO技术的设计。 任何语言或虚拟机都可以与EOS.IO软件API集成在一起，这些语言或虚拟机具有足够的性能，并且具有确定性和正确的沙箱效果。
8.1 明确的指令架构
所有账户间发送的指令都是通过区区块链共识状态模式来定义的。该架构允许在二进制和JSON表示形式中无缝转换。
8.2 定义数据库的架构
数据库状态也使用类似的模式进行定义。 这确保了所有应用程序存储的数据都可被解释为人类可读的JSON格式，但以二进制的效率进行存储和操作。
8.3 通用多索引数据库API
开发智能合约需确定的数据库模式来追踪，存储和查找数据。 开发人员通常需要对多个字段进行排序或索引的相同数据，并保持所有索引之间的一致性。
8.4 身份验证与应用程序分开
为了最大化并行机会并最大限度地减少与事务日志中重新生成应用程序状态相关的计算债务，EOS.IO软件将逻辑验证分为三部分：
1.验证Action是否内部一致; 2.验证所有先决条件是否有效; 3.修改应用程序状态。
验证Action内部的一致性是只读的，不需要访问区块链状态。这意味着它能以最大并行度执行。验证的先决条件（如所需的平衡）是只读的，因此也可以从并发性中受益。只有修改应用程序状态才需写入权限，并且必须按顺序处理每个应用程序。
身份验证是验证可以应用操作的只读过程。事实上，应用程序在做这项工作，实时两项计算都需要执行，但是一旦交易包含在区块链中，就不再需要执行认证操作。
EOS.IO软件旨在促进区块间链接通信。 这是通过生成动作存在证明和动作序列证明来实现的。这些证明与围绕Action传输指令而设计的应用程架构相结合，使应用程序开发人员可隐藏区块链间通信和确认证明的细节，从而高度抽象地呈现给开发人员。
9.1 轻客户验证（LCV）Merkle证明
如果客户不需要处理所有交易，与其他区块链集成将更容易。毕竟，交易所只关心交易的汇入和汇出。如果交易所能够利用轻量级的存款证明而不是完全信任自己的区块生产者，这将是理想的选择。如果交易所能有效利用轻量级的存款证明，而不需完全信任自己的区块生产者，这将是理想的选择。至少，一个区块链生产者在与另一个区块链同步时希望尽可能的维持最低开销。
LCV的目标是能够生成相对较轻的存在证据，并且任何人都可追踪轻量级数据集来验证。在这种情况下，目标是证明特殊交易包含在特定区块中，并且该区块包含在经验证的特定区块链的历史记录中。
比特币支持事务验证的方式是，假设所有节点都有权读取区块头数据完整记录的能力，而每年区块头增长4MB。假设每秒产生10笔交易，一个有效的证明需要大约512 bytes。这对于一个出块时间是10分钟的区块链来说是可行的，但对于块区间隔为0.5秒的区块链这就不再“轻”了。
EOS.IO软件为任何在包含事务处理后拥有任何不可逆区块头的人提供轻量级证明。使用显示的哈希链接结构，可以证明任何事务的存在性，且证明是小于1024字节的。
在区块链中，每个区块链都拥有一个ID，并将头部标题设为可信的不可逆区块。 有可能证明该块已包含在区块链中。该证明采用ceil（log2（N））摘录其路径，其中N是链中的块数。 指定的SHA256摘要方法可证明所有在864个字节中包含的1亿个区块的存在。
当需要验证其他链上的证据时，可进行各种时间/空间/带宽优化。追踪所有块头（420 MB /年）将使证明保持较小证据。仅跟踪近期标题可在最小的长期存储和证明大小间折中。另外，区块链可使用缓慢评估方式记忆过去证明的中间哈希值。新的证明只需包含已知稀疏树的链接。所使用的确切方法必将取决于包含引用merkle证明交易的外部块的百分比。
在一定密度的相互连接之后，只让一条链包含另一条链的整个区块历史记录并且不需要提供所有样本将变得更有效率。出于性能考虑，最理想的做法就是尽可能减少链间证据的频率。
9.2 链间通信延迟
当与外部区块链通信时，区块生产商必须等到100％确定交易已被其他区块链不可逆转地确认后，再将其作为有效输入接受。使用基于EOS.IO软件的区块链和DPOS以及0.5s的DPOS出块速度及拜占庭容错不可逆性添加，这大约需要0.5秒。如果任何一个区块链生产者不等待，那就好比一笔后来被逆转的存款交易一样，并可能影响区块链共识的有效性。 EOS.IO软件同时使用DPOS和aBFT来实现快速的不可逆性。
9.3 完整性证明
当使用来自外部区块链的merkle证据时，知道所有处理过的交易为有效的，和知道没有交易被跳过或省略的，这两者存在显著差异 。尽管不可能证明所有最近的交易都是已知的，但却可证明交易记录没有间断。 EOS.IO软件为每个指令、每个账户分配一组序列去简化操作。用户可使用这些序号来证明那些特殊帐户的所有指令已被处理，并且是按序处理。
9.4 隔离见证
隔离见证的概念是指：一旦区块链完成不可逆交易后，交易签名便会无关紧要。因此，即使签名数据被缩减，当前状态仍可有效导出。由于签名占据了多数事务的大量数据，隔离见证可显著减少磁盘存储空间和同步时间。
相同概念也可使用到merkle 证明区块链之间的沟通上：一旦证明被接受，将不可逆转地记录在区块链上，区块链状态正确导出时便不再需要这2kb的SHA256哈希值来证明，在区块链之间的沟通上，这比一般签名减少了超过32倍的占用空间。
另外一个隔离见证的应用例子是Steem博客帖子，在这种模型下，帖子仅包括SHA256（博客内容），帖子内容会存在隔离见证数据内，区块链生产者将查证内容的存在性及已有的哈希值。不过，在区块链日志上恢复当前状态时并不需要预先储存帖子内容，因为内容一经确认，无需永久储存。
EOS.IO软件的设计源自经过验证的概念和最佳实践经验，并代表了区块链技术的根本性进步。 该软件是全球可扩展区块链社会的整体蓝图的一部分，其中可以轻松部署和管理去中化应用程序。