结果没有在以太坊执行，凭什么可信？

01 / 12

Orientation

先把“链下”与“不可信”分开

链下执行并不等于把账本交给一家公司；关键在于，链下结果能否被以太坊上的规则独立检查和强制执行。

想象一座繁忙的法庭。如果每一张发票、每一次加减法都要全体法官重算，法庭会非常慢。 Rollup 的办法是：在法庭外批量算账，把必要数据和一个结果摘要交回法庭，再让法庭用一套明确规则判断结果是否可以结案。

以太坊主网是这里的“最终法院”。它不必重做每一笔 L2 交易，却必须能够回答三个问题： 数据是否可获得？状态变化是否符合规则？用户在运营者失灵时是否仍有路径取回资产或提交交易？

Working definition

Rollup 是把执行和大部分状态存储移到以太坊之外、把批次数据或状态差异以及状态承诺发布到以太坊，并由以太坊合约裁定 L2 状态是否可以结算的一类扩容协议。它与把安全完全交给另一组验证者的普通侧链不同。 ^[1]

信任边界：L2 做大量工作，L1 保留最终裁决

FIG 01

L2 / Execution domain

接收、排序和执行交易
维护更频繁更新的 L2 状态
压缩交易或状态差异
生成状态根与批次承诺

L1 / Settlement domain

提供数据可用性空间
保存承诺与桥中托管资产
验证争议或有效性证明
给出协议级结算结果

“链下”描述执行位置；“继承以太坊安全”描述 L1 合约、数据与退出机制共同提供的约束。两者不能混为一句口号。

可信，不是说所有东西都无须信任

一个具体 L2 仍可能由单一排序器快速出块，证明者可能集中，升级权限可能掌握在多签手里，官方桥也可能有暂停开关。更准确的说法是：协议希望把“运营者必须诚实”缩小为“只要关键假设成立，运营者就不能把无效状态结算到 L1”。

Rollup security ≈ data availability + state-transition verification + enforceable exits + governance assumptions 这不是数学定理，而是一张审计清单：漏掉任意一项，都可能把“证明安全”误读成“系统没有风险”。

02 / 12

Shared model

两条路线，先共享同一副骨架

在讨论“乐观”或“零知识”之前，先看一笔交易从钱包到以太坊结算合约必须经过哪些角色。

01

User

签名 L2 交易；签名证明意图，不证明排序器会及时处理。

02

Sequencer

收集并排序交易，给出快速的 L2 确认体验。

03

Batcher

压缩批次并把数据、承诺或状态差异发布到 L1。

04

Prover / Challenger

生成有效性证明，或监控断言并对错误状态发起挑战。

05

L1 contracts

保存根、验证证明、处理争议并控制规范桥资产。

这些是逻辑角色，不保证由五个独立组织承担；一个运营方可以同时运行排序、批处理与证明服务。

共同流水线：差异发生在“L1 如何认可新状态”

FIG 02

钱包
签名交易

排序器
确定顺序

L2 VM
执行批次

发布数据
与状态承诺

L1 合约
认可状态

两类 Rollup 都会批量执行、压缩和向 L1 提交。核心差别是最后一格的接受规则，而不是前面所有组件都不同。

状态根是一枚“整本账本的指纹”

L2 不会把所有余额直接写进以太坊合约，而是把状态组织成可承诺的数据结构，提交一个固定长度的 状态根。只要任意叶子变化，根就会变化。根能锁定一个状态，却不能独自证明这个状态是怎样算出来的。

最小例子：Alice 向 Bob 转 1 个单位

FIG 03

PRE-STATE ROOT · 0xA1…

Alice10

Bob3

Alice nonce7

tx: Alice → Bob 1

POST-STATE ROOT · 0xB7…

Alice9

Bob4

Alice nonce8

为聚焦状态转换，例子忽略手续费。真正批次会包含大量账户、合约调用、中间状态和失败交易。

Sₙ = F(F( … F(S₀, tx₁), tx₂) … , txₙ) S₀ 是旧状态，F 是 L2 的状态转换规则，交易顺序也是输入的一部分，Sₙ 是新状态。两类 Rollup 都要让 L1 相信这个关系成立。

Do not overfit the names

排序器、批处理器、状态提议者和证明者的具体拆分会随协议变化。理解逻辑职责，比背某个项目今天的服务名称更耐用。

03 / 12

Optimistic path

