ゼロ知識ロールアップ

ゼロ知識ロールアップ（ZKロールアップ）とは、計算および状態保存をオフチェーンで実行することで、イーサリアムメインネットのスループットを向上するための、レイヤー2のスケーリングソリューションです。 ZKロールアップは、数千件のトランザクションをバッチ処理した上で、最低限のサマリーデータのみをメインネットに書き込みます。このサマリーデータには、イーサリアムの状態に対して変更すべき事項の定義と、それらの変更が正しいことを示す暗号学的証明が含まれます。

前提知識

イーサリアムのスケーリングとレイヤー2のページを読んで理解しておくことをお勧めします。

ゼロ知識ロールアップとは何か？

ゼロ知識ロールアップ（ZKロールアップ）は、複数のトランザクションをひとつのバッチにまとめて（ロールアップする）、このバッチをオフチェーンで実行します。計算をオフチェーンで実行することで、ブロックチェーンに書き込む必要があるデータの量を削減することができます。 ZKロールアップのオペレーターは、個別のトランザクションを送信する代わりに、バッチに含まれるすべてのトランザクションを実行するのに必要な変更のサマリーのみを送信します。同時に、これらの変更の正しさを証明するために、を生成します。

ZKロールアップの状態は、イーサリアムネットワーク上でデプロイされたスマートコントラクトにより管理されます。 ZKロールアップの状態を更新するために、ZKロールアップのノードは検証のための有効性証明を送信する必要があります。前述したように、この有効性証明は、ロールアップにより提案された状態の変更が、バッチに含まれるトランザクションを実行した結果と同一であることを暗号論的に保証します。つまり、ZKロールアップを用いる場合、オプティミスティック・ロールアップの場合のようにすべてのトランザクションデータをイーサリアムに書き込む必要はなく、有効性証明を提要するだけでイーサリアム上のトランザクションをファイナライズすることができます。

ZKロールアップのコントラクトが有効性証明が正しいことを確認した時点で出金トランザクションが実行されるため、ZKロールアップからイーサリアムの資金移動において遅延が発生しません。一方、オプティミスティック・ロールアップからの資金の引き出しの場合、すべてのユーザーがを用いて出金トランザクションに対してチャレンジできるようにするための遅延期間が必要になります。

ZKロールアップでは、トランザクションをcalldataとしてイーサリアムに書き込みます。 calldata とは、スマートコントラクトの関数を外部から呼び出す際に含まれるデータが格納される場所を指します。 calldata に含まれる情報はブロックチェーン上で公開されるため、すべてのユーザーが独自にロールアップの状態を再構築することができます。 ZKロールアップでは、圧縮技術を用いてトランザクションデータのサイズを縮小します。例えば、アカウントはアドレスではなくインデックスで表されるため、28バイト分のデータが節約できます。ロールアップにおいては、オンチェーンへのデータ公開が大きなコストとなるため、データ圧縮はユーザー費用を引き下げる効果を持ちます。

ZKロールアップは、イーサリアムとどのようにやりとりするか？

ZKロールアップのチェーンは、イーサリアムブロックチェーン上で動作するオフチェーンのプロトコルであり、イーサリアムのオンチェーンのスマートコントラクトにより管理されます。 ZKロールアップでは、メインネット外でトランザクションを実行しますが、オフチェーンのトランザクションをまとめたバッチをオンチェーンのロールアップコントラクトに定期的に書き込みます。このトランザクション記録は、イーサリアムブロックチェーンの場合と同様に改変不可であり、ZKロールアップのチェーンを形成します。

ZKロールアップのコアアーキテクチャは、以下のコンポーネントで構成されます：

