L2-15: Run Your Own Node（运行自己的节点）

1. 问题

绝大多数以太坊开发者（和所有普通用户）依赖 Infura、Alchemy 或 QuickNode 等第三方 RPC 提供商来与以太坊交互。这些服务虽然便利，但引入了中心化依赖：你的 DApp 只有在这个服务商在线且没有限流你的 API Key 时才能正常工作。更根本的是，你将自己置于"信任某个公司告诉你区块链的状态"的位置——你的 MetaMask 钱包显示的余额，实际上是 Infura 告诉它的。

运行自己的以太坊全节点意味着你拥有自己的"区块链真相源"——你的节点独立验证每一个区块、每一笔交易、每一个状态变更。你的 RPC 调用不需要 API Key、不受速率限制、不会有每月调用配额。你可以用最低的延迟读取链上数据（本地网络 vs 互联网），并且掌控自己的数据隐私。

本挑战（参考 scripts/run-node.md）要求完成从零搭建一个以太坊全节点的全过程——包括执行客户端、共识客户端的安装配置、JWT 认证、同步监控和 Docker 化部署。

2. 原因

自托管节点是从"Web3 用户"到"Web3 基础设施运营者"的身份转变。当你运行自己的节点时，你真正理解了以太坊的两层架构：执行层（Execution Layer，处理交易和执行 EVM）和共识层（Consensus Layer，处理 PoS 共识和区块最终性）。这两个层通过 Engine API（基于 JWT 认证）通信——这不是课本上的抽象概念，而是你手动配置的 --authrpc.jwtsecret 参数。

运行节点也是成为专业区块链工程师的必要步骤。在 MEV 搜索、交易模拟、高频 DeFi 策略、和 L2 排序器开发中，拥有自己的高可用节点是基础设施的前提。你的节点不仅提供 RPC 访问——它还维护着完整的 mempool（待处理交易池）、提供交易追踪（tracing）API、能执行复杂的 eth_call 模拟（包括状态覆写）。

更重要的是，自托管节点是对网络去中心化的贡献。每一个新加入的全节点都让以太坊网络更抗审查、更多样化。当足够多的人运行自己的节点时，就不存在"单一 RPC 提供商可以决定你看到的区块链状态"的风险。

3. 方案

核心架构：执行客户端 + 共识客户端

以太坊全节点
├── 执行客户端 (EL)     ← Geth / Nethermind / Besu / Erigon
│   ├── 维护世界状态 (账户余额、合约存储)
│   ├── 执行 EVM 交易
│   ├── 管理交易池 (mempool)
│   ├── 提供 JSON-RPC API (eth_call, eth_sendRawTransaction...)
│   └── 通过 Engine API (端口 8551) 与 CL 通信
│
└── 共识客户端 (CL)     ← Lighthouse / Prysm / Teku / Nimbus
    ├── 跟踪 PoS 链 (Beacon Chain)
    ├── 参与区块验证和最终性
    ├── 通过 Engine API 通知 EL 新区块
    └── 提供 Beacon API (端口 5052)

推荐方案：Geth + Lighthouse

步骤 1：安装执行客户端 Geth

bash

# Ubuntu/Debian
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install -y ethereum

# macOS
brew install ethereum

# 或从源码编译
git clone https://github.com/ethereum/go-ethereum.git
cd go-ethereum
make geth
sudo cp build/bin/geth /usr/local/bin/

步骤 2：安装共识客户端 Lighthouse

bash

curl -LO https://github.com/sigp/lighthouse/releases/latest/download/lighthouse-linux-x86_64
chmod +x lighthouse-linux-x86_64
sudo mv lighthouse-linux-x86_64 /usr/local/bin/lighthouse

步骤 3：配置 JWT Secret（EL 与 CL 之间的认证）

bash

sudo mkdir -p /var/lib/ethereum
openssl rand -hex 32 | sudo tee /var/lib/ethereum/jwt.hex > /dev/null
# 这个 jwt.hex 文件必须对 EL 和 CL 都可读
# EL 读取它来验证 CL 的 Engine API 调用
# CL 读取它来签署对 EL 的 Engine API 请求

步骤 4：启动执行客户端

bash

geth \
  --mainnet \                          # 主网（测试网用 --sepolia）
  --datadir /data/ethereum \           # 区块链数据存储路径
  --http \                             # 启用 HTTP JSON-RPC
  --http.api eth,net,engine,admin \    # 暴露的 API 命名空间
  --http.addr 0.0.0.0 \               # 监听所有接口（允许外部访问）
  --authrpc.jwtsecret /var/lib/ethereum/jwt.hex \  # JWT 密钥路径
  --syncmode snap \                    # 快照同步（推荐）
  --cache 4096                         # 内存缓存 (MB)

关键参数说明：

