L2の役割とOptimistic/ZK Rollupの違い

はじめに

今ではL3と言われるUXの観点を取り入れた新たな概念も生まれ、その点で様々なサービスが設計中であったり、試験的に実運用的に提供されていたりするが、その流れに乗っている背景を今一度皆さんと共有していこうと思う。

L1/L2という概念が生まれた背景

この記事を読むほとんどの読者はご存知の通り、ブロックチェーンという概念の大元はBitCoinというバーチャルの世界で「流動資産」を分散的に担保・透明化できる画期的なネットワークシステムが生まれたことで瞬く間に世界中に広まった。

しかし、当時のBitCoinネットワークの仕様上、持続性・参画性で問題があった。そこで、「重たい計算処理の大部分を分担しよう！」という発想で生まれたのがL2だ。

多くの取引に関する重たい計算処理をL2で分担をすることにしよう。しかし、効率性という観点で「ユーザーの1取引ごと」にその処理をL2で行うのは何か勿体無い。「そうだ！L2内で複数の取引を一つのバッチにして一緒に計算してしまおう！」ということで、L2では「複数の取引」を「バッチ」にし、それらをL1の「1つのブロック」に入れることにした。これにより、持続性という点でも大きく改善された。


しかし、「取引の結果(状態)が改竄されたものでないかを担保する必要がある」点では旧来のブロックチェーンと大差ない。そこで、L2で生成される複数取引のバッチもブロックチェーンのような形式で扱おうという発想となった。

そのため、実は従来のブロックチェーンの取引処理過程とL2の取引処理過程はかなり似ている。

異なるポイントはただ二つある。

• L2のバッチ内にある複数取引のブロックチェーンスタイルの適用自体はあくまで擬似的なものであり、実質オフチェーンでの処理である(≒時系列的に複数取引が合意形成された順番自体は担保しない)
• L2では複数の取引の結果(状態)をL1上の単一のブロックに保存することから、基本一回の形式でその点を担保しなければいけない

つまり、オフチェーンで計算された複数の取引結果を基本一回形式で改竄されたものでないことを担保しなければならないということだ。そのために、基本L2がL1に渡すものの中には、その点を最低限検証できるように「問題」と「答え」を渡している。

• 問題：圧縮された複数取引のバッチデータ
• 答え：複数取引の状態結果をまとめたハッシュ
  
  そして、上記を利用した証明方法として、現在以下の２つがある。
• Optimistic Rollup
• ZK Rollup

両者の大きな違いを以下にまとめる。

• Optimistic Rolupではオフチェーンで証明してくれるWatcherが必要になるが、ZK Rollupでは必要ない。
• Optimistic RollupではL2がL1に送信してからチャレンジ期間(大体1週間)と言われる取引結果が未確定の期間があるが、ZK Rollupでは即時確定。

Optimistic Rollupではバッチ内の複数取引の結果をL2上では一切証明しない。その代わり、チャレンジ期間の間に、オフチェーン上で公開されているOptimistic Rollupの複数取引計算処理コードを用いてL1に渡されたバッチからきちんと同じハッシュが生成されるかを確認する。そこで異なる結果が出た時に、複数取引結果の中の異常があるもののみを抽出(L2では取引の順序は保証しない)してその結果をL1のRollupコントラクトに渡し、検証され同様に異常であるとコントラクトが判断することでやっと異常状態を記録することができる。そして、チャレンジ期間の間に異常が記録されなければ正式に正史として記録確定される。

ZK Rollupでは基本的にL2上で99.9%複数取引の結果を証明するという考え。そのため、L2からL1に送信される際にValidity Proofという証明書も一緒に渡される。しかし、完全にオフチェーンであるL2上でその担保を完結させるべきでない(実質完全に証明することは性質上できない)ので、L1のRollupコントラクト上で「きちんとした方式で導出されたものか？」という点だけ検証は行う(≒これは実質L1からL2にブリッジされていた流動資産に対する微々たる確認)形をとっている。