ギャラクシー：イーサネット・ネットワークの次なる起爆剤、ペクトラに注目

著者：Christine Kim、Galaxy; コンパイラー：Whitewater、Golden Finance

まえがき

このレポートでは、Pectraのアップグレードの概要と、10月時点のメインネット活性化までの予想スケジュール、バリデータ、ETH保有者、投資家について説明します。最後に、このレポートでは、履歴の失効、組み込み提案者ビルダー分離（ePBS）、バークルツリー移行など、ペクトラと並行して行われたプロトコル開発に関する洞察を共有しています。

始まり

Bragg-Electra、略して「ペクトラ」は、次のイーサのアップグレードの名前です。名前以外のアップグレードに関する詳細は、開発者が11月に計画を始めて以来、流動的でした。しかし、Pectraに何が含まれるかを議論する際、Verkle移行以外のイーサリアムプロトコルの最優先事項が何であるかについて、開発者たちの意見が一致していることは明らかです。開発者たちは、Verkle移行がPectra後のアップグレードの焦点となるべきだという点では合意していますが、Verkleの前にどのようなコード変更を優先させるかは明確ではありませんでした。

背景として、Verkle移行はEtherの状態データ構造の大幅なオーバーホールです。ステータスは、すべてのEtherアカウントの現在の残高、それらを制御するコントラクトコード、およびストレージデータを指します。開発者は、すべてのステートデータをMerkle Patricia Tree構造からVerkle構造に移行する予定です。これにより、ノードは状態データに関するより小さな証明を生成し、より簡単に他のノードに渡すことができるようになる。将来的には、開発者は「ステートレス・クライアント」と呼ばれる、イーサネットの状態記録を維持する必要のないノードをユーザーが実行することを想定している。リソースに制約のあるデバイス上で動作するこれらの軽量ノードは、ブロックを検証するために必要な情報を受け取り、チェーンが進むように、ステートレコードを保存するネットワーク内の他のノード（「ステートフル・クライアント」と呼ばれる）が生成する証明に依存する。基本的に、バークルの移行は、ユーザーがノードを実行しやすくすることで、イーサリアムの分散化を改善することを目的としています。

EtherStateデータベースのリファクタリングは複雑であるため、開発者たちはPectraの次のアップグレード（Fulu-Osaka、または「Fusaka」と呼ばれる）をVerkle専用に予約することに合意しました。アップグレードの技術的リスクを最小限に抑えるためだ。開発者たちは、Verkleへの移行というより困難な作業に全神経を集中する前に、Pectraは簡単に完了できるマイナーなアップグレードになると期待しています。

2024年8月末までに、ペクトラはイーサネット改良提案 (EIPs) の数でイーサネット史上最大のアップグレードになります。開発者たちはペクトラに20のEIPを含めることに合意し、9月上旬にはそのリストにさらにEIPを追加することを検討しています。しかし、ペクトラの大きな範囲はイーサリアム開発者やその他の利害関係者にとって論争や懸念の種となっています。その規模の大きさゆえに、ペクトラは、実装が計画されている20のEIPに隠れたバグや脆弱性が含まれていないことを確認するために、特に並行して実装される場合には、広範なテストとシミュレーションを必要とします。

2024年5月、イーサネットのアップグレードのテストを組織する役割を担っていたイーサネット財団のエンジニアグループ、EthPandaOpsチームは、ペクトラのアップグレードを2つに分割することを提案するブログ投稿を共有しました。当時、このアイデアは、Pectraのアクティベーション後に予定されていたVerkleへの移行が遅れるかもしれないという懸念から、真剣に検討されることはなかった。イーサネット財団の研究者であるアレックス・ストークス（Alex Stokes）氏は、9月初旬に開催されたAll Core Developers Execution call #196で、このアイデアを再び持ち出した。この時、開発者たちはこのアイデアに同意し、そうすることでアップグレードの最初の部分を6ヶ月以内に提供できると主張しました。

その結果、Pectraに含まれるすべてのEIPは、1回ではなく2回のハードフォークで実装される予定です。最初のハードフォークの範囲には、ペクトラのリストにある20のEIPのうち8つが含まれます。リストにある他の12のEIPについては、開発者は最初の8つのEIPの後にメインネットに実装するために並行して作業を続けます。

ペクトラの概要

