针对EOS全历史节点，一个可扩展的解决方案

可能是最靠谱不忽悠的区块链资讯平台

EOS 的DAPP查询数据，主要是通过访问完整历史节点来进行的。但是随着EOS网络的快速增长，历史插件变得越来越难以维护。

与历史插件相关的问题，未来会出现更多。如果现在不采取行动，最终会对网络造成严重影响。为了改善当前基础设施的脆弱性，提高网络的寿命，EOS42正与其他社区成员合作，为完整的历史节点提供一个可扩展的解决方案。

EOS42 发文总结了当前的各种解决方式，并提出了一个可扩展的解决方案。EOS42 节点是首个安装并运行了状态历史插件的EOS API节点，并为BlockOne所创建的状态历史插件提供了一个 开源 RPC API。EOS社区将很快能够使用我们的API来查询历史数据。

为了对EOS网络中常用的插件进行标准化，会确保API的响应与当前的实现相匹配，以便现有的dApps能够无缝地接入我们的解决方案。

如下为正文。

EOS完整历史节点的问题

EOS的应用程序，非常依赖于区块链上的数据。历史插件可以使得应用程序对存储在区块链上的任意的历史信息进行查询。然而，实现这一重要功能的各种 机制 之间，会存在一些差别。事实上，最初的历史插件，在2018年8月14日的EOSIO 1.2.0更新中已经被弃用。

不出所料，由于EOS网络的快速增长，历史插件变得越来越难以支持。

在2018年11月初同步和运行一个完整的历史节点大约需要800 GB RAM。在不到一个月的时间里，历史插件现在需要超过1.5 TB的ram，在几周内几乎翻了一番!

使用历史插件来运行完整的历史节点现在需要花费大约3万美元。按照这种速度，历史插件既不具有可持续性，也不具有成本效益。

此外，BPs通过过滤掉“高流量”账户来降低存储成本。因此，EOS 主网没有“真正完整的历史”节点来存储EOS区块链上的所有内容。例如，由于过多的事务(许多人认为是垃圾邮件)，许多BPs不为blocktwitter保存任何事务历史。此外，在11月14日的那一周发生了短暂的问题，所有完整的历史节点都崩溃了。如果没有任何可公开访问的端点，就无法查询区块链的完整状态。由于维护完整的历史节点非常昂贵、耗时和技术要求，dApps利用了BP API节点。结果，像DEXEOS这样的dapp和Lynx这样的钱包暂时无法完成它们的用户请求。

虽然EOS网络今天没有遭遇危机，但我们预测，与历史插件相关的问题，未来会出现更多。如果现在不采取行动，最终会对网络造成严重影响。为了改善当前基础设施的脆弱性，提高网络的寿命，EOS42正与其他社区成员合作，为完整的历史节点提供一个可扩展的解决方案。

可能的解决方案

历史插件通常被认为是一个短期的解决方案，需要切换为更有效的解决方案。此外，EOS社区一直在努力开发更好的解决方案，让每个人都可以使用。首先，让我们探讨一下当前的解决方案。

MongoDB插件

blockone开发了 MongoDB 插件。MongoDB插件允许将区块链数据存储在MongoDB数据库中，这样可以更有效地索引和查询数据。MongoDB插件是一个很好的选择，可以弥补历史插件危机。

然而，MongoDB插件有许多挑战。

例如，MongoDB插件本身并不是一个完整的解决方案。虽然MongoDB插件将用区块链信息填充MongoDB数据库，但它不允许外部用户以与历史插件相同的方式查询数据库中的信息。

社区必须创建API接口，以允许MongoDB插件“接入”到许多dApps现在依赖的经典API接口。Cryptolions已经开发并维护了一个很棒的开源解决方案，称为EOS Mongo 历史 API。

此外，目前的MongoDB插件还没有最终确定，我们已经看到了EOS.io软件所发布的多个更新版本之间数据结构(schema)的变化。每当结构发生变化时，任何维护MongoDB节点的人都需要完全重新同步他们的节点，以构建新的数据结构。根据所使用的硬件，完全同步一个节点可能需要几天或几周的时间。重新同步也造成了许多挫折和时间损失。许多人反馈说，需要多次同步，才能够最终成功。

