图片原始来源 · CC BY 4.0 · 使用公开缩略图并转WebP；未改动内容
排序器和证明器是不是一家公司，取决于具体 Rollup 的运营安排，没有统一答案。两者是功能角色：排序器决定交易顺序并组织批次，证明器为 ZK 批次生成有效性证明。它们可以由同一团队运行，也可以分开；即使同属一个主体，排序权、证明生成和合约升级控制仍是三件需要分别审查的事。
两类角色分别做什么
排序器接收用户交易，决定先后顺序，执行后把交易数据或状态承诺提交到 L1。执行、批次提交也可能由不同组件或主体承担，不宜默认全部归排序器。
证明器主要出现在 ZK Rollup 中。它针对一批交易生成有效性证明，交由 L1 验证合约核验，核验通过后新的状态根才被接受。按以太坊开发者文档的说明，ZK Rollup 在链下执行交易，向主网提交状态变更摘要和正确性证明。证明不一定逐批单独生成，也可能把多个批次的证明聚合后再提交，因此不能从“有一批新状态”反推出“必然有一次独立证明提交”。
Optimistic Rollup 的常规路径不同：批次先被接受，依靠挑战期和欺诈证明纠错，不要求每批附有效性证明。对它来说，对应角色更接近挑战者和欺诈证明计算方。把“排序器对证明器”直接套到所有 Rollup 上，会混淆两类系统的安全机制。
用一张表拆开看
假设某 Rollup 对外称“排序和证明由同一团队提供”，可以按以下项目分别核查：
| 审查项 | 要问的问题 | 同主体时的含义 |
|---|---|---|
| 批次提交 | 哪个地址能把批次写入 L1 合约？ | 与其他关键地址同控，说明运营集中度可能较高 |
| 证明生成 | 谁生成证明，是否可替换或聚合提交？ | 同一团队既排序又证明，故障域可能重叠 |
| 证明验证 | L1 验证合约的代码与升级权限归谁？ | 验证规则由合约决定，与公司是否同一无关 |
| 升级控制 | 代理合约管理员、多签人是谁？ | 往往比“是不是一家公司”更影响信任假设 |
| 退出路径 | 排序器停止时，用户能否经 L1 强制交易或退出？ | 决定单点故障能否被用户自行缓解 |
管理员地址只能辅助判断控制权，不能据此确认公司身份。同一多签可能代表多家机构，不同地址也可能由同一团队控制。要判断主体关系，还需结合治理文档、运营披露和合约权限结构。
同主体，后果未必相同
假设 A 公司同时运行排序器和证明器。排序器长时间下线，用户交易可能无法及时进入批次，影响出块和抗审查；证明器停止工作，则新的 ZK 批次无法完成 L1 验证，状态更新会停住。两者都会造成服务中断，但作用环节不同。
再假设排序由 B 运行、证明由 A 运行。A 停止生成证明，新批次同样会卡在终局性之前；B 仍可接收交易并排队，但队列会持续积压。反过来，若排序器由 A 运行而证明由 B 运行，排序停摆会先影响交易纳入。可见“是不是一家公司”不能替代对停机位置和影响范围的分析。
还有一种常见错位：证明生成看似由多家参与，但 L1 验证合约可被单一管理员替换。此时证明者再分散，验证规则仍可能被集中控制。审查时应把排序去中心化、证明去中心化和升级控制去中心化分开评估。
可操作的判断顺序
- 先确认 Rollup 类型。查看 L1 合约是否通过有效性证明接受最终状态更新；若依靠挑战窗口纠错，就不应把“证明器”当作必备角色。
- 查批次提交地址和证明提交路径。记录哪些地址可写入批次、哪些地址可提交证明，再对照多签成员和治理披露。地址相同只是线索，不是公司身份证明。
- 单独检查验证合约。确认验证逻辑是否可升级、升级由谁触发。验证合约的权限与排序器运营方是否重合，需要分别核实。
- 查升级与准入控制。代理合约管理员、排序器准入规则、证明器替换权限，通常比日常运营主体更能决定信任边界。
- 查退出和强制纳入机制。用户能否绕过不配合的排序器，经 L1 提交交易或退出，直接关系到排序集中化的实际危害。
- 区分计划与已生效状态。文档写“将开放排序器准入”属于计划；链上准入规则已生效、多签已完成更换，才属于可核验的完成状态。
概括来说，排序器和证明器是功能角色，不是公司标签。要回答“是不是一家公司”，应落到合约控制、提交地址和治理权限；要回答“风险有多大”，还要继续看停机影响、退出路径和升级控制。把这三层分开，比追求一个统一的是非答案更有用。