2024年10月現在、開発者はペクトラの範囲を拡大し、追加のコード変更であるEIP 7742を含めることに合意しています。 このコード変更をペクトラに組み込むことでこのコード変更をペクトラに組み込むことで、開発者はペクトラでもブロブ容量を増やすことが可能になります。現在、9つのEIPがあります。 2025年初頭にメインネットのアクティベーションが暫定的に予定されているペクトラのアップグレードには、以下の10のコード変更が含まれる可能性があります:

全体として、ペクトラにはイーサに対する一連のアップデートが含まれており、3つの成果を達成することが期待されています:

• Proof-of-interest blockchainとしてのプロトコルの役割における重要な欠陥を修正

• Ether上のスマートコントラクトアプリとやりとりする際のユーザーエクスペリエンス（UX）を改善

• Etherがデータを利用可能にする能力を改善

表面的には、UXの改善とDAレイヤーとしてのイーサの改善は、エンドユーザーがイーサ上でスマートコントラクトとやり取りすることから離れ、代わりにロールアップ上でスマートコントラクトと安価な方法でやり取りすることを促すことを意図しています。しかし、イーサのUX改善は「トリクルダウン」効果をもたらす可能性があります。つまり、メインネットで実装されると、ロールアップでも採用される可能性が高く、ロールアップとイーサの両方のエンドユーザーに恩恵をもたらすということです。

注目すべきは、PectraはETHの「健全な通貨」または価値貯蔵としての物語を強化するためのコード変更を一切行っていないことです。さらに、EIPのどれも、検閲に強いブロックチェーンとしてのイーサの質を直接改善するものではありません。この問題は、合併アップグレード以降、ブロック構築プロセスに関わる既知の規制対象エンティティの数が増えたため、開発者にとっての優先事項となっています。

イーサ上のブロックの50%以上がOFAC準拠のリレーによって生成されており、これは、これらのブロックの作成を担当するエンティティが、米国市場に上場されているイーサのアドレスとやりとりするトランザクションを意図的に除外していることを意味します。

開発者は、将来のアップグレードでETHのリリースを減らし、検閲耐性を高めるためのコード変更に取り組んでいます。しかし、それらはペクトラの焦点ではありません。

Fusaka Overview

Pectra の次のアップグレードの名前は Fusaka で、開発者がアップグレードの範囲を確定していないため、Fusaka のスケジュールを見積もるのは困難です。しかし、ペクトラのアップグレードが完了した後、開発者はフサカの優先順位と準備状況に基づいてEIPを再評価する予定です。

参考までに、12のコード変更を以下に示します。

参考までに、12のコード変更を以下に示します。

最初のEIP以外はすべて、Ethernet仮想マシン(EVM)の側面を変更するコード変更であることに注意してください。EOFは、EVMの構築方法とコード処理方法に重要な変更を加え、スマートコントラクトのコード実行をより予測可能、安全、コスト効率的にすることで、スマートコントラクト開発者のエクスペリエンスを向上させることが期待されています。

PeerDASとEOFに加え、2024年10月時点でFusakaへの組み込みが検討される可能性のあるコード変更の一覧は以下の通りです:

Account AbstractionとVerkleを除く、上記のすべてのイニシアチブは、ペクトラのアップグレード候補として議論されてきましたが、コード変更に関するコンセンサスが得られなかったため、アップグレードには含まれていません。となり、アップグレードには含まれませんでした。これらの構想の多くについては、その設計が実施可能な状態になるまでには、まだ多くの調査が必要である。上表の最後の列は、これらのコード変更の準備状況を1から3までランク付けしたもので、3はすぐに実施可能、1は開発の初期段階である。

上記の取り組みのうち、インベントリーの組み込みとSSZへの移行は最も成熟しています。なぜなら、イーサ上の完全なアカウント抽象化への道はまだ不透明であり、そのロードマップの多くは、ペクトラのEIP 7702によって影響を受けるからです。

これらの並行イニシアチブに関連する不確実性を考えると、メインネットの準備やETHの価値に与える影響を評価することは、現時点では有益ではありません。しかし、一連の10のコード変更は、2025年までにイーサのステークホルダーに影響を与える可能性があります。

本レポートの次のセクションでは、ペクトラのEIPがネットワーク関係者とETHの価値に与えると予想される影響について、より詳しく説明します。

