はじめに: 検証可能性への道

Web3 の最大のメリットは検証可能性です。ユーザーはシステムが実際にどのように動作するかを検証できます。この機能により、暗号業界内外の多くの人が、Web3 をより透明性が高く検証可能なインターネットへの一歩と表現する理由がわかります。

Facebook や Instagram などの Web2 プラットフォームでは、アルゴリズムやルールが文書化されていても不透明なままですが、暗号プロトコルは完全な監査可能性を考慮して設計されています。共有されていても、プラットフォームが仕様どおりに動作しているかどうかを確認する機能はありません。これは、すべてのプロトコルが可能な限り監査可能であるように設計されている (少なくとも、そうであることが期待されている) 暗号とは正反対です。

今日は、Vitalik が最近公開したEthereum の将来に関する 6 部構成のシリーズから「The Verge」を取り上げ、Ethereum が将来的に検証可能性、持続可能性、スケーラビリティを実現するために取っているステップを分析します。「The Verge」という見出しの下で、ブロックチェーン アーキテクチャをより検証可能にする方法、これらの変更がプロトコル レベルでもたらす革新、そしてそれらによってユーザーに安全なエコシステムが提供される方法について説明します。それでは始めましょう。

「検証可能性」とはどういう意味ですか?

Web2 アプリケーションは「ブラック ボックス」として機能します。つまり、ユーザーは入力とその結果の出力しか見ることができず、アプリケーションが実際にどのように動作するかはわかりません。対照的に、暗号通貨プロトコルは通常、ソース コードを一般公開するか、少なくともそうする予定です。この透明性には 2 つの目的があります。ユーザーが希望する場合は、プロトコルのコードと直接やり取りできるようにすることと、システムがどのように動作し、どのようなルールが適用されるかをユーザーが正確に理解できるようにすることです。

「できるものは分散し、残りは検証する。」

検証可能性は、システムの説明責任を保証し、多くの場合、プロトコルが意図したとおりに機能することを保証します。この原則は、集中化を最小限に抑えることの重要性を強調しています。集中化は、ユーザーが操作を検証できない不透明で説明責任のない構造につながることが多いためです。代わりに、可能な限り分散化を図り、分散化が実現できない場合は残りの要素を検証可能で説明責任のあるものにする必要があります。

イーサリアム コミュニティはこの見解に賛同しているようで、ロードマップにはイーサリアムの検証可能性を高めることを目的としたマイルストーン (「The Verge」と呼ばれる) が含まれています。ただし、The Verge について詳しく説明する前に、ブロックチェーンのどの側面を検証する必要があるのか、またユーザーの観点からどの部分が重要なのかを理解する必要があります。

ブロックチェーンは、本質的にはグローバル クロックとして機能します。約 10,000 台のコンピューターで構成される分散ネットワークでは、トランザクションが発信ノードから他のすべてのノードに伝播するのにかなりの時間がかかることがあります。このため、ネットワーク全体のノードは、独自の主観的な視点しか持たないため、トランザクションの正確な順序 (あるトランザクションが別のトランザクションより先に到着したか後に到着したか) を判断できません。

トランザクションの順序は重要であるため、ブロックチェーン ネットワークでは、「コンセンサス アルゴリズム」と呼ばれる特殊な方法を使用して、ノードが同期された状態を維持し、トランザクション シーケンスを同じ順序で処理できるようにします。ノードはトランザクションの順序をグローバルに決定することはできませんが、コンセンサス メカニズムにより、すべてのノードが同じシーケンスに同意できるようになり、ネットワークが単一のまとまりのあるコンピューターとして機能するようになります。

コンセンサス レイヤーの他に、すべてのブロックチェーンに存在する実行レイヤーもあります。実行レイヤーは、ユーザーが実行したいトランザクションによって形成されます。トランザクションがコンセンサスによって正常に順序付けされると、各トランザクションは実行レイヤーの現在の状態に適用されなければなりません。「状態とは何か?」と疑問に思う場合は、ブロックチェーンがデータベースと比較されているのを見たことがあるでしょう。より具体的には、銀行のデータベースと比較されます。なぜなら、ブロックチェーンは銀行のように、全員の残高の記録を保持しているからです。

「S」と呼ばれる状態に 100 ドルあり、その 10 ドルを他の人に送金したい場合、次の状態「S+1」での残高は 90 ドルになります。トランザクションを適用して 1 つの状態から別の状態に移行するこのプロセスを、 STF (状態遷移関数)と呼びます。

ビットコインでは、STF は主に残高の変更に限定されているため、比較的シンプルです。ただし、ビットコインとは異なり、イーサリアムの STF ははるかに複雑です。イーサリアムは、コードを実行できる実行レイヤーを備えた完全にプログラム可能なブロックチェーンだからです。

ブロックチェーンには、検証する必要がある、または検証できる 3 つの基本的なコンポーネントがあります。

1. 状態: ブロックチェーン上のデータの一部を読み取りたいが、フルノードを実行していないため状態にアクセスできない場合があります。そのため、Alchemy や Infura などの RPC (リモート プロシージャ コール) プロバイダーを介してデータを要求します。ただし、データが RPC プロバイダーによって改ざんされていないことを確認する必要があります。
2. 実行: 前述のように、ブロックチェーンは STF を利用します。状態遷移が正しく実行されたかどうかを、トランザクションごとではなくブロックごとに検証する必要があります。
3. コンセンサス: RPC などのサードパーティ エンティティは、ブロックチェーンにまだ含まれていない有効なブロックを提供する場合があります。したがって、これらのブロックがコンセンサスによって承認され、ブロックチェーンに追加されたことを確認する必要があります。

私

わかりにくい、または不明瞭に思えても心配しないでください。それぞれの側面について詳しく説明します。まずはブロックチェーンの状態を確認する方法から始めましょう。

ブロックチェーンの状態を検証するにはどうすればいいですか?

Ethereum の「状態」とは、任意の時点でブロックチェーンに保存されているデータのセットを指します。これには、アカウントの残高 (契約アカウントと外部所有アカウントまたは EOA)、スマート コントラクト コード、契約ストレージなどが含まれます。Ethereum は状態ベースのマシンです。Ethereum 仮想マシン (EVM) で処理されるトランザクションによって以前の状態が変更され、新しい状態が生成されるためです。

各 Ethereum ブロックには、そのブロックの後のネットワークの現在の状態を要約した値、つまりstateRoot が含まれています。この値は、64 文字のハッシュで構成される、Ethereum の状態全体をコンパクトに表現したものです。

新しいトランザクションが状態を変更するたびに、後続のブロックに記録される stateRoot がそれに応じて更新されます。この値を計算するために、Ethereum バリデータは Keccak ハッシュ関数とMerkle Treeと呼ばれるデータ構造を組み合わせて使用し、状態のさまざまな部分を整理して要約します。

ハッシュ関数は、入力を固定長の出力に変換する一方向関数です。Ethereum では、 Keccakなどのハッシュ関数を使用してデータの要約を生成し、入力の指紋のような役割を果たします。ハッシュ関数には、次の 4 つの基本的な特性があります。

1. 決定論: 同じ入力は常に同じ出力を生成します。
2. 固定出力長: 入力の長さに関係なく、出力長は常に固定されます。
3. 一方向特性: 出力から元の入力を導き出すことは事実上不可能です。
4. 一意性: 入力が少し変更されただけでも、まったく異なる出力が生成されます。したがって、特定の入力は実質的に一意の出力にマッピングされます。

これらの特性のおかげで、Ethereum バリデータは各ブロックに対して STF (状態遷移関数) を実行できます。つまり、ブロック内のすべてのトランザクションを実行して状態に適用し、ブロックに示されている状態が STF 後の状態と一致するかどうかを検証できます。このプロセスにより、ブロックの提案者が誠実に行動したことが保証されるため、バリデーターの重要な責任の 1 つとなります。

ただし、Ethereum バリデータは、状態全体を直接ハッシュしてその概要を見つけることはありません。ハッシュ関数の一方向の性質により、状態を直接ハッシュすると検証可能性が失われます。ハッシュを再現する唯一の方法は、状態全体を所有することだからです。

