Etherlink：Tezos 上 EVM Layer 2 实用指南

Etherlink 是什么以及本指南涵盖的内容

Etherlink 是 Tezos 的 Layer 2 执行层。它是非托管的，由 Tezos Smart Rollup 技术驱动，并且兼容 EVM，因此可以使用 MetaMask、Hardhat 和 Foundry 等熟悉的以太坊工具。同一条区块链可通过两个接口访问：EVM 接口和 Michelson 接口。

本指南面向需要连接 Etherlink、部署或调用合约、验证交易结果并诊断故障的开发者和运维人员。假设你基本熟悉 EVM 概念（如地址、gas 和 JSON-RPC），并且能够运行命令行工具。本指南不假设任何特定提供商；端点选择是一个单独的决定，将在后面讨论。

• 范围：在 Etherlink 上的连接、部署、验证和故障排查。
• 不涉及：代币价格分析、收益策略和治理投票机制。
• 假设：你拥有 EVM 钱包，并在目标网络上拥有已注资的账户。

心智模型：一条链、两个接口、L1 结算

将 Etherlink 视为一条有两个前门的区块链。EVM 门接受以太坊风格的交易和 JSON-RPC 调用。Michelson 门接受 Tezos 风格的交互。两扇门通向同一状态，这就是资产可以在 Etherlink 和 Tezos L1 主网之间移动，以及兼容 EVM 的链可以互操作的原因。

结算发生在 Tezos Layer 1 上。Etherlink 使用 Smart Rollups，这是由 Tezos 实现的内置乐观 rollup 机制。排序器提供低延迟确认，而最终性和安全性最终取决于 Tezos L1。这种分离在操作上很重要：交易可能在执行层显示为已确认，但在共识层尚未结算。

文档描述执行层确认时间约为 500 毫秒，L1 结算时间约为 6 秒，并有一个实验性的即时确认功能，可在约 50 毫秒内提供预确认。将这些视为文档化的特性，而不是针对你特定工作负载的保证。在你自己的路径上进行测量。

• 执行层：EVM 交易被排序和执行的地方。
• 共识层：Tezos L1，结算和安全性的锚定处。
• 排序器：提供快速确认；它不是最终的事实来源。
• 治理：与 Tezos 链上治理集成，用于协议变更。

先决条件和环境假设

在运行以下流程之前，准备一个工作环境。你需要 Node.js 和 npm 用于 JavaScript 示例，curl 用于 RPC 检查，以及一个 EVM 钱包或私钥用于部署。将机密信息排除在 shell 历史记录和源代码管理之外。

你还需要一个 Etherlink 的 RPC 端点。示例使用占位符 RPC_URL。不要在生产环境中硬编码公共端点；根据你的延迟、速率限制和可靠性要求选择提供商。如需具体的端点推荐，请使用 RPC Assistant，而不是猜测。

• Node.js 18 或更高版本以及 npm。
• 已安装 curl。
• 在 Etherlink 上拥有已注资的账户用于部署测试。
• 一个你控制或信任的 RPC_URL，以及存储在环境变量中的 PRIVATE_KEY。

通过 JSON-RPC 连接 Etherlink

确认连接性的最快方法是标准 JSON-RPC 调用。Etherlink 兼容 EVM，因此 eth_chainId 和 eth_blockNumber 的行为符合预期。运行以下命令并记录链 ID 和区块号。链 ID 是你在钱包和部署脚本中配置的内容。

如果调用失败，问题通常出在端点、网络选择或客户端前面的代理。先用 curl 测试，然后再使用库。

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

使用 ethers 部署和调用合约

一个最小的部署可以确认你的工具链、账户和 RPC 路径都能协同工作。下面的脚本使用 ethers 读取链 ID、发送交易并等待收据。将 RPC_URL 和 PRIVATE_KEY 替换为你自己的值。合约字节码有意省略；请使用你自己编译的产物。

关键的验证点是收据状态。状态为 1 表示交易在执行层成功执行。这本身并不证明 L1 结算，后者是单独的检查。

