容量预言机：经济学

由 maryam 和 mike 撰写；2026 年 4 月 23 日。

tl;dr; 区块链协议设计中出现了一种新兴模式：delegation-verification，即由一组专业节点执行计算密集型任务，再由更大的一组参与者验证其输出。这种模式利用了 doing 工作与 verifying 工作是否被正确执行之间的成本不对称性。ZK proofs 是这方面最典型的例子，但其他更通用的工作负载也符合这一范式。例如，运行 AI inference 的 TEE 可以通过验证硬件生成的 attestation 来加以验证。这些系统面临着 information elicitation 问题。潜在用户可能希望知道，针对自己的工作负载是否还有足够的额外容量，但他们无法看见 worker 的可用 throughput。特别是，链上节点容量的唯一信号，只能是已执行工作负载的 ex-post 结果，而这并不能说明还能处理多少 additional 工作。本文提出了一个用于刻画这一问题的简单模型。

1. Intro

下一代区块链协议的一种常见设计模式，是用“replicated verifier”模型取代原始版本的 replicated state machine（即每个节点都重放状态更新的历史）。在这种模型下，任务只需执行一次，却会被验证很多次，这利用了验证多个任务比执行这些任务更容易这一事实。这方面的典型例子，是为以太坊 mainnet 提出的 ZK-EVM 扩展：网络中的每个节点不再重新执行每个区块，而是为区块附带一个证明，用简洁的方式验证其内容的正确性，而无需重新运行完整的交易列表。

内置 ZK-EVM 的原生实现要求，每个区块的完整证明必须由单个 prover 在以太坊 12 秒的 slot 内生成。这有两个根本性局限。首先，它没有利用多个 prover 的聚合资源（也就是说，这是一种赢家通吃模式）。其次，它只适用于那些执行和证明都能在单个 slot 内完成的工作负载。一种更通用的方法是允许多个 prover 并行处理不同任务，并且理想情况下，任务完成的时间线应由用户配置，而不是受 slot 时间限制。

为了理解这为什么是必要的，请考虑在链上实现 AI inference 的目标。在那样的世界中，每笔交易都可能调用要求各不相同、成本高昂的 AI 操作。与其依赖单一参与者对区块中的所有内容进行批量证明——这会导致 builder 市场进一步中心化——不如将任务执行分发给广泛的供应节点，以异步方式完成，并最终在链上验证。

这就是 Ritual 正在采取的方法。他们设想了具有不同资源需求（例如硬件、模型访问、带宽、延迟等）的任务，并提出了一个双边市场（Resonance），以实现任务与供应商之间的高效匹配，同时通过最终的链上验证（Symphony）提供正确性保证。

区块链扩展的这种演变启发了我们的模型。

1.1 Understanding network capacity

在多供应商模型中，用户自然会问：链当前的容量是多少？ 这个问题的答案可能会影响用户是否选择该平台而不是中心化云服务提供商，因为用户需要可靠性保证。考虑一种基础的 first-come-first-served 采购机制，谁先完成任务，谁就获得报酬。FCFS 无法反映链的真实容量，因为只有赢家最终会交付完成的任务，而输家会立刻停止处理并丢弃部分已完成的任务，以避免进一步浪费资源。

或者，我们也可以通过拍卖征集出价，希望获得更好的容量指标，但并非所有拍卖都会产生高质量的信号。例如，众所周知，第一价格拍卖不会导致真实报告，这意味着出价可能无法反映真实容量。这就引出了 “capacity oracle” 的想法：采购机制的设计目标，是为链的可用容量提供更好的信号。例如，如果采购机制是严格 DSIC 的，那么协议就拥有一个完美的 oracle，因为均衡出价将准确估计链的聚合容量。

然而，在区块链语境下运行 DSIC 拍卖向来非常困难，因为与经典拍卖设计环境不同，这里容易出现诸如创建多个虚假身份等偏离行为。例如，在 “On Sybil Proof Auctions” 一文中，Pan 等人证明，在正向拍卖设定下，唯一同时满足 Sybil proof 和 DSIC 的机制是标准的第二价格拍卖；但它很难在链上运行，因为拍卖人是不可信的，可能会注入虚假出价。对于反向拍卖（这与我们的设定更接近），“Beyond Winner-Take-All Procurement Auctions” 设计了 DSIC 但不具备 Sybil-proof 性质的采购机制，也设计了 Sybil-proof 但不满足 DSIC 的机制，但没有一种能同时满足这两个属性。

本文探讨了如何在区块链采购设定中构建 capacity oracle。第 2 节介绍了一个基础模型，并提出了一种在固定身份集下满足 DSIC 的朴素机制，但它容易受到简单的 Sybil 攻击。第 3 节扩展模型以纳入 Sybil，并提出两种不同的对抗 Sybil 的方法（3.1 中的关联支付和 3.2 中的 slashing）。第 4 节研究了 capacity oracle 的一个实际实例，并通过数值结果展示了协议成本与 oracle 准确性之间的权衡，为从业者提供图表和具体结论。

