6.1 扩容与链下计算：把执行搬下链，把信任搬上链

6.1 扩容与链下计算：把执行搬下链，把信任搬上链

本节摘要：扩容是零知识证明最大的商业落地点：把成千上万笔交易的执行搬下链，把一份"执行正确"的证明搬上链。本节解剖有效性证明架构与欺诈证明的分野、rollup 与数据可用性托管的残余信任差异，并合并讲清链下计算与跨链互操作如何复用同一套证明思路。承接第 6 章现场主线，通往 6.2 的隐私交易。

场景代入：一笔转账的两种命运

主网高峰期，一笔转账要排长队、付高额手续费——因为每个全节点都要重新执行每一笔交易来验账。这是"全体重复执行"模式的固有成本。扩容现场把账本撕成两半：执行搬到链下的专用环境里做，链上只收两样东西——新的状态根（执行后的账本快照哈希）与一份证明（断言"从旧状态根出发，按这批交易执行，必然得到新状态根"）。链上合约验过证明即切换状态，全体节点不再重复执行。

这套结构里，零知识证明扮演的角色与隐私毫无关系——它是正确性的搬运工。3.3 节的性能三本账在此全部兑现：链上验证一次两百字节级的证明，成本被数千笔交易摊薄；代价集中在链下证明器，这也是扩容团队疯狂堆 GPU、做聚合、开证明市场的全部原因。

有效性证明与欺诈证明：两条路线的分野

同样"链下执行、链上验证"，验证正确性的方式分两派。有效性证明派（ZK rollup）：每次状态更新附带证明，验证通过才生效——错误状态在源头就被拦下，资金提取无需等待期。欺诈证明派（optimistic rollup）：状态更新先默认生效，设一段挑战窗口，任何观察者发现错误可提交欺诈证明回滚——省了证明生成的开销，代价是提款等待窗口与"至少有一个诚实观察者在线"的活性假设。

两派差异的本质在第 5 章的账本上：欺诈证明把第一本账（证明生成）压到几乎为零，把"挑战者激励与窗口期"记成新的运营成本；有效性证明把成本前置到证明器，换来即时确定性与无观察者依赖。近年产业明显向有效性证明倾斜，但"链下数据可用性"问题两派都要面对。

图：有效性证明扩容架构解剖

读架构图的正确姿势是拿红笔圈残余信任：排序器会不会审查交易（能否被替换或强制包含）、交易数据是否真正公开可获取（决定用户能否无许可退出）、合约升级钥匙的治理（能否一夜改走资金）。三个问题问完，方案的安全成色就有了底分——宣传页上"去中心化"三个字不算数，圈出来的答案才算数。

三种形态：数据放哪决定信任放哪

围绕"数据可用性"这个残余信任，方案形成三档。rollup：交易数据完整上链，任何人可独立重建状态并提取资产——信任最薄，数据费用最高。数据可用性托管（validium）：数据留在链下运营方或数据委员会手里，证明仍保证执行正确，但"数据被藏起来导致无法提款"的风险由委员会担保——便宜，信任回填。混合档：部分数据上链（如仅状态差分）、或链上链下双通道，用复杂度换折中。选择问题可以化简成一句商业语言：你的用户能否接受"极端情况下需要运营方配合才能拿回资产"？能，托管档省钱；不能，rollup 的数据费就是必要保费。

链下计算的延伸：互操作与轻客户端

同一套"证明正确性"的思路还在向两个方向延伸。跨链互操作：链 A 想相信"链 B 上确实发生了某笔事件"，传统做法信任多签桥或预言机——历史上多起巨额事故都发生在这里；证明思路是给链 B 的区块头与状态转换生成简洁证明，链 A 合约验证证明即等同轻节点级验证，信任从"几个签名者"压缩回"链 B 的共识本身"。通用链下计算：云计算服务商对其计算任务的正确性证明、AI 推理过程的证明（7.1 节会提到）——"算过了且没算错"从口头承诺变成可验证对象。两个方向的共同瓶颈仍是 5.2 节的第一本账：证明生成成本决定这些能力能覆盖多大的计算量。

过渡：正确性之外，还有保密需求

扩容现场证明了"证明可以不姓零"；下一个现场把它请回本行——金额与身份的隐藏。承诺树与空值器如何拼出既能查重又不露内容的账本？下一站进隐私池。

一次提款争议的复盘

残余信任的价值，在出事时才看得最清。设想这样一个场景：某托管档方案的数据委员会出现分歧，部分委员拒绝继续签名出块，用户提款流程停滞。若这是 rollup，任何人可以凭链上完整数据自行重建状态、走强制退出通道拿回资产——争议只影响体验，不影响资产安全；若是托管档，唯一的出路是等委员会恢复协作或动用应急多签——资产的"可及性"此时完全取决于那个被信任的委员会。两类方案的月费差价，本质就是"这种场景发生时谁来兜底"的保险费。给业务方的问题因此可以非常具体：**你的用户能不能接受"极端情况下资产两周不可动"？**答案决定了选择哪一档，也决定了要不要为该风险再买一层保险（如数据可用性证明采样等新兴方案）。

追问三则

**问：证明上链后还能撤回吗？**不能，也不需要——这正是模型的价值：状态根切换一旦完成即不可逆，错误状态被证明机制拦在源头。需要"撤销"能力的业务（争议交易回滚）应该在业务层设计对冲机制，而不是指望链层开倒车。

**问：排序器中心化是硬伤吗？**是当前形态的主要残余信任，行业的演进方向是去中心化排序器集合与强制包含机制（用户可绕过排序器直接把交易塞进批次）。评估方案时把这两项的路线图当必答题：没有路线图的中心化排序器，就是把"高性能"建在了单点善意上。

**问：跨链证明方案与传统多签桥怎么选？**看"错误的代价与速度"：证明桥的错误要攻破源链共识才能发生，但跨链延迟高（要等源链最终性）；多签桥快而便宜，错误只需要攻破签名者集合。大额资产走证明桥的慢通道，小额高频走多签的快通道，是当前常见的分层配置。

数一数：扩容倍数怎么算

新闻里"吞吐提升百倍"之类的数字，拆开其实是三笔乘法。第一笔是每批交易数：一个批次塞下多少笔，受证明器吞吐与批次窗口限制；第二笔是摊销后的单笔验证开销：链上一次验证成本除以批量（5.2 的摊销表）；第三笔是数据可用性开销：rollup 要为每笔交易付链上数据费，托管档这笔趋近于零——这是两者成本差的主要来源。三笔相乘再与主链直接执行的单笔成本相除，才是可比较的"提升倍数"。看到宣传数字时，先问三个分项各是多少——分项报不齐的倍数，多半是把对自己有利的两项相乘、对不利的一项隐去。

最后给一组现场提问模板，进任何扩容方案的技术评审都适用：批次数据的承诺在链上还是链下、证明生成的平均与尾部时延各是多少、强制退出通道的实测时长、升级钥匙的治理结构与时效、历史证明系统有几次安全事件与响应记录。五个问题的答案写进评审纪要，方案的真实水位就浮出水面了。

本节要点回顾

• 扩容的本质是"执行下链、证明上链"，证明扮演正确性搬运工而非保密工具；
• 两派分野在账本：有效性证明前置证明成本换即时确定，欺诈证明省证明换观察者假设与窗口期；
• 三档形态由数据位置决定：rollup 薄信任贵数据费，托管便宜但回填委员会信任，混合档换复杂度；
• 互操作是同一思路的延伸：链间状态证明把多签桥的信任压缩回共识本身。