オンチェーンのコントラクト: 前述した通り、ZKロールアップのプロトコルはイーサリアム上で実行されるスマートコントラクトにより管理されます。これには、ロールアップの各ブロックを保存し、入金状態を追跡し、状態更新を監視するメインのコントラクトが含まれます。オンチェーンにおけるもう一つのコントラクト（検証者コントラクト）は、ブロック生成者が送信したゼロ知識証明を検証します。つまり、イーサリアムはZKロールアップにおけるベースレイヤー（「レイヤー1」）の役割を果たします。
オフチェーンの仮想マシン（VM）: ZKロールアップのプロトコルはイーサリアム上に置かれますが、トランザクションの実行および状態保存は、EVMとは独立した別個の仮想マシン上で行われます。このオフチェーンの仮想マシンは、ZKロールアップ上のトランザクションに対する実行環境であり、ZKロールアップのプロトコルにおける第2層（つまり、「レイヤー2」）の役割を果たします。イーサリアムメインネット上で検証された有効性証明により、オフチェーンのVMにおける状態遷移の正しさが保証されます。

ZKロールアップは、イーサリアムとは別個に実行されるもののセキュリティについてはイーサリアムに依存するオフチェーンのプロトコルであるため、「ハイブリッド型のスケーリング・ソリューション」であると言えます。具体的には、イーサリアムネットワークがZKロールアップにおける状態更新が有効であることを強制し、ロールアップの状態更新の裏付けとなるデータの可用性を保証します。この結果、ZKロールアップは、それ自体がセキュリティ特性の維持に責任を負うサイドチェーンや、バリディアムのように、有効性証明によりイーサリアム上でトランザクションを検証する点は共通しているもののトランザクションデータを別の場所に保存する、純粋にオフチェーンのみを活用したスケーリング・ソリューションと比較すると、大幅に安全性が高いと言えます。

ZKロールアップでは、以下の事項につきメインのイーサリアムプロトコルに依存します：

データ可用性

ZKロールアップでは、オフチェーンで処理されたすべてのトランザクションの状態データをイーサリアムに書き込みます。個人または企業のユーザーは、このデータを用いてロールアップの状態を再現し、チェーン自体を検証することができます。イーサリアムでは、ネットワークのすべての参加者に対し、このデータをcalldataとして提供します。

ZKロールアップでは、状態遷移の正しさがすでに有効性証明により検証済みであるため、オンチェーンに書き込む必要があるトランザクションデータの量は多くありません。それにも関わらず、データをオンチェーンで保存するのが重要である理由は、これによりLCチェーンの状態をパーミッションレスかつ独立して検証できるようになるからであり、これにより、トランザクションをバッチ化して送信するすべてのユーザーは、悪意のオペレーターがチェーンを検閲したり、凍結したりするのを防ぐことができます。

ユーザーは、ロールアップとのやりとりを実行する場合にオンチェーンでなければなりません。状態データへのアクセス権限を持たないユーザーは、各自のアカウント残高を照会したり、状態情報に依存する取引（例：出金）を開始することができません。

トランザクションのファイナリティ

イーサリアムは、ZKロールアップに対する決済レイヤーの役割を果たします。つまり、L2上のトランザクションは、L1のコントラクトが有効性証明を承認してはじめてファイナライズされます。これにより、すべてのトランザクションがメインネット上の承認を必要とするため、悪意のオペレーターがチェーンを毀損する（例：ロールアップ上の資金を窃盗する）リスクが除去されます。イーサリアムはさらに、L1上でファイナライズされた操作は取消不能であることを保証します。

検閲耐性

大部分のZKロールアップでは、トンラザクションの実行、バッチの生成、およびL1へのブロック送信を「スーパーノード」（オペレーターと呼ぶ）が担います。このアプローチは、効率性を向上させる一方で、検閲のリスクを高めるものです。ZKロールアップのオペレーターが悪意を持つ場合、特定のトランザクションをバッチに含めないことで、それらのトランザクションを行いたいユーザーを検閲できるからです。

ZKロールアップでは、セキュリティ対策として、ユーザーがオペレーターの検閲を受けていると考える場合はロールアップ上のコントラクトを直接メインネットに送信することを許可しています。これにより、オペレーターの許可なしで、ZKロールアップからイーサリアムへの出金を強制実行することができます。

