EOS学习(二) - 白皮书学习

EOS.IO 技术白皮书 v2

March 16, 2018
摘要： EOS.IO 软件引入一种新的区块链架构设计，它使得去中心化的应用可以横向和纵向的扩展。 这通过构建一个仿操作系统的方式来实现，在它之上可以构建应用程序。 该软件提供帐户、身份验证、数据库、异步通信和跨越数百个CPU内核或集群的应用程序调度。 由此产生的技术是一种区块链架构，它可以扩展至每秒处理百万级交易，消除用户的手续费，并且允许快速和轻松的部署去中心化的应用。

请注意：本白皮书中提到的加密token是指采用eos.io软件的已发布的区块链上的加密token。它们并不指在以太坊区块链上发行的与EOS代币发行相关的ERC-20兼容代币。
Copyright © 2018 block.one

未经允许，在非用于商业和教育用途的前提下 (即，除了收取费用或商业目的)，如果注明原始出处并适用声明的版权，任何人可以使用、复制或发布本白皮书内的任何内容。

免责声明：This EOS.IO Technical White Paper v2 is for information purposes only. block.one does not guarantee the accuracy of or the conclusions reached in this white paper, and this white paper is provided “as is”. block.one does not make and expressly disclaims all representations and warranties, express, implied, statutory or otherwise, whatsoever, including, but not limited to: (i) warranties of merchantability, fitness for a particular purpose, suitability, usage, title or noninfringement; (ii) that the contents of this white paper are free from error; and (iii) that such contents will not infringe third-party rights. block.one and its affiliates shall have no liability for damages of any kind arising out of the use, reference to, or reliance on this white paper or any of the content contained herein, even if advised of the possibility of such damages. In no event will block.one or its affiliates be liable to any person or entity for any damages, losses, liabilities, costs or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special for the use of, reference to, or reliance on this white paper or any of the content contained herein, including, without limitation, any loss of business, revenues, profits, data, use, goodwill or other intangible losses.

背景

区块链技术是通过 2008 年诞生的比特币货币得以被认知，自从那之后企业家和开发者就不断的尝试推广这一技术，以便在单一的区块链平台上支持更为广泛的应用程序。

而一些区块链平台努力的支持可运作的去中心化应用，具体的应用比如 BitShares 去中心化交易所 (2014) 和 Steem 社交媒体平台 (2016) 已经成为每天被成千上万活跃用户重度使用的区块链。 他们能做到这些，是通过性能的提升达到每秒处理上千交易，消除手续费和提供堪比已经存在的中心化服务的用户体验。

已存在的区块链平台承担着大量的交易费和有限的可计算能力，这都阻碍了区块链技术的大面积应用。

区块链应用的要求

为了赢得广泛的应用，构建在区块链之上的应用需要一个灵活性足以满足以下要求的平台：

支持成百上千的用户
像 Ebay、Uber、AirBnB 和 Facebook 这样企业，他们需要区块链技术能处理每日数以千万的活跃用户。 在某些情况下，除非用户群体达到一个极庞大的量级否则应用并无用武之地，因此一个可以处理极其庞大用户的平台是至关重要的。

免费的使用
应用程序开发者需要灵活度来为用户提供免费的服务，用户不应该为了使用该平台或者从该平台提供的服务中获益而付费。一个可以免费供用户使用的区块链平台或许将赢得更为广泛的使用。 开发者和企业可以制订有效的货币策略。

简单升级和 bug 修复
构建基于区块链的应用程序的企业需要能够为应用增加新特性的灵活性。区块链平台必须能够支持软件和智能合约升级。

所有非同凡响的软件都会受到 bug 的影响，即便是经过了最严格意义上的形式化验证(formal verification)。这个平台必须具有足够的鲁棒性以便应对不可避免出现的 bug。

低延时
一个好的用户体验需要延时时间在数秒内就能收到可靠的反馈。 高延时会阻碍用户，并且会让构建在区块链上的应用比已有的非区块链应用缺乏竞争力。区块链平台应该要支持交易的低延时。

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

并发性能
大规模应用需要将工作量分配到多个 CPU 和计算机之上。

共识算法(BFT-DPOS)

