委员会签名门槛怎么算？AnyTrust 数据可用性委员会里 N、H、K 的关系

数据不上链，靠什么兜底

AnyTrust 类链把交易数据交给一个链下委员会保管，父链上只登记一份签过名的凭证，费用因此明显低于把数据全量发布到 L1 的路线。但”委员会保管”四个字里有三个必须量化的小问题：委员会有多少人、允许多少人不可信、一笔数据要被几个人签过名才算数。Arbitrum 官方文档给这三个量起了名字，也给了它们之间的一条硬关系。

N、H、K 三个数

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

第一个数是 N，委员会成员总数，由密钥清单里公钥的个数决定。第二个数叫 assumed-honest，记作 H，是协议假设至少保持诚实的成员数。第三个数 K 是做成一张有效数据可用性证书所需的最低签名数，官方文档给出公式：K 等于 N 加一减 H。举几个文档里列过的配置：八个成员、假设两人诚实，那么需要七张签名，容忍一个成员不响应；五个成员、假设三人诚实，需要三张签名，容忍两个成员离线。公式的直觉是：在最坏情况下，只要 H 个人确实诚实，凑齐 K 张签名就能保证其中至少有一张来自诚实成员，证书覆盖的数据就不至于被整组人合谋抹掉。这张证书本身很小，发布到父链的正是它而非原始数据——省钱的来源与信任的转移，都浓缩在这一个结构里。

签名怎么验：keyset 与 BLS 公钥

每位委员会成员为自己的数据服务器生成一对 BLS 公私钥，只用于这个用途。把所有成员的 RPC 端点和公钥连同 assumed-honest 参数打包，就是 keyset（密钥清单）；链上合约 SequencerInbox 通过 setValidKeyset 方法接受这份清单，而调用它需要链的所有者权限。要注意两处配置必须一致：节点端 rpc-aggregator 里的 assumed-honest 数值必须与链上 keyset 里的完全相同，两边一旦不一致，聚合器可能拒绝有效证书，也可能放过签名不足的证书。成员轮换也不能”补一个新人进去”——必须准备一份包含全部公钥的新 keyset 整体换发。数据服务器默认开放两个端口：批次提交者写入用的 RPC 端口与节点取数用的 REST 端口，具体默认值以官方运维文档为准。

凑不齐签名会发生什么

运维文档列了几种失败形态：响应不足 K 个、有人用错 BLS 密钥、全部后端宕机、网络分区导致可达成员不足。共同的回退路径是同一条——批次提交者放弃签发轻量证书，改把完整批次数据直接发布到父链，链暂时退化成普通 Rollup 的工作方式继续运转。反过来说，若把禁用回退的开关在生产环境打开，委员会整体故障就会直接停链，官方文档对此标注了危险警告。节点侧另有取数策略：REST 取不到数据时回到父链读完整数据，超时与容错参数同样在文档里可调。

H 的取法就是一条信任曲线

同一批成员，H 取多大直接改变两个方向的暴露。把 H 调高，意味着假设更多成员诚实，K 随之变小、证书更容易凑齐、容忍离线的人数变少；把 H 调低，凑签名要多拉人，数据更抗个别成员失踪，但”至少一个诚实签名”的保证被稀释。链方在 keyset 里选哪组数字，是一条写在链上、任何人可查的假设声明，不是营销文案里的”多家机构共同保障”。

普通用户能核验的动作也因此变得具体：在父链浏览器上找到批次提交者发布的证书交易，看它引用的 keyset 哈希是否仍是链上有效的当前版本；证书版本对不上时，节点会直接拒绝，这类拒绝日志往往就是”成员换发没通知到位”的第一现场。

信任成本也要摊开看：只要 K 个签名者串通隐藏数据，链上就没有任何密码学证据能找回它们，提款安全依赖委员会持续履行公开承诺。Rollup 到底分几种？用数据可用性和状态证明两根轴看懂二层谱系 把数据可用性放回整个二层谱系里比较。本文为机制说明，不构成任何投资建议。