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

base/node

菜单

核心概念

相关源文件

本页面解释了 Base 作为以太坊 Layer 2 (L2) 解决方案所依据的基础概念。它涵盖了以太坊 (L1) 与 Base (L2) 之间的关系、rollups 以及 Base 节点系统中不同组件的作用。有关具体的安装说明，请参阅入门指南，有关各个组件的详细信息，请参阅组件。

Base 是什么？

Base 是一个安全、低成本、对开发者友好的以太坊 L2，旨在将下一个十亿用户带上链。它构建在 Optimism 的开源OP Stack之上，该堆栈实现了一种称为 optimistic rollup 的扩容解决方案。

来源：README.md5-7

L1 和 L2 的关系

理解 Base 是如何运作的，关键在于理解以太坊 (L1) 和 Base (L2) 之间的关系。

L1-L2 关系的要点

  1. 数据可用性：所有 Base 交易数据最终都会作为 calldata 发布到以太坊 L1，从而确保数据的可用性和安全性。

  2. 安全继承：Base 的安全性源于以太坊。通过将状态锚定到以太坊，Base 继承了以太坊的安全特性。

  3. 排序：虽然交易最初由排序器在 L2 上处理，但这些交易的官方排序和包含是由它们发布到 L1 来确定的。

  4. 最终性：Base 交易在其对应的批次交易在以太坊 L1 上最终确定后，方可获得最终性。

来源：.env.mainnet13-20 .env.sepolia13-16 README.md5-7 README.md57-59

Optimistic Rollups

Base 实现了一种 optimistic rollup，这是一种特定的 Layer 2 扩容解决方案。

Optimistic Rollups 的关键特征

  1. 默认乐观：交易被假定为有效，除非被证明无效。这允许在 L2 上立即确认交易，同时保持安全性。

  2. 欺诈证明：该系统在挑战期（通常为 7 天）内允许欺诈证明，在此期间任何人都可以通过提交证明来挑战无效的状态转换。

  3. 批量处理：交易被批量处理，然后发布到 L1，将 L1 的 Gas 成本分摊到许多 L2 交易中。

  4. 数据压缩：交易数据在发布到 L1 之前会被压缩，进一步降低成本。

  5. EVM 等价性：Base 保持与以太坊虚拟机 (EVM) 的兼容性，允许现有的以太坊智能合约和工具以最小的修改正常工作。

来源：README.md5-7

Base 节点组件

Base 节点由两个主要组件组成，它们协同工作以处理和验证 L2 交易。

op-node

op-node 负责

  1. L1 数据处理：读取和处理以太坊 L1 的数据以推导出 L2 状态。
  2. 区块派生：根据 L1 链上的交易数据创建 L2 区块。
  3. 与排序器交互：从 Base 排序器接收交易数据。
  4. P2P 通信：与网络中的其他节点同步。
  5. 最终性跟踪：监控 L1 链的最终性信息。

执行客户端

执行客户端（可以是 Geth、Reth 或 Nethermind）负责

  1. 交易执行：执行实际的 L2 交易。
  2. 状态管理：维护 L2 状态（账户、余额、合约存储等）。
  3. RPC 接口：提供 JSON-RPC 接口供用户与 L2 链进行交互。
  4. EVM 兼容性：确保与以太坊智能合约和工具的兼容性。

组件之间的身份验证

op-node 和执行客户端使用 Engine API 进行通信，该 API 使用 JWT (JSON Web Token) 进行身份验证。这确保只有授权的 op-node 才能向执行客户端提交区块。

来源：README.md71-78 .env.mainnet22-26 .env.sepolia21-25

Base 节点中的数据流

了解数据如何流经系统对于掌握 Base 节点如何运行至关重要。

数据流的关键方面

  1. 从 L1 到 L2 的推导：op-node 读取发布在 L1 上的交易数据，并利用这些数据推导出 L2 状态。

  2. Engine API：op-node 使用 Engine API 与执行客户端进行通信，这是以太坊共识客户端与执行客户端通信时使用的相同接口。

  3. 交易处理:

    • 用户交易直接提交给执行客户端。
    • 执行客户端将它们添加到其内存池中。
    • op-node 决定哪些交易应包含在 L2 区块中。
    • 执行客户端在 op-node 的指示下执行这些交易。

  4. 同步：当节点启动时，它需要通过以下方式与网络同步：

    • 读取历史 L1 数据以推导 L2 状态。
    • 或者，它可以从快照恢复，然后同步剩余的区块。

来源：README.md112-122 .env.mainnet50-52 .env.sepolia44-50

节点同步

Base 节点有多种方式可以与网络同步。

完整派生同步

在此模式下，节点从 L1 数据派生整个 L2 状态。

  1. op-node 读取所有相关的 L1 区块。
  2. 它根据这些 L1 数据派生 L2 区块。
  3. 它将这些 L2 区块发送给执行客户端以执行。

这是最安全的方法，但可能需要很长时间。

快照同步

为了加快同步速度，节点可以从受信任的快照开始。

  1. 将 L2 状态的快照下载到特定区块。
  2. 将快照导入执行客户端。
  3. 从 L1 数据派生剩余的区块。

执行层同步

为了更快地同步，节点还可以使用执行层同步。

  1. 节点连接到 Base P2P 网络中的对等节点。
  2. 它直接从这些对等节点下载 L2 区块。
  3. 这可以避免从 L1 推导所有区块的需要。

通过设置 OP_NODE_SYNCMODE=execution-layer 并配置适当的引导节点来启用此功能。

信任 RPC 选项

在不需要完全验证的情况下，或者在使用不支持存储证明的 L1 节点时，可以启用 OP_NODE_L1_TRUST_RPC 选项。这仅应用于完全受信任的 L1 节点。

来源：README.md108-111 .env.mainnet43-52 .env.sepolia39-50

网络配置

Base 支持多个网络，每个网络都有特定的配置

网络状态描述
主网✅生产网络
Sepolia 测试网✅开发测试网络

每个网络都有其特定的配置，包括

  1. 引导节点：P2P 发现的初始对等节点。
  2. 排序器 URL：用于从排序器获取交易数据的端点。
  3. 网络 ID：每个网络的唯一标识符。

使用 NETWORK_ENV 环境变量来选择适当的配置。

# For mainnet:
export NETWORK_ENV=.env.mainnet
# For testnet:
export NETWORK_ENV=.env.sepolia

来源：README.md48-53 README.md58-64 .env.mainnet1-4 .env.sepolia1-4

数据持久性和管理

Base 节点将其数据存储在持久化目录中，该目录默认为 ${PROJECT_ROOT}/geth-data。这确保了节点数据在重启后得以保留。

为了加快节点设置速度，可以使用链状态的快照。这些快照可以提取到数据目录中，以避免从头开始完全同步的需要。

来源：README.md91-94 README.md108-111

与 Optimism OP Stack 的关系

Base 构建在 Optimism OP Stack 之上，这是一个用于构建 optimistic rollup L2 解决方案的开源框架。这意味着 Base 继承了 Optimism 的许多设计原则和架构决策，同时为自身用例做出了特定的选择和优化。

Base 使用的 OP Stack 的关键组件包括

  1. op-node：从 L1 数据派生 L2 链的共识客户端。
  2. 执行客户端：处理 L2 交易的兼容执行客户端。
  3. 批次提交协议：将交易批次提交到 L1 的协议。

来源：README.md5-7