検証可能性への道

Web3の最大の利点は検証可能性です-ユーザーはシステムが実際にどのように動作するかを検証できます。この機能により、多くの人々が暗号通貨業界内外でweb3をより透明で検証可能なインターネットへの一歩として説明しています。

FacebookやInstagramのようなWeb2プラットフォームでは、アルゴリズムやルールが文書化されていても不透明なままであるのに対し、暗号プロトコルは完全に監査可能に設計されています。それらが共有されていたとしても、プラットフォームが指定されたとおりに動作しているかどうかを検証することができません。これは、暗号とは正反対であり、すべてのプロトコルができるだけ監査可能に設計されているか、少なくともそのように期待されていることを意味しています。

今日は、最近公開されたヴィタリックのセクション「The Verge」を探求しますイーサリアムの将来に関する6部作シリーズ, Ethereumが将来的に検証可能性、持続可能性、およびスケーラビリティを実現するために取る手順を分析すること。 「The Verge」の見出しの下で、ブロックチェーンアーキテクチャをより検証可能にする方法、これらの変更がプロトコルレベルでもたらす革新、およびユーザーにより安全なエコシステムを提供する方法について議論します。さあ始めましょう!

「検証可能性」とは何を意味しますか？

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

「できるだけ分散化し、残りを検証します。」

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

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

ブロックチェーンは実質的にグローバルなクロックとして機能します。約10,000台のコンピュータから成る分散ネットワークでは、トランザクションが起点ノードから他の全ノードに伝播するのにかなりの時間がかかる場合があります。そのため、ネットワーク全体のノードは、各ノードが独自の主観的な視点しか持っていないため、トランザクションの正確な順序を決定することはできません。つまり、トランザクションが他のトランザクションの前に到着したのか、それとも後に到着したのかを判別することはできません。

取引の順序が重要なため、ブロックチェーンネットワークは「スペシャライズドな方法」と呼ばれる専門の方法を使用しています。コンセンサスアルゴリズムノードが同期し、トランザクションの順序を同じに処理するためには、ネットワーク全体で取引の順序を決定することはできませんが、合意メカニズムによりすべてのノードが同じ順序で合意することができます。これにより、ネットワークは一つの統合されたコンピュータとして機能します。

コンセンサス層を超えて、すべてのブロックチェーンに存在する実行層もあります。実行層は、ユーザーが実行したいトランザクションによって形作られています。

トランザクションがコンセンサスによって正常に順序付けられた後、各トランザクションは実行レイヤーの現在の状態に適用される必要があります。もし「状態とは何か？」と疑問に思っているならば、おそらくブロックチェーンがデータベースと比較されることを見たことがあるかもしれません。具体的には、銀行のデータベースに似ていることで、ブロックチェーンは銀行と同様に、全員の残高の記録を維持しています。

もし、「S」と呼ばれる状態に$100を持っていて、他の誰かに$10を送りたい場合、次の状態「S+1」での残高は$90になります。1つの状態から別の状態に移動するための取引を適用するプロセスを、私たちはSTF（State Transition Function）と呼んでいます。

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

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

1. ステート：ブロックチェーン上のデータの一部を読み取りたい場合でも、ステートにアクセスできない場合は、実行していないためです。フルノード. そのため、AlchemyやInfuraのようなRPC（リモート手続き呼び出し）プロバイダーを介してデータを要求する必要があります。ただし、RPCプロバイダーによるデータの改ざんが行われていないことを確認する必要があります。
2. 実行：前述のように、ブロックチェーンはSTFを利用しています。トランザクション単位ではなく、ブロック単位で状態遷移が正しく実行されたことを確認する必要があります。
3. コンセンサス：RPCのような第三者エンティティは、ブロックチェーンにまだ含まれていない有効なブロックを提供することができます。したがって、これらのブロックがコンセンサスによって受け入れられ、ブロックチェーンに追加されたことを確認する必要があります。

これがわかりにくいまたは不明確に見える場合は心配しないでください。これらの側面をそれぞれ詳しく説明します。まずはブロックチェーンの状態を検証する方法から始めましょう！

ブロックチェーンの状態を確認する方法はありますか？

イーサリアムの“状態”とは、ブロックチェーンにおけるあらゆる時点でのデータセットを指します。これには、口座の残高（コントラクト口座と外部所有口座、またはEOA）、スマートコントラクトコード、コントラクトのストレージなどが含まれます。イーサリアムは状態ベースのマシンであり、イーサリアム仮想マシン（EVM）で処理されるトランザクションが以前の状態を変更し、新しい状態を生み出します。

各Ethereumブロックには、そのブロックの後のネットワークの現在の状態を要約する値であるstateRootが含まれています。この値は、64文字のハッシュで構成されるEthereumの全体的な状態の簡潔な表現です。

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

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

1. 決定論：同じ入力は常に同じ出力を生成します。
2. 固定の出力長さ：入力の長さに関係なく、出力の長さは常に固定されています。
3. 一方向の特性：出力から元の入力を実質的に導出することはほとんど不可能です。
4. 独自性：入力のわずかな変更でも完全に異なる出力が生成されます。したがって、特定の入力は実質的に一意の出力にマップされます。

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

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

イーサリアムの状態はテラバイトのサイズであるため、電話やパーソナルコンピュータなどの日常的なデバイスに完全な状態を保存することは現実的ではありません。そのため、イーサリアムはMerkleツリー構造を使用してstateRootを計算し、状態の検証可能性をできるだけ保持しています。

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

