メインコンテンツへスキップ
Change page

ゼロ知識ロールアップ

ゼロ知識ロールアップ（ZKロールアップ）は、計算と状態の保存をオフチェーンに移行することで、イーサリアム・メインネットの処理能力（スループット）を向上させるレイヤー2 (L2)のスケーリングソリューションです。 ZKロールアップは、数千のトランザクションをバッチ処理し、最小限の要約データのみをメインネットに送信します。 この要約データは、イーサリアムの状態に加えるべき変更と、それらの変更が正しいことを示す暗号証明を定義します。

前提条件

イーサリアムのスケーリングとレイヤー2 (L2)に関するページを読んで理解しておく必要があります。

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

ゼロ知識ロールアップ（ZKロールアップ）は、トランザクションをバッチに束ねて（または「ロールアップ」して）、オフチェーンで実行します。 オフチェーンでの計算により、ブロックチェーンに送信しなければならないデータ量が削減されます。 ZKロールアップのオペレーターは、各トランザクションを個別に送信するのではなく、バッチ内のすべてのトランザクションを表すために必要な変更の要約を送信します。 また、変更の正確性を証明するためにを生成します。

ZKロールアップの状態は、イーサリアム・ネットワーク上にデプロイされたスマート・コントラクトによって維持されます。 この状態を更新するには、ZKロールアップのノードが検証のために有効性証明を送信する必要があります。 前述の通り、有効性証明は、ロールアップによって提案された状態の変更が、実際に指定されたトランザクションのバッチを実行した結果であることを暗号的に保証するものです。 つまり、ZKロールアップは、オプティミスティック・ロールアップのようにすべてのトランザクションデータをオンチェーンに送信するのではなく、イーサリアム上でトランザクションをファイナライズするために有効性証明を提供するだけで済みます。

ZKロールアップのコントラクトが有効性証明を検証するとエグジット・トランザクションが実行されるため、ZKロールアップからイーサリアムへ資金を移動する際の遅延はありません。 逆に、オプティミスティック・ロールアップからの資金の引き出しには、誰でもを用いてエグジット・トランザクションに異議を唱えることができるようにするための遅延が伴います。

ZKロールアップは、トランザクションをcalldataとしてイーサリアムに書き込みます。 calldataは、スマート・コントラクト関数への外部呼び出しに含まれるデータが保存される場所です。 calldata内の情報はブロックチェーン上で公開されるため、誰でも独立してロールアップの状態を再構築できます。 ZKロールアップは圧縮技術を使用してトランザクションデータを削減します。例えば、アカウントはアドレスではなくインデックスで表され、これにより28バイトのデータが節約されます。 オンチェーンでのデータ公開はロールアップにとって大きなコストとなるため、データ圧縮によってユーザーのガス代を削減できます。

ZKロールアップはイーサリアムとどのように相互作用するのか？

ZKロールアップ・チェーンは、イーサリアム・ブロックチェーン上で動作し、オンチェーンのイーサリアムのスマート・コントラクトによって管理されるオフチェーンのプロトコルです。 ZKロールアップはメインネットの外部でトランザクションを実行しますが、定期的にオフチェーンのトランザクションバッチをオンチェーンのロールアップ・コントラクトにコミットします。 このトランザクション記録は、イーサリアム・ブロックチェーンと同様にイミュータブルであり、ZKロールアップ・チェーンを形成します。

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

  1. オンチェーン・コントラクト: 前述の通り、ZKロールアップ・プロトコルはイーサリアム上で実行されるスマート・コントラクトによって制御されます。これには、ロールアップのブロックを保存し、入金を追跡し、状態の更新を監視するメイン・コントラクトが含まれます。別のオンチェーン・コントラクト（検証者コントラクト）は、ブロック生成者によって送信されたゼロ知識証明を検証します。したがって、イーサリアムはZKロールアップのベースレイヤー、つまり「レイヤー1 (L1)」として機能します。

  2. オフチェーン仮想マシン (VM): ZKロールアップ・プロトコルはイーサリアム上に存在しますが、トランザクションの実行と状態の保存は、EVMから独立した別の仮想マシンで行われます。このオフチェーンVMは、ZKロールアップ上のトランザクションの実行環境であり、ZKロールアップ・プロトコルのセカンダリレイヤー、つまり「レイヤー2 (L2)」として機能します。イーサリアム・メインネットで検証された有効性証明は、オフチェーンVMにおける状態遷移の正確性を保証します。

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