EOS.IO 软件使用唯一能满足区块链之上应用性能需求的去中心化共识算法，委托股权证明 (DPOS)。在这种算法下，持有采用了EOS.IO软件的区块链上的tokens的结点可以通过持续的批准投票系统来选举区块生产者。任何人都可以选择参与到区块生成中，并且如果能说服token持有者给自己投票，则会有机会生成区块。

EOS.IO 软件使得区块准确的每 0.5 秒生成一个并且在任何时间点都只有一个被授权的生产者来生成区块。 如果一个区块在规定时间之内未被生产出来，则这一时间段的区块将被跳过。 当一个或多个区块被跳过时，在区块链中会有一个 0.5 秒或者更多的时间间隔。

在 EOS.IO 软件中，每轮生成126个区块 (6 blocks each, times 21 producers)。在每一轮的开始时，21 个唯一的区块生产者被token持有者通过选票选举产生。 被选举出的生产者是按照15个或者更多的生产者商定好的顺序被调用的。

如果一个生产者错过了一个区块并且在过去的 24 小时内没有生产任何区块，那么它将被从候选中移除，直到它在区块链中通知它要开始再次生产区块的意图。 通过不调度被证实为不可靠的节点从而最小化区块丢失数量来确保网络操作的稳定性。

在一般情况下，一个 DPOS 区块链不会经历任何的分叉，因为区块生产者是通过合作而非竞争的方式来生产区块。 即便真的出现了分叉，共识机制会自动的切换到最长的链上。之所以会这样运作，是因为区块添加到一个区块链分叉上的速率与公用同一共识的区块生产者的比例是相关的。 换句话说，具有更多生产者的区块链分叉会比拥有较少生产者的那个分叉增长的速度更快，因为具有更多生产者的分叉会经历较少的区块丢失。

此外，没有一个生产者会同时在两个分叉上生产区块。 如果一个区块生产者被抓到做这样的事儿，那么这个生产者将很可能被投票投出。 这些双重生产行为的加密凭证也可以用来自动删除这些滥用者。

允许所有生产者可以给所有区块签名，只要没有生产者用同一个时间戳或者同一个区块高度签名两个区块即可，通过这种方式将BFT引入到了传统的DPOS。只要有15个区块生产者为一个区块签名，那么这个区块就会被视为不可逆。任何用同一个时间戳或者同一个区块高度签名了两个区块的拜占庭生产者(byzantine producer)将会生成他们谋反的加密证据。在这种模式下，一个不可逆转的共识可以在1秒内达成。

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

除了DPOS外，EOS.IO为了更快的实现交易的不可逆，还加入了匿名拜占庭容错(aBFT)。aBFT算法提供了1秒内交易不可逆的100%确认。

交易作为股权证明 (TaPoS)
EOS.IO 软件需要每一个交易包含最近一个区块头的哈希值。这个哈希值有两个目的：

1. 防止交易重放发生在不包含引用的区块那个分叉上；和
2. 通知网络，特定用户和他们的股份在某个具体的分叉上。

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

帐户

EOS.IO 软件允许所有的帐户使用一个唯一的人类可读的名称来索引，长度最长是12个字符。这个名称由帐户创建者自己选择。账户创建者必须保留所需的RAM以存储新账户，直到新账户持有代币以保留自己的RAM。

在一个去中心化的场景中，应用开发者将会为创建账户以注册新用户的成本买单。传统的企业已经为他们获得的每个客户花费了大量的钱，比如广告，提供免费服务等形式。相比较而言，创建一个新的区块链帐户的花费简直微不足道。 值得庆幸的是，对一个已经在另一个应用注册过的用户并不需要再创建新的帐户。

消息 & 处理(Actions & Handlers)

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

为了支持并发执行，每一个账户也可以在其数据库中定义任意数量的作用域。区块生产者将以这样的一种方式调用交易，即对作用域的内存访问没有冲突，因此它们可以并行执行。

基于角色的权限管理

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

认证和权限管理被标准化和从应用的业务逻辑中分离开是至关重要的。这使得管理权限的工具以通用的方式进行开发，并且又为性能优化提供了重要的可能性。

