Avalanche 子网（L1）指南：架构、部署与 RPC 验证

范围与直接答案

Avalanche 子网是一组动态的验证者，他们同意验证一个或多个区块链。自 Avalanche9000 升级以来，生态系统越来越多地将这些网络称为 Avalanche L1，但底层的 P-Chain 原语仍然是子网。子网不继承 C-Chain 的执行环境；它定义自己的验证者成员资格，而部署到其上的每个区块链定义自己的 VM、创世和 Gas 规则。

本文涵盖思维模型、使用 Avalanche CLI 和 subnet-evm 的可运行部署路径，以及验证子网 RPC 端点的诊断程序。假设您对 EVM 链有基本了解，拥有终端，并且可以访问 Avalanche 节点或托管 RPC 提供商。具体端点选择不在本文范围内；请使用 RPC Assistant 获取提供商和网络建议。

• 已记录的行为：P-Chain 子网注册、验证者质押和 VM 插件加载。
• 建议：隔离 RPC 流量、固定链 ID，并独立于应用程序监控区块高度。
• 您必须运行的测量：您自己端点上的延迟、出块时间和最终性。

先决条件与假设

在部署之前，确认工具版本和资金。Avalanche CLI 封装了节点和子网操作，但它仍然需要一个可访问的 Avalanche 节点和一个在 P-Chain 上有资金的密钥用于验证者注册。确切的最低质押和费用表随网络升级而变化，因此请阅读当前的 Avalanche 文档，而不是依赖旧数据。

您还需要一个链规范：VM 选择（用于 EVM 兼容性的 subnet-evm）、创世分配、链 ID 和费用配置。将这些置于版本控制之下。有关节点托管选项，请参阅专用节点基础设施和网络目录。

• 已安装 Avalanche CLI 并在您的 PATH 中。
• 一个拥有足够 AVAX 的 P-Chain 密钥，用于子网和验证者交易。
• 为您的网络保留的创世 JSON 和链 ID。
• RPC 暴露计划，可以是自托管或通过托管提供商。

子网和 L1 如何融入 Avalanche

Avalanche 有三个主要链：用于资产操作的 X-Chain、用于 EVM 合约的 C-Chain 和用于验证者和子网的 P-Chain。子网在 P-Chain 上注册，然后通过质押将验证者添加到其中。子网上的每个区块链由区块链 ID 标识并运行 VM 插件。主网络验证 X-、C- 和 P-Chain；子网自己的验证者验证其区块链。

这种分离是核心思维模型：子网是验证者集合，区块链是状态机。单个子网可以托管多个区块链，如果满足质押要求，一个验证者可以属于多个子网。跨子网通信使用 Avalanche 链间消息传递（ICM）和 Teleporter，它们在链之间中继消息而不是直接共享状态。

subnet-evm 与执行层

subnet-evm 是大多数 Avalanche L1 使用的 EVM 实现。它支持可配置的 Gas 目标、费用市场、预编译合约和状态升级。独立的 ava-labs/subnet-evm 仓库已归档，其代码已移至 AvalancheGo，因此请固定您的节点版本并阅读 AvalancheGo 发行说明，而不是克隆已归档的仓库。

创世配置控制初始分配、链 ID 和费用参数。启动后更改创世需要协调的状态升级，因此请将其视为与用户之间的不可变合约。有关执行环境的更广泛比较，请参阅RPC 端点指南。

部署本地子网以进行验证

在公共网络上花费资金之前，本地部署是验证创世和 RPC 假设的最快方式。Avalanche CLI 可以创建一个包含子网和 subnet-evm 区块链的本地网络。以下命令使用名称和路径的占位符；请替换为您自己的值。

部署后，CLI 会打印 RPC URL 和区块链 ID。记录两者。本地网络是临时的，因此不要将其用于生产数据。

avalanche blockchain create myl1 --vm subnet-evm --genesis ./genesis.json
avalanche blockchain deploy myl1 --local
# Expected output includes:
# RPC URL: http://127.0.0.1:<port>/ext/bc/<blockchainID>/rpc
# Blockchain ID: <blockchainID>