ZKロールアップは、以下の点においてメインのイーサリアム・プロトコルに依存しています。

データの可用性

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

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

ユーザーがロールアップとやり取りするには、オンチェーンのデータが必要です。 状態データにアクセスできなければ、ユーザーはアカウントの残高を照会したり、状態情報に依存するトランザクション（例：引き出し）を開始したりすることができません。

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

イーサリアムはZKロールアップのセトルメント・レイヤーとして機能します。L2トランザクションは、L1コントラクトが有効性証明を受け入れた場合にのみファイナライズされます。 すべてのトランザクションはメインネットで承認されなければならないため、これにより悪意のあるオペレーターがチェーンを破損させる（例：ロールアップの資金を盗む）リスクが排除されます。 また、イーサリアムは、L1でファイナライズされたユーザーの操作が取り消されないことを保証します。

検閲耐性

ほとんどのZKロールアップは、「スーパーノード」（オペレーター）を使用してトランザクションを実行し、バッチを生成し、ブロックをL1に送信します。 これにより効率性は確保されますが、検閲のリスクが高まります。悪意のあるZKロールアップのオペレーターは、ユーザーのトランザクションをバッチに含めることを拒否することで、ユーザーを検閲する可能性があります。

セキュリティ対策として、ZKロールアップでは、ユーザーがオペレーターによって検閲されていると判断した場合、メインネット上のロールアップ・コントラクトに直接トランザクションを送信できるようになっています。 これにより、ユーザーはオペレーターの許可に依存することなく、ZKロールアップからイーサリアムへのエグジットを強制することができます。

ZKロールアップはどのように機能するのか？

トランザクション

ZKロールアップのユーザーはトランザクションに署名し、処理と次のバッチへの組み込みのためにL2オペレーターに送信します。 場合によっては、オペレーターはシーケンサーと呼ばれる中央集権的なエンティティであり、トランザクションを実行し、それらをバッチに集約してL1に送信します。 このシステムにおけるシーケンサーは、L2ブロックを生成し、ZKロールアップ・コントラクトにロールアップ・トランザクションを追加することが許可された唯一のエンティティです。

他のZKロールアップでは、プルーフ・オブ・ステーク (PoS)のバリデータセットを使用してオペレーターの役割をローテーションする場合があります。 オペレーター候補はロールアップ・コントラクトに資金を入金し、各ステークのサイズが、ステーカーが次のロールアップバッチを生成するために選ばれる確率に影響を与えます。 オペレーターが悪意のある行動をとった場合、そのステークはスラッシングされる可能性があり、これが有効なブロックを送信するインセンティブとなります。

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)（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）またはZK-STARK (opens in a new tab)（Zero-Knowledge Scalable Transparent Argument of Knowledge）の形式をとることができます。

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

ZK-SNARKs

ZK-SNARKプロトコルが機能するためには、共通参照文字列（CRS）の作成が必要です。CRSは、有効性証明の証明と検証のための公開パラメータを提供します。 証明システムのセキュリティはCRSのセットアップに依存します。公開パラメータの作成に使用された情報が悪意のあるアクターの手に渡った場合、彼らは偽の有効性証明を生成できる可能性があります。

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

トラステッド・セットアップは、CRSセットアップのセキュリティを高めるために使用されます。 少なくとも1人の誠実な参加者が自分の入力を破棄する限り、ZK-SNARKシステムのセキュリティは保証されます。 それでも、このアプローチでは、関係者がサンプリングしたランダム性を削除し、システムのセキュリティ保証を損なわないことを信頼する必要があります。