先接受一个可反驳的断言

Optimistic Rollup 不在每个批次提交时证明全部计算正确；它把新状态视为一项可挑战的断言。

“乐观”不是相信排序器品德高尚，而是一个协议流程：正常情况下不触发昂贵裁决；只有观察者发现结果不一致时，才把争议缩小并交给 L1 判定。

批次数据和状态承诺发布到以太坊后，独立节点可以从旧状态重放交易。如果自己算出的新状态根与提议根不同，就在挑战期内发起争议。若挑战成功，无效断言不会成为可用于安全提款的已结算状态，相关保证金和后续状态会按协议处理。 ^[2]

Optimistic 生命周期：常态快速，结算留出反驳时间

FIG 04

L2 执行

排序器给出快速回执

发布批次

数据与状态承诺到 L1

开放挑战

观察者重放并核对

必要时裁决

把争议缩到可验证一步

协议结算

无有效挑战或争议已解决

用户看到的 L2 “成功”早于对 L1 的协议级结算。挑战期长度和状态命名依实现而异；常见规范桥提款等待约一周，但不是所有网络的永恒常数。

完整节点一直在验证，只是 L1 没有逐笔重算

一个常见误解是：“乐观 Rollup 默认不验证交易。”更准确地说，L2 节点仍会执行并检查交易； L1 合约在无争议时不重演整个批次。安全依赖数据可用，以及至少有一个能够发现并及时挑战错误断言的诚实参与者。

The honest challenger assumption

协议不要求多数观察者诚实，却要求至少一个诚实方能获得数据、重放状态、筹集挑战所需资源并在时限内上线响应。因此，无许可挑战、监控基础设施、保证金设计和安全委员会权限都是实际安全模型的一部分。

Interactive lab 01

同一个新状态，L1 到底检查什么？

切换证明路线，观察以太坊合约在接受状态时主动执行的检查，以及仍依赖哪些外部参与者。

ASSERT NOW · DISPUTE IF NEEDED

合约记录状态断言并启动可争议窗口；若有人挑战，争议协议才把错误执行交给 L1 裁决。

PROVE FIRST · VERIFY ON L1

合约运行固定验证算法；证明不能通过，新状态就不会被接受为已验证状态。

当前关键假设：至少一个诚实观察者能在挑战期内行动。

批次数据或状态差异与承诺一致
挑战窗口是否已经无有效争议地结束
争议发生时，单步执行结果谁正确
有效性证明是否满足验证密钥与公开输入
L1 是否逐笔重新执行整个批次

04 / 12

Fault proof

上百万步计算，怎样缩成 L1 能裁决的一步？

交互式欺诈证明不会把整个 L2 区块原样塞回以太坊；它通过二分争议逐轮锁定第一处不一致。

假设提议者声称执行轨迹从状态 S₀ 走到 Sₙ，挑战者认为中间某一步错了。双方先对整段轨迹的中点状态作承诺。若前半段一致，争议一定在后半段；若中点已不同，争议在前半段。重复这个过程，最终只剩一个 VM 指令或一个极小步骤，让以太坊上的验证合约直接判定。 Arbitrum Nitro 等系统用交互式二分和单步证明实现这一思路。^[8]

二分争议：每一轮只保留包含错误的那一半

FIG 05

完整轨迹 2²⁰ 步

第 1 轮 2¹⁹

继续二分 …

最终裁决 1 步

若原轨迹约有 2²⁰ 步，理论上约 20 次二分即可把争议缩到单步；真实协议还包含回合时钟、保证金、状态承诺格式和边界条件。

挑战期同时服务于安全，也制造提款等待

L1 必须给观察者足够时间取得批次数据、重放、发现错误并提交挑战。因此从 L2 到 L1 的规范提款通常要等状态越过挑战窗口。 OP Mainnet 的规范提款目前采用 7 天窗口；这只是一个具体配置，而不是“Optimistic 数学上必然等 7 天”。 ^[7]

流动性提供者可以先在 L1 垫付资产，再等待规范桥最终结算，这就是常说的“快速桥”。它改善体验，却把一部分风险从 Rollup 协议换成了桥合约、做市商、流动性和跨域消息风险。

Terminology

文献常用 fraud proof，不少团队更偏好 fault proof：被纠正的可能是软件错误或错误断言，不一定有主观诈骗意图。本课把两者视为同一类“错误证明/争议证明”机制。

05 / 12

