在 Devin 中试用 DeepWiki 处理私有仓库
DeepWiki

base/node

菜单

组件

相关源文件

本页面提供了构成 Base 节点的主要组件的概述。它解释了核心组件的架构和它们之间的关系，以及它们如何协同工作以运行一个功能齐全的 Base 节点。有关特定组件的详细信息，请参阅其各自的专用页面：op-node、执行客户端和进程管理。

组件架构

Base 节点系统由两个主要组件协同工作，并辅以一个进程管理系统来协调它们。

  1. op-node - 负责 L1 数据处理和 L2 区块派生的 Optimism 节点组件。
  2. 执行客户端 - 处理交易的以太坊执行引擎（Geth、Reth 或 Nethermind）。
  3. 进程管理 - 使用 Supervisord 管理容器环境中的组件。

组件关系图

来源：README.md55-85 supervisord.conf1-18

核心组件

op-node

The op-node 是 Base 节点系统的 Rollup 节点组件。它通过以下方式充当以太坊 L1 和 Base L2 之间的桥梁：

  1. 连接到以太坊 L1 节点以检索区块数据。
  2. 处理 L1 数据以派生 L2 链。
  3. 通过 Engine API 与执行客户端通信。
  4. 公开 RPC 端点以提供节点状态和操作。

op-node 是确保 Base 节点根据共识规则和来自 Layer 1 的数据可用性正确遵循 Layer 2 链的组件。

来源：README.md57-58

执行客户端

执行客户端是一个以太坊执行引擎，负责处理和执行 Base L2 链上的交易。Base 节点支持三种不同的执行客户端。

执行客户端描述
GethGo Ethereum - 以太坊协议的 Go 实现。
RethRust Ethereum - 以太坊协议的 Rust 实现。
Nethermind一个用 C# 和 .NET 构建的高性能以太坊客户端。

所有支持的执行客户端都实现了 Engine API，这允许 op-node 与它们通信并提供 L2 区块以供执行。启动节点时，可以使用 CLIENT 环境变量来选择客户端。

来源：README.md71-78

进程管理

Base 节点使用 supervisord 来管理容器内的 op-node 和执行客户端进程。这种方法允许在单个容器中运行这两个组件，这对于 Kubernetes 部署或其他编排系统特别有用。

supervisord.conf 文件定义了这些进程的管理方式。

来源：supervisord.conf1-18 README.md96-106

组件通信

组件之间的通信遵循特定协议。

内部通信

op-node 和执行客户端通过 Engine API 进行通信，这是以太坊共识和执行客户端使用的相同接口。此通信使用 JWT 身份验证进行保护。

来源：README.md57-58 README.md114-122

外部通信

op-node 和执行客户端都公开 RPC 端点供外部用户进行交互。

  1. 执行客户端 RPC：端口 8545 - 标准以太坊 JSON-RPC API。
  2. 执行客户端 WebSocket：端口 8546 - 以太坊 API 的 WebSocket 接口。
  3. op-node RPC：端口 7545 - 特定于 Optimism 的 RPC 端点，包括 optimism_syncStatus。

来源：README.md82-85 README.md114-122

组件配置

每个组件都可以通过 .env.mainnet 或 .env.sepolia 文件中指定的环境变量进行配置，具体取决于目标网络。

关键配置参数包括

参数描述适用
OP_NODE_L1_ETH_RPC以太坊 L1 节点的 URL。op-node
NETWORK_ENV要使用的网络环境文件（.env.mainnet 或 .env.sepolia）。两者
CLIENT要使用的执行客户端（geth、reth 或 nethermind）。执行客户端
GETH_HOST_DATA_DIR用于存储链数据的目录。执行客户端
OP_NODE_L2_ENGINE_RPC执行客户端 Engine API 的 RPC 端点。op-node
OP_NODE_RPC_PORTop-node RPC 服务器的端口。op-node

当使用 supervisord 在单个容器中运行时，需要额外的配置以避免端口冲突并确保组件之间的正确通信。

来源：README.md57-64 README.md90-106

有关每个组件的详细信息，请参阅以下页面：