Ethereum の状態はテラバイト単位のサイズであるため、電話やパソコンなどの日常的なデバイスに状態全体を保存するのは非現実的です。このため、Ethereum は Merkle ツリー構造を使用して stateRoot を計算し、状態の検証可能性を可能な限り維持します。

マークル ツリーは、データの整合性と正確性を安全かつ効率的に検証するために使用される暗号化データ構造です。マークル ツリーはハッシュ関数に基づいて構築され、データセットのハッシュを階層的に整理して、このデータの整合性と正確性を検証できるようにします。このツリー構造は、次の 3 種類のノードで構成されています。

1. リーフ ノード: これらのノードには個々のデータ ピースのハッシュが含まれており、ツリーの最下位レベルにあります。各リーフ ノードは、Merkle ツリー内の特定のデータ ピースのハッシュを表します。
2. ブランチ ノード: これらのノードには、子ノードの結合ハッシュが含まれます。たとえば、バイナリ マークル ツリー (N = 2) では、2 つの子ノードのハッシュが連結され、再度ハッシュされて、より高いレベルのブランチ ノードのハッシュが生成されます。
3. ルート ノード: ルート ノードは Merkle ツリーの最上位レベルにあり、ツリー全体の暗号化の概要を表します。このノードは、ツリー内のすべてのデータの整合性と正確性を検証するために使用されます。

このようなツリーを構築する方法がわからない場合は、次の 2 つの簡単な手順を実行するだけです。

• リーフ ノードの作成: 各データはハッシュ関数によって処理され、その結果のハッシュがリーフ ノードを形成します。これらのノードはツリーの最下位レベルに存在し、データの暗号化された要約を表します。

• 結合とハッシュ: リーフ ノードのハッシュはグループ化され (たとえば、ペアで)、結合されてからハッシュされます。このプロセスにより、次のレベルのブランチ ノードが作成されます。1 つのハッシュだけが残るまで、同じプロセスがブランチ ノードに対して繰り返されます。

ツリーの最上部で取得される最終ハッシュは、Merkle ルートと呼ばれます。Merkle ルートは、ツリー全体の暗号化の概要を表し、データの整合性の安全な検証を可能にします。

Merkle ルートを使用して Ethereum の状態を検証するにはどうすればよいですか?

マークル証明により、検証者は、対象データ (リーフ ノード) からブロック ヘッダーに格納されているマークル ルートまでのパスを作成する一連のハッシュ値を提供することで、特定のデータ部分を効率的に検証できます。この中間ハッシュのチェーンにより、検証者は状態全体をハッシュしなくてもデータの信頼性を確認できます。

検証者は、特定のデータ ポイントから始めて、それを Merkle Proof で提供される各「兄弟」ハッシュと組み合わせ、ツリーを段階的にハッシュします。このプロセスは、単一のハッシュが生成されるまで続行されます。計算されたハッシュが保存されている Merkle Root と一致する場合、データは有効であるとみなされます。それ以外の場合、検証者は、データが要求された状態に対応していないと判断できます。

例: マークル証明によるデータポイントの検証

RPC からデータ #4 を受信し、Merkle 証明を使用してその信頼性を検証するとします。これを行うには、RPC は Merkle ルートに到達するために必要なパスに沿ってハッシュ値のセットを提供します。データ 4 の場合、これらの兄弟ハッシュにはハッシュ #3、ハッシュ #12、ハッシュ #5678 が含まれます。

1. データ 4 から開始します。まず、データ #4 をハッシュしてハッシュ #4 を取得します。
2. 兄弟との結合: 次に、ハッシュ #4 をハッシュ #3 (リーフ レベルでの兄弟) と結合し、一緒にハッシュしてハッシュ #34 を生成します。
3. ツリーの上へ移動: 次に、ハッシュ #34 をハッシュ #12 (次のレベルの兄弟) と組み合わせてハッシュし、ハッシュ #1234 を取得します。
4. 最終ステップ: 最後に、ハッシュ #1234 とハッシュ #5678 (提供された最後の兄弟) を組み合わせてハッシュします。結果のハッシュは、ブロック ヘッダーに保存されている Merkle ルート (ハッシュ #12345678) と一致するはずです。

計算されたマークル ルートがブロック内の状態ルートと一致する場合、データ #4 がこの状態内で実際に有効であることが確認されます。一致しない場合は、データが要求された状態に属していないことがわかり、改ざんの可能性があります。ご覧のとおり、すべてのデータのハッシュを提供したり、検証者にマークル ツリー全体を最初から再構築させたりすることなく、証明者は 3 つのハッシュのみを使用して、データ #4 が状態に存在し、途中で変更されていないことを証明できます。これが、マークル証明が効率的であると考えられる主な理由です。

マークルツリーは、イーサリアムのような大規模なブロックチェーンシステムで安全かつ効率的なデータ検証を提供するのに間違いなく効果的ですが、本当に十分な効率性があるのでしょうか? この疑問に答えるには、マークルツリーのパフォーマンスとサイズが証明者と検証者の関係にどのような影響を与えるかを分析する必要があります。

マークルツリーのパフォーマンスに影響を与える2つの重要な要素

1. 分岐係数: 分岐あたりの子ノードの数。
2. 合計データ サイズ: ツリー内に表示されるデータセットのサイズ。

分岐因子の影響:

その影響をよりよく理解するために、例を見てみましょう。分岐係数は、ツリー内の各ノードから発生するブランチの数を決定します。

• 小さな分岐係数 (例: バイナリ マークル ツリー) : バイナリ マークル ツリー (分岐係数 2) を使用すると、証明サイズが非常に小さくなり、検証者にとって検証プロセスがより効率的になります。各ノードに 2 つの分岐しかないため、検証者はレベルごとに 1 つの兄弟ハッシュを処理するだけで済みます。これにより、検証が高速化され、計算負荷が軽減されます。ただし、分岐係数が減るとツリーの高さが増し、ツリー構築時にハッシュ操作が増え、検証者にとって負担になる可能性があります。
• より大きな分岐係数 (例: 4) : より大きな分岐係数 (例: 4) はツリーの高さを減らし、より短くより広い構造を作成します。これにより、必要なハッシュ操作が少なくなるため、フルノードはツリーをより速く構築できます。ただし、検証者にとっては、各レベルで処理する必要がある兄弟ハッシュの数が増え、証明サイズが大きくなります。検証ステップあたりのハッシュが増えると、検証者の計算コストと帯域幅コストも高くなり、実質的に検証者から検証者への負担が移行されます。

総データサイズの影響

Ethereum ブロックチェーンが成長するにつれて、新しいトランザクション、契約、またはユーザーインタラクションがデータセットに追加され、Merkle ツリーも拡張する必要があります。この成長はツリーのサイズを増やすだけでなく、証明のサイズと検証時間にも影響を及ぼします。

• フルノードは、Merkle ツリーを維持するために、増え続けるデータセットを定期的に処理して更新する必要があります。
• 一方、検証者は、データセットが大きくなるにつれて、より長く複雑な証明を検証する必要があり、追加の処理時間と帯域幅が必要になります。

このデータサイズの増大により、フルノードと検証者の両方に対する需要が増加し、ネットワークを効率的に拡張することが難しくなります。要約すると、Merkle Trees はある程度の効率性を提供しますが、Ethereum の継続的に成長するデータセットに対する最適なソリューションには至っていません。このため、 The Vergeフェーズでは、Ethereum はMerkle Trees をVerkle Treesと呼ばれるより効率的な構造に置き換えることを目指しています。Verkle Trees は、同じレベルのセキュリティを維持しながら証明サイズを小さくできる可能性があり、証明者と検証者の両方にとって検証プロセスをより持続可能でスケーラブルにします。

The Verge: イーサリアムの検証可能性を革新する

The Verge は、検証可能性の向上、ブロックチェーンの分散構造の強化、ネットワーク セキュリティの強化を目的とした Ethereum のロードマップのマイルストーンとして開発されました。Ethereum ネットワークの主な目標の 1 つは、誰でも簡単にバリデーターを実行してチェーンを検証できるようにし、集中化することなく誰もが参加できる構造を作成することです。

