作者：Daniel Larimer

翻译：IMEOS

距离 block.one 发布 EOSIO Dawn 3.0已经一个月了。 在过去的一个月里，我们的团队一直专注在EOSIO软件的优化和稳定性，这其中很大一部分工作是在证明链间通信的可行性。

不将merge操作计算在内，共有43位开发者提交818个commit到项目的github仓库。 这让EOSIO成为过去一个月中github中最活跃的8个C++项目之一。 正如你所看到的，许多事情正在发生。

时间一致性|Now is now Now

EOSIO Dawn 4.0最大的变化之一是我们已将当前时间的定义从“头块的时间”改为“当前区块的时间”。 这种变化使得大量包含时间操作的案例可以在存在缺失区块的情况下执行，并且更精确地计算智能合约的运行时间。

新的内存分配模型|RAM Allocation Model

测试中我们发现了EOSIO系统合同分配RAM(数据库空间)的方式会导致未来资源的短缺。我们改用了一种基于市场的分配方法，使用Bancor算法。

我们的计算表明，如果1TB RAM按比例分配给token持有者，那么每字节的成本将是0.018美元(假设每个token20美元)。事实上，大多数token持有者实际上并不需要使用他们可能拥有的RAM；因此，我们最初对RAM的定价是每字节0.000018美元(假设每个token20美元)。创建一个新帐户需要大约4KB的RAM，这意味着将花费约0.10美元。随着RAM被分配，价格会自动增加，这样在系统耗尽RAM之前价格就会接近无穷大。

在Dawn 3.0系统合约中，您只能以您支付的价格出售RAM。 目的是抑制囤积和投机。 这种方法的缺点那些廉价购买RAM的人在RAM变得更紧缺后，没有为其他用户腾出RAM的经济激励。在Dawn 4.0之下，系统合约现在以当前市场价格购买和销售RAM分配。 这可能会导致交易商在预计明天可能出现短缺的情况下购买RAM。 总的来说，这将导致市场随着时间的推移平衡RAM的供需。

随着时间的推移，摩尔定律将允许超级节点升级到4TB甚至16TB的内存，并且这种供应增长将逐渐降低EOSIO RAM市场价格。

对智能合约开发者的影响|Implications for Smart Contract Developers

作为一名智能合约开发者，RAM是一项宝贵的资源，数据库记录需要消耗RAM。考虑到RAM的成本，将存储在内存数据库中的数据量减到最小，并且设定你的应用程序在用户使用完后释放RAM将是非常重要的。例如，Steem仅在RAM中存储了1周的内容，因此总体的量大小不会随着时间增长而增长。

尽量遏制投机|Minimizing Speculation

那么现在形成了一个RAM市场，投机者或许想要利用RAM价格的波动性获取盈利。而 EOSIO 系统合约设定RAM不可转让，并收取1％的交易费用。这笔费用的结果是通过将其退出市场来抵消Token 的自然通货膨胀。如果RAM的年度交易量等于 Token 供应量，则所有块生产者奖励的100％将由 RAM 市场费用支付。

链间通信兴起|The Rise of Inter Blockchain Communication

高性能区块链需要RAM中的所有数据，因为访问磁盘的时间会使事务吞吐量迅速下降到几百TPS。 为了扩展RAM使用量，我们需要在独立硬件上运行独立内存区域的多个链。

EOSIO区块生产者可以运行许多不同的链，它们都使用相同的token来购买RAM和持有带宽。超级节点选举将在主链上进行，所有相关的侧链将由同一组超级节点维护。 每个链可以拥有1 TB以上的RAM，DAPP可以在链间发送消息，仅需几秒钟的延迟。

RAM的价格在所有的链上都会有所不同，这会告诉DAPP开发者哪里运行起来最便宜。

并行链的发展|Roadmap for Parallelism

链间通信（IBC）涉及到两条链的merkle证明验证，这些证明大小在1KB以上，还涉及数十个密码散列函数以及15个以上的签名验证。换句话说，验证来自另一个链的消息的成本比验证正常事务的成本高出大约15到30倍。

幸运的是，验证这些证明很容易并行化，因为它们不依赖于区块链状态。一条链仅仅只处理来自其他链的消息就很轻易需要消耗30核CPU，同时只能维持几千TPS。

我们相信，通过链间通信的扩展，几乎可以释放无限的性能扩展潜能。这种方法同时扩展RAM、网络和CPU。考虑到签名验证、无上下文操作验证和IBC证明已经满足了大多数CPU的高单线程吞吐量，对多线程WASM执行的优化可能会受到其他资源限制的阻碍。

在EOSIO Dawn 3.0下，我们围绕未来多线程WASM执行的潜力做出了许多设计决策。不幸的是，在您真正实现一个完整的多线程实现之前，不可能知道我们是否涵盖了所有的个例。这意味着EOSIO Dawn 3.0具有许多架构复杂性，而这些复杂性并没有立即带来任何好处。

我们现在认为，从单线程升级到多线程执行的途径是启动一个具有多线程支持的新链，由相同的区块生产者运行，并使用相同的本地token。这使得新链可以完全自由地进行必要的设计调整，以支持多线程操作，而无需对现有活跃链进行就地升级。

通过这个并行性路线图，我们可以简化EOSIO 1.0并优化它以实现最高的单线程性能和易于开发。 我们预计EOSIO的单线程版本有一天可能达到5,000-10,000 TPS。 我们也预计，许多应用程序将更倾向于多链方法来扩展，因为它会降低总体成本并加快扩展。

DPOS不可逆确认算法|Upgrade DPOS Last Irreversible Block Algorithm

参与过共识算法讨论的人可能听说过，使用最后一个不可逆块（LIB）算法（如 Steem＆BitShares 中存在的算法）的DPOS在某些极端网络连接中断时有可能失去共识。在过去，由于其纯粹的理论性质以及相对最低的成本和停机时间，我已经驳回了这种潜在的失败模式。LIB算法只是一个度量标准，就像比特币的6区块规则。纯粹的DPOS总是依赖最长链规则，这将永远达到最终的一致。LIB算法是一种捷径，旨在优化还原历史并为交易提供可信度度量。

EOSIO的IBC算法依赖于DPOS LIB以确定最终结果。一旦你引入IBC，与LIB失败相关的成本和修复它的难度都会变高。我们的团队，特别是 Bart 和 Arhag，对LIB算法进行了优化改进，以保证不超过其中的1/3是拜占庭式的时，两个节点不可能达到不同的LIB。此外，有可能检测单个对等体的拜占庭行为。关于此的更多信息见：https://github.com/EOSIO/eos/issues/2718

比特币和以太坊区块的缺限导致区块链与传统链之间的沟通困难和/或非常高的延迟。对DPOS的新调整将其带到全新的拜占庭容错水平，并且在所有网络环境中都具有强大的可靠性。

账户命名|Name Squatting

一些用户对EOSIO帐户上的12个字符名称限制表示担忧。 这12个字符名称是从64位整数的base-32编码派生的。 64位整数是本地机器字大小，因此非常有效。 在一个事务中，我们多次引用帐户名（代码，范围，权限等），而我们的数据库索引也是以这些64位整数为基础的。 增加帐户名称的长度将对性能和架构产生深远影响。

也就是说，我们关于区块链的愿景是将帐户的概念与身份分开，并在帐户名称和更易读的显示名称之间建立动态链上映射。

最好将帐户名称视为牌照，用户可以选择容易记住的个性名称。也就是说，绝大多数人应该能够找到一个有吸引力的12个字符（或更少）的名字。

由于某些名称潜在的高价值，我们认为EOSIO系统应为帐户名称提供动态定价模式。 此外，诸如* .com之类的命名空间帐户的能力可以为用户或者群体提供额外的安全保护。

由于从现在到EOSIO软件1.0版的开发时间有限，我们将建议所有帐户名都强制为12个字符，而不包含任何“.”字符。一旦确定了可行的定价和反名称抢占政策，社区就可以升级系统合约(不是通过硬分叉)。我们可能会提供一个类似于Bitshare的模式，其中帐户名的定价是根据长度和字符内容。

块头验证|Header-Only Validation

在Steem, BitShares和 EOS Dawn 3.0以及更早的版本中，如果不使用整个区块是不能验证区块头的。在EOS Dawn 4.0中，我们支持了只需要对区块头进行验证。这个功能是轻客户端和链间通信的基础，同时还可以阻止一系列攻击媒介，同时无需等待每个节点进行全节点验证的情况下，区块数据也可以在网络中传播。

