背景

区块技术在2008年随着比特币的发布而被引入，至此企业与开发者尝试在单一区块链平台上应用这一技术来支持各种各样的应用。

当一些区块链平台积极尝试单一功能的区块链的去中心化应用，比如BitShares去中心化交易所（2014）和Steem去中心化社交平台（2016），都以被每天数以千计活跃用户使用着。为支持这么大量的用户使用，它们都通过提升性能到每秒处理上千个交易，延迟低到1.5秒，清除费用，提供与中心化服务的类似体验。

当前已存在的区块链平台，被手续费，有限的计算容量所牵绊，阻止了区块链的广泛接纳。

区块链应用的需求

如果让达到广泛使用，在区块链上的应用需要一个平台，足够的灵活以达到下述的要求：

支持数以百万计的用户

要打败诸如Ebay，Uber，AirBnB，和Facebook，需要区块链技术能处理数以百万计的日活用户。在某些情况下，应用也许不能正常工作，除非出现了极其大量的用户，但总的来说，一个能处理大量用户的平台是基本的。

免费使用

应用开发者能被允许提供免费服务；用户不应该需要强制付费以使用平台或服务。一个免费的区块链平台将更可能得得到大家的接纳。开发者或企业基于免费的用户可以找到更有效的商业模式。

方便升级和Bug恢复

建立在区块链上的商业需要足够的灵活性来让他们的应用提供更多的特性。

所有的软件都有bug，即使有最严格的代码审查。平台必须足够强大以便在不可避免的情况下修复bug。

低延迟

一个好的用户体验需要可靠的反馈，而且反馈的延迟不应该在几秒以上。长的反馈时间打击用户的积极性，也让区块链上的应用相比中心化的应用不具竞争性。

串行执行的性能

有一些应用，不能使用并行的算法来优化，因为他们依赖逻辑的顺序执行。比如交易所，需要足够的串行化的执行性能来处理大量的交易。由此快速的串行执行的性能是必须的。

并行执行的性能

大规模应用程序需要能在多个CPU或计算机之间分配工作负载。

共识算法（DPOS）

EOS.IO软件将要实现唯一的去中心化共识算法，DPOS，以达到区块链上应用的性能需求。基于这个算法，持有令牌的人可以通过持续的批准投票系统来选择块生产者，任何人都可以选择参与块生产，机率与他收到的投票份额与所有总投票份额成正比。 对于私链，管理则通过代币来增减IT员工来实现。

EOS.IO软件允许区块精准的以每3秒产生一个区块，一个生产者在同一个时间点只能生产一个块。如果区块在指定的时间没有被生产出来，那么，那个时间的区块将被跳过。当一个或多个区块被跳过，将会有6秒或更多秒的区块间隔。

使用EOS.IO软件，区块以21生产者为一轮。在每一轮的开始，21个唯一的区块生产者将被选中。投票最高的20个你是我的候选者在每轮开始将自动被选中，最后一个生产者由其它生产者按投票比例选择。所有被选中的生产者都会使用基于块时间的伪随机数进行随机排序。随机是为了让所有的生产者保持与其它生产者的连接平衡。

如果一个生产者错过了一个区块，并且在24小时内没有生产任何区块，它将会从候选中移除，直到他通知区块链它想继续产生区块。通过不安排那些不够可靠的节点，尽可能的减少错过区块创建，来让整个网络运行得更平稳。

在常规的情况下，DPOS区块链不太可能会产生分叉，因为区块的生产过程是一个合作的过程而不是一个相互竞争的过程。如果产生的分叉，共识将会自动转向最长的链。这一机制有效是因为区块被加入到区块的速率与对最长链条这一共识一致的生产者数量直接相关（译者注：大多数是好的，那么最长的链，因为生产更快，将更长）。换句话说，一个区块分支，如果有更多的生产者，长度将会比更小的生产者更快。此外，不应该有区块生产者同时在两个分支上生产区块。如果一个区块生产者被发现这个，将被投出生产者。如果发现重复生产的加密证据，也可以设计成自动移除恶意使用者。

