所有区块链网络：为你的项目构建可用的清单

为什么所有区块链的通用列表无法保持真实

搜索所有区块链网络通常会返回两类页面：列举数百条链的百科式列表，以及定义什么是区块链的说明文章。两者都是有用的起点，但都不是可靠的运营参考。区块链列表是一份动态文档。新的第一层和第二层网络启动，测试网被重置或弃用，分叉拆分现有链，一些网络完全停止运营。维基百科自己的区块链列表因此带有明确的不完整声明。

对于工程工作而言，问题不是抽象意义上的“所有区块链是什么”，而是“我的系统依赖哪些网络，每个网络的已验证身份是什么？”链的身份锚定在其链 ID、创世块和原生货币元数据中。这些是你可以测试的字段。名称和营销描述不可测试，并且会随时间漂移。

因此，本指南将这一主题视为清单问题。你将把列表范围限定到你的项目，对照实时 RPC 端点验证每个条目，并将结果存储在一个表格中，每当怀疑有漂移时就可以重新运行。

• 百科式列表是快照，并且明确不完整。
• 链的身份可通过链 ID 和创世数据验证。
• 你的清单应限定在代码实际触及的链上。

在收集任何内容之前界定清单范围

在收集链数据之前，对你项目交互的每个网络进行分类。大多数多链应用属于四类：生产第一层网络、生产第二层汇总、用于 CI 或预发布的测试网，以及用于分析的归档或只读链。每个类别有不同的可靠性要求，将它们混在一个扁平列表中会使验证变得嘈杂。

一个有用的范围界定练习是在你的代码库和基础设施配置中搜索链标识符。查找链 ID 常量、RPC URL 环境变量、合约部署记录和桥接配置。出现在部署清单中的任何内容都是生产关键；仅出现在测试夹具中的内容可以降低验证频率。

界定范围后，为每条链分配一个角色：主结算、执行、数据可用性或只读参考。这个角色决定了你重新验证条目的频率以及端点需要多少冗余。关于跨多条链的端点选择，/en/learn/multi-chain-rpc-endpoints-guide 的多链 RPC 端点指南涵盖了共享网关与按链提供商之间的权衡。

• 生产 L1、L2 汇总、测试网和归档链需要不同的验证节奏。
• 搜索链 ID、RPC URL 和部署清单以发现隐式依赖。
• 为每条链分配角色，使验证工作与关键性匹配。

心智模型：链身份与端点身份

一个常见的 bug 来源是将链与其服务的端点混为一谈。链是由其创世块和共识规则定义的规范账本。端点是回答关于该链的 JSON-RPC 调用的服务。一条链可以由多个端点服务，一个端点提供商可以服务多条链。你的清单必须分别记录这两层。

在链层，记录链 ID、可用的创世块哈希、原生货币符号和小数位数，以及区块浏览器 URL。在端点层，记录提供商、URL 模式、认证方法和速率限制。当调用失败时，这种分离告诉你链变了还是端点变了。

这个模型也解释了为什么链 ID 检查如此重要。一个指向错误网络的错误配置端点会欣然接受交易并为错误的链签名。在每条写入路径之前验证链 ID 是廉价的保险。/en/learn/what-is-a-blockchain-nonce 的 nonce 解释文章是理解交易排序如何与端点正确性交互的有用伴侣。

• 链身份：链 ID、创世哈希、原生货币、浏览器。
• 端点身份：提供商、URL、认证、速率限制、支持的方法。
• 在每条写入路径上验证链 ID，以防止跨链签名错误。

从多个来源收集候选链

没有单一来源能完整列出所有区块链，因此要三角验证。从你的钱包或 SDK 供应商维护的链注册表开始，与区块浏览器目录交叉参考，并添加出现在你自己依赖图中的任何链。将每个来源视为候选生成器，而非真相。

对于每个候选，记录其来源和捕获日期。当两个来源对链 ID 或货币符号存在分歧时，这种来源信息很重要。对于分叉链和重用名称的测试网，分歧很常见。

当你需要特定链的具体端点时，RPC Assistant 涵盖单个网络的推荐。例如，/en/learn/arbitrum-rpc-endpoints 的 Arbitrum RPC 端点指南和 /en/learn/best-solana-rpc-provider 的 Solana 提供商指南涉及按链的端点选择。使用这些进行端点选择，并将本文重点放在清单方法上。

• 从钱包注册表、浏览器目录和你自己的代码进行三角验证。
• 为每个候选记录来源和捕获日期。
• 通过对照实时链数据测试来解决分歧，而不是信任声音更大的来源。

使用 curl 验证链 ID 和元数据

最快的验证是直接 JSON-RPC 调用。eth_chainId 方法以十六进制字符串返回链 ID。转换为十进制后与你的预期值比较。以下脚本遍历候选列表并为每个条目打印通过或失败。

将 RPC_URL_* 替换为你的实际端点。不要在生产脚本中硬编码公共端点；使用环境变量或密钥管理器。

#!/usr/bin/env bash
set -euo pipefail

declare -A CHAINS=(
  [ethereum]="${RPC_URL_ETHEREUM}"
  [arbitrum]="${RPC_URL_ARBITRUM}"
  [base]="${RPC_URL_BASE}"
)