每一个帐户可以被任何权重组合的其他帐户和私钥管控。 这创建了分层级的权利结构，这反映了现实中的权限组织方式，并且使得多用户控制帐户比以往更容易。 多用户控制是安全的最大贡献者，并且，如果使用得当，它可以极大的消除因被黑而导致被盗窃的风险。

EOS.IO软件允许账户定义秘钥和/或账户以什么样的组合以将一个特定类型的消息发送给另外一个账户。
举个例子，可以指定一个密钥给一个用户的社交媒体账号，同时另一个密钥访问交易所。 甚至可以给其他帐户权限来代表一个用户的账户而无需分配给他们密钥。

命名的权限级别

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

另一个例子在 Steem 区块链中，它包含三个硬编码的命名权限级别：拥有者，活跃和发帖。 发帖权限就只能进行如投票和发帖的社交活动，而活跃权限可以做除了变更拥有者之外的所有的事情。 拥有者权限是用于冷存储并且能够做任何事。EOS.IO软件通过允许每个账户持有人定义自己的层次结构以及操作分组来概括这一概念。

权限映射

EOS.IO 软件允许每个帐户定义从任意其他帐户的一个合同/操作(或者合同)与自己的命名权限级别之间的映射。 举个例子，一个帐户所有者可以将自己社交媒体应用与自己的"Friend"权限群组建立映射。 有了这个映射，任何朋友可以以这一账户持有者的身份在这一帐户持有者的社交媒体上发帖。 尽管他们将以帐户持有者的身份发帖，但他们仍然使用自己的密钥来签名消息(sign the Action)。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。

评估权限

当 @alice 以 “Action” 类型发送一条消息给 @bob 时，EOS.IO 软件首先会检查 @alice 是否为 @bob.groupa.subgroup.Action 定义过权限映射。 如果什么都没有找到，紧接着检查 @bob.groupa.subgroup 映射，然后是 @bob.groupa，最后 @bob 将被检查。 如果都没有找到，那么假定的映射为命名权限群组 @alice.active。

一旦一个映射被识别，那么将使用阈值多重签名过程和与命名权限关联的权限来验证签名权限。 如果失败了，则跃迁至父权限，最终直至拥有者权限，@alice.owner。

默认权限群组

EOS.IO技术同样允许所有账户拥有一个能做任何事的"owner"组，以及一个除了改变所有者外能做其他任何事的"active"组，所有其他权限组派生自"active"组。

权限并行评估

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

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

当从消息日志中重新生成确定性状态时不再需要重复的权限验证。事实是一个交易如果被包含进了一个被认为是好的的区块时它就有足够的理由跳过这步。这大大减少了与重放不断增长的区块链相关的计算负载。

带强制性延时的消息(Actions with Mandatory Delay)

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

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

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

恢复被盗窃的密钥

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

黑客尝试进行恢复流程是无意义的，因为他们已经“控制”了帐户。 此外，就算他们真的进行这一流程，恢复合作者也会要求身份证明和多因素认证 (手机和邮件)。 这可能会让黑客妥协或者无功而返。

这一流程与简单的多重签名有很大差异。 在多重签名中，另一个实体要参与所有执行的交易。相比之下，在恢复流程中，恢复合作者只在恢复过程时才起作用，对每天的交易无作用。 这大大的降低了每个参与者的成本和法律责任。

应用程序的确定性并行执行

区块链共识取决于确定性 (可重现的) 的行为。 这意味着所有的并行计算必须是不能互斥或者具有其他锁特性的。没有了锁就必须有一些方式可以确保那些并发执行的交易不会创建不确定性的结果。

2018年6月发行的EOS.IO软件将运行单线程，目前它包含了未来多线程并行执行所必需的数据结构。

在一个基于EOS.IO软件的区块链中，区块生产者会负责组织将消息分发到独立的线程中，使得他们并发执行。
进度表由区块生产者输出并且会被确定性的执行，但是生成进度表的过程却不一定是确定性的。这意味着区块生产者可以使用并发算法来调度交易。

并行执行的一方面意味着当一个脚本生成了一个新的消息，它不会立即被发送，而是被安排在下一个轮询中发送。 不能立马发出的原因是接受者可能在另一个碎片中活跃的变更自己的状态。