Validity path

不是等待别人找错，而是先交一张可验证收据

ZK Rollup 为批次生成简洁的有效性证明；以太坊合约验证通过后，才接受新的已验证状态。

把一百万步计算想象成一场极长考试。证明者不把整张草稿纸交给 L1 重算，而是生成一份短得多的密码学证明： “存在一条满足全部规则的执行轨迹，确实把旧状态根变成了这个新状态根。”

排序器执行交易并产生执行轨迹；证明系统把 VM 规则、签名检查、余额约束、存储读写等转换成数学约束；证明者提交证明；L1 验证器只运行远小于原始计算的验证工作。证明通过，合约接受新根；证明失败，交易回滚，新根不生效。 ^[3]

ZK 生命周期：执行可以先发生，协议结算必须等证明

FIG 06

L2 批次
执行交易

生成
执行轨迹

Prover
生成 π

L1 verifier
验证 π

接受
新状态根

“证明后才结算”不等于用户必须等证明才看到 L2 回执。许多网络仍会先给排序器级确认，之后才完成批次证明与 L1 验证。

“零知识”不自动等于“交易隐私”

零知识证明可以在不公开某些见证数据的情况下证明命题，但多数通用 ZK Rollup 的核心目标是 简洁地证明计算有效，同时仍把足够数据发布到 L1 以便重建状态。因此，地址、金额或调用数据是否隐私，取决于协议是否专门设计了隐私语义，而不是名称里出现 “ZK”。

Proof of computation, not proof of reality

有效性证明能证明“程序按约束正确运行”，不能证明预言机喂入的现实价格一定真实，也不能证明合约业务逻辑没有漏洞。 正确执行一段错误设计的代码，仍然会得到错误业务结果。

06 / 12

Proof anatomy

一份有效性证明，里面究竟锁住了什么？

理解公开输入、见证、约束和验证器，就能避开“一个短证明凭空代表所有正确性”的神秘感。

证明解剖：把长执行压成可在 L1 快速检查的 π

FIG 07

Public inputs

旧状态根 S₀
新状态根 Sₙ
批次 / 数据承诺
链与协议参数

Witness + constraints

完整执行轨迹与中间状态
签名、nonce、余额检查
每条 VM 指令与存储读写规则
从输入到输出的全部约束

L1 verifier

固定验证逻辑
通过：接受根
失败：回滚

Scroll 用状态转换函数概括 zkEVM：给定旧状态 S 与交易 T，应证明执行函数 f 得到新状态 S′，即 f(S,T)=S′。^[11]

电路不是一张电路板，而是一组可证明约束

证明系统需要把“EVM 这一条 opcode 应怎样改变栈、内存、Gas 和状态”表达成有限域上的约束。证明者必须提供满足全部约束的见证；如果它伪造了 Alice 的余额、跳过签名检查或把 ADD 算错，至少一项约束就无法同时成立。

Proving

生成证明很重

需要把执行轨迹转换、承诺并进行大量密码学运算；硬件、并行度和证明系统会影响延迟与成本。

Verification

验证证明很轻

L1 不按原始批次规模重算，验证成本可远低于逐笔执行；这正是扩容收益的来源之一。

Amortization

批次越满越能摊薄

证明与 L1 提交的固定成本分摊给更多交易时，平均成本通常更低；低负载时优势可能没有想象中明显。

SNARK、STARK 与递归：先记功能，不急着背缩写

不同证明系统在证明大小、生成速度、验证成本、可信设置、抗量子假设和工程成熟度之间取舍。递归证明允许“证明一份证明验证正确”，从而把多个区块或多个子证明聚合成更少的 L1 验证工作。对用户而言，最重要的不是看到某个缩写就判断安全，而是问：谁能生成证明？验证器是否正确？证明延迟多久？系统失灵时能否继续或退出？

ZK-EVM compatibility is a spectrum

有的系统更贴近以太坊字节码和执行语义，有的使用不同 VM 并在编译层兼容 Solidity。兼容越接近，不代表所有预编译、Gas 细节、调试工具和升级节奏都完全相同；应以目标网络当前文档为准。

07 / 12

Data availability

证明计算正确，不代表别人拿得到数据

数据可用性决定独立节点能否重建状态、观察者能否挑战，以及用户在运营方失灵时能否证明自己的余额。