declare -A EXPECTED=(
  [ethereum]=1
  [arbitrum]=42161
  [base]=8453
)

for name in "${!CHAINS[@]}"; do
  url="${CHAINS[$name]}"
  hex=$(curl -s -X POST "$url" \
    -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \
    | python3 -c 'import sys,json; print(json.load(sys.stdin)["result"])')
  actual=$((hex))
  if [[ "$actual" -eq "${EXPECTED[$name]}" ]]; then
    echo "PASS $name chainId=$actual"
  else
    echo "FAIL $name expected=${EXPECTED[$name]} actual=$actual"
  fi
done

使用 JavaScript 验证端点健康状况和区块进度

仅凭链 ID 不能证明端点健康。端点可以报告正确的链 ID，但落后于链头或无法提供历史状态。添加第二项检查，将端点的最新区块号与参考端点或链的公共浏览器进行比较。

下面的脚本查询 eth_blockNumber 和 eth_getBlockByNumber 获取最新区块，然后打印区块时间戳。区块时间戳与墙上时钟时间之间的较大差距表明端点滞后。从与生产工作负载相同的区域运行此脚本，因为延迟和可用性因地理位置而异。

这是你必须自行运行的测量。不要假设提供商公布的正常运行时间反映了你的区域或你的方法组合。

const endpoints = {
  ethereum: process.env.RPC_URL_ETHEREUM,
  arbitrum: process.env.RPC_URL_ARBITRUM,
};

async function rpc(url, method, params = []) {
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params }),
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

for (const [name, url] of Object.entries(endpoints)) {
  const blockHex = await rpc(url, 'eth_blockNumber');
  const block = await rpc(url, 'eth_getBlockByNumber', [blockHex, false]);
  const ts = Number(BigInt(block.timestamp) * 1000n);
  const lagSeconds = Math.round((Date.now() - ts) / 1000);
  console.log(`${name} block=${Number(blockHex)} lag=${lagSeconds}s`);
}

将结果记录在可复现的表格中

将验证输出存储在表格中，以便随时间比较运行结果。下表是一个模板；用你的脚本产生的值填充它。不要从任何外部来源复制数字，包括本文。

按计划运行表格，至少在每个生产部署之前以及任何提供商变更之后。将历史运行记录保存在版本控制中，以便将事件与端点漂移关联起来。如果你运营专用基础设施，/en/dedicated-node 的专用节点指南解释了如何直接控制端点层，而不是依赖共享网关。

排查常见的清单故障

当验证失败时，原因通常属于以下四类之一。快速区分它们可以节省时间。

第一，链 ID 不匹配。这几乎总是意味着端点 URL 指向了与预期不同的网络，通常是测试网或分叉。对照提供商的文档检查 URL，并确认环境变量在正确的环境中设置。

第二，区块滞后。滞后的端点可能受到速率限制、地理距离远或服务于修剪节点。与同一链的第二个端点进行比较。如果两者都滞后，链本身可能正在经历最终性问题。

第三，方法不支持。某些端点限制历史查询或调试方法。如果你的清单包括归档读取，请明确验证这些方法，而不是假设 eth_chainId 成功意味着完全支持。

第四，认证失败。API 密钥会过期、轮换或限定于特定链。401 或 403 响应应与 JSON-RPC 错误区分记录，以便将其路由到正确的待命轮换。

• 链 ID 不匹配：错误的 URL 或错误的环境。
• 区块滞后：速率限制、距离或修剪状态。
• 不支持的方法：单独验证归档和调试调用。
• 认证失败：过期或范围错误的 API 密钥。

任何链清单的局限性和权衡

每个清单都是快照。链启动、测试网重置、提供商更改其支持的网络列表。今天准确的列表下个季度可能就错了。为重新验证做预算，而不是假设完整性。

还有一个成本权衡。每次部署都验证每条链在时间和 API 调用上都很昂贵。对你的检查进行分层：关键结算链每次部署，执行链每天，测试网每周，归档链按需。这使验证工作与影响范围相匹配。

最后，要谨慎对待任何第三方列表为权威。钱包供应商维护的列表优化钱包兼容性，而不是你的应用需求。浏览器维护的列表优化浏览器覆盖范围。两者都不能替代测试你代码调用的特定方法。

后续步骤：自动化和扩展清单

将验证脚本移入你的 CI 管道作为部署前门禁。如果生产链的链 ID 与预期值不匹配，则使构建失败。这在配置漂移到达用户之前捕获它。

用每条链的合约地址扩展清单。没有你的应用调用的合约地址，链条目是不完整的，而且这些地址在不同网络间不同。将它们与链元数据一起存储，以便单次查找返回构建交易所需的一切。

对于清单中跨链的端点选择，请查看 /en/pricing/rpc 和 /en/networks 的定价和网络覆盖范围，并咨询 RPC Assistant 获取按链推荐。/en/learn/blockchain-node-hosting-guide 的区块链节点托管指南涵盖了在共享端点不足的链上运行自己节点的运营方面。

在每次提供商变更和每次重大链升级后重新运行验证表。将清单视为活的工件，而不是一次性文档。

• 将链 ID 检查添加到 CI 作为部署前门禁。
• 将每条链的合约地址与链元数据一起记录。
• 在提供商变更和链升级后重新验证。