1. Leaf nodes: These nodes contain the hashes of individual data pieces and are located at the bottom level of the tree. Each leaf node represents the hash of a specific piece of data in the Merkle tree.
2. ブランチノード：これらのノードには、子ノードの結合ハッシュが含まれています。たとえば、バイナリMerkleツリー（N=2の場合）、2つの子ノードのハッシュが連結され、再びハッシュされて、より高いレベルのブランチノードのハッシュが生成されます。
3. ルートノード：ルートノードは、Merkleツリーの最上位レベルにあり、全体のツリーの暗号化要約を表します。このノードは、ツリー内のすべてのデータの完全性と正確性を検証するために使用されます。

そのような木を構築する方法が気になる場合は、たった2つの簡単な手順が関与しています。

• 葉ノードの作成：データの各部分はハッシュ関数を通じて処理され、その結果のハッシュが葉ノードを形成します。これらのノードは、木の最も低いレベルに位置し、データの暗号化された要約を表します。

• 結合とハッシュ：葉ノードのハッシュはグループ化され（例：ペアで）、組み合わされ、その後ハッシュ化されます。このプロセスにより、次のレベルに枝ノードが作成されます。同じプロセスが枝ノードに対して繰り返され、最後には単一のハッシュのみが残ります。

木の頂上で得られた最終ハッシュはMerkleルートと呼ばれます。Merkleルートは全体の木の暗号的要約を表し、データの整合性を安全に検証することができます。

Merkleルートを使用してEthereumの状態を検証する方法は？

マークル証明は、特定のデータを効率的に検証するために、ブロックヘッダーに格納されているマークルルートへのパスを作成するハッシュ値のシリーズを提供することによって、検証者がデータの正当性を確認するための中間ハッシュ値の連鎖を提供します（葉ノード）。この中間ハッシュ値の連鎖により、検証者は全体の状態をハッシュ化する必要なく、データの真正性を確認できます。

特定のデータポイントから始めて、検証者はそれをマークルプルーフで提供された各“兄弟”ハッシュと組み合わせ、木の上に段階的にハッシュを行います。このプロセスは単一のハッシュが生成されるまで続きます。この計算されたハッシュが格納されているマークルルートと一致する場合、データは有効と見なされます。そうでない場合、検証者はデータが主張されている状態に対応していないと判断できます。

例: Merkle 証明を使ってデータポイントを検証する

RPCからデータ＃4を受け取り、メルクルプルーフを使用してその正当性を検証したいとしましょう。これを行うには、RPCはメルクルルートに到達するために必要なパスに沿ってハッシュ値のセットを提供します。データ4の場合、これらの兄弟ハッシュにはハッシュ＃3、ハッシュ＃12、およびハッシュ＃5678が含まれます。

1. データ4から始めます: ますます、ハッシュデータ#4を取得します。
2. 兄弟と結合する: 次に、Hash #4をHash #3（葉のレベルでの兄弟）と結合し、一緒にハッシュしてHash #34を生成します。
3. ツリーを上に移動します。次に、ハッシュ＃34を取り、上の次のレベルにある兄弟であるハッシュ＃12と組み合わせてハッシュ化し、ハッシュ＃1234を取得します。
4. 最終ステップ: 最終的に、ハッシュ＃1234とハッシュ＃5678（最後に提供された兄弟）を組み合わせて一緒にハッシュします。生成されたハッシュは、ブロックヘッダーに格納されているMerkle Root（ハッシュ＃12345678）と一致するはずです。

計算されたMerkle Rootがブロック内の状態ルートと一致する場合、データ＃4がこの状態内で確かに有効であることを確認します。一致しない場合、データが主張された状態に属していないことを示し、潜在的な改ざんを示します。見ての通り、すべてのデータのハッシュを提供することなく、またはVerifierに完全なMerkle Treeを再構築することを要求することなく、Proverはデータ＃4が状態に存在し、その旅の間に変更されていないことを証明することができます-たった3つのハッシュを使用して。これがMerkle Proofが効率的とされる主な理由です。

メルクルツリーは、イーサリアムのような大規模なブロックチェーンシステムにおいて、確実で効率的なデータ検証を提供することは間違いありませんが、それでも十分に効率的でしょうか？ これに答えるためには、メルクルツリーのパフォーマンスとサイズがプロバーバーの関係にどのような影響を与えるかを分析する必要があります。

マークルツリーパフォーマンスに影響を与える2つの主要要因：⌛

1. 分岐係数：1つの枝ごとの子ノードの数。
2. データの合計サイズ: ツリーで表されるデータセットのサイズ。

分岐因子の効果：

その影響をよりよく理解するために、例を使って説明しましょう。枝分かれ係数は、木の各ノードから出てくる枝の数を決定します。

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

Total Data Sizeの効果:

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

• フルノードは、メルクルツリーを維持するために成長するデータセットを定期的に処理および更新する必要があります。
• データセットが成長するにつれて、検証者はより長く、より複雑な証明を検証する必要があり、追加の処理時間と帯域幅が必要です。
  この増加するデータサイズは、フルノードと検証者の両方に需要を増加させ、効率的にネットワークをスケーリングすることを難しくしています。

要約すると、マークルツリーは効率性を提供しますが、イーサリアムのデータセットの持続的な成長に対する最適な解決策には及びません。この理由から、The Vergeフェーズ中に、イーサリアムはより効率的な構造である「ゲート」でマークルツリーを置き換えることを目指しています。Verkle Trees. Verkle Treesは、証明のサイズを小さくする可能性がありますが、同じレベルのセキュリティを維持しながら、検証プロセスをProverとVerifierの両方にとって持続可能でスケーラブルにすることができます。

Chapter 2: イーサリアムでの検証性の革命 - The Verge

