イントロダクション

2024年、Ethereumを中心とした多くの重要なイベントが起こりました。年初に、EthereumはDencunのアップグレードを通じてブロブを導入しました。このアップデートにより、既存のロールアップのトランザクションコストが劇的に削減され、ロールアップエコシステムの急速な拡大の基盤が築かれました。

(Dencunアップグレード後のOPチェーンでの手数料削減 | 出典:Optimism X)

しかしながら、エコシステム内のdappsが高いスケーラビリティを持つロールアップや代替のLayer 1（L1）ネットワークに移行するにつれて、Ethereum上のユーザーアクティビティは減少し始めました。さらに、ロールアップが高額の手数料をEthereumに提出しなくなったため、コミュニティ内で懸念が生じ始めました。

さらに、2024年はSolanaやSuiなどのスケーラビリティに焦点を当てたL1が大きな力を発揮した年でした。これらのネットワークが生成する膨大なTPS（1秒あたりのトランザクション数）により、ロールアップ上のアクティビティは比較的小さく見えました。

この文脈では、「イーサリアムのロールアップ中心のロードマップは欠陥がある」といった批判が浮上し、「イーサリアムの開発は成功するには遅すぎる」といった批判も出ています。イーサリアムは本当に正しい道を進んでいるのでしょうか？イーサリアムは2025年や2030年にどのようになっているのでしょうか？

このシリーズでは、テクニカルな詳細に基づいて、Ethereumのロードマップの一部について掘り下げ、その将来を分析します。最初のトピックは、Beam Chainです。

Beamチェーン提案とは何ですか、そしてなぜ重要なのですか？

今年、イーサリアムコミュニティで最も話題になったトピックを選ぶとしたら、おそらくDevconでのイーサリアム研究者ジャスティン・ドレイク氏のビームチェーンに関する発表でしょう。この発表は多くの関心を集め、それに応じて多くの騒音が発生しました。この提案が意味することを分析してみましょう。

Beamチェーンの提案の中心的なアイデアは、イーサリアムのコンセンサスレイヤーを完全に再設計することです。現在のコンセンサスレイヤーであるビーコンチェーンを再設計する必要があるとJustin Drakeは以下の3つの理由を提示しました。

• 過去の経験を通じてMEVの理解を深める
• SNARKテクノロジーの急速な進歩（例：驚異的な速さで進化するzkVM開発、10倍以上速く）
• ビーコンチェーン内の「技術的負債」を排除する

現在、イーサリアムのコンセンサスレイヤーロードマップには、次の要素が含まれています:

これらのうち、太字で示された4つのエリアは、ビーコンチェーンの単なる修正を超えた基本的な変更を表しています。たとえば、チェーンスナーキフィケーションとは、コンセンサスレイヤーのステートハンドリングをZKテクノロジーに変換することを指し、ハッシュ関数からステートのメルクライジング/シリアライジングの方法まで基本的な変更が必要です。

さらに、より速いスロットとより速い最終的な確定は、セキュリティを維持しながら性能の向上を実現するために提案された新しいデザインです。これらを実装するには、コンセンサスレイヤーで広範な変更が必要です。

Beam Chainは、単一のハードフォークを通じてこれらの変更を実現することを提案しています。要約すると：

1. イーサリアムのコンセンサス層のロードマップを実装するには、コンセンサス層を完全に再設計する必要があります。
2. このため、ロードマップ上の主要な変更は、Beam Chainというハードフォークにまとめられます。
3. それは、より速いブロックタイム、より速い最終性、チェーンのスナーキフィケーション、そして量子耐性を含む4つの要素を含んでいます。

次に、これらのそれぞれがどのように実装され、どのような技術的影響があるかを探ってみましょう。

Beamチェーンデザインの技術的な詳細

より速いスロットとより速い確定性

現在、Ethereumのスロット時間は12秒であり、スロットに接続されたブロックが最終性に達するまでには2〜3エポック（約15分）かかります。これらの時間を改善すると、Ethereumのユーザー、アプリ、およびEthereum上で構築されたロールアップにポジティブな影響を与えるでしょう。

より短い確定（オービットSSF）

このトピックは、イーサリアムの研究者の間でSSF（シングルスロットファイナリティ）として知られており、イーサリアムのブロックが約15分から12秒以内に確定する時間を短縮し、ユーザーにより速い確認を提供することを目的としています。シングルスロットファイナリティを理解するには、イーサリアムの現在のコンセンサスアルゴリズムであるGasperを理解する必要があります。

