ゼロ知識ロールアップ

ゼロ知識ロールアップ (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とは独立した別の仮想マシンで行われます。このオフチェーンVMは、ZKロールアップ上のトランザクションの実行環境であり、ZKロールアッププロトコルのセカンダリレイヤー、つまり「レイヤー2」として機能します。イーサリアムメインネットで検証された有効性証明は、オフチェーンVMにおける状態遷移の正しさを保証します。

ZKロールアップは「ハイブリッドスケーリングソリューション」、つまり独立して動作するもののイーサリアムからセキュリティを継承するオフチェーンプロトコルです。具体的には、イーサリアムネットワークがZKロールアップにおける状態更新が有効であることを強制し、ロールアップの状態更新の裏付けとなるデータの可用性を保証します。その結果、ZKロールアップは、自身のセキュリティ特性に責任を持つサイドチェーンや、同じく有効性証明を用いてイーサリアム上のトランザクションを検証するもののトランザクションデータを別の場所に保存するvalidiumsのような、純粋なオフチェーンスケーリングソリューションよりもかなり安全です。

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

データ可用性

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

有効性証明がすでに状態遷移の信憑性を検証しているため、ZKロールアップは多くのトランザクションデータをオンチェーンで公開する必要はありません。それでも、データをオンチェーンで保存することは重要です。なぜなら、それによりL2チェーンの状態をパーミッションレスかつ独立して検証でき、ひいては誰もがトランザクションのバッチを提出できるようになり、悪意のあるオペレーターがチェーンを検閲したり凍結したりするのを防ぐことができるからです。

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

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

イーサリアムは、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-SNARKopens in a new tab (ゼロ知識の簡潔な非対話的知識アーギュメント) またはZK-STARKopens in a new tab (ゼロ知識のスケーラブルな透明知識アーギュメント) の形式をとることができます。

SNARKとSTARKはどちらも、ZKロールアップにおけるオフチェーン計算の完全性を証明するのに役立ちますが、それぞれの証明タイプには独自の特徴があります。

ZK-SNARKs

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

一部のZKロールアップでは、信頼できる個人が参加するマルチパーティ計算セレモニー (MPC)opens in a new tab を使用してZK-SNARK回路の公開パラメータを生成することで、この問題を解決しようとします。 MPCでは、各参加者がCRSを構築する際に一定のランダム性（「毒性廃棄物」と呼ぶ）を提供した上で、そのランダム性をただちに破壊しなければなりません。

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

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

ZK-STARKs

ZK-SNARKと同様に、ZK-STARKは入力を明らかにすることなくオフチェーン計算の有効性を証明します。しかし、スケーラビリティおよび透明性において、ZK-STARKはZK-SNARKよりも優れていると評価されています。

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

ZK-STARKは、有効性証明の証明と検証に必要な時間が、基礎となる計算の複雑さに対して_準線形_に増加するため、より高いスケーラビリティも提供します。 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の互換性

オプティミスティック・ロールアップとは異なり、ZKロールアップはイーサリアム仮想マシン (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-1559opens 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の開発に取り組んでいるプロジェクトとしては、以下が挙げられます：

zkEVMopens in a new tab - zkEVMは、イーサリアム・ファウンデーションから資金提供を受けているプロジェクトで、EVM互換のZKロールアップとイーサリアムブロックの有効性証明を生成するメカニズムを開発しています。
Polygon zkEVMopens in a new tab - は、イーサリアムメインネット上の分散型ZKロールアップであり、ゼロ知識イーサリアム仮想マシン (zkEVM) 上で動作します。ゼロ知識証明による検証を伴うスマートコントラクトを含め、イーサリアムのトランザクションを透過的に実行します。
Scrollopens in a new tab - Scrollは、イーサリアム向けのネイティブzkEVMレイヤー2ソリューションを構築しているテクノロジー主導の企業です。
Taikoopens in a new tab - Taikoは、分散型のイーサリアム等価なZKロールアップ (タイプ1 ZK-EVMopens in a new tab) です。
ZKsyncopens in a new tab - ZKsync Eraは、Matter Labsによって構築されたEVM互換のZKロールアップで、独自のzkEVMを搭載しています。
Starknetopens in a new tab - StarkNetは、StarkWareによって構築されたEVM互換のレイヤー2スケーリングソリューションです。
Morphopens in a new tab - Morphは、レイヤー2の状態の異議申し立て問題に対処するためにゼロ知識証明を利用するハイブリッドロールアップスケーリングソリューションです。
Lineaopens in a new tab - LineaはConsensysによって構築されたイーサリアム等価のzkEVMレイヤー2であり、イーサリアムエコシステムと完全に連携しています。