イーサリアムが提案した新しいビームチェーンはETHの状況を変えることができますか?

中級11/21/2024, 7:56:12 AM
イーサリアムのコア開発者であるジャスティン・ドレイク氏は、過去数年間でイーサリアムの「最も野心的な」コンセンサスレイヤーの変更提案であるビームチェーンを発表し、「古い」イーサリアムビーコンチェーンに代わる一連のZKテクノロジーを導入しました。しかし、市場はそれを買わなかったようで、記者会見が行われている間にイーサリアムの価格は急落しました。誰もが考えているようです:財団にはコインを売る別の言い訳がありますか?

編集者注:今日の午後、バンコクで開催されたDevconイベントのメイン会場で、イーサリアムのコア開発者であるジャスティン・ドレイクは、過去数年間でイーサリアムの「最も野心的な」コンセンサスレイヤーの変更提案である「ビームチェーン」を発表しました。会議でジャスティン氏は、新しいコンセンサスレイヤーの開発は2030年まで続く可能性があると述べました。しかし、市場はそれを買わなかったようで、記者会見が行われている間にイーサリアムの価格は急落しました。誰もが考えているようです:財団にはコインを売る別の言い訳がありますか?

次に、スピーチの全文をご紹介します:

今年私が多くの時間を投資したプロジェクトは「Beam Chain」と呼ばれます。Beam Chainは、研究ロードマップから最新かつ最も先進的なアイデアを取り入れたコンセンサスレイヤーの再設計です。目標は、現在のBeacon Chainから安全かつ迅速な方法でこの設計に移行し、それがイーサリアムにより近い最終形になることです。

画像ソース: Uncommons Dasong

さらに共有する前に、免責事項が2つあります。まず第一に、これは私だけの提案であり、コンセンサスが得られた場合のみ前進します。第二に、新しいトークンや新しいネットワークはありません。同じティッカーを引き続き使用します。Vitalikはこれについて非常に明確でした。

次のトークでは、私は見た目には狂った考えを理にかなった提案に変えて説明しようとします-つまり、合意レイヤーを完全に再設計することです。

まず、Beam Chainの大きな枠組みビジョンについてお話ししたいと思います。Beam Chainの範囲はコンセンサス層に焦点を当てており、blobとEVMはアプリケーションによって直接使用され、上位互換性を維持する必要があるため、これら2つの層を変更する機会は比較的限られているため、データレイヤーのブロブと実行レイヤーのEVMは含まれていません。コンセンサス層はアプリケーションによって直接消費されないため、この点で調整の余地があります。

なぜBEAMチェーン?

なぜ私は今、コンセンサスレイヤーの大規模なリファクタリングを提案しているのか?

主な理由は、ビーコンチェーンがすでに少し「古い」ということです。

「仕様」は5年前に凍結されましたが、その5年間で多くのことが変化しました。特に、新しい視点に対する理解は5年前よりも深まっています。5年前はPoWに関して比較的に素朴でしたが、その後市場は急速に成長し、MEVの負の外部性を緩和するためのメカニズムに対する理解も深まりました。

エンジニアリングの観点からは、SNARKsという非常に強力な技術が現在利用可能です。過去5年間で、SNARKs技術において多くのブレークスルーがあり、その速度は桁違いに向上しました。同時に、zkVMsの誕生も見られ、世界中のプログラマーがこの強力な技術を利用することができ、暗号技術に精通している必要もなくなりました。

さらに、時間が経つにつれて、私たちはBeacon Chainで犯されたミスと蓄積された技術的負債について明確な理解を持つようになりました。これらの負債は非常に頑固で、時間とともに増えていきます。

今、おそらく私たちはこの技術的負債を整理する機会があるかもしれません。したがって、私はコンセンサスレイヤーロードマップから最も先進的な技術をBeam Chainに統合することをお勧めします。

Beam Chainには、どのような変更が含まれていますか?

次に、コンセンサスレイヤーのロードマップに含まれる具体的な内容を説明します。基本的には9つの異なるプロジェクトがあり、それらをブロック生成、ステーキング、および暗号化の3つのカテゴリに分けました。

