# オンチェーンコミットメント ###### tags: `Yellow paper` zkRollupは、十分に短いL1へのコミットメント間隔(10分など)を採用することで、即時のファイナリティを得ることが実現できる。ただ短い間隔にするとガスコストは高くなるので、即時のファイナリティとガスコストはトレードオフの関係にある。 具体的にはzkのペアリング検証には200kを超えるガスが必要となり(groth16の場合)、これはzkRollupの手数料の大きな負担になる。 これを解決するために次の手法を提案する。 ## 閾値署名によるステート共有証明 一般的なzkRollupではステートは再構築可能なようにL1コミット時にcalldataに載せておくが、SRUではステートをL1にコミットしないため、SRUのオペレーターノードはブロック生成をして、ステートを公開しないということが考えられる。このような攻撃を防ぐために、SRUのオペレーターノードの51%以上が、ブロックに含まれるステートを受け取ったことを確認しブロックハッシュに対して署名することで、SRUネットワーク内のノードが正しく受け取れたことを証明できる。またこの時にzkRollupのロジックが正しく実行されたことを証明するProofをブロック生成者から受け取り、Verifyすることで全部のtxを実行することなく状態遷移が正しいことを検証することができる。 閾値署名をオンチェーンで検証し半数以上の署名があることを検証することもできるが、ペアリングの検証が必要になるのでガスコストがかかる。Optimistic　Commitと同じようにオンチェーンに検証できるデータをコミットするが、検証自体はしない。オペレーターノードは供託しネットワークに参加しているので、供託している資産を奪われてまで不正な署名のデータをコミットするインセンティブがない。 SRUオペレーターが閾値署名をする条件は以下の通りである。 - ブロック内の情報が過不足なく共有されている - ブロック内のtxのzkEVMで実行されたproofがあり、verifyが通ること - 分散ストレージにステートがアップロードされていること - ブロック生成者がブロック生成者としてリーダー選出されていること **また、Optimistic Commit が受理されるにはその commiter が L1 ETH で供託を deposit していなければならない。** ## Recursive zk finalize zk verificationを使用しないコミットメントは、zk verificationを行う前のプリコンセンサスとして扱う。 ```mermaid flowchart LR pre-consensus-commit --> id2[pre-consensus-commit] --> id3[pre-consensus-commit] --> id4>consensus commit] --> id5[pre-consensus-commit] --> id6[pre-consensus-commit] ``` コンセンサスコミットは、前回のコンセンサスコミット(チェックポイント)から最新のプリコンセンサスコミットまでを、再帰的なzkで検証する必要がある。プリコンセンサスではzkRollupのロジックが正しいのかを検証する回路を用いる。コンセンサスコミットでは再帰でプリコンセンサスのproofが正しいのかを検証する回路を用いる。 ## プリコンセンサス中のexitについて Verifyされるまでは状態遷移が確定しないので、プリコンセンサスを導入するとexitできるタイミングが限定される。6時間ごとにverifyすることを仮定すると、それまでのプリコンセンサスの間はexitできない。緊急を要する場合、ペアリング検証代をユーザーが負担することにより、いつでもexitすることができる。 ### verifyされればそれ以降exitできるケース aliceは12ブロック以降state更新をしなければいつでもexitできる。bobはupdate stateを実行してないのでexitできない。 ```mermaid sequenceDiagram autonumber 10 Pre ->> 10 Pre : alice => bob 11 Pre ->> 11 Pre : alice udpate state 11 Pre ->> 11 Pre : bob udpate state 12 Verify ->> 12 Verify : bob => charlie 13 Pre ->> 13 Pre : alice can exit 13 Pre ->> 13 Pre : bob cannot exit ```