Vergeは、検証性を向上させ、ブロックチェーンの分散構造を強化し、ネットワークのセキュリティを高めることを目的としたEthereumのロードマップのマイルストーンとして開発されました。 Ethereumネットワークの主要な目標の1つは、誰でも簡単にバリデータを実行してチェーンを検証できるようにすることで、参加が中心化せずに誰でも開かれた構造を作成することです。この検証プロセスのアクセシビリティは、ブロックチェーンを中央集権的なシステムと区別する主要な特徴の1つです。中央集権的なシステムでは検証機能を提供しないため、ブロックチェーンの正確性は完全にユーザーの手に委ねられます。しかし、この保証を維持するには、バリデータを誰でもアクセスできるようにする必要があります。現在のシステムでは、ストレージと計算要件の制限により、この課題に対処することができません。

The Mergeを使用したProof-of-Stakeのコンセンサスモデルに移行して以来、イーサリアムのバリデータは2つの主な責任を持っています:

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

第2の責任を果たすために、バリデータはブロックの前の状態にアクセスする必要があります。これにより、彼らはブロックのトランザクションを実行し、その後の状態を導くことができます。ただし、この要件はバリデータに重い負担を課しており、彼らは大量のストレージ要件を扱う必要があります。イーサリアムは実現可能であり、ストレージコストも世界的に低下してきていますが、問題はコストではなく、バリデータ向けの特殊なハードウェアへの依存性にあります。Vergeは、モバイル電話やブラウザウォレット、さらにはスマートウォッチなどのストレージが制限されたデバイスでも完全な検証が行えるインフラストラクチャを作成することで、この課題を克服することを目指しています。これにより、バリデータはこれらのデバイス上で実行することができます。

検証の最初のステップ：ステート

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

Vitalikによる計算によると、平均的な証明サイズは約4 KBで、管理可能な範囲内に収まっていると思われます。しかし、最悪の場合、証明サイズは330 MBに膨らむことがあります。はい、あなたが正しく読んだ通り-330 MBです。

最悪の場合におけるEthereumのMerkle Treesの極端な非効率性は、2つの主な理由によるものです:

1. Hexaryツリーの使用: Ethereumは現在、枝分かれ数が16のMerkleツリーを使用しています。これは、単一のノードを検証するには、分岐内の残りの15つのハッシュを提供する必要があることを意味します。Ethereumの状態のサイズと枝の数を考慮すると、最悪の場合にはかなりの負担が生じます。

1. コードの非メルケリゼーション：契約コードを木構造に組み込む代わりに、Ethereumは単純にコードをハッシュ化し、その結果の値をノードとして使用します。契約の最大サイズが24 KBであることを考慮すると、このアプローチは完全な検証を実現するためにかなりの負担を強いています。

証明書のサイズは、分岐係数に比例します。分岐係数を減らすと、証明書のサイズが小さくなります。これらの問題に対処し、最悪のシナリオを改善するために、イーサリアムはヘキサリーツリーからバイナリーマークルツリーに切り替え、コントラクトコードをマークル化することができます。イーサリアムの分岐係数が16から2に減少し、コントラクトコードもマークル化された場合、最大証明書サイズは10 MBに縮小できます。これは重要な改善ですが、このコストは1つのデータを検証するために適用されることに注意することが重要です。単純なトランザクションで複数のデータにアクセスする場合、より大きな証明書が必要になります。ブロックあたりのトランザクション数とイーサリアムの継続的な成長状況を考慮すると、この解決策は改善されましたが、まだ完全に実現可能ではありません。

これらの理由から、Ethereumコミュニティは問題に対処するために2つの異なる解決策を提案しています:

1. Verkle Trees
2. STARK証明+バイナリMerkle木

Verkle Trees & Vector Commitments

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

これに対し、Verkle Treesは、「楕円曲線ベースのベクトルコミットメント」として知られる専門の構造を利用しています。より具体的には、内積引数（IPA）ベースのベクトルコミットメントです。ベクトルとは、基本的に特定の順序で整理されたデータ要素のリストです。 Ethereumの状態は、ベクトルと考えることができます。つまり、多数のデータ要素が特定の順序で格納されており、各要素が重要である構造です。この状態には、アドレス、契約コード、およびストレージ情報など、さまざまなデータコンポーネントが含まれており、これらの要素の順序がアクセスと検証に重要な役割を果たしています。

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

マークルツリーとは異なり、Verkleツリーは楕円曲線ベースのベクトルコミットメントを使用し、2つの主要な利点を提供します:

• 楕円曲線ベクトルコミットメントにより、検証されるデータ以外の要素の詳細を必要としなくなります。分岐係数が16のMerkle Treeでは、単一のブランチを検証するには他の15つのハッシュを提供する必要があります。Ethereumの状態が非常に大きいため、多くのブランチが関係しており、これにより著しい非効率性が生じます。しかしながら、楕円曲線ベクトルコミットメントにより、このような複雑さが解消され、より少ないデータと計算努力で検証が可能になります。
• マルチプルーフを通じて、楕円曲線ベースのベクトルコミットメントによって生成されたプルーフを単一の一定サイズのプルーフに圧縮することができます。 Ethereumの状態は大きいだけでなく、絶えず成長しており、つまり、Merkle Rootにアクセスするために検証が必要なブランチの数が時間とともに増加しています。 ただし、Verkle Treesを使用すると、「」で詳細に説明されている方法を使用して、各ブランチのプルーフを単一の一定サイズのプルーフに「圧縮」することができます。Dankrad Feist’s articleこれにより、検証者は、個々の枝を個別に検証するのではなく、1つの小さな証明で全体のツリーを検証できます。これはまた、Verkle TreesがEthereumのステートの成長に影響されないことを意味します。

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

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

このため、Verkle Treesは無状態への有望な解決策を提供していますが、それが究極の修正ではないことに注意が必要です。ただし、Dankrad Feistなどの人物は、量子耐性暗号をEthereumに統合する際には注意深い検討が必要であると強調していますが、Ethereumのブロブに使用されているKZGコミットメントも量子耐性ではないことに留意する価值があります。したがって、Verkle Treesは暫定的な解決策として機能し、ネットワークにより堅牢な代替手段を開発するための追加時間を提供できます。