交易确认

标准的DPOS区块链有100%的区块生产参与度。一个交易可以在平均在广播后的1.5秒达到99.9%的确认度。

这里有一些特殊的情况，当出现软件bug，网络拥塞，或恶意的区块生产者创建两条或多条分叉。交易为达到绝对的不可逆转，一个节点可以选择等待21个生产者中的15块生产者的确认（译者注：确认的方式就是在你的交易所在块后继续产生新块）。基于EOS.IO中的标准配置，在通常情况下，需要平均45秒的时间。默认情况下，所有的节点会认为，21个中的15个确认了某个块，块中的交易将是不可逆的，将不会切换到某个不含有那个块的其它分叉中，无论其它分支的长度是多长。

在分叉开始的9秒内，一个节点可能警告用户他们非常可能处于一个较少的分支上。在2个连续的块缺失后，一个节点存在95%的可能性处于一个少数分支。如果连续3次缺失块，将有99%的可能性，正处于一个少数的分支上。将非常可能生成一个可靠的预测模型，实现某个节点是否错过块生产，最近块生产的参与率，以及其它的因素来提醒参与者可能的节点风险。

对于警告的响应取决于交易业务的场景，但最简单的处理方式是等待15/21的确认，直到警告停止。

交易作为权益证明（TaPoS）

EOS.IO软件需要每个交易被包含进最近的区块头哈希中。哈希有如下的目的：

防止不包含引用块的分叉上的交易重放攻击
通知网络，声明在某个分叉上的特定用户以及它的权益
随着时间的推移，所有用户最终直接确认块链，这使得难以伪造假冒链，因为假冒将无法从合法链路迁移交易。

帐户

EOS.IO软件允许所有的帐户使用一个独特的2到32字符长的可读字符引用。名称由帐户创建者选择。所有的帐户在创建时都必须有最小的帐户余额来支付保存帐户数据的花费。帐户名称同样支持命名空间，比如帐户@domain的拥有者可以创建帐户@user.domain。

在去中心化的上下文中，应用开发者需要支付名义上的帐户创建费。传统业务已经以广告，免费服务等形式获得的每个客户花费大量资金。在区块链上创建一个新的帐户的花费看起来微不足道。但幸运的是，如果一个用户已经在另一个应用中注册过，你们不再需要创建一个新的。

消息与处理方式

每个帐户都可以向另一个帐户发送结构化的信息，而且也可以定义脚本来处理接收到的消息。EOS.IO软件为每一个帐户设计了其独有的数据库，且仅仅只能通过他自身的消息处理器来定位。消息处理脚本也可以向其它帐户发送消息。消息和自动消息处理流程的结合即是EOS.IO定义的智能合约。

基于角色的权限管理

权限管理包括判断是否一个消息是否经过授权。最简单的形式的权限管理是检查一个交易是否有应有的签名，但这意味着需要的签名已经被知道了。
通常来说权限会被赋予某个人，或一组个体，且常常是划分的。EOS.IO软件提供了一个声明的权限管理系统来保证帐户足够的细粒度以及足够高的控制层级，包括谁可以做什么，以及什么时候。

认证与权限管理标准化，以及与业务逻辑分离是非常关键的。这将允许开发通用的权限管理工具同时提供重要的性能调优的可能。

每个帐户都可以被任意的，其它帐户和私匙的组合来控制。由此将创建一个层次化的权限结构来反应现实中的权限组成方式，这让多用户控制资金前所未有的方便。多用户控制的方式是对安全最大的贡献，当合理使用这点，它将极大程度上的减少黑客入侵的被盗。

EOS.IO软件允许帐户可以定义私匙及其它帐户发送特定消息类型到另一个帐户。举例来说，你可以让权限之一使用用户的社交媒体的帐户，另一个是访问交易所的权限。甚至可以给予其他帐户许可，代表用户的帐户行事，而无需分配密钥。

命名的权限层级