クリティカルな修正とクリティカルでない修正

ペクトラには、プルーフ・オブ・ステーク・ブロックチェーンとしてのイーサの運用にとって重要なEIPが1つあります。 EIP 7251は、バリデータの最大有効残高を32ETHから2048ETHに増やし、最大有効残高が32ETHの既存のバリデータが株式を統合できるようにします。これにより、2024年9月時点で100万人を超えているEther Validatorsの数が減少すると予想されます。

イーサネット財団（EF）のエンジニアが実施したイーサのシミュレーションによると、140万人のバリデータが存在するため、プロトコルは深刻なネットワーク問題を経験しています。 EIP 7251は、誓約されたETHの統合を促進することで、ネットワークの圧力を緩和することが期待されています。大規模なバリデータセットに関する問題の詳細については、このGalaxy Researchのレポートをお読みください。

32ETHのバリデーターを支える理由

Beacon Chainはもともと、最大有効残高が32ETHのバリデーターを想定して設計されていました。これは、プロトコル開発者が多くの参加者にProof of Equityコンセンサスプロトコルへの参加を促したかったからです。開発者は控えめに見積もって、32ETHの場合、ビーコンチェーンはおよそ312,500人の検証者を引き付け、これらの検証者によって生成された暗号署名を集約することで、新生チェーンを保護するのに十分であると予想している。

2020年12月にビーコンチェーンが稼動したときのETHの価格は約600ドルで、資金が2万ドル未満のユーザーでも独自に検証機を稼動させ、Stake Rewardsを獲得することができた。当時、Stake Rewardsには取引手数料やMEV報酬は含まれておらず、ユーザーは資金を引き出すことができなかったため、Stakeにはかなりのリスクが伴いました。

参加を促すことに加えて、32ETHという有効残高が選ばれたのは、「シャーディング」によってビーコンチェーンを拡張する当初の設計では、各バリデータが同じ有効残高を維持する必要があったからです。すべてのユーザーが32ETHより高い誓約残高を維持することを要求された場合、開発者はチェーンを確保するのに十分なバリデータが存在しなくなることを懸念するだろう。すべてのユーザーが32ETH以下の誓約残高を維持する場合、バリデータが多すぎてイーサネットネットワークレイヤーに不必要な負担がかかることが懸念されます。

32ETHの最大有効残高に加え、開発者はプロトコルにその他多数の定数やパラメータを設定しており、これらはイーサ上の誓約に対する将来の需要を大まかに見積もったものです。開発者の見積もりが非常に不正確だった場合、その後のハードフォークによってチェーンの経済性とプレッジパラメータを調整できると考えたのだ。今日、LidoやCoinbaseのような流動性誓約ソリューションの急速な採用は、イーサの発行曲線を下げるために開発者の間で議論を呼び起こしました。

最後に、イーサのネットワークレイヤーの真の容量について誤った思い込みがあるかもしれません。2021年のブログ投稿で、Etherの創設者であるVitalik Buterin氏は、ビーコンチェーンの設計仕様では、現実的に410万人の検証者のオーバーヘッドをサポートできる、またはETHの全供給量を誓約でき、最大有効残高は32ETHであると書いています。ましてや400万人以上である。

EIP 7251の実装の詳細

EIP 7251は実装が複雑なコード変更です。これは、プロトコルが検証者の報酬、ペナルティ、引き出しを計算する方法を根本的に変更します。アクティブな検証者の数に基づいてこれらの計算を行う代わりに、プロトコルは検証者の合計アクティブ残高に基づいて計算を行います。

特に、関連する削減ペナルティを変更する過程で、開発者は、有効残高の小さい検証者が有効残高の大きい検証者に比べて不釣り合いにペナルティを受けるエッジケースを発見しました。このエッジケースは、ペクトラのテストプロセス中に解決された。2024年10月現在、開発者はまだEIP 7251仕様のバグを特定し、その解決に取り組んでいます。

計算の更新に加え、EIPは検証者が既存の検証者を統合するための新しい操作を導入し、統合を奨励するために、有効残高が大きい検証者の初期削減ペナルティを下方に調整する。