ソース:Aaros.183

1つ目は、MEVを含むブロック生産です。現在、ブロックビルダーとリレイヤーレベルでの集中化の問題が多数あります。検閲への耐性を大幅に向上させるために、「インクルージョンリスト」を導入したいと考えています。インクルージョンリストが検閲に耐性を持つようになれば、バリデーターをブロック生成プロセスから明確に分離できるようになります。これは提案者と構築者の分離 (PBS) と呼ばれ、実行関数などのアイデアが含まれます。

ブロック生産カテゴリーの最後のアイテムは、より高速なタイムスロットです。現在の12秒のタイムスロットを変更せずに、さらにタイムスロットを短縮することができ、オーストラリアでもネットワークの遅延が高くても、ユーザーはバリデーターとして参加し、一流の権利を享受することができます。

第二のカテゴリは担保です。研究者たちは、現行の発行曲線に欠陥があり、イーサリアムの健全性と長期的な発展を改善するための調整の機会があるという点で大きく合意に達しています。ステーキングカテゴリの第2のプロジェクトは、現在の32 ETHからわずか1 ETHにバリデータになるために必要なETHを大幅に削減することです。

最近、「オービット」に関するいくつかのアイデアが出ています。さらに、数年間議論されてきたもう1つのアイデアは、シングルスロット最終性で、これによりイーサリアムの最終性プロセスを大幅に高速化できる可能性があります。

最後のカテゴリは暗号化で、2つの重要なプロジェクトが含まれています。最初のプロジェクトは、合理的なハードウェアサポートを備えたリアルタイムでの完全なコンセンサスレイヤーのSNARK検証です。

最終的には、イーサリアムのセキュリティを確保するための暗号化を、数十年、あるいは数世紀にわたって持続可能で量子攻撃に耐えるものとすることはできるのでしょうか?

ここでは、ロードマップ内のアイテムが簡単にまたは段階的に完了できるか、または実現が困難かを区別するために異なる色を使用しています。左上隅の4つの緑のプロジェクトは、ビーコンチェーンで段階的に実装できると思われるプロジェクトであり、これらの小規模プロジェクトが完了すると、より包括的なアプローチを経て最善と考えられるいくつかの重要なプロジェクト(赤い部分)が残ります。

「変更通知」を例にとると、合理的なハードウェアでビーコンチェーンのリアルタイム証明を実現するために、ハッシュ関数、署名方法、および状態のシリアライズとMerkel化方法を変更する必要があります。これはビーコンチェーンにとって大きな変更になるため、他の改良と一緒にこれらの調整を行う機会があるかもしれません。

同様の状況は、下部の2つの赤いボックスの「Faster Slots」と「Faster Finality」にも適用されます。5年前にBeacon Chainを設計したとき、焦点はセキュリティであり、パフォーマンスではありませんでした。しかし、今では、必要なセキュリティを維持しながら、パフォーマンスを向上させ、いくつかの簡単に達成できるパフォーマンスの改善を進めることができる設計があることがわかっています。

このPPTには、私がちょうど言及したコンセンサスレイヤーロードマップからVitalikのより広範なロードマップへのマッピングが示されています。私たちのプロジェクトの一部はマージフェーズにあり、一部はスカージフェーズにあり、そして一部はバージとスカージフェーズにあります。

このPPTの核心目的は、Beam Chainが全体的なロードマップを変更しているのではなく、特定のサブセットを特定し、それを加速し、それに独自の意味を与えることを伝えることです。

ソース:Aaros.183

コンセンサスレイヤーのロードマップの「より速いタイムスロット」は新しいもので、より速いタイムスロットについての議論は2024年に始まりましたが、Vitalikのロードマップは2023年に最後に更新されました。

これらの重要なプロジェクトを加速させることができるだけでなく、以前に言及されたいくつかの技術的負債も解消することができます。 シングルソースの最終性を実装すれば、エポックは不要になり、スロットを直接使用できます。 また、現在の預金契約はやや複雑で、合併からの遺産です。ビーコンチェーンのリアルタイムSNARKingが実現された後は、同期委員会などのインフラが不要になります。 これは一挙に片付ける好機です。

