eos节点服务器_首个高性能区块链轻节点解决方案EOS Arclight上线

EOSC主网

持续向去中心化高性能智能合约平台演进

专注于

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

EOS 弧光灯

EOS原力开发团队近日发布了首款高性能区块链轻节点解决方案——EOS Arclight。 该方案基于Golang开发，针对EOSIO等高性能区块链协议引入轻量级节点方案。 不同于基于nodeos的EOSIO全节点，“EOS Arclight”轻节点只需要验证区块头，不需要执行区块中的Action。

高性能区块链的新瓶颈：

1、运维成本高

EOSIO的区块头结构支持轻量级节点，但目前EOSIO社区还没有可靠的轻量级节点实现。

在比特币白皮书中，中本聪提出可以在不运行全网节点的情况下进行支付验证。 对于区块链数据，可以通过剪枝的方式进行压缩。 旧区块只能保留区块头和节点关注的交易数据。 即使在2008年白皮书发布的时候，也可以存储在当时普通微机的内存中。 存储所有区块头数据。

在随后的讨论中，中本聪认为比特币网络最终可能只有10万个左右的全节点。 这些全节点具备出块能力，同时有数以百万计的轻量级客户端。 这些客户可以发送和接收交易。 虽然无法产生区块，但支付仍然可以自行验证，无需依赖其他节点进行验证。

EOSIO 的区块链结构也支持轻量级节点。 在其网络和应用中，也需要大量的轻量级节点。 特别是，与比特币的设计不同，EOSIO 全节点对机器性能的要求非常严格。 并且由于其自身的Token发行和RAM扩展机制，这种需求不会随着机器物理性能的提升而得到缓解。

在EOSIO网络中，一个全节点对机器性能、网络和运维都有非常高的要求。 目前EOSIO网络中可用的全节点非常少，这意味着目前的EOSIO网络结构还不够去中心化。 稳定性影响很大，同时也让链上应用的开发和部署变得更加困难。

以EOS网络（chainID：aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906）为例（2020年1月中旬），内存总量174G，分配内存约74G。 虽然实际使用的数据很少，但至少要配置64G以上的全节点，否则会因为内存读写未命中导致交易执行失败。 即使重放区块，区块重放速度也可能跟不上新区块的生产速度。 这也意味着目前大部分的计算设备都无法满足一个EOSIO节点的需求。

另一方面，目前EOSIO区块数据非常庞大比特币服务器主网，这给节点的维护和存储带来了很大的挑战。 同时，重放区块的时间过长。 在一些主流的性能服务器上，一个完整的replay block需要将近一个月的时间。 即便使用快照功能可以在几小时内恢复RAM状态，仍然无法解决节点消耗过大的问题。 甚至有开发者感叹高TPS是一个“伪命题”，认为未来部署节点需要一年时间，这样就不会出现新的全节点了。

2、开发难度大，成本高

EOSIO的插件架构虽然可以让节点扩展功能，但是节点对机器性能的要求很高，EOSIO基于C++开发插件的开发门槛很高。 因此EOSIO的扩展工具很少，间接的提升了DAPP。 开发难度。

很多早期的DAPP查询和索引服务依赖于EOSIO的历史插件和mongoDB插件，但是随着节点块数据的增加，这样的历史节点或者mongoDB数据库造成了很大的性能问题，虽然社区也提出了一些，但是比特币服务器主网，因为它往往依赖于全节点，所以成本相当高，使得很多这样的服务都比较昂贵，这给DAPP的开发和运营带来了很多额外的成本。

中本聪对比特币网络结构的预测也适用于其他区块链网络。 除了全节点，EOSIO网络还需要大量满足成本博弈的轻量级节点。

3. 无法满足跨链要求

当前公链发展的一个重要方向就是对跨链功能的支持。 EOSIO将支持添加基于IBC的侧链。 目前启动IBC需要基于全节点，用户才能基于Merkle Tree获取证明数据。 但是，由于全节点的建立成本太高，即使需要少量的验证者和钓鱼者来启动全节点也是非常困难的，这会使得一些理论上的支撑方案在经济成本上站不住脚，如果跨链的运行只依赖于少数网络全节点提供的服务，那么整个系统将非常脆弱。

基于以上问题，我们需要一个足够轻量级的EOSIO节点实现。 在保证区块验证的同时，轻节点要易于扩展和二次开发。