使用EOS.IO软件，帐户可以定义命名的权限层级。其中的每一个层次可以继承更高层级的命名权限。每个命名的权限层级定义了一个权限。每个权限是由私匙或其它帐户的定义的命名权限层级组成的，一个多签名检查的阀值。举例来说，一个帐户的朋友权限，可以设置为允许这个帐户的朋友无差别的操作这个帐户。

另一个例子是Steem区块链，它有三个硬编码的层级权限，owner，active和posting。posting权限可以进行社交活动，比如投票，发帖。而active权限，则可以做除了改变所有者，以外的任何事。owner则用来备份，它可以做任何事。EOS.IO泛化了这个概念，通过允许每个帐户持有者定义他们自己的层级以及可以执行的操作。

命名的消息处理组

EOS.IO软件允许每个帐户来组织其自己消息处理链，允许为处理链命名，处理链间也可以嵌套。这些命名的消息处理组可以在其它帐户配置自己的许可层级时被引用。

最高层级的消息处理组是帐户名称，最低的层级是帐户接收到的某个具体的消息类型。消息处理级可以通过下述方式引用：@accountname.groupa.subgroupb.MessageType。

在这样的模型下，一个交易所合约可以来分别分组分别创建与取消存款与取款。通过交易所合约的这种分组，将极大的方便用户的使用。

权限映射

EOS.IO允许每个账户定义从任何帐户的命名消息处理组到他们自己全名权限级别的映射。比如，一个帐户拥有者可以关联他的社交媒体应用到它的帐户的“朋友”权限组。有了这个权限的映射，它的所有朋友都能像帐户所有者那样在他的社交媒体上发送消息了。尽管他们像帐户所有者那样操作，但他们仍然使用自己的私匙来签名消息。这意味着，我们总是可以知道哪个朋友使用了这个帐户，用什么样的方式使用的。

权限评估

当从"@aclice"到"@bob"，发送一个类型为"Action"的消息时，EOS.IO会首先检查是否"@alice"已经定义了一个"@bob.groupa.subgroup.Action"的权限映射。如果没有找到这样的一个映射，会继续查找“@bob.groupa.subgroup”，“@bob.groupa”，直到最后的“@bob”。如果没有匹配任何权限，最后默认匹配的将是命名权限组@alice.active。

一旦映射确定存在，接着通过多签名的的流程校验签名权威，校验与命名权限关联。如果失败，它会接着上溯权限，直到最终遍历到根权限@alice.owner。

并行的权限评估

权限评估流程是只读的。一个交易中包含的权限的修改只能在块成功打包后才会生效。这意味着所有的交易的私匙和权限评估流程可以并行的执行。另外，这意味着不需要运行应用逻辑的，而进行快速的权限验证是可行的，这将省却在权限验证不通过时导致的逻辑回滚。最后，交易权限可以在收到pending交易时进行验证，且不需要在真正应用时再次检验。

将所有的考虑在内，权限验证代表了在验证交易时，很大比重的计算量。将之设定为只读的，并引入并行计算流程可以显著的提高性能。

当使用消息日志来重放区块链来确认某些状态的确定性时，则没有必要进行再次的权限检查。交易在某个好的区块中被包含的事实足够来跳过这个步骤。这将极大的减少一个一直增长的区块链中的重放时的计算负载。

具有强制延迟的消息

时间是安全的重要组成部分。在大多数的情况下，你没法知道一个私匙是否已被盗，除非它被使用了。当人们将私匙存在电脑上，以方便每天的使用时，基于时间的安全变得更加关键。EOS.IO软件允许应用开发者将某些特定的消息必须等待某个时间后才能被打包进区块中。在中间的空白时间，块可以被取消。

当一个这种消息被广播了，用户可以接收到一个邮件或文本。如果他们没有授权，wbnw产可以使用帐户恢复流程，并收回消息。

要设置的延延时间由操作的敏感度决定。买一杯coffe不需要任何延迟，并可以在几秒内被确认，而买一座需要72小时的清算期。移交整个帐户的控制权限可以占用30天。使用的延迟由应用开发者和用户自行选择。