--syncmode snap：快照同步——下载最新状态快照而非从头重放所有交易。同步时间约 12-24 小时
--http.api eth,net,engine,admin：engine 是 CL 通信必需的，eth 是标准 RPC，net 和 admin 是运维 API
--cache 4096：为状态树分配 4GB 内存缓存，更高的缓存 = 更快的同步

步骤 5：启动共识客户端

bash

lighthouse bn \
  --network mainnet \                           # 主网
  --datadir /data/lighthouse \                  # Beacon 链数据
  --http \                                      # 启用 Beacon API
  --execution-endpoint http://localhost:8551 \  # EL Engine API 地址
  --execution-jwt /var/lib/ethereum/jwt.hex \  # JWT 密钥路径
  --checkpoint-sync-url https://sync-mainnet.beaconcha.in  # 检查点同步加速

--checkpoint-sync-url 是关键加速参数：它从一个可信的检查点开始同步 Beacon 链（而非从创世区块），将 CL 同步时间从数天缩短到 2-3 小时。检查点由社区信任的节点提供（beaconcha.in 是 beaconcha.in 浏览器的基础设施）。

步骤 6：验证同步状态

bash

# 检查 EL 同步进度
geth attach --exec "eth.syncing"
# 返回 false → 已同步完成
# 返回 { currentBlock: ..., highestBlock: ... } → 正在同步中

# 检查 CL 同步状态
curl http://localhost:5052/eth/v1/node/syncing
# {"data":{"head_slot":"...","sync_distance":"..."}}

硬件要求

组件	最低配置	推荐配置
CPU	4 核	8+ 核
RAM	16 GB	32 GB
存储	2 TB SSD (NVMe)	4 TB NVMe
网络	25 Mbps	100+ Mbps 不限流量

NVMe SSD 至关重要——SATA SSD 的随机 IOPS 不足会导致同步速度极慢。存储空间以每周约 2.5 GB 的速度增长（以太坊状态增长），4 TB 提供约 2-3 年的余量。

Docker Compose 快速部署

yaml

version: '3.8'
services:
  geth:
    image: ethereum/client-go:latest
    volumes:
      - /data/geth:/root/.ethereum
      - /var/lib/ethereum/jwt.hex:/jwt.hex
    command: >
      --mainnet --http --http.addr 0.0.0.0
      --http.vhosts="*" --http.api eth,net,web3
      --authrpc.jwtsecret /jwt.hex
      --syncmode snap --cache 4096
    ports:
      - "8545:8545"     # HTTP RPC
      - "30303:30303"   # P2P TCP
      - "30303:30303/udp"  # P2P UDP

  lighthouse:
    image: sigp/lighthouse:latest
    volumes:
      - /data/lighthouse:/root/.lighthouse
      - /var/lib/ethereum/jwt.hex:/jwt.hex
    command: >
      lighthouse bn --network mainnet
      --execution-endpoint http://geth:8551
      --execution-jwt /jwt.hex
      --checkpoint-sync-url https://sync-mainnet.beaconcha.in
    ports:
      - "5052:5052"

bash

docker compose up -d      # 启动
docker compose logs -f    # 查看日志

4. 遭遇的陷阱

同步时间远超预期：快照同步文档说 12 小时，但实际可能 2-3 天——取决于硬件 IOPS 和对等节点质量
存储空间耗尽：主网状态以每周约 2.5 GB 增长——2 TB 盘在 12-18 个月后可能不够；当磁盘满时 Geth 会崩溃而非优雅降级
JWT 配置错误：EL 和 CL 的 --authrpc.jwtsecret 指向不同文件，或文件权限不可读——两者无法通信，节点停滞
防火墙/P2P 可达性：端口 30303 (TCP/UDP) 未开放 → 对等节点只有出站连接，没有入站连接——发现速度慢、同步慢
快照同步的安全假设：快照同步不验证同步点之前的历史状态——它信任快照点是正确的
RPC 暴露风险：--http.addr 0.0.0.0 将 RPC 暴露到公网——没有防火墙保护时，任何人都可以使用你的节点（可能造成 DoS）

5. 陷阱的原因

存储空间的线性增长是以太坊状态的"账户模型"特性决定的。不同于 UTXO 模型（比特币的未花费输出可以被修剪），以太坊的每个账户状态（余额、nonce、合约存储）都必须持续维护。即使一个账户多年未使用，它的存储槽仍然占用磁盘空间。当磁盘 100% 满时，Geth 的 LevelDB 数据库会报告 I/O 错误，节点进程终止——你必须手动清理或扩容。

