扩容来自分工与摊薄。L2 执行许多交易，L1 不逐笔重算；一批用户共同承担数据发布、承诺和证明的固定成本。
Ethereum · Chapter 17 · Lesson 01
一千笔交易，为什么可以只向以太坊交一次作业？
Rollup 不会让以太坊停止负责。它把昂贵的逐笔执行移到 L2， 再把可重建的数据、状态承诺与可验证的正确性交回以太坊， 让许多用户共同购买一次结算。
Rollup common core / execute elsewhere, settle here
LAYER 2
01 · SIGNED TRANSACTIONS
用户签名；排序器接收并给出快速回执
02 · ORDER + EXECUTE + COMPRESS
L2 环境排序、执行，并把多笔输入压成批次
ETHEREUM L1
03 · PUBLISH DATA + COMMIT STATE
Blob / calldata 提供数据；合约记录状态承诺
04 · VERIFY + SETTLE
有效性证明，或可挑战主张；L1 给出最终裁决
DATA能否重建
ROOT承诺了什么
PROOF为何能接受
状态根不是答案，只是一份承诺。数据可用性让任何人能重建账本，证明或挑战机制让 L1 能拒绝错误状态。
“继承以太坊安全”有条件。还要检查证明系统、升级密钥、排序器、强制通道、桥与数据究竟由谁控制。
00 / ORIENTATION
先找瓶颈：以太坊贵，不只是因为“机器不够快”
正式目录主题：Rollup 的核心思想：链下批量执行，链上结算与保障安全
如果只想提高每秒交易数，换一台更大的服务器就行。但公共区块链的难点是： 陌生人必须在不信任运营者的前提下，对同一段历史达成一致，并且普通参与者仍有能力验证。
以太坊 L1 的每个执行节点都要接收区块、验证交易、运行 EVM，并检查新的世界状态。 这种“很多独立节点重复同一份工作”看起来浪费，却正是无需许可验证的来源。如果直接把 区块做得无限大，节点的带宽、计算和存储门槛会升高，能够独立验证的人会减少。 扩容因此不是单纯追求速度，而是在吞吐量、安全性、去中心化与可验证成本 之间重新分工。Ethereum.org 把 Rollup 归为从以太坊 L1 直接取得安全属性的 L2， 并把“执行移出 L1、数据提交回 L1”作为核心结构。[1]
逐笔重复执行
同一笔交换、转账或合约调用，被许多 L1 节点完整执行。安全很强，但每个用户都在购买稀缺的全网计算。
永久状态昂贵
修改 L1 状态会给未来节点留下长期负担。把所有应用状态都留在 L1，会把今天的操作成本传给明天的验证者。
数据也必须传播
即使计算搬走，验证者仍要拿到足以检查和重建结果的数据。Rollup 的主要 L1 成本往往因此来自数据发布。
最终裁决不能含糊
两个运营者给出不同结果时，用户需要一个共同承认的法庭。Rollup 把这个裁决点放在以太坊合约与共识上。
- 一句话定义 Rollup
- 一套在以太坊之外排序并执行大量交易、把重建状态所需的数据发布到以太坊， 再让以太坊合约通过证明或挑战规则确认状态承诺并结算跨层消息的协议。
这里的“链下”只表示不在 Ethereum L1 的 EVM 中逐笔执行，不表示数据 必须私密，也不表示运营者可以随意改账。L2 自己有节点、执行环境、区块与状态； 独立节点可以根据 L1 上的数据推导同一条 L2 链。Ethereum.org 也强调： Rollup 的交易数据被提交到 L1，而实际执行发生在单独的 Rollup 环境中。[2]
01 / MENTAL MODEL
把 Rollup 想成“分校做题，总校封卷”
执行地点改变了，但出题数据、答案承诺与最终裁决仍回到同一个可信根
想象一所总校每天要批改一千份同类作业。最笨的办法，是总校逐份重做； Rollup 的办法，是让分校先做、先排序、先汇总，再提交一套任何审查者都能核对的材料。
Three-part trust loopEXECUTE → PUBLISH → SETTLE
排序器把交易排成确定顺序，L2 节点执行状态转换。用户很快看到余额和应用状态变化。
压缩后的交易或状态差分进入 Blob / calldata，使独立参与者能重建过程，而不只看到答案。
Rollup 合约只接受满足有效性证明，或经过挑战规则未被推翻的状态承诺。
类比的重点不在“学校”，而在三份职责没有混为一谈： 执行回答“新状态怎么算出来”，数据可用性回答“别人有没有材料重算”， 结算回答“哪个结果能控制 L1 上锁住的资产与跨层消息”。只优化其中一项， 不能自动得到完整的 Rollup。
一个最小的形式化表达
Si+1 = F(Si, Bi)
Ci+1 = Commit(Si+1)
AcceptL1(Ci+1) ⇐ DataAvailable(Bi) ∧ ValidTransition(...)
S 是 L2 状态，B 是按顺序排列的一批输入，
F 是确定性的状态转换函数，C 是状态承诺。
L1 不必逐笔运行 F，但必须有规则判断这份承诺何时可以接受。
正确性 / Validity
这批交易有没有按协议规则执行？余额是否守恒？签名、nonce、Gas 和合约代码是否被正确处理？
可用性 / Availability
验证者和用户能否取得足够数据，独立重建 L2 状态、发现错误、生成证明或提出退出请求？
最终性 / Finality
这批结果是否仍可能因 L1 重组、挑战成功或证明尚未接受而改变？“看见回执”不等于“已经结算”。
活性 / Liveness
排序器停机或审查交易时，用户是否仍有强制包含、替代提议或无需许可退出的路径？需要等多久？
02 / ANATOMY
Rollup 不是一个合约，而是六个部件围绕一份状态协作
具体项目会拆成更多服务与合约；先掌握共同职责，再看不同实现名称
“排序器”“批处理器”“状态提议者”有时由同一家公司运行，有时由不同服务承担。 名称也会因技术栈而变化。判断系统时，先问每项职责由谁完成，不要只背进程名。
Rollup anatomyRESPONSIBILITY BEFORE IMPLEMENTATION
用户入口与 RPC
UX SURFACE
接收签名交易、估算费用、返回交易哈希；它是便捷入口，不是最终真相来源。
排序器 Sequencer
FAST PATH
决定交易的先后和 L2 区块内容，提供秒级体验，也拥有排序与临时审查权。
L2 执行节点
STATE MACHINE
运行 L2 状态转换，得到收据、日志、交易根和新状态根；独立节点可重复这一过程。
批处理与数据发布器
DA PATH
收集 L2 区块，编码、压缩，并把足以推导链的数据提交到 L1 Blob 或 calldata。
状态提议者、证明者与挑战者
VALIDATION
提交状态承诺；用有效性证明直接证明，或允许独立参与者在窗口内指出错误。
L1 Rollup 与桥合约
ROOT OF TRUST
记录被接受的状态、验证证明或争议、托管资产，并依据已结算消息释放提款。
例如 OP Stack 把“从 L1 数据推导 L2 链”称为 derivation；Rollup 节点读取 L1 上的 存款消息和排序器批次，确定性地产生 L2 区块。其 batch submitter 则负责对 L2 区块 数据编码、压缩并提交给数据可用性提供者。[3] [4] 这揭示一个重要边界： 排序器给你的区块是一条快速建议；L1 数据能推导出的链才是协议可验证的依据。
03 / TRANSACTION JOURNEY
从按下“确认”到 L1 认可，中间至少跨过七道门
点击步骤查看每个阶段写入什么、依赖谁，以及用户此时究竟拥有哪一级保证
钱包显示“成功”通常只代表交易已经进入某个 L2 区块。要变成能够从 L1 桥合约提款的事实， 还要经历数据发布、状态承诺、验证和 L1 最终性。不同项目给这些状态使用不同名称。
Interactive 01 / Transaction journey
逐步检查：这笔交易现在“确定”到哪一步？
按钮只切换固定教学内容。真实项目的发布频率、证明延迟、挑战窗口和状态命名并不统一。
04 · 数据发布：把“题目”交给以太坊
批处理器把一段 L2 区块编码并压缩，放进 Blob 或 calldata。独立 Rollup 节点随后能从 L1 读取这些输入，推导出同一条 L2 链。此时排序器不能靠隐藏交易内容让错误历史无人复算。
把三种“成功”分清
执行成功
L2 虚拟机没有回滚，收据状态为成功。它回答的是程序是否运行完，不回答所在 L2 区块是否最终成为规范历史。
排序器确认
排序器承诺把交易放进某个 L2 区块，体验很快；在批次尚未发布前，这通常仍是最弱的一层协议保证。
数据已锚定
对应输入进入 L1，独立节点能按协议推导 L2 历史；但状态证明、挑战窗口或 L1 最终性可能尚未完成。
已结算
L1 Rollup 合约接受相关状态或消息，且其 L1 区块达到所需最终性；提款才可按协议条件在 L1 生效。
04 / BATCHING ECONOMICS
“打包”不是魔法：省下的是重复开销，付出的仍是数据
批量摊薄固定成本，压缩减少每笔数据；两者共同决定用户的 L1 成本份额
如果每笔交易都单独向 L1 提交一份承诺、一次证明和一套固定字段，固定成本会重复出现。 Rollup 把很多交易装进同一批次，让用户共享这些固定开销，再用专门编码减少每笔输入的字节数。
Batch + compressMANY INPUTS / ONE ENVELOPE
TXTXTXTXTX
TXTXTXTXTX
TXTXTXTXTX
TXTXTXTXTX
BATCH DATA共享头部 · 地址索引 · 去除冗余 · 一次 L1 发布
每笔平均成本 ≈ L2 执行 + L1 数据/笔 + (批次固定开销 + 证明开销) ÷ 批内交易数 + 运营费用
批次越大，最后一个分数通常越小；压缩越好，第二项越小。但批次不会让数据成本归零： 签名语义、调用参数与状态变化仍需要足够信息供别人重建。等待更大批次也可能增加发布延迟。
Interactive 02 / Amortization
拖动两个变量，看“摊薄”和“压缩”分别改变什么
这是相对模型，不对应 ETH、美元或任何链的实时 Gas。固定参数只用于观察方向。
更多交易共同承担 800 单位的批次/证明固定开销。
原始教学假设为每笔 120 字节；比例越低，L1 数据项越小。
每笔平均教学成本
4.81
relative units / transaction
L2 执行
0.35
L1 数据
3.46
固定开销摊薄
1.00
当前 800 笔共享固定开销；继续增大批次主要压低固定项，改善压缩主要压低数据项。
Blob 改变的是数据价格轨道，不是正确性规则
EIP-4844 引入携带 Blob 的交易：大量数据随以太坊共识传播，但 EVM 合约不能像读取
calldata 那样直接读取 Blob 全文。执行层的 BLOBHASH 提供 KZG commitment 的
versioned hash；点求值预编译可进一步核对 commitment、versioned hash、指定点和值之间的关系。
这个独立的数据空间和费用市场，专门适合 Rollup 发布批次。[5]
截至本课日期，2025 年 12 月上线的 Fusaka 已启用 PeerDAS。验证者通过采样和分片托管来 检查 Blob 数据可用性，而不是每个验证者都下载每个 Blob 的完整副本；Ethereum 网络仍在 共识层集体提供数据可用性保证，同时能支持更高的数据吞吐。[14] [15]
Blob 数据只需要在 Ethereum 协议规定的窗口内保持可用，不要求每个执行节点永久保存全文。 Rollup 需要的是：在状态被证明或可挑战的关键时期，独立参与者能获得数据、重建链并采取行动。 这个保留窗口不会自动适配某条 Rollup 的证明延迟或挑战窗口；协议设计者必须让参数彼此兼容， 并为更久远的重放准备归档来源。历史归档服务可能长期保存 Blob，但那是查询历史的服务层问题， 不应和数据发布当时的共识可用性保证混为一谈。
05 / DATA AVAILABILITY
只给你答案哈希，却不给题目，为什么谁都救不了你？
数据可用性不是“网上某处可能有备份”，而是协议能否让独立验证与退出不依赖运营者许可
假设排序器声称新状态根是 0x7a…91，但隐藏了产生它的交易。
你无法知道自己的余额，挑战者无法定位错误，新的排序器也无法从最后状态继续服务。
一个短短的根可以承诺完整状态，却不能替代状态所需的数据。
Data availability gateCOMMITMENT ≠ DATA
状态承诺我承诺答案是这个根
公开输入数据任何人能重建题目与过程
可执行验证规则证明或挑战决定能否接受
Ethereum.org 将数据可用性问题描述为：网络怎样确信与某个摘要对应的完整交易数据确实已经提供， 同时又不要求每个轻客户端下载全部数据。对于 Rollup，数据必须足以让独立验证者确认状态转换， 也必须让用户在运营者消失时重建自己的状态和提款证明。[6]
同一份“正确性证明”，配上不同数据位置，会变成不同系统
Interactive 03 / Classification boundary
选择验证方式与数据位置，看系统名称为何改变
行业命名并非绝对统一；这里采用常见的技术分类，重点是额外信任假设发生在哪里。
Optimistic RollupL1 DA + FAULT PROOF
以太坊同时提供数据锚点与争议法庭
压缩输入在 L1 可得，独立节点能重算状态；若提交者提出错误承诺，观察者能在挑战期内向 L1 合约提交故障证明。安全至少依赖一个诚实且能行动的挑战者，以及实际可用的证明系统。
当有效性证明仍在 L1 验证、但完整数据放在委员会或外部网络时，常被称为 Validium；证明能阻止无效状态被接受，却不能强迫数据持有者把账户数据交给你。 Ethereum.org 也以“有效性证明相同、数据存放在别处”区分 Validium 与 ZK Rollup。 [7]
06 / COMMITMENTS + PROOFS
一个状态根如何代表几百万个余额，又为什么不能单独证明自己正确？
承诺负责压缩“是什么”，验证机制负责证明“怎么来的”
L2 状态通常被组织成可承诺的数据结构。根哈希像整本账簿的防拆封条： 改动任何账户或存储槽，根大概率都会改变。但封条只能证明“这本书没被换页”， 不能证明书里的计算符合协议。
From inputs to accepted stateDATA → TRANSITION → COMMITMENT
按序输入 Bi
用户签名、存款消息、系统属性与其他协议规定的输入。
tx₀…txₙ
状态转换 F
所有诚实节点以相同旧状态、相同输入和相同规则得到相同新状态。
S′ = F(S,B)
状态承诺 C
把庞大状态压缩成固定长度根；账户与存储可用 Merkle 路径证明包含关系。
C = H(S′)
L1 接受规则
有效性证明通过，或主张经过挑战机制成为最终；被接受的根控制结算。
Accept(C)
两条验证分支，共同回答同一个问题
理想的无需许可设计：先主张，任何人可反驳
提议者提交状态主张。系统先“乐观地”看待它，但在挑战窗口结束前不会给予完整结算保证。 若挑战者证明某一步状态转换错误，L1 合约拒绝或纠正无效主张。
- 正确性依赖可执行的故障证明与至少一个能观察、能挑战的诚实参与者。
- 优点是正常路径无需为每批生成有效性证明；代价是原生提款通常要等争议期。
随主张提交简洁密码学证明
证明者生成一份简洁证明，说明这批输入按规定电路从旧状态得到新状态； L1 验证器合约验证证明，不必逐笔重放所有计算。
- 正确性依赖证明系统、电路、实现和可能存在的可信设置都没有被破坏。
- 证明被接受后无需等待欺诈挑战；生成证明的成本、延迟和复杂度仍需承担。
Optimistic Rollup 把错误检测放在挑战路径；ZK Rollup 把正确性证明放在提交路径。 两者都在 L2 执行，也都需要状态承诺和 L1 结算。Ethereum.org 分别把故障证明与有效性证明 描述为两类 Rollup 的核心验证机制。[8] [7]
07 / FINALITY + SETTLEMENT
为什么两秒看到余额变化，仍不等于两秒后能从 L1 提款？
用户体验确认逐步增强；完整结算则是 L1 最终性与 Rollup 验证条件的交集
Rollup 同时服务两种需求：应用希望马上响应，桥和高价值结算希望结果不可逆。 因此它通常先给快速、较弱的确认，再积累更强保证。但 L1 最终性和 Rollup 的证明/挑战 是两条相关却不固定先后的时间轴，不能画成所有系统都遵循的一条流水线。
Finality has multiple coordinatesL1 FINALITY ∩ ROLLUP VALIDATION
很快；依赖排序器不撤回或重排尚未发布的 L2 区块。
输入已锚定；独立节点能推导 L2 历史，但相关 L1 区块仍可能重组。
数据、状态主张或证明所在的 L1 区块各自需要最终化；撤销它们需破坏 Ethereum 最终性。
有效性证明通过，或挑战规则完成；这份接受记录本身仍要随所在 L1 区块获得最终性。
OP Stack 的用户文档就把交易区分为 sequencer confirmed / unsafe、safe 与 finalized： 排序器收录提供快速反馈，数据发布到 Ethereum 后进入更强状态，承载它的 L1 区块最终化后再提升。 这是一个具体技术栈的名称，不应机械套给所有 L2，却很好地说明“确认有层级”。 [9]
结算层究竟结算什么？
以太坊不会把 L2 的每个账户余额复制进 L1 世界状态。它保存 Rollup 合约所需的承诺、证明状态、 消息根、资产托管和升级配置。当某个 L2→L1 消息被证明属于已接受的 L2 状态，L1 合约才允许它 释放资产或调用目标合约。这里的“结算”是以太坊对跨层可执行结果给出权威判断。
可用于低风险交互
应用可以在排序器确认后更新界面，但应理解这层历史可能在批次发布或 L1 重组时被调整。
依赖 Ethereum 共识
承载 L2 数据与承诺的 L1 区块最终化后，撤销成本上升到攻击以太坊共识的级别。
依赖 Rollup 验证规则
状态证明被接受或挑战窗口完成后，Rollup 合约把该状态作为后续结算依据；记录它的 L1 区块也要获得最终性。
还可能有应用自己的等待
交易所入账、第三方桥、预言机或多签可能要求额外确认；它们不是 Rollup 协议最终性的同义词。
08 / BRIDGES + WITHDRAWALS
资产没有真的“穿过”两条链：锁定、记账、证明、释放
原生桥把 L1 托管与 L2 状态连接起来；提款是 Rollup 安全模型最具象的一次检验
当你把 1 ETH 存入 L2，常见逻辑不是把同一枚硬币搬走，而是让 L1 桥合约锁住资产， 再把一条存款消息纳入 L2；L2 据此给你的账户记账。提款则沿反方向证明一条已结算消息。
Canonical bridge loopLOCK / MESSAGE / PROVE / RELEASE
托管与最终释放
- 存款：资产进入 L1 桥或门户合约。
- 消息：L1 事件成为 L2 必须处理的输入。
- 提款：验证已结算消息和包含证明后释放资产。
余额与应用状态
- 存款消息被派生并执行，用户获得 L2 余额。
- 资产可在 L2 应用中转账、交换或抵押。
- 提款先在 L2 销毁或记录，再等待 L1 认可对应状态。
原生提款与“快速桥”不是同一件事
原生桥按 Rollup 自己的证明与结算规则释放 L1 资产。Optimistic Rollup 的退出通常要等待 挑战期；Validity Rollup 在证明被接受后可更快建立正确性，但仍受数据发布、证明生成、L1 包含和 合约流程影响。第三方快速桥则可能先从自己的 L1 流动性池垫付，再替你等待原生结算——你得到的是 流动性服务，也额外承担该桥合约、验证网络或流动性提供者的风险。
L1 → L2：存款消息
用户直接向 L1 合约提交，因此即使排序器不愿服务，设计良好的系统也会在规定窗口后强制把存款纳入 L2 派生链。
L2 → L1：提款消息
用户要证明消息属于被 L1 接受的 L2 状态。提款安全直接依赖状态验证、消息根和桥合约实现。
强制包含 / Forced inclusion
绕过常规排序器，把协议规定的 L1 来源消息或交易请求送入慢路径；是否支持任意已签名 L2 交易，取决于具体技术栈。
逃生舱 / Escape hatch
在运营者长期失联时，用户是否能仅凭公开数据和 L1 合约取回资产；真实可用性取决于系统的精确实现。
OP Stack 规范通过 L1 sequencing window 和存款派生约束，让某些 L1 消息最终进入 L2； Arbitrum Nitro 也描述了排序器 inbox 与 delayed inbox / 强制包含路径。 [10][11] 它们说明抗审查并不要求快速排序器永远诚实，而要求排序器作恶时存在不依赖它的慢路径。
09 / CATEGORY BOUNDARIES
Rollup、Validium、侧链都“在别处执行”，真正差别在哪里？
不要按营销名称分类；沿执行、数据、验证、结算四条轴检查额外信任假设
“比主网便宜”“兼容 EVM”“有一座桥”都不能证明它是 Rollup。分类的关键是： 在严格的理想模型中，用户能否只依赖 Ethereum L1 数据与合约规则，重建状态、 拒绝无效结果并退出；真实部署还要继续检查许可角色、暂停键与升级密钥。
| 系统 | 执行在哪里 | 数据可用性 | 状态正确性 | 最终结算与额外信任 |
|---|---|---|---|---|
| Rollup | L2 执行环境 | 重建所需数据发布到 Ethereum L1 | L1 验证有效性证明，或执行故障证明/挑战规则 | Rollup 与桥合约在 L1；仍须检查升级、排序器、证明权限与实现缺陷 |
| Validium | L2 / 链外执行环境 | 外部 DA 网络或委员会 | 有效性证明在 L1 阻止无效状态 | 正确性可强，但数据方合谋扣留数据时可能冻结用户或阻止独立重建 |
| Optimium / Alt-DA | L2 / 链外执行环境 | 外部 DA 网络 | 乐观主张与挑战 | 挑战者还必须能取得外部数据；具体保证取决于 DA 集成与回退机制 |
| Sidechain | 独立链自己的执行环境 | 独立链自己的节点网络 | 独立共识/验证者集合 | 以太坊通常只看到桥结果；安全主要来自侧链共识与桥，而非 Ethereum Rollup 合约 |
这也是为什么“数据发布到 Ethereum”具有分类意义：它减少了一个额外的、独立于 Ethereum 的 数据可用性信任源。Ethereum.org 的扩容总览明确把 Rollup 描述为在 L1 发布数据并由原生 Ethereum 安全保障的方案，同时把数据存于别处的 Validium 单独列出。[1]
10 / SECURITY INHERITANCE
“继承以太坊安全”不是贴纸，而是一条必须闭合的证据链
理想协议保证、当前部署成熟度与外围操作风险要分层检查
在理想 Rollup 中，排序器可以停机或审查，却不能让一笔无效提款最终通过； 用户能依据 L1 数据重建状态，并通过 L1 合约强制处理或退出。但真实系统常有升级代理、 安全委员会、许可证明者、暂停键、尚未完全启用的故障证明，以及普通软件漏洞。
Three security ringsFOUNDATION / PROTOCOL / OPERATIONS
L1 共识与数据基础
承载 Blob / calldata、Rollup 合约、证明验证与桥资产。相关 L1 区块最终化后，历史回滚需要攻击以太坊本身。
状态与退出规则
派生规范、状态转换、证明或挑战、消息包含、提款和异常路径。任何漏洞都可能破坏“正确数据得到正确状态”的链条。
当前控制者与服务
排序器、批处理器、证明者、RPC、前端、升级多签与安全委员会。它们影响审查、停机、升级与用户实际可达性。
四个攻击面，四种不同后果
排序器拒绝或重排
可影响先后、MEV 与短期可用性；若强制通道有效，通常不能永久阻止用户，但用户会承担延迟和 L1 成本。
提议错误状态根
必须由有效性证明在接受前阻止，或由故障证明系统在挑战期识别并推翻；仅靠声誉不是协议保证。
隐藏重建所需数据
严格 Rollup 把数据放到 Ethereum DA 来降低这项风险；外部 DA 会引入委员会或另一网络的活性假设。
升级密钥改写规则
可快速修复漏洞，也可能替换验证器、桥或退出逻辑。延迟、门槛、委员会结构与用户退出窗口决定治理风险。
Ethereum 的扩容路线也承认现实 Rollup 仍可能依赖中心化排序器和有限证明者，去中心化是逐步推进的。 [12] L2BEAT 的 Stage 框架尝试衡量 Rollup 从“由少数实体控制” 向“由代码控制”的成熟度，但该框架自己也明确提醒：Stage 主要衡量去中心化和信任最小化， 不等同于无漏洞或整体安全评级。[13]
Safety：坏结果能否结算？
关注无效状态、伪造提款、双花、恶意升级。最坏情况下，攻击者能否把不属于自己的 L1 资产取走？
Liveness：好结果能否前进？
关注停机、审查、数据扣留、证明者失联。最坏情况下，诚实用户要等多久、付多少，才能恢复交易或退出？
Correctness：规则是否实现正确？
证明电路、故障证明 VM、派生逻辑、桥与合约都可能有 bug；密码学正确不代表集成代码正确。
Governance：谁能改变规则？
管理员、代理升级、紧急委员会和参数治理可能覆盖常规证明路径；权限就是安全模型的一部分。
11 / PRACTICAL AUDIT
面对任何一条 L2，用八个问题拆掉营销语言
目标不是立刻判定“安全/不安全”，而是把每个保证对应到可检查的机制与控制者
真正的 Rollup 分析不是先看 TPS、TVL 或品牌，而是画出一条失败路径： 排序器消失、数据发布停止、证明者拒绝工作、管理员试图升级时，普通用户还剩哪些无需许可的动作？
数据究竟发布到哪里？
Ethereum Blob / calldata，还是外部 DA 网络、委员会或运营者服务器？数据是否足以从 L1 推导完整状态？
谁能提交状态承诺？
只有许可地址，还是任何满足规则的人？提议者失联时是否有替代路径，多久才能触发？
谁能证明或挑战？
证明系统是否实际启用、无需许可且覆盖全部状态转换？挑战或证明需要什么硬件、押金与时间？
排序器停机怎么办？
用户能否通过 L1 提交消息、强制包含、继续出块或退出？这条慢路径是否经过实际测试？
桥资产由谁控制？
L1 托管合约地址是什么？提款依赖哪个消息根和证明？第三方桥是否引入独立验证者或流动性风险？
谁能升级或暂停？
多签门槛、成员独立性、时间锁、紧急权限与退出窗口如何？升级能否替换证明验证器或转移桥资产？
你看到的是哪层最终性？
前端所称“完成”是排序器回执、L1 数据包含、L1 最终化，还是状态已经能在原生桥结算？
最坏情况下能否独立退出？
不依赖官网、RPC 和运营者，用户能否从公开数据构造余额与消息证明？费用和等待是否现实可承受？
一个三分钟阅读顺序
- 先看项目风险页和合约权限：快速识别 DA 类型、证明状态、升级与安全委员会。
- 再看官方协议规范：确认 L1 数据如何派生 L2、状态根如何提交、证明/挑战和提款如何运行。
- 最后核对链上事实：合约地址、代理实现、管理员、时间锁、事件与最近批次是否和文档一致。
- 把“计划”与“当前”分开：去中心化排序器、无需许可证明和逃生舱的路线图，不等于今天已经启用。
12 / RECAP
把整课压成五个动词，再用六道题检验
能沿这五步说清责任、数据与失败路径，就已经掌握 Rollup 的共同骨架
01ORDER
排序大量签名交易，提供快速 L2 区块。
02EXECUTE
按确定性规则从旧状态计算新状态。
03PUBLISH
把可重建数据压缩后发布到 Ethereum。
04VERIFY
用有效性证明，或允许错误主张被挑战。
05SETTLE
由 L1 合约接受状态并执行跨层消息。
Rollup 的扩容不是删除工作，而是把工作放到更合适的位置：L2 节点承担高频执行， Ethereum 承担共享数据、最终裁决和桥资产结算。批处理让许多用户共同购买 L1 资源； 证明或挑战让 L1 不必重放每笔交易；公开数据让任何人仍能核对、接管和退出。
1. Rollup 所说的“链下执行”最准确的意思是？
答案：B。链下是相对 Ethereum L1 执行而言；L2 仍是一套有节点、区块、状态和确定性规则的协议。
2. 为什么只把最新状态根写到 L1 还不够？
答案：C。状态根只是一份固定长度承诺；没有输入数据，独立参与者无法重建状态、定位错误或构造退出证明。
3. 其他条件不变，批次从 100 笔增到 1,000 笔，最直接摊薄的是？
答案：A。增大批次主要摊薄批次与证明等固定成本；数据每笔成本仍存在，压缩才直接减少每笔发布字节。
4. 钱包收到排序器的两秒确认，最稳妥的理解是？
答案：B。排序器确认提供快速体验，但批次可能尚未发布，L1 也尚未最终化，状态证明或挑战流程更未必完成。
5. 有效性证明在 L1 验证，但数据只由外部委员会保管，额外风险是？
答案：C。有效性证明约束状态正确性；若数据由外部委员会保管，委员会仍可能扣留数据，使用户无法独立重建或退出。
6. 看到“继承 Ethereum 安全”时，下一步最应该做什么？
答案：A。真实保证还取决于数据、证明/挑战、桥、强制路径、升级权限与代码实现；名称本身不是安全证明。
13 / GLOSSARY + SOURCES
把术语钉牢，并保留可追溯的一手路径
协议会更新；定义、数据路径和权限应回到当前规范与链上合约再次核对
- L1 / Layer 1
- 本课指 Ethereum Mainnet：提供共识、数据可用性、Rollup 合约执行与最终结算的基础层。
- L2 / Layer 2
- 建立在 L1 之上的扩容协议。Rollup 是 L2 的一种，其安全属性通过数据和验证规则锚定到 L1。
- Sequencer
- 接收、排序并通常执行 L2 交易的服务。提供快速确认，但不等同于 Ethereum 最终性。
- Batch
- 按协议编码、压缩并共同发布的一组 L2 区块或交易数据，使固定 L1 开销被许多用户分担。
- Blob
- EIP-4844 引入的数据载体，随 Ethereum 共识提供阶段性数据可用性，并拥有独立于普通执行 Gas 的费用市场。
- State commitment
- 对 L2 状态的固定长度密码学承诺，常见形式是状态根或组合输出根；必须配合数据和验证规则才有意义。
- Fault proof
- 在乐观验证中证明某个状态主张错误的机制；真实安全性取决于系统是否启用、覆盖完整且允许诚实方行动。
- Validity proof
- 简洁证明某次状态转换满足规定计算的密码学证明；L1 验证证明而不是逐笔重放整个批次。
- Settlement
- L1 Rollup 合约接受状态或跨层消息，使其能够权威地控制 L1 桥资产或后续协议状态。
- Forced inclusion
- 在排序器审查或停机时，通过 L1 通道提交协议允许的消息或交易请求，使其按特定延迟与约束进入 L2 派生链的慢路径；能力因技术栈而异。
以下外部来源将在新标签页打开。
-
[01]
ethereum.org · Scaling
Rollup 的 L2 定位、执行移出 L1、数据回到 L1，以及 Rollup 与 Validium 的基本分类。
-
[02]
ethereum.org · What is layer 2?
L2 与 Rollup 的入门定义、数据提交到 L1 与安全继承的教学说明。
-
[03]
OP Stack Specification · Batch Submitter
批处理器如何收集、编码、压缩并把 L2 排序器数据提交给数据可用性层。
-
[04]
OP Stack Specification · Derivation
Rollup 节点如何从 L1 数据确定性地推导 L2 链，以及排序器快路径与 L1 规范路径的关系。
-
[05]
EIP-4844 · Shard Blob Transactions
Blob 交易、KZG 承诺、版本化哈希、独立费用市场，以及 Rollup 如何使用 Blob 发布数据。
-
[06]
ethereum.org · Data availability
为何状态摘要不能替代完整数据，以及 Rollup 验证、重建和挑战为何依赖数据可用性。
-
[07]
ethereum.org · Zero-knowledge rollups
有效性证明、状态承诺、L1 数据、结算和 ZK Rollup 与 Validium 的安全边界。
-
[08]
ethereum.org · Optimistic rollups
乐观主张、挑战窗口、故障证明、L1 数据可用性、结算与原生提款延迟。
-
[09]
Optimism Docs · Transaction statuses
Sequencer confirmed / unsafe、safe 与 finalized 的具体定义，用于理解确认层级。
-
[10]
OP Stack Specification · Protocol overview
排序窗口、L1 存款派生、抗审查路径和 Rollup driver 的协议级总览。
-
[11]
Arbitrum Nitro · Technical whitepaper
排序器、Sequencer Inbox、Delayed Inbox、批次数据、状态转换与交互式证明的完整设计。
-
[12]
ethereum.org · Scaling Ethereum
Rollup-centric 扩容、Blob、中心化排序器与证明者，以及逐步去中心化的当前路线。
-
[13]
L2BEAT · Stages Framework
Rollup 从许可控制走向代码控制的成熟度框架，以及 Stage 不等同于完整安全评级的明确限制。
-
[14]
EIP-7594 · PeerDAS
通过数据可用性采样扩大 Blob 数据容量的协议设计，以及 Rollup 扩容为何受 L1 DA 吞吐约束。
-
[15]
ethereum.org · PeerDAS
Fusaka 上线后的当前运行模型：节点采样并分片托管 Blob 数据，以及 BPO 如何逐步提高数据容量。