被盗私匙的恢复

EOS.IO软件为用户提供了一种方式来当私匙被盗后恢复帐户的访问权限。一个帐户所有者可以使用任何最近30天所使用的私匙同之前指定的帐户恢复伙伴来重置帐户的私匙。帐户恢复伙伴不能单独重置帐户，必须需要帐户的所有者的帮助。

因为黑客已经控制了帐户，所以黑客尝试通过帐户恢复流程不会取得任何收益。此外，如果他们的确尝试通过恢复流程，恢复伙伴也会尝试认证身份及多因素认证（邮件或电话）。这可能让黑客无法向前并不会获得任何收益。

这个流程与简单的多签名认证是非常不同的。在一个多签名的交易中，第三方也是做为交易缔结的一方而存在，而帐户恢复流程中，代理只是帐户恢复流程的一方，并没有每天的交易执行权限。这将显著减少所有参与者的成本与法律风险。

应用并行执行的确定性

匹块链的共识取决于确定性（可重现性）。这意味着并行执行时不应该考虑排他性或使用锁。如果不使用锁同步，那我们必须保证所有的帐户都只能读写他们自己的数据库。这意味着每个帐户处理消息时是线性的，也即帐户的并行性是帐户级别的（译者注：众筹时仍可能有线性执行的性能问题？）。

使用 EOS.IO软件，区块生产者任务之一就是组织消息分发到互不依赖的线程，从而消息可以并行处理。每个帐户的状态依赖于发送到他的消息。区块生产者打包的交易必须被确定性的执行，但打包的过程没有必要是确定的。这意味着区块生产者可以通过调度交易来实现并行化算法。

并行执行在某种程度上意味着，一个脚本生成了一个新的消息，它并不会立即被发送，而是被也许被调度到下一轮执行。这样做的原因可能是当前的接收者正在被其它线程修改状态。

低的交互延迟

延迟是从一个帐户发送消息到另一个帐户，并收到回复的耗时。要实现的目标是允许两个帐户在同一个块中发送一个消息的来回，而不需要必须等待一个区块打包时间的3秒。为实现这一点， EOS.IO软件把每个区块划成一个周期，每个周期又被划为线程，每个线程又包含一系列的交易，每个交易又包含一组要发送的消息。这样的结构可以被可视为树状结构，每一个交叉点可能串行也可能并行执行

Block

    Cycles (sequential)

      Threads (parallel)

        Transactions (sequential)

          Messages (sequential)

            Receiver and Notified Accounts (parallel)

在某个时间周期生成的交易，可以发送到后续的时间周期或块中。块生产者会持续向块中的添加新的时间周期直到最终的时间截止或没有新生成的交易需要被发送。

这将可能使用静态方式分析一个给定的时间周期内是否存在两个线程中的交易会修改同一个帐户。如果我们能排除这种不变性，所有的区块就都能并行的执行所有的线程了。

只读的消息处理器

一些帐户也许会执行一些通过或失败的判断，不需要修改内在的状态。如果是这种情况，这些处理器可以通过并行的方式执行，只要在同一个周期内保证，即便有多个线程访问同一个帐户，以只读方式就不存在问题。

多账户的原子的交易

有时需要保证多帐户间消息的原子性。在这种情况下，消息和帐户的操作都会被指定到同一线程内，消息会被串行的处理。这种情形对于性能来说不是很理想，考虑使用时计费，按交易内关联到的独立用户数计费。

为了性能和成本的考虑，应尽量减少帐户间的原子操作。

区块状态的部分评估

可扩展的区块链技术要求组件是模块化的。每个人不需要运行所有的东西，特别是当他们只使用应用的某一个很小部分的时候。

一个交易所应用开发者运行一个全节点，是为了向它的用户展示交易所的整体状态。而这个交易所并不需要一个社交媒体应用状态数据。EOS.IO允许所有的全节点选择任何应用的子集来运行。发送到其它应用消息被安全的忽略了，因为一个应用的状态是由发送给他的消息决定的。