一旦同步完成，还有其他需要克服的挑战。如果MongoDB实例被太多的请求造成了溢出，数据库会崩溃，NodeOS将继续实时接收块，并尝试将信息插入数据库。如果数据库本身停机了几分钟，就会在数据库中出现缺口。在这种情况下，唯一的解决方案是完全重播(replay)/重新同步节点。

MongoDB插件的另一个问题是，可能会为相同的事件插入重复的数据。这个问题可能会增加存储需求，并在管理数据库时增加额外的复杂性。最值得注意的是，重复的数据必须手动删除。

EOS Light API

EOS Light API是一个由BP赞助的开源插件和API。被称为cc32d9的开发人员创建了这个项目，并开发了最初的ZeroMQ插件。ZeroMQ插件在Chintai的开发中发挥了至关重要的作用。

事实上，ZeroMQ是我们在Chintai中使用的开源插件的基础。EOS Light API在插件级别使用ZeroMQ和 MySQL 作为数据库存储。EOS Light API已经准备好进行公开测试，更多信息可以在这里找到。

Elastic Search插件+ API

Elastic Search 是分析大 型数据集的一种常用方法。EOSLaoMao已经为Nodeos开发了一个开源插件来支持对Elasticsearch集群中的EOSIO 主网中的历史数据进行索引。此解决方案的优点是，能够快速搜索并关联区块链的完整历史上的数据指标。目前，EOSLaoMao和EOS Rio正在为这一方案和其他数据历史解决方案，开发一个开源API，以及新的API标准。

DFuse

DFuse是EOS Canada开发的新解决方案。DFuse允许dApp开发人员从区块链获取历史数据和实时事件。虽然Dfuse这一解决方案并未开源，但是对于EOS社区dApp开发人员来说，在构建应用程序时从区块链获取历史信息的多一个选择，也同样重要。

状态历史插件(state history plugin)

来自BlockOne的Todd Fleming 开发了名为State history Plugin(状态历史插件)的这一历史解决方案。状态历史插件解决了MongoDB插件遇到的一些问题:

• 自动处理分叉，不会存储任何重复的数据。

• 数据库存储与节点解耦。因此，如果数据库宕机，可以很容易地进行同步，而无需停止节点或需要重播区块链。

• 其他以前无法实现的功能。这些功能包括，在某个 智能合约 所有相关区块中，获得该智能合约的数据表中的记录。

• 由于采用了解耦设计，未来对任何数据表结构的更改都不需要重放Nodeos(注意：这一功能会包含在未来的更新中)。

Todd还开发了一个实用程序 fill-postgresql，它会用新的历史信息填充Postgresql数据库。未来会开发出许多其他向数据库填充数据的程序，而不只局限于一个数据库。

这对MongoDB插件意味着什么

据Todd所说，BlockOne在并行开发State History插件和MongoDB插件，并计划同时支持这两个插件。Todd设想未来可以使用多种历史方式和存储机制，允许社区成员自由选择适合他们需求、预算和专业知识的解决方案。

状态历史API

状态历史插件目前已经可以使用了，但是没有像Cryptolions EOS Mongo History API这样的API。幸运的是，情况已不再如此。

最近，EOS42成为了第一个安装并运行状态历史插件的EOS API节点。这标志着一个新的完整历史解决方案之旅中，一个重要里程碑。EOS42提供了第一个正式环境下运行的系统，在EOS主网上测试和运行了状态历史插件。

我们还激动地宣布，我们已经为状态历史插件创建了一个开源RPC API，称为EOS状态历史API。EOS社区将很快能够使用我们的API来查询历史数据，这进一步增加了社区完整历史API的冗余性和灵活性。

为了对EOS网络中常用的插件进行标准化，我们确保API的响应与当前的实现匹配，以便现有的dApps能够无缝地插入我们的解决方案。此外，作为Elasticsearch插件项目持续开发的一部分，EOS Rio和EOSLaoMao发起了开发新API标准的倡议，我们也会进行紧密的合作。

最后,为了使状态历史插件更容易使用, EOS42正与(blockmatrix)(https://blockmatrix.network/)一起，提供针对日常历史状态数据的快照数据文件, 这可以让任何人都能够在几分钟内创建起来一个全新的历史节点, 不用花费数周时间等待数据同步。

EOS42 开创去 中心化 的未来

EOS42的账号为: eos42freedom。
请为EOS42 投票 ，支持我们继续不停开拓去中心化解决方案的未来。