2. Model

我们考虑一组 $n$ 个供应商，每个供应商具有相同的单位线性生产成本，以及私有容量 $c_i \in \mathbb{R}+$，其中 $i \in [n]$。我们用 $\mathbf{c}$ 表示容量向量。每个供应商向协议提交一个出价 $b_i$，表明其声称拥有的容量。协议定义了一个分配规则 $x: \mathbb{R}+^n \mapsto \mathbb{R}+^n$，将出价向量 $\mathbf{b}$ 映射到分配向量 $\mathbf{x}$。请注意，协议可进行的分配量没有限制，且分配可以是分数形式。你可以将其理解为：协议始终可以选择创建“虚假”工作并分配给供应商，以证明他们确实拥有所声称的容量。根据分配情况，供应商将决定是否“交付”分配给他们的工作。令 $d_i \in [0, c_i]$ 表示供应商 $i$ 交付的工作量（因为其交付量不能超过真实容量 $c_i$），$\mathbf{d}$ 表示完整的交付向量。协议还定义了一个支付规则 $p : \mathbb{R}+^n \times \mathbb{R}+^n \mapsto \mathbb{R}+^n$，将出价向量 $\mathbf{b}$ 和交付向量 $\mathbf{d}$ 映射到支付向量 $\mathbf{p}$。完整机制由元组 $(x,p)$ 定义。每个供应商 $i$ 都具有 quasi-linear utility，且单位生产成本归一化为 1：

$$ u_i(\mathbf{b}, \mathbf{d}) = p_i(\mathbf{b}, \mathbf{d}) - d_i. $$

供应商的均衡出价行为可用于构建 capacity oracle。capacity oracle 是一个函数 $F: \mathbb{R}+^n \times \mathbb{R}+^n \mapsto \mathbb{R}+$，它将均衡出价向量和交付向量映射为一个实数，用以量化供应商的总可用容量。一个 完美 的 capacity oracle $F$ 等于 $\sum{i \in [n]} c_i$。我们的目标是设计一种机制，在实现完美 capacity oracle 的同时，使预期支付 $\sum_{i\in[n]} p_i$ 尽可能小。

2.1 Comments on the model

有几点值得明确指出。首先，我们考虑的是 common value setting，即每个人的生产成本相同，但拥有私有的 容量。这已经偏离了采购拍卖的标准文献，后者通常将私有信息建模为只有供应商自己知道的“成本”（例如，“Truthful Mechanisms for One-Parameter Agents”）。对于我们的场景，我们更关心的是诱导出网络的 容量，而不是成本，因此为了便于分析，我们将成本固定为公开信息。

此外，在我们的模型中，协议可以任意分配工作，这也与传统采购机制有很大不同，因为后者的总可分配工作量通常是固定的。有界分配在物理世界中是有意义的。比如，政府向承包商征集建桥投标；桥只能建一座，因此最多只能分配一个单位的工作。而在数字环境中，所做的“工作”是计算性的，协议可以任意构造任务让供应商完成。与 Proof-of-Work 的思路类似，既然谜题可以被设计得任意困难，协议也可以构造合成 AI 工作负载，并专门设计 ZK 挑战来证明容量。事实上，Aleo 已经探索过这种技术，尽管其目标不同，是为了吸引初始供应商集合。当然，天下没有免费的午餐；根据 individual rationality，如果协议分配了 $k$ 个单位的工作，就必须向参与者支付至少 $k$，以确保他们一开始有动力加入这个博弈。

请注意，我们模型最基础的解释是：协议仅为了确保可用性而创建工作；但更实际的解释则是，协议只对自然产生的工作进行 补充。如果某些时期的 organic demand 足够大，足以确保得到一个良好的 capacity oracle，那么协议就不需要创建和补贴任何额外工作。然而，在使用率较低的时期，协议可以增加其生成的工作负载。从这个角度看，协议可以被视为一个控制器，用来确保有足够的工作存在，以维持高质量的 capacity oracle 和稳定的供应商集合。

更一般地说，我们可以根据工作负载作为 capacity oracle 基础时的成本高低，来考虑不同类型的工作负载。一方面，organic demand 是“免费”的，因为费用由用户承担，而不是协议承担。另一方面，我们所考虑的合成工作负载处于另一个极端，因为其成本完全由协议承担。作为中间情况，我们可以设想一些对协议 有一定用处、但并非完全由用户支付的工作负载。一个很好的例子是 Ritual 的 scheduled transactions，它们是协议预先知道的、类似 cron 的作业，因此协议可以提前执行它们，作为可用性 oracle 的一部分。然而，如果它们的

• 原文链接： ethresear.ch/t/capacity-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～