Skip to content

Instantly share code, notes, and snippets.

@kmalloc

kmalloc/layer2-intro.md

Last active August 25, 2023 09:03
Show Gist options
  • Save kmalloc/bc6661e5d3cfa8292be3ed40d9578a40 to your computer and use it in GitHub Desktop.
Save kmalloc/bc6661e5d3cfa8292be3ed40d9578a40 to your computer and use it in GitHub Desktop.
Download ZIP
layer 2 简介
Raw
layer2-intro.md

区块链是分布式的共识账本, 网络中节点众多, 各节点达成共识需要复杂的协议交互(POW 算哈希/POS 投票), 导致系统整体并发能力低下, 无法支持大规模大范围应用(TPS极其低), 拥挤的结果是区块空间异常昂贵, 解决的方法是减少底层 transaction 数量, 把部分计算和存储移到线下.

image

state channel

bitcoin 上的闪电网络采取的方案, 基本思路是交互双方很多的中间交易是不必全部放到区块链中的, 此时可以通过把钱放到一个合约里面, 线下双方双签维护金额的变化即可, 无需其它无关人士来参与并协调达成共识, 具体例子参考[5]. image

plasma

vitalik 于 2017 年提出的初代扩展方案[0], 对 state channel 进行了扩展(如不限于只有交易双方而是 multi-party), v 神方案一如既往的复杂, 该思路将 channel 的离线合并 transaction 从概念上扩展成了一个二层的 blockchain, 使得其能力上限极高, 但实现上也极其复杂, 乃至不现实[1][2].

理解该方案有几个关键点:

  1. 有个中心的 sequencer/operator, 负责收集用户 transaction, 并进行打包, 构建 merkel root 写到主链合约上:
    • sequencer/operator 中心化, 但不需可信任.
    • 主链合约保证 sequencer/operator 作恶也无法损害用户利益:
      • 合约基于块的时间先后排序提取请求, operator 的非法块必然在最后.
        • 非法块 operator 必然不会广播.
        • 非法块会被诚实节点拒绝, 因此正常用户的 withdraw 时必然用的旧块.
  2. plasma 账本基于 utxo 模型, 无合约概念.
    • 能力模型只服务于基本的支付场景.
    • sequencer 逻辑简单, 可理论将 tps 提高至 visa scale(~24k/s)[3].
  3. 资金入场在主链进行, 转入 plasma 合约即可, sequencer 线下给对应的账号转入对应的资金.

image

  1. 难点在资金提取, 资金提取也是在主链发起, 需要发起者提供 utxo 以及对应的 merkel proof.
    • 主链合约是可靠的, 行为可监控可预测, 而 operator 是线下的, 不可信任.
    • 发起者需要能获取 proof(utxo所在块确实存在的merkle prooft), 依赖 sequencer 提供 data availability, 有中心化问题.
    • 主链合约无能力验证 proof 是否可靠, 依赖 plasma 链上第三方来挑战, 因此需要较长的 challange perioid.
    • sequencer/operator 作恶的情况下, 用户需在 challenge period 窗口内发起提取, 有 mass exit 问题[1].
      • 看到一个在未知块进行(大额)提款, 但却没法验证其是否合法(没数据)
      • 没法约束拒绝 sequencer 的恶意行为
    • 用户需要监控合约上的 withdraw 请求, 防止别人提取自己的资金, 对普通用户要求过高.

rollup

layer2 通过中心化的单一 sequencer 来出块, 减少去中心化协调各节点达成共识的消耗, 从而达到提高并发的目的, 但问题也由此产生, 怎么保证单一的 sequencer 出块是可靠的, 如果作恶怎么发现.

image

可以看到, 与 plasma 只存储块中 tx 的 merkle root 到主链不同, rollup 强调要把所有 transaction 数据存储到主链上. sequencer 作恶只会影响 state root, 而 tx 无法伪造, 不用回滚[6].

由于 rollup 存储 transaction 数据到主链, 数据量庞大而主链存储昂贵, 导致主链一个块不能存储太多 l2 的块, 因此 l2 的 tps 上限对 rollup 来说比较低, plasma 类型上限较高(数据越少越好扩展).

state root 代表 rollup 当前块的最新状态, 这个状态准确与否需要能验证, 验证方式目前分为 optimism 和 zk 两种. 1_ehGjsgy00RCnxr2x5wby9A