STARK証明 + 2進メルクル木

Verkle Treesは、Merkle Treesと比較して証明サイズが小さく、効率的な検証プロセスを提供し、Ethereumの急速に成長する状態を管理しやすくしています。楕円曲線ベースのベクトルコミットメントにより、大規模な証明をかなり少ないデータで生成できます。ただし、印象的な利点にもかかわらず、Verkle Treesは量子コンピューターの脆弱性を抱えており、一時的な解決策に過ぎません。EthereumコミュニティはVerkle Treesを時間を稼ぐための短期的なツールと見なしていますが、長期的な焦点は量子耐性ソリューションへの移行にあります。これが、STARK ProofsとBinary Merkle Treesが将来のより堅牢な検証インフラを構築するための強力な代替手段となります。

イーサリアムの状態検証プロセスでは、バイナリMerkleツリーを使用することでMerkleツリーの枝分かれ係数を（16から2に）削減できます。この変更は証明サイズを削減し、検証プロセスをより効率的にするための重要なステップです。ただし、最悪の場合でも、証明サイズは依然として10 MBに達する可能性があり、これはかなりの量です。ここでSTARKプルーフが登場し、これらの大きなバイナリMerkleプルーフを100-300 kBにまで圧縮します。

この最適化は、特に軽量クライアントまたはハードウェアが限られているデバイスでバリデータを運用する制約を考慮する場合に特に重要です、特に平均的なグローバルモバイルのダウンロードおよびアップロード速度がそれぞれ約7.625 MB/sおよび1.5 MB/sであると考えると。ユーザーは、完全な状態にアクセスする必要なしに、小さな携帯用の証拠でトランザクションを検証でき、バリデータは完全な状態を保存せずにブロック検証タスクを実行できます。

この二重の利益アプローチにより、検証者の帯域幅とストレージ要件が低減され、検証が高速化されます。これらは直接、スケーラビリティに向けたEthereumのビジョンを支援する3つの重要な改善点です。

STARKプルーフの主な課題：

1. Proversに対する高い計算負荷：\
   STARKプルーフを生成するプロセスは、特に証明者側では計算コストが高くなるため、運用コストが増加する可能性があります。
2. 小規模データの証明における非効率性:

STARKプルーフは大規模なデータセットを扱うのに優れていますが、小規模なデータを証明する際には効率が低く、特定のシナリオでの適用が妨げられる可能性があります。ステップ数やデータセットが小さいプログラムを扱う場合、STARKの比較的大きな証明サイズのため、それらは実用的でコスト効果が低い場合があります。

量子セキュリティはコストがかかります：検証側の計算負荷

ブロックのMerkle Proofには約330,000のハッシュが含まれる可能性があり、最悪の場合、この数は660,000に上昇することがあります。このような場合、STARKプルーフは秒間約200,000のハッシュを処理する必要があります。

ここで、ポセイドンのようなzkフレンドリーなハッシュ関数が登場し、この負荷を軽減するためにSTARKプルーフに特に最適化されています。Poseidonは、SHA256やKeccakなどの従来のハッシュアルゴリズムと比較して、ZKプルーフでよりシームレスに動作するように設計されています。この互換性の主な理由は、従来のハッシュアルゴリズムの動作方法にあります:入力をバイナリデータ(0と1)として処理します。一方、ZKプルーフは、根本的に異なる数学的構造である素数体で機能します。この状況は、人間が日常生活で 10 進法を使用しているのに、コンピューターが 2 進数で動作することに似ています。ビットベースのデータをZK互換形式に変換するには、かなりの計算オーバーヘッドが伴います。ポセイドンは、プライムフィールド内でネイティブに動作することでこの問題を解決し、ZKプルーフとの統合を劇的に加速します。

ただし、ポセイドンは比較的新しいハッシュ関数であるため、SHA256やKeccakなどの従来のハッシュ関数と同じ信頼レベルを確立するためには、より包括的なセキュリティ分析が必要です。このため、gateのような取り組みがあります。ポセイドン暗号解析イニシアチブイーサリアム財団によって発表されたこのテストでは、専門家がポセイドンのセキュリティを厳密にテストし、敵対的な検証に耐えられるようにし、暗号アプリケーションの堅牢な標準になることを確認しています。一方で、SHA256やKeccakなどの古い機能はすでに広範囲にわたるテストを受け、確立されたセキュリティの記録を持っていますが、ZKフレンドリーではなく、STARKプルーフと使用するとパフォーマンスが低下します。

例えば、これらの従来のハッシュ関数を使用したSTARK証明は現在、10,000から30,000のハッシュしか処理できません。幸いにも、STARK技術の進歩により、このスループットは近いうちに100,000から200,000のハッシュに増加する可能性があり、効率が大幅に向上するかもしれません。

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

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

1. Post-AAトランザクションの検証：\
   Account Abstraction（AA）を使用すると、ウォレットは契約コードを指し示すことができ、イーサリアムでは現在強制されているnonceや署名の検証などの手順を回避したり、カスタマイズしたりすることができます。ただし、この検証の柔軟性には、トランザクションの妥当性を証明するために契約コードや他の関連するデータをステートでチェックする必要があります。
2. ライトクライアントRPC呼び出し：\
   ライトクライアントは、完全なノードを実行せずにネットワークから状態データをクエリする（たとえば、eth_callリクエスト中）。この状態の正確性を保証するためには、証明がクエリされたデータをサポートし、ネットワークの現在の状態に一致することを確認する必要があります。
