イーサリアムのコア開発者らは、2024年末か2025年に実施される可能性のある「Dencun」に続く次のハードフォークの優先順位を議論している。
木曜日の All Core Devs の電話会議の後、Dencun フォークの暫定スケジュールは変更されず、Goerli テストネットは 17 月 XNUMX 日に最初に稼働します。
アップグレードの公開は 3 月になる可能性が高いため、開発者はプラハ-エレクトラ (略してプラレクトラ) で次に何が起こるか、それに続くアップグレードに注目を集めています。
依然として非常に流動的であり、全体的なビジョンについて議論が進行中です。機能に焦点を当てた小規模なイーサリアム改善提案 (EIP) のセットか、実行層に Verkle Trees を導入するための主要なプロトコルのアップグレードのいずれかです。
Verkle ツリーは、現在使用されているマークル ツリーを進化させた新しいデータ構造で、より洗練された数学的手法、つまり楕円曲線のペアに基づくベクトル コミットメントを使用しており、verkle 氏によると、これはマークル ツリーで使用される単純なハッシュ関数とは大きく異なります。情報。
この構造では、使用するスペースが少なくなり、検証が高速化されるため、ネットワークはより多くのトランザクションを処理できるようになります。
一言で言えば、これは「国家の肥大化」という長期的な問題に対処する方法であり、イーサリアムの規模が拡大するにつれてその重要性はますます高まっています。
このアップグレードはイーサリアムの長期ロードマップにおける重要なマイルストーンであり、この段階は「The Verge」と呼ばれます。
この呼びかけには明確な意見の一致はなかった。イーサリアム財団のギョーム・バレエ氏が「小さな分岐点など存在しない」と警告するなど、ヴァークル・ツリーに引き続き焦点を当て続けることを主張する者もいたが、ネットワークをアップグレードする断固とした取り組みを求める者もいた2024年に再び。
懸念されているのは、Verkle Trees の配信には 18 か月以上かかる可能性があるということであり、これは仮想通貨における永遠の期間に相当します。
Dencun自体は当初2024月に予定されていたが、最終的に昨年XNUMX月にXNUMX年に延期された。
続きを読む： コア開発者は今年 Dencun フォークを除外
「Verkleは、複雑さの点ではマージよりも劣らないとしても、マージと同等の規模です」とバレエ氏は語った。 「実際には、[実行層] 側で何かを同時に出荷することはできません。」
Nethermind 実行クライアント チームの Lukasz Rozmej 氏もこれに同意し、開発者が Verkle Trees に完全に移行する前に、まず機能豊富なフォークを優先することを推奨しました。
「私の経験から、州の再設計は非常に難しく、非常に長い時間がかかることが分かりました」と同氏は電話会議で同僚らに語った。 「Verkle の靭性は仕様ではなく、実装、最適化、テストです。」
機能はありますが、どの機能ですか?
機能に焦点を当てた 2024 回目の XNUMX 年のフォークを提唱している人々の中には、Nethermind、Besu、Reth のクライアント チームも含まれていました。しかし問題は、何が優先されるのかということです。
Erigon クライアント チームのソフトウェア エンジニアである Andrew Ashkhmin 氏は、EVM オブジェクト フォーマット (EOF) は、より小規模なチームで実装できるため、Verkle Trees での長期的な作業を妨げることなく次のアップグレードを推進する候補の 1 つになるだろうと示唆しました。コード ベースに対するより独立した変更でした。
「しかし、ヴァークルが主な焦点となるべきだ」と彼は言った。
EOF は当初、Shapla ハード フォーク用に検討されましたが、メインの「ドライバー」である Proto-Dank シャーディングまたは EIP-4844 と並べて「パッセンジャー」として組み合わせるには大きすぎると考えられました。
続きを読む： ブロブに焦点を当てるイーサリアムの次のアップグレード
Besu クライアント チームのプロトコル エンジニアである Justin Florentine 氏によれば、EOF は「間違いなく乗客ではない」が、Besu はすでにこの機能に関して「多くの進歩」を遂げており、したがって Pralectra での採用に賛成していると述べました。
Rust Ethereum（Reth）クライアントを構築している投資会社Paradigmの最高技術責任者兼研究員であるGeorgios Konstantopoulos氏は、彼のチームは「EOFは（）一人の仕事であり、個別のテスト（が必要）であるため、EOF（で）OKだ」と述べた。
しかし、イーサリアム財団の開発者マリウス・ファン・デル・ワイデン氏は、「EOFはスモールフォークにはならない」という意見を共有した。
イーサリアム財団のアンスガー・ディートリヒス氏は、昨年4月にPralectraにEOFを含めることを支持し、木曜日の電話会議で、EVMの主要なスマートコントラクトプログラミング言語を維持するSolidityチームが強く支持していると述べた。
しかし、この電話会議には EOF を明確に主張する人は誰もいなかったため、Nethermind 創設者の Tomasz Stanczak 氏は、「もしこの電話会議で EOF を支持する人がいなかったら、なぜまだ出荷されていないのかが要約されてしまうだろう」と発言しました。
Stanczak氏は、EIP-7002、つまり「実行層でトリガー可能な出口」をイーサリアム・マジシャンズ・フォーラムで最も支持されたEIPであり、「ステーキングに関する重大な設計バグが修正されており、十分に早期に実現できない」ため「非常に重要」であると述べた。
「Potuz」の愛称で知られるコア開発者仲間の Parithosh Jayanthi 氏は、出荷する機能を 7002 つ選択しなければならないとしたら、それは EIP-7549 だろうと述べました。しかし、彼の見解では、EIP-XNUMX は「間違いなく含まれるはずです」。
この機能はコンセンサス層にのみ影響し、イーサリアムの設計のバグを修正し、コンセンサスルールを検証するために必要なペアリングの平均数を減らすことを目的としています。ペアリングは、楕円曲線を含む特定の暗号アルゴリズムで使用される操作です。
現在、コンセンサスに達するには、バリデーター間の合意を示す最低 1366 個の認証を検証する必要がありますが、EIP-7549 以降はわずか 22 個に減少します。
「実装は簡単で、集計時間を大幅に節約できます」とポタス氏は言います。 「トラストレスブリッジ、そしてzk-provers、zk-bridgesで役立つ可能性があります。これは、私たちが次に行うどの分岐点にも必ず組み込まれるはずです。」
この電話会議の目的は議論を開始することであり、具体的なアプローチと改善提案は後日決定される予定です。イーサリアムのアップグレードはコンセンサス主導で行われます。明示的な権限の階層や、優先順位を決定するための投票メカニズムはありません。
猫の群れと同じように、前進するのは困難で混沌としているように見えることもありますが、それが分散型の動物の性質です。
次の大きなニュースをお見逃しなく – 毎日の無料ニュースレターにご参加ください。
出典: https://blockworks.co/news/ethereum-devs-plan-2024