ETH Research：利用The Graph保留历史数据并启用EIP-4444

原文标题：《Using The Graph to Preserve Historical Data and Enable EIP-4444》

原文作者：Seve 2、 Eray 4、Semiotic Labs 2 的Lichu 3和Tatu 3、The Graph 的核心开发人员

原文编译：Luccy，BlockBeats

编者按：

EIP-4444 提议把 HISTORY_PRUNE_EPOCHS 设为 82125 个 epoch (即信标链上 1 年)，使得在 PoS 以太坊里执行层客户端不再在 p2p 网络上提供超过一年的区块头、区块主体和收据的数据，客户端可以在本地修剪这些历史数据。

The Graph 是一种可在以太坊和 IPFS 等网络上进行查询的索引协议。任何人都可以构建和发布被称为子图（subgraphs）的开放 API，从而使数据更加易于获取，其中核心组件是索引器。

索引器需要访问区块链的历史数据来完成任务，而 Firehose 是一个用于从区块链中提取数据的开源工具。目前，区块链数据是通过执行完整的归档同步从启用 Firehose 的完整节点中提取的，但在 EIP-4444 实施后，The Graph 的索引器需要调整其区块链数据提取流程。

在本文中，Semiotic Labs 分享了如何利用 The Graph 协议上的技术开发来解决更广泛社区的问题。最初，Semiotic Labs 为了提高 The Graph 协议的性能和可验证性开发了 Firehose 和 Substreams，而这一工具和技术恰好能够应对 EIP-4444 问题，并基于此为索引器专门创建了一个采用这种技术的新索引管道。

在这个管道中，Firehose 首先从区块链中提取数据并将其存储在平面文件中，并为区块提供了一个 gRPC 接口进行流式传输，这个流在 The Graph 中可以被多个端点消费。其中，平面文件作为可共享的以太坊档案，它们包含了所有必要的历史数据。这些文件是可共享、可验证的。

此外，本文比较了平面文件格式和 era1/era 格式的结构细微差别和用例，并指出，在 The Graph 中，新的索引器在运行 Firehose 时必须执行一个完整的归档节点同步，以提取用于索引的所需历史区块链数据，同时解释了如何通过共享、可验证的平面文件与 The Graph 的激励市场解决这些问题。

Semiotic Labs 是 The Graph 协议的核心开发者之一。本文的作者所在的团队致力于开发和实施验证 The Graph 提供的来自各个索引区块链上数据的机制。本文所介绍的工作内容是 Semiotic Labs 持续不懈努力的成果。Severiano Sisneros 将这篇文章发表在以太坊研究论坛中，BlockBeats 将原文编译如下：

The Graph 简介

The Graph 是一个去中心化的区块链数据索引和查询协议。索引器是 The Graph 的核心，为特定事件索引区块链的历史，并使数据可供消费者查询，索引器需要访问历史区块链数据以完成他们的工作。未来，The Graph 的索引器将使用作为 Firehose 数据抽取过程一部分的特殊工具化的区块链完整节点从区块链中提取数据。

Firehose 是由 The Graph 的核心开发者 StreamingFast 创建的开源工具。Firehose 为处理区块链数据提供了基于平面文件（Flat File）和流优先（streaming-first）的方法。Semiotic Labs 是 The Graph 的另一个核心开发团队，专注于人工智能和密码学领域的研究和开发。

目前，区块链数据是通过执行完整的归档同步从启用 Firehose 的完整节点中提取的，这依赖于区块链的 P2P 网络中的对等方提供完整的历史数据。然而，在 EIP-4444 实施后，由于完整节点将不再提供超过一年的历史数据，The Graph 的索引器需要调整其区块链数据提取流程，以确保继续获取所需数据。

本文将介绍 The Graph 索引器如何利用 Firehose 从区块链中抽取数据，并将其存储在称为平面文件的 Google protobuf 序列化对象存储中。当 Firehose 从创世区块进行同步时，这些平面文件会存储区块链中存储数据的完整历史所需的所有信息（具体来说是区块体和收据）。我们建议将这些平面文件作为存档数据格式，与 era 和 era1 文件类似，并演示如何验证存储在平面文件中的数据属于权威区块链。