この検証プロセスのアクセシビリティは、ブロックチェーンを中央集権型システムと区別する重要な機能の 1 つです。中央集権型システムには検証機能はありませんが、ブロックチェーンの正確性は完全にユーザーの手に委ねられています。ただし、この保証を維持するには、バリデータの実行に誰もがアクセスできる必要があります。これは、現在のシステムでは、ストレージと計算の要件により制限されるという課題です。

The MergeでProof-of-Stakeコンセンサス モデルに移行して以来、Ethereum バリデーターには主に 2 つの責任があります。

1. コンセンサスの確保: 確率的コンセンサス プロトコルと決定論的コンセンサス プロトコルの両方が適切に機能することをサポートし、フォーク選択アルゴリズムを適用します。
2. ブロックの精度の確認: ブロック内のトランザクションを実行した後、結果の状態ツリーのルートが提案者によって宣言された状態ルートと一致することを確認します。

2 番目の責任を果たすには、バリデーターはブロック前の状態にアクセスできなければなりません。これにより、バリデーターはブロックのトランザクションを実行し、後続の状態を導出することができます。ただし、この要件はバリデーターに大きな負担をかけます。バリデーターは大量のストレージ要件を処理する必要があるためです。

Ethereum は実現可能な設計になっており、ストレージ コストは世界的に減少していますが、問題はコストではなく、バリデーター用の専用ハードウェアへの依存にあります。The Verge は、携帯電話、ブラウザー ウォレット、スマートウォッチなど、ストレージ容量が限られたデバイスでも完全な検証を実行できるインフラストラクチャを作成し、バリデーターをこれらのデバイスで実行できるようにすることで、この課題を克服することを目指しています。

検証可能性を実現するための第一歩: 効率的な状態検証

Verkle Treeへの移行は、このプロセスの重要な部分です。当初、 The Verge は、 Ethereum の Merkle Tree 構造を Verkle Tree に置き換えることに重点を置いていました。Verkle Tree を採用する主な理由は、Merkle Tree が Ethereum の検証可能性に大きな障害となるためです。Merkle Tree とその証明は通常のシナリオでは効率的に機能しますが、最悪のシナリオではパフォーマンスが大幅に低下します。

Vitalik の計算によると、平均的な証明サイズは約4 KBで、管理可能なように思えます。ただし、最悪の場合、証明サイズは330 MBにまで膨れ上がる可能性があります。はい、その通りです。330 MB です。

最悪のシナリオにおける Ethereum の Merkle Tree の極端な非効率性は、主に 2 つの理由から生じます。

1. 六分木の使用: Ethereum は現在、分岐係数が 16 の Merkle ツリーを使用しています。つまり、1 つのノードを検証するには、ブランチ内の残りの 15 個のハッシュを提供する必要があります。Ethereum の状態のサイズとブランチの数を考えると、最悪のシナリオでは大きな負担が生じます。

2. コードの非マーケッティング: 契約コードをツリー構造に組み込む代わりに、Ethereum はコードをハッシュし、結果の値をノードとして使用します。契約の最大サイズが24 KBであることを考慮すると、このアプローチは完全な検証可能性を実現するために大きな負担を課します。

証明サイズは分岐係数に正比例します。分岐係数を減らすと証明サイズも減ります。これらの問題に対処し、最悪のシナリオを改善するために、Ethereum は六分木から二分マークル木に切り替え、コントラクト コードのマークル化を開始する可能性があります。Ethereum の分岐係数が 16 から 2 に削減され、コントラクト コードもマークル化されると、最大証明サイズは10 MBに縮小される可能性があります。

これは大きな改善ですが、このコストは1 つのデータのみを検証する場合に適用されることに注意することが重要です。複数のデータにアクセスする単純なトランザクションでも、より大きな証明が必要になります。ブロックあたりのトランザクション数と Ethereum の継続的な成長を考えると、このソリューションは優れているものの、まだ完全に実現可能ではありません。

これらの理由から、イーサリアム コミュニティはこの問題に対処するために 2 つの異なる解決策を提案しました。

1. ヴェルクルツリー
2. STARK 証明 + バイナリ マークル木

Verkle ツリーとベクトルコミットメント

Verkle Treeは、その名前が示すように、 Merkle Treeに似たツリー構造です。ただし、最も大きな違いは、検証プロセス中に提供される効率性にあります。Merkle Treeでは、ブランチに 16 個のデータが含まれており、そのうちの 1 つだけを検証する場合、他の 15 個のデータをカバーするハッシュ チェーンも提供する必要があります。これにより、検証の計算負荷が大幅に増加し、証明のサイズが大きくなります。

対照的に、 Verkle Trees は「楕円曲線ベースのベクトルコミットメント」と呼ばれる特殊な構造、より具体的にはInner Product Argument (IPA)ベースのベクトルコミットメントを利用します。ベクトルは基本的に、特定の順序で整理されたデータ要素のリストです。Ethereum の状態はベクトルと考えることができます。つまり、多数のデータ片が特定の順序で保存され、各要素が重要な構造です。この状態は、アドレス、コントラクト コード、ストレージ情報などのさまざまなデータ コンポーネントで構成され、これらの要素の順序はアクセスと検証において重要な役割を果たします。

ベクトルコミットメントは、データセット内のデータ要素を証明および検証するために使用される暗号化方法です。これらの方法を使用すると、データセット内の各要素の存在と順序の両方を同時に検証できます。たとえば、Merkle Trees で使用されるMerkle Proofsも、ベクトルコミットメントの一種と考えることができます。Merkle Trees では、要素を検証するためにすべての関連するハッシュ チェーンが必要ですが、その構造は本質的に、ベクトルのすべての要素が特定の順序で接続されていることを証明します。

Merkle ツリーとは異なり、Verkle ツリーは楕円曲線ベースのベクトルコミットメントを採用しており、次の 2 つの重要な利点があります。

• 楕円曲線ベースのベクトルコミットメントは、検証対象のデータ以外の要素の詳細を必要としません。分岐係数が 16 の Merkle Tree では、1 つの分岐を検証するには、他の 15 個のハッシュを提供する必要があります。多くの分岐を含む Ethereum の状態は膨大なため、これは大きな非効率性を生み出します。しかし、楕円曲線ベースのベクトルコミットメントは、この複雑さを排除し、より少ないデータと計算量で検証を可能にします。
• マルチプルーフにより、楕円曲線ベースのベクトルコミットメントによって生成されたプルーフを、単一の一定サイズのプルーフに圧縮できます。Ethereum の状態は大きいだけでなく、継続的に成長しているため、Merkle Root にアクセスするために検証が必要なブランチの数は、時間の経過とともに増加します。ただし、Verkle Trees を使用すると、 Dankrad Feist の記事で詳しく説明されている方法を使用して、各ブランチのプルーフを単一の一定サイズのプルーフに「圧縮」できます。これにより、検証者は各ブランチを個別に検証するのではなく、1 つの小さなプルーフでツリー全体を検証できます。これは、Verkle Trees が Ethereum の状態の成長の影響を受けないことも意味します。

楕円曲線ベースのベクトルコミットメントのこれらの機能により、検証に必要なデータの量が大幅に削減され、最悪のシナリオでも Verkle Trees は小さく一定サイズの証明を生成できます。これにより、データのオーバーヘッドと検証時間が最小限に抑えられ、Ethereum のような大規模ネットワークの効率が向上します。その結果、Verkle Trees で楕円曲線ベースのベクトルコミットメントを使用すると、Ethereum の拡張状態をより管理しやすく効率的に処理できるようになります。

すべてのイノベーションと同様に、Verkle Tree にも限界があります。主な欠点の 1 つは、量子コンピューターに対して脆弱な楕円曲線暗号に依存していることです。量子コンピューターは従来の方法よりもはるかに高い計算能力を備えているため、楕円曲線ベースの暗号プロトコルに大きな脅威をもたらします。量子アルゴリズムはこれらの暗号システムを破ったり弱めたりする可能性があり、Verkle Tree の長期的なセキュリティに関する懸念が生じています。

このため、Verkle Trees はステートレス化への有望な解決策を提供しますが、最終的な解決策ではありません。ただし、 Dankrad Feistなどの人物は、量子耐性のある暗号を Ethereum に統合する際には慎重な検討が必要であると強調していますが、現在 Ethereum の BLOB に使用されているKZG コミットメントも量子耐性がないことに留意する価値があります。したがって、Verkle Trees は暫定的な解決策として機能し、ネットワークにさらに堅牢な代替手段を開発するための時間を提供します。