Beacon Chainの設計上のいくつかの問題に興味がある場合、昨年、Beacon Chainの設計時に私たちが犯した20以上のミスについて完全な講演を行いました。

この図は、合意レイヤーのアップグレードの完全な全体像を示しています。左下の角に見えるように、ジェネシスは2020年に起こり、その後毎年新しいフォークがあり、それぞれのフォークで合意レイヤーを段階的に改善してきました。

2021年には同期委員会を追加し、2022年にはマージを行い、2023年には出金機能とネイティブなダイナミックシャーディングを追加し、2025年には最大有効残高を増やします。

これからも、この数年間にわたって、私たちはこれらの増分のフォークを作り続け、ロードマップの左上隅に緑色でマークされた低難易度のプロジェクトを手に入れることを期待しています。

徐々に私たちはボトルネックに直面することになります。低難易度のプロジェクトがすべて完了すると、残りは徐々に実装するのが難しい主要なプロジェクトです。この時、「Beam Fork」が必要です。ビームフォークは、一度のアップグレードを通じてコンセンサスレイヤーで大きな飛躍をする機会を提供します。ビームフォークをバッチングの機会と考えてください。複数のアップグレードが単一のフォークにマージされ、技術的およびガバナンス上の利点が両方得られます。

このバッチ処理の機会は、「固体化されたアクセラレーショニズム」と呼ばれることがあります。これは矛盾した言葉のように聞こえますが、基本的な考え方は、イーサリアムをできるだけ早くメンテナンスモードに移行させたいというものであり、現在そのような緊張が存在しています。私たちは、イーサリアムの基本的な再構築を必要とする重要なプロジェクトがいくつかあることを知っています。これらの変更が遅れれば遅れるほど、イーサリアムが安定した状態に達するまでの時間はさらに延びることになります。

Beam Chainはどのような技術を使用していますか?

次はパート2です。ここでは、Beam Chainで使用されるいくつかの技術を紹介します。これをイーサリアムのコンセンサスメカニズムの異なる時代と考えてください。最初はProof of Work(POW)時代、次にProof of Stake(POS)時代に移行し、そして今回はZero Knowledge Proof(ZK)時代に入る可能性があります。

ZK時代には、SNARKs技術を大々的に活用します。既にSNARKsを使用している1つの場所は、Beam Chain全体のゼロ知識検証を提供することです - すべてのコンセンサスレイヤー - これがzkVMs(ゼロ知識仮想マシン)が非常に役立つ場所です。

Beam Chainを異なる高水準プログラミング言語(RustやGoなど)で実装し、それらの高水準言語をzkVMが理解できるバイトコードにコンパイルすることができると想像してみてください。その結果、低水準の詳細を気にすることなく、SNARK検証が実現できます。

強調する必要があるのは、SNARKの検証が必要なのは、コンセンサスクライアントになるための中核であるステートトランジション関数のみであるということです。基本的に、ステートトランジション関数はクライアントビルドの非常に小さな部分であり、周囲のインフラストラクチャ(ネットワーキング、同期、キャッシュ最適化、ブロック選択ルールなど)にはSNARKの検証が必要ありません。

これらのzkVMの業界標準として、RISC-Vが過去数年間で確立されてきました。RISC-Vは、基本的に高水準のコードをRISC-V命令にコンパイルする命令セットです。RISC ZeroやSP1など、RISC-V zkVMを提供している企業は現在7社あります。お聞きになったことがあるかもしれません。

この強力なテクノロジーは、Beam Chainとは異なる話ですが、実行レイヤーでも使用することができることに注意することが重要です。これは非常に興味深いです。なぜなら、ガスキャップを大幅に増やし、EthereumをL1垂直スケーラビリティとして向上させることができるからですが、これは別の話題です。

Beam ChainでSNARKが広く使用されているもう一つの場所は、集約可能署名です。私たちは量子耐性のある集約可能署名を持ちたいと考えています。ここでの提案は、ハッシュ関数を使用することです。ハッシュ関数は量子耐性があり、暗号を構築するための基本モジュールとして使用できます。