一张有效的“总账余额证明”可以说明加总没有错，却不一定把每个人的明细交给你。对 Rollup 而言，正确性与可恢复性是两个不同问题。

Optimistic Rollup 必须让挑战者获得足以重放的批次数据，否则没有人能构造错误证明。 ZK Rollup 即使能证明新根有效，也仍需要让其他节点重建当前状态、查询账户并在运营方停摆时继续系统。这就是为什么“有效性证明 + 链外数据”通常被称为 Validium，而不是具有同等数据可用性保证的 Rollup。 ^[4]

证明方式与数据位置是两条独立坐标轴

FIG 08

Optimistic Rollup 错误证明 / 争议机制 + 数据发布到 Ethereum L1 DA

ZK Rollup 有效性证明 + 数据或可重建状态差异发布到 Ethereum L1 DA

Validium 有效性证明 + 数据保存在链外委员会或其他 DA 层 External DA

“ZK”描述状态有效性如何被证明；“Rollup / Validium”还涉及数据发布在哪里。把这两个维度分开，很多项目宣传就会变得清晰。

Blob 是给 Rollup 的临时数据货舱

EIP-4844 引入 blob-carrying transaction：blob 数据由共识层保证一段时间内可获得，EVM 只读取其承诺而不直接读取完整内容。 Rollup 需要数据在关键窗口内足够可用，让节点下载、重建和验证；不要求每个 blob 永久占据昂贵的执行层历史。这带来独立费用市场和更低的数据发布成本。^[5]

Safety

无效状态能否结算？

由错误证明或有效性证明、验证器合约、数据承诺和 L1 共同回答。

Liveness

系统能否继续前进？

排序器、批处理器、证明者、挑战者和强制包含路径是否可用，决定停机与审查韧性。

Recoverability

别人能否重建状态？

数据发布格式、保留与归档生态决定独立节点能否从 L1 可用数据恢复 L2。

Temporary does not mean optional

Blob 会被协议节点在规定时间后裁剪，不表示期间可以不下载。关键参与者必须在可用窗口内取走并保存所需数据；历史长期检索由 Rollup 节点、索引器和归档服务继续承担。

08 / 12

Finality & exits

钱包显示“成功”，究竟成功到哪一层？

一笔 L2 交易至少有软确认、L1 数据锚定、状态正确性结算和 Ethereum 共识最终性四只时钟；跨层提款又是一条单独流程。

用户提交交易后，排序器可以很快返回收据，这适合日常交互，却仍可能受排序器重组或批次未发布影响。批次进入 L1 后，数据与承诺获得更强锚定。最后，Optimistic 状态要越过挑战机制，ZK 状态要等有效性证明被 L1 接受，才达到各自协议定义下的结算状态。

四层“确定”：体验、数据、状态正确性与 Ethereum 最终性

FIG 09

01 · L2 receipt 排序器已接收并放入 L2 区块；快，但仍依赖排序器和后续发布。

02 · L1 inclusion 批次数据或承诺已进入以太坊区块；重建与验证有了 L1 锚点。

03 · Settlement 挑战窗口已安全结束，或有效性证明已被验证；状态正确性达到协议定义的结算条件。

04 · L1 finality 承载数据、断言、证明或结算结果的 Ethereum 区块被共识最终确定。

第 3 层与第 4 层在界面里常被压成一个“finalized”，但逻辑上不同。不同钱包、浏览器和协议对 “safe / finalized / verified” 的命名也不完全一致。

Interactive lab 02

一笔提款，什么时候真正回到 Ethereum？

切换四种情景。时间只表达相对顺序，不代表任何网络的实时承诺。

01

发起提款

在 L2 销毁或锁定资产

02

批次发布

提款消息进入 L1 可见批次

03

挑战窗口

等待潜在错误被反驳

04

状态结算

断言成为可用结算状态

05

L1 释放

规范桥把资产发给接收者

正常 Optimistic 提款：主要等待来自挑战窗口。许多网络采用约一周配置，但必须以目标网络当前参数为准。

规范桥与第三方桥解决的不是同一个问题

规范桥按照 Rollup 自己的 L1 合约和消息规则铸造、锁定或释放资产，安全性与 Rollup 结算直接相连。第三方流动性桥让另一方先给你 L1 资产，再承担等待和再平衡；用户因此引入桥合约、流动性提供者与路由风险。 “到账更快”并不让底层 Rollup 更早完成协议结算。

09 / 12

Comparison