Gasperの主要な設計原則は、各スロットで提案されたブロックが一定の経済的セキュリティレベルに達し、各バリデータの通信負荷を最小限に抑えることです。これを実現するために、Ethereumはすべてのバリデータを32のスロットに分散した委員会に分割します。各スロットには最大64の委員会を含めることができ、目標は各委員会を128のバリデータで構成することです（ただし、アクティブなバリデータの合計数がこれを超える場合は、この数は増加する可能性があります）。

各委員会内のバリデータは、BLS署名を使用してブロックを独立して検証し、投票します。BLS署名メカニズムにより、複数の署名を1つに集約することができます。つまり、委員会内の指定されたノードがこれらの署名を収集し、1つのコンパクトなデータパッケージにまとめます。この集約された署名をブロードキャストすることで、次のブロック提案者は最小限のデータでブロックが適切に検証されたことを確認できます。

(イーサリアムのバリデータ間のBLS署名集約 | 出典: eth2book)

要約すると、イーサリアムのGasperは、次のメカニズムを通じてスケーラビリティと経済的セキュリティの両方を実現しています:

• バリデータは6.4分の間に委員会のスロットに分散され、すべてのバリデータ間の直接通信の必要性をなくします。
• 集約署名プロセスにより、ブロックへのバリデータの投票が少量のデータを使用して検証できるようになります。

ただし、ガスパーはエポック単位で動作するため、スロットが最終的に達成する前にエポック間の「接続性」を検証する必要があります。ガスパーでは、完全な経済的セキュリティを達成するには、少なくとも2つのエポック（64スロット）が経過する必要があります。

これにより、次の図式表現が得られます。

(ギャスパーの経済ファイナリティ |源：Orbit SSF)

これにより、さまざまな課題が生じ、UXが低下します。例えば:

• CEX（中央集権型取引所）からイーサリアムへの資金の引き出し、またはその逆の場合、確認期間は約10分かかる場合があり、比較的に長いです。
• EthereumのロールアップとdAppsは、依存しているL1ブロックが最終化されずに無効になる可能性に直面しています。適切な対策が実施されない場合、これは問題を引き起こす可能性があります。

例えば、2024年3月に、Polygon zkEVMはイーサリアムの再構築の適切な処理が行われていないため、2日以上にわたるチェーンの停止を経験しました。

最終性までの時間を短縮することは不可能ではありません。これは、Tendermintなどの合意アルゴリズムによって実証されており、すでにいくつかのプロトコルで適用されています。ただし、Tendermintのメカニズムを採用する際の課題は、ノード間での頻繁なP2P通信にあり、これによりスケーラビリティの制限が発生します。

Tendermintでは、ノード数がNである場合、メッセージ複雑度はO（N ^ 3）です。これは、ノード数が増加するにつれて、それらの間の通信頻度が指数関数的に増加し、拡張性が制限されることを意味します。したがって、多数の検証者を持つEthereumなどのプロトコルは、そのままTendermintを採用することはできません。

TendermintスタイルのコンセンサスをEthereumに適用するためには、これらの問題に対して追加の作業が必要です。

Orbit SSF提案の概要

Orbit SSFは、スロットの確定時間を短縮するためにGasperの委員会メカニズムを修正し、高い経済的セキュリティを維持することを目指しています。

提案は、エポックサイズを32スロットから1スロット（約12秒）に減らすことです。ただし、前述のように、これによりバリデータの通信に必要なリソースが増え、Ethereumの分散化に悪影響を与えます。

これに対処するため、Orbit SSFは次のアイデアを提案しています:

各イーサリアム検証者の最大ステーキング量を増やすことで、より少ない検証者でも同じレベルの経済的セキュリティを達成することができます。

スロットごとに複数の委員会を持つ代わりに、Orbit SSFでは単一の「スーパー委員会」を導入することを提案しています。より高いステーキング額を持つバリデータは、ほとんどの場合、委員会に比例して含まれるため、より少ない委員会でも同じ経済的なセキュリティレベルが維持されます。

次のEthereumのアップグレード、Pectraには、最大ステーキング量（MaxEB）を32 ETHから2048 ETHに引き上げることを提案するEIP-7251が含まれています。この提案は、Ethereumノードインフラ運用業者にとって魅力的ですが、Orbit SSFの前提条件でもあります。