一旦有効化されると、大規模な誓約主体がどの程度迅速にバリデーターを統合し、ネットワークストレスを軽減できるかは不明である。現在からバリデーターの統合が有効になるまでの間に、バリデーターセットのサイズが急増すると、ネットワークの健全性や、低品位のハードウェアやインターネット帯域幅が制限された場所でバリデーターを実行しているネットワーク参加者に悪影響を及ぼすことが懸念されます。

次のチャートは、Dencunのアップグレード以降のアクティブなバリデータ数の増加を示しています。 Dencunのアップグレードとは、Etherの1エポックあたりの最大バリデータエントリ数を15から一定の値である8に減らすことを指します。以下のチャートは、バリデータが8に減少してからの新しいバリデータエントリのアクティビティに基づいて、Etherバリデータセットの成長のための予測エントリチャーンを示しています。以下の予測は保守的であり、Ether上のEigenlayerやその他の再プレッジングサービスの再プレッジングなど、プレッジング需要の潜在的な将来の触媒を考慮していないことは注目に値します。Eigenlayerのような再誓約プロトコルの成熟。

重要でない修正

EIP 7251に加えて、プロトコルには、Pectraのアップグレードで有効になる、重要でない修正や拡張が多数あります。

• EIP 7549, 委員会インデックスの証明外への移動 - CLクライアントソフトウェアをより効率的にするために、このコード変更では、リファクタリングが導入されました。このコード変更は、検証者証明メッセージのリファクタリングを導入する。

• EIP 6110, Provisioning of Validator Deposits on the Chain - このコード変更により、新しく誓約されたETHデポジットの検証責任がCLからELに移ります。開発者は、デポジットのセキュリティを向上させ、CLクライアント側のプロトコルの複雑さを軽減し、EL上の32ETHのデポジットとCL上のバリデータの新しいアクティブ化の間の待ち時間を短縮することによって、プレッジのユーザーエクスペリエンスを向上させることができます。

• EIP 2935, Providing Historical Block Hash from State - ELに変更を導入し、過去のブロックの証明を状態から生成できるようにします。スマートコントラクト開発者が以前のブロックからイーサの状態に関する情報にアクセスできるようになるため、スマートコントラクト開発者にいくつかの追加機能を提供する可能性があります。主に、これはVerkle移行に備えるために必要なコード変更です。

• EIP 7685、Generic Execution Layer Requests - スマートコントラクトをトリガーとするCLへのリクエストを保存するための汎用フレームワークを作成します。スマートコントラクトに基づく誓約プールの人気が高まっているため、スマートコントラクトがCL上でバリデータの引き出し（EIP 7002）とマージ（EIP 7251）を直接トリガーできるようにする必要があります。このコード変更により、CLが簡単に処理できるように、これらのタイプのリクエストを保存するプロトコルフレームワークが導入されます。

予想される影響

Pectraで有効化される重要および非重要な修正は、主にバリデーター・ノード・オペレーターに影響します。彼らは、EIP 7251の高い有効残高、EIP 7549の効率性の向上、およびEIP 6110のマイナーなユーザー・エクスペリエンスの改善を利用するために、業務を更新しなければなりません。後者はEIP 7251のようなコード変更の実装を改善しますが、それ以外にネットワークの現状を改善するものではありません。

エンドユーザーとETHホルダーは、これら5つのコード変更から直接恩恵を受けることはないと予想されます。これらのコード変更は主に、プルーフ・オブ・ステーク・ブロックチェーンとしてのイーサの健全性と回復力に利益をもたらします。これらは、プロトコルが安全かつ円滑に動作し続けることを保証するため、長期的にはプロトコルの価値にとってプラスとなる。しかし、エンドユーザー、スマートコントラクト開発者、アグリゲーターにとって、ユーザーエクスペリエンスを実質的に向上させるような新機能を導入するものではない。そのため、ETHの価値に不釣り合いな影響を与えることはないと予想されます。

イーサのネットワーク全体のアップグレードと同様に、ETHのボラティリティはペクトラの前後で強まる可能性が高く、アップグレードに関連する予期せぬエラーや障害が発生した場合、価格がマイナスに変動する可能性があります。はっきりさせておくと、ペクトラのアップグレードが失敗する可能性は、メインネットワークからネットワークに障害が発生した場合に備えて、これらのコード変更を有効にする前に広範な実戦テストを行ったことを考えると、小さい。したがって、修復プロトコルのさまざまな部分に関連するペクトラのコード変更は、アップグレード前とアップグレード直後のETHの一時的な変動を除けば、ETHの価値に長期的なプラスまたはマイナスの影響を与えることはないと予想されます。