import { JsonRpcProvider, Wallet, ContractFactory } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);
const wallet = new Wallet(process.env.PRIVATE_KEY, provider);

const chainId = (await provider.getNetwork()).chainId;
console.log("chainId", chainId.toString());

const factory = new ContractFactory(abi, bytecode, wallet);
const contract = await factory.deploy();
const deployTx = contract.deploymentTransaction();
console.log("deploy tx", deployTx.hash);

const receipt = await deployTx.wait();
console.log("status", receipt.status, "block", receipt.blockNumber);

验证交易状态和结算

验证有两个层面。首先，使用 eth_getTransactionReceipt 确认执行层收据。其次，在收据区块之后读取相关合约或余额，确认交易已反映在链状态中。对于结算敏感的操作，还要根据 Tezos 工具和 Etherlink 文档检查 L1 侧。

使用以下流程并将结果记录在表格中。不要凭记忆填写数字；运行每个步骤并粘贴实际输出。表格是模板，不是对性能的声明。

• 步骤 1：调用 eth_getTransactionReceipt 并记录 status、blockNumber 和 gasUsed。
• 步骤 2：在收据区块读取受影响的状态并记录值。
• 步骤 3：短暂延迟后重复读取并确认一致性。
• 步骤 4：对于结算检查，遵循文档化的 Tezos L1 验证路径。

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["TX_HASH"]}'

用于自行测量的结果表格模板

使用此 Markdown 表格记录你自己的观察结果。在测量之前将单元格留空。列将执行层确认与 L1 结算分开，以免混淆两者。

排查常见的 Etherlink 故障

大多数故障属于几类：网络错误、gas 资金不足、nonce 冲突和端点问题。由于 Etherlink 兼容 EVM，标准的以太坊调试方法适用，但当交易看起来卡住时，你还必须考虑 L1 结算层。

由外向内排查。确认端点响应，然后确认账户和 nonce，再确认交易收据。如果执行层显示成功但你的应用程序没有，检查你是否在正确的区块读取状态。

• 连接被拒绝或超时：验证 RPC_URL 以及任何代理或防火墙。
• 链错误：确认 eth_chainId 与你配置的网络匹配。
• 资金不足：在发送前检查用于 gas 的原生余额。
• Nonce 过低或过高：检查待处理交易并重置 nonce。
• 收据缺失：等待并重新查询；不要仅凭一次轮询就假设失败。
• 状态不匹配：将读取固定到特定区块号。

局限性、权衡以及需要测量什么

Etherlink 继承了其设计的权衡。快速的执行层确认改善了用户体验，但它们与 L1 最终性不同。乐观 rollup 设计涉及挑战期和欺诈证明，因此结算语义与单体 L1 不同。治理与 Tezos 集成，这提供了可升级性，但也意味着协议变更遵循 Tezos 治理流程。

测量影响你应用程序的因素：从用户到 RPC 端点的端到端延迟、收据延迟、状态读取一致性以及负载下的错误率。不要依赖已发布的数字进行容量规划。如果你需要可预测的吞吐量，考虑使用专用节点而不是共享公共端点。

• 执行确认不是最终结算。
• 公共端点可能有限速；生产工作负载需要容量规划。
• 跨接口操作需要理解 EVM 和 Michelson 工具。
• 升级遵循 Tezos 治理，并可能改变内核行为。

后续步骤：工具、端点与运维

在验证连接和部署后，转向运维加固。将 RPC 配置放入环境变量，添加带退避的重试，并监控收据延迟和错误率。如果你正在选择端点，使用 RPC Assistant 获取直接推荐，并在配置钱包之前查看网络详情。

对于运行生产工作负载的团队，根据你测量的吞吐量评估专用基础设施和定价。为 nonce 冲突和结算检查保留运行手册，并在任何提供商或网络变更后重新运行验证流程。

• 在配置你的技术栈之前查看支持的网络。
• 比较 API 服务选项以获取托管访问。
• 评估专用节点选项以获得可预测的性能。
• 查看定价以进行 RPC 容量规划。
• 使用 RPC Assistant 获取端点选择指导。