STARK 証明 + バイナリ マークル木

Verkle Tree は、 Merkle Tree に比べて証明サイズが小さく、検証プロセスが効率的であるため、Ethereum の増え続ける状態の管理が容易になります。楕円曲線ベースのベクトルコミットメントにより、大幅に少ないデータで大規模な証明を生成できます。しかし、その優れた利点にもかかわらず、Verkle Tree は量子コンピューターに対して脆弱であるため、一時的な解決策にすぎません。

Ethereum コミュニティは Verkle Trees を短期的な時間稼ぎのツールと見なしていますが、長期的には量子耐性ソリューションへの移行に重点を置いています。ここで、 STARK ProofとBinary Merkle Trees は、将来に向けてより堅牢な検証インフラストラクチャを構築するための強力な代替手段となります。

Ethereum の状態検証プロセスでは、バイナリ マークル ツリーを使用することで、マークル ツリーの分岐係数を(16 から 2 に) 削減できます。この変更は、証明サイズを削減し、検証プロセスを効率化するための重要なステップです。ただし、最悪の場合でも、証明サイズは10 MBに達する可能性があり、これはかなりの量です。ここでSTARK 証明が役立ち、これらの大きなバイナリ マークル 証明をわずか100～300 kBに圧縮します。

この最適化は、軽量クライアントやハードウェアが制限されたデバイスでバリデーターを操作する制約を考慮すると特に重要です。特に、世界のモバイルの平均ダウンロード速度とアップロード速度がそれぞれ約 7.625 MB/秒と 1.5 MB/秒であることを考慮すると、この最適化は重要です。ユーザーは、完全な状態にアクセスする必要なく、小さくポータブルな証明でトランザクションを検証でき、バリデータは、状態全体を保存せずにブロック検証タスクを実行できます。

この二重の利点のあるアプローチにより、バリデーターの帯域幅とストレージ要件が削減され、検証が高速化されます。これは、Ethereum のスケーラビリティのビジョンを直接サポートする 3 つの重要な改善点です。

STARK証明の主な課題

1. 証明者に対する高い計算負荷: STARK 証明を生成するプロセスは、特に証明者側で計算負荷が高く、運用コストが増加する可能性があります。
2. 少量データの証明における非効率性: STARK 証明は大規模なデータセットの処理に優れていますが、少量のデータの証明では効率が悪く、特定のシナリオでは適用が困難になることがあります。より小さなステップやデータセットを含むプログラムを扱う場合、STARK の証明サイズが比較的大きいため、実用性やコスト効率が低下する可能性があります。

量子セキュリティにはコストがかかる：証明者側の計算負荷

ブロックの Merkle Proof には約330,000 個のハッシュが含まれ、最悪の場合、この数は660,000 個にまで増加する可能性があります。このような場合、STARK 証明では1 秒あたり約200,000 個のハッシュを処理する必要があります。ここで、この負荷を軽減するために STARK 証明に特に最適化された、 Poseidonなどの zk 対応ハッシュ関数が役立ちます。

Poseidon は、 SHA256やKeccakなどの従来のハッシュ アルゴリズムと比較して、ZK 証明とよりシームレスに連携するように設計されています。この互換性の主な理由は、従来のハッシュ アルゴリズムの動作方法にあります。つまり、入力をバイナリ データ (0 と 1) として処理します。

一方、ZK 証明は、根本的に異なる数学的構造である素体で動作します。この状況は、コンピューターが 2 進数で動作しているのに対し、人間は日常生活で 10 進数を使用していることに似ています。ビットベースのデータを ZK 互換形式に変換するには、かなりの計算オーバーヘッドがかかります。Poseidon は、素体内でネイティブに動作することでこの問題を解決し、ZK 証明との統合を大幅に加速します。

しかし、Poseidon は比較的新しいハッシュ関数であるため、SHA256 や Keccak などの従来のハッシュ関数と同じレベルの信頼性を確立するには、より広範なセキュリティ分析が必要です。この目的のために、Ethereum Foundation が立ち上げたPoseidon Cryptanalysis Initiativeなどのイニシアチブでは、専門家を招いて Poseidon のセキュリティを厳密にテストおよび分析し、敵対的な精査に耐え、暗号化アプリケーションの堅牢な標準となることを保証しています。一方、SHA256 や Keccak などの古い関数は、すでに広範囲にテストされており、セキュリティの実績が証明されていますが、ZK フレンドリーではないため、STARK 証明で使用するとパフォーマンスが低下します。

たとえば、これらの従来のハッシュ関数を使用する STARK 証明は現在、 10,000 ～ 30,000ハッシュしか処理できません。幸いなことに、STARK テクノロジの進歩により、このスループットはすぐに 100,000 ～ 200,000 ハッシュに増加し、効率が大幅に向上することが予想されます。

STARKの小規模データの証明における非効率性

STARK 証明は大規模なデータセットのスケーラビリティと透明性に優れていますが、小規模で多数のデータ要素を扱う場合には限界があります。これらのシナリオでは、証明されるデータは小さいことが多いですが、複数の証明が必要であることに変わりはありません。例:

1. AA 後のトランザクション検証: アカウント抽象化 (AA) を使用すると、ウォレットはコントラクト コードを指定して、現在 Ethereum で必須となっている nonce や署名検証などの手順をバイパスまたはカスタマイズできます。ただし、この検証の柔軟性には、トランザクションの有効性を証明するために、状態内のコントラクト コードまたはその他の関連データをチェックすることが必要です。
2. ライト クライアント RPC 呼び出し: ライト クライアントは、フル ノードを実行せずに、ネットワークから状態データを照会します (例: eth_call 要求中)。この状態の正確性を保証するには、照会されたデータを証明でサポートし、それがネットワークの現在の状態と一致することを確認する必要があります。
3. 包含リスト: 小規模なバリデーターは、包含リスト メカニズムを使用して、トランザクションが次のブロックに含まれるようにし、強力なブロック プロデューサーの影響を制限できます。ただし、これらのトランザクションの包含を検証するには、その正確性を検証する必要があります。

このようなユースケースでは、STARK 証明にはほとんど利点がありません。STARK は、スケーラビリティを重視しており (名前の「S」で強調されているように)、大規模なデータセットでは優れたパフォーマンスを発揮しますが、小規模なデータのシナリオでは苦労します。対照的に、 SNARK は簡潔性を重視して設計されており (名前の「S」で強調されているように)、証明のサイズを最小限に抑えることに重点を置いており、帯域幅やストレージの制約がある環境では明らかな利点があります。

STARK 証明のサイズは通常40～50 KBで、わずか288 バイトの SNARK 証明の約175 倍の大きさです。このサイズの違いにより、検証時間とネットワーク コストの両方が増加します。STARK 証明のサイズが大きい主な理由は、スケーラビリティを確保するために透明性と多項式コミットメントに依存しているため、小規模データのシナリオではパフォーマンス コストが発生します。このような場合、 Merkle 証明などのより高速でスペース効率の高い方法の方が実用的である可能性があります。Merkle 証明は計算コストが低く、更新が速いため、このような状況に適しています。

表にまとめられているように、Ethereum には選択可能な 4 つのパスがあります。

ヴェルクルツリー

1. Verkle Trees はEthereum コミュニティから幅広いサポートを受けており、開発を促進するために 2 週間に 1 回のミーティングが開催されています。この一貫した作業とテストのおかげで、Verkle Trees は現在の選択肢の中で最も成熟し、十分に研究されたソリューションとして際立っています。さらに、その加法的準同型性により、Merkle Trees とは異なり、すべてのブランチを再計算して状態ルートを更新する必要がなくなり、Verkle Trees はより効率的なオプションになります。他のソリューションと比較して、Verkle Trees はシンプルさを重視し、「シンプルさを保つ」や「シンプルがベスト」などのエンジニアリング原則に従っています。このシンプルさにより、Ethereum への統合とセキュリティ分析の両方が容易になります。