ただし、大口ステーキングを持つバリデーターがほぼ常に委員会に含まれる場合、より小規模な単独のバリデーターは報酬が減少し、イーサリアムの分散化に悪影響を与える可能性があります。これを防ぐため、Orbit SSFはステーキング額に比例してAPRが増加するように報酬を調整し、より大きなバリデーターが頻繁に委員会に含まれるようにします。

（報酬およびオービットSSF委員会への含まれる確率 | ソース：オービット SSF)

さらに、Orbit SSFは「委員会ベースの確定性」に向かって移行しています。Gasperでは、委員会は2つ以上のエポックが経過した後に確定性に貢献することができましたが、Orbit SSFでは、各スロットに割り当てられた委員会がリアルタイムで確定性に貢献することができます。委員会をより積極的な確定性の貢献者にし、スケーラビリティをより速く実現することを目指しています。

(Cap-and-slow-rotateを使用したOrbit SSFにおける最終性 | 出典: Gate.io)Orbit SSF)

ここでの鍵は、委員会メンバーの構成にあります。Orbit SSFは、大口のステークを持つバリデータが数学的にほぼ委員会内で固定される「スローローテーション」メカニズムを提案しており、一方で小口のバリデータは出入りを繰り返します。これにより、経済的セキュリティのしきい値を非常に高く設定できる一方で、バリデータ間の最小限の通信オーバーヘッドを維持し、最終性の時間を低く保つことができます。

例えば、n = 3 とかなり大きなFを設定することで、Ethereumは約3つのスロットで最終性を達成し、Justin Drakeの3つのスロットFFGのビジョンを実現することができます。

しかし、Ethereumの全体のバリデーターセットのレベルにFを引き上げることは簡単ではありません。これにより、Ethereumへの51％攻撃のコストを削減する可能性があります。そのため、Orbit SSFの将来の主な課題は、Ethereumのセキュリティを確保しながらFを技術的にどのように増やすかを決定することです。分散化を犠牲にすることなく、セキュリティを確保することです。

スロット時間を短くする（4秒のスロット）SSF（または3スロットの確定性）が達成されたとしても、イーサリアムのユーザーは最小のトランザクション確認時間が12秒になります。これにはユーザーにとって2つの主な欠点があります。

1. SolanaやSuiなどの他のL1と比べて、長いレイテンシがあります
2. MEV（ブロック時間が短くなるとMEVが減少し、EthereumのユーザーはよりMEVに対して脆弱になります）に対するより高い脆弱性

さらに、12秒のブロック時間は、特にベースロールアップにとって不利です。たとえば、太鼓は、すべてのL2ブロックをL1に投稿することでベースロールアップを実装しています。その結果、太鼓のブロック時間は最低12秒に増加し、24秒を超えることもあります。

この問題に対処するために2つの解決策が提案されています:

a. イーサリアムのブロック時間を4または8秒に短縮します

b. 事前確認を使用する

イーサリアムのブロック時間を短縮する

イーサリアムのブロック時間の短縮は活発な議論のテーマです。EIP-7782として正式に提案されており、スロット時間を12秒から8秒に短縮することで、イーサリアムのスケーラビリティを33%向上させることが提案されています。しかし、8秒のスロット時間はユーザーエクスペリエンスやベースロールアップにとって最適でない場合もあります。より短いスロット時間の実現がより望ましいとされています。

そのように言っても、より短いブロック時間はバリデータセットの中央集権化を引き起こす可能性があります。物理的な制約のため、地理的に遠いバリデータはより長い通信時間を要し、4秒のスロット時間では特定のシナリオで通信が不可能になる可能性があります。

Ethereumメインネットのブロック伝播時間の統計は、4秒のブロック時間の実現可能性についての洞察を提供します。下のグラフは、ブロック伝播時間の分布を示しています。

(CDF of message arrival times | Source:Gossipsubメッセージ伝播遅延)

約98%のブロックは4秒以内に伝播されますが、約2%はより長い時間がかかります。このデータに基づくと、4秒のブロック時間は実現可能に見えるかもしれません。しかし、ブロック時間は通信だけでなく、実行と投票も含まれています。これらの要因を考慮すると、4秒のブロック時間のうち約2秒しか通信に利用できません。この状況下では、4秒のブロック時間を達成することは挑戦的です。