最小化通信延迟

延迟是一个帐户从发出一条消息给另一个帐户，直到收到回应的这段时间。我们的目标是在一个单独的区块中包含两个帐户交换消息的来去信息，而不用在每条消息间等待 0.5 秒钟。 为了做到这一点，EOS.IO 软件将每个区块划分到循环中。 每个循环划分为碎片，每个碎片包含了一个交易列表。 每一个交易包含了待发送的消息集合。 这个结构可以被可视化为一个树，其中交互层彼此并行，各自被顺序的执行。

区块

  循环 (顺序)

    碎片(并行)

      交易 (顺序)

        消息 (顺序)

          接受者和被通知帐户 (并行)

在一个循环中生成的交易可以在后续的任何一个循环或者区块中被发送。 区块生产者会持续不断的向区块中添加循环直到最大的墙上时间( wall clock time )到了或者没有更多的新交易需要发送。

可以对一个区块使用静态分析来验证同一个循环内不存在包含有修改同一个账户的交易的两个碎片。 只要维持不变的，一个区块就可以以并行的运行所有碎片的方式被处理。

只读消息的处理程序

有些帐户可以在通过/失败的基础上处理消息而不修改他们的内部状态。 如果是这样的话，那么这些处理程序可以并行执行，只要只有一个特定的帐户的只读消息处理程序包含在一个特定的循环里的一个或多个碎片中。

多帐户的原子化交易

有时我们需要确保消息自动的被多个账户传递和接收。 在这种情况下，消息会被放在同一个交易内，账户都会被分配到同一个线程，并且消息被顺序的添加。

区块链状态的部分评估

扩展区块链技术使得组件化成为必要。每个人不应该执行所有的事务，尤其是当其只需要运行应用的一个小的子集。

一个交易所应用开发者运行一个完整节点的目的是为其用户展现所有的交易状态。 这个交易所应用没有与社交网络建立关联的必要性。EOS.IO 软件允许任何的完整节点选择应用的任何子集来执行。 如果你的应用不依赖任何其他合同的状态，传递给其他应用的消息可以被安全的忽略掉。

自主最优调度(Subjective Best Effort Scheduling)

EOS.IO 软件并不能为区块生产者向任何其他帐户送达的任何消息负责。每个区块生产者要对计算的复杂度和处理一个交易所需的时间自己进行主观上的预测。这同时适用于用户生成的交易和脚本自动生成的交易。

在一个采用了EOS.IO软件的已启动的区块链中，在网络级别上，所有交易都会根据执行的WASM指令数量收取计算带宽成本。然而，每个单独的区块生产者要通过自己的算法来计算资源的消耗。当一个区块生产者断定一个交易或者帐户消耗了不相称的大量的计算资源时，他们可以在生成自己的区块时拒绝该交易；但是，如果其他区块生产者认为交易是有效的，他们就仍需要处理该交易。

一般而言，只要一个区块生产者认为一笔交易在资源使用限度内是有效的，那么其他区块生产者也会接受该交易，但该交易找到那个生产者可能需要花费 1 分钟。

在某些情况下，生产者可能会创建包含有可接受范围之外数量级交易的区块。在这种情况下，下一个区块生产者可能会选择拒绝该区块并且第三个生产者会打破这个联系。这和因为区块过大导致的网络延时没什么不同。 社区会注意到模式的异常并且最终会删除恶意生产者的投票。

这种对计算成本的主观评估将区块链从必须精确和确定的预测一些东西要花多长时间来运行这一问题中解放出来。 有了这一设计就不需要精确的计算指令数量，这样可以在不打破共识的情况下显著增加优化的机会。

延迟交易(Deferred Transactions)

EOS.IO软件支持延迟交易，该交易可以在将来被调用执行。这使得计算可以移动到不同的碎片和/或创建连续调度连续交易的长时间运行的进程。

上下文无关消息(Context Free Actions)

一个上下文无关消息所涉及到的计算是仅依赖于一个交易的数据，但不是区块链状态。例如，签名验证是一种计算，它只需要交易数据和一个签名来确定签名了该交易的公钥。这是区块链必须执行的其中一个最昂贵的独特的计算，但由于此计算是上下文无关的，因此可以并行执行。