这对与其它帐户的交互上有重要的影响。其中最重大的是，即即使在同一台设备上，也不能假设另一个帐户的状态是可以访问的。这也意味着锁住另一个帐户以同步的方式调用另一个帐户的方式不再可行，因为另一个帐户并不保证在同一内存中。

所有的关乎状态的帐户间的交互都必须在区块链中通过消息的方式。

主观上最佳的调度方案

EOS.IO软件不能限制区块生产者发送任意消息到任何其它帐户。每一个区块生产者做出他们自己主观上的执行一个交易所需的复杂度，时间消耗。这适用于无论是通过脚本生成的，或者是通过用户生成的交易。

EOS.IO软件规定，在网络层面，无论是执行用0.01毫秒还是10毫秒，所有交易都将收取固定的网络计算的带宽成本。然而，使用该软件的每个单独的块生产者可以使用它们自己的算法和测量来计算资源使用。 当块生产者断定交易或帐户消耗了不成比例的计算能力时，他们在生产自己的块时简单地拒绝交易; 然而，如果其他块生产者认为它有效，他们仍可以处理该交易。

总仨来说，如果其中一个区块生产者认为一个交易有效，且在合理的资源使用的情况下，其它所有区块生产者都会接受，但也许会让这个交易花费好几分钟来找到这样的块生产者。

在某些情况下一个生产者可能创建一个超出了可接受范围的交易数区块。在这种情况下，下一个区块生产者可以选择性的拒绝这个区块，僵局将留给第三个区块生产者来打破。这与一个超大区块可能导致网络传播超时时的处理方式一致。社区将注意到异常，最终将移除恶意区块生产者的投票。

来自生产者的主观计算评估将释放区块链必须准确及确定的度量某些计算所花费的时长。通过这个设计，不用打破共识，不需要精确的计算指令数量，可能有非常大的机会优化这一块（译者注：计算量评估与共识分离）。

代币模型与资源使用

所有的区块链的资源都是受限的，需要一种机制来避免滥用。使用EOS.IO，主要有如下三大类别的资源被程序所使用：

• 带宽与日志存储（Disk）
• 计算与计算积压（CPU）
• 状态存储（RAM）

带宽与计算量有两个组成部分，立即使用或长期使用。一个区块链维护的是所有消息的日志和这些日志最终被全节点下载与存储。通过消息的日志，最终可以重建所有应用。

计算债务是从消息日志中重新生成状态必须的计算量。如果计算量增长过于迅猛，那么生成区块当前状态的快照，并丢弃区块的历史就变得非常必要。如果计算债务增长过于快，比如需要6个月时间来重放1年的交易量。这就非常严重，因此，计算债务必须小心的管理。

区块状态存储是可以从应用逻辑访问的消息。它包含订单或账户余额。如果状态不会被应用读取，那么它就不应该存储。举例来说，博客发贴的内容和评论不会被应用逻辑存储，他们就不应该存储到区块状态中。同时，博客和评论的存在性，投票数，其它一些属性应做为区块链状态的一部分存储起来。

区块生产者发布了他们可用的带宽，计算和状态资源。EOS.IO软件允许每一个帐户消费与被锁定在一个3天的权益合约中的其所占对应的代币比例的资源。举例来说，如果一个基于区块链的EOS.IO软件运作了，如果其中一个帐户持有总代币分配量的1%，那么这个帐户有资格来使用1%的状态存储容量。

使用EOS.IO软件，带宽，计算量的分配因为是瞬时的，基于分离的分配（没有使用的量不能留待将来使用）。EOS.IO使用的算法与Steem使用的带宽限速算法类似。

客观和主观的测量方法

如前面所提到的那样，基础的计算对性能和优化有非常大的影响。因此，所有的资源使用限制最终是主观的和强制的，由单个的区块生产者根据自己的算法评估。