JWT 配置错误的最常见原因是路径不匹配——EL 启动脚本使用 /var/lib/ethereum/jwt.hex，CL 启动脚本使用 /etc/ethereum/jwt.hex，两者指向不同的文件（一个存在，另一个可能为空或内容不同）。另一个常见问题是 Docker 卷挂载——容器内路径 /jwt.hex 与宿主机路径需要正确映射。

P2P 可达性影响同步速度的原因：以太坊发现协议 (discv5) 是双向的——你的节点不仅需要找到其他节点，其他节点也需要能找到你的节点。默认情况下，启动后你的节点向 bootstrap 节点发出查询，获取初始对等节点列表。如果端口 30303 不可达（NAT/防火墙），其他节点无法主动连接你，你只能依靠出站连接到已发现的对等节点——这大幅减少了对等节点池的多样性。

快照同步是安全与速度的权衡：完全同步 (--syncmode full) 从创世区块重放每一笔交易——这需要数周时间和数 TB 空间，但验证了全部历史。快照同步从最近的"安全点"开始——这个"安全点"由 Geth 团队硬编码在代码中，你信任 Geth 团队没有恶意插入错误的状态快照。

6. 如何解决陷阱

配置自动磁盘监控，在磁盘满之前得到预警：

bash

# crontab: 每天检查磁盘使用
0 9 * * * df -h /data/ethereum | mail -s "Disk Report" admin@example.com

或使用 Prometheus + Grafana 监控系统（Geth 导出 Prometheus metrics 在端口 6060）。

使用 --checkpoint-sync-url 加速 CL 同步，但从多个来源交叉验证检查点的可信性。beaconcha.in 和 ethstaker.cc 都提供公有的 checkpoint sync 端点。

确保 JWT 一致性：使用环境变量或配置文件统一管理 JWT 路径：

bash

export JWT_PATH=/var/lib/ethereum/jwt.hex
geth --authrpc.jwtsecret $JWT_PATH ...
lighthouse bn --execution-jwt $JWT_PATH ...

配置 NAT 穿透解决 P2P 可达性：

bash

geth --nat extip:<your-public-ip>  # 手动指定公网 IP
# 或在路由器上启用 UPnP

RPC 安全加固：生产环境不暴露 personal 和 admin 命名空间；使用反向代理（Nginx）添加认证层：

bash

geth --http.api eth,net --ws.api eth,net
# 仅暴露必需的 API 命名空间
# personal: 账户管理（绝对不暴露）
# admin: 节点管理（仅本地访问）
# txpool: 交易池内容（可能敏感）

建立备份和恢复计划：定期备份 datadir/chaindata（使用 geth export 导出快照），以便在磁盘故障或数据损坏时恢复。

7. 技术要点

要点	说明
EL + CL 双客户端架构	执行层 (Geth) + 共识层 (Lighthouse) = 完整验证节点
Engine API	EL 端口 8551，通过 JWT 认证与 CL 通信
JWT 密钥	`openssl rand -hex 32` 生成，EL 和 CL 必须使用同一文件
快照同步 (snap sync)	~12-24 小时，下载状态快照而非重放所有历史交易
完全同步 (full sync)	数周时间，从创世区块重放全部交易，完整验证所有历史
检查点同步	`--checkpoint-sync-url` 从信任的检查点开始，CL 同步仅需 2-3 小时
P2P 端口	30303 TCP/UDP，需要双向可达以最大化对等节点池
RPC 端口	8545 (HTTP)，用户名空间控制暴露的功能范围
Docker 化	`ethereum/client-go` + `sigp/lighthouse` 官方镜像，compose up 即可

L2-15: Run Your Own Node（运行自己的节点） #

1. 问题 #

2. 原因 #

3. 方案 #

核心架构：执行客户端 + 共识客户端 #

推荐方案：Geth + Lighthouse #

步骤 1：安装执行客户端 Geth #

步骤 2：安装共识客户端 Lighthouse #

步骤 3：配置 JWT Secret（EL 与 CL 之间的认证） #

步骤 4：启动执行客户端 #

步骤 5：启动共识客户端 #

步骤 6：验证同步状态 #

硬件要求 #

Docker Compose 快速部署 #

4. 遭遇的陷阱 #

5. 陷阱的原因 #

6. 如何解决陷阱 #

7. 技术要点 #

L2-15: Run Your Own Node（运行自己的节点）

1. 问题

2. 原因

3. 方案

核心架构：执行客户端 + 共识客户端

推荐方案：Geth + Lighthouse

步骤 1：安装执行客户端 Geth

步骤 2：安装共识客户端 Lighthouse

步骤 3：配置 JWT Secret（EL 与 CL 之间的认证）

步骤 4：启动执行客户端

步骤 5：启动共识客户端

步骤 6：验证同步状态

硬件要求

Docker Compose 快速部署

4. 遭遇的陷阱

5. 陷阱的原因

6. 如何解决陷阱

7. 技术要点