これを解決するために、送信されるデータのサイズを削減し、クライアントのP2Pコンポーネントのパフォーマンスを最大化するか、物理的な通信を効率化する必要があります。

事前確認を使用する

その間、事前確認はユーザーエクスペリエンスを向上させることができます。事前確認により、ブロックを生成するエンティティはユーザーに「あなたのトランザクションは次のブロックに含まれます」と約束し、スロット時間よりも早く結果をユーザーに提供することができます。

事前確認の利点は、L1バリデータがフォークやクライアントの修正を必要とせずにそれを利用できることです。たとえば、Commit-Boostは、イーサリアムバリデータが安全に事前確認を生成および伝播するためのソフトウェアです。

Commit-Boost、MEV-Boostのように、バリデーターのためのオプションのサイドカーであり、安全に"コミットメント"を生成および伝播することができます。ユースケースに応じて、これらのコミットメントはさまざまな形を取ることがあります。

第3種の事前確認アーキテクチャを使用することで、ブロック時間が長くてもユーザーの認識される待ち時間を大幅に短縮することができます。バリデータがユーザーのトランザクションを受け取ると、実行して結果をユーザーに返すことができます。この結果はブロック作成ではなくバリデータのコミットメントに基づいているため、ユーザーはミリ秒単位でそれを受け取ることができます。

ただし、Commit-Boostの効果はバリデータの採用に依存します。ほんのわずかなバリデータしか使用しない場合、UXへの影響は最小限にとどまるでしょう。とはいえ、Commit-Boostはイーサリアムコミュニティから強力な支持を受けており、MEV-Boostのような広範なミドルウェアになる可能性があります。Rocket Pool、Renzo、SSV、Luganodes、Nethermind、Puffer、A41、Figmentなどの有名なバリデータオペレータからの支持を受けています。さらに、EF、Lido、Eigenlayerからの助成金を獲得し、ブロックビルダーTitanから強力なサポートを受けています。

しかしながら、前述のように、プレコンファームはプロトコルに直接統合されるよりも、MEV-Boostのようなオフチェーンのサイドカーとして使用される可能性が高いです。

BEAMチェーンの役割はより速いスロットにあります

Justin Drakeのプレゼンテーションで議論されたように、Beam Chainの目標はブロックの時間を短縮することです。そのため、研究と実装はおそらく4秒のスロット時間を短縮することに焦点を当て、分散化を損なうことなく実現されます。この記事の後半で説明されるように、イーサリアムの完全なsnarkificationによって解決される可能性があります。

チェーンsnarkificationと量子耐性

ジャスティンはプレゼンテーションで、Beam Chainの目標はZKテクノロジーを使用してコンセンサスクライアントをスナーキファイすることだと述べました。これはどういう意味であり、どのように達成できるのか、なぜ必要なのでしょうか？

チェーン snarkification

現在、Ethereum Beacon Chainは、バリデータが各ブロックを「再実行」して、その結果の状態ルートが正しいことを検証することでコンセンサスを実現しています。この再実行プロセスは非効率性をもたらし、バリデータのハードウェア要件を下げる障壁となっています。

Beamチェーンは、ZK技術を使用した「検証」によってこの再実行プロセスを置き換えることを目指しています。これにより、バリデーターのハードウェア要件が大幅に低下し、誰でもどこからでもEthereumノードを実行できるようになります。これを実現するため、BeamチェーンとEthereumはZK SNARKを利用します。

イーサリアムプロトコル内のZK

ZK SNARKsには次の2つの特性があります:

1. 特定の計算が再実行する必要なく実行されたことを検証することができます
2. 元のデータと比較して、証明のサイズはコンパクトです

イーサリアムでの合意に必要な計算とデータにZKを適用し、指示されたロジックが守られたことを証明することが考えられています。これにより、バリデータはZKの証明を検証することで合意を達成することができ、ブロック全体を再実行し更新された状態を保存する必要がありません。ZKの証明を検証することは、データサイズとスケーラビリティの観点から見て、再実行よりもはるかに効率的です。

その結果、イーサリアムのバリデーターのハードウェア要件は劇的に削減される可能性があります。例えば、VitalikはThe Vergeの記事で述べており、その目標はバリデーターがスマートウォッチなどのリソース制約の厳しい環境でも動作できるようにすることです。