トラスト前提はさておき、ZK-SNARKは証明サイズが小さく、検証時間が一定であるため人気があります。 L1での証明の検証はZKロールアップの運用において大きなコストを占めるため、L2はZK-SNARKを使用して、メインネット上で迅速かつ安価に検証できる証明を生成します。

ZK-STARKs

ZK-SNARKと同様に、ZK-STARKは入力を明らかにすることなくオフチェーン計算の有効性を証明します。 しかし、ZK-STARKはスケーラビリティと透明性の点でZK-SNARKの改良版と考えられています。

ZK-STARKは、共通参照文字列（CRS）のトラステッド・セットアップなしで機能するため、「透明」です。 代わりに、ZK-STARKは公開検証可能なランダム性に依存して、証明の生成と検証のためのパラメータを設定します。

また、ZK-STARKは、有効性証明の証明と検証に必要な時間が、基礎となる計算の複雑さに比例して_準線形_に増加するため、より高いスケーラビリティを提供します。 ZK-SNARKの場合、証明と検証の時間は、基礎となる計算のサイズに比例して_線形_にスケールします。 これは、大規模なデータセットが関与する場合、ZK-STARKはZK-SNARKよりも証明と検証に必要な時間が短くなることを意味し、大量のトランザクションを処理するアプリケーションに役立ちます。

また、ZK-STARKは量子コンピュータに対しても安全ですが、ZK-SNARKで使用される楕円曲線暗号（ECC）は量子コンピューティング攻撃に弱いと広く信じられています。 ZK-STARKの欠点は、証明サイズが大きくなり、イーサリアムでの検証コストが高くなることです。

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

証明の生成

トランザクションを受け入れる前に、オペレーターは通常のチェックを実行します。これには以下の確認が含まれます。

  • 送信者と受信者のアカウントが状態ツリーの一部であること。
  • 送信者がトランザクションを処理するのに十分な資金を持っていること。
  • トランザクションが正しく、ロールアップ上の送信者の公開鍵と一致していること。
  • 送信者のナンスが正しいこと、など。

ZKロールアップのノードは十分なトランザクションを集めると、それらをバッチに集約し、証明回路が簡潔なZK証明にコンパイルするための入力をまとめます。これには以下が含まれます。

  • バッチ内のすべてのトランザクションで構成されるマークル・ツリーのルート。
  • トランザクションがバッチに含まれていることを証明するためのマークル証明。
  • トランザクション内の各送信者・受信者ペアのアカウントがロールアップの状態ツリーの一部であることを証明するためのマークル証明。
  • 各トランザクションの状態更新（つまり、送信者アカウントの減少と受信者アカウントの増加）を適用した後に状態ルートを更新することで導出される、一連の中間状態ルート。

証明回路は、各トランザクションを「ループ」し、オペレーターがトランザクションを処理する前に完了したのと同じチェックを実行することで、有効性証明を計算します。 まず、提供されたマークル証明を使用して、送信者のアカウントが既存の状態ルートの一部であることを検証します。 次に、送信者の残高を減らし、ナンスを増やし、更新されたアカウントデータをハッシュ化し、それをマークル証明と組み合わせて新しいマークル・ルートを生成します。

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

証明回路は、受信者のアカウントに対しても同じプロセスを実行します。 （マークル証明を使用して）中間状態ルートの下に受信者のアカウントが存在するかどうかを確認し、残高を増やし、アカウントデータを再ハッシュ化し、それをマークル証明と組み合わせて新しい状態ルートを生成します。

このプロセスはすべてのトランザクションに対して繰り返されます。各「ループ」は、送信者のアカウントを更新することで新しい状態ルートを作成し、続いて受信者のアカウントを更新することで新しいルートを作成します。 説明したように、状態ルートのすべての更新は、ロールアップの状態ツリーの一部が変更されたことを表しています。

ZK証明回路はトランザクションバッチ全体を反復処理し、最後のトランザクションが実行された後に最終的な状態ルートをもたらす一連の更新を検証します。 計算された最後のマークル・ルートが、ZKロールアップの最新の正規の状態ルートになります。