上下文无关的消息与其他用户消息类似，只是它们缺乏对区块链状态的访问以进行验证。这不仅使 EOS.IO 能够并行处理所有上下文无关的消息（如签名验证），而且更重要的是，这使得通用签名验证成为可能。

随着对上下文无关的消息的支持，诸如分片、雷电网络、Plasma、状态通道等其他可扩展性技术变得更加并行化和实用。这种开发能够实现高效的区块链间通信和潜在的无限的可扩展性。

Token 模型与资源使用

请注意：本白皮书中提到的加密通证是指使用了EOS.IO软件的区块链上的通证，不包括以太坊区块链平台上发布的ERC-20通证和EOS通证。

所有区块链都受到资源限制，需要一个系统来防止滥用。通过使用了EOS.IO软件的区块链，应用程序可以使用三大类资源：

1. 带宽和日志存储 (磁盘)；
2. 计算与计算储备 (中央处理器)；
3. 状态存储 (内存)。

带宽和计算有两部分，瞬时使用和长期使用。 一个区块链维持着所有消息的日志，这些日志最终被全节点存储和下载。 通过消息日志可以重现所有应用的状态。

可计算债务是一个必须通过消息日志重新构建状态的计算。 如果可计算债务增长变得过于臃肿则有必要通过快照方式记录区块链状态，并且丢弃区块链历史记录。 如果可计算债务增长过快，则它需要花费 6 个月时间来重放与 1 年等值的交易。因此，可计算债务被细心的管理是至关重要的。

区块链状态存储是通过访问应用逻辑获取的信息。 它包括诸如订单量和账户余额等信息。 如果状态从未被应用读取，则它不会被存储。 比如，博客发布的内容和评论如未被应用逻辑读取，则他们就不应该存储在区块链状态中。 同时，发布的内容／评论的存在、投票的数量和其他属性要作为区块链状态的一部分被存储下来。

区块生产者对外发布他们可用的带宽，计算能力和状态。 EOS.IO 允许帐户按比例消耗一个 3 天对赌合约中的可用资源。 举个例子，如果一个基于 EOS.IO 软件的区块链启动了，并且一个帐户持有所有 token 发行总量的 1%，那么帐号就具有使用 1% 状态存储空间的可能性。

在已发布的区块链上采用EOS.IO软件意味着带宽和计算能力是以少量保留为基础进行分配的，因为它们是暂时的（未使用的容量不能保存以备将来使用）。EOS.IO软件使用的算法与Steem用于速率限制带宽使用的算法类似。

客观与主观的度量

如前所述，检测计算使用对性能和优化有重大影响；因此，所有资源的使用限制最终都是主观的，强制执行是由区块生产者根据各自的算法和评估完成的。这些通常由区块生产者通过编写自定义插件来实现。

也就是说，有一些事情是微不足道的客观衡量。发送的消息数，以及存储在内部数据库中的数据的大小，客观地衡量起来是很便宜的。EOS.IO软件使区块生产者能够对这些客观测量应用相同的算法，但可以选择对主观测量应用更严格的主观算法。

接收方付费(Receiver Pays)

传统上，企业需要支付办公空间、计算能力和其他运营成本。客户从业务中购买特定产品，这些产品销售收入用于支付业务运营成本。同样，没有网站要求访问者支付访问其网站的小额费用来支付托管费用。因此，去中心化应用程序不应强迫其客户直接为使用区块链服务支付给区块链。

使用EOS.IO软件发布的区块链不会要求用户直接支付区块链使用费，因此不会限制或阻止企业为其产品确定自己的盈利策略。

虽然接收者确实可以付费，但EOS.IO允许发送方支付带宽、计算和存储费用。这使应用程序开发人员能够选择最适合其应用程序的方法。在许多情况下，对于不想实现自己的配给系统的应用程序开发人员来说，发送者支付的模式大大降低了复杂性。应用程序开发人员可以将带宽和计算委托给他们的用户，然后让“发送者付费”模型强制使用。从最终用户的角度来看，它是免费的，但从区块链的角度来看，它是发送者支付的。