3. Inclusion lists: \
   小規模なバリデータは、トランザクションが次のブロックに含まれることを確保するために、インクルージョンリストのメカニズムを使用することができます。これにより、強力なブロックプロデューサーの影響を制限することができます。ただし、これらのトランザクションの含まれているかどうかを検証するには、その正確性を確認する必要があります。

このようなユースケースでは、STARKプルーフはほとんど利点を提供しません。STARKは、名前の中の「S」によって強調されるように、大規模なデータセットに適していますが、小規模なデータシナリオでは苦労します。一方、SNARKは、名前の中の「S」によって強調されるように、簡潔さを目指して設計されており、プルーフのサイズを最小限に抑えることに焦点を当てており、帯域幅やストレージの制約がある環境で明確な利点を提供しています。

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

それにもかかわらず、STARKの証明は、その量子セキュリティのために、イーサリアムの状態レスの未来において重要なままです。

表にまとめられたように、Ethereumには選択肢として4つの潜在的な道があります:

• Verkle Trees
  1. Verkle Treesは、イーサリアムコミュニティから広く支持されており、その開発を促進するために隔週で会議が開かれています。この一貫した作業とテストのおかげで、Verkle Treesは現在の代替案の中で最も成熟し、よく研究されたソリューションとして際立っています。さらに、加法的同型性の特性により、Merkle Treesとは異なり、状態ルートを更新するためにすべてのブランチを再計算する必要がなく、Verkle Treesはより効率的なオプションとなります。他のソリューションと比較して、Verkle Treesは「シンプルに保つ」や「シンプルが最良である」といったエンジニアリング原則に従ってシンプルさを重視しています。このシンプルさは、イーサリアムへの統合やセキュリティ分析を容易にします。
  2. ただし、Verkle Treesは量子セキュアではないため、長期的な解決策としては適していません。この技術がEthereumに統合された場合、将来的には量子耐性のある解決策が必要とされる際に、おそらく置き換える必要があるでしょう。Vitalik自身もVerkle TreesをSTARKsや他の技術が成熟するまでの時間稼ぎの一時的な手段と見なしています。また、Verkle Treesで使用されている楕円曲線ベースのベクトルコミットメントは、単純なハッシュ関数と比較してより高い計算負荷を課します。ハッシュベースのアプローチは、完全ノードのより高速な同期時間を提供する可能性があります。さらに、多数の256ビット演算への依存は、Verkle Treesを現代の証明システム内でSNARKsを使用して証明することをより難しくし、将来的な証明サイズの縮小の取り組みを複雑化させます。

ただし、ハッシングに依存しないVerkle Treesは、Merkle Treesよりもはるかに証明性が高いことに注意することが重要です。

• STARKs + 保守的なハッシュ関数
  1. STARKsをSHA256やBLAKEなどの確立された保守的なハッシュ関数と組み合わせることで、Ethereumのセキュリティインフラを強化する堅牢なソリューションが提供されます。これらのハッシュ関数は、学術的および実用的な分野で広く使用され、広範囲にテストされています。さらに、彼らの量子抵抗性は、量子コンピュータによる将来の脅威に対するEthereumの弾力性を高めます。セキュリティクリティカルなシナリオに対して、この組み合わせは信頼性の高い基盤を提供します。
  2. ただし、STARKシステムでの保守的なハッシュ関数の使用は、著しい性能制限を導入します。これらのハッシュ関数の計算要件は、プルーバーの遅延が高くなるため、証明の生成に10秒以上かかります。これは特に低遅延を要求するブロック検証などのシナリオで、大きな欠点です。多次元ガス提案などの取り組みは、最悪のケースと平均のケースの遅延を整合させようと試みますが、その結果は限られています。また、ハッシュベースのアプローチはより速い同期時間を可能にするかもしれませんが、その効率はSTARKの広範なスケーラビリティの目標とは一致しないかもしれません。従来のハッシュ関数の長い計算時間は実用的な効率を低下させ、それらの適用範囲を制限します。
• STARKs + 比較的新しいハッシュ関数
  1. STARKsは、新世代のSTARK向けハッシュ関数（例：Poseidon）と組み合わせることで、その性能が大幅に向上します。これらのハッシュ関数は、STARKシステムにシームレスに統合され、プルーバーのレイテンシーを大幅に低減します。従来のハッシュ関数とは異なり、1～2秒で証明生成が可能になります。その効率性と低いコンピューターオーバーヘッドにより、STARKsのスケーラビリティポテンシャルが向上し、大規模なデータセットの処理に非常に効果的です。この機能により、高性能を必要とするアプリケーションにとって特に魅力的です。
  2. ただし、これらのハッシュ関数の相対的な新しさから、包括的なセキュリティ分析とテストが必要とされます。包括的なテストの不足は、イーサリアムのような重要なエコシステムへの実装を考慮する際にリスクを導入します。さらに、これらのハッシュ関数がまだ広く採用されていないため、必要なテストと検証プロセスによってイーサリアムの検証目標が遅れる可能性があります。セキュリティの完全な確保に必要な時間は、このオプションを短期的には魅力的ではなくし、イーサリアムのスケーラビリティと検証の意欲を先送りするかもしれません。
• 格子ベースのMerkle Trees
  1. 格子ベースのMerkle Treesは、量子セキュリティとVerkle Treesの更新効率を組み合わせた先進的なソリューションを提供します。これらの構造は、Verkle TreesとSTARKsの両方の弱点に対処し、有望な長期オプションと見なされています。格子ベースの設計により、量子コンピューティングの脅威に対して強力な耐性を提供し、Ethereumのエコシステムの将来にわたる焦点に合致しています。さらに、Verkle Treesの更新可能性の利点を維持することで、効率を犠牲にすることなく、強化されたセキュリティを提供することを目指しています。
  2. しかしながら、格子ベースのMerkle Treesに関する研究はまだ初期段階にあり、主に理論的です。これにより、実用的な実装とパフォーマンスについて著しい不確実性が生じます。このようなソリューションをEthereumに統合するには、広範な研究開発と潜在的な利点を検証するための厳格なテストが必要です。これらの不確実性とインフラの複雑さにより、格子ベースのMerkle Treesは近い将来においてEthereumにとって実現可能な選択肢ではない可能性が高く、ネットワークの検証可能な目標に向けた進展を遅らせる可能性があります。