ZKロールアップの仕組みとは？

トランザクション

ZKロールアップのユーザーは、トランザクションに署名した上で、トランザクションの処理および次のバッチへの追加のためにL2オペレーターに送信します。場合により、このオペレーターは、トランザクションを実行し、バッチ化した上でL1に送信する中央集権的なエンティティ（シーケンサーと呼ぶ）の場合があります。このシステムにおけるシーケンサーは、L2のブロックを生成し、ロールアップのトランザクションをZKロールアップのコントラクトに追加できる唯一のエンティティです。

このアプローチを採用しないZKロールアップでは、プルーフ・オブ・ステークによる複数のバリデータがオペレーターの役割をローテーションで担います。オペレーターに立候補するユーザーは、ロールアップのコントラクトに資金を入金し（ステーキング）、このステークの規模に応じて、次のロールアップ・バッチを生成する役割を与えられる可能性が増減します。悪意の行動を行ったオペレーターのステークは没収されるため、有効なブロックの送信を促すインセンティブとして機能します。

ZKロールアップにおいてトランザクションデータをイーサリアムに書き込む方法

すでに述べた通り、トランザクションデータはcalldataとしてイーサリアムに書き込まれます。 calldataとは、スマートコントラクトにおいて関数に引数を渡すためのデータ領域であり、メモリと同様に動作します。 calldata はイーサリアムの状態として保存されませんが、イーサリアムチェーンの履歴ログ(opens in a new tab)としてオンチェーン上で永続します。 calldata はイーサリアムの状態を変化させないため、オンチェーン上でのデータ保存が安価に実行できます。

多くの場合、calldataにおけるキーワードがトランザクションで呼び出されるスマートコントラクトのメソッドを決定し、当該メソッドへの入力を任意のバイト列として保持します。 ZKロールアップでは、calldataを用いて圧縮されたトランザクションデータをオンチェーンに書き込みます。ロールアップのオペレーターの役割は、ロールアップのコントラクトにおいて要求される関数を呼び出し、関数の引数として圧縮データを渡すことにより新規バッチを追加することだけです。このため、ロールアップにおける手数料の大半はトランザクションデータのオンチェーンの保存において発生するため、ユーザー手数料が軽減されます。

ステートコミットメント

L2のアカウントおよび残高が含まれるZKロールアップの状態は、マークルツリーとして表示されます。マークルツリーのルート（マークルルート）の暗号ハッシュがオンチェーンのコントラクトに保存されるため、ロールアップのプロトコルによりZKロールアップの状態変化を追跡することができます。

ロールアップは、一連の新たなトランザクションを実行することで、新しい状態に遷移します。この状態遷移を開始したオペレーターは、新しい状態ルートを計算し、オンチェーンのコントラクトに送信しなければなりません。当該バッチの有効性証明が検証者コントラクトにより承認されると、新たなマークルルートがZKロールアップにおける正規の状態ルートになります。

ZKロールアップのオペレーターは、状態ルートを計算するだけでなく、バッチに含まれるすべてのトランザクションで構成されるマークルツリーのルートであるバッチルートも作成します。新規バッチが送信されると、ロールアップのコントラクトがバッチルートを保存するため、ユーザーは当該バッチに特定のトランザクション（例：出金リクエスト）が含まれていたかを証明できます。この場合ユーザーは、トランザクションの詳細、バッチルート、および追加パスを表示するマークル証明を提供しなければなりません。

有効性証明

ZKロールアップのオペレーターがL1のコントラクトに送信する新しい状態ルートは、ロールアップにおける状態更新の結果です。例えば、アリスがボブに10トークンを送信する場合、オペレーターは単にアリスの残高を10減らし、ボブの残高を10増やします。オペレーターはその上で、残高変更後のアカウントデータをハッシュ化し、ロールアップのマークルツリーを再構築した上で、新しいマークルルートをオンチェーンのコントラクトに送信します。