委托能力(Delegating Capacity)

使用EOS.IO软件启动的区块链上的代币持有人，可能没有立即需要消耗全部或部分可用带宽，可以将未使用的带宽委托或出租给其他人；在该区块链上运行EOS.IO软件的区块生产者将承认这种委托，并相应地分配带宽。

分离交易成本与 Token 价值(Separating Transaction costs from Token Value)

EOS.IO软件的一个主要好处是，应用程序可用的带宽量完全独立于任何代币价格。如果应用程序所有者在采用EOS.IO软件的区块链上持有相关数量的Token ，那么应用程序可以在固定状态和带宽使用范围内无限期运行。在这种情况下，开发者和用户不受代币市场价格波动的影响，因此不依赖于价格。换句话说，采用EOS.IO软件的区块链使区块生产者能够自然地增加每个代币的带宽、计算和存储，而不受代币价值的影响。

使用EOS.IO软件的区块链也会在每次生成区块时奖励区块生产者代币。代币的价值将影响带宽、存储和生产者可以购买的计算；这个模型自然地利用增加的代币价值来提高网络性能。

状态存储成本

由于带宽和计算资源可以被委托，因此应用的状态存储需要应用程序的开发者持有 token 直到状态被删除。 如果状态没有被删除，那么 token 实质上就从流通中被移除了。

区块奖励(Block Rewards)

采用EOS.IO软件的区块链将在每次生成区块时向区块生产者奖励新的代币。在这种情况下，创建的代币数量由所有区块生产者发布的预期工资的中位数决定。EOS.IO软件可以配置为强制执行生产者奖励上限，这样token供应的年度总增长不会超过5%。

工作者提案系统(Worker Proposal System)

除了选择区块生产者外，根据基于eos.io软件的区块链，代币持有人还可以选择一些旨在造福社区的工作者提案。获胜的提案将收到代币供应量按照配置的百分比的代币减去已支付给区块生产者的代币。这些提案将收到与每个应用程序从代币持有人处收到的投票数成比例的代币，达到执行其工作所需的金额。代币持有人可将所选提案替换为新选提案。
在2018年6月首次启动时，执行工作者提案的系统合约可能不到位，但供资机制将到位。随着区块生产者奖励开始，将开始积累资金。由于工作者提案系统将在WASM中实现，因此可以在后期添加，而不需要进行分叉。

治理(Governance)

治理通常是一个社区中的人们的以下过程：

1. 就不能完全由软件算法捕获的集体消息的主观问题达成共识；
2. 执行他们达成的决定；以及
3. 通过宪法修正案改变治理规则本身。

一个基于eos.io软件的区块链实现了一个有效地指导区块生产者现有影响的治理过程。如果没有一个明确的治理过程，以前的区块链依赖于特殊的、非正式的、经常引起争议的治理过程，从而导致不可预测的结果。

基于eos.io软件的区块链认识到权力来源于代币持有人，他们将权力委托给区块生产者。区块生产者被授予有限的、经过检查的权限，可以冻结帐户、更新有缺陷的应用程序，并对基础协议提出硬分叉更改。

嵌入到eos.io软件中的是区块生产者的选择。在对区块链进行任何更改之前，这些区块生产者必须批准它。如果区块生产者拒绝进行代币持有人所期望的更改，那么他们可以被否决。如果区块生产者未经代币持有者许可而进行更改，则所有其他非生产的全节点验证器（交换等）将拒绝更改。

冻结帐户

有时，一个智能联系人的行为异常或不可预测，无法按预期执行；有时，应用程序或帐户可能会发现一个漏洞，使其消耗不合理数量的资源。当此类问题不可避免地发生时，区块生产者有权纠正此类情况。

所有区块链上的区块生产者都有权选择区块中包含哪些交易，从而使他们能够冻结账户。使用eos.io软件的区块链通过使冻结账户的过程受制于活跃生产者的15/21投票，从而使该权限正式化。如果生产者滥用权力，他们将被否决，账户将被解冻。

更改帐户代码

当所有其他的失败，“不可阻挡的应用程序”以不可预测的方式运行时，使用eos.io软件的区块链允许区块生产者替换账户的代码，而无需硬分叉整个区块链。与冻结账户的过程类似，这一代码的替换需要所选区块生产者的15/21票。

