Superchain Registry 是什么？一条 OP Stack 链的身份档案存在哪、怎么查

一条链的”身份证”为什么要做成机器可读

OP Stack 生态里”一条链”听起来含糊：同一条以太坊主网上挂着多条二层，各自有排序器和桥。但真要配置节点、连接钱包或者核对桥的安全性，靠的是精确参数——L2 的链 ID、创世配置、L1 侧 OptimismPortal 与 StandardBridge 的地址、批次提交地址、RPC 端点。这些信息早年散落在官网、区块浏览器和社区 wiki 里，谁都可能抄错、谁都可能过期。Superchain Registry 就是把它们集中起来的 GitHub 仓库：按链存放 toml 与 json 格式的配置数据，按超链目标存放全局配置，再打包成 Go 模块供 op-geth、op-node 等下游 OP Stack 软件直接引用，官方文档的合约地址页也以它为数据源。

它管的两类配置

https://assets.skjop.cn/articles/202609021030/content-1.jpg

第一类是逐链配置：这条 L2 的链 ID 是多少、创世状态长什么样、L1 上部署了哪些合约、地址分别是什么、RPC 与区块浏览器指向哪里。第二类是超链级配置。登记册定义了超链目标的概念：一组在 L1 上共用同一份 SuperchainConfig 合约的 L2 链集合。旧名单里还有一枚 ProtocolVersions 合约用于向节点软件通报推荐与必需的协议版本号；官方文档明确该合约已从 OP Stack 合约集合中移除，但版本号方案仍保留在超链升级规范里。同一 L1 可以有多个目标并存，例如主网名单与测试网名单就分别登记、互不混用。

用它自查的三件事

普通用户能从登记册里做的核验其实很具体。第一，连接一条新的 OP Stack 链时，先比对链 ID 与货币符号，防住假 RPC 冒充”官方网络”。第二，跨链前把官方地址页给出的桥合约地址与登记册条目对照一遍，两边一致再动手。第三，弄清批次提交地址的来历：OP Stack 规范特别注明，批次收件地址不是智能合约，而是一个假定没有已知私钥的普通账户，历史上常按 0xFF0000… 拼接目标链 ID 十六进制的惯例推导。地址对得上，才谈得上”这条链的参数”，而不是某个网站的话术。

登记册怎么被下游软件消费

登记册不是一个”给人看的表”。仓库里除了逐链与超链级数据，还有一个 Go 模块：配置被嵌入 superchain 模块后，op-geth 与 op-node 启动时按链 ID 直接查表拿到创世配置与合约地址，不需要各自维护一份内嵌名单。这就是”单一事实源”的工程含义——节点软件、官方地址页、第三方工具读到的是同一份提交历史里的数据，任何一条改动都要走仓库的校验与合并流程，留下可追溯的记录。对研究链配置的人来说，仓库的提交记录本身就是一部”这条链何时换了地址、何时接入新 L1”的流水账，比转述型资料更可靠。

同一份数据也界定了”超链”的制度含义：共用 SuperchainConfig 的链在协议层面被视作一个升级单元，共享 Guardian 等系统角色的暂停与治理边界；逐链差异则留在各自条目里。于是”加入超链”不再是市场话术，而是一个可以用配置验证的事实——看该链条目指向的 SuperchainConfig 地址是否与目标名单一致即可。

它不管什么

有两条边界必须说清。第一，登记册记录事实，不做安全评级：它能告诉你合约部署在哪、Guardian 可以暂停提款、Challenger 可以质疑输出提案，但不评价一条链的排序器有多中心化、升级权限有多集中，这类判断要去专门的风险评估页面和链方文档找。第二，登记册内容随软件迭代变化——故障证明上线后合约集合就与旧图不同，链名单也会添新成员——因此列表本身的字段与结构也应以仓库当前版本为准。本文讲它的组织方式与用法，不锁定任何具体地址或名单；Rollup 到底分几种？用数据可用性和状态证明两根轴看懂二层谱系 从另一根轴解释了这些链的安全归属，两篇配合看更完整。本文为机制说明，不构成任何投资建议；跨链转账前请逐项核对链上参数，配置错误可能造成不可逆损失。