しかし、ロールアップのコントラクトは、オペレーターがこの新しいマークルルートがロールアップの状態に対する正しい更新によって生成されたことを証明するまでは、提案された状態コミットメントを自動的に承認しません。 ZKロールアップのオペレーターは、バッチ化されたトランザクションの正しさを証明する簡潔な暗号学的コミットメントである有効性証明を生成することで、これを証明します。

有効性証明は、ステートメント自体を示さずにその正しさを証明するものであるため、ゼロ知識証明とも呼ばれます。 ZKロールアップでは、有効性証明を用いることで、トランザクションをイーサリアム上で再実行することなく、オフチェーンの状態遷移の正しさを確認することができるのです。この有効性証明には、ZK-SNARK(opens in a new tab)（ゼロ知識の簡潔かつ非双方向の知識アーギュメント）またはZK-STARK(opens in a new tab)（ゼロ知識のスケーラブルかつ透明性を持った知識アーギュメント）の2種類があります。

SNARKおよびSTARKのいずれもZKロールアップにおけるオフチェーンの計算処理の完全性を証明するのに有益ですが、それぞれが独自の機能を持ちます。

ZK-SNARK

ZK-SNARKのプロトコルが機能するには、共通参照文字列（CRS）を生成する必要があります。このCRSは、有効性証明を証明、検証するための公開パラメータを提供します。証明システムのセキュリティは、このCRSの設定に依存しています。つまり、公開パラメータが悪意のアクターに所有された場合、虚偽の有効性証明が生成可能になります。

一部のZKロールアップでは、ZK-SNARKの証明サーキットに対する公開パラメータの生成を信頼された個人ユーザーが参加する複数当事者による計算セレモニー（MPC）(opens in a new tab)で実行することで、この問題を解消しようとします。 MPCでは、各参加者がCRSを構築する際に一定のランダム性（「毒性廃棄物」と呼ぶ）を提供した上で、そのランダム性をただちに破壊しなければなりません。

このような信頼されたユーザーによる関与は、CRS設定のセキュリティを高めるためのものです。参加者のうち少なくとも1名が正直にインプットを破壊すれば、ZK-SNARKのシステムにおけるセキュリティが保証できます。しかしこのアプローチでも、システムのセキュリティ保証を毀損しないためには、「参加者は提供したランダム性を消去するはずだ」という信頼が必要になる点は変わりがありません。

ZK-SNARKは、このような信頼の前提という問題を抱えているものの、証明の規模が小さく、一定時間による検証が可能なために広く用いられています。 ZKロールアップの運用コストの大部分はL1における有効性証明の検証において発生するため、L2では、ZK-SNARKを用いることで、メインネット上で迅速かつ安価に検証可能な有効性証明を生成できるのです。

ZK-STARK

ZK-STARKは、オフチェーンにおける計算につき、そのインプットを示すことなく正しさを証明できるという点ではZK-SNARKと同じです。しかし、スケーラビリティおよび透明性において、ZK-STARKはZK-SNARKよりも優れていると評価されています。

ZK-STARKでは、共通参照文字列（CRS）の信頼できる設定を必要としないため、「透明性」を持ちます。 ZK-STARKでは、有効性証明の生成および検証につき、CRSの代わりに公開的に検証可能なランダム性を用いてパラメータを設定します。

ZK-STARKではさらに、有効性証明を証明、検証するのに必要な時間が、証明を要する計算処理の複雑さに応じてほぼ線形的に増化するため、ZK-SNARKよりもスケーラビリティが高いと言えます。つまりZK-SNARKでは、証明を要する計算処理の規模に応じて、証明および検証に必要な時間が線形的に変化します。このためZK-STARKでは、大規模なデータセットの証明、検証をZK-SNARKよりも短時間で完了できるため、大規模なアプリケーションにとってより有益なのです。