証明の検証

証明回路が状態更新の正確性を検証した後、L2オペレーターは計算された有効性証明をL1の検証者コントラクトに送信します。 コントラクトの検証回路は証明の有効性を検証し、証明の一部を形成する公開入力もチェックします。

  • 事前状態ルート: ZKロールアップの古い状態ルート（つまり、バッチ処理されたトランザクションが実行される前）。L2チェーンの最後に確認された有効な状態を反映しています。

  • 事後状態ルート: ZKロールアップの新しい状態ルート（つまり、バッチ処理されたトランザクションの実行後）。L2チェーンの最新の状態を反映しています。事後状態ルートは、証明回路で状態更新を適用した後に導出される最終的なルートです。

  • バッチルート: バッチ内のトランザクションを_マークル化_し、ツリーのルートをハッシュ化することによって導出される、バッチのマークル・ルート。

  • トランザクション入力: 送信されたバッチの一部として実行されたトランザクションに関連するデータ。

証明が回路を満たす（つまり、有効である）場合、それは、ロールアップを前の状態（事前状態ルートによって暗号的にフィンガープリントされている）から新しい状態（事後状態ルートによって暗号的にフィンガープリントされている）に遷移させる一連の有効なトランザクションが存在することを意味します。 事前状態ルートがロールアップ・コントラクトに保存されているルートと一致し、証明が有効である場合、ロールアップ・コントラクトは証明から事後状態ルートを取得し、ロールアップの変更された状態を反映するように状態ツリーを更新します。

エントリーとエグジット

ユーザーは、L1チェーンにデプロイされたロールアップのコントラクトにトークンを入金することで、ZKロールアップにエントリーします。 オペレーターのみがロールアップ・コントラクトにトランザクションを送信できるため、このトランザクションはキューに入れられます。

保留中の入金キューがいっぱいになり始めると、ZKロールアップのオペレーターは入金トランザクションを取得し、ロールアップ・コントラクトに送信します。 ユーザーの資金がロールアップに入ると、処理のためにオペレーターにトランザクションを送信することで、取引を開始できます。 ユーザーは、アカウントデータをハッシュ化し、そのハッシュをロールアップ・コントラクトに送信し、現在の状態ルートと照合するためのマークル証明を提供することで、ロールアップ上の残高を検証できます。

ZKロールアップからL1への引き出しは簡単です。 ユーザーは、ロールアップ上の資産をバーン用の指定されたアカウントに送信することで、エグジット・トランザクションを開始します。 オペレーターがそのトランザクションを次のバッチに含めた場合、ユーザーはオンチェーン・コントラクトに引き出しリクエストを送信できます。 この引き出しリクエストには以下が含まれます。

  • ユーザーのバーンアカウントへのトランザクションがトランザクションバッチに含まれていることを証明するマークル証明

  • トランザクションデータ

  • バッチルート

  • 入金された資金を受け取るためのL1アドレス

ロールアップ・コントラクトはトランザクションデータをハッシュ化し、バッチルートが存在するかどうかを確認し、マークル証明を使用してトランザクション・ハッシュがバッチルートの一部であるかどうかを確認します。 その後、コントラクトはエグジット・トランザクションを実行し、L1上のユーザーが選択したアドレスに資金を送信します。

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

オプティミスティック・ロールアップとは異なり、ZKロールアップはイーサリアム仮想マシン (EVM)と容易には互換性がありません。 回路内で汎用的なEVM計算を証明することは、（前述のトークン送金のような）単純な計算を証明するよりも困難であり、リソースを大量に消費します。

しかし、ゼロ知識技術の進歩 (opens in a new tab)により、EVM計算をゼロ知識証明でラップすることへの関心が再び高まっています。 これらの取り組みは、プログラム実行の正確性を効率的に検証できるゼロ知識EVM（zkEVM）実装の作成に向けられています。 zkEVMは、回路内での証明/検証のために既存のEVMオペコードを再構築し、スマート・コントラクトの実行を可能にします。