2. しかし、Verkle Trees は量子耐性がないため、長期的なソリューションにはなり得ません。Ethereum に統合された場合、このテクノロジーは、将来的に量子耐性ソリューションが必要になったときに置き換える必要がある可能性があります。Vitalik氏でさえ、Verkle Trees を STARK やその他のテクノロジーが成熟するまでの時間を稼ぐための一時的な手段と見なしています。さらに、Verkle Trees で使用される楕円曲線ベースのベクトルコミットメントは、単純なハッシュ関数と比較して計算負荷が高くなります。ハッシュベースのアプローチでは、フルノードの同期時間が短縮される可能性があります。さらに、多数の 256 ビット演算に依存しているため、現代の証明システム内で SNARK を使用して Verkle Trees を証明することが難しく、証明サイズを削減する将来の取り組みが複雑になります。

   
   

それでも、ハッシュに依存しない Verkle ツリーは Merkle ツリーよりもはるかに証明しやすいことに注意することが重要です。

STARK + 保守的なハッシュ関数

1. STARK をSHA256やBLAKEなどの定評のある保守的なハッシュ関数と組み合わせると、Ethereum のセキュリティ インフラストラクチャを強化する堅牢なソリューションが提供されます。これらのハッシュ関数は、学術分野と実用分野の両方で広く使用され、徹底的にテストされています。さらに、その量子耐性により、量子コンピューターがもたらす将来の脅威に対する Ethereum の耐性が強化されます。セキュリティが重要なシナリオでは、この組み合わせは信頼できる基盤を提供します。

2. ただし、STARK システムで保守的なハッシュ関数を使用すると、パフォーマンスが大幅に制限されます。これらのハッシュ関数の計算要件により、証明者のレイテンシが長くなり、証明の生成に 10 秒以上かかります。これは、特にブロック検証のように低レイテンシが求められるシナリオでは大きなデメリットとなります。多次元ガス提案などの取り組みでは、最悪の場合のレイテンシと平均的な場合のレイテンシを一致させようとしていますが、その結果は限られています。さらに、ハッシュベースのアプローチでは同期時間を短縮できますが、その効率は STARK のより広範なスケーラビリティの目標と一致しない可能性があります。従来のハッシュ関数の長い計算時間は、実用的な効率を低下させ、適用範囲を制限します。

   STARK + 比較的新しいハッシュ関数

• STARK を新世代の STARK 対応ハッシュ関数(例: Poseidon) と組み合わせると、このテクノロジーのパフォーマンスが大幅に向上します。これらのハッシュ関数は、STARK システムとシームレスに統合し、証明者の待ち時間を大幅に短縮するように設計されています。従来のハッシュ関数とは異なり、 1～2 秒という短い時間で証明を生成できます。その効率性と計算オーバーヘッドの低さにより、STARK のスケーラビリティの潜在能力が向上し、大規模なデータセットの処理に非常に効果的になります。この機能により、高パフォーマンスを必要とするアプリケーションにとって特に魅力的です。

• しかし、これらのハッシュ関数は比較的新しいため、広範囲にわたるセキュリティ分析とテストが必要です。包括的なテストが不足しているため、Ethereum のような重要なエコシステムへの実装を検討する際にはリスクが生じます。さらに、これらのハッシュ関数はまだ広く採用されていないため、必要なテストと検証プロセスにより、Ethereum の検証可能性の目標が遅れる可能性があります。セキュリティを完全に確保するために必要な時間により、短期的にはこのオプションの魅力が低下し、Ethereum のスケーラビリティと検証可能性の目標が延期される可能性があります。

  格子ベースのマークルツリー

1. 格子ベースの Merkle Tree は、量子セキュリティと Verkle Tree の更新効率を組み合わせた先進的なソリューションを提供します。これらの構造は Verkle Tree と STARK の両方の弱点に対処しており、有望な長期的オプションと考えられています。格子ベースの設計により、量子コンピューティングの脅威に対する強力な耐性を提供し、エコシステムの将来性を確保するという Ethereum の重点と一致しています。さらに、Verkle Tree の更新可能性の利点を維持することで、効率を犠牲にすることなくセキュリティを強化することを目指しています。
2. しかし、格子ベースのマークルツリーの研究はまだ初期段階にあり、大部分が理論的なものです。そのため、実際の実装とパフォーマンスについて大きな不確実性が生じています。このようなソリューションをイーサリアムに統合するには、広範な研究開発と、その潜在的な利点を検証するための厳格なテストが必要になります。これらの不確実性とインフラストラクチャの複雑さにより、格子ベースのマークルツリーは近い将来イーサリアムにとって実現可能な選択肢になる可能性は低く、ネットワークの検証可能性の目標に向けた進歩が遅れる可能性があります。

実行について: EVM実行の有効性証明

これまで説明してきたことはすべて、バリデーターが状態を遷移するために使用する以前の状態を保存する必要性をなくすことを中心に展開しています。目標は、バリデーターがテラバイト単位の状態データを保持せずに職務を遂行できる、より分散化された環境を作成することです。

これまでに述べたソリューションを使用しても、バリデータはブロックに含まれる証人を通じて実行に必要なすべてのデータを受け取るため、状態全体を保存する必要はありません。ただし、次の状態に移行してブロックの上にある stateRoot を検証するには、バリデータは STF 自体を実行する必要があります。この要件は、Ethereum の許可のない性質と分散化に対する別の課題をもたらします。

当初、 The Verge は、状態の検証可能性を向上させるために、Ethereum の状態ツリーをMerkle TreeからVerkle Treeに移行することだけに焦点を当てたマイルストーンとして構想されていました。しかし、時間の経過とともに、状態遷移とコンセンサスの検証可能性を強化することを目的とした、より広範な取り組みに進化しました。状態、実行、コンセンサスの 3 つが完全に検証可能な世界では、Ethereum バリデータは、ライト クライアントとして分類できるインターネット接続を備えたほぼすべてのデバイスで動作できます。これにより、Ethereum は「真の分散化」というビジョンの実現に近づくことになります。

問題の定義とは何でしょうか?

前述のように、バリデータは 12 秒ごとにSTF (状態遷移関数)と呼ばれる関数を実行します。この関数は、前の状態とブロックを入力として受け取り、次の状態を出力として生成します。バリデータは、新しいブロックが提案されるたびにこの関数を実行し、ブロックの上にある状態を表すハッシュ (一般に状態ルートと呼ばれます) が正しいことを確認する必要があります。

バリデーターになるためのシステム要件が高いのは、主にこのプロセスを効率的に実行する必要性から生じます。

スマート冷蔵庫（そう、冷蔵庫であっても）をインストールされたソフトウェアの助けを借りて Ethereum バリデーターに変えたい場合、 2 つの大きな障害に直面します。

1. 冷蔵庫には十分な速度のインターネットがない可能性が高いため、これまで説明した状態の検証可能性ソリューションを使用しても、実行に必要なデータと証明をダウンロードすることはできません。

2. STF に必要なデータにアクセスできたとしても、最初から最後まで実行したり、新しい状態ツリーを構築したりするために必要な計算能力はありません。

   
   

ライト クライアントが前の状態または最後のブロック全体にアクセスできないことによって引き起こされる問題を解決するために、 The Verge は、提案者が実行を実行し、ブロックに証明を添付することを提案しています。この証明には、前の状態ルートから次の状態ルートへの遷移と、ブロックのハッシュが含まれます。これにより、ライト クライアントは、zk 証明を必要とせずに、 3 つの 32 バイトハッシュのみを使用して状態遷移を検証できます。

ただし、この証明はハッシュを通じて機能するため、状態遷移のみを検証すると言うのは誤りです。それどころか、ブロックに添付された証明は複数のものを同時に検証する必要があります。

前のブロックの状態ルート = S、次のブロックの状態ルート = S + 1、ブロックハッシュ = H

1. ブロック自体は有効である必要があり、その中の状態証明（Verkle 証明または STARKs）は、ブロックに付随するデータを正確に検証する必要があります。つまり、ブロックと付随する状態証明の検証です。
2. Hに対応するブロックに含まれる実行に必要なデータを使用して STF を実行すると、状態で変更されるはずのデータが適切に更新される必要があります。つまり、状態遷移の検証です。
3. 正しく更新されたデータを使用して新しい状態ツリーが再構築されると、そのルート値はS + 1と一致する必要があります。つまり、ツリー構築プロセスの検証です。