宪法

EOS.IO软件使区块链能够在签署服务协议的用户之间建立对等的服务条款协议或具有约束力的合同，称为“宪法”。本宪法的内容界定了用户之间不能完全由法典强制执行的义务，并通过确立管辖权和法律选择以及其他相互接受的规则来促进争议解决。在网络上广播的每一个交易都必须将宪法的哈希作为签名的一部分，从而明确地将签名者绑定到合同中。

宪法还定义了人类可读的源代码协议。此意图用于当错误发生时识别bug和特性之间的区别，并指导社区怎样的修复才是正确或不正确的。

升级协议 & 宪法

EOS.IO软件定义了以下由协议规定的过程，该协议由范源代码及其宪法定义：

1. 区块生产者提议修改宪法并获得15/21的批准。
2. 区块生产者连续30天对新宪法保持15/21的批准。
3. 所有用户都必须表明接受新宪法是未来交易处理的一个条件。
4. 区块生产者采用对源代码的更改来反映宪法的更改，并使用新宪法的哈希值将其提交给区块链。
5. 区块生产者连续30天保持15/21对新代码的批准。
6. 对代码的更改将在7天后生效，在源代码得到批准后，所有非生产者的完整节点将在1周内升级。
7. 不升级到新代码的所有节点都会自动关闭。

按照EOS.IO软件的默认配置，更新区块链以添加新功能的过程需要2到3个月，而修复不需要更改宪法的非关键bug的更新需要1到2个月。

紧急变更

如果需要软件更改来修复有害的bug或安全漏洞，而这些漏洞或漏洞正积极地危害用户，则区块生产者可以加速该过程。一般来说，加速更新以引入新功能或者修复无害的bug可能会违反宪法。

脚本&虚拟机(Scripts & Virtual Machines)

EOS.IO软件是第一个也是最重要的一个协调已验证的消息（称为Actions）传递到帐户的平台。脚本语言和虚拟机的细节是实现特定的细节，这些细节几乎独立于EOS.IO技术的设计。任何具有确定性和适当沙盒并具有足够性能的语言或虚拟机都可以与EOS.IO软件API集成。

模式定义的消息

帐户之间发送的所有消息都由一个模式定义，该模式是区块链共识状态的一部分。此模式允许在二进制和JSON表示的消息之间进行无缝转换。

模式定义的数据库

数据库状态也使用类似的模式定义。这确保了所有应用程序存储的所有数据都是一种格式，它可以解释为人类可读的JSON，但以二进制的效率进行存储和操作。

通用多索引数据库API

开发智能合约需要定义的数据库模式来跟踪、存储和查找数据。开发人员通常需要按多个字段排序或索引相同的数据，并保持所有索引之间的一致性。

从应用中分离授权

为了最大限度地增加并行化的机会并最小化与事务日志中重新生成应用程序状态相关的计算债务，eos.io软件将验证逻辑分为三个部分：

1. 验证消息是否在内部一致；
2. 验证所有前提条件是否有效；以及
3. 修改应用程序状态。

验证消息的内部一致性是只读的，不需要访问区块链状态。这意味着它可以以最大并行度执行。验证前提条件，如所需的余额，是只读的，因此也可以从并行性中获益。只有修改应用程序状态才需要写访问权，并且必须对每个应用程序按顺序进行处理。

身份验证是验证消息是否可以被应用的只读过程。应用程序实际上正在做这项工作。两种计算都需要实时执行，但是一旦交易被包含在区块链中，就不再需要执行身份验证操作。

跨链通信

EOS.IO软件旨在促进区块链间通信。这是通过使其易于生成消息存在证明(proof of Action existence)和消息序列证明(proof of Action sequence)来实现的。这些证明与围绕消息传递而设计的应用程序架构相结合，使得区块链间通信和证明验证的细节对应用程序开发人员透明，从而能够向开发人员呈现高级别抽象。

用于轻客户端的 Merkle 证明 (LCV)