何をすればいいですか？

最初のステップは、状態遷移関数をスナーキファイすることです。状態遷移関数は一般的に以下の形式を取ります:

f(S,B)=S’

ここに:

• S: ブロックチェーンの事前状態
• B: ブロックが与えられた
• S’：ブロックを実行した後のブロックチェーンのポスト状態
• f: 状態遷移関数

すべてのブロックチェーンは決定論的な状態遷移関数に基づいており、イーサリアムも例外ではありません。イーサリアムには、コンセンサス層と実行層のための異なる状態遷移関数があります。これらの両方をスナーキファイすることで、ZKを使用してイーサリアムシステム全体を検証することが可能になり、完全に軽量なバリデータを実現します。

Beam Chainでは、コンセンサス層の状態遷移関数をスナーク化することが目標です。現在、Ethereumのコンセンサス層内の状態遷移関数は、各スロットで実行され、以下のアクションを実行します:

• ブロックを受信した後、スロットおよびブロックヘッダー情報を更新します
• ブロックを提案したバリデータの署名を検証します
• ブロック内のトランザクションを検証します
• エポックの移行時に引き出し、スラッシュ、ブロック最終化などの情報を処理します

この機能は、検証者が他の検証者からブロックを受信するたびに実行されます。この機能がsnarkifiedされた場合、検証者はもはや直接状態遷移関数を実行する必要がありません。代わりに、その関数が正しく実行されたことを示す証拠を検証できます。

この場合、ZKプルーフを生成するのは誰ですか？通常、ブロックの提案者がZKプルーフの生成も担当すると思われるかもしれません。しかし、すべてのバリデータがZKプルーフを生成できるわけではないことに注意することが重要です。

Beam Chainは、標準のノートパソコンで3秒以内にZKプルーフを生成するパフォーマンスを実現することを目指しています。しかし、この目標が達成されたとしても、スマートウォッチやスマートフォンなどのデバイスで実行されるバリデーターは、十分なリソースを持っていないかもしれません。ZKプルーフを生成するには。

ここでは、ネットワークは利他主義に依存することができます。 コンセンサスレイヤーの状態遷移に対するZKプルーフがブロックごとに1つだけ必要であり、それは必ずしもブロック提案者によって生成される必要はありません。 言い換えると、ネットワーク内の少なくとも1つの実体が各ブロックに対してZKプルーフを生成すれば、Beam Chainのブロックが正しく生成されることを保証できます。

未来:イーサリアムの完全スナーク化

この変更だけでは、バリデータのパフォーマンスが大幅に改善されるわけではありません。コンセンサス層の状態遷移関数は、実行層の状態遷移関数と比較して比較的軽量なアクションを含んでいます。しかし、主なボトルネックは状態遷移関数を実行するために必要なリソースではなく、ネットワーク帯域幅にあります。データ（ブロック）のサイズが増えると、バリデータは割り当てられた時間内にコンセンサスを達成するのに苦労します。これが、イーサリアムが過去3年間にわたって30Mのガス制限を維持している理由の1つです。

この変更が実装されると、実行レイヤーのスナーキフィケーションと併せて、バリデータはブロック全体と比べてはるかに小さなデータ量の交換しか必要ありません。これは、SNARK証明が元のデータよりもはるかにコンパクトであるためです。完全にスナーキフィケーションされたイーサリアムのバリデータは、現行システムと比べてデータの交換が少なくなり、ネットワークの要件も低減されます。

要約すると、Ethereumの完全なスナーキフィケーションのメリットは、以下の通りです。バリデーターのために。

1. バリデーターは、計算を再実行する必要はなく、証明書を確認するだけであるため、計算要件が低下します
2. バリデータは完全なブロックデータではなく、証明データを交換し、ネットワークの帯域幅要件を削減します

その結果、イーサリアムのエコシステムは大幅に変わる可能性があります。例えば:

• 「Ethereum Node Apps」のようなものは、バリデーターがモバイルデバイスで操作できるようにするかもしれません。
• 最低ステーキング要件を満たす人は誰でも、イーサリアムノードを実行できます。これにより、バリデータになるための障壁が大幅に低下します。

これにより、バリデータの参加がはるかにアクセスしやすく、分散化されます。

量子耐性署名