使用 curl 验证子网 RPC 端点

第一个检查是链身份。调用 eth_chainId 并将十六进制结果与您的创世链 ID 进行比较。不匹配通常意味着您指向了错误的区块链，或者代理路由到了 C-Chain。第二个检查是出块：延迟调用两次 eth_blockNumber 并确认高度增加。

使用占位符表示端点。切勿将真实凭据提交到源代码管理。

RPC_URL="https://your-subnet-rpc.example/ext/bc/<blockchainID>/rpc"

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":[]}'

JavaScript 健康检查程序

对于持续验证，编写检查脚本并将结果记录在表格中。下面的脚本测量链 ID、区块高度和往返延迟。它不断言特定的出块时间，因为这取决于您的创世和验证者集合。

按计划运行并存储输出。包含时间戳、链 ID、区块高度、延迟和状态列的结果表使回归可见。

const RPC_URL = process.env.RPC_URL;

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

(async () => {
  const chainId = await call('eth_chainId');
  const block1 = await call('eth_blockNumber');
  await new Promise(r => setTimeout(r, 5000));
  const block2 = await call('eth_blockNumber');
  console.log({
    chainId: chainId.result,
    block1: parseInt(block1.result, 16),
    block2: parseInt(block2.result, 16),
    latencyMs: chainId.latencyMs
  });
})();

解读验证结果

健康的端点返回稳定的链 ID、在样本之间增加的区块高度以及与您的网络路径一致的延迟。如果链 ID 正确但高度静止，验证者可能正在同步，区块链可能已暂停，或者您的请求可能命中了缓存。如果链 ID 错误，请检查 URL 路径中的区块链 ID 以及任何反向代理路由规则。

记录测量值而不是猜测。下表是模板；用您自己的观察填充它。

• | 检查 | 方法 | 预期 | 观察 |
• | 链身份 | eth_chainId | 与创世匹配 | （记录） |
• | 出块 | eth_blockNumber x2 | 高度增加 | （记录） |
• | 延迟 | 计时请求 | 在您的 SLO 内 | （记录） |
• | 最终性 | eth_getBlockByNumber | 已接受区块 | （记录） |

排查常见的子网 RPC 故障

连接被拒绝或 502 通常意味着节点未运行、RPC 端口未暴露或负载均衡器没有健康的后端。返回 200 响应但带有 JSON-RPC 错误（如方法未找到）表明您正在与不同的 VM 或较旧的节点版本通信。负载下的超时通常表明节点资源耗尽而非协议问题。

对于验证者级别的问题，检查 P-Chain 注册和质押状态。不在子网验证者集合中的验证者不会为该子网产生或验证区块。有关更广泛的节点操作，请参阅区块链节点托管指南。

• 确认 RPC 路径中的区块链 ID 与已部署的区块链匹配。
• 检查节点日志中的 VM 插件加载错误。
• 验证验证者已在 P-Chain 上注册并质押。
• 从不同的网络路径测试以排除本地 DNS 或防火墙问题。

限制与权衡

子网以共享安全性换取主权。您选择并资助您的验证者集合，因此安全性是您的质押设计的函数，而不是主网络的。这种灵活性支持自定义 Gas 代币、许可成员资格和特定于应用程序的吞吐量，但也意味着您拥有正常运行时间、升级和事件响应。

与同链调用相比，跨子网消息传递增加了延迟和复杂性。如果您的应用程序依赖于与 C-Chain 流动性的原子可组合性，请在承诺之前评估 L1 是否合适。对于托管 RPC 选项，请比较RPC 定价和API 服务。

后续步骤

本地验证后，部署到具有小型验证者集合的公共网络，然后持续运行健康检查脚本。在运行手册中记录您的链 ID、创世哈希和 RPC URL。当您准备好选择生产端点时，使用 RPC Assistant 获取具体的提供商和网络建议，而不是从列表中猜测。

相关阅读，请参阅什么是区块链 nonce和多链 RPC 端点指南。