先ほど言及した証明者と検証者の類推では、一般的に両者の間には計算上のバランスがあると言っても過言ではありません。STF を検証可能にするために必要な証明が複数のものを同時に検証できることは検証者にとって大きな利点となりますが、実行の正確性を保証するためにそのような証明を生成することは証明者にとって比較的困難であることも示しています。Ethereum の現在の速度では、Ethereum ブロックは4 秒未満で証明される必要があります。しかし、現在最も高速な EVM 証明者でも、平均的なブロックを約15 秒で証明することしかできません。[1]

そうは言っても、この大きな課題を克服するために私たちが取ることができる3 つの異なる道があります。

1. 証明と集約の並列化: ZK 証明の大きな利点の 1 つは、集約できることです。複数の証明を 1 つのコンパクトな証明に組み合わせる機能により、処理時間の面で大幅な効率化が実現します。これにより、ネットワークの負荷が軽減されるだけでなく、分散型の方法で検証プロセスが加速されます。Ethereum のような大規模なネットワークでは、各ブロックの証明をより効率的に生成できます。

証明生成中、実行プロセスのあらゆる小さな部分 (計算ステップやデータ アクセスなど) を個別に証明することができ、これらの証明は後で 1 つの構造に集約できます。適切なメカニズムを使用すると、このアプローチにより、ブロックの証明をさまざまなソース (数百の GPU など) によって迅速かつ分散的に生成できます。これによりパフォーマンスが向上すると同時に、より幅広い参加者を巻き込むことで分散化の目標にも貢献します。

2. 最適化された証明システムの使用: 新世代の証明システムは、Ethereum の計算プロセスをより高速かつ効率的にする可能性があります。Orion、 Binius 、 GKRなどの高度なシステムは、汎用計算の証明時間を大幅に短縮できます。これらのシステムは、現在のテクノロジーの限界を克服し、消費リソースを減らしながら処理速度を向上させることを目的としています。Ethereum のようなスケーラビリティと効率性を重視したネットワークでは、このような最適化は大きな利点となります。ただし、これらの新しいシステムを完全に実装するには、エコシステム内での包括的なテストと互換性の取り組みが必要です。
3. ガス コストの変更: 歴史的に、Ethereum Virtual Machine (EVM) での操作のガス コストは、通常、計算コストに基づいて決定されていました。しかし、今日では、別の指標が重要になっています。それは、証明者の複雑さです。一部の操作は比較的簡単に証明できますが、他の操作は構造が複雑で、検証に時間がかかります。計算量だけでなく、操作の証明の難しさに基づいてガス コストを調整することは、ネットワークのセキュリティと効率の両方を向上させるために重要です。

このアプローチにより、最悪のシナリオと平均的なシナリオのギャップを最小限に抑え、より一貫したパフォーマンスを実現できます。たとえば、証明が難しい操作ではガスコストが高くなり、証明が容易な操作ではガスコストが低くなる可能性があります。さらに、Ethereum のデータ構造 (状態ツリーやトランザクション リストなど) をSTARK 対応の代替構造に置き換えると、証明プロセスがさらに加速される可能性があります。このような変更により、Ethereum はスケーラビリティとセキュリティの目標を達成し、検証可能性のビジョンをより現実的なものにすることができます。

実行証明を可能にする Ethereum の取り組みは、検証可能性の目標を達成する大きなチャンスを表しています。ただし、この目標を達成するには、技術革新だけでなく、エンジニアリングの取り組みの強化とコミュニティ内での重要な決定も必要です。レイヤー 1 で実行プロセスを検証可能にするには、分散化を維持しながら幅広いユーザー ベースにアクセスできるようにし、既存のインフラストラクチャと整合させるというバランスを取る必要があります。

このバランスを確立すると、実行中に操作を証明するために使用される方法の複雑さが増し、並列証明生成などの進歩の必要性が浮き彫りになります。さらに、これらのテクノロジのインフラストラクチャ要件（ルックアップテーブルなど）を実装して運用化する必要があり、依然としてかなりの研究開発が必要です。

一方、特定のタスク専用に設計された専用回路(ASIC、FPGA、GPU など) は、証明生成プロセスを高速化する大きな可能性を秘めています。これらのソリューションは、従来のハードウェアに比べてはるかに高い効率性を提供し、実行プロセスを高速化できます。

しかし、イーサリアムのレイヤー 1 レベルでの分散化の目標により、このようなハードウェアは特定のアクターのグループのみがアクセスできるようにはなりません。その結果、これらのソリューションはレイヤー 2 システムでより広範囲に使用されることが予想されます。ただし、コミュニティは証明生成のハードウェア要件についても合意に達する必要があります。

重要な設計上の疑問が浮かび上がります。証明生成は、ハイエンド ラップトップのような消費者向けハードウェアで機能するべきでしょうか、それとも産業用インフラストラクチャを必要とするべきでしょうか。その答えが Ethereum のアーキテクチャ全体を形作ります。レイヤー 2 ソリューションに対して積極的な最適化を可能にしながら、レイヤー 1 に対してはより保守的なアプローチを要求します。

最後に、実行証明の実装は、イーサリアムの他のロードマップの目標に直接結びついています。有効性証明の導入は、ステートレス性などの概念をサポートするだけでなく、ソロステーキングなどの領域へのアクセスを容易にすることで、イーサリアムの分散化を強化します。目標は、最も低スペックのデバイスでもステーキングを可能にすることです。さらに、計算の難しさや証明可能性に基づいて EVM のガスコストを再構築することで、平均的なケースと最悪のケースのシナリオのギャップを最小限に抑えることができます。

ただし、このような変更により、現在のシステムとの下位互換性が失われ、開発者はコードの書き直しを余儀なくされる可能性があります。このため、実行証明の実装は単なる技術的な課題ではなく、Ethereum の長期的な価値を維持するために設計する必要がある旅なのです。

真の完全検証可能性のための最後のステップ：コンセンサス

Ethereum のコンセンサス メカニズムは、検証可能性の目標を達成しながら、分散化とアクセス性を維持する独自のバランスを確立することを目指しています。このフレームワークでは、確率的コンセンサス方式と決定論的コンセンサス方式には、それぞれ異なる利点と課題があります。

確率的コンセンサスは、ゴシップ通信モデルに基づいて構築されます。このモデルでは、ネットワークを代表するすべてのノードと直接通信する代わりに、ノードはランダムに選択された 64 または 128 のノードのセットと情報を共有します。ノードのチェーン選択はこの限られた情報に基づいて行われるため、エラーが発生する可能性があります。ただし、時間の経過とともにブロックチェーンが進化するにつれて、これらの選択は 0% のエラー率で正しいチェーンに収束することが期待されます。

確率的構造の利点の 1 つは、各ノードがチェーン ビューを個別のメッセージとしてブロードキャストしないため、通信のオーバーヘッドが削減されることです。その結果、このような構造では、システム要件が低い、はるかに多くの許可のない分散ノードで動作できます。

対照的に、決定論的コンセンサスは、1対全の通信モデルを通じて機能します。ここでは、ノードがチェーンビューを投票として他のすべてのノードに送信します。このアプローチでは、メッセージの強度が高くなり、ノードの数が増えると、システムが最終的に限界に達する可能性があります。

しかし、決定論的コンセンサスの最大の利点は、具体的な投票が利用できることです。これにより、どのノードがどのフォークに投票したかを正確に知ることができます。これにより、チェーンの高速かつ確実なファイナリティが保証され、ブロックの順序が変更されないことが保証され、ブロックが検証可能になります。

分散化と許可のない構造を維持しながら検証可能なコンセンサス メカニズムを提供するために、Ethereum はスロットとエポックのバランスをとっています。12 秒間隔を表すスロットは、バリデータがブロックを生成する基本単位です。スロット レベルで使用される確率的コンセンサスにより、チェーンはより柔軟かつ分散的に動作できますが、明確な順序付けと検証可能性の点で制限があります。