影響を受けるステークホルダー：検証ノード運営者

ETHに予想される影響：中立

ユーザーエクスペリエンスの改善

ペクトラには、イーサのエンドユーザーとスマートコントラクト開発者のためのユーザーエクスペリエンスの改善を導入する3つのEIPがあります。の開発者がユーザーエクスペリエンスの改善を導入するための3つのEIPがあります。集約中心のロードマップを追求する一方で、開発者は、主要な汎用ブロックチェーンとしてのEtherの価値提案を改善するために協調して努力しています。

EIP 2537、BLS12-381曲線算術のプリコンパイル - ゼロ知識暗号で広く使用されている代数構造であるBLS12-381曲線上の算術を効率的に実行するための新しい関数を追加します。ゼロ知識暗号は、より強力なプライバシー保証、セキュリティ、スケーラビリティなど、ブロックチェーンベースのアプリケーションに複数の利点を提供できます。BLS曲線上で演算を実行できることは、すでにゼロ知識証明システムを使用しているか、そのようなシステムを業務に統合しようとしているイーサ上に構築されたアプリケーションやアグリゲーションに利益をもたらすでしょう。

EIP 7002、実行レイヤーのトリガー可能な引き出し - EIP7002はステートフル・プリコンパイルを作成し、バリデータの引き出しのためにEVMの状態を変更するメカニズムです。現在、ビーコンチェーン上のバリデータは、バリデータ引き出しキーの所有者（通常はバリデータのオペレータ）の介入によってのみ引き出すことができる。 EIP 7002は、バリデータ引き出しクレデンシャルを所有するスマートコントラクトメカニズムを導入し、そのクレデンシャルを使用することで、バリデータのオペレータによる手動介入を必要とせずにバリデータの引き出しをトリガーする。これは、誓約アプリケーションにより信頼性のない設計を提供し、既存の誓約アプリケーションが、バリデータノードのオペレータの誠実な行動とそれらのアプリケーションのセキュリティに関する信頼の前提を取り除くことを可能にします。

EIP 7702、EOAアカウントコードの設定 -

エンドユーザーが、ユーザーが管理するイーサアカウントに短期的な機能を追加するための新しいトランザクションタイプを作成します。"list-style-type: disc;">

• Transaction batching（トランザクションのバッチ処理）、1つのトランザクションに署名することで複数のオンチェーン操作を承認する

• Sponsorship（スポンサーシップ）、別のアカウントに代わってトランザクションを支払う

• Privilege degradation（特権の劣化）、アカウント残高の特定の支出条件を承認する

ほとんどのユーザーがウォレットプロバイダーを通じてイーサでトランザクションを実行することを考えると、ウォレット開発者は新しいトランザクションタイプを活用し、ユーザーが簡単にアクセスできる方法でこれらの機能を設計に追加する必要があります。

予想される影響

クリティカルおよび非クリティカルな修正とは異なり、これらのコード変更はイーサ上でより完全に機能するアプリケーションの開発を直接可能にします。 7002、2537、および7702のようなEIPは、それぞれ、より信頼性のない誓約プールの設計、プライバシーを強化する分散型金融プロトコル、および安全なユーザー制御アカウントを可能にします。

影響を受けるステークホルダー：エンドユーザー、スマートコントラクト開発者

予想されるETHへの影響：ポジティブ

DAの改善

本レポートで前述したように、Pectraは別のコード変更を含む可能性があります。コード変更が含まれる可能性があります。開発者は、データ可用性 (DA) レイヤーとしてのイーサネットのスケーラビリティを向上させるために、ブロブ Gas ターゲットの小さな増加を検討しています。EIP 7594（PeerDAS）のアップグレードによる DA 機能の向上には、より大規模で複雑なコード変更が多数あります。しかし、EIP 7549はもはやPectraでアクティブではないため、DAコストを削減するために、より単純な変更を導入することが提案されています。

現在、イーサネットはブロックごとに最大6つのブロブを扱うことができ、平均ブロックが目標3つのブロブを含むように、これらのブロブのコストを動的に調整します。 Layer-2 rollup Baseの開発者であるFrancis Liは、ブロックあたりのブロブターゲットの数を5つに、ブロックあたりのブロブの最大数を8つに増やすことを提案しています。

