EOSIO 的出现引领了区块链技术从实验室向大规模商用发展,随着更多高性能区块链协议涌现,信任经济的雏形已现。高性能区块链的大规模部署带来了新的问题:全节点的运维成本居高不下,应用数据无法高效同步,数据无法在多链之间共享。高性能区块链亟需引入轻量级的节点方案,为信任经济进一步发展扫清最后的障碍。

「EOS 弧光」

EOS 原力开发团队于近日发布了首个高性能区块链轻节点方案--EOS 弧光。该方案基于 Golang 开发,为 EOSIO 这类高性能区块链协议引入轻量级节点解决方案。与基于 nodeos 启动的 EOSIO 全节点不同 ,「EOS 弧光 」轻节点仅需验证区块头 , 无需执行区块中 Action。

高性能区块链的新瓶颈:

1、运维费用高

EOSIO 的区块头结构支持轻量级的节点,但是当前 EOSIO 社区中并没有一个可靠的轻量级节点实现。

在比特币白皮书中,中本聪提出不运行一个完整的网络节点也是可以进行支付验证。对于区块链数据可以采取剪枝的方式进行进行压缩, 老的区块可以只保留区块头和节点关注的交易数据,即使在白皮书发布的 2008 年,也可以在当时常见的微型计算机的内存中存储全部区块头数据。

随后的讨论中, 中本聪认为比特币网络最终可能只存在 10 万左右的全节点,这些全节点具备生产区块的能力,而同时存在着数百万的轻量级客户端,这些客户端可以收发交易,虽然不能生产区块,但仍能自己验证支付,而不需要依赖别的节点进行验证。

EOSIO 的区块链结构同样支持轻量级节点,在其网络与应用中,同样需要大量的轻量级节点,特别的, 区别于比特币的设计,EOSIO 全节点对机器性能的要求十分苛刻,并且由于其本身的 Token 增发与 RAM 扩容机制,这一要求不会随着机器物理性能的提升而得到缓解。

在 EOSIO 网络中,一个全节点对于机器性能、网络和运维的要求是非常高的,目前 EOSIO 网络中可用的全节点很少 , 这意味着当前 EOSIO 网络结构不够去中心化 , 对整个网络的稳定性产生了很大影响 , 同时这也提高了链上应用的开发和部署难度。

以 EOS 网络(chainID:aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906)为例(2020 年 1 月中旬),RAM 总量为 174G,已分配的内存为 74G 左右,虽然实际使用的数据很少,但作为一个全节点至少要配置超过 64G 的内存,否则会出现因为内存读写未命中而导致事务执行失败,即使是重放区块,也可能导致区块重放速度无法跟上新区块生产速度,这也意味着目前的大多数计算设备无法满足 EOSIO 节点的需求。

另一方面,目前 EOSIO 区块数据十分庞大,这给节点的维护和存储带来很大挑战,同时重放区块消耗时间过长,在一些主流性能服务器上,完整的重放区块需要近一个月时间。即便使用快照功能可以在几个小时时间之内恢复 RAM 状态但依然不能解决节点消耗过大的问题。有的开发者甚至感叹高 TPS 是「伪命题」,认为今后节点部署甚至会花费一年时间,以至于没有新的全节点出现。

2、开发难度及成本高

虽然 EOSIO 的插件式架构可以允许节点拓展功能 , 但是节点对机器性能的要求较高 , 同时 EOSIO 基于 C++开发插件有较高的开发门槛 , 因此 EOSIO 的拓展工具很少 , 这也间接提高了 DAPP 的开发难度。

早期的很多 DAPP 的查询与索引服务依赖于 EOSIO 的 history 插件和 mongoDB 插件,但随着节点区块数据的增多,这样的 history 节点或 mongoDB 数据库产生了很大的性能问题,虽然社区也提出了一些解决方案,但是由于其往往依赖于全节点,故而成本颇高,使得很多此类服务的价格比较高昂,这给 DAPP 的开发和运营带来了很多额外成本。

中本聪对于比特币网络结构的预测同样适用于其他的区块链网络,除了全节点外,EOSIO 的网络也同样需要大量符合成本博弈的轻量级节点。

3、跨链需求无法满足

目前公有链发展的一个重要方向是跨链功能的支持 , EOSIO 将支持基于 IBC 来添加侧链 , 目前启动 IBC 需要基于全节点以使用户可以获取基于 Merkle Tree 的证明数据 , 但是由于搭建一个全节点的成本过高 , 即使要求少数验证者和钓鱼者启动全节点也是一件非常难以实现的事,这会使得某些理论上的支持方案从经济成本上不成立,如果跨链的运行仅仅依赖于少数的全节点提供的服务 , 那么整个系统将会十分脆弱。

综合以上问题 , 我们需要一个足够轻量级的 EOSIO 节点实现 , 轻节点在保证对区块的验证同时 , 应当易于拓展和二次开发。

「EOS 弧光」技术原理:

「EOS 弧光」轻节点不会处理每一个事务,仅仅验证区块与区块头的有效性,同时确认其区块不可逆。