ZK-STARKはさらに量子コンピュータに対してもセキュリティを防御できます。一方、ZK-SNARKで用いられている楕円曲線暗号（ECC）は、量子コンピュータによる攻撃に対して脆弱性を持つという意見が支配的です。 ZK-STARKの欠点としては、生成される有効性証明のサイズが大きくなるため、イーサリアム上での検証コストが高くなります。

ZKロールアップにおいて、有効性証明はどのように機能するか？

有効性証明の生成

オペレーターは、トランザクションを受け入れる前に通常と同じチェック作業を行います。具体的には、以下を確認します：

送信者と受信者のアカウントがステートツリーに含まれていること。
送信者が、トランザクションの処理に必要とされる十分な資金を持つこと。
トランザクションが正しく、ロールアップにおける送信者の公開鍵と一致すること。
送信者のノンスが正しいこと、など。

ZKロールアップのノードは、トランザクションが一定数に達すると、これらをバッチ化した上で、証明サーキット向けのインプットをコンパイルして簡潔なゼロ知識証明としてコンパイルします。このゼロ知識証明には、以下が含まれます：

バッチに含まれるすべてのトランザクションで構成されるマークルツリールート。
各トランザクションが当該バッチに含まれることを証明するマークル証明。
トランザクションにおける送信者／受信者ペアのアカウントが、ロールアップのステートツリーに含まれることを証明するマークル証明。
各トランザクションに対する状態更新を適用した後の状態ルートの更新により得られる、プロセスの中間における状態ルートのセット（つまり、送信者アカウントの残高減と受信者アカウントの残高増）。

証明サーキットでは、各トランザクションを「ループ」させ、オペレーターがトランザクションを処理する事前に実行したのと同一のチェックを行うことにより、有効性証明を計算します。証明サーキットではまず、提供されたマークル証明を用いて、送信者アカウントが既存のステートルートに含まれることを確認します。次に、送信者の残高をマイナスし、ノンスを増やし、変更後のアカウントデータのハッシュをマークル証明と結合させて、新しいマークルルートを生成します。

このマークルルートは、送信者の残高およびノンスにおける変更というZKロールアップの状態に対する唯一の変更を反映しています。これが可能なのは、アカウントの存在を証明するためのマークル証明が新しいステートルートを導出するために用いられているためです。

証明サーキットは、これと同じプロセスを受信者アカウントに対しても実行します。つまり、（マークル証明を用いて）プロセス中間のステートルートにおいて受信者アカウントが存在することを確認し、残高を増やした上で、アカウントデータを再度ハッシュ化し、マークル証明と結合することで、新しいステートルートを生成します。

このプロセスを、各トランザクションに対して繰り返します。それぞれの「ループ」処理では、受信者アカウントの変更により新しいステートルートが生成され、受信者アカウントの変更によりさらに次の新しいステートルートが生成されます。前述したように、このステートルートに対するそれぞれの更新は、ロールアップのステートツリーにおける1回の変化を反映したものです。

ゼロ知識証明サーキットでは、トランザクションバッチの全体を反復的に処理することで、バッチにおける最後のトランザクションが実行された際の最終的なステートルートに至るまでの状態更新のシーケンスの正しさを検証します。この計算プロセスで得られた最後のマークルルートが、ZKロールアップにおける最新の正規ステートルートになります。

有効性証明の検証

証明サーキットにおいて状態更新の正しさが検証されると、L2のオペレーターは、計算された有効性証明をL1上の検証者コントラクトに送信します。検証者コントラクトの検証サーキットでは、この有効性証明の正しさを検証すると同時に、有効性証明の一部である公開インプットについても確認します。

事前のステートルート: ZKロールアップの古い状態（つまり、当該バッチに含まれるトランザクションの実行前）を反映した、L2チェーンにおいて有効である最後の既知のステートルートです。
事後のステートルート: ZKロールアップの新しい状態（つまり、当該バッチに含まれるトランザクションの実行後）を反映し、L2チェーンの最新状態であるルートです。事後のステートルートは、証明サーキットに状態更新を適用することで得られた最終的なルートです。
バッチルート: 当該バッチのマークルルートであり、バッチにマークル化を施し、マークルツリーのルートをハッシュ化することで得られます。
トランザクションにおけるインプット: 提出されたバッチにおいて実行されたトランザクションに含まれるデータ。