需要指出的是, state root 代表区块链的完整状态, 是很关键的一个数据, 比如从 rollup 提取资金需要通过二层链中的状态来生成证明(merkle proof), 主链是没有二层链的完整状态的, state root 是它唯一能相信, 唯一能校验的东西.

image

optimistic rollup

optimistic rollup(arbitrum&optimism) 脱胎于 plasma, 以牺牲一定并发能力为代价(2k/s), 增加了合约支持, 同时解决了 plasma 一些核心问题.

  1. 优化 data availability.
    • 二层数据压缩存储到主链, 并同时存储该块的 state root hash.
    • 通过回放主链上的 tx 能计算出 state root, 从而确保状态正确.
  2. 为保证储存到合约上的 transaction 能运行, 需要存储的数据比较多, 比如 signature/calldata 不能少.
    • tx 能回放保证了任何人来都可以来验证 sequencer 提交的 state root.
    • 依托主链进行数据储存, 安全可靠, 且实现容易.
  3. withdrawal 相对 plasma 来说很复杂:
    • 从二层发起 tx 到跨桥合约.
    • 合约 burn 掉对应的 token.
    • 跨桥合约记录 withdrawal.
    • proposer 根据跨桥合约中的记录和state roote生成 merkle proof.
    • 主链发起提取, 需要传入离线计算所得的 proof.
  4. state root 可靠性通过事后异步进行.
    • 不堵塞关键路径.
    • 提交 state root 不需要验证.
    • 旁观者通过回放 tx 验证主链 state root 是否.
    • 需要较长 challenge period(7days).

image

zk rollup

zk 其实先于 optimistic 出现, 同样启发于 plasma, 但致力于解决 plasma 的 data availability 问题, 最原始版本是设计了一套缩水版的数据结构试图将全部数据结构放置于主链合约中, 例如 3byte 地址等, 参考[8][9][10].

rollup 概念出现后, zk rollup 演变巨大, 现在我们谈论的 zk-rollup 和最初设想的版本已经差别非常巨大, 但总体上更通用, 也容易实现 evm 兼容.

zk 离线生成块时, 执行每个 tx 都会额外进行一系列骚操作, 从而最终出块时额外生成一个 proof, 这个 proof 保证生成的 state root 和块中的 tx 是一一对应的, 只要按块中的 tx 顺序执行,一定会得到这个 state root.

  1. proof 生成非常耗时, L2 TPS 有所影响, 但优化空间较大(软件硬件升级).
  2. state root 提交时需要验证 proof 也是非常耗时(gas).
  3. 兼容 evm 难度大, 对 evm 后续演化适配难度非常大.
  4. L1 资金提取近于实时, 因为 state root 是可靠的, 不用等人验证.
  5. tx 数据理论上可以不用储存到主链(zkSync?), security 没问题, data availability 的考量.
    • 真正意义上 permissionless, 用户不依赖任何人可以可靠获取数据.

谁来出块

  1. Centralized.
  2. POS.
  3. Total anarchy.

arbitrum && opstack 架构

  1. 更新 state root
    • opstack: sequencer 负责打包 tx, op-proposer 计算 state root 并上传 L1.
    • arbitrum: sequencer 负责打包 tx, validator 读取 tx 计算 state root 上传 L1.
  2. 判决 fault proof
    • opstack replayability proving, not implemented[11]
    • arbitrum interactive proving.

image

image

references:

  1. http://plasma.io/plasma-deprecated.pdf
  2. https://www.theblock.co/amp/post/10793/understanding-plasma-part-1-the-basics
  3. https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#
  4. https://news.bitcoin.com/no-visa-doesnt-handle-24000-tps-and-neither-does-your-pet-blockchain/
  5. https://community.optimism.io/docs/protocol/withdrawal-flow/
  6. https://vitalik.ca/general/2021/01/05/rollup.html
  7. https://jumpcrypto.com/writing/bridging-and-finality-op-and-arb/
  8. https://medium.com/privacy-scaling-explorations/an-introduction-to-optimisms-optimistic-rollup-8450f22629e8
  9. https://medium.com/coinmonks/zk-rollup-optimistic-rollup-70c01295231b
  10. https://github.com/barryWhiteHat/roll_up
  11. https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477
  12. https://github.com/ethereum-optimism/optimism/blob/develop/specs/proposals.md
  13. https://hackmd.io/mv0f3MiNSEi271ojKF3t9w
  14. https://mirror.xyz/msfew.eth/WQJaOcFkpTOZLns8MBQaCS4OepRoaZ7uoctnLAnalVw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment