Reth 以太坊执行客户端：架构、节点搭建与 RPC 运维

Reth 是什么以及它适合放在哪里

Reth（Rust Ethereum 的缩写）是一个以太坊执行层客户端。它负责交易执行、状态存储、EVM 以及应用程序查询的 JSON-RPC 接口。它不是共识客户端：它必须与实现 Engine API 的信标/共识客户端配对使用，后者处理分叉选择、验证者职责和区块 gossip。

该项目由 Paradigm 和广泛的贡献者群体公开开发，并以 Apache/MIT 许可证分发。其宣称的设计目标是模块化、高性能和对贡献者友好。由于代码库组织为独立的 crate，相同的组件可以组装成标准的以太坊全节点、归档节点或定制的 EVM 兼容链。

在继续之前有一个命名上的注意事项：代币代码 "rETH"（Rocket Pool ETH）与 Reth 客户端无关。如果您是来寻找流动性质押代币价格的，那不是本主题。以下所有内容都涉及节点软件。

• 执行客户端：执行交易、维护状态、提供 JSON-RPC 服务。
• 需要通过 Engine API 连接共识客户端。
• 根据修剪配置支持全节点和归档模式。
• 模块化的 crate 允许自定义节点和执行扩展（ExEx）。

假设与前提条件

本指南假设您对 Linux 主机拥有管理权限，对以太坊的执行/共识分离有基本了解，并且已安装或准备安装共识客户端。它还假设您熟悉 systemd、防火墙规则和阅读日志。

硬件要求因模式而异。全节点需要的磁盘空间远多于轻客户端，并且受益于快速的 NVMe 存储；归档节点需要更多。与其引用随链增长和客户端发布而变化的固定数字，不如在配置前查看 Reth 官方文档中的当前要求，然后为存储预留增长空间。内存和 CPU 应根据您的 RPC 工作负载而不仅仅是同步来配置。

• 支持 Engine API 的共识客户端（信标节点）。
• 执行客户端和共识客户端之间共享的 JWT 密钥。
• 持久、快速的本地磁盘；避免对数据库使用网络附加存储。
• 用于对等发现和快照同步的出站互联网访问。

心智模型形式的模块化架构

将 Reth 视为一个具有可替换阶段的管道。网络和区块下载馈入一个分阶段同步管道，该管道执行区块并写入状态。存储层持久化区块头、区块体、收据和状态。顶层是 RPC 服务器，它从该存储读取并可进行扩展。

分阶段同步设计是关键的操作概念。Reth 不是从创世区块开始严格按顺序一次性执行每个区块，而是分阶段处理链（区块头、区块体、发送者、执行等），每个阶段都可以恢复。这就是为什么同步进度按阶段报告，以及为什么重启通常会恢复而不是重新开始。当您诊断同步缓慢或停滞时，通常是在诊断某个阶段。

执行扩展机制（ExEx）允许您订阅已提交的区块并在进程内运行自定义逻辑，这对索引器和链下服务很有用。不过，对大多数运维人员来说，实际接触面是 CLI、配置文件和 RPC API。

安装 Reth 并准备主机

在存在 formula 的地方通过包管理器安装，或者如果需要特定提交则从源码构建。以下命令使用占位符；请替换为您自己的数据目录和 JWT 路径。

创建一个专用服务用户、一个数据目录和一个 JWT 密钥。执行客户端和共识客户端的 JWT 密钥必须相同，并且应仅对这些服务可读。

# Example host preparation (adjust paths and user to your environment)
sudo useradd --system --home /var/lib/reth reth
sudo mkdir -p /var/lib/reth/data /var/lib/reth/jwt
sudo openssl rand -hex 32 | sudo tee /var/lib/reth/jwt/jwt.hex > /dev/null
sudo chown -R reth:reth /var/lib/reth
sudo chmod 600 /var/lib/reth/jwt/jwt.hex

# Install via Homebrew on macOS/Linux where available
brew install paradigmxyz/brew/reth

# Or build from source
# git clone https://github.com/paradigmxyz/reth && cd reth
# cargo build --release --locked

运行启用 JSON-RPC 的节点

使用显式数据目录、为共识客户端启用 Engine API，并仅启用您实际需要的 RPC 命名空间来启动 Reth。暴露 eth、net 和 web3 对于应用后端是典型的；debug 和 trace 开销很大，应有意启用。

默认将 HTTP 服务器绑定到 localhost，如果需要远程访问，则在其前面放置反向代理。下面的示例保持 RPC 本地，并将 Engine API 指向共识客户端的认证端口。

reth node \
  --datadir /var/lib/reth/data \
  --authrpc.addr 127.0.0.1 \
  --authrpc.port 8551 \
  --authrpc.jwtsecret /var/lib/reth/jwt/jwt.hex \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3 \
  --metrics 127.0.0.1:9001

验证节点是否健康

验证分为三层：进程正在运行、执行客户端正在跟随链头、RPC 正确响应。首先检查日志中是否有 Engine API 认证错误，这通常意味着 JWT 密钥与共识客户端的副本不匹配。

然后查询 RPC。已同步的节点返回一个随时间推进的近期区块号，并且 eth_syncing 返回 false。将报告的头区块与公共区块浏览器进行比较，以确认您没有悄悄落后。

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_syncing","params":[]}'

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"web3_clientVersion","params":[]}'

同步与 RPC 的可复现测量流程

已发布的性能声明只有相对于硬件、对等节点和工作负载才有意义。与其相信博客文章中的数字，不如在您自己的主机上测量并记录条件。以下流程生成一个结果表，您可以在不同配置之间进行比较。

首先，记录环境：CPU 型号、RAM、磁盘类型、内核版本、Reth 版本、共识客户端版本和对等节点数量。其次，通过从干净数据库以固定间隔采样区块号并计算每个阶段的每分钟区块数来测量同步。第三，通过发出一批固定的只读调用（例如 eth_blockNumber、eth_getBlockByNumber 和针对固定地址的 eth_getBalance）并记录至少几百个样本的 p50 和 p95 来测量 RPC 延迟。第四，在任何配置更改后重复。

将结果记录在如下表中。将单元格留空以填写您的测量值；不要从其他地方复制数字。

• | 指标 | 配置 A | 配置 B |
• | 同步区块/分钟（执行阶段） | 测量值 | 测量值 |
• | 从干净数据库到链头的时间 | 测量值 | 测量值 |
• | RPC p50 延迟（毫秒） | 测量值 | 测量值 |
• | RPC p95 延迟（毫秒） | 测量值 | 测量值 |
• | 峰值 RSS（GB） | 测量值 | 测量值 |
• | 同步后磁盘使用量（GB） | 测量值 | 测量值 |

安全地向应用程序暴露 RPC

为您的自有应用程序提供服务的节点不应与公共端点使用相同的暴露面。将 RPC 绑定到 localhost，在反向代理处终止 TLS，添加身份验证或 IP 允许列表，并按客户端进行速率限制。禁用您不需要的命名空间；debug 和 trace 可用于耗尽内存和 CPU。

如果您不想自己运维节点，托管端点可以消除同步、升级和故障转移的负担。OnFinality 的 RPC API 服务 提供多链端点，您可以在 RPC 定价页面 上比较套餐。对于需要隔离容量的团队，专用节点 是相关选项。如果您仍在选择提供商，RPC Assistant 的 最佳以太坊 RPC API 指南涵盖了选择标准。

// Minimal client-side health check against your own RPC_URL
const RPC_URL = process.env.RPC_URL; // e.g. http://127.0.0.1:8545

async function head() {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_blockNumber', params: [] }),
  });
  const { result } = await res.json();
  return parseInt(result, 16);
}

const a = await head();
await new Promise((r) => setTimeout(r, 15000));
const b = await head();
console.log({ start: a, end: b, advanced: b - a });

排查常见的 Reth 问题

大多数运维问题都属于少数几类。按顺序逐一处理，而不是同时更改多个变量。

Engine API 认证失败。 执行客户端和共识客户端必须共享相同的 JWT 密钥文件。确认两者指向同一路径，并且权限允许两个服务读取它。

同步似乎停滞。 检查日志中哪个阶段处于活动状态。执行阶段停滞通常表明磁盘饱和或内存不足；下载阶段停滞则指向对等节点或网络问题。重启会从最后提交的阶段恢复，因此避免将清空数据库作为第一反应。

负载下 RPC 超时。 确认您没有启用重型命名空间，检查反向代理的超时是否比客户端短，并在更改前后测量 p95 延迟。如果节点受 CPU 限制，在负载均衡器后添加副本通常比无限期调整单个实例更好。

磁盘意外填满。 归档模式和收据及状态的长期保留会稳步增长。将磁盘使用情况作为一级指标进行监控，并在容量不足之前提前告警。

局限性与权衡

Reth 是一个完整的执行客户端，而不是交钥匙的 RPC 产品。您仍然需要负责升级、监控、备份和事件响应。其性能特征在很大程度上取决于存储和内存，因此慢速磁盘上的快速客户端不会提供您期望的吞吐量。

运行自己的节点为您提供数据主权、自定义命名空间以及进程内扩展行为的能力。托管端点则用部分控制权换取运维简便性和弹性容量。两者都不是普遍正确的；决策取决于查询量、合规要求以及您可以投入节点运维的工程时间。

最后，客户端多样性对整个网络很重要。在不同环境中与其他执行客户端一起运行 Reth 可降低相关故障风险，这也是许多基础设施团队有意混合客户端而不是标准化为单一客户端的原因。

后续步骤

一旦您的节点同步并验证完毕，下一步工作是运维加固：具有重启策略的 systemd 单元、日志轮转、Prometheus 抓取指标端点、对链头滞后和磁盘使用情况告警，以及有文档记录的升级流程。如果您计划为多个应用程序提供服务，请在 RPC 前面放置缓存和速率限制层。

对于扩展到以太坊之外的团队，在决定自行托管什么之前，请查看可用的 网络 和更广泛的 区块链节点托管指南。如果您想要具体的端点推荐而不是自己构建的路径，RPC Assistant 可以列出提供商候选名单；本页面有意止步于方法论。