用于高频通信的链间通信的最简单的形式需要轻客户端处理所有头信息，然后用户提供与已知区块相关行为的最简单的merkle证明。

区块重构和应用结构|Refactored Block Building & Applying Architecture

我们花费了大量时间来优化区块构建和应用的过程。在新的模型中，区块由应用于该区块的API序列创建。这样做保证了遵循相同的代码路径，并且能够最小化生产者和验证者在确认是否有效时发生不一致性的可能。这次优化让应用区块的过程相当于是重新执行了生产者的脚本。

轻量级BP调度变化证明|Lightweight Producer Schedule Change Proofs

在我们实施IBC概念验证时，我们意识到Dawn 3.0有一些极端情况，在这些情况下简单的签名证明是不可能的。我们希望尽可能简化轻量级稀疏头验证，这需要对区块的签名方式进行重构。

１．生产者调度链可独立进行块头验证
２．每个区块头引用调度版本
３．如果没有签署调度变更证明，就不可能生产区块
４．轻客户端和IBC合约只能处理生产者调度变更

使用EOSIO Dawn 4.0 现在可以验证生产者调度的更改，而无需验证任何区块头。当一个生产者签署一个区块时，他们也签署新的调度，这样就不可能出现两者相互竞争和有效签署的生产者调度，而没有⅔以上生产者的共同勾结或者⅓以上在非常差的网络分离中勾结

新的节点报酬范例|New Producer Pay Paradigm

关于节点收益的社区讨论以及如何分配最高5％的通货膨胀问题已经有很多。EOSIO 1.0中发布的参考系统合同将像这样分配通货膨胀：

有21个活跃生产节点和任意数量的备选节点。排名前21节点按区块数量每块奖励分成0.25％。所有BP候选人（包括前21名）也将按照他们收到的总票数，以每票0.75％的比例提成。他们最多可以每天一次要求获得每票收益的份额。为了要求他们的份额，他们必须有资格获得至少每天100个token。如果没有资格，那么他们将不会收到任何费用。

该算法背后的思想是确保所有候选生产者有足够的收益为社区提供全面节点服务，并确保没有人能够接受不足以支付其成本的资金。假设前200名生产者候选人都获得相同数量的选票，这将支持21名活跃生产者和179名备用生产者。实际上，一些BP会比其他人拥有更多的选票，这可能会减少达到收益资格的备选BP的数量。设定每日收益最低限额是至关重要的，因为那些无意生产区块的富裕人士不能试图通过为自己投票成为BP候选人来获益。

投票权重衰减|Producer Vote Decay

自Dawn 3.0以来，我们所做的大部分工作都涉及调整系统合约。 其中一项调整是实施投票衰减。 为了保持最大的投票影响力，每个选民必须每周重新投票。 对于那些不更新其选票的人来说，其投票影响力会衰退，而且半衰期为1年。

我们建议宪法规定禁止使用自动投票机器人，因为投票衰减政策的目的是确保选民重新评估他们的决定，而不是“设定然后忘记”。 虽然无法证明使用机器人，但可以证明人们不使用智能合约进行自动投票。

集成交易所合约|Exchange Integration Support

随着EOSIO 1.0版本的临近发布，很多人都在要求我们提供有关交易所如何监控EOSIO区块链接收存款，以及确认其外部撤回被接受并不可逆转地确认的信息。 我们已经创建了一个使用cleos（我们的命令行eosio界面）来监视链上交易的教程。 我们还创建了一个python脚本的验证来监视存款和提款。 通过本教程和示例脚本，交易所就可以让一切所需的基于EOSIO的区块链集成开始工作了。

EOSIO Dawn 4.0的可用性|Availability of EOSIO Dawn 4.0

EOSIO Dawn 4.0代码的开发工作正在Github上进行。 我们将在2018年5月11日正式将其发布。届时，我们会将slim移到master分支上，掌握并打一个版本标签。 希望继续使用最新版本的开发人员可以继续关注slim分支。

总结|Conclusion

今年6月，EOSIO软件正朝着强劲的1.0版本迈进。 使用Dawn 4.0后，代码已经被显著优化，我们比以往更加自信。

在下一期，我们邀请了EOS New York接受我们的采访，扫描下方微博话题的二维码，可参与我们的提问。

= END =

转载声明：本文转载自「IMEOS」，搜索「IMEOSONE」即可关注。