EOS弧光灯技术原理：

EOS arclight 轻节点并不处理每一笔交易，只是验证区块和区块头的有效性，确认它们的区块是不可逆的。

EOSIO对节点要求高的主要原因之一是它的内存（RAM）状态，它的内存（RAM）状态非常大并且在区块中没有经过验证，因此任何节点想要获得任何状态都需要重放整个EOSIO区块，虽然节点可以通过快照功能恢复，即使是保持同步的节点，一旦发生故障恢复时间也比较长。 同时，由于EOSIO链上交易较为繁忙，峰值可达4000TPS左右，同步实时EOSIO区块对机器的要求也会更高。

不处理每一笔交易意味着轻节点的大部分工作可以并行完成，也可以从任何区块高度同步。 在目前的原型实现中，轻节点只需要占用极少的计算资源即可完成验证。

虽然不处理每笔交易让轻节点占用的资源非常少，但也使得轻节点无法提供内存（RAM）状态。 在 EOSIO 中，几乎所有状态都在内存中。 一些操作（EOSIO称为Action）也需要通过执行交易来触发。 为了解决这个问题，需要一些断言机制来保证节点可以只根据区块数据获取EOSIO的状态。 这可以通过 EOSIO 状态断言合约和状态静态断言合约来实现。

根据EOSIO轻节点的不同角色，我们将EOSIO轻节点分为区块节点和区块头节点。 前者包含全部或部分 EOSIO 区块，后者仅包含 EOSIO 区块头数据。

考虑到EOSIO还在持续发展中，轻节点也需要与之迭代，所以轻节点的设计要尽可能和EOSIO保持一致，API和操作要尽可能和nodeos统一。 当然，轻节点Node是不包含内存状态的，所以一些API轻节点是不支持的。 如：获取表等。

EOS弧光灯使用场景：

1 真正的去中心化钱包：

目前的EOSIO钱包往往是基于中心化的第三方提供的数据，未经验证。 这与比特币钱包非常不同。 如果这些钱包脱离了第三方提供的服务，就无法正常使用。 在这些钱包中，用户无法获得准确的交易执行反馈。 如果他们想确认交易是否完成，只能依靠其他服务，比如区块浏览器，来确认交易是否完成。 这实际上会带来很大的安全隐患。

基于“EOS Arclight”，我们可以将轻节点嵌入到钱包中，让每个钱包都是一个轻节点。 此时钱包可以独立验证交易是否成功，即使在不安全的网络环境下也可以安全使用。

2 可信实时区块数据服务：

很多DAPP都需要实时的链上数据，尤其是去中心化交易所这类响应时间短、注重安全性的应用。 共识算法还处于完成的初始阶段，一个区块进入不可逆状态的时间间隔比较长，这意味着很多应用需要乐观地接受没有进入不可逆状态的区块，避免状态不一致通过后期验证。 逻辑上需要编写节点插件和部署全节点，这会增加大量的DAPP开发和运营成本。

基于“EOS Arclight”，轻节点可以以库的形式融入现有的数据服务。 轻节点基于Golang开发，对后端开发友好，无门槛。 同时，由于轻节点已经完全实现了共识算法，因此非常方便实现可信、实时的区块数据服务。

3 高性能跨链服务：

如果要实现EOSIO链与其他链的跨链交互，往往需要同时实现两条链的轻节点。 “EOS Arclight”可以方便的嵌入到其他服务或节点中，并且可以独立验证节点，可以很好的支持这类应用。

事实上，“EOS Arclight”最初的开发引擎是作为跨链服务中的一个环节。 比如目前很多链都是基于Cosmos SDK开发的。 一种很常见的架构是使用基于 Cosmos SDK 的链作为结算链。 EOSIO的链作为计算链，通过实现Cosmos的IBC协议完成跨链计算结果的结算。 在这个系统中，我们只需要在结算链的节点中集成“EOS Arclight”，让每个结算链节点都是计算链的一个轻节点，通过原有结算链的共识机制，每个结算链节点持有的计算链区块数据（只需要考虑不可逆区块的ID）达成共识，使得计算链的数据可以追溯到结算链。

EOS Arclight 技术路线图

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

EOS Arclight 已经全部开源，Github 地址：.