Li氏の提案では、ターゲットとなるブロブ数を控えめに3から4に増やすだけでも、イーサでのロールアップチームの構築に役立つと指摘しています。開発者たちは、ペクトラのブロブターゲットの増加を大きく支持しています。しかし、この見解の確認とペクトラへのDA改良の正式な組み込みは、将来のACDカンファレンスコールで決定される予定です。今のところ、開発者はEIP 7742をPectraに組み込むことに合意しており、これはCLへの調整を通じてイーサネットのブロブ容量に変更を加える道を開くことになります。

• EIP 7742は、CLとEL間のブロブカウントを切り離します。 EIP 7742は、CLが最大およびターゲット・ブロブリミットを動的に調整することを可能にします。これにより、将来的なDA容量の変更は、両方のレイヤーをハードフォークする必要はなく、CLを介してのみ調整できます。

EIP7742とブロブ容量の増加に加えて、開発者はPectraまたはFusakaにおけるイーサネットDA機能の最適化に関連する2つの追加コード変更を検討しています。

• EIP 7762、MIN_BASE_FEE_PER_BLOB_GASを追加- Blobの需要がターゲットレート（現在は1ブロックあたり3 Blob）を超えると、プロトコルは自動的にMIN_BASE_FEE_PER_BLOB_GASを上方修正します。EIP 7762は、Blob料金市場がBlob需要の変動により敏感に反応し、より迅速なBlob価格の発見を可能にするように、Blobの最小基本コストをより高く調整します。

• EIP7623、コールデータのコストを引き上げる-ブロブに加え、アグリゲーションはトランザクションのコールデータフィールドを使用して、任意のデータをイーサにポストすることができます。しかし、トランザクションのコールデータフィールドを活用することは、一般的にアグリゲーションにとってよりコストがかかる。 EIP 7623はイーサブロックの最大サイズを縮小するためにコールデータのコストをさらに増やすことを目的としている。イーサリアムの開発者は、ブロブ容量を増やすことでブロックサイズを大きくするため、大量のコールデータと最大ブロブ数を含むバリデータが異常に大きなブロックを伝播するエッジケースを防ぎたいと考えています。

ペクトラでブロブスループットを増加させることは、ネットワーク上で動作する個々の誓約者の数を減らすことによって、イーサにおける分散化に悪影響を与える可能性があるため、開発者の間で議論の的になっています。スタンドアローン・プレッダーとは、自分のETHをプレッジし、プレッジプールや他の仲介サービスに頼らず、自宅やクラウドプロバイダーを通じて自分のプレッジ操作を実行するユーザーのことです。他のタイプのプレッジャーとは対照的に、独立したプレッジャーは、最もリソースに制約のあるデバイスでバリデータを操作するユーザーです。

ブロブのスループットが増加すると、バリデータを操作するための計算要件が増加する可能性があるため、一部の個人誓約者は自分のマシンを停止することになります。ACDE #197で、開発者は、Dencun後のバリデータを操作するのに苦労している個人の誓約者がすでにいるという逸話的証拠を共有しました。開発者は、ペクトラのブロブ容量を増やすことを決定する前に、単独での誓約操作の健全性についてデータに基づいた調査を行うことに合意しました。

予想される影響

短期的には、イーサのDAの改善は、レイヤー2ロールアップ（L2）からのプロトコル収益を減らし、L2シーケンサーのマージンを改善し、L2エンドユーザーのトランザクション手数料を減らすと予想されます。これらの影響は、DencunのアップグレードでEIP 4844がアクティブ化されたときに見られたものと同様であると予想されます。

影響を受けるステークホルダー: レイヤー2アグリゲーション、L2エンドユーザー、ETHホルダー

予想されるETHへの影響: ネガティブ

Pectraのタイムライン分析

開発者は、Pectraに含める2つの代替コードについて議論しました。これらの2つのコード変更は、アップグレードに含まれない可能性が高いです。これらの2つのコード変更は、ペクトラのブロブ容量が増加する可能性が高いため、ペクトラに含まれる可能性は低いです。これらはEIP 7782と