不要问谁全面胜出，要问代价落在哪一层

两条路线都在快速演化：Optimistic 可以加入 ZK 证明，ZK 系统也有中心化排序器与升级控制。比较应落到具体机制。

比较轴	Optimistic Rollup	ZK / Validity Rollup
L1 接受规则	先记录可挑战断言；无有效挑战或争议裁决后结算。	验证有效性证明通过后，接受新状态为已验证状态。
关键诚实假设	至少一个有能力、在线且可行动的诚实挑战者。	证明系统、约束实现和 L1 验证器正确；证明可持续生成。
常态 L1 计算	记录数据与承诺；通常不重放批次，争议时才执行裁决。	每个待结算批次执行简洁证明验证，而非重做原始执行。
规范 L2 → L1 提款	通常受挑战窗口影响，等待较长。	不需要欺诈挑战期；仍要等证明生成、发布和 L1 确认。
运行角色	排序 / 批处理 / 提议 + 监控 / 挑战基础设施。	排序 / 批处理 + 证明者 / 聚合者 + L1 验证器。
成本敏感项	L1 数据、批次提交、监控与极少发生的争议成本。	L1 数据、证明生成、证明验证与批次利用率。
EVM 迁移	成熟实现通常高度兼容 EVM 工具与字节码。	兼容性进展很快，但 VM、编译器、opcode 和调试差异需逐网核对。
典型失败模式	挑战者失灵、争议实现漏洞、挑战期活性攻击。	电路 / 证明系统 / 验证器漏洞、证明者停机或证明延迟。
共同风险	中心化排序与审查、批次停发、升级密钥、桥漏洞、数据发布、治理与应用合约风险。

费用不是“哪种证明更高级”的排行榜

user fee ≈ L2 execution + share of L1 data + share of settlement/proving + operator margin 数据大小、blob 市场、批次装载率、压缩方式、证明摊销、项目补贴和拥堵都会改变最终数字。某一时刻的最低费不能证明一种架构永久更便宜。

Existing EVM app

先核对兼容与迁移成本

部署字节码、预编译、Gas 语义、调试工具、索引服务和桥资产都应实测；标签不能替代测试网验证。

Fast canonical exit

核对结算时钟

有效性证明通常避免长期欺诈挑战窗口，但证明批次频率与 L1 确认仍决定实际提款时间。

High-value assets

先审升级和桥

即使证明机制完美，可快速升级的合约、托管桥或安全委员会也可能成为更近的控制点。

Decision rule

比较一个具体 L2 时，按顺序问：数据放哪里 → 状态怎样被认可 → 谁负责排序、证明或挑战 → 谁能升级或暂停 → 用户怎样强制交易或退出 → 目前处于什么安全阶段。最后才比较费用、生态和体验。

10 / 12

Security boundary

证明类型只守住一层，不替你守住整栋楼

从用户操作到 Ethereum 共识，中间至少有六层控制面；“数学证明”只是其中一层。

风险栈：越靠上越接近日常体验，越靠下越接近最终信任根

FIG 10

用户与应用 钓鱼、错误授权、前端被劫持、应用合约漏洞、预言机与经济攻击。

桥与消息 资产映射、消息重放、流动性桥对手方、跨域消息验证错误。

治理与升级 多签、安全委员会、延迟、暂停权、合约升级与紧急绕过路径。

运营与活性 排序器审查、批处理器停发、证明者离线、挑战者资金或网络故障。

验证协议 错误证明 VM、争议游戏、电路、证明系统、验证器合约和数据承诺实现。

Ethereum L1 数据可用性、合约执行、共识最终性，以及 Rollup 在 L1 上的托管状态。

排序器离线通常首先是活性问题，不必然能伪造已结算状态；但若强制包含或退出路径不可用，用户仍可能长时间被冻结。

面对任何 L2，先做八问审计

数据发布在哪里？Ethereum blob / calldata、其他 DA 层，还是委员会签名？能否从公开数据重建状态？
新状态何时被 L1 接受？挑战期、证明验证、额外延迟和安全委员会否决分别在哪一步？
错误证明或验证器是否已启用且无许可？“代码存在”“主网上线”“任何人可参与”是三个不同成熟度。
谁能排序、批处理、证明或挑战？中心化不会自动等于可盗取资产，但会影响审查、停机与故障恢复。
用户能否绕过排序器？强制包含、逃生舱、L1 发起提款的条件和延迟是什么？
谁能升级、暂停或替换验证逻辑？多签成员、阈值、时间锁、紧急权限与公开监控是否足够清楚？
规范桥托管什么资产？桥合约是否可升级，消息如何证明，失败后是否能恢复？
最坏情况下会发生什么？无效状态、资金盗取、交易审查、证明停摆和暂时冻结应分别评估。

