〜最もスケーラブルなzkRollupアルゴリズム〜 zkRollupは現状発見されているものでは唯一、Ethereumのスケーラビリティを機能の一般性と同期性の両方を保ったまま向上させる手法である。zkpがスケーリング用途に使われた初めての事例であり、2018年にVitalik Buterinにより発明され、2020？年よりLoopringによってその汎用な機能実装が本番環境にて実行された。これをその性質を保ったまま、極限的にスケーリングする手段を提供する。 Overview このzkRollupは通常のzkRollupと異なった次の性質を持つ。 ・実行したアカウントのリストを除くcalldataコストの全般的な削減 これは各ユーザーウォレットへのデータの蓄積や、データの受け取り可能性におけるセキュリティアサンプションの追加といった限定された代償によって得られた大きなスケーラビリティである。この利点と代償の交換を可能にしたのは、ユーザーの資産領域と共有のストレージ領域の分離、そしてトランザクションデータ自体の圧縮である。 Background Rollupとは、Ethereum Layer1の性質やセキュリティを失うことなく引き継ぐことのできるLayer2のスケーラブルなネットワークである。Rollupはその前身であるPlasmaのアイディアの修正である。Plasmaは、あるネットワークにおいて資産等を表すデータベース全体のマークルツリーのルートが公開された形であれば、それに対して資産等のデータをインクルージョンプルーフできることを利用する。それにより、Layer1のスマートコントラクト上の変数にこのマークルツリーのルートをセットして、まとまった多数のトランザクションの結果、つまりは資産状況などを反映し、ルートをアップデートすることで資産の移転を可能にすることを意味する。資産を表すデータとしては、非常に少ないデータであるマークルツリーのルートのみがLayer1に書き込まれるため、効率的である。これがPlasmaの基本的なアイディアである。 しかしながら、この資産証明のマークルプルーフのプロセスにおいては、個人が自身の資産を証明する場合でも、そのネットワーク全員の資産等の全てのデータがなければ証明を作成することが不可能であるため、証明作成者がデータの一部を欠損する時、資産を失う可能性があることが示された。Rollupはこの問題に焦点をあて、全てのtransactionデータをもっとも安価な領域であるcalldataに保存することを暗号学的な手段で強制し、ネットワークのデータベース全体をいつでも誰でもEthereum Layer1のフルノードを同期することで回復・再計算可能な形にした。暗号学的な手段がzkpであるものをzkRollup, 検証をLayer1において遅延させ、Layer1外の計算で間違っていることを発見した時再検証する方式がOptimistic Rollupと呼ぶ。 初期から提案された仕様のzkRollupの実行でEthereumのマイナーに支払われるコストのうち、大きなものは2つである。 トランザクションデータの保存 zkpの検証 多くのトランザクションが利用されればされるほど、(1)のコストは大きくなり、(2)のコストは一定である。大規模なスケーリングを想定する場合(1)のコストの削減は根本的な解決策である。そして固定費である(2)について、チェックポイント方式に合意することで解決できることを本チームによる投稿で議論した。 また、Layer2 Operatorノードの複数間協調により、その独占または寡占によって想定されうる以下の弊害をクリアした。 MEVあるいはフロントランニングによるユーザーからの実質的な中抜き OperatorノードのSPOF化による実質的Livenessへの攻撃ベクター Methodology 1)のトランザクションデータの保存は同じセキュリティを保ちながら次の方法に置換可能である。 トランザクションの結果としてのステート更新をそのままcalldataに書き出す この変更は初期からのzkRollupの仕様であるトランザクションデータのcalldataへの保存の元来の目的が、基本的にLayer2ステートマシンの全ストレージの保存を達成する必要があることに由来する。前述の通り、データ可用性喪失によるネットワーク参加者全員の資産の証明不可能性は、そのまま参加者全員の資産の永久的な凍結を意味していたため、全ストレージの保存は全般的に確保される必要があった。 全ストレージの保存のためには各トランザクションの結果としての各ストレージの変更履歴があれば十分であり、これはトランザクションデータの保存は代替することができる。 この代替により効率化される条件は 1バッチ内のトランザクションデータ合計 > 1バッチで最終的に変更されるstate diffの合計 である。 重要な点として、最終的にこの手法ではこの「1バッチで最終的に変更されるstate diffの合計」の保存義務を全て排除する。 まず、この不等式をより成り立たせるために、1バッチで最終的に変更されるstate diffの合計を減らすことにする。 1バッチには数多くのトランザクションが格納され、これらの途中経過を除いた最終的なステート変更が記録されることから、多くのトランザクションが共有で変更するステート(変数)が多いほど、この合計のデータ量は減ることとなる。 共有で変更するステートと共有しないステートの違いに言及する。 元来パブリックブロックチェーンは、ユーザーの資産を外部から奪われないという財産権を保証するために2009？年に始まったものであり、ユーザー固有のデータは外部から勝手な変更を基本的には許さないものである。一方、Ethereum型スマートコントラクトは不特定多数間で共有・変更するデータを汎用なプログラムで操作することをパブリックブロックチェーンに付与したものである。 つまり、ユーザーの資産という共有しないステートをstate diffから排除することにより、より共有するステートのみをstate diffに残すことができ、１バッチの途中経過で多く変更されるステートを持つトランザクション群の最終的なステート差分だけ記録することができるため効率的である。 ユーザーの資産という共有しないステートをstate diffから排除するには、ユーザーの資産が如何なる場合でもLayer1に安全に退避可能であるという性質を保てればよい。 オペレーターの操作 (1) オペレーターはユーザーのトランザクション後の資産に関するMerkle Proofをレシートとして返す。 ユーザーのExit操作 (1) レシートに署名してオペレーターに返し、Exitまでレシートを保管する (2) この後に資産が移動してはいないことを証明する (3) このレシートを証明する これによりユーザーの資産はいつでも退避可能な形で保たれるため、state diffからは全ユーザーの資産を含むステートは排除された。 では、次に考察すべき点はユーザーの資産が常に安全ならば分割したもう一方のデータである「共有するステート」のデータは何に必要かという点である。 この「共有するステート」はExitには必要ないがトランザクションを打ち、引き続きスマートコントラクトのdappsを利用するのに必要である。これは上述の資産の安全性である”Safety”と対比して”Liveness”と呼ばれる。 つまり、共有するステートをLayer1保存から排除し、Liveness喪失をしないようにオペレーターにより共有するステート保存の最大の努力をし、最悪の事態の場合には利用を止め資産を安全に退避させるというモデルが可能である。 そして前述の2つのコストにある、2) zkpの検証 のコストについても削減することが次の手段で可能である。 [後でかく]