EIP 7782で、Nethermindの開発者Ben Adamsによって提案され、イーサネットのスロット時間を12秒から8秒に短縮します。このスロット時間の変更により、イーサネットのトランザクション・スループットは実質的に50パーセント向上し、トランザクションの確認速度は33パーセント低下します。ACDE #198とACDC #144で開発者がこの提案について提起した懸念は、ステートの成長速度を加速させ、Verkleへの移行をより困難にする可能性があるというものだった。さらに、イーサネット財団の研究者であるFrancesco D'Amato氏は、期間の変更は、組み込み型プロポーザルビルダー分離(ePBS)やインクルードリスト(IL)などの前向きな研究イニシアチブに悪影響を与える可能性があると述べています。

Erigonの開発者であるGiulio Rebuffo氏によって提案されたEIP 7783は、ハードフォークを必要としないため、開発者にとって比較的実装しやすいコード変更です。 EIP 7783は、クライアントチームが時間の経過とともにGasターゲットを徐々に増加させる仕組みを作ります。Gasターゲットを増やすと、ブロックに含めることができるトランザクションの最大数が増加する。 Rebuffoの提案は具体的なGasターゲットを指定しているわけではなく、開発者がターゲットを選択し、その閾値まで徐々に安全に増加させるメカニズムを提案しているに過ぎない。2024年10月に行われた最近の電話会議では、開発者たちはペクトラのアップグレードの直後にEIP7783を実施する可能性について議論した。

ペクトラに新しいEIPを追加すると、メインネットのアップグレードの起動が遅れる可能性があります。さらに、開発者がペクトラの最終的な範囲を決定するのが遅れれば遅れるほど、開発者がパブリック・イーサネット・テスト・ネットワークをアップグレードするのに時間がかかります。2024年10月現在、開発者はペクトラの最終的なスコープに近づいていないようです。その結果、ペクトラの公開テストネットのアップグレードが今年末までに稼動する可能性は低い。

ペクトラの範囲が来年1月か2月初旬に最終決定されると仮定すると、開発者は、公開イーサリアムテストネットワークのアップグレードに移る前に、プライベートテストネットワーク（開発ネットワークとも呼ばれる）でペクトラへの追加をテストする必要があります。ペクトラへの他のコード変更をテストするために少なくとも1ヶ月の予算を確保し、4月か5月にメインネットワークのアップグレードを一時的にアクティブにするために、開発者は3月にパブリックテストネットワークのアップグレードを開始することが推奨されます。

これらのタイムラインの見積もりは、開発者が今後数ヶ月の間にペクトラの範囲を最終決定するのにかかる時間や、最終的にアップグレードに追加することを決定したコード変更の複雑さによって変更される可能性があります。

ETHの価値を高めるその他の触媒

これまでのところ、ペクトラはコードの変更が混在しており、その一部はユーザーとスマートコントラクト開発者の両方のエクスペリエンスを向上させることが期待されています。ペクトラの範囲が簡素化されたため、アップグレードはETH価値に大きな影響を与えないと予想されます。Pectraに加え、イーサネットには、発行量の削減やPeerDASの実装に向けた取り組みなど、ETHの価値に直接的に影響を与える可能性のあるアップデートがその後も続く。しかし、本レポートで前述したように、これらの変更がメインネット上でいつ有効になるかを予測するのは困難です。

イーサにおけるプロトコルのアップグレードは、イーサが「集約中心のロードマップ」に基づいてさらなるDAのスケーラビリティの向上を追求するため、時間の経過とともにETHの価値への影響が減少していくはずであることは注目に値します。長期的には、アプリケーションとユーザーがL2に移行するにつれて、Etherの収益は主にL2上のユーザーアクティビティによってもたらされる可能性が高い。 L2上で発生するアップグレードは、ユーザーエクスペリエンス、相互運用性、分散化、これらのネットワーク上のセキュリティを改善することができ、これらはベースレイヤーの最適化や改善よりもEtherの価値にとって重要である。Pectraのようなアップグレードは、プロトコルの分散化とユーザビリティをさらに向上させるだろうが、ロールアップがEtherにはできない方法でこのニーズを満たすために拡張できるため、新しいユーザーの波を引き寄せ、分散型アプリケーションの採用を促進することはないだろう。したがって、ロールアップベースのアプリケーションとロールアップベースのプロトコルのアップグレード（ロールアップベースのアプリケーションの機能をさらに強化する）は、ETHの価値を高めるものを評価する際の分析の鍵となります。