スナーキングすることだけで、ビームチェーンのコンセンサスレイヤーとしての状態遷移関数は十分ですか？

ポスト量子世界でイーサリアムはどのような問題に直面するのでしょうか？

Beam Chainが目指すもうひとつの領域は、シグネチャー生成です。イーサリアムのコンセンサスレイヤーは現在、バリデーターの署名を認証データとして使用してブロックをファイナライズし、フォークの場合に正しいチェーンを決定します。

イーサリアムは現在、この目的のためにBLS署名を使用しています。これは、前述のように、集約の特性を持ち、複数の署名を1つに組み合わせることができます。この集約により、イーサリアムのコンセンサスプロセスの効率が大幅に向上します。ただし、この署名メカニズムには基本的な問題があり、量子コンピュータの攻撃に対して脆弱です。

イーサリアムのビーコンチェーンで使用されるBLS署名は、楕円曲線に基づいています。楕円曲線に基づいた署名メカニズムのセキュリティは、量子コンピュータの優れた計算能力によって危険にさらされる離散対数問題（DLP）に依存しています。これにより、楕円曲線に基づいた署名は、量子コンピュータに対して本質的に脆弱です。

Googleの最近のWillowなどの量子コンピューティングチップの進化により、量子コンピューティングは急速に進んでいます。Googleは、Willowが超コンピュータで10^25年かかる計算を5分で実行できると主張しています。これは、楕円曲線のセキュリティに根本的な脅威をまだ与えていませんが、このペースでの継続的な進歩は数年以内にブロックチェーンシステムを危険にさらす可能性があります。

(耐量子計算機暗号標準への移行 |源：NIST IR 8547)

アメリカ国立標準技術研究所（NIST）は、既存のシステムの量子コンピュータによる崩壊を受けて、量子耐性署名アルゴリズムの標準化に取り組み始めました。

イーサリアムもこの問題を真剣に受け止めています。Beam Chainでは、量子耐性署名アルゴリズムの実現を目指しています。

量子耐性署名にはいくつかのタイプがありますが、JustinのBeam Chainプレゼンテーションでは特にハッシュベースの署名アルゴリズムが言及されています。楕円曲線とは異なり、ハッシュベースの署名は数学的なメカニズムに依存していないため、量子コンピュータにとっては破ることがはるかに難しいです。その結果、ハッシュベースの署名は量子に耐性があり、Beam Chainはそのような署名を採用することを目指しています。

課題とZKの役割

メインの課題は、ハッシュベースの署名にBLS署名に存在する集約性が欠けていることです。Ethereumでは、効率を実現するために署名の集約を利用しています。集約がなければ、Ethereumは大規模なバリデータセットを収容することができなくなります。

ZKはこれを処理するために使用できます。それは、複数のZKプルーフを1つのプルーフに組み合わせる技術であるProof Aggregationを活用することを含みます。このメカニズムは次のように機能します:

(Proof Aggregationのダイアグラム | 出典: Figment Capital)

1. バリデーターは、量子耐性アルゴリズムを使用してブロックに署名します。
2. 署名はアグリゲーターに送信されます**または集約委員会。
3. アグリゲータは、署名の正しさを検証するZKプルーフを生成します。
4. 証明の集約技術を使用することで、集約器は新しい証明を既存の証明と組み合わせ、新しい署名が受信されるたびに結合します。

このアプローチにより、EthereumはBLS署名の集約と同じ効率を実現しつつ、コンセンサスレベルで量子耐性を獲得することができます。

BeamチェーンにおけるZKの役割

要約すると、ZKを備えたBeamチェーンには以下の利点があります:

1. コンセンサスレイヤーの状態遷移関数に対する再実行ではなく、検証を行うことで、軽量検証者の要件に貢献しています。
2. 量子耐性署名の集約アルゴリズムの基盤として機能し、コンセンサス層の効率を向上させるために使用されます。

BeamチェーンにおけるZKの基盤としてのzkVM

Beam ChainのZKの基礎となる証明システムはzkVMになります。Risc-VベースのzkVMは、任意の言語でプログラムの証明を可能にし、より柔軟性を提供します。

(BEAMの状態遷移がRisc-Vにコンパイルされ、zkVMで証明されます | ソース: ジャスティン・ドレイクによるビームチェーンの発表)