对于 The Graph，一旦 EIP-4444 实施生效，索引器便可以共享这些平面文件以获取所需的历史数据进行索引和查询。在以太坊的情况下，The Graph 的激励型索引器网络共同确保了历史数据的保存和可用性，为 EIP-4444 提供了可验证、去中心化且独立的解决方案。

有趣的是，我们最初的目标并不是为 EIP-4444 设计解决方案。这里讨论的工具和技术是为了提高 The Graph 协议的性能和可验证性而开发的。然而，在这个过程中，我们意外地发现了一个解决 EIP-4444 的方案。我们的愿景是让这个解决方案与其他 EIP-4444 解决方案共存，就像以太坊执行客户端的多种实现一样，而不会导致区块数据的异构分布。

The Graph Firehose 管道概述

The Graph 是一个不断发展的动态协议，旨在满足快速访问区块链数据的需求。为此，开发了一种名为 Firehose 和 Substreams 的新技术，并为索引器专门创建了一个采用这种技术的新索引管道。

在这个管道中，Firehose 是第一步处理过程。它从区块链中提取数据并将其存储在平面文件中（将在下一节详细介绍）。接着，Firehose 为存储在平面文件中的区块提供了一个 gRPC 接口进行流式传输。在 The Graph 中，这个流可以被多个端点消费。例如，Substreams 服务可以过滤感兴趣的特定事件，并对过滤后的数据执行任何指定的转换。处理后的结果将被路由到一个端点汇集处，并提供给消费者。

图 1 提供了关于 Firehose 和 Substreams 管道视图，说明了如何从区块链中提取数据、处理数据，并通过各种端点使数据可供消费者使用。

图 1：Firehose + Substreams

在 EIP-4444 背景下，我们特别关注如何将区块链数据提取并存储到平面文件中。我们观察到平面文件包含了保留区块链历史所需的所有数据，同时可以通过简单的技术手段验证这些数据是否真实地包含在区块链的规范历史中。作为一种去中心化的区块链数据索引和查询协议，The Graph 具有确保整个区块链历史可用性的天然优势。

平面文件作为可共享的以太坊档案

Firehose 通过运用专用的完整节点 2 从区块链中提取数据。以太坊 Firehose 采用的是官方 Geth 1 实现的仪表化版本，需要注意的是，Firehose 支持多个链，包括非 EVM 链，使用的完整节点会因链的不同而有所不同。具体而言，Firehose 在执行完整的归档同步时，会从完整节点的跟踪 API 中读取数据。请参阅图 2 以获取这些步骤的详细描述。

图 2：提取 Firehose 数据

跟踪 API 的输出内容被存储在平面文件中。需要注意的是，跟踪 API 可以根据需要配置，以提供不同程度的 EVM 执行内省。例如，可以将其配置为 callTracer，用于追踪交易过程中执行的调用帧（包括顶级交易调用和交易内部的调用），或将跟踪 API 配置为结构/操作码记录器，在交易执行的每一步中输出操作码和执行上下文。为了验证 Firehose 平面文件作为以太坊历史存档的可行性，我们专注于保留顶级交易调用和收据，因为这些是提交到区块链并可以在区块链中验证的数据。在这种情况下，Firehose 存储了与区块链中交易执行相关的所有交易数据（区块体）和收据。

虽然 Firehose 平面文件并未专门设计用于导出历史以太坊存档数据，但它们包含了所有必要的历史数据。这些文件是可共享的，并且如我们所见，是可验证的，这使得它们成为存档格式的有力候选。

可验证的平面文件

