作为最著名的区块链索引协议，并在Web3中带来了事实上的开放API标准的The Graph，是一个完整的ETLQ(用于查询的Q)过程的开箱即用解决方案，它具有一组预定义的规则，包括可以提取什么数据、如何转换数据、在哪里加载数据以及以何种格式设计之后进行查询。它在大多数情况下为开发人员提供了便利，因为它只要求开发人员设计他们想要存储和编码处理程序函数的丰富数据的实际模式，但这种方法限制了可访问数据的范围，限制了选择观察、记录和监控数据的工具的灵活性。

Source: https://archive.devcon.org

在决定使用平台即服务，以及自行构建或启动许多不同的组件时，这是一个典型的权衡。好消息是，一些低级组件开发似乎不再被需要，但仍然为我们提供了上述所有必要的灵活性！

按照惯例，如果不将这些构建块付诸实践，我们就无法进行太多分析。如果没有正确设置我们尝试的开发工具，就不可能进行太多练习。有时（大部分时间）我们在这个过程中会遇到很多问题，无论文档写得多么好，你研究得多么透彻。尤其是在像Web3 这样快节奏的领域。而且特别是在合并之后。

现在要转向这篇文章更枯燥和实用的部分：一个关于如何使用Firehose沿着共识客户端启动区块数据提取的指南，在新的PoS世界中，这需要由执行客户端的一边来运行。

提取教程

在以太坊过渡到权益证明共识之前，只要遵循文档中的步骤，就可以很容易地设置Firehose实例来开始提取数据。然而，现在在Geth的最新版本中，“似乎需要一个共识客户端来正确地同步链，即使是发生在合并之前的区块”。

先决条件

在我们开始实际步骤之前，你可能需要检查以下内容：

• 由于本地运行Firehose实例也意味着运行一个完整的Geth节点，所以有关于硬件需求的建议；

• 我们选择使用Lighthouse作为共识客户端，指南中提供的命令是为Linux环境设计的；

• 我们在Ubuntu 22.04发行版上测试了下面的指南。

LFG

让我们为指南创建一个新目录。

$ mkdir firetorch; cd firetorch

1. 建立共识客户端-Lighthouse。

我们建议使用最新的标记版本，指南中使用的版本在命令中显示。

• 下载并提取一个合适的二进制文件。

$ wget -O lghths.tar.gz https://github.com/sigp/lighthouse/releases/download/v3.2.1/lighthouse-v3.2.1-x86_64-unknown-linux-gnu.tar.gz
$ tar -xf lghths.tar.gz

$ rm -rf lghths.tar.gz

使lighthouse可通过系统范围的调用访问，即“安装”它。

$ sudo mv lighthouse /usr/local/bin/

2. 设置执行客户端—Geth，使用Firehose读取器进行检测。

发布（对于以太坊主网，我们使用的是这种格式的最新标记版本：geth-v1.xx.xx-fh2.1）。

• 下载该bin，使其可执行，并“安装”它。

$ wget -O geth_linux https://github.com/streamingfast/go-ethereum/releases/download/geth-v1.10.26-fh2.1/geth_linux
$ chmod +x geth_linux
$ sudo mv geth_linux /usr/local/bin

3. 克隆示例配置

我们将使用由StreamingFast团队提供的准备好的脚本。除了这些脚本之外，对于Firehose本身，还有一些(几乎)现成的配置。

因此，我们克隆他们的repo，然后去特定的目录那里，清理所有不必要的文件(节省存储空间，我们将需要它来存储区块文件)。

$ git clone --depth 1 --branch v1.2.0 https://github.com/streamingfast/firehose-ethereum.git
$ mv firehose-ethereum/devel/sync-mainnet/* .
$ rm -rf firehose-ethereum/

该存储库还包含一个fireeth二进制文件，但我们建议用户自己跟踪它，并单独下载所需的版本。

4. 设置流水线

发布

• 下载并提取一个合适的二进制文件，启用系统范围的调用。

$ wget -O fireeth.tar.gz https://github.com/streamingfast/firehose-ethereum/releases/download/v1.2.0/fireeth_1.2.0_linux_x86_64.tar.gz
$ tar -xf fireeth.tar.gz
$ rm -rf fireeth.tar.gz
$ sudo mv fireeth /usr/local/bin/

5. 调整示例配置

我们克隆的sync-mainnet.yaml配置文件已准备好用于首次启动，现在还剩一个小细节：我们需要指定我们的检测执行节点可以通过系统范围的调用使用，就像在第2步中完成的那样。只需运行以下命令:

$ echo $'\n    # Update the reader-node-path to reference the geth binary for the chain and OS being targeted (if custom node client is needed)\n    reader-node-path: geth_linux' >> sync-mainnet.yaml

6. 启动共识客户端

为了更快地同步信标标头，我们从公共检查点引导共识客户端数据库(我们可以从自己信任的任何节点运营商那里获得一个)。

$ CHECKPOINT_SYNC_URL=https://sync-mainnet.beaconcha.in/ ./consensus.sh

出于某种原因，README指南建议我们“等待共识客户端正确同步，然后继续启动执行客户端同步”。鉴于这一点，我们试图修复 Lighthouse 因连接被拒绝状态而在引擎检查中失败的错误。

发生这种情况是因为 Lighthouse 实际上试图通过 Engine API 端口访问 Geth 并发现 Geth 没有响应，因此返回了错误。

因此，我们建议将lighthouse放在后台或打开另一个终端选项卡，并立即进行下一步。

此外，由于我们正在运行一个不参与质押的非验证信标节点，并且只是在试验数据提取，因此我们使用了社区贡献的标志，以消除不相关的错误消息。编辑consensus.sh脚本，在lighthouse启动命令的末尾添加这两个标志：

exec "$lighthouse"\
    beacon\
    --datadir="$ROOT/cs-data"\
    --debug-level=info\
    ...
    --execution-jwt="$ROOT/jwt.txt" "$@"\
    --disable-deposit-contract-sync\
    --execution-timeout-multiplier 5

我们可以在CLI中输入lighthouse bn—help;)来进行阅读。

7. 启动Firehose(以及扩展到一个检测过的 Geth 节点)

$ fireeth -c sync-mainnet.yaml start

(我们没有使用所提供的start.sh脚本，它从目录中启动fireeth实例，因为我们在第4步中自己设置了二进制文件)

我们应该能够看到信标标头的同步过程，然后开始提取区块并将它们合并到文件中。

我们刚刚开始用自己的Firehose实例提取区块数据，支持最新版本的共识和执行客户端，准备好开始与Eth Panda一起观察PoS网络。

Source：https://medium.com/@blocktorch/how-to-extract-on-chain-data-from-an-ethereum-node-6b710399e8b3

关于

ChinaDeFi - ChinaDeFi.com 是一个研究驱动的DeFi创新组织，同时我们也是区块链开发团队。每天从全球超过500个优质信息源的近900篇内容中，寻找思考更具深度、梳理更为系统的内容，以最快的速度同步到中国市场提供决策辅助材料。

本文首发于：https://mp.weixin.qq.com/s/-MBji0R1WOzBpAhbOTfzww