# オンチェーンコミットメント ###### 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 ```
Last changed by  
 
IntMax
Intmax zkRollUp
113

Read more

intmax operator 旧仕様 (PlonK 版)

intmax の operator 側の仕様について, account や transaction の表現方法などを記載しています. Notation $\mathbb{N}$ は 0 以上の整数全体からなる集合, $\mathbb{N}{m} := [0, 2^m - 1]$ $(m > 1)$ は $m$ bits で表せる数値全体からなる集合, $\mathbb{B}{n}$ $(n \geq 1)$ はちょうど $n$ bytes のバイト列全体からなる集合, $\mathbb{B} = \bigcup_{n = 0}^{\infty} \mathbb{B}_{n}$ は任意の長さのバイト列全体からなる集合とする. $\mathbb{F}_r$ は位数 $r$ の有限体とする. $E$ は楕円曲線, $E(\mathbb{F}_r)$ は $E$ の $\mathbb{F}_r$ 有理点全体からなる集合とする. $E(\mathbb{F}r)$ 上の二項演算 $+$ をうまく定めることにより, $E$ の無限遠点 $\mathcal{O}{E}$ を単位元とする可換群の構造が入る. 楕円曲線 $E(\mathbb{F}r)$ には素数位数 $s$ の元 $B$ が存在するとし, $B$ が生成する巡回群を $\langle B \rangle := { B, 2B, \ldots, (s-1)B, sB = \mathcal{O}{E} }$ で表す. その任意の元 $G \in \langle B \rangle$ は,

9/8/2022
Dfinity まとめ

単一障害点を作らないということでDfinityを利用。 メモリは4GBで十分そう。 Dfinity上のオペレータをチューニングする。最大限パフォーマンスを引き出せるような設計とプログラムにすること。 Reply Edit Delete

8/21/2022
DfinityとLightning Nodeの比較表

ノードとして「Dfinity」「Lightning node」のどちらを使用すればいいかの判断材料。 比較表 早見表 評価基準: それぞれを相対的に見た大変さ・コスト 評価 ◎: とてもいい

8/21/2022
Dfinity benchmarkとcanisterについて

概要 benchmark A. 10回PUT(更新)処理とGET(取得)処理を行う B. 100回PUT(更新)処理とGET(取得)処理を行う 総評 スケール canisterの呼び出し canisterとコスト Reference 概要

8/21/2022
Read more from IntMax
Published on HackMD