EOS.IO DAWN 4.0 发布

翻译:Hansen imeos

声明:版权所有,未经许可,不得转载。

距离 Block.One 发布 EOSIO Dawn 3.0已经一个月了。 在过去的一个月里,我们的团队一直专注在EOSIO软件的优化和稳定性,这其中很大一部分工作是关于跨链通讯的概念验证。

不将merge操作计算在内,共有43位开发者提交818个commit到项目的github。 这让EOSIO在过去的一个月里在github上的C++项目中活跃度排前八。 正如你所看到的,许多事情正在发生。

  1. 时间一致性
  2. 新的基于市场的内存分配模型
  3. 跨链通讯的崛起
  4. 更新不可逆的最后一个区块算法
  5. 账户不正当抢注问题
  6. 仅区块头验证
  7. 轻量级BP排表变化证明
  8. 改进的BP收益模型
  9. 投票权重衰减
  1. 集成交易所合约

 

时间一致性

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

 

RAM分配模型

测试中我们发现了EOSIO系统合同根据token持有量分配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市场价格。

 

对智能合约开发者的影响

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

 

尽量遏制投机

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

 

跨链通讯的崛起

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

 

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

 

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

 

并行路线图

跨链通讯(IBC)涉及到两条链都要相互进行merkle证明验证,这些证明大小在1KB以上,还涉及数多个密码散列函数以及15个以上的签名验证。换句话说,验证来自另一个链的消息的成本比正常验证的成本高出大约15到30倍。

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

 

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

 

在EOSIODaw3.0下,我们围绕未来多线程WASM的可能性做出了许多设计决策。不幸的是,真正在一个完整的多线程被实施之前,不可能知道我们是否涵盖了所有可能发生的个例。这意味着EOSIODaw3.0具有许多架构复杂性,而这些复杂性并没有立即带来任何好处。

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

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

 

升级DPOS最后不可逆区块算法

关注过共识算法辩论的人可能听说过,使用最后一个不可逆块(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的新调整将提高其最终结果的拜占庭容错水平,并且在所有网络环境中都具有强大的可靠性。

 

账户名不正当抢注

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

 

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

最好将帐户名称视为车牌号,用户可以选择容易记住的个性车牌。这样其实,绝大多数人都应该能够找到一个有吸引力的12个字符(或更少)的名字。

 

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

 

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

 

仅区块头验证

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

 

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

 

重构区块构建和应用结构

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

 

轻量级生产者排表变更证明

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

  1. 生产者排表链可独立进行块头验证
  2. 每个区块头注明排表版本
  3. 如果没有签署排表变更证明,就不可能生产区块
  4. 轻客户端和IBC合约只能处理生产者排表变更

使用EOSIO Dawn 4.0 现在可以验证生产者排表的更改,而无需验证任何区块头。当一个生产者签署一个区块时,他们也签署新的排表,这样就不可能同时出现两个不同的被有效签署的生产者排表,除非有⅔以上区块生产者的共同勾结或者⅓以上的区块生产者勾结导致恶性的网络分叉。

 

新的区块生产者收益范例

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

有21个活跃区块生产者和任意数量的备选区块生产者。排名前21区块生产者按各自产生区块的数量来分得这总共为0.25%的预留给每个区块的奖励。所有BP候选人(包括前21名)也将根据他们各自收到的总投票数来分得那总共为0.75%的预留给每个投票的奖励。他们每天最多可以申请一次获得每票收益的份额。要想得到这份收益份额,他们得达到每天100个token。如果区块生产者候选人没有达到每天一百个token将不会收到任何奖励。

 

该算法目的是确保所有候选区块生产者有足够的收益为社区提供全面节点服务,并确保不会有人得到的资金不足以覆盖其运营成本。假设前200名区块生产者候选人都获得相同数量的选票,这将造成21名活跃区块生产者和179名备选区块生产者。在现实中,生产者们所得的票数差距会比较大,这样可以减少有收益资格的备选生产者的数量。

 

设定每日收益最低限额是至关重要的,因为那些无意生产区块的土豪们不能试图通过为自己投票成为BP候选人来获益。

 

投票衰减

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

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

 

交易所集成支持

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

 

EOSIO Dawn 4.0的可用性

EOSIO Dawn 4.0代码的开发工作正在Github上的“slim”分支上进行。 我们将对它进行完善并于2018年5月11日正式将其发布。届时,我们会将slim移到master分支上,并放上发布标签。 希望继续使用最新版本的开发人员可以在slim分支上关注我们的进展。

 

总结

EOSIO软件正朝着在今年六月发布坚实的1.0版本迈进。 Dawn 4.0对代码进行了显著优化,我们比以往更加自信。