平面文件存储了所有顶级交易数据（区块体）以及与交易执行相关的收据。例如，如图 3 所示，使用 Semiotic 的 flat-files-decoder 解码的 1500 万区块的平面文件（JSON 格式）。我们可以看到所存储的区块头信息以及顶级交易的交易追踪，如下面的交易 0x7ecdee...e3222 所示。通过 Firehose 提取的以太坊区块链数据按照这种模式存储在平面文件中。

图 3：来自平面文件的区块 15,000,000 的解码区块链数据

平面文件存储了用于重建交易和收据 Merkle 树的所有必要信息。这些 Merkle 树会被提交到规范区块链的每个区块中。要验证这些数据属于规范区块链，我们只需确保重建的 Merkle 树的根与存储在规范区块头中的根相匹配。在合并后，我们可以利用共识层提供的信息。例如，以太坊提供了一个同步委员会子协议，用于验证来自规范区块链的区块头。为了验证存储在合并后平面文件中的数据是否正确，我们只需为平面文件中的区块重建收据和交易 Merkle 树，然后将这些根与有效的同步委员会签名的区块头进行比较。我们可以从共识轻客户端获取有效的区块头。

有关如何实现此操作的示例，请参阅我们的概念验证代码。根据我们的基准测试，M1 Mac 上一个区块的数据提取和 Merkle 树构建大约需要 5 毫秒。

在合并前，我们需要完成更多工作。幸运的是，我们并不孤单。以太坊社区一直在寻求解决此问题的方案。具体来说，门户网络利用 Header Accumulator 来验证区块头是否已包含在规范链中。值得注意的是，这些累加器对存档数据的存储格式是无关的，因此我们可以与这种方法保持一致，并从平面文件中存储的数据计算相同的 Header Accumulator 值。当索引器共享包含合并前区块的平面文件时，它们还需要为包含收据和交易 Merkle 树根的区块头提供证明。

平面文件、Era 文件

针对 The Graph 的 Firehose 平面文件提出的存档数据格式和验证机制与现有的数据格式方法相兼容，例如这里描述的 era/era1 数据格式。一个关键的区别在于存储了哪些区块链数据。具体来说，era 文件格式要求每个 era 文件都包含一个 Beacon 链状态的快照，以便在从该文件开始处理链时获取状态数据。然而，Firehose 平面文件故意不包含任何 Beacon 链状态数据，因为其目的仅仅是集中存储执行层的历史交易数据和收据。

由于 Firehose 平面文件并非为引导实际的以太坊节点而设计，因此保留状态数据是超出其范围的。The Graph 产品主要关注于索引事件数据以进行查询，而非以太坊节点的有状态执行。

表 1 比较了平面文件格式和 era1/era 格式的结构细微差别和用例。

表 1：平面文件与 Era1 属性的对比

激励平面文件的可检索性

正如我们所看到的，在 The Graph 中，新的索引器在运行 Firehose 时必须执行一个完整的归档节点同步，以提取用于索引的所需历史区块链数据。这个过程引入了两个挑战，我们将解释如何通过共享、可验证的平面文件与 The Graph 的激励市场解决这些问题。

挑战 1：执行完整归档同步可能耗时较长，具体取决于文件系统和索引器硬件。在 Semiotic Labs，同步一个 Firehose 节点（Geth + Firehose）需要大约两个月的时间。

解决方案 1：如果在同步过程中平面文件受损（就像我们经历的两个月后那样），可以通过从其他索引器下载平面文件并引导 Firehose 使用它们来完成 Firehose 同步。利用上述工具，索引器可以验证从对等方下载的平面文件属于规范区块链。索引器将使用从对等方下载并根据规范区块链验证的平面文件为 Firehose 提供种子，而不是执行完整归档同步。瓶颈变成了下载速度，例如，从创世纪开始下载整个归档的约 2TB 需要几天，而不是完整归档同步所需的几个月。

挑战 2：一旦 EIP-4444 生效，需要一种保留历史数据的机制。

解决方案 2：我们注意到平面文件既可以共享，也可以验证，因此索引器可以建立一个共享平面文件的激励市场。The Graph 的消费者指定事件和所需的历史范围，事先不知道这个历史范围。希望未来证明自己的索引器将确保他们拥有整个区块链历史的数据。目前，在 The Graph 生态系统内正在努力建立这个市场作为一项数据服务，这是一项由 The Graph 支持的「平面文件共享数据服务」。关于 EIP-4444，我们回答了两个问题：「谁将存储数据？」和「数据将如何提供？」。The Graph 的索引器将以平面文件的形式存储历史数据，数据将通过 The Graph 协议中的子图/子流和目前正在开发的平面文件共享数据服务提供。

结论

The Graph 的 Firehose 生成的平面文件格式为实施 EIP-4444 后保留以太坊历史数据提供了一种去中心化且可验证的解决方案。我们已经证明了这种平面文件包含了所有必要的区块链数据，并且可以与规范链进行验证。

我们正在努力完善我们的开源平面文件验证代码，以便可用于验证下载的平面文件。我们预期 The Graph 协议中的索引器将利用这段代码在数据服务市场中分发和盈利平面文件，而非通过以太坊的 p2p 网络同步完整节点。

The Graph 网络天然地支持并激励了一种独特的 EIP-4444 解决方案。特别是，由索引器生成和使用的平面文件还可以作为一种可共享、可验证的归档格式。我们已经证明了这种平面文件包含了所有必要的区块链数据，并且可以进行验证，同时提供了概念验证代码。我们提出的方法与现有的努力（如 Portal Network 的头部累加器和 era/era1 文件格式）保持一致，提供了一个侧重于执行层数据的互补解决方案，可以与其他 EIP-4444 解决方案并存，而不会导致区块数据的异构分布。我们正在努力完善我们的开源验证工具，以便索引器可以轻松验证下载的平面文件。不久的将来，The Graph 将推出一个扁平 p2p 文件共享数据服务，为获取历史数据提供替代方法。

这种去中心化、可验证的平面文件解决方案不需要协议层面的更改，并且可以帮助像 The Graph 这样的协议在 EIP-4444 之后继续正常运行。我们提供这种方法作为一种可行的途径来保留以太坊的历史，造福整个生态系统。

行动号召

反馈：在本文中，我们将分享如何利用 The Graph 协议上的技术开发来解决更广泛社区的问题。我们非常希望收到您的反馈，所以如果您有任何问题、建议等，请随时与我们联系。

平面文件的分发与可访问性：我们对于 Firehose 生成的平面文件（从创世纪开始同步的启用 Firehose 的节点产生）包含了保留整个区块链历史所需的所有信息的说法充满信心。这些平面文件中的数据可以通过上述机制进行验证。那么如何管理平面文件的分发并确保历史数据易于检索呢？我们给出了两个激励分发和可检索性的论点：一是索引器将维护完整的历史数据，以便在未来 The Graph 协议中为子图/子流提供最大程度的支持；二是未来的平面文件共享数据服务将确保一个激励索引器销售这些数据的市场。

整合全节点的 Firehose 功能：我们目前正在进行的一个项目是将 Firehose 集成到全节点中。如同在 The Graph 中用于实现高性能索引的应用场景所证明的那样，Firehose 为与区块链数据的交互提供了一种新颖的方法。正如本文所示，Firehose 输出的平面文件还可以作为历史区块链数据的可共享和可验证存储格式。这进一步证实了将 Firehose 作为全节点功能能够为全节点操作员解锁新的效用维度。值得注意的是，Firehose 支持多个链，并且这个列表还在不断扩大，为各个链提供了一个通用接口。

参考阅读：

1.EIP-4444: Bound Historical Data in Execution Clients 1；

2.Example flat files；

3.Example era files；

4.StreamingFast Firehose data storage；

5.Era files specification；

6.Log In ERA - archival files for block and consensus data；

7.The Graph Network In Depth 2；

8.https://ethereum-magicians.org/t/eip-7542-eth-69-available-blocks-extended-protocol/；

9.https://substreams.streamingfast.io/。