実行についてはどうですか：EVM実行の妥当性証明

ここまで説明してきたことはすべて、バリデーターが以前の状態を保存する必要性をなくすことを中心に展開し、バリデーターはある状態から次の状態に移行するために使用します。目標は、バリデーターがテラバイト単位の状態データを維持することなく職務を遂行できる、より分散化された環境を作ることです。これまで述べてきた解決策を用いても、バリデーターは、ブロックに含まれる証人を通じて実行に必要なすべてのデータを受け取るため、状態全体を保存する必要はありません。ただし、次の状態に遷移し、それによってブロックの上でstateRootを検証するには、バリデーターはSTFを自分で実行する必要があります。この要件は、イーサリアムのパーミッションレスな性質と分散化に別の課題をもたらします。

最初は、ザ・バージは、イーサリアムの状態ツリーをマークルツリーからバークルツリーに移行することに焦点を当てたマイルストーンとして構想されました。状態の検証性を向上させることを目的としています。しかし、時間の経過とともに、それは状態の遷移とコンセンサスの検証性を高めることを目指すより広範な取り組みに発展しました。状態、実行、およびコンセンサスのトリオが完全に検証可能な世界では、イーサリアムのバリデータは「真の分散化」を実現するために、インターネット接続を持つほぼどんなデバイスでも動作させることができます。

問題の定義は何ですか？

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

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

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

1. おそらくあなたの冷蔵庫には十分に高速なインターネットがないため、これまでに議論した状態検証ソリューションでも必要なデータと証拠をダウンロードすることができません。
2. STFに必要なデータにアクセスできたとしても、開始から終了までの実行または新しい状態ツリーの構築に必要な計算能力を持っていない可能性があります。

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

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

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

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

先程参照したProver-Verifierの類推において、一般的には両者の間には通常、計算上のバランスがあると言えます。STFを検証可能にするために必要な証明の能力は、複数のことを同時に検証することを可能にするためVerifierにとって重要な利点をもたらしますが、実行の正確性を確認するためのこのような証明を生成することはProverにとっては比較的困難であることを示しています。Ethereumの現在のスピードでは、Ethereumブロックを4秒未満で証明する必要があります。しかし、今日最速のEVM Proverでさえ、平均ブロックを約15秒で証明することしかできません。[1]

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

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

証明生成中、実行プロセスのすべての小さな部分（例：計算ステップまたはデータアクセス）は個別に証明でき、これらの証拠は後で1つの構造に集約できます。正しいメカニズムを使用すると、このアプローチにより、多くの異なるソース（例：数百のGPU）によって、ブロックの証拠が迅速かつ分散型に生成されます。これにより、参加者の幅広いプールが関与し、パフォーマンスが向上し、同時に分散化の目標に貢献します。

1. 最適化された証明システムの使用: 新世代の証明システムは、イーサリアムの計算プロセスをより速く、効率的にする可能性を秘めています。ゲートなどの先進的なシステムオリオン、Binius、そしてGKR一般目的の計算の証明時間を大幅に削減することができます。これらのシステムは、現在の技術の限界を克服し、処理速度を向上させながら、より少ないリソースを消費することを目的としています。スケーラビリティと効率に焦点を当てたEthereumのようなネットワークにとって、これらの最適化は重要なアドバンテージを提供します。ただし、これらの新しいシステムの完全な実装には、エコシステム内での包括的なテストと互換性の努力が必要です。
2. ガスコストの変更: これまで、Ethereum Virtual Machine (EVM) 上の操作のガスコストは、通常、計算コストに基づいて決定されていました。しかし、現在では、別の指標であるプルーバの複雑さが注目されています。一部の操作は比較的簡単に証明できますが、他の操作はより複雑な構造を持ち、検証に時間がかかります。計算の手間だけでなく、操作の証明の難易度に基づいてガスコストを調整することは、ネットワークのセキュリティと効率の向上に重要です。

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