この有効性証明が証明サーキットに合格した場合（つまり、有効性証明が有効である場合）、ロールアップを古い状態（事前のステートルートにより暗号学的にフィンガープリントされる）から新しい状態（事後のステートルートにより暗号学的にフィンガープリントされる）に移行させる、有効なトランザクションのシーケンスが存在することになります。事前のステートルートがロールアップのコントラクトに保存されたルートと一致し、有効性証明が有効であれば、ロールアップのコントラクトは有効性証明から事後のステートルートを取り出し、ロールアップの変更後の状態を反映するようにステートツリーを更新します。

参加と退出

ユーザーがZKロールアップに参加するには、L1チェーン上でデプロイされたロールアップのコントラクトにトークンを入金する必要があります。ロールアップのコントラクトにトランザクションを送信できるのはオペレーターのみであるため、このトランザクションはキュー上で保留されます。

キューに含まれる保留中の入金件数が一定数に達すると、ZKロールアップのオペレーターが入金トランザクションをロールアップのコントラクトに送信します。ユーザーの資金がロールアップに入金された時点で、ユーザーはトランザクションをオペレーターに送信し、処理させることで、取引を開始できます。ユーザーは、各自のアカウントデータをハッシュ化し、ハッシュをロールアップのコントラクトに送信し、さらに現在のステートルートを検証するためのマークル証明を提供することで、ロールアップにおける自らの残高を確認できます。

ZKロールアップからL1への出金は、簡単に実行できます。出金トランザクションでは、まずロールアップ上の各自の資金をバーン用の特定のアカウントに送信します。オペレーターがこのトランザクションを次のバッチに追加した時点で、ユーザーは出金リクエストをオンチェーンのコントラクトに送信できます。この出金リストには、以下を含める必要があります：

ユーザーのバーンアカウントへの送金トランザクションが当該バッチに含まれることを証明するマークル証明。
トランザクションデータ。
バッチルート。
入金資金を受け取るL1上のアドレス。

ロールアップのコントラクトは、このトランザクションデータをハッシュ化し、バッチルートが存在することを確認した上で、マークル証明を用いてこのトランザクションハッシュがバッチルートに含まれることを確認します。その上で、コントラクトは出金トランザクションを実行し、ユーザーが選択したL1上のアドレスに資金を送金します。

ZKロールアップとEVMの互換性

オプティミスティック・ロールアップと異なり、ゼロ知識ロールアップはそれ自体がイーサリアム仮想マシン (EVM) と互換であるわけではありません。ゼロ知識の証明サーキットにおいて汎用的なEVMの計算を証明するのは、（上記のトークン転送例のような）単純な計算を証明する場合よりも困難であり、多くのリソースが必要になります。

しかし、ゼロ知識技術の進歩(opens in a new tab) により、EVMの計算にゼロ知識証明を用いるアプローチに対する関心が再び高まっています。これらの取り組みは、ゼロ知識EVM（zkEVM）の実装を実現することで、プログラム実行の正しさをより効率的に検証できるようにするものです。 ZkEVMは、証明サーキットにおける証明／検証のためにEVMの既存オペコードを再作成するもので、これによりスマートコントラクトの実行が可能になります。

zkEVMでは、EVMと同様に、インプットに対する計算を実行した時点で状態が遷移します。しかしzkEVMでは、プログラム実行の各ステップの正しさを検証するためにゼロ知識証明が生成されるという点が異なります。有効性証明は、仮想マシンの状態（メモリ、スタック、およびストレージ）に関連した操作ならびに計算自体の正しさを検証することができます（つまり、この操作は適切なオペコードを呼び出し、適切に実行されたかを確認できます）。

