バリディアム
最終編集者: @HiroyukiNaito(opens in a new tab), 2024年6月11日
バリディアムは、 ゼロ知識ロールアップのような有効性証明を使用してトランザクションの完全性を強化するスケーリングソリューションですが、トランザクションのデータはイーサリアムメインネットに保存されません。 オフチェーンにおけるデータの可用性が低下するというトレードオフが存在する一方で、スケーラビリティが大幅に向上します(バリディアムでは、1秒間に9,000件以上のトランザクションが実行可能です(opens in a new tab))。
前提知識
イーサリアムのスケーリングとレイヤー2 のページを読んで理解しておくことをおすすめします。
バリディアムとは何か?
バリディアムは、オフチェーンにおけるデータの可用性および処理能力を用いてイーサリアムメインネット外でトランザクションを処理することでスループットの向上を目指すスケーリング・ソリューションです。 ゼロ知識ロールアップ(ZKロールアップ)と同様に、バリディアムではを発行することで、オフチェーンのトランザクションをイーサリアム上で検証します。 これにより無効な状態遷移の発生を防ぐことができるため、バリディアムチェーンのセキュリティが強化されます。
ゼロ知識証明をはじめとする「有効性証明」は、ZK-SNARK(ゼロ知識であり、簡潔かつ非双方向の知識アーギュメント)またはZK-STARK(ゼロ知識であり、スケーラブルかつ透明性が高い知識アーギュメント)のいずれかに分類されます。 詳細については、ゼロ知識証明(opens in a new tab)をご覧ください。
バリディアムでは、ユーザーの資金はイーサリアム上のスマートコントラクトで管理されます。 バリディアムは、ゼロ知識ロールアップの場合とよく似たほぼ瞬時の出金が可能です。出金リクエストに対する有効性証明がメインネット上で検証されると、ユーザーはマークル証明を提供することで資金を引き出せるようになります。 マークル証明は、ユーザーの出金トランザクションが検証済みのトランザクション・バッチに含まれることを確認するもので、オンチェーンのコントラクトが当該の出金を処理することを許可します。
一方で、バリディアムでは、ユーザーの資金を凍結し、引き出しを制限することも可能です。 バリディアムチェーンでデータの可用性を管理するマネージャーが、他のユーザーにオフチェーンの状態データを提供できなくすることができるためです。 トランザクションデータにアクセスできないユーザーは、資金の所有権を証明し、出金を実行するのに必要なマークル証明を計算できません。
つまり、データの可用性に関する姿勢が、バリディアムとゼロ知識ロールアップとの最大の違いだと言えます。 これらのソリューションは、データストレージに対して異なるアプローチを採用しているため、セキュリティやトラストレス性にも影響があります。
バリディアムは、どのようにイーサリアムメインネットとやりとりするのか?
バリディアムは、既存のイーサリアムチェーン上で構築されたスケーリング用のプロトコルです。 バリディアムチェーンは、オフチェーンでトランザクションを実行する一方で、メインネット上でデプロイされた以下をはじめとする一連のスマートコントラクトで管理されます。
検証者コントラクト: 検証者コントラクトは、バリディアムチェーンが状態更新を行う際に、バリディアムのオペレーターから受信した有効性証明を検証します。 これには、オフチェーンのトランザクションの正しさを証明する有効性証明と、オフチェーンにおいてトランザクションデータが存在することを証明するデータ可用性証明があります。
メインコントラクト: メインコントラクトは、ブロック生成者が送信したステートコミットメント (マークルルート) を保存し、有効性証明がオンチェーンで確認された時点でバリディアムの状態を更新します。 メインコントラクトはさらに、バリディアムチェーンからの入金/出金を処理します。
バリディアムでは、さらに以下の機能についてメインのイーサリアムチェーンに依存します:
決済
バリディアム上で実行されたトランザクションは、親チェーンが当該トランザクションの有効性を検証するまでは、完全に確定しません。 バリディアム上で実行されたすべての処理は、最終的にメインネットで決済される必要があります。 また、イーサリアムブロックチェーンはバリディアムのユーザーに対して「決済保証」を提供するため、オンチェーンでコミットされたオフチェーンのトランザクションは取消/改変が不可能になります。
セキュリティ
イーサリアムはさらに、決済レイヤーとして動作することで、バリディアムの状態遷移についてもその有効性を保証します。 バリディアムチェーン上で実行されたオフチェーンのトランザクションは、イーサリアムのベースレイヤー上のスマートコントラクトによって検証されます。
オンチェーンの検証者コントラクトにより、当該の証明が無効だと判断された場合、トランザクションは却下されます。 つまり、バリディアムのオペレーターは、バリディアムの状態を更新する事前に、イーサリアムのプロトコルが要求する有効性の条件を満たす必要があります。
バリディアムはどのように機能するのか?
トランザクション
各ユーザーは、バリディアムチェーンにおいてトランザクションの実行に責任を負うノードであるオペレーターにトランザクションを送信します。 バリディアムの実装により、バリディアムチェーンの実行を単独のオペレーターが担う場合と、プルーフ・オブ・ステーク(PoS)のメカニズムを用いてオペレーターをローテーションする場合があります。
オペレーターは、複数のトランザクションをバッチ化した上で、検証のために証明サーキットに送信します。 証明サーキットは、このトランザクションバッチ(およびその他の関連データ)をインプットとして受け取り、操作が正しく実行されたことを検証する有効性証明をアウトプットとして出力します。
ステート・コミットメント
バリディアムの状態は、ルートがイーサリアムのメインコントラクトに保存されたマークルツリーとしてハッシュ化されます。 マークルルート(ステートルートとも呼ぶ)は、バリディアムチェーンにおける各アカウントおよび残高の現在状態に対する暗号コミットメントの役割を担います。
オペレーターが状態を更新するには、(トランザクションを実行した後で)新規の状態ルートを計算し、これをオンチェーンのコントラクトに送信する必要があります。 有効性証明が確認されると、提案された状態が承認され、バリディアムが新たな状態ルートに移行します。
入金と出金
各ユーザーは、オンチェーンのコントラクトにETH(またはその他のERC互換トークン)を預け入れることで、イーサリアムからバリディアムに資金を移動できます。 当該コントラクトが入金イベントをオフチェーンのバリディアムにリレーし、入金額と同じ額がバリディアムチェーン上のユーザーアドレスに追加されます。 オペレーターは同時に、入金トランザクションを新規バッチに追加します。
資金をメインネットに戻したい場合は、バリディアム上で出金トランザクションを開始し、オペレーターに送信します。オペレーターは、この出金リクエストに対して検証を行った上で、次のバッチに追加します。 また、バリディアムチェーン上のユーザー資産は、ユーザーがバリディアムチェーンから退出する事前に破壊されます。 当該バッチに関連付けられた有効性証明が確認だれると、ユーザーはメインのコントラクトを呼び出し、初回のデポジットの残余分を引き出すことができます。
バリディアムのプロトコルでは、検閲耐性のメカニズムとして、ユーザーはオペレーターを介さずに直接バリディアム上のコントラクトから資産を引き出すことが可能です。 この場合、ユーザーは、アカウントが状態ルートに含まれることを示すマークル証明を検証者コントラクトに提供する必要があります。 この証明が承認されれば、ユーザーはメインのコントラクトにおける引き出し関数を呼び出し、バリディアムから資金を退出させることができます。
バッチの送信
オペレーターは、複数のトランザクションからなるバッチを実行した後、それに関連した有効性証明を検証者コントラクトに送信し、メインのコントラクトに新規のステートルートを提案します。 この証明が有効であれば、メインのコントラクトはバリディアムの状態を更新し、当該バッチに含まれるトランザクションの処理を確定します。
ゼロ知識ロールアップとは異なり、バリディアム上のブロック生成者は、トランザクションを含むバッチのトランザクションデータを公開する必要がありません(ブロックヘッダーのみ公開すればよいです)。 これによりバリディアムは、メインのイーサリアムチェーンに状態データをcalldata
として公開する「ハイブリッド型」のスケーリング・プロトコル(つまり、レイヤー2)ではなく、純粋にオフチェーンのスケーリング・プロトコルであると言えます。
データ可用性
前述のように、バリディアムでは、オペレーターがすべてのトランザクションデータをイーサリアムメインネット外で保存するというオフチェーンのデータ可用性モデルを採用しています。 バリディアムでは、オンチェーンにおけるデータ消費量が少ないため、スケーラビリティが向上し(イーサリアムのデータ処理能力によりスループットが制限されない)、ユーザー手数料が軽減されます(calldata
を公開する費用が抑えられる)。
ただし、オフチェーンのデータ可用性においては、マークル証明の作成/検証に必要なデータが参照できない可能性があるという問題があります。 つまり、オペレーターが悪意で行動する場合、ユーザーはオンチェーンのコントラクトから資金を引き出せない可能性があります。
様々なバリディアムのソリューションでは、状態データの保存を分散化することでこの問題を解消しようとします。 具体的には、ブロック生成者は、オフチェーンでデータを保存し、リクエストに応じてユーザーに提供する作業に責任を負う「データ可用性の管理者」に対して、裏付けとなるデータを送信しなければなりません。
バリディアムにおけるデータ可用性の管理者は、バリディアム上の各バッチに署名することで、オフチェーンのトランザクションに関連したデータの可用性を保証します。 この署名は、オンチェーンの検証者コントラクトが状態更新を承認する事前に確認する「可用性証明」の形を取ります。
さまざまなバリディアムの実装により、データ可用性の管理アプローチは異なります。 具体的には、信頼できる当事者のみに状態データを保存させる方法と、無作為に指定したバリデータにこのタスクを委任する方法があります。
データ可用性委員会(DAC)
一部のバリディアム・ソリューションでは、オフチェーンにおけるデータの可用性を保証するために、状態コピーの保存およびデータ可用性証明の提供を担う信頼されるエンティティの集団を指名します(これらのエンティティを総称して「データ可用性委員会」(DAC)と呼びます)。 DACは、メンバーであるユーザーの数が限定されるため、導入やメンバー間の連携が容易になります。
その一方で、通常ユーザーは、データを必要とする際に(例:マークル証明を生成するため)、その可用性についてDACを信頼しなければならなくなります。 また、DACのメンバーが悪意のアクターに侵入され(opens in a new tab)、オフチェーンのデータを秘匿してしまう可能性があります。
バリディアムにおけるデータ可用性委員会の詳細(opens in a new tab)をご覧ください。
ボンド提供を伴うデータの可用性
その他のバリディアム実装では、オフラインでのデータ保存を担うユーザーに対し、その役割を引き受ける事前にスマートコントラクト上でトークンをステークする(つまり、ロックアップする)ことを要求しています。 このステークは、データ可用性の管理者における正直な行動を保証するための「ボンド」(担保)として機能するため、信頼性の要求を軽減することができます。 これらの参加者がデータの可用性を証明できない場合、預け入れたボンドは没収されます。
ボンド提供型のデータ可用性スキームでは、要求されるステークを提供すればどのユーザーでもオフチェーンのデータ保存の役割を担うことができます。 これにより、データ可用性の管理者を担えるユーザーの層が拡大するため、データ可用性委員会(DAC)に伴う分散性の低下を抑えることができます。 さらに重要なのは、この暗号経済的なインセンティブにより悪意の行為を抑制するアプローチは、バリディアムにおけるオフラインデータのセキュリティを保証する上で、信頼できるユーザーを指定するアプローチよりもはるかに安全だという点です。
バリディアムにおけるボンド提供型のデータ可用性の詳細(opens in a new tab)をご覧ください。
Volitionsとバリディアム
バリディアムは様々な利点を提供する一方で、トレードオフ(特に、データの可用性)も存在します。 他の多くのスケーリング・ソリューションと同様に、バリディアムの様々な実装は具体的なユースケースに合わせて開発されており、そのひとつとしてVolitionsが挙げられます。
Volitionsは、ゼロ知識ロールアップとバリディアムチェーンを組み合わせたサービスであるため、これら2つのスケーリング・ソリューションを使い分けることが可能です。 Volitionsを使えば、一部のトランザクションについてはバリディアムによるオフチェーンのデータ可用性を活用しつつ、必要に応じてオンデータのデータ可用性(ゼロ知識ロールアップ)も利用できる自由度を確保できるのです。 これにより、ユースケースごとの要請に応じて、どのトレードオフを選択するのかをユーザーが決定できます。
分散型取引所(DEX)の場合、高価値の取引に対してスケーラブルかつプライベートなインフラを提供するバリディアムが適しているかも知れません。 しかし同時に、より高いセキュリティ保証とトラストレス性を望むユーザーのために、ゼロ知識ロールアップを使用することもできます。
バリディアムにおけるEVMとの互換性
バリディアムは主に、ゼロ知識ロールアップと同じくトークンのスワップや決済といったシンプルな用途に適しています。 ゼロ知識の証明サーキットでEVMの命令を証明しようとすると大きな間接費用が発生するため、バリディアムの実装において一般的な計算処理やスマートコントラクトの実行をサポートするのは困難です。
一部のバリディアムのプロジェクトでは、効率的な証明のために最適化されたカスタムのバイトコードをコンパイルする際にEVM互換の言語(例:Solidity、Vyper)を用いることで、この問題を回避しようとしています。 このアプローチは、ゼロ知識証明に対応したより新しいVMの場合に重要なEVMオペコードをサポートしていない可能性があるため、デベロッパは最善の利用体験を提供するために高レベル言語で直接コーディングしなければならないという欠点があります。 これにより、デベロッパはまったく新しい開発スタックを用いてDappを開発しなければならなくなり、現在のイーサリアム・インフラとの互換性が失われてしまうため、問題がさらに悪化します。
しかし一部の開発チームでは、既存のEVMオペコードをゼロ知識証明サーキットのために最適化する作業を進めています。 この取り組みを通じて、プログラムの正確な実行を証明するEVM互換のVMとしてのゼロ知識イーサリアム仮想マシン(zkEVM)の開発が期待されています。 ZkEVMが実現した場合、バリディアムチェーンはオフチェーンでスマートコントラクトを実行し、有効性証明を送信することで、オフチェーンにおける計算をイーサリアム上で(再実行せずに)証明することができます。
zkEVMの詳細(opens in a new tab)をご覧ください。
バリディアムは、イーサリアムのスケーラビリティをどのように向上させるのか?
1. オフチェーンにおけるデータ保存
オプティミスティック・ロールアップやゼロ知識ロールアップといったレイヤー2のスケーリングプロジェクトでは、純粋にオフチェーンのみを活用したスケーリング・プロトコル(例:プラズマ)の場合に実現可能な無限のスケーラビリティを犠牲にする代わりに、トランザクションデータの一部をL1上で公開することでセキュリティを強化しています。 しかし同時に、ロールアップのスケーラビリティに関する特性は、イーサリアムメインネットのデータ帯域により制限されます(データシャーディングでは、この理由により、イーサリアムのデータストレージ容量の向上を提案しています)。
バリディアムでは、すべてのトランザクションデータをオフチェーンで保存し、状態アップデートをメインのイーサリアムチェーンにリレーする際にのみ状態コミットメント(および有効性証明)を送信することでスケーラビリティを達成しています。 しかしバリディアムは、有効性証明を用いることで、その他の純粋にオフチェーンのスケーリングソリューション(プラズマやサイドチェーン)よりも高いセキュリティ保証を提供しています。 バリディアムでは、イーサリアムがオフチェーンのトランザクションを検証する前に処理しなければならないデータ量が軽減されるため、メインネットのスループットを大きく改善できる設計を実現しています。
2. 再帰的証明
再帰的な証明とは、他の証明の有効性を証明する有効性証明です。 このような「証明に対する証明」は、最終的にこれまで作成されたすべての証明を証明できる1つの最終証明が作成されるまで、複数の証明を再帰的に集約することで実行されます。 再帰的証明は、1件の有効性証明で検証できるトランザクションの数を増やすため、ブロックチェーンの処理速度におけるスケーラビリティ向上を実現します。
通常、バリディアムのオペレーターがイーサリアムに提出する有効性証明は、単一のブロック全体を検証します。 これに対し、再帰的証明では、1件の再帰的証明を用いてバリディアム上の複数のブロックの有効性を同時に確認することができます。これは、再帰的証明のサーキットにおいては、複数のブロック証明を1件の最終証明に再帰的に集約できるためです。 オンチェーンの検証者コントラクトがこの再帰的証明を承認すると、その対象である裏付けのブロックすべてがただちに確定します。
バリディアムの長所と短所
長所 | 短所 |
---|---|
有効性証明により、オフチェーンにおけるトランザクションの完全性が確保でき、オペレーターが無効な状態アップデートをファイナライズできなくなる。 | 有効性証明を生成するには特別なハードウェアが必要なため、分散化が低下するリスクがある。 |
ユーザーがより効率的に資金を利用できる(イーサリアムへの資金引き出しにおいて、遅延が発生しない)。 | 汎用的な計算/スマートコントラクトに対するサポートが限定的であり、開発には特殊な言語が必要である。 |
高価値の取引用に用いられる不正証明ベースのシステムを標的とする一部の経済的攻撃に対する脆弱性がない。 | ゼロ知識証明を生成するには高い処理能力が必要であり、低スループットの用途においてはコスト効率が悪い。 |
calldataをイーサリアムメインネットに送信しないため、ユーザーのガス代が軽減される。 | ユーザーの主観ではファイナリティを得るまでの時間が長い(ゼロ知識証明を生成するのに10〜30分が必要)が、紛争による遅延が生じないため、完全なファイナリティはより迅速に得られる。 |
トランザクションにおけるプライバシーやスケーラビリティが重視される資金取引やブロックチェーンゲームなど、特定のユースケースに適している。 | 所有権に対するマークル証明を生成するには常にオフチェーンのデータが利用可能でなければならないため、ユーザーの資金引き出しが妨害される可能性がある。 |
オフチェーンにおけるデータの可用性により、より高いスループットとスケーラビリティが実現できる。 | 純粋に暗号論的なセキュリティメカニズムに依存しているゼロ知識ロールアップとは異なり、信頼性の前提と暗号経済的なインセンティブに依存したセキュリティモデルである。 |
バリディアム/Volitionsの活用
複数のプロジェクトにより、Dappに組み込み可能なバリディアムおよびVolitionsの実装が提供されています。
StarkWare StarkEx - StarkExは、有効性証明ベースのイーサリアムレイヤー2((L2)の スケーリング・ソリューションです。 ゼロ知識ロールアップあるいはバリディアムのいずれかを用いたデータ可用性モードを選択できます。
Matter Labs zkPorter- zkPorterは、ゼロ知識ロールアップとシャーディングを結合したハイブリッド型のアプローチによりデータ化要請を追跡する、レイヤー2のスケーリング・プロトコルです。 任意の数のシャードをサポートしており、シャードごとに異なるデータ可用性ポリシーを定めることができます。