ロールアップ中心のロードマップに対する一般的な抵抗は、イーサがDAレイヤーにとって安くなりすぎるかもしれないという恐れ、またはロールアップからの収益がETHの価値を支えるには小さすぎるという恐れです。これらの議論は、分散型アプリケーションの潜在的な市場全体を過小評価している。現在、暗号通貨のユースケースは世界のあらゆる産業を破壊しています。人工知能（AI）があらゆる産業を破壊する可能性を秘めているように、パブリックブロックチェーンは人間の協調活動を根本的に変える可能性を秘めており、この技術はあらゆる産業でデジタルコンテンツの生成方法を根本的に変えます。

EIP4844やPeerDASのようなスケーラビリティの向上は、短期的にはプロトコルの収益を減少させるでしょう。これらはイーサがイーサL1で可能であったよりも多くのオンチェーン活動をサポートするための土台を築いています。ゲーム、資金調達、分散型金融、ソーシャルメディアは、歴史的にイーサの取引量と手数料の急増につながったタイプのアプリケーションのほんの一例に過ぎません。これらのアプリケーションは、イーサのネットワーク効果、非中央集権性、検閲耐性、複合性を利用しています。理論的には、アグリゲーション上のアプリケーションは、大幅に低い手数料と強化された機能性（例えば、異なるタイプの仮想マシン、プログラミング言語、アカウント管理）に加えて、イーサ上でこれらすべての利点を利用できるようになります。

しかし実際には、アグリゲーションはイーサネットの分散化、検閲への耐性、コンポーザビリティといった属性を有意義に継承していません。トランザクションコストの削減には効果的ですが、分散化とセキュリティを犠牲にしています。言い換えれば、アグリゲーションは、取引コストを削減する以上の有意義な方法でイーサを拡張するものではない。L1からL2へ活動やアプリケーションを移行する際、ユーザーにはトレードオフが多すぎる。Rollupは、代替のレイヤー1ブロックチェーンで開発された他のスケーリング・ソリューションや、リプレッジ・ソリューションやZKVMのようなインフラ・プロジェクトと同様に、進行中である。Rollupが技術として成熟し、イーサの分散型の性質から恩恵を受けるまで、純粋なDAの改善はイーサやその上に構築されたRollupの新たな採用の波を促進しないかもしれません。

結論

Pectraの範囲と時間軸が不透明であるにもかかわらず、イーサは、人間の協調が中央集権的なインターネットプロトコルではなく、主に分散型ブロックチェーン技術を通じて行われるウェブ3時代の先駆者であり続けています。これを実現するためには、イーサは最大抽出価値（MEV）やトランザクション検閲といった中央集権的な力に対抗しながら、分散型テクノロジーとして拡張し続けなければならない。イーサにはこのビジョンを実現するための競争相手がいることは確かですが、ウェブ3ブロックチェーン空間を支配することは、イーサが負けるに違いないゲームであることに変わりはありません。

イーサは、汎用ブロックチェーンの中で最も高いネットワーク効果を発揮し続けています。スマートコントラクト開発者にとっては最も試行錯誤されたブロックチェーンであり、研究者や開発者の間ではスケーリング、MEV、検閲、ユーザーエクスペリエンスなどに関する課題を解決するために最も研究されているブロックチェーンであり続けています。しかし、イーサネットの開発者がロールアップ中心のロードマップを追求するにつれ、技術としてのイーサネットやイーサネットのアップグレードの重要性は薄れていくはずで、ウェブ3が直面する最大の問題の解決策はロールアップに継承されることになります。

Pectraは、新しいユーザーやスマートコントラクト開発者をWeb 3空間に引きつけると期待される、UX中心のコード変更を導入する予定です。しかし、これはユーザーとETH保有者に直接影響を与えるプロトコル上のコード変更を伴う、残された最後の数少ないアップグレードの1つかもしれません。ユーザーがRollupに移行し、プロトコルの収益がRollupの活動によってますます左右されるようになるにつれ、Ether関係者にとって最も重要なコード変更はRollupで行われるものになるでしょう。このため、技術としてのRollupの成熟度と、Etherのセキュリティを有意義に継承し、数百万人の新規ユーザーに拡大する能力を分析することが重要です。