EOS.IO 技术白皮书（翻译）
声明
准备研究EOS，正好把他翻译一下，加深理解。第一次翻译东西，虽然修订了一版，估计有些地方翻译不对，或者不到位，请大家谅解，欢迎批评指正。
欢迎转载，只需注明出处即可。
terryc007
2017.9.20-9.25
概要
EOS.IO软件引入了一种区块链架构。 它为满足去中心应用纵向，横向扩展需求而设计。它通过一个可以在上面构建应用程序，类似操作系统的方式来实现。 该软件提供了账号，身份认证，数据库，异步通信，以及跨多核CPU或集群调度应用程序等功能。 由此而形成一种区块链架构， 它能达到每秒百万交易量的处理，用户可免费使用，且很容易快速部署去中心化应用。
注意
在本技术白皮书中所说的加密代币指的是采用EOS.IO软件，且正式上线的区块链上的加密代币。 跟在Ethereum上众筹来的兼容ERC-20的EOS代币是不一样的。
Copyright © 2017 block.one
只要注明来源以及版权归属，对于非商业，教育用途（除了卖钱，或者其他商业用途）的，任何人可在不需通过授权的情况下，使用，复制，分发本技术白皮书中任何相关的信息。
免责声明
EOS.IO技术白皮书仅仅是一个资料文档，Block.one不保证准确的实现白皮书中的结论。本白皮书基于“视为事实”。Block.one不会提供以及拒绝所有的，明确的，隐性的，法规，或其他代表，担保，但不限于(i) 商业担保，基于特定用途的适配性，适用性，用途，权利或者非侵权性。 (ii) 白皮书中的内容是无误差的。 (iii)白皮书的内容不侵犯第三方版权的。 Block.one 以及其隶属机构由于使用本白皮书中任何内容而造成的损失，不承担任何责任。即使在白皮中有告知会造成这种损失的可能的情况下。 Block.one或其隶属机构对任何人，企业因使用，引用，或依赖本白皮书或其中的任何内容，而造的任何直接的，间接的，后续的，偶然的，赔偿性的，实际的，惩戒性的，惩罚性的，特定的损害，损失，债务，花费，费用，包括并不限于任何的商业，收入，盈利，数据，用途，商誉，以及其他无形的损失，绝不承担责任。
背景
在2008年，随着比特币的发行，区块链技术被引进。随后，企业，开发者为了区块链技术获得更为广泛的应用，他们不断地尝试让区块链技术更加通用。
目前一些区块链平台已经可以支持一些功能性的去中心化的应用和应用区块链。比如像BitShare去中心化交易所（2014），Steem社交平台（2016）已经有成千上万的活跃用户在大量使用的区块链平台。他们通过提升每秒上千比交易的处理性能，把延迟减少到1.5秒，用户不需要发钱，同时提供了跟现有中心化服务类似的用户体验来实现这些目标。
已有的区块链平台受制于大量的交易费，有限的算力，以至于妨碍了区块链的大规模使用。
区块链应用要求
区块链要获得广泛的使用，区块链平台要有足够灵活以满足应用的需求，需满足以下的要求：
支持百万级别的用户
像Eaby，Uber，Airbnb，Facebook这种分散商业模式要求区块链技术有处理千万级别日活用户的能力。 在某些特定的情况下，应用可能无法工作除非用户数达到一个临界点。 因此对于一个区块链平台，能够处理大量用户是非常重要的。
免费使用
应用开发者需要有为用户提供免费服务的灵活性，用户在使用或者得益于平台时，可以不用付费。 一个让用户可以免费使用的区块链平台才会获得更为广泛的使用。开发者跟企业通过构建有效的商业策略来实现盈利。
易于升级和Bug修复
基于应用构建的商业区块链，在为应用增加功能时候，具有一定的灵活性。
所有重要的软件即使经过最严格的正式检验，也会有bug。 因此在bug不可避免的出现的时候，平台须有足够的健壮性以方便去修复它们。
低延时
良好的用户体验要求可靠及时的反馈，通常应在几秒延时之内。如果延时比这还长，会让用户有挫败感，那么构建在区块链上的应用跟现有的非区块链应用相比，就缺乏竞争力。
串行性能
一些应用程序由于算法步骤是串行依赖的，所以它就无法实现并行算法。像交易这种应用为了处理大量的交易，就需要足够的串行处理量。因此对于一个台而言，快速串行处理性能是必须的。
并发性能
大规模的应用需要把任务分割，在多个cpu，计算机上运行。
共识算法(DPOS)
EOS.IO 软件使用目前唯一一个去中心化的，可满足区块链应用性能需求的共识算法： 委托权益证明（DPOS）. 在该共识算法下，在采用EOS.IO软件的区块链上，那些持有代币的人可以通过了一个连续的赞成投票系统来选择矿工。任何人可以选择参与挖矿，并有机会获得其相应比例的区块奖励，而这是跟其获得票数与其他所有矿工所获得票数成比例。对于私有链，管理人员可以使用代币来添加，删除IT部门的员工。
在任何时候，EOS.IO 软件能让一个授权的矿工，每3秒挖出一个区块。如果在预定时间内，区块没有被挖出，那么这个时间段的区块就被忽略掉。当一个或更多的区块被忽略掉，那么区块链上就会出现6秒或更多的时间空隙。
使用EOS.IO软件时，通过21个矿工轮流来挖矿。在每轮开始之前，会选21个单独的矿工。在每一轮，票数最高的前20名会自动被选择，最后一个则是按其获得票数的相对于其他区块生成者获票数的比例来选取。这些矿工是通过基于区块时间的伪随机数被随机选中的。这样保证了所有矿工之间连接的稳定。
如果矿工丢失了一个区块，并且在最近的24小时之内没有挖出过区块，根据情况，他们会被从挖矿队伍中移除，直到通知区块链，他们想再挖矿为止。通过过滤掉那些被证明是不可靠的矿工，从而最小化区块的丢失，从而保证整个区块链网络流畅地运行。
基于DPOS的区块链通常不会产生分叉，因为矿工是通过合作而非竞争来挖矿的。万一出现分叉，共识会让整个区块网络自动切换到最长的链。这之所以可以工作是因为往分叉链上增加区块的速度直接取决于遵守同一个共识的矿工所占的比例。也就是说，矿工越多的分叉链会变的更长。此外，一个矿工不可能在同一时间在两个分叉链上去挖矿。如果一旦发现矿工这么做，它很有可能被投票出局。像双发这样的加密证据可以用来自动删除那些滥用区块链者。
交易确认
通常DPOS区块链100%有矿工参与。一个交易从广播起，平均1.5秒就可以被99.9%被确认。
但也有一些特殊的情况，比如软件bug，网络拥堵，或者恶意矿工创建2个或2个以上的分叉。 为了确保交易是不可逆的，节点可以等待21个矿工中15个确认即可。 基于EOS.IO典型配置，在通常情况下，一个交易被确认平均需要45秒。在默认情况下，所以的节点会认为只要区块被21个矿工中的15个确认，区块就是不可逆的。同时矿工也不会切换到一个不有包含这个区块的分叉链上，不管这个分叉有多长。
用户在切换到一个分叉前9秒内，如发现他们很有可能在一个非主链上，节点是有可能去提醒用户。如果一个节点连续错过了两个区块，那么它有95%的概率是在非主链上。 如果连错过过3个区块，那就有99%的概率。我们可以通过利用丢失节点，最近节点参与的比例，以及其他因数等信息来构建一个健壮的预测模型，来快速警告操作者出现问题了。
如何应对这些警告，要根据业务性质而定。但最简单的做法就是等待15/21个确认直到警告停止。
权益证明交易（TaPoS）
EOS.IO的要求每一个交易都包含了最近一个区块头的Hash值。这个Hash有两个用途：
- 防止在不包交易中引用的区块的分叉链上对该交易进行重放
- 告诉区块网络一个特定的用户以及他们的权益在一个特定的分叉链上。
随着时间的推移，所有的用户会直接确认区块链。这使得伪造一个假的区块链变的很困难，因为无法从合法区块链中的交易迁移到伪造的区块链上来。
账号
EOS.IO允许所有的账号通过便于人类阅读的，由2~ 32字符组成的名字来关联。账号的名字由账号的创建者来选择。所有的账号在创建的时必须存入一笔很少的资金以支付存储账号数据的费用。账号名字也支持名字空间。比如账号的拥有者@domain是唯一可以创建@user.domain账号的人。
在一个去中心化的环境，应用程序开发者将会支付，因创建新注册用户而产生的正常费用。传统的商业比如通过广告，免费服务等形式获取用户，并在获取每个用户上发了大量的资金。相比于传统商业，在一个区块链创建账号获取一个新的用户上，成本几乎是很少的。好在，如果一个用户已经在别的应用程序已经注册了，就再不用创建另外一个新的账号。也就是说，在一个采用EOS.IO软件的区块链上，只需要一个账号就可以使用所有的应用。
消息&处理器
每个账号可以发送结构化消息给其他账号，当收到消息时，可以自定义脚本来处理它们。每个账号有一个自己私有的数据库，只有账号自己的消息处理器才能访问它。消息处理脚本也可以给其他账号发送消息。消息以及自动消息处理器组合就是EOS.IO如何定义智能合约的。
基于角色的权限管理
权限管理涉及到判断一个消息是否是被正确授权。最简单的权限管理方式是检查交易是否包含必须的签名。但是这就意味着这个签名是已知的。通常，权限跟个人或者个人分组绑定，同时常常又被划分开来。EOS.IO软件提供了一个声明性权限管理系统，用户可以通过更好的粒度，更高的级别的控制，来决定谁可以做什么，什么时候做。
用户身份验证和权限管理实现标准化并从应用业务逻辑中分离出来非常重要。 这样权限管理工具可以用通用的方式来开发。同时为优化工具性能提供了更多空间。
每个帐户都可以通过其他帐户和私钥的加权组合来控制。这样可以实现一个跟现实权限很像的层次化权利结构。 这使得多个用户控制资金比起之前要容易的多。对于安全而言，多用户控制起着非常大的作用。如果使用得当，它会极大的减少被黑失窃的风险。
EOS.IO软件允许账号定义哪些私钥的组合或者用户可以发送特定的消息类型给其他账号。比如，一个私钥赋予一个社交账号用于社交，另外一个私钥可用于访问交易。甚至在不需要赋予其他账号私钥的情况下，给予其他账号权限，来使用我们的账号。
命名权限等级
在EOS.IO软件中， 账号可以定义命名权限等级。 每个权限可以继承高级别的命名权限。每个命名权限定义了一个权力，每一个权力是一个阀值多重签名校验，包含了其他账号的私钥和（或者）命名权限等级。 比如，一个设置了”Friend“权限等级的账号，这个账号的任何朋友可以控制像这个账号一样控制这个账号。
另外一个例子是，Steem区块链有3个硬编码的命名权限等级：拥有者，活跃，发帖。 发帖权限只可以做一些社交操作，比如投票，发帖。 而活跃权限可以做任何事情除了改变账号的拥有者。拥有者权限可以做任何事情，不过注定要被冷藏起来，因为通常我们用不到。EOS.IO软件让每个账号的持有者不但可以定义自己的权限层级，还可以对动作进行分组。
命名消息处理器组
EOS.IO允许每个账号可以通过命名，嵌套组来管理自己的消息处理器。当其他账号配置他们的权限等级的时候，可以引用这些命名消息处理组。
最高级别的消息处理器组是账号名字，最低级别的是账号所收到个私人消息类型。这些组可以这样的方式来引用： @accountname.groupa.subgroupb.MessageType.
在这种模型下，对于一个交易合约，实现把订单创建，取消从存款，取款中分离进行分组是可能的。交易合约的这种分组方式对于用户之间的交易是很方便的。
权限映射
EOS.IO软件允许每个账户可以定义任何账号的命名消息处理组跟他们自己的命名权限等级之间的映射。例如，账号持有者可以把账号的社交应用程序映射到账号持有者的”Friend“权限组。通过这样的映射，任何该账号的朋友可以像该账号一样在该账号社交应用上发帖， 但仍然需要使用他们自己的公钥来签名消息。 这就意味着我们总是可以确定是哪些朋友使用这个账号，他们以什么样的方式使用的。
权限评估
当从@alice给@bob发送”Action“类型的消息时，EOS.IO首先会检查@alice是否为 @bod.groupa.subgroup.Action定义了权限映射. 如果没有，再检查 @bod.groupa.subgroup映射, 然后@bod.groupa映射, 最后@bod。如果还没有找到任何匹配的，将会映射到假定的命名权限组@alice.active。
一旦映射被确认，然后使用阈值多重签名程序验证签名授权的有效性，最后授权会被关联到命名权限。 如果失败，就上溯到父权限，直到拥有者权限， @alice.owner.
默认权限组
EOS.IO为所有的账号内置了一个可以做任何操作的”拥有者“组，一个做任何操作除了更改”拥有者“组的”活跃“组。其他所有的权限组都从”活跃“组继承。
权限并行评估
权限评估程序是只读的，在一个区块结束后，交易对权限所做的修改直才会生效。这意味着所有交易的密钥跟权限评估可并发执行。此外，在不需要启动那些需要回滚操作的耗时应用逻辑的情况下，实现快速权限有效性的验证是可行的。最后，对于收到的，且在暂停状态的交易，可以进行权限评估，在交易被执行时，就不需要再重新评估。
总而言之，在交易有效性验证的计算量中，权限验占了很大一部分。把权限评估程序设置成只读的，可并发执行的，可极大的提升性能。
在重放区块链时，从消息日志中重新恢复确定性状态时，不需要重新评估权限。事实上，对于已知有效区块的交易，完全可以省掉权限评估这个环节。当对不断增长的区块链进行重放时，这会极大地减少计算负载。
强制延时消息
对于安全而言，时间是非常重要的。在大多数情况，不可能知道私钥是否被盗，直到被发现它盗用。 人们每日使用应用访问互联网，但这些应用的密钥又要被保存在本地电脑上时，基于时间的安全接显得格外重要。EOS.IO软件可以让应用开发者设定特定的消息，使得在交易被打包到区块时，交易执行前，需等待一个最少的时间。这个等待期间，这些消息是可以取消的。
从被盗密钥恢复
在用户的密钥被盗之后，EOS.IO软件为用户提供了一个办法来恢复对其账户的控制。 账号的拥有者可以从指定的账号恢复合作方获取密钥，在该密钥有限的30天内，可使用该密钥来重置该账号的拥有者密钥。该账号的恢复合作方在没有该账号的拥有者的帮助下是不能控制账号的。
当黑客在恢复的过程中试图获取东西时，他们其实什么也获取不到。因为他们实际已经”控制“了账号。此外，如果黑客进入恢复过程时，恢复合作方可能会需要进行身份证明，多方面进行认证（电话，email）。这可能会让黑客放弃或者毫无所获。
这种恢复被盗账号过程跟简单的多重签名是有很大区别的，对于一个多重签名的交易，有一个公司是每笔已执行交易的当事人，但是对于恢复过程而言，对于恢复流程而言，这个代理是唯一的当事人，它没有能力去处理日常所有的交易。这样极大的减少了相关人的费用，合法债务。
9.24 7：31am
应用的确定性并行执行
区块链共识依赖于确定性（可复现）行为。这也就是说所有的并发执行必须可以自由使用互斥变量或其他原子类同步锁。如果没有同步锁，那也必须有办法保证所有的账号只能读写自己的私人数据库。也就意味着每个账号需要以串行的方式来处理消息，在账号级别上进行并发处理。
在基于EOS.IO的区块链上，矿工负责把消息组织并分发到独立的线程进行并行处理。 每个账号的状态仅依赖于发送给它的消息。矿工会输出调度任务，这些任务会按确定的顺序执行，但是生成调度任务的过程是无序的，不确定的。这就意味着矿工可以利用并行算法去调度交易。
部分并发执行指的是，当一个脚本生成一个新的消息时，它并不是立即被发送，而是在下一个循环才被发送。之所以不能立即发消息分发出去是因为消息接受者可能在另外一个线程修改它自己的状态。
最小化通信延迟
延迟指的是从一个账号发送消息到另外一个账号，以及收到回应所花的时间。我们的目标就是让两个账号来回交换消息在同一个区块进行，并在3秒内完成。 为实现这个功能，EOS.IO把每个区块分成多个周期。 每个周期被分成多个线程，每个线程包含一个交易列表。每个交易包含了一些要被分发的消息。这个结构可被可视化为一个树结构。这些交替的层会以并发的方式被串行的处理。
Block
Cycles (sequential)
Threads (parallel)
Transactions (sequential)
Messages (sequential)
Receiver and Notified Accounts (parallel)
在一个周期里面产生的交易可以在后续任何的周期或者区块进行分发。矿工会不断的给一个区块添加周期直到最大的设定时间用完，或者直到没有新的可分发的交易为止。通过对一个区块的静态分析来验证，在一个周期里面，不会存在包含交易的两个线程修改同一个账号是可能的。 只要保持不变，就可以通过运行所有并发线程来处理区块。
只读消息处理器
一些账号可以在不修改他们内部状态的情况下，可以基于成功或失败的情况，来处理消息。在这种情况下，只要在一个特定的周期里，特定的账号的只读消息处理器被包含在一个或多个线程里面，这些消息处理器可以并发执行。
多个账号间原子交易
有时候我们需要在多个账号之间保证消息的收发操作的原子性。在这种情况下，双方的消息需要放到同一个交易里面，同时双方账号需分配到同一线程，并且消息被串行执行。这种情形从性能上讲并不完美。当需要支付费用的时，交易中所涉及的各个独立账号都需要支付费用。
从性能和开销上考虑，在频繁使用的2个或多个账号之间，最好减少进行原子操作。
区块链状态局部评估
规模化的区块链需要组件模块化。每个人没有必要运行所有东西，特别当他们只使用很少部分应用的时候。
对于一个交易应用开发者而言，运行所有节点是为了把交易状态显示给出它的用户。这个交易应用根本不需要社交媒体应用的状态。EOS.IO允许任何全节点可选择部分应用来运行。如果消息发送给没有运行应用程序，会被安全的忽略掉，因为一个应用程序的状态完全取决于发送给出它的消息。
在跟其他账号通信的的时候，还有一些重要的隐含信息。其中最为重要的是不能假定在同一机器上的其他账号的状态是可以访问的。这也就是说当另外一个账号不在内存时，尝试开启允许一个账号同步调用另外一个账号锁，会让这个设计模式失效。
在区块链中，账号之间所有状态通信必须通过传递消息来完成。
主动最优调度
EOS.IO不能强制矿工发送任何消息给其他任何账号。每个区块生成者可以自己测量计算的复杂性，处理交易所需时间。不管是用户自己产生的交易，还是脚本产生的都适用。
对于已发布的采用EOS.IO软件的区块链，从网络级来看，所有的交易都会被收取固定的计算宽带费用，不管是花了0.010毫秒，还是10毫秒的计算时间。然而，对于使用EOS.IO软件的每个矿工，可以使用自己的算法，度量来计算资源的使用情况。 当矿工在生产区块时，如果判断一个交易或者账号消耗了不成比例的计算资源，他们可简单的拒绝这个交易加入它的区块。 但是如果其他矿工认为交易是有效的，该矿工仍然会处理该交易。
通常只要一个矿工认为一个交易是有效的，同时交易对资源的消耗并没有超过可用资源的上限，那么其他矿工会认为交易也是有效的。但是要找到确认该交易的矿工，可能需要1分钟的时间。
在一些情况下，矿工可能创建一个区块包含超出可容纳交易数目的交易。在这种情况下，下一个矿工可以选择拒绝这个区块，这个需要通过第三个矿工来打破这个僵局。 这个跟一个大块导致整个网络变的拥堵没什么两样。社区可以检测到这种滥用模式，最后可以删除恶意矿工的票数。
这种主动评估计算开销的方式把区块链从精确地计算交易要花多少时间中解放出来。这种设计下，就没有必要去精确的去统计在遵守共识的情况下，有多少指令提升了优化空间。
代币模型和资源使用
所有的区块链的资源都会受到约束，同时需要一个系统来防止资源被滥用。对于采用EOS.IO软件的区块链，应用会消耗三大类资源：
- 带宽跟日志存储空间（硬盘）
- 算力以及待计算的事务（CPU）
- 状态存储空间（内存）
带宽跟计算有两个部分，一个是即时使用，一个是长时间使用。区块链会保存所有消息的日志，这个日志了最终会被所有的全节点下载并存储。通过消息日志可以重建所有应用程序的状态。
计算债务指的是那些，需要从消息日志中重建状态的所需要的计算。 如果计算债务增长的太大，那就很有必要对区块链的状态做一个快照，并丢掉区块链的历史快照。 如果可计算债务增长的太快，那么这就需要发6个月时间去重放1年内交易。因此，小心对待计算债务是很关键的。
区块链状态存储是应用程序逻辑可以访问的信息。它包括了交易订单，账号余额。如果状态信息从未被使用过，它就不应保存。比如，博客发送内容，评论的状态是不会被应用逻辑读取，因此他们就不应该保存到区块链状态里面。 同时，已有的帖子，评论，投票数，以及其他属性需要作为区块链状态的一部分保存起来。
矿工会公布他们可用的带宽，计算量，以及状态存储空间。 EOS.IO软件允许每个账号可以根据其在3-day押金合约里面所持有代币的比例消耗对应比例的可用资源量。比如，对于采EOS.IO已上线的区块链，如果账号持有这个区块链可代币总量的1%，那么这个账号就有可能使用1%的状态存储空间。
对于采用EOS.IO已正式发布的区块链，带宽，计算量的分配是基于部分预留的策略。因为他们是即时的（为被使用的容量并不可以保存下来留着以后用）。这个算法跟Steem中的”带宽使用限制“算法类似。
客观跟主动测量
如前面所述，对计算使用情况进行测量会给性能，优化带来很大的影响。因此，所有的资源的使用限制情况，最终是由矿工根据他们自己的算法，判断来完成。
这就是说，有一些琐碎的东西是需要客观测量的。 发送的消息数量，在内部数据库中存储的数据大小测量起来会很廉价。EOS.IO允许矿工在这些客观的测量上应用同样的算法。但在主观的测量上，可以选择使用更为严格的主观算法。
接受者支付
在传统中，需要支付办场地，计算电力，以及其他费用来运作商业。消费者从企业购买特定的商品，企业卖掉的商品赚取收入，然后支付商业运营费用。同样，没有网站会强制访问者交一笔钱去支付维护网站的费用。因此，去中心化的应用不应该强迫消费者在使用区块链的时候直接给区块链支付费用。
在采用的EOS.IO软件的区块链的用户，在使用区块链的时，是不需要直接给区块链支付费用的。因此使用EOS.IO软件的企业，在为用户提供服务的时候，可根据自己的情况，采用不同的货币化策略来实现盈利。
委托容量
在采用EOS.IO的区块链上，持有代币的人不一定会立即使用所有或部分的带宽，他们可以送给或者出租这些未被消耗的带宽给其他人。矿工会发现这些带宽委托，并分配相应的带宽。
代币价值跟交易费用分离
EOS.IO软件一个主要的优点在于，对于应用程序可用的带宽是完全独立于代币的价格的。在采用EOS.IO软件的区块链上，如果一个应用的所有者持有相关数量的代币，那么这个应用就可以一直使用固定的状态存储空间，固定的带宽。 这样，开发者，用户就不会被市场上代币价格的影响。因此也就不依赖于代币的价格。换句话说，对于采用EOS.IO软件的区块链，矿工可不需要考虑代币的价值，就能轻而易举的为每个代币增加可用的带宽，算力，存储空间。
在采用EOS.IO软件的区块链，矿工每挖出一个区块，系统就会奖励矿工代币。代币的价值了会直接影响到矿工可购买带宽，存储空间，算力的数量。这个模型了轻松地利用代币的升值来提升网络的性能。
状态存储费用
虽然带宽跟算力可以委托，但应用状态的存储需要一个应用开发者持有代币，直到应用的状态被删除。如果状态一直没被删除，那么这些代币会从发行量中被有效的删除。
每个账号需要一定数量的存储空间，因此，每个账号里面必须要保留最少量的代币。当随着网络的存储容量增加，需要的代币数量会减少。
区块奖励
在采用EOS.IO软件的区块链，矿工每挖出一个区块，就会被奖励一些代币。在这样的情况下，奖励的代币数目是所有矿工期望支付的中间值。EOS.IO软件可以配置每个区块奖励的上限，以实现每年代币的增发不会超过总量的5%。
有益于社区的应用
采用EOS.IO软件的区块链，用户除了选举矿工，还可以选举3个有益于社区的应用（智能合约）。在每年增发的代币中，会设置其一定比例的代币（可配置），先扣除已支付给矿工代币后，再分配给这3个应用。然后根据每个应用从代币持有者获得的票数，会获得相对应比例的代币。 这些被选出来的应用或智能合约是可以被代币持有者新选出的应用或智能合约替换掉。
管理
管理是大家在一些主观事情上达成共识的的一个过程，仅靠算法是远远不够的。一个基于EOS.IO软件的区块链实现了一个管理流程可以有效地引导矿工。之前的区块链缺乏清晰的管理流程，依赖于自治的，非正式的，通常是有争议的管理流程，导致了不可预知的结果。
基于EOS.IO的区块链承认那些把权利委托给矿工的代币持有者的权利。矿工被赋予有限的，被验证过的权利去冻结账户，更新有缺陷应用，对底层协议提出硬分叉提议。
矿工选举被嵌入在EOS.IO软件里面。在对区块链进行更改之前必须通过这些矿工的批准。如果矿工拒绝执行代币持有者所希望的更改，矿工可被投票出局。如果矿工在没有获得代币持有者授权的情况下执行更改操作，那么其他非挖矿全节点验证器（如交易所）会拒绝这一更改。
冻结账户
有时候智能合约的行为看起来异常，或者出现不可预测的行为，没有按预期方向的执行。还有时候一个应用或者一个账号可能出现消耗不合理的数量资源的漏洞，但出现这些情况不可避免的发生时，矿工有权利去修正这些问题。
区块链上所有的矿工有权利选择哪些交易可以打包到区块，哪些给予他们冻结账户的能力。使用EOS.IO软件的区块链，通过基于活跃矿工的17/21票数来冻结一个账号。如果矿工滥用这个权利，他们可以被投票出局，同时被冻结的账号被解冻。
更改账号代码
当一个”不可停止的应用“出现不可预测的行为时，经过其他所有尝试之后，仍然无法解决问题时，使用EOS.IO软件的区块链可以在不硬分叉的情况下，允许矿工替换账号的代码。类似冻结账号的流程，替换账号代码需要获得所有选举出来的矿工17/12的投票数。
章程
EOS.IO能够让区块链建立一个端对端的服务使用协议，或者一个跟用户绑定的，签名的合约，这就是所说的”章程“。章程的内容定义了用户之间的义务，通过建立一个管辖机构，以及选择一些彼此可接受的法律，来解决在用户之间，那些不能完全通过代码解决的争议。每个在网络上广播的交易必须包含章程的Hash值，使得它成为签名的一部分。从而明确的把签名者绑定到合约上。
章程也定义了源码协议的易用阅读的意图。在错误发生时，这种意图用来区分bug跟功能，以及指导社区什么样的修正是合适的。
升级协议跟章程
通过标准代码，章程定义的协议，EOS.IO软件定义了一个可以更新的流程。流程如下：
- 矿工提交一个修改提议给章程，并获得17/21投票批准。
- 矿工保证17/21投票批准持续30天。
- 所有用户要求使用新的章程给交易签名。
- 矿工通过接纳源代码的更改来表示章程的改变。同时区块链生产者使用git commit的hash值把章程提议到区块链。
- 矿工保证17/21投票批准持续30天。
- 代码更改生效后7天，源代码批准后，所有全节点有1周的时间去更新这些源代码。
- 所有没有更新到最新代码的节点会自动被关掉。
在EOS.IO软件默认配置下，给区块链添加新的功能大约需要2到3个月，而对于解决一些不需要更改章程的不重要的bug时，更新区块链需要1到2个月。
紧急更改
对于需要修复一个有害的bug或者损害用户利益的安全漏洞，需要修改软件时候，矿工可以加速这个修复过程。 一般而言，为了新增功能或者解决有害bug而加速代码更新能是可以违反章程。
脚本跟虚拟机
EOS.IO软件将会是第一个也是最重要的一个可支持协调账号之间授权消息的分发的平台。脚本语言，虚拟机的具体实现几乎是独立于EOS.IO技术的。任何确定性语言，确定性虚拟机，以及有足够性能保证的沙盒都可以集成EOS.IO API.
模式定义消息
账号之间所有的消息的发送是通过一个模式来定义的。这作为区块链共识状态的一部分。这个模式允许消息在二进制与JSON格式之间无缝的转换。
模式定义数据库
数据库状态也是使用类似的模式来定义的。 这保证了所有应用程序保存的数据以一种即可以方便阅读的JSON格式来解读，又使用有效的二进制格式来存储这些数据。
从应用中分离认证
为了从交易日志重构应用程序的状态时，最大化并发处理，以及最小化计算债务，EOS.IO软件把校验逻辑分成了3个部分：
- 校验消息内部的一致性
- 校验所有前置条件有效
- 修改应用状态
验证消息内部的一致性是一个只读操作，同时不需要访问区块链的状态。这就意味着它可以最大化的并发处理。前置条件校验，比如要求的余额，是只读的，因此也可以采用并行处理。只要修改应用状态时才需要写操作，并以串行方式来处理。
认证就是验证一个消息是否能够被应用的只读的过程。应用实际上就在做这个事情。两个计算会实时的被执行，然而一旦交易被写入区块链，就再也不需要进行认证。
虚拟机独立架构
让区块链支持多个虚拟机，同时随着时间的推移新的虚拟机也可以加进来是EOS.IO软件的目标。 因为这个原因，本白皮书不会讨论任何特定语言或虚拟机的具体细节。也就是说，对于EOS.IO软件区块链，当前有两种虚拟机可被评估。
Web Assembly (WASM)
Web Assembly是一个嵌入web的标准的虚拟机，为创建高性能的web应用而生。只要对Web Assembly做很小的改动就可以实现确定性，沙盒化。Web Assembly的优势在于有很多企业的支持，同时了可以使用熟悉的语言，比如c或者c++来开发合约。
以太坊的开发者已经开始在他们的以太坊风格的WASM上，对WASM进行修改以实现适当的沙盒化，确定性。这种方法可以很容易的集成到EOS.IO软件。
以太坊虚拟机（EVM）
目前大部分智能合约使用以太坊虚拟机来执行。以太坊虚拟机也可以在EOS.IO区块链上工作。 可以想象在EOS.IO区块链上，EVM合约可以运行在自己的沙盒中。同时对EVM合约做一些改编就可以跟EOS.IO上其他应用通信。
区块链内部通信
EOS.IO的设计使得区块链内通信更加便利。这是通过让消息存在的证明，消息队列的证明变的更简单来实现的。 围绕消息传达而设计的应用架构跟证明的组合，使得内部通信跟证明验证的内部细节，相对于应用开发者而言是不可见的。
轻验证客户端(LVC)的默克尔证明
如果客户端不需要处理所有的交易，集成其他区块链就会更容易。毕竟，对于一个交易只关心交易的输入跟输出，再无其他。如果交易链能够利用存款的轻量默克尔证明，而完全不用信任自己的矿工，那就完美了。 当跟其他区块链同步时，至少区块链上的矿工愿意花最少的钱。
轻验证客户端的目标是让相对的轻量存在证明的生成，可被任何跟踪相对轻量数据集的用户验证。在这种情况下，目标就是证明一个特定的交易被一个特定的区块包含，同时这个区块已经被记录在特定区块链的验证历史记录里面。
比特币交易验证，它假设所有的节点可以访问所有历史区块头，每年有4MB区块头产生。每秒10比交易，一个有效证明需要512个字节。这种交易验证对于每10分钟挖出一个区块的区块链而言是可以工作的，但是对于每秒挖出3个区块的区块链就无法适用了。
在EOS.IO软件中，在交易被包含进区块后，对于任何人，如果有不可逆区块头，就可允许轻量证明。 使用下面的hash-linked结构，用少于1024字节的证明就可以证明交易的存在。 如果假设验证节点保留了过去所有区块头（2MB数据大小），那么要证明这些交易是否存在只需增加200字节。
在区块生产增加一点开销，以及合适的Hash-link可以让这些证明没有理由不按这样的方式生成区块。
对其他区块链的证明进行验证时，在时间，空间，带宽上有很大的优化空间。跟踪所有区块头（每年以420MB的速度增长）会使证明所需的大小很小。跟踪最近的区块头能够在最小化长期存储大小跟证明大小上提供一个平衡点。或者，区块链可以使用一种延迟评估的方法，它可以记住过去证明的中间Hash值。新的证明仅需要把链接包含到已知的稀疏树。所使用的确切方法取决于包含被默克尔证明引用交易的外部区块所占的比例。
通过区块链之间一定程度的关联，使得在简化一个区块链包含另外一个区块链的历史记录，以及消除对证明的需求变的更加有效。从性能上讲，减少链之间的证明的频率是一个好的办法。
链间通信延迟
当跟外部另外一个区块链通信时，在把交易当作一个有效的输入前，矿工必须等待交易100%的被外部区块链确认为止。使用基于EOS.IO的区块链， 能3秒出一个区块，由21个矿工参与的DPOS共识，完成一次外部交易有效的确认大约需要45秒的时间。如果一个区块链的区块生产者不等待不可逆确认，那么它就像接收一个会被撤销的存款交易。这会对区块链的共识的有效性产生影响。
完备性证明
在外部区块链使用默克尔证明时候，知道所有处理过的交易是有效的跟知道没有交易被忽略掉或者遗漏掉是有很大区别的。 然而要证明最近所有的已知的交易是不可能的，但去证明交易历史里面是否有遗漏是有可能的。EOS.IO软件通过给发送给每个账号的消息赋予一个序列号来方便实现这个目的。用户可以使用这些序列号去证明特定账号所有的消息是否已经被处理了，是非被有序的处理了。
结论
EOS.IO软件代表了区块链基础技术的进步。它的设计来自于被已经证明的概念和最佳的实践。它是全球化的，规模化区块链社区蓝图中的一个部分，它使得去中心化应用的部署，管理更加容易。