跳到正文
Financial Context Wiki

Rollup

说明区块链 Rollup 如何执行交易、发布数据与承诺、验证状态转换、在基础层结算，以及由此引入的不同运营风险。

更新于

仅供教育参考，不构成财务、投资、桥接或安全建议。Rollup 的保证取决于其已部署合约、证明系统、数据可用性、运营者权限、治理和基础层，而这些均可能改变。

直接答案

Rollup 是一种区块链扩容设计：它在基础层之外执行交易，同时利用基础层发布协议规定的数据或承诺，并结算有争议或已证明的状态转换。多笔交易共同分摊基础层数据与结算成本。因此，Rollup 不只是交易压缩，单独一个状态根也不能提供重建链所需的交易数据。

乐观 Rollup 通常接受状态声明，除非成功的错误证明挑战表明某次转换无效。ZK Rollup 则提交由结算合约验证的有效性证明。这些名称描述的是状态转换如何被接受，并不对排序器去中心化、数据存储、升级控制、费用或提款时间作出统一保证。

工作原理

  • 排序与执行。 排序器或其他排序机制选择交易、确定顺序并计算由此产生的 Rollup 状态。用户可能在结果得到基础层确认之前收到快速回执。
  • 发布数据。 系统向基础层发布足够的协议输入数据，常见方式是 calldata 或 Blob，也可能采用独立的数据可用性设计。数据可用性决定独立节点能否重建并验证 Rollup 状态。
  • 承诺状态。 Rollup 发布状态根或其他承诺，将其与某个执行结果绑定。承诺很紧凑，但并不是底层交易历史。
  • 验证转换。 乐观设计依赖挑战窗口和已部署的错误证明流程；ZK 设计依赖有效性证明与链上验证器。两种设计都仍需考虑证明系统漏洞、权限与活性。
  • 结算与提款。 基础层合约决定声明或证明何时被接受，以及消息和资产如何最终确认。规范提款可能受证明期、挑战期或最终确认延迟影响；快速桥还会增加独立的流动性提供者和对手方风险。
  • 升级与恢复。 治理、安全委员会、守护者或管理员可能暂停或升级合约。必须检查具体已部署 Rollup 的时间锁、逃生路径和强制纳入机制，不能仅从类别推断。

示例

假设一个批次包含 1,000 笔交易。用户合计支付 0.8 ETH，测得基础层数据成本为 0.5 ETH，Rollup 执行成本为 0.2 ETH。无法解释的剩余为 0.8 - 0.5 - 0.2 = 0.1 ETH，即每笔交易 0.1 / 1,000 = 0.0001 ETH，其中尚未扣除证明生成、基础设施、失败批次、资金成本和退款。这是成本核对，并非运营者利润。

在把该批次视为最终确认之前，应分别确认回执是否仅由排序器确认、数据与承诺是否已到达基础层、相应错误证明窗口是否结束或有效性证明是否获接受，以及提款消息是否另外达到可执行状态。

风险

  • 中心化排序器可以审查、重新排序交易，或暂时停止服务。
  • 批次数据缺失或不可用，可能妨碍独立重建与退出。
  • 错误证明程序、有效性电路、验证器或客户端实现可能存在漏洞。
  • 挑战者或证明生成者可能离线、受审查、资金不足或权限配置错误。
  • 基础层拥堵、重组或故障可能延迟发布、证明与结算。
  • 升级密钥、守护者或治理可以改变代码、参数或桥接行为。
  • 即使 Rollup 执行正确，规范桥和代币映射仍可能失败。
  • 费用、证明时间与提款延迟因部署而异，并可能在升级后改变。

常见误区

  • 所有 Rollup 都会把一切永久存储在基础层。 发布格式和归档保证各不相同；例如，Blob 并不是永久存储。
  • 排序器回执就是最终结算。 它可能只是早期排序承诺，而非已在基础层结算的结果。
  • ZK 就意味着隐私。 在 ZK Rollup 中，有效性证明用于证明计算正确；交易隐私是另一项设计选择。
  • 乐观模式意味着不验证。 正确性依赖可重现的数据、有效运行的错误证明系统，以及能够挑战无效声明的参与者。
  • 较低的平均费用消除了运营风险。 共享结算可以降低成本，但排序器、证明、治理、桥和数据可用性依赖仍然存在。

相关主题

来源

导航

搜索知识库...