EVM互換のZKロールアップを活用することで、デベロッパはゼロ知識証明がもたらすスケーラビリティとセキュリティ保証を得ることができます。さらに重要なのは、イーサリアムネイティブのインフラとの互換性が保証されるために、使い慣れた（すでに実戦で検証済みの）ツールや言語を用いて、ZKフレンドリーなDappを構築できるという点です。

ZKロールアップにおける手数料の仕組み

ZKロールアップにおけるトランザクション手数料は、イーサリアムメインネットと同じようにガス料金に応じて変化します。ただしL2においては、ガス料金の仕組みが異なっており、以下のコストの影響を受けます：

ステートへの書き込み: イーサリアムのステートに書き込む（つまり、イーサリアムブロックチェーンにトランザクションを送信する）場合、固定コストが発生します。 ZKロールアップでは、トランザクションをバッチ化し、固定コストを複数のユーザーに分散させることで、ユーザーあたりのコストを引き下げています。
データの公開: ZKロールアップでは、各トランザクションの状態データをcalldataとしてイーサリアムに送信します。現在、calldataのコストは EIP-1559(opens in a new tab) によって管理されています。 calldata の非ゼロバイトに対しては16ガス、ゼロバイトに対しては4ガスのコストが、それぞれ規定されています。各トランザクションに対して支払われるコストは、オンチェーンで公開されるcalldataの規模に応じて決定されます。
L2オペレーター手数料：これは、トランザクション処理にかかる計算コストに対する補償としてロールアップオペレーターに支払われる金額で、イーサリアムメインネットにおけるトランザクションの「優先手数料 (チップ) 」に似ています。
有効性証明の生成と検証: ZKロールアップのオペレーターは、多くのリソースを用いてトランザクションバッチに対する有効性証明を生成しなければなりません。メインネットにおけるゼロ知識証明の検証にもガス代が発生します（最大50万ガス）。

ZKロールアップでは、トランザクションのバッチ化に加えて、トランザクションデータを圧縮することでユーザー手数料を引き下げています。イーサリアムのZKロールアップにおける利用コストは、リアルタイムで確認できます(opens in a new tab)。

ZKロールアップは、どのようにイーサリアムのスケーラビリティを向上させるか？

トランザクションデータの圧縮

ZKロールアップでは、オフチェーンでの計算を通じてイーサリアム・ベースレイヤーのスループットを向上させますが、実際にスケーラビリティを向上させるのはトランザクションデータを圧縮することによってです。イーサリアムのブロックサイズは、各ブロックが保持できるデータ量を制限しているため、必然的に各ブロックが処理できるトランザクションの数も制限されます。 ZKロールアップでは、トランザクション関連データを圧縮することで、各ブロックで処理されるトランザクションの数が大きく増えるのです。

ZKロールアップでは、各トランザクションを検証するためにすべての関連データを書き込む必要がないため、オプティミスティック・ロールアップよりもデータの圧縮度が高いと言えます。ロールアップにおけるアカウントおよび残高の最新状態を再構築する上で、必要最小限のデータのみを送信すればよいのです。

再帰的プルーフ

ゼロ知識証明の優位性のひとつとして、他の種類の証明を検証するためにも使用できる点が挙げられます。例えば、あるZK-SNARKを用いて他の複数のZK-SNARKを検証することができます。このような「プルーフに対するプルーフ」を再帰的プルーフと呼び、ZKロールアップのスループットを劇的に向上させます。

現在のところ、有効性証明はブロックごとに生成され、検証のためにL1上のコントラクトに送信されています。しかしこの1つのブロックのみを検証する有効性証明のアプローチでは、オペレーターが有効性証明を送信する際に1つのブロックしかファイナライズできないため、ZKロールアップにより達成可能なスループットが制限されてしまいます。

