Preconsensus mechanism
zkRollupにおける即時の資金回収を損なうことなく、検証ガスコストを削減する
Recrusive SNARKを使ってzk-Rollupでの検証コストを削減する
背景と動機
zkRollupは、十分短いコミットメント間隔(インターバル)で即時ファイナリティを達成することができる。
この方法では、アグリゲータの信頼リスクはインターバルの長さに応じて増加するが、ファイナライズのコストはインターバルの長さに応じて減少していく。
長ければ長いほど多くのTxがバッチされるので、経済的だがアグリゲータへの依存が大きくなる
まず、zkのペアリング検証がGroth16ベースで200kガス以上(= $100〜$500 )とする
これは、zkRollupの各インターバルでアグリゲーターがコミットメントを検証し、確定するためのコスト
Recrusive SNARKと効率的な証明計算システムで多くのTxを集約することができても、この間隔を変更することは困難であり、単純に間隔を長くすると安全性が損なわれる。
zkRollupのコミットメント間隔が短いのは、そのコミットメントで即時ファイナリティを得るためで、間隔が短い限り即時ファイナリティは許され、悪意のあるアグリゲーターが元に戻すインセンティブはほとんどないため、このコストは無視できない。
つまり、単に間隔が長ければいいとい訳でなく、即時ファイナリティを得るためにも適宜バッチしてくれた方がUX的には嬉しかったりする
つまり、インターバルについて考えると、
1. アグリゲータへの依存に対する安全性
2. 検証ガスコスト
3. 即時ファイナリティによって受けるUX
そこで、zkRollupにおいて、安全な即時終了と長い検証間隔を両立させる方法を考える必要がある。
Intmaxのアプローチ
アグリゲータのランニングコストは、コントラクトに対するzk-verificationのガス代が高く、検証間隔が短いという条件に起因している。そこで、安全性とUXを損なわずに、検証間隔を長くする。
1. zk-pairing-verificationのスキップ
まず一つ目は「ペアリング計算をスキップして、コミットメントに対する簡単なfraud proofを導入する」という案
ペアリングは特殊な楕円曲線を使った証明の検証で用いられる。
アグリゲータは、zkRollupのコミットメントを検証するために必要なproofなどをコントラクトに提出するが、この時点ではペアリング計算を実行せず、20万ガスの支払いをスキップする
このコミットメントは、一定期間経過後に検証される。
コミットメントの各状態は、次のコミットメントのpublic inputとなる。
アグリゲーター(証明者)は事前にいくらかEther(slahing用の担保)を投入する。
これは不正発見者(検証者)にインセンティブを与える
コミットメントは以下のようになる。
$ hash(public\ input, {zk\ proof\ data}, last\ state\ root\, next\ state\ root, tx\ hash, aggregator\ /address)
プリイメージはイベントオンチェーンで発せられ、このコミットメントはコントラクトストレージに保存される。
このアプローチはOptimistic Rollupのメリットを享受できる
フルノードや特別な設定なしに、誰もがORUにおける監視者になることができる
検証や不正行為の証明に必要なものはすべてオンチェーンで発行されるイベント内にあるため、DA問題は発生しない
L2 Txデータおよびその結果の保存は、zkのpublic inputとproofにすでに集約されているため、fraud proofの実行時に必要ない
悪意のあるアグリゲーターが悪意のあるmerkle rootを提出し、すべてのtxデータとmerkle treeデータを放棄した場合、fraud proofのためにフルノードを立ち上げる必要はない。
zk-proofのデータを確認し、ペアリングしてverify関数を実行するだけで、そのような悪意ある行為を検出することができる。
しかし、L1上で51%攻撃が発生し、悪意のあるmerkle rootが正当化された場合、それを阻止することは難しい。
51%攻撃の実行コストはブロック長に比例して増加するため、51%攻撃を困難にするために十分な長さの期間が必要である。
理想的な間隔の長さは7日間(ORUの終了期間がであるのと同じ理由)
採掘コストと現実的な攻撃インセンティブから計算できる。したがってわざわざORUを避け、この解決策を使う理由はない。
zk検証を行わないpre-consensus commitment、recursive zk’s pairingによる最終化
前述の51%攻撃問題を以下の方法で克服することができる。
zk検証を行わないコミットメントをpre-consensusとして扱い、zk検証を伴うファイナリティを制限するのである。
(consensus commitment ) => (pre-consensus commitment ) => (pre-consensus commitment ) => ... => (pre-consensus commitment ) => (consensus commitment )
consensus commitment前のコミットはすべてペアリングによるコンセンサスを制限している。そのため、L2ユーザは安全にトランザクションを即時ファイナリティさせることができる。
このconsensus commitmentは、再帰的zkを用いたすべてのpre-consensus commitment と検証する必要がある。
回路はpre-consensus回路とrecursive回路の2種類
pre-consensus回路には、zkRollupedされたdappのロジックが含まれる。
recursive回路は、L1 のpre-consensusデータをpublic inputとして取得するだけでよい。
pre-consensusはrecursive zkによって時間軸の水平方向にマージされる。
同時に、recursive zkはpre-consensus commitment に大量のトランザクションを集約するために垂直方向にも使用することができる
もし不正なpre-consensus commitment がペアリングによる合意検証を妨害した場合、zk-pairingによって数学的に不正を証明することが可能
この不正が証明されると、アグリゲーターはzk-verifier機能でこれを除去し、アグリゲーションとpre-consensus commitment を再開する。
ファンドホルダーは、急げばいつでも20万ガスでプレコンセンサスからコンセンサスを作ることができる。(もちろん、アグリゲータによるコンセンサスを待つこともできる)。
すべてのinputはすでに集約されており、これらはオンチェーンイベントで検索できるため、コンセンサスのファイナリティ確認に特別な設定は必要ない。
この再帰的検証のガスコストは、pre-consensus commitment の証明がエントリハッシュにハッシュ化されるため、いくつ検証されても増加しない
51%の攻撃者は悪意のあるマークルルートを確定できない。なぜなら、すべてのルートは最終的にzk-circuitで実装されたコントラクトコードの論理によってオンチェーン検証を受けるから
参考文献