也就是说，有些事情客观的去度量是微不足道的。消息发送的数量，以及内部数据库所存的数据的大小是客观的。EOS.IO允许区块生产者应用相同的，客观的衡量方法，而选择性的应用更严苛的主观的算法来进行主观的度量。

接收者的支付

传统上，商业会为办公空间，计算资源，其它商业活动中需要的资源进行付费。消费者购买对应的产品，来自产品的利润最终来涵盖其之前投入的成本。同样的，没有网站胁迫他的访问者为访问他们的网站付费，用于支付提供访问服务的费用。因此，去中心化的应用也不应该强制他们的消费者因为使用区块链而支付费用。

EOS.IO软件并不要求它的用户因为使用区块链而直接付费。因此也不会限制或阻止一个企业为他们的产品找到合适的商业模式。

资源委托

如果一个使用EOS.IO软件驱动的区块链，一个代币持有者也许没有立即的需求来消耗所有的或其中的一部分带宽等资源。它可以选择性的给或出租未消费的带宽给其它人；运行EOS.IO的区块生产者会识别这样的资源委托，而根据情况使用带宽。

区分代币价值与交易花费

EOS.IO软件的最大的一个好处是，一个应用的可用带宽与代币的价格无关。如果一个应用程序的所有者拥有相当数量的代币，那么这个程序可以在稳定状态及带宽的状态下永久运行。开发者和用户不受代币市场的价格的影响，因此不依赖于价格。EOS.IO软件允许区块生产者来自然的增长每个代币可用的带宽，算力和存储，不与代币的价格绑定。

EOS.IO在区块生产者生成一个新的区块是奖励代币。这些代币的价值将影响一个生产者可以购买的带宽，计算量和存储的量。这种模式自然地利用增加的代币值来增加网络性能。

状态存储花费

虽然带宽和计算可以被委托，但应用的存储需要应用开发者持有对应的代币直到状态被删除为止。如果状态永远不会被删除，那么代币也将从流通量中被移除。（译者注：这是赚应用开发者的钱的啊）

每个用户帐户都要消耗一定数量的存储；因此每个帐户必须维持一个最低的余额。当网络的存储容量增加时，需要的最低的余额会下降。

区块奖励

EOS.IO在一个区块生产者生产一个新区块时发行新的代币进行奖励。创建的代币数量由所有区块生产者期望获得的报酬的中值来确定。EOS.IO也许会强制设置一个生产者奖励上限来保证每个新增的代币数量不超过5%。

社区支持应用

社区不止可以选举新的区块生产者，用户还可以选择3个社区支持的应用或智能合约。这三个应用可以接收配置的总的每年的供应量百分比，其中要减去已奖励给区块生产者的部分。这些应用会接收到对应的被代币持有者的投票比例的代币奖励。被选中的应用或智能合约可以被代币持有者新选举出来的应用或智能合约所代替。

治理

治理是一个人们对一个主观的问题，不好通过软件算法解决，而通过人为介为达成共识的过程。EOS.IO实现了一个治理流程可以有效的指导块生产者对当前已存在区块的影响。没有一个事前定义的治理过程，先前的块链依赖于导致不可预测的临时的，非正式和经常有争议的治理过程。

EOS.IO认识到，权力源于代币持有者，它们把权力代理给区块生产者。区块生产者被给予受限和被审核的权限来冻结帐户，更新有缺陷的应用程序，并为底层协议提出硬分支。

EOS.IO的其中一部分是选举区块生产者。在任何对区块链的更新操作前，所有的区块生产者必须要同意。一个不同意的区块生产者可以被代币持有者投出去。如果区块生产者做出改变时没有经过代币持有者同意，那么所有其它的非生产的全节点验证者（交易所等）可以拒绝这个变化。

冻结帐户

有时一个智能合约以异常，不可预测，或运行不及预期；其它一些时候，一个程序或帐户被发现有漏洞，从而消耗非常多的资源。当这种不可避免的事件发生时，区块生产者有权纠正这种情况。

区块生产者在所有的区块链上都有权选择哪个交易被打包进区块中，这就给了他们一个权力来冻结帐户。EOS.IO通过17/21活跃的生产者的投票来主观上的赋予这项权力。如果某个生产者滥用这个权力，它将会被投出去，从而帐户会被解封。

修改帐户代码

当所有其它的失败了，一个永不停机的应用运行在一个不可预测的状态时。EOS.IO允许区块生产者更换帐户的代码，而不用在区块链上进行一个硬分叉。与冻结帐户的流程类似，更换某个帐户的代码需要17/21个被选举的区块生产者的投票。

宪法

EOS.IO允许在区块链上多个签署的用户中建立一个P2P的协议服务条款，或一个附属的合约，通过宪法的方式被引用。宪法的内容定义了在用户之间的不能完全通过代码强制执行的，并通过确立司法管辖权和法律选择以及其他相互接受的规则来促进争议解决。 在网络上进行的每一次交易都必须将宪法的哈希表作为签名的一部分，从而明确地将签署者绑定到合同中。

宪法还定义了源代码协议的可以人为读取的意图。 这个意图用于在发生错误时识别错误和功能之间的区别，并指导社区判定修复是正确的或不正确的。

升级协议与宪法

EOS.IO软件定义了一个流程，通过代码定义的协议及其宪法，可以使用下述流程进行更新：

• 区块生产者发起一个宪法修改，并获得了17/21的批准
• 区块生产者维持30天以上的17/21的同意
• 所有用户都需要使用新的宪法的哈希签名交易
• 区块生产者通过改动源代码来反映对宪法的更改，并将git提交的哈希值提交到区块链上。
• 区块生产者维持连续30天以上的17/21的同意
• 对代码的修改在7天后生效。在源代码被批准后给予全节点一周的时间来更新。
  所有不升级到新代码的节点将自动关闭

默认的配置情况下，升级区块链上的新特性将花费2到3个月，修复不严重的bug，不需要修改宪法的会花费1到2个月。

紧急更新

区块生产者可以加速整个流程，如果软件需要修复一个有危害的错误或严重的正在影响用户的漏洞，一般来说需要调整宪法以加速更新，引入新特性或修复有危害的bug。

脚本与虚拟机

EOS.IO将会是第一或至少是前面的协调帐户间的认证信息传递的平台。脚本语言和虚拟机在实现上的细节将极大可能的与EOS.IO的技术设计无关。任何语言或虚拟机如果是确定性的，且是有足够性能的以沙盒形式运行的将能很好的与EOS.IO的API集成。

模式定义的消息

帐户间发送的所有消息都是通过模式定义的，这也是区块链共识的一部分。这种模式消息允许二进制或JSON格式消息间的无缝衔接。

模式定义的数据库

数据库状态也是通过类似模式定义。这保证了所有应用存储的数据能以人类可以解释可读的JSON格式，而又可以以二进制的性能被计算机使用。

隔离应用认证

为了使用交易日志重建应用状态的过程中，最大化的提高并行的可能性，以及尽可能的减少计算债。EOS.IO将验证逻辑分为了三个部分：

• 验证消息是内部一致的
• 验证所有的前置条件是正确的
• 修改应用状态

验证消息是内部一致的是只读的，不需要访问区块的状态。这意味着可以尽可能的并行化。验证前置条件，比如需要的余额，同样也因为是只读的可以并行化。只有修改应用状态需要写入状态，必须线性的执行。

认证是一个只读的过程，用于校验一个消息是否可以接收，应用程序实际已经在做这个工作。在实际情形中，两个计算都需要执行，然而一旦一个交易被打包进了区块，认证的操作就不再是需要的了。

虚拟机无关的架构

EOS.IO希望可以支持多虚拟机且在未来新虚拟机可以按需添加。因为这个原因，这篇文章将不再讨论某个具体的语言或者虚拟机。有两个虚拟机当前被考虑可以用于EOS.IO。

Web Assembly(WASM)

Web Assembly是构建高性能Web应用的新兴Web标准。通过一点小小的修改，Web Assembly可以被调整为确定的，沙盒的。其好处是来自工业的广泛的使用，这可以让智能合约以大家熟悉的C或C++语言进行开发。

以太坊的开发者已经开始修改Web Assembly以提供合适的沙盒和确定性Ethereum flavored Web Assembly(WASM) 。这个方式也可以容易的被采用并集成到EOS.IO中来。

EVM

这个虚拟机已经被用来运行大多数现存的智能合约，可以为EOS.IO所采用。在EOS.IO的区块链中非常可能运行一个以沙盒模式运行的EVM智能合约。通过一些适配EVM中的智能合约可以与EOS.IO的区块应用交互。

区块交互

EOS.IO旨在促进内部区块链交互的。这通过让生成消息存在的证据以及消息顺序的证明更加容易来实现。这个证明结合消息传递的应用的架构，来让内部区块链的交互及证明的校验对应用程序的开发者透明。

轻客户端的梅克尔证明

如果客户端不能执行所有交易来进行校验的话，那么集成其它区块链其实是非常容易的。毕竟，一个交易所只关心交易所进出的操作，其它的都不关心。如果交易所能使用一个轻量级关于存款的梅克尔证明而不需要信任整个的区块生产者，那么一切都将会变得有价值得多。当一个链与其它链同步时，一个链的区块生产者就尽可能维持小的可能的开销。

LCV将让生成足够轻量的，且能被任何跟踪一个足够轻量的数据来进行存在证明变得可能。在这种情况下，目标是证明特定交易被包括在特定块中，并且该块被包括在特定块链的经过验证的历史中。

比特币支持交易验证，假设所有的节点都能访问每个头为4M的区块历史。如果交易为10每秒，一个有效的验证需要512字节。这在10分钟一个块的情况下能良好的工作，但对于间隔是3秒的区块链来说，就不再轻量。EOS.IO通过让交易被包含进块内，任何人都可以提供这个不可逆转的块头来做为证明。使用哈希链接的结构，让交易存在的证明只需要不到1024字节大小。如果假设验证节点跟踪过去一天中的所有块头（2 MB数据），则证明这些事务将仅需要200字节长的证明。

由于有一些增加的开销，来生成恰当的哈希链接的区块以进行证明，所以没有任何理由来像这样生成区块。

但如果是其它块链需要证明时，他们有足够的时间，空间，带宽资源来实现这一切。跟踪所有的区头（420M每年)将会让证明的空间占用变小。仅跟踪最近的区块头可以在长期尽可能小的占用存储和证明大小间取得折衷。或者，一个区块可以使用懒惰的评估方法，它可以记住之前证明的一个中间哈希值。新证明只需要包含一个到已知稀松树的关联即可。具体的方法仍取决于外部区块通过梅克尔树包含的交易数的比例来定。

但超过一定的量的链间的认证，反而让一个链包含整个另一个区块的完整历史，从而消除证明变得更加有效。为了性能上的考虑，应尽可能的减少跨链的证明。

链间的交互延迟

当与另一个外部的链进行交互时，区块生产者必须等到100%的确定一个交易被其它链认为不可逆转后才能接受这个块中的交易做为一个有效的输入。EOS.IO和他的3秒的21个生产者的DPOS的机制，这一切需要大概45秒。如果一个区块生产者不等待确定性，就像一个交易接受一个稍后可能被撤销的交易一样，将会影响整个链的共识。

完整性证明

当在链外使用梅克尔证明时，知道所有的交易校验都是有效的与知道没有交易被跳过和忽略是完全不同的。有可能证明所有最近交易是知道的，或者是证明交易历史之间是否有被跳过。EOS.IO通过为发送给每个帐户的每个消息指定了一个序列号来实现。一个用户可以使用这个序列号来证明某个帐户的所有消息都被处理了，且他们都是按顺序处理的。

结语

EOS.IO的设计来自于已验证的概念和最佳实践，代表了区块链技术的基本进步。 该软件是全球可扩展区块链社区的整体蓝图的一部分，让去中心化应用程序可以轻松部署和管理。