これは、Ethereumの既存のクライアントエコシステムとよく合致しており、複数の言語で開発されているため、Ethereumの多様性と耐障害性を保持しています。将来のBeamチェーンでは、さまざまなクライアントが状態遷移関数を複数のプログラミング言語で書き、Risc-Vにコンパイルし、任意のRisc-VベースのzkVMで検証できるようにします。そのため、zkVMはBeamチェーンにとって自然な選択肢です。

結論

Beamチェーンが正常に実装された場合、イーサリアムはおそらく以下の機能を持つでしょう:

1. ユーザーは4秒以内にトランザクションの確認を体験し、12秒以内に確定します。
2. バリデータはZKプルーフを使用してコンセンサスレイヤーでの状態遷移を検証します。実行レイヤーもスナーキング化されている場合、バリデータはコンセンサスに参加するために最小限のデータしか必要ありません。
3. Validator signatures will be quantum-resistan
4. t、量子コンピューターによるイーサリアムのコンセンサスの危険を防ぐ。

現在、Beam Chainは公式にEthereumのロードマップの一部として認識されていません。実装するには、長い期間にわたる広範な調査、開発、テストが必要です。ただし、EthereumがBeam Chainフォークを進める場合、その結果としてのUX改善は変革的なものとなる可能性があります。

ビーコンチェーンの視点から、イーサリアムが5年後にどのように進化するかの探求はこれで終わりです。次の記事では、UXと検閲耐性の2つの視点から、2025年のイーサリアムの姿を考察します。

付録：BEAMチェーンのよくある質問

(Q): Justin Drakeの提案は非公開で議論されました。これはEthereumの「オープン」なコアバリューと矛盾しませんか？

(A): いいえ、そうではありません。Beam Chain提案は単に、ある一定の部分を一度に実装することを提案しているだけです。それが実装されるかどうかは、まだコミュニティの議論が必要なものです。上記で議論されたトピックはすでに関連するEIPやEthresear.chの投稿があります。これにより、Beam Chainは、以前に公開されていなかった新しい方向を提案する提案ではありません。さらに、Ethereumのロードマップに関する議論は、二週ごとのAll Core Devs Callで公開され、誰でも参加できます。誰かがロードマップに反対する場合や新しいアイデアがある場合、これらのミーティングで意見を述べるか、EIPやEthresear.chの投稿として新しい提案を提出することができます。

要約すると、JustinのBeam Chain提案は、ロードマップを変更することではなく、むしろロードマップの一部を単一の名前やミームの下にグループ化することに関するものです。

(Q): 5年でBeam Chainを実装するのは長すぎると思いませんか？

(A): 5年は長い時間に感じるかもしれませんが、2つの要素を考慮する必要があります:

1. イーサリアムはマルチクライアントアーキテクチャ上に構築されています。
2. イーサリアムは、どのブロックチェーンよりも多くのバリデータを持っています。

(Consensus client diversity | Source: イーサリアムクライアントの多様性)

イーサリアムのコンセンサスメカニズムは、BFTベースのプロトコルに従っており、バリデータのうち1/3以上が他の者と異なる行動を取れば、ブロックは最終確定されません。イーサリアムがたった1つまたは2つのクライアントで構築されていた場合、これらのクライアントにバグがあれば、ブロックの生成が混乱する可能性があります。そのため、イーサリアムは常に複数のプログラミング言語で開発されたマルチクライアントアーキテクチャを目指してきました。この多様性は、イーサリアムの現在のクライアントエコシステムで明らかです。

画像に示されているように、イーサリアムのコンセンサス層は現在、少なくとも4つのクライアントで動作しています。ビーコンチェーンをビームチェーンに置き換えるためには、4つのクライアントチーム全員が開発に協力する必要があります。これを考慮すると、イーサリアムの大規模な検証者セットを考慮すると、ビームチェーンの開発プロセスは安定性を優先し、数ヶ月または1〜2年という時間枠で加速することはできません。

免責事項：

1. この記事は[から転載されています。2077research]. すべての著作権は元の著者に帰属します [sm-stack]. もし、この転載に異議がある場合は、お問い合わせください。ゲート・ラーンチーム、そして彼らは迅速に対処します。
2. 責任の免責事項: この記事で表現されている意見や考えは、著者個人のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームは記事の翻訳を他の言語に行っています。特に言及されていない限り、翻訳された記事の複製、配布、盗作は禁止されています。