一方、再帰的プルーフを用いれば、1つの有効性証明に基づいて複数のブロックをファイナライズすることが可能になります。このアプローチでは、証明サーキットにおいて複数のブロックに対する証明が集約され、最終的な証明を作成することができるためです。 L2のオペレーターがこの再規制プルーフを提出し、コントラクトが承認すれば、関連するすべてのブロックが瞬時にファイナライズされます。再帰的プルーフを用いることで、イーサリアムにおいて一定間隔でファイナライズできるZKロールアップのトランザクション数を増やすことができます。

ZKロールアップの長所と短所

長所	短所
有効性証明により、オフチェーンのトランザクションの正しさが保証でき、オペレーターが無効な状態遷移を実行するのを防ぐことができる。	有効性証明を計算、検証する際にかなりのコストが発生し、ロールアップにおけるユーザー手数料がかさむ可能性がある。
有効性証明がL1上で検証されれば状態更新が承認されるため、トランザクションのファイナリティをより迅速に実現できる。	ゼロ知識は複雑な関連技術を要するため、EVM互換のZKロールアップ構築は容易ではない。
オプティミスティック・ロールアップとは異なり、インセンティブに基づく正直なアクターに依存するのではなく、トラストレス性を持つ暗号学的なメカニズムを通じてセキュリティを確保できる。	有効性証明の生成には特殊なハードウェアを必要とするため、少数のユーザーがチェーンを中央集権的に管理する傾向が強まる可能性がある。
L1上でオフチェーンの状態を復元するために必要なデータを保存できるため、セキュリティ、検閲耐性、および分散化が保証される。	中央集権的なオペレーター（シーケンサー）がトランザクションの実行順位に影響を及ぼしうる。
ユーザーはL2からの出金を遅延なく行えるため、資本の効率性が高まる。	厳格なハードウェア要件によりチェーンを強制的に進められる参加者数が限定されることで、悪意のオペレーターがロールアップの状態を凍結し、ユーザーを検閲するリスクが高まる。
生存性の前提に依存しないため、ユーザーは資金を保護するためにチェーンを検証する必要がない。	一部の証明システム（ZK-SNARKなど）は信頼性に基づく設定が必要であるため、不適切な利用によりZKロールアップのセキュリティモデルが悪用される可能性がある。
優れたデータ圧縮機能により、イーサリアム上で`calldata`を公開する費用が軽減され、ユーザーのロールアップ手数料を最小限に抑えられる。

ZKロールアップに関する動画による説明

FinematicsによるZKロールアップの説明動画をご覧ください：

zkEVMの開発プロジェクト

現在、zkEVMの開発に取り組んでいるプロジェクトとしては、以下が挙げられます：

zkEVM(opens in a new tab) - zkEVMは、イーサリアム・ファウンデーションによる資金提供に基づき、EVM互換のZKロールアップならびにイーサリアムブロックに対する有効性証明を生成するメカニズムを開発するプロジェクトです。
Polygon zkEVM(opens in a new tab) - イーサリアムメインネット上の分散型ゼロ知識ロールアップであり、ゼロ知識証明による検証が可能なスマートコントラクトなど、イーサリアムのトランザクションを透明性が高い方法で実行するゼロ知識イーサリアム仮想マシン(zkEVM)の開発に取り組んでいます。
Scroll(opens in a new tab) - Scrollは、ネイティブのzkEVMを搭載したイーサリアムのレイヤー2ソリューションを開発中のテクノロジー企業です。
Taiko(opens in a new tab) - Taiko は分散型のイーサリアム等価のゼロ知識ロールアップです (タイプ1のZK-EVM(opens in a new tab))。
ZKsync(opens in a new tab) - ZKsync Eraは、Matter Labsによって構築されたEVM互換のZKロールアップであり、自社開発のzkEVMを基盤としています。
Starknet(opens in a new tab) - StarkNetは、StarkWareによって開発されたEVM互換のレイヤー2スケーリングソリューションです。
Morph(opens in a new tab) - Morphは、ハイブリッドのロールアップ・スケーリング・ソリューションで、レイヤー2の状態における異議申し立て問題の対処にゼロ知識証明を利用します。