Intmax におけるzk-Rollupの最適化
基本的に「state diffをできるだけ貯める、削減する->zkp検証間隔延長->その分コストが下がる」というアイデア
最適化1 Preconsensus Mechanism
ORUとZKRUのいいとこ取り
state diffとは、過去の取引データを全てL1上に保存するzkRollupの原案とは異なり、最終的な変更を全てデータベース自体に書き込むことでレイヤー2データベースを再構築し、ユーザーの資産の安全を保証する方法
ユーザーがオンラインであれば、直接データを渡す。オンラインでない場合は、取得可能なデータを安価な領域(Proto-dankshard blob)に一定期間保存する。
これは、L1上でも実際にトランザクションが実行できることが前提のOptimistic Rollupでは不可能だが、zkRollupでは可能
ここでのキモとなる技術はProto-dankshard blob
最適化2 zkRollup with limited online assumption
state diff(user asset storage)の大部分を占めるEOAのdiffを直接オンラインでユーザーに配信することで L1 exitできる。
これにより、頻繁に共有・使用されるスマコンのデータのみがstate diffに残り多くの変更はその中で重複して使われる。
この重複するデータはShared Storageと呼ばれる
最終的なデータのみが書き込まれるため、大きな効率化と言える。
オンラインでない場合でも、zkRollupのオペレータがZKP回路によって強制的にユーザーのstate diffを一定期間Proto-dankshard blobに書き込むという新しい手法によって、コストをかけずに解決することができる
ここでのキモとなる技術はShared storage と User asset storage
オペレータは必ずshared storageを持ってないといけないので、safetyが侵される可能性は低い
最終結果だけ帰ってくるのでState diffの考えはLNに似てるかも?
最適化3 Liveness/Safety Separation
かきこむ量を減らす
一般的に共有されているストレージ、つまり上記のスマートコントラクトデータもL1から削除できる
ユーザーは、資産をL1に移動するために必要なものをすでに手にしています。仮にコントラクトのDAが失われたとしても、そのリスクはコントラクトを利用するdappsの状態を更新できなくなる程度にとどまり、ユーザーの資産を安全にL1に移動させることができる
ユーザーの資産を安全にL1へ退避させることができる。
L1が停止するとアセットを移動できなくなり、事実上アセットが失われるため、L1ではLivenessとSafetyは分離できない
しかし、Layer2ではL1のLivenessを利用することで、Safetyを分離して資産のExitを可能にすることができる
これにより、残高などのデータとL1へのExitに必要なトランザクタIDのリスト以外はstate diffから削除され、残った部分はPreconsensus Mechanismによるfinalityの長さの恩恵を受け、強い効率性が得られる。
実際に、停止したDappsがExitしたアセットやL2に残っているアセットで再開することも可能
以上の最適化によりzkRollupでほぼゼロガスが実現できるうえ、ストレージだけでなく、zkpの検証コストさえも、Preconsensus Mechanismによってほぼ削減される。
state diff = transactor ID list + 残高などのデータ?
アドレスリスト=アドレスツリー(SMT実装)で、ここでのアドレスはEOAアドレス
`
`
さらなる最適化
zk-EVM
安さは手に入れたがproof生成速度が改善されれば嬉しいので、最速Plonky2を使ったアプローチを考案中