作为最著名的区块链索引协议,并在 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
建立共识客户端 -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/
设置执行客户端—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
克隆示例配置
我们将使用由 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
二进制文件,但我们建议用户自己跟踪它,并单独下载所需的版本。
设置流水线
发布
下载并提取一个合适的二进制文件,启用系统范围的调用。
$ 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/
调整示例配置
我们克隆的 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
启动共识客户端
为了更快地同步信标标头,我们从公共检查点引导共识客户端数据库 ( 我们可以从自己信任的任何节点运营商那里获得一个 )。
$ 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;) 来进行阅读。
启动 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 篇内容中,寻找思考更具深度、梳理更为系统的内容,以最快的速度同步到中国市场提供决策辅助材料。
Layer 2 道友 - 欢迎对 Layer 2 感兴趣的区块链技术爱好者、研究分析人与 Gavin(微信: chinadefi)联系,共同探讨 Layer 2 带来的落地机遇。敬请关注我们的微信公众号 “去中心化金融社区”。
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。