私たちは、検証者と証明者によって生成されるハッシュベースの署名を使用し、数千の署名を単一の証明に圧縮できるハッシュベースのSNARKを導入します。これら2つを組み合わせることで、量子耐性のある集約可能なハッシュベースのソリューションをEthereumで使用できます。興味深いのは、この集約スキームは無限再帰集約の機能を持っていることであり、これにより、現在のBLS署名では不可能であり、柔軟性に優れています。

今日この提案をする理由は、最近数ヶ月でSNARKハッシュ関数の性能が大幅に向上したためです。詳細を知っている方々には、これをラップトップ上で検証できるようになりました。

このベンチマークはMacBook ProのCPUで完了し、現在は毎秒200万のハッシュを検証できます。これは驚異的な速度であり、これはハッシュベースの提案がBeam Chainで優れたパフォーマンスを持つ可能性を意味します。

zkVMとSNARKsに加えて、大部分は既存のインフラストラクチャを再利用することを強調したいと思います。

たとえば、ネットワークライブラリのlibp2p、シリアライズライブラリSimple Serializeなどは直接再利用できます。Pyspecフレームワークも同様で、形式仕様とユニットテストを記述するために使用しています。

さらに、Protocol Guildなどのインフラストラクチャも再利用できます。これらはBeacon Chainの初期に存在しなかったものですが、現在は無料で再利用できます。

同様に、現在、Beacon Chainの開発をサポートする複数のチームがあります。当時、私たちにはコンセンサスのあるクライアントチームはありませんでした。現在の5つのコンセンサスクライアントチームは、再編成することなく直接使用できます。

さらに、Panda Opsチームによって提供されるDevOpsサポートなど、統合オペレーションを担当する専門チームがあります。セキュリティチームやモチベーションチームなどのアプリケーション研究グループも、直接活用できるリソースです。

最後に、次のステップと将来の展望について話したいと思います。 1つの可能性として、2025年から正常化プロセスに入ることが考えられます。 これは少数の研究者によって実施され、1年間かかるかもしれません。 2026年には、クライアントチームが本番用のコードを記述し、2027年には非常に徹底したテストプロセスが行われ、本番展開のセキュリティと安定性を確保します。

画像の出典:Uncommons Dasong

研究者としての次の仕事は、私が「実行可能なロードマップ」と呼ぶ実行可能な仕様書の作成を開始することです。そのアイデアは、ロードマップの「ピクセル」、さまざまな研究や学術論文の何十万もの言葉、研究者の心にあるさまざまな考えを組み合わせ、それらの核心を抽出し、実行可能な仕様書を形成することです。最終的に、これは非常にコンパクトなドキュメントになります。Pythonコードで約1000行です。

私にとって興奮しているのは、Beam Chainの新しい方向について一般的な合意があれば、これが合意クライアントに新しい血を注入する絶好の機会になるということです。

現在、私たちのコンセンサスクライアントチームは北アメリカ、ヨーロッパ、オセアニアにまたがっています。今日、ビームクライアントを開発することに意欲を示した新しいチームが存在することを嬉しく思います。その1つはインドに拠点を置くZineというチームであり、Zig言語を使用してBeamクライアントを作成しています。また、南アメリカに拠点を置くLambda ClassチームもBeamクライアントの開発に関心を示しています。

参加に興味がある場合は、仕様およびネットワークの専門家、コーディネータ、暗号専門家、クライアント開発者など、多くの有能な人材が必要です。私たちと一緒にこの新しい冒険を始めるために、このメールアドレスでお問い合わせください。ありがとうございます!

免責事項:

  1. この記事は[から転載されていますBlockBeats], すべての著作権は元の著者に帰属します [BlockBeats]. If there are objections to this reprint, please contact the gateラーンチームはそれに迅速に対応します。
  2. 責任の免責事項:この記事で表現される見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 記事の翻訳は、ゲートのLearnチームによって他の言語に行われます。特に記載されていない限り、翻訳された記事のコピー、配布、盗作は禁止されています。
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.