実行証明を可能にするためのイーサリアムの取り組みは、検証可能性の目標を達成するための重要な機会を表しています。ただし、この目標を達成するには、技術的な革新だけでなく、コミュニティ内でのエンジニアリングの取り組みと重要な決定の増加も必要です。レイヤー 1 で実行プロセスを検証可能にするには、分散性を維持しながら、既存のインフラストラクチャと連携しながら、幅広いユーザー ベースがアクセスできるようにすることのバランスを取る必要があります。このバランスを確立すると、実行中に演算を証明するために使用される方法の複雑さが増し、並列証明生成などの進歩の必要性が浮き彫りになります。さらに、これらのテクノロジーのインフラストラクチャ要件 (例:ルックアップテーブル実装および運用化する必要がありますが、これには引き続き実質的な研究と開発が必要です。

一方で、特定のタスクに特化した回路（例：ASIC、FPGA、GPUなど）は、証明生成プロセスを加速させるための大きなポテンシャルを持っています。これらのソリューションは、従来のハードウェアと比較してはるかに高い効率を提供し、実行プロセスを高速化することができます。しかし、Ethereumの第1レイヤーでの分散化目標により、このようなハードウェアが一部のアクターにしか利用できないようになっています。その結果、これらのソリューションは第2レイヤーシステムでより広範囲に使用されることが予想されています。ただし、コミュニティは証明生成のハードウェア要件についても合意しなければなりません。重要な設計課題が浮かび上がります。証明生成はハイエンドのノートパソコンのような消費者向けのハードウェアで動作させるべきでしょうか、それとも産業用インフラが必要でしょうか？その答えがEthereum全体のアーキテクチャを形作ります。第2レイヤーソリューションの積極的な最適化を可能にする一方で、第1レイヤーに対してはより保守的なアプローチを求めることになります。

最後に、実行証明の実装は、直接的にEthereumの他のロードマップの目標と結びついています。有効性の証明の導入は、状態のないといった概念のみならず、ソロステーキングなどの領域をよりアクセスしやすくするだけでなく、Ethereumの分散化を向上させます。目標は、最も低スペックのデバイスでもステーキングを可能にすることです。さらに、計算の難しさと証明に基づいたEVM上のガスコストの再構築は、平均ケースと最悪ケースのシナリオのギャップを最小限に抑えることができます。しかし、このような変更は現行のシステムとの後方互換性を壊す可能性があり、開発者にコードの書き直しを余儀なくさせるかもしれません。このため、実行証明の実装は単なる技術的な課題ではなく、Ethereumの長期的な価値を守るために設計された旅であると言えます。

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

イーサリアムのコンセンサスメカニズムは、分散化とアクセシビリティを維持しながら、検証目標を達成するために一意のバランスを確立しようとしています。このフレームワークでは、確率的および決定論的なコンセンサス手法がそれぞれ異なる利点と課題を提供します。

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

確率的構造の利点の 1 つは、各ノードがチェーン ビューを個別のメッセージとしてブロードキャストしないため、通信のオーバーヘッドが削減されることです。その結果、このような構造は、システム要件が低く、はるかにパーミッションレスで分散型のノードで動作することができます。対照的に、決定論的コンセンサスは、1対すべてのコミュニケーションモデルを通じて機能します。ここで、ノードは、そのチェーンビューを他のすべてのノードに投票として送信します。この方法では、メッセージの強度が高くなり、ノード数が増えると、システムが最終的に限界に達する可能性があります。しかし、決定論的コンセンサスの最大の利点は、具体的な投票が利用できることであり、どのノードがどのフォークに投票したかを正確に知ることができます。これにより、高速で決定的なチェーンのファイナリティが保証され、ブロックの順序が変更されないことが保証され、検証可能になります。

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

エポックは32スロットからなり、決定論的な合意を導入します。このレベルでは、バリデータはチェーンの順序を確定させるために投票し、確実性を提供し、チェーンを検証可能にします。ただし、エポックレベルで具体的な投票による検証可能性を提供する一方で、確率的な構造のためにエポック内での完全な検証可能性は提供できません。このギャップを埋め、エポック内の確率的な構造を強化するために、EthereumはSync委員会として知られる解決策を開発しました。

アルテアのライトクライアントプロトコル：シンク委員会

Syncコミティは、Altairアップグレードで導入されたメカニズムであり、Ethereumの確率的コンセンサスの制限を克服し、軽量クライアントのためのチェーンの検証性を向上させるためのものです。このコミティは、256個のエポック（約27時間）にわたって務める512人の無作為に選ばれたバリデータで構成されています。これらのバリデータは、チェーンのヘッドを表す署名を生成し、軽量クライアントが過去のチェーンデータをダウンロードする必要なく、チェーンの妥当性を検証できるようにします。Syncコミティの動作は、次のように要約することができます:

1. 委員会の形成:
   ネットワーク内のすべてのバリデータからランダムに512人のバリデータが選ばれます。この選択は定期的に更新され、集中化を維持し、特定のグループへの依存を防止します。
2. 署名生成：
   委員会メンバーは、チェーンの最新の状態を表す署名を生成します。この署名は、メンバーによって作成された集団BLS署名であり、チェーンの妥当性を検証するために使用されます。
3. ライトクライアント検証:
   ライトクライアントは、シンク委員会からの署名を単純にチェックすることで、チェーンの正確性を検証できます。これにより、過去のチェーンデータをダウンロードせずに、安全にチェーンを追跡できます。

ただし、シンク委員会はいくつかの分野で批判の対象となっています。特に、選択されたバリデータが意図的にプロトコルに逆らって行動しても、そのような悪質な行為に対してバリデータを削減する仕組みがプロトコルに欠けているという指摘があります。その結果、多くの人々がシンク委員会をセキュリティリスクと見なし、完全にライトクライアントプロトコルとして分類することを控えています。それでも、シンク委員会のセキュリティは数学的に証明されており、詳細は以下で確認できます。Sync Committee Slashingsに関するこの記事.

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

この文脈では、同期委員会を不安全というよりも、それを非効率な解決策と表現する方が正確です。問題は、同期委員会の機械的な設計や運用に起因するのではなく、確率的コンセンサスの本質的な性質に由来しています。確率的コンセンサスはノードが観測する内容について確定的な保証を提供することができないため、同期委員会はそのようなモデル内で設計されることのできる最良の解決策の一つです。しかしながら、これは確率的コンセンサスの弱点を排除するものではなく、チェーンの最終性を保証する際の確率的コンセンサスの弱点を排除するものではありません。問題はメカニズムではなく、イーサリアムの現在のコンセンサス構造の内部にあります。

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

コンセンサスのスナーキフィケーション

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

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

現在のコンセンサスレイヤーで使用されているECADD、Pairing、およびSHA256操作は、イーサリアムの検証可能性の目標において重要な役割を果たしています。しかし、彼らのzkフレンドリーさの欠如は、これらの目標を達成するための道のりに重大な課題をもたらします。ECADD操作は、高い数のバリデータの投票による負荷を作り出し、Pairing操作は数が少なくてもzkプルーフで証明するには数千倍も費用がかかります。さらに、SHA256ハッシュ関数のzk非フレンドリーさは、ビーコンチェーンの状態遷移を証明することを非常に困難にします。これらの問題は、イーサリアムの既存のインフラをゼロ知識技術に合わせるために包括的な変革が必要であることを明確に示しています。

ソリューション“Beam Chain”: Ethereumのコンセンサスレイヤーを再構想する

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

Justin Drakeのプレゼンテーションでは、イーサリアムはMEVの理解、SNARK技術の突破、技術的なミスの反省など、これらの5年間で重要な教訓を学んできました。これらの新しい学びに基づく設計は、ブロックプロダクション、ステーキング、暗号化の3つの主要な柱に分類されます。以下のビジュアルは、これらの設計と提案されたロードマップを要約しています。

• 緑と灰色のボックスは、1年ごとに実装できる増分の開発を表しています。これらの種類の改善は、以前のアップグレードと同様に、イーサリアムの既存のアーキテクチャを崩さずに段階的に統合されることができます。
• 一方、赤い箱は、高シナジー、大規模、そして基盤となる変更を示し、これらは一緒に実装する必要があります。ドレイクによると、これらの変更は、イーサリアムの能力と検証性を一気に進化させることを目指しています。

このセクションでは、詳細にThe VergeのConsensus、State、Executionステップを検討しました。このプロセス中に強調された最も顕著な問題の1つは、EthereumのBeacon ChainでのSHA256ハッシュ関数の使用です。SHA256はネットワークのセキュリティとトランザクションの処理を確保する上で中心的な役割を果たしていますが、zk技術との互換性のなさから、Ethereumの検証可能性の目標達成には重大な障害となっています。高い計算コストとzk技術との非互換性は、Ethereumの将来の開発で必ず解決されなければならない重要な問題です。

Justin Drakeのロードマップは、彼のDevconトークで発表され、Beacon ChainのSHA256をPoseidonなどのzk-friendlyハッシュ関数で置き換えることを予想しています。この提案は、Ethereumのコンセンサスレイヤーを現代化し、より検証可能で効率的で、zk-proofテクノロジーと一致するようにすることを目指しています。

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

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

Justin Drake が強調したように彼のDevconプレゼンテーションハッシュ関数は、事前イメージ耐性に依存しているため、量子コンピュータに対して固有に耐性を持っています。これにより、ハッシュ関数は現代の暗号の基本的な構成要素の1つとなっています。この特性により、量子コンピュータでも特定のハッシュから元の入力を効率的に逆算することはできず、セキュリティが保たれます。ハッシュベースの署名システムは、バリデータやアテスターがハッシュ関数に完全に基づいて署名を生成できるようにし、ポスト量子セキュリティを確保しながらネットワーク全体でより高い検証性を提供します。特に、SNARKフレンドリーなハッシュ関数が使用される場合、これはネットワークのセキュリティを向上させるだけでなく、Ethereumの長期的なセキュリティインフラをより堅牢で将来に対応できるものにします。

このシステムは、ハッシュベースの署名とハッシュベースのSNARKs（STARKのような証明）を組み合わせて、集約可能な署名スキームを作成します。 集約可能な署名は、何千もの署名を単一の構造体に圧縮し、わずか数百キロバイトの証拠にまで減少させます。 この圧縮により、ネットワーク上のデータ負荷が大幅に減少し、検証プロセスが大幅に加速します。 たとえば、イーサリアムの単一のスロットで生成される何千もの検証者の署名は、単一の集約署名で表すことができ、ストレージスペースと計算能力の両方を節約します。

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

最終的な考えと結論

イーサリアムの検証可能性への道は、ブロックチェーン技術における根本的な変化を表しています。Vergeイニシアチブは、状態の検証のためのVerkle TreesやスケーラブルなトランジションのためのSTARKプルーフを通じて、コアの非効率性に対処しています。

最も野心的な提案の1つは、Beam Chainです。これはEthereumのコンセンサスレイヤーの包括的な再設計です。ビーコンチェーンの制限を解決し、zkフレンドリーな代替案を取り入れることにより、このアプローチはEthereumのスケーラビリティを向上させると同時に、分散化とアクセシビリティの核心原則を保持することを目指しています。ただし、この移行は、計算要件と許可なしで包括的なネットワークを維持するというEthereumの目標のバランスを取る上での課題も浮き彫りにしています。

NISTが現在の楕円曲線暗号を2035年までに段階的に廃止する計画を立てているため、Ethereumはハッシュベースの署名やPoseidonなどの量子耐性のある解決策を採用する必要があります。これらの解決策は、独自の効率のトレードオフを提供します。

EthereumのロードマップでのSTARKの使用は、スケーラビリティと検証性をさらに強調しています。STARKは透明性と量子耐性のある証明を提供する点で優れていますが、その統合にはプルーバ側の計算コストと小規模データの非効率性に関する課題があります。これらのハードルを克服することが必要であり、Ethereumのステートレスネスと効率的なブロック検証のビジョンを完全に実現するために、ネットワークが増加する需要に対して堅牢性を維持する必要があります。

これらの進展にもかかわらず、重要な課題は残っています。イーサリアムは、zkフレンドリー性、コンセンサスのスケーラビリティ、および量子耐性暗号の統合の複雑さなどの問題に対処する必要があります。さらに、既存のインフラの後方互換性は、開発者やユーザーへの影響を防ぐために慎重なエンジニアリングソリューションが必要な実用的なハードルを提起しています。

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

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

免責事項：

1. この記事は、から転載されています。[[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 リサーチ](https://research.2077.xyz/)\]. すべての著作権は元の著者に帰属します [Koray Akpinarr]. If there are objections to this reprint, please contact the ゲートラーンチームが迅速に対応します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、ゲートラーンチームによって他の言語に行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。