如果客户端不需要处理所有交易，那么与其他区块链集成就容易得多。毕竟，交换只关心交换的进出，而不关心更多。如果交换链可以利用轻量级的Merkle存款证明，而不必完全信任自己的区块生产者，这也是理想的选择。至少，一个链的区块生产者希望在与另一个区块链同步时保持尽可能小的开销。

LCV的目标是生成相对轻量的存在证明，任何跟踪相对轻量数据集的人都可以验证该证明。在这种情况下，目的是证明特定的交易包含在特定的区块中，并且该区块包含在特定区块链的已验证的历史中。

Bitcoin支持验证交易，是假设所有节点可以访问区块头的全部历史，这些区块头每年的数量是4MB。每秒10笔交易，一个有效的验证需要512字节。这个工作良好是对于区块生成间隔是10分钟的区块链，但是对于区块生成间隔是0.5秒的区块链就不再是“轻量级”了。

eos.io软件可以为任何在包含交易的点之后具有任何不可逆区块头的人提供轻量级的证明。使用所示的哈希链接结构，可以证明具有小于1024字节的证明的任何交易的存在。

给定区块链中的任意一个区块的区块ID，以及一个可信的不可逆区块的区块头。可以证明区块链中包含该区块。这个证明需要 ceil(log2(N)) 为其路径做摘要，其中N是链中的区块数。给定sha256摘要算法，你可以证明在一个包含1亿个区块（864字节）的链中的任何区块的存在性。

这种验证方式，使用适当的哈希链接生成区块相关联的增量开销很少，这意味着没有理由不以这种方式生成区块。

当需要验证其他链上的证明时，可以进行各种时间/空间/带宽上的优化。跟踪所有区块头(420 MB/年)将保持证明尺寸小。只跟踪最近的区块头可以在最小的长期存储和证明大小之间进行权衡。或者，区块链可以使用一种懒惰的评估方法，在这种方法中，它可以记住过去证明的中间散列。新的证明只需要将链接包含到已知的稀疏树。所使用的确切方法必须取决于包含Merkle Proof引用的交易的外国区块的百分比。

在一定密度的互连之后，简单地让一个链包含另一个链的整个区块历史，并消除对所有证明的需要，就变得更有效了。出于性能方面的考虑，最理想的方法是最小化链间证明的频率。

跨链通信的延时

当与另一个外部区块链通信时，区块生产者必须等到100%确定某个交易已被另一个区块链不可撤销地确认后，才能接受它作为有效输入。使用基于eos.io软件的区块链和具有0.5秒区块的DPOS，加上拜占庭容错不可逆性，这大约需要0.5秒。如果任何一个链的区块生产者不等待不可逆性，这就像一个交易所贷记一笔存款，该存款随后被撤销，并可能影响区块链共识的有效性。eos.io软件同时使用DPOS和aBFT来提供快速的不可逆性。

完备性证明

当从外部区块链使用Merkle证明时，在知道所有处理的交易都是有效的和知道没有跳过或忽略任何交易之间存在显著差异。虽然不可能证明所有最近的交易都是已知的，但可以证明交易历史中没有任何空白。eos.io软件通过为发送给每个帐户的每个消息分配一个序列号来促进这一点。用户可以使用这些序列号来证明针对特定帐户的所有消息都已处理，并且已按顺序处理。

隔离见证

隔离见证（segwit）的概念是，在区块链中永久包含交易后，交易签名不相关。一旦它是不可变的，就可以修剪签名数据，其他人仍然可以派生当前状态。由于签名占大多数交易的很大比例，因此Segwit可以显著节省磁盘使用量和同步时间。

同样的概念也适用于用于区块链间通信的Merkle证明。一旦一个证明被接受并不可逆转地记录到区块链中，证明所使用的2KB的sha256哈希就不再需要得到正确的区块链状态。在区块链间通信的情况下，这一节省是普通签名节省的32倍。

Segwit的另一个例子是Steem博客文章。在这种模式下，一篇文章将只包含sha256（博客内容），而博客内容将在隔离的见证数据中。区块生产者将验证内容是否存在并具有给定的哈希值，但为了从区块链日志中恢复当前状态是不需要存储博客内容的。这可以证明内容曾经是已知的，而不必永远存储所述内容。

总结

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