32 スロットを含むエポックは、決定論的コンセンサスを導入します。このレベルでは、バリデーターがチェーンの順序を確定するために投票し、確実性を確保してチェーンを検証可能にします。ただし、この決定論的構造はエポック レベルでの具体的な投票を通じて検証可能性を提供しますが、確率的構造のため、エポック自体内で完全な検証可能性を提供することはできません。このギャップに対処し、エポック内の確率的構造を強化するために、Ethereum は Sync Committee と呼ばれるソリューションを開発しました。

Altair の軽量クライアント プロトコル: 同期委員会

Sync Committee は、Altair アップグレードで導入されたメカニズムで、Ethereum の確率的コンセンサスの制限を克服し、軽量クライアントのチェーンの検証可能性を向上させます。この委員会は、ランダムに選択された 512 のバリデーターで構成され、256 エポック (約 27 時間) にわたって機能します。これらのバリデーターはチェーンの先頭を表す署名を生成し、軽量クライアントがチェーンの履歴データをダウンロードしなくてもチェーンの有効性を検証できるようにします。Sync Committee の動作は、次のように要約できます。

1. 委員会の構成: ネットワーク内のすべてのバリデーターから 512 人のバリデーターがランダムに選択されます。この選択は、分散化を維持し、特定のグループへの依存を防ぐために定期的に更新されます。
2. 署名生成: 委員会メンバーは、チェーンの最新の状態を表す署名を生成します。この署名は、メンバーによって作成された集合的な BLS 署名であり、チェーンの有効性を検証するために使用されます。
3. ライト クライアント検証: ライト クライアントは、同期委員会からの署名を確認するだけでチェーンの正確性を検証できます。これにより、過去のチェーン データをダウンロードすることなく、チェーンを安全に追跡できます。

しかし、Sync Committee はいくつかの分野で批判を受けています。特に、このプロトコルには、選ばれたバリデータが意図的にプロトコルに反する行動をとったとしても、悪意のある行動に対してバリデーターを排除するメカニズムがありません。その結果、多くの人が Sync Committee をセキュリティ上のリスクと見なし、完全にライト クライアント プロトコルとして分類することを控えています。とはいえ、Sync Committee のセキュリティは数学的に証明されており、詳細については、 Sync Committee Slashings に関するこの記事をご覧ください。

プロトコルにスラッシング メカニズムがないのは設計上の選択ではなく、確率的コンセンサスの性質から生じる必然性です。確率的コンセンサスは、バリデーターが観察するものについて絶対的な保証を提供しません。バリデーターの大多数が特定のフォークを重いフォークとして報告したとしても、例外的なバリデーターが別のフォークを重いフォークとして観察する可能性があります。この不確実性により、悪意を証明することが困難になり、不正行為を罰することが不可能になります。

この文脈では、Sync Committee を安全でないと決めつけるのではなく、非効率的なソリューションと表現する方が正確でしょう。この問題は、Sync Committee の機械的な設計や操作から生じるのではなく、確率的コンセンサスの本質から生じます。確率的コンセンサスはノードが何を観察するかについて明確な保証を提供できないため、Sync Committee はそのようなモデル内で設計できる最良のソリューションの 1 つです。ただし、これによって、チェーンのファイナリティを保証する確率的コンセンサスの弱点が解消されるわけではありません。問題はメカニズムではなく、Ethereum の現在のコンセンサス構造にあります。

これらの制限のため、イーサリアム エコシステムでは、コンセンサス メカニズムを再設計し、より短い期間で確定的な最終性を提供するソリューションを実装する取り組みが進行中です。Orbit -SSFや3SFなどの提案は、イーサリアムのコンセンサス構造を根本から作り直し、確率的コンセンサスに代わるより効果的なシステムを構築することを目的としています。このようなアプローチは、チェーンの最終時間を短縮するだけでなく、より効率的で検証可能なネットワーク構造を提供することを目指しています。イーサリアム コミュニティは、将来の実装に向けてこれらの提案を積極的に開発し、準備し続けています。

コンセンサスの皮肉化

The Verge は、Ethereum の現在および将来のコンセンサス メカニズムを完全に置き換えるのではなく、zk プルーフ テクノロジーを通じて検証可能性を高めて強化することを目指しています。このアプローチは、分散化とセキュリティという基本原則を維持しながら、Ethereum のコンセンサス プロセスを近代化することを目指しています。チェーンの過去および現在のすべてのコンセンサス プロセスを zk テクノロジーで最適化することは、Ethereum の長期的なスケーラビリティと効率性の目標を達成する上で重要な役割を果たします。Ethereum のコンセンサス レイヤーで使用される基本的な操作は、この技術変革において非常に重要です。これらの操作とそれらが直面する課題を詳しく見てみましょう。

• ECADD :
• 目的: この操作はバリデーターの公開鍵を集約するために使用され、チェーンの正確性と効率性を確保するために不可欠です。BLS 署名の集約可能な性質により、複数の署名を 1 つの構造に組み合わせることができます。これにより、通信オーバーヘッドが削減され、チェーン上の検証プロセスがより効率的になります。大規模なバリデーター グループ間の同期をより効果的に確保するために、この操作は非常に重要です。
• 課題: 前述のように、Ethereum のバリデータはエポック中にチェーンの順序に投票します。現在、Ethereum は約110 万のバリデータを持つネットワークです。すべてのバリデータが同時に投票を伝播しようとすると、ネットワークに大きな負担がかかります。これを回避するため、Ethereum ではエポック中にバリデータがスロット ベースで投票できるようにしており、スロットごとにバリデータ全体の1/32のみが投票します。このメカニズムによりネットワーク通信のオーバーヘッドが削減され、コンセンサスがより効率的になりますが、現在のバリデータ数では、約34,000 のバリデータが各スロットに投票します。これは、スロットあたり約 34,000 の ECADD 操作に相当します。
• ペアリング:
• 目的: ペアリング操作はBLS 署名の検証に使用され、チェーン上のエポックの有効性を保証します。この操作により、署名のバッチ検証が可能になります。ただし、これはzk フレンドリーではないため、zk 証明技術を使用して証明するには非常にコストがかかります。これは、ゼロ知識技術を使用した統合検証プロセスを作成する上で大きな課題となります。
• 課題：イーサリアムのペアリング操作は、スロットあたり最大128の証明（集約署名）に制限されているため、ECADDと比較してペアリング操作が少なくなります。ただし、これらの操作はzkフレンドリーではないため、大きな課題があります。zk証明を使用してペアリング操作を証明することは、ECADD操作を証明するよりも数千倍コストがかかります[2]。これにより、ペアリング操作をゼロ知識技術に適応させることは、イーサリアムのコンセンサス検証プロセスにおける最大の障害の1つになります。
• SHA256ハッシュ:
• 目的: SHA256 ハッシュ関数は、チェーンの状態を読み取って更新し、チェーンのデータの整合性を保証するために使用されます。ただし、zk フレンドリーではないため、zk 証明ベースの検証プロセスが非効率になり、Ethereum の将来の検証可能性の目標に大きな障害となります。
• 課題: SHA256 ハッシュ関数は、チェーンの状態の読み取りと更新に頻繁に使用されます。ただし、zk との相性の悪さが、Ethereum の zk 証明ベースの検証目標と矛盾します。たとえば、2 つのエポック間で、各バリデータは Ethereum のコンセンサス レイヤーの STF を実行し、エポック中のバリデータのパフォーマンスに基づいて報酬とペナルティで状態を更新します。このプロセスは SHA256 ハッシュ関数に大きく依存しており、zk 証明ベースのシステムのコストが大幅に増加します。これにより、Ethereum のコンセンサス メカニズムを zk テクノロジーと連携させる上で大きな障壁が生じます。

現在のコンセンサス レイヤーで使用されている ECADD、ペアリング、および SHA256 操作は、Ethereum の検証可能性の目標において重要な役割を果たします。ただし、これらの操作は zk フレンドリーではないため、これらの目標を達成する上で大きな課題が生じます。ECADD 操作は、バリデーターの投票数が多いためコストの負担が大きく、ペアリング操作は数が少ないにもかかわらず、zk 証明で証明するには数千倍のコストがかかります。

さらに、SHA256 ハッシュ関数はゼロ知識に不向きであるため、ビーコン チェーンの状態遷移を証明することが非常に困難です。これらの問題は、Ethereum の既存のインフラストラクチャをゼロ知識テクノロジーに合わせるための包括的な変革の必要性を浮き彫りにしています。