EOSIO 对节点高需求的一个主要原因是其内存(RAM)状态,这些状态十分庞大且没有在区块中验证,所以任何一个想要获取任意状态的节点都需要完整的重放一遍 EOSIO 的区块,虽然可以通过快照功能复原节点,但即使对于保持同步的节点,一旦出现故障其复原时间也比较漫长。同时由于 EOSIO 链上的事务比较繁忙,峰值时可达 4000 TPS 左右,同步实时的 EOSIO 区块也会对机器的要求较高。

不处理每一个事务意味轻节点的大部分工作可以并行完成,而且也可以从任意区块高度开始同步,在目前的原型实现中,轻节点只需占用很少的计算资源即可完成验证。

不处理每一个事务虽然允许轻节点占用很少的资源,但是也使得轻节点无法提供内存(RAM)状态,而在 EOSIO 中几乎所有的状态都在内存中,一些操作(EOSIO 称之为 Action)也需要通过执行事务来触发,为了解决这个问题,这就需要一些断言机制来保证节点仅仅基于区块数据就可以获得 EOSIO 的状态,这可以通过 EOSIO 状态断言合约和状态静态断言合约来实现。

根据 EOSIO 轻节点所负担的角色的不同,我们将 EOSIO 轻节点分为区块节点和区块头节点,前者包含全部或部分 EOSIO 区块,后者只包括 EOSIO 区块头数据。

考虑到 EOSIO 还在不断的发展中 , 轻节点也需要跟随其进行迭代 , 所以轻节点的设计应该尽可能的和 EOSIO 保持同构 , 其 API 与操作也应该尽可能与 nodeos 保持统一 , 当然 , 轻节点不含内存状态 , 所以一些 API。如:get table 等。

「EOS 弧光」使用场景:

1 真正的去中心化钱包:

目前的 EOSIO 钱包往往基于中心化的第三方提供的数据,这些数据并没有被验证,这与比特币的钱包有很大区别,这些钱包如果脱离了第三方提供的服务就无法正常使用,同时在这些钱包中,用户无法得到准确的交易执行回馈,如果要确认交易是否完成,只能依赖于其他服务,例如区块浏览器来确认交易完成,这实际上存在的很大安全风险。

基于「EOS 弧光」我们可以将轻节点嵌入进钱包中,这样每一个钱包都是一个轻节点,这时钱包可以独立去验证交易是否成功,即使在不安全的网络环境中也可以安全的使用。

2 可信实时的区块数据服务:

很多 DAPP 需要实时的链上数据,尤其是去中心化交易所等响应短且重视安全性的应用,需要可以安全、确定的获取链上实时的状态,特别是 EOSIO 的不可逆区块判定,由于目前的共识算法尚处于初步完成的阶段,区块进入不可逆状态的时间间隔较长,这也就意味着很多应用需要先乐观的接受未进不可逆的区块,以事后验证的方式避免状态不一致,这样的逻辑需要编写节点插件,并部署全节点,这会增加很大的 DAPP 开发与运营成本。

基于「EOS 弧光」,可以把轻节点以库的形式纳入到已有的数据服务中,轻节点基于 Golang 开发,对于后端开发比较友好且不存在门槛,同时因为轻节点完整的实现了共识算法,所以实现可信实时的区块数据服务十分方便。

3 高性能跨链服务:

如果需要实现 EOSIO 链与其他链的跨链交互,往往需要同时实现两条链的轻节点,「EOS 弧光」可以很简单的嵌入其他服务或节点中,并且能够独立的验证节点,可以很好的支撑此类应用。

事实上,「EOS 弧光」最初的开发动机即是作为跨链服务中的一环,比如,目前很多链基于 Cosmos SDK 开发,一个很常见的架构就是把基于 Cosmos SDK 的链作为结算链,把基于 EOSIO 的链作为计算链,通过实现 Cosmos 的 IBC 协议来完成跨链计算结果结算。在这个系统中,我们只需在结算链节点节点中集成「EOS 弧光」,使每个结算链的节点都是计算链的轻节点,通过原有结算链的共识机制使各个结算链节点持有的计算链区块数据(只需考虑不可逆块的 ID)达成共识,这样就实现了计算链的数据回溯到结算链的过程。

「EOS 弧光」技术路线图

「EOS 弧光」由 EOSC 社区开发团队 EOS 原力开发,目前开发工作主要分为三个方向:节点实现、兼容全节点 API 和计算性能优化,EOS 原力团队已经实现了初步的版本,可以完成区块数据的同步和验证,同时发布了技术路线图:

2020 Q1 : 实现区块不可逆块判定算法,完善区块存储实现 , 兼容 nodeos 的 block db
2020 Q2 : 支持其他节点从轻节点同步区块与事务,完善 API 接口以尽可能兼容 nodeos
2020 Q3 :优化并发计算能力 , 加速同步过程,支持 EOS-VM 以实现部分 Action 的执行

「EOS 弧光」已全部开源,Github 地址:https://github.com/eosforce/eos-light-node