六个最容易把人带偏的句子

Misread 01

“ZK 就是隐私链”

错。有效性证明可以只服务计算正确性；交易数据是否隐藏取决于额外的隐私设计。

Misread 02

“Optimistic 不验证”

错。节点仍执行验证；L1 把逐批证明换成可挑战断言，并在争议时裁决。

Misread 03

“有证明就不需要数据”

错。没有可用数据，其他节点难以重建状态、继续出块或支持用户退出。

Misread 04

“排序器中心化就能任意改余额”

不一定。它能审查或延迟，但无效状态能否结算取决于验证协议和升级权限。

Misread 05

“ZK 提款必然瞬时”

错。仍要等批次、证明生成、L1 验证和消息处理；只是通常没有长期欺诈挑战窗口。

Misread 06

“Rollup 等于完全继承 L1”

过度简化。数据模式、证明成熟度、升级密钥和逃生路径会改变继承到什么程度。

11 / 12

Recap

把整课压缩成四个问题

以后看到任何 L2，不先背项目名；先沿着数据、执行、验证和退出画一遍。

数据在哪？ DATA AVAILABILITY

谁来执行？ SEQUENCING & EXECUTION

错了怎办？ FAULT OR VALIDITY PROOF

如何退出？ SETTLEMENT & BRIDGE

Optimistic Rollup 的核心句是：“这个状态先作为断言存在；任何人可在窗口内用错误证明推翻它。”
ZK Rollup 的核心句是：“这个状态只有在有效性证明通过 L1 验证后，才成为已验证状态。”

六题自检

1. 排序器把新状态根提交到 L1，是否已经证明所有交易正确？

答案 B：状态根锁定结果，不说明结果怎样得出。

2. Optimistic Rollup 最关键的额外活跃假设是什么？

答案 C：错误必须有人在协议时限内发现并挑战。

3. 名称含 “ZK” 能否直接证明用户交易具有隐私？

答案 A：“零知识”证明技术不等于整条链默认隐私。

4. 有效性证明在 Ethereum、交易数据在链外，最接近哪种描述？

答案 B：证明位置与数据位置是两条不同轴。

5. 快速桥让 Optimistic 提款几分钟到账，说明了什么？

答案 C：快的是流动性路径，不是规范结算规则。

6. 判断一个具体 L2 安全性，最完整的做法是什么？

答案 A：安全是一条依赖链，不是单一证明标签。

12 / 12

Glossary & sources

术语与一手资料

本课刻意避免把快速变化的吞吐量、费用和“阶段”写成永久事实。实现细节请回到目标网络当前官方文档核对。

核心术语

State root / 状态根: 对整份状态的密码学承诺；能锁定状态，不独自证明状态转换正确。
Sequencer / 排序器: 接收并排序 L2 交易、生成快速区块或回执的逻辑角色。
Assertion / 断言: Optimistic 路径中对某个 L2 状态或输出的可挑战主张。
Fault proof / 错误证明: 在 L1 争议机制中证明某个状态转换不符合规则的过程。
Validity proof / 有效性证明: 证明某条执行轨迹满足约束、公开输入与输出关系成立的简洁密码学证明。
Witness / 见证: 证明者掌握、用于满足证明约束的完整执行轨迹与中间数据。
Data availability / 数据可用性: 网络参与者能取得重建和验证状态所需数据的保证。
Blob: EIP-4844 引入的专用数据对象；由共识层临时保证可用，面向 Rollup 数据发布。
Settlement / 结算: L1 合约按 Rollup 规则认可某个状态，可据此处理规范跨层消息与提款。
Canonical bridge / 规范桥: 由 Rollup 协议官方 L1/L2 合约实现、与其结算规则直接相连的桥。
Validium: 使用有效性证明，但把状态重建所需数据放在 Ethereum 之外的数据模式。
Force inclusion / 强制包含: 排序器审查或离线时，用户通过 L1 路径迫使交易进入 L2 处理流程的机制。

官方与协议原文

01 · ETHEREUM.ORG