ソリューション「ビームチェーン」：イーサリアムのコンセンサス層を再考する

2024年11月12日、Devconでのプレゼンテーションで、ジャスティン・ドレイクは、イーサリアムのコンセンサスレイヤーを根本的かつ包括的に変革することを目的とした「ビームチェーン」と呼ばれる提案を発表しました。ビーコンチェーンは、イーサリアムのネットワークの中核として5年近くにわたって機能してきました。しかし、この期間中、ビーコンチェーンに大きな構造的変化はありませんでした。対照的に、技術の進歩は急速に進み、ビーコンチェーンの静的な性質をはるかに超えています。

ジャスティン・ドレイク氏はプレゼンテーションで、イーサリアムは過去5年間で、 MEVの理解、 SNARK技術の飛躍的進歩、技術的ミスの回顧的認識など、重要な分野で重要な教訓を学んだと強調しました。これらの新しい学習に基づいた設計は、ブロック生成、ステーキング、暗号化の3つの主要な柱に分類されます。次の図は、これらの設計と提案されたロードマップをまとめたものです。

• 緑色と灰色のボックスは、毎年 1 つずつ実装できる段階的な開発を表しています。これらのタイプの改善は、以前のアップグレードと同様に、Ethereum の既存のアーキテクチャを混乱させることなく段階的に統合できます。

• 一方、赤いボックスは、一緒に実装する必要がある、高い相乗効果と大規模な基礎的な変更を意味します。ドレイク氏によると、これらの変更は、イーサリアムの容量と検証可能性を一度に向上させることを目的としているとのことです。

  
  

このセクションでは、The Verge のコンセンサス、状態、実行の各ステップを詳細に検討しましたが、このプロセスで強調された最も顕著な問題の 1 つは、Ethereum のビーコン チェーンでのSHA256 ハッシュ関数の使用です。SHA256 はネットワークのセキュリティを確保し、トランザクションを処理する上で中心的な役割を果たしますが、zk フレンドリーではないため、Ethereum の検証可能性の目標を達成する上で大きな障害となっています。計算コストが高く、zk テクノロジと互換性がないため、これは Ethereum の将来の開発で対処しなければならない重要な問題です。

Devcon での講演で発表された Justin Drake 氏のロードマップでは、Beacon Chain の SHA256 をPoseidonなどの zk 対応ハッシュ関数に置き換えることを想定しています。この提案は、Ethereum のコンセンサス レイヤーを最新化し、検証可能性と効率性を高め、zk 対応テクノロジーと連携させることを目指しています。

この文脈では、イーサリアムはzk非対応のハッシュ関数の課題に直面しているだけでなく、長期的なセキュリティのためにコンセンサス層で使用されるデジタル署名を再評価する必要があることがわかります。量子コンピューティングの進歩により、現在使用されているECDSAなどのデジタル署名アルゴリズムは重大な脅威に直面する可能性があります。NISTが発行したガイドラインに記載されているように、 112ビットのセキュリティレベルのECDSAのバリアントは2030年までに廃止され、2035年までに完全に禁止されます。これにより、イーサリアムや同様のネットワークは、将来的に量子セキュア署名などのより回復力のある代替手段に移行する必要があります。

この時点で、ハッシュベースの署名は、ネットワークのセキュリティと検証可能性の目標をサポートする上で重要な役割を果たす可能性のある量子耐性ソリューションとして登場しました。このニーズに対処することで、ビーコンチェーンを検証可能にするための2番目の大きな障害であるBLS署名も取り除かれます。イーサリアムが量子セキュリティを確保するために取ることができる最も重要なステップの1つは、ハッシュベースの署名やハッシュベースのSNARKなどのポスト量子ソリューションを採用することです。

Justin Drake 氏がDevcon のプレゼンテーションで強調したように、ハッシュ関数は原像解析耐性に依存しているため量子コンピューターに対して本質的に耐性があり、現代の暗号の基本的な構成要素の 1 つとなっています。この特性により、量子コンピューターであっても、特定のハッシュから元の入力を効率的にリバース エンジニアリングすることができず、セキュリティが維持されます。

ハッシュベースの署名システムにより、検証者と証明者はハッシュ関数のみに基づいて署名を生成できるため、量子コンピュータセキュリティが確保されると同時に、ネットワーク全体でより高いレベルの検証可能性が提供されます (特に SNARK 対応ハッシュ関数が使用されている場合)。このアプローチは、ネットワークのセキュリティを強化するだけでなく、Ethereum の長期的なセキュリティ インフラストラクチャをより堅牢で将来性のあるものにします。

このシステムは、ハッシュベースの署名とハッシュベースの SNARK (STARK のような証明) を組み合わせて、集約可能な署名スキームを作成します。集約可能な署名は、数千の署名を 1 つの構造に圧縮し、証明をわずか数百キロバイトに減らします。この圧縮により、ネットワーク上のデータ負荷が大幅に軽減され、検証プロセスが大幅に加速されます。たとえば、Ethereum の 1 つのスロット用に生成された数千の検証署名は、1 つの集約署名で表すことができるため、ストレージ スペースと計算能力の両方を節約できます。

しかし、この方式の最も注目すべき特徴は、無限に再帰的に集約できることです。つまり、1 つの署名グループをさらに別のグループに統合することができ、このプロセスはチェーン全体で継続できます。このメカニズムと将来の技術進歩を考慮すると、これは現在 BLS では実現できない可能性への扉を開くと言っても過言ではありません。

結論

Ethereum の検証可能性への道は、ブロックチェーン技術の根本的な変化を表しています。Verge イニシアチブは、状態検証のための Verkle Trees とスケーラブルな遷移のための STARK 証明を通じて、コアの非効率性に対処します。

最も野心的な提案の 1 つは、Ethereum のコンセンサス レイヤーを包括的に再設計したBeam Chainです。このアプローチは、 Beacon Chainの制限に対処し、zk に適した代替手段を組み込むことで、分散化とアクセシビリティという中核原則を維持しながら、Ethereum のスケーラビリティを強化することを目指しています。ただし、この移行により、Ethereum がコンピューティングの要求と、許可のない包括的なネットワークを維持するという目標のバランスを取る上で直面する課題も浮き彫りになっています。

NIST は 2035 年までに現在の楕円曲線暗号を段階的に廃止する予定であるため、Ethereum はハッシュベースの署名や Poseidon などの量子耐性ソリューションを採用する必要があります。これらのソリューションには、独自の効率性のトレードオフがあります。

イーサリアムのロードマップにおけるSTARKの使用は、スケーラビリティと検証可能性をさらに重視しています。STARK は透明性と量子耐性のある証明を提供する点で優れていますが、その統合により、証明者側の計算コストと小規模データの非効率性に関連する課題が生じます。これらのハードルは、ステートレスと効率的なブロック検証というイーサリアムのビジョンを完全に実現し、需要の増加に直面してもネットワークが堅牢であり続けるようにするために解決する必要があります。

これらの進歩にもかかわらず、重要な課題は残っています。イーサリアムは、 zk フレンドリ性、コンセンサス スケーラビリティ、量子耐性暗号の統合の複雑さなどの問題を解決する必要があります。さらに、既存のインフラストラクチャの下位互換性は実用的なハードルをもたらし、開発者とユーザーの両方に混乱が生じないように注意深いエンジニアリング ソリューションを必要とします。

Ethereum が他と一線を画しているのは、その技術革新だけでなく、ブロックチェーンの最も難しい問題のいくつかを解決するための反復的なアプローチです。Beam Chain 、 Verkle Trees 、 STARK 証明などの技術を通じて前進する道は、開発者、研究者、そしてより広範なコミュニティによる共同作業にかかっています。これらの進歩は、一夜にして完璧を達成することではなく、透明性、分散性、検証可能なインターネットの基盤を構築することです。

Ethereum の進化は、Web3 時代を形成する上で重要な役割を担っていることを強調しています。実用的なソリューションで今日の課題に取り組むことで、Ethereum は検証可能性、量子耐性、スケーラビリティが例外ではなく標準となる未来に近づいています。