EVMと同様に、zkEVMはいくつかの入力に対して計算が実行された後に状態間を遷移します。 違いは、zkEVMがプログラム実行のすべてのステップの正確性を検証するためのゼロ知識証明も作成することです。 有効性証明は、VMの状態（メモリ、スタック、ストレージ）に触れる操作の正確性と、計算自体（つまり、操作が正しいオペコードを呼び出し、それらを正しく実行したか？）を検証できます。

EVM互換のZKロールアップの導入により、開発者はゼロ知識証明のスケーラビリティとセキュリティ保証を活用できるようになると期待されています。 さらに重要なことに、ネイティブのイーサリアム・インフラストラクチャとの互換性により、開発者は使い慣れた（そして実戦テスト済みの）ツールや言語を使用して、ZKフレンドリーな分散型アプリケーション (dapp)を構築できるようになります。

ZKロールアップの手数料はどのように機能するのか？

ZKロールアップでのトランザクションに対してユーザーが支払う金額は、イーサリアム・メインネットと同様にガス代に依存します。 ただし、ガス代はL2では異なる働きをし、以下のコストの影響を受けます。

  1. 状態の書き込み: イーサリアムの状態への書き込み（つまり、イーサリアム・ブロックチェーンへのトランザクションの送信）には固定コストがかかります。ZKロールアップは、トランザクションをバッチ処理し、固定コストを複数のユーザーに分散させることで、このコストを削減します。

  2. データの公開: ZKロールアップは、すべてのトランザクションの状態データをcalldataとしてイーサリアムに公開します。calldataのコストは現在EIP-1559 (opens in a new tab)によって管理されており、calldataの非ゼロバイトには16ガス、ゼロバイトには4ガスのコストがそれぞれ規定されています。各トランザクションで支払われるコストは、そのためにどれだけのcalldataをオンチェーンに送信する必要があるかに影響されます。

  3. L2オペレーター手数料: これは、イーサリアム・メインネットのトランザクションの「優先手数料（チップ）」と同様に、トランザクションの処理で発生した計算コストの補償としてロールアップのオペレーターに支払われる金額です。

  4. 証明の生成と検証: ZKロールアップのオペレーターはトランザクションバッチの有効性証明を生成する必要がありますが、これにはリソースを大量に消費します。メインネットでのゼロ知識証明の検証にもガスがかかります（約500,000ガス）。

トランザクションのバッチ処理とは別に、ZKロールアップはトランザクションデータを圧縮することでユーザーの手数料を削減します。 イーサリアムのZKロールアップを使用する際のコストのリアルタイムの概要を確認 (opens in a new tab)できます。

ZKロールアップはどのようにイーサリアムをスケーリングするのか？

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

ZKロールアップは計算をオフチェーンに移行することでイーサリアムのベースレイヤーのスループットを拡張しますが、スケーリングの真の推進力はトランザクションデータの圧縮から来ます。 イーサリアムのブロックサイズは、各ブロックが保持できるデータ量、ひいてはブロックごとに処理されるトランザクションの数を制限します。 トランザクション関連のデータを圧縮することで、ZKロールアップはブロックごとに処理されるトランザクションの数を大幅に増やします。

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

再帰的証明

ゼロ知識証明の利点は、証明が他の証明を検証できることです。 例えば、単一のZK-SNARKは他のZK-SNARKを検証できます。 このような「証明の証明」は再帰的証明と呼ばれ、ZKロールアップのスループットを劇的に向上させます。

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

しかし、再帰的証明を使用すると、1つの有効性証明で複数のブロックをファイナライズすることが可能になります。 これは、証明回路が1つの最終的な証明が作成されるまで、複数のブロック証明を再帰的に集約するためです。 L2オペレーターはこの再帰的証明を送信し、コントラクトがそれを受け入れると、関連するすべてのブロックが即座にファイナライズされます。 再帰的証明により、一定間隔でイーサリアム上でファイナライズできるZKロールアップのトランザクション数が増加します。

ZKロールアップのメリットとデメリット

メリットデメリット
有効性証明はオフチェーン・トランザクションの正確性を保証し、オペレーターが無効な状態遷移を実行するのを防ぎます。有効性証明の計算と検証に関連するコストは大きく、ロールアップユーザーの手数料を増加させる可能性があります。
L1で有効性証明が検証されると状態の更新が承認されるため、より高速なトランザクションのファイナリティを提供します。ゼロ知識技術の複雑さのため、EVM互換のZKロールアップを構築することは困難です。
セキュリティは、オプティミスティック・ロールアップのようにインセンティブを与えられたアクターの誠実さではなく、トラストレスな暗号メカニズムに依存しています。有効性証明の生成には専用のハードウェアが必要であり、これが少数の当事者によるチェーンの中央集権的な制御を助長する可能性があります。
オフチェーンの状態を回復するために必要なデータをL1に保存し、セキュリティ、検閲耐性、および分散化を保証します。中央集権的なオペレーター（シーケンサー）がトランザクションの順序付けに影響を与える可能性があります。
ユーザーはより高い資本効率の恩恵を受け、遅延なくL2から資金を引き出すことができます。ハードウェア要件により、チェーンを強制的に進行させることができる参加者の数が減少し、悪意のあるオペレーターがロールアップの状態を凍結し、ユーザーを検閲するリスクが高まる可能性があります。
ライブネスの仮定に依存せず、ユーザーは自分の資金を保護するためにチェーンを検証する必要がありません。一部の証明システム（例：ZK-SNARK）はトラステッド・セットアップを必要とし、これが誤って処理された場合、ZKロールアップのセキュリティモデルを損なう可能性があります。
より優れたデータ圧縮は、イーサリアムにcalldataを公開するコストを削減し、ユーザーのロールアップ手数料を最小限に抑えるのに役立ちます。

ZKロールアップの視覚的な説明

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

Rollups: the ultimate Ethereum scaling strategy?

A deep dive into rollups as Ethereum's primary scaling strategy.

トランスクリプト付きで視聴 

誰がzkEVMに取り組んでいるのか？

L2向けzkEVMとL1向けzkEVM

以下のプロジェクトは、zkEVM技術を使用してレイヤー2 (L2)ロールアップを構築しています。また、L1ブロックの検証にzkEVMを使用する研究も行われており、これによりバリデータはトランザクションを再実行することなくイーサリアムのブロックを検証できるようになります。

zkEVMに取り組んでいるプロジェクトには以下が含まれます。

  • zkEVM (opens in a new tab) - zkEVMは、EVM互換のZKロールアップとイーサリアムのブロックの有効性証明を生成するメカニズムを開発するために、イーサリアム財団から資金提供を受けているプロジェクトです。

  • Polygon zkEVM (opens in a new tab) - イーサリアム・メインネット上の分散型ZKロールアップであり、ゼロ知識証明の検証を伴うスマート・コントラクトを含むイーサリアムのトランザクションを透過的な方法で実行するゼロ知識イーサリアム仮想マシン（zkEVM）に取り組んでいます。

  • Scroll (opens in a new tab) - Scrollは、イーサリアム向けのネイティブなzkEVMレイヤー2 (L2)ソリューションの構築に取り組んでいる技術主導の企業です。

  • Taiko (opens in a new tab) - Taikoは、分散型のイーサリアム等価なZKロールアップ（タイプ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 (L2)スケーリングソリューションです。

  • Morph (opens in a new tab) - Morphは、レイヤー2 (L2)の状態チャレンジ問題に対処するためにZK証明を利用するハイブリッド・ロールアップ・スケーリングソリューションです。

  • Linea (opens in a new tab) - Lineaは、コンセンシスによって構築されたイーサリアム等価なzkEVMレイヤー2 (L2)であり、イーサリアム・エコシステムと完全に連携しています。

ZKロールアップに関する参考文献

チュートリアル：イーサリアムにおけるプライバシーとゼロ知識