ペクトラ・アップグレードには何が含まれるのか？

Devcon SEAでのChristine Kimによるプレゼンテーション。イーサリアムのペクトラ・アップグレードに含まれるEIP、プロトコルの変更点、メインネットでの有効化の時期、そしてスコープから外されたEIPについて解説します。

このトランスクリプトは、イーサリアム財団が公開した元のビデオのトランスクリプト (opens in a new tab)のアクセシブルなコピーです。読みやすさのために軽く編集されています。

はじめに (0:00)

ペクトラ・アップグレードに含まれるすべてのEIPについてお話しします。始める前に簡単な免責事項をお伝えします。これからお話しすることはすべて情報提供のみを目的としており、財務的または投資的なアドバイスとして解釈されるべきではありません。

ペクトラのメインネットはいつか (0:23)

ペクトラに何が含まれるかについて入る前に、私が最もよく聞かれる質問は「ペクトラはいつメインネットに導入されるのか？」というものです。技術的な話に入る前に、まずはこの疑問にお答えしておきましょう。

これは非常に暫定的なタイムラインの分析です。ペクトラがいつ実施されるかと聞かれたとき、私は「まだ早すぎてわからない」と答えます。なぜなら、それが事実だからです。ペクトラはまだ開発の非常に初期の段階にあります。仕様は変更されており、ペクトラのスコープはまだ完全にはファイナライズ済みではありません。

このプロセスを通じて学べることの1つは、アップグレードがどのように開発され、テストされ、最終的にメインネットに導入されるかということです。最初に、開発者はアップグレードに含めるいくつかのEIPを決定し、それらのEIPをデブネットと呼ばれる開発者向けのプライベートなテストネットに実装します。開発者はすでにペクトラ用のデブネットをいくつか立ち上げており、これらのEIPはすでに数回の実装ラウンドを経ています。開発者は修正したいエッジケースやバグに気づき、新しいデブネットを立ち上げることでこれらのEIPを反復的に改善しています。デブネット4は先月10月に立ち上げられました。

通常はこのようなことはありませんが、開発者はこのカンファレンス全体と聴衆の皆さんのために特別に、今月最初の公開ペクトラ・テストネットを立ち上げました。これはMekongと呼ばれており、ペクトラに含まれる予定のいくつかのEIPに早期に触れることができます。これはデブネット4の仕様に基づいていますが、これらの仕様は変更される可能性があることに注意してください。

開発者がすでにペクトラのデブネット5に含めたいと考えているEIPの仕様変更のリストがあります。例えば、BLSプリコンパイルの価格再設定や、デブネット4には実装されていないものの、開発者がデブネット5または将来のアップグレードでの実装を目指している新しいEIPなどです。このように、ペクトラの仕様は変更され続けています。仕様が完全に凍結されるまでには、さらに複数のデブネットを経る必要があると予想しています。

ペクトラ・アップグレードがメインネットに向けて進む上で非常に重要なもう1つの部分は、スコープがファイナライズ済みになること、つまりペクトラに含まれるすべてのEIPが決定されることです。まだ正式なEIPではありませんが、開発者がまだペクトラに正式に含めていないブロブ容量の増加に関する提案があります。しかし、実行レイヤーとコンセンサス・レイヤーにパラメータをハードコードするのではなく、コンセンサス・レイヤーを通じてブロブのガス・ターゲットと最大ガスを動的に更新するメカニズムを導入するEIPが最近含まれたため、何らかの形でブロブ容量の増加が含まれる可能性が高いと思われます。

スコープがファイナライズ済みになると、実装した新しいEIP（ペクトラ・アップグレードの全スコープ）のテストを開始し、さらにいくつかのデブネットで実戦テストを行います。おそらくデブネット6か7まで続くと予想しています。そして、ペクトラの仕様が凍結され、準備が整うと（開発者がデブネットで見つけられるすべてのエッジケースが発見されると）、ペクトラ・アップグレードが公開のイーサリアム・テストネットにリリースされます。現在、SepoliaとHoleskyの2つがあります。

歴史的に、開発者は公開テストネットのアップグレード間に約2週間の期間を設けてきました。まれに、テストネット間のタイムラインをわずか1週間に短縮したこともありましたが、ペクトラの規模を考慮すると、開発者は十分な時間をかけたいと考えるでしょう。SepoliaとHoleskyにはおよそ1ヶ月を見込んでおり、その後ようやくメインネットでの有効化が行われます。

現在私が知っているすべての情報と、開発者がこれまでにペクトラで進めてきた進捗を考慮すると、私の最善の分析と推測では、ペクトラのメインネットは現実的に2025年4月に行われるでしょう。繰り返しますが、多くのことが変わる可能性があるため、これは非常に暫定的なものです。開発は週単位で行われており、開発者はACDコールで、このEIPで予期していなかったバグや、ペクトラに追加したい新しいEIPについて話し合っています。

実行レイヤーのEIP (6:23)

それでは、このトークの核心である、ペクトラ・アップグレードに何が含まれるのかについて移りましょう。ペクトラには10個のEIPが含まれており、そのうち4つは実行レイヤーに焦点を当てています。

EIP-2537は、EVMへの新しいプリコンパイルであるBLS12-381曲線演算です。これは、スマート・コントラクト開発者が長い間求めてきた新しい暗号技術による署名スキームです。このEIPは2020年に作成され、当時、分散型アプリケーション (dapp) の開発者は、ゼロ知識暗号技術に依存する特定のdappに強力なプライバシー保証を与え、セキュリティとスケーラビリティを向上させる可能性があるため、これを強く望んでいると述べていました。BLS署名は、バリデータのアテステーションのためにコンセンサス・レイヤーで行われる集約でもあります。このEIPは長い間待たれていたものです。懸念事項の1つは、BLSプリコンパイルを待っているアプリがまだ存在し、それが稼働したときに使用されるのかということです。しかし、もしこの会場にいて、BLSプリコンパイルがついに導入されることを知らなかった方がいれば、お伝えします。ついに導入されます。

EIP-2935 — 状態から過去のブロックハッシュを提供する。これは、過去のブロックの証明を状態から生成できるように、実行レイヤーに変更を導入するものです。ライト・クライアントの同期や、過去のブロックの状態に関するデータをEVMを通じて直接利用したいスマート・コントラクトにとって、短期的な利点があります（現在は実際にはそれができません）。しかし、これらの短期的な利点が、このEIPがペクトラに含まれた主な理由ではありません。主な理由は、これがイーサリアムの状態データ構造の大規模な見直しであるVerkleの前提条件だからです。開発者はその移行がペクトラの直後に行われると考えていましたが、Verkleはフサカには含まれません。別のアップグレードに先送りされましたが、この足がかりはすでにリストからチェックされています。

EIP-7685 — 汎用的な実行レイヤーのリクエスト。このEIPはイーサリアムに新しい機能を導入するものではなく、ペクトラ内の他のEIPをサポートするためのEIPです。ペクトラには、実行レイヤーが以前はできなかった、はるかに多くのメッセージ（さまざまな種類のメッセージ）をコンセンサス・レイヤーに渡すことができるようになるEIPがいくつかあります。実行レイヤー上のスマート・コントラクトは、バリデータの引き出し、統合、およびデポジットをトリガーできるようになります。これらの新しい通信チャネルをすべて個別の独自の方法で実装するのではなく、このEIPはこれらのリクエストを格納するための一般化された構造（一般化されたバス）を作成します。これにより、テストが容易になり、クライアント間での実装が容易になり、特に開発者が実行レイヤーでトリガー可能な新しいタイプのリクエストを導入したい場合に標準化が容易になります。

EIP-7702 — 外部所有アカウント (EOA) のコード設定。イーサリアムに新しいトランザクション・タイプが導入されます。このトランザクション・タイプにより、EOAは一時的により大きな柔軟性を持つようになり、トランザクションのバッチ処理、スポンサー付きトランザクション、条件付きトランザクション、委任されたセキュリティなどの機能が可能になります。「これはイーサリアムでアカウント抽象化のビジョンが実現するということか？」と思われるかもしれませんが、そうではありません。これはほんの小さな一歩です。イーサリアムにおける真のネイティブなアカウント抽象化への実際のロードマップがどのようなものになるかを確認するための初期段階です。開発者がその最初の一歩をどのように踏み出すべきかについてはかなりの議論があり、このEIPの導入とその設計をめぐっては多くの論争がありましたが、最終的に導入されることになりました。

コンセンサス・レイヤーのEIP (12:00)

他にも6つあります。これらはコンセンサス・レイヤーのEIPです。

EIP-7742 — コンセンサス・レイヤーと実行レイヤー間のブロブ数の分離。これはペクトラに含まれることになった最も新しいEIPです。現在、ブロブ容量はすべての異なるクライアントの実行レイヤーとコンセンサス・レイヤーにハードコードされています。そのハードコーディングを更新することは、一部の人が考えるほど簡単ではありません。コンセンサス・レイヤーを通じてブロブ容量を動的に設定するメカニズムを作成することで、将来的に開発者がイーサリアムのブロブ容量を簡単に変更できるようになり、そのようなアップグレードには両方のレイヤーの変更ではなく、コンセンサス・レイヤーの変更のみが必要になることが保証されます。

EIP-6110 — バリデータのデポジットをオンチェーンで提供する。マージが完了し、イーサリアムはプルーフ・オブ・ステーク (PoS) ブロックチェーンとしてより成熟しました。現在では、特定のセキュリティの前提を緩和することができます。このEIPは、デポジット・コントラクトに32 ETHをデポジットするたびにコンセンサス・レイヤー側で行われる追加の投票ラウンドを削除し、すべてのデポジットの検証が実行レイヤーで行われるようにします。これはバリデータのUXに利点をもたらします。32 ETHをデポジットしてから、ビーコン・チェーン上でバリデータが実際に有効化されるまでの時間を短縮します。

EIP-7002 — 実行レイヤーでトリガー可能な引き出し。これはステーキング・プールにとって非常に有益です。現在、バリデータを完全に引き出したい場合、そのバリデータを運用するノード・オペレーターは、引き出し鍵を使用してバリデータを完全にエグジットさせる必要があります。このEIPにより、スマート・コントラクトがそれらの完全な引き出しを開始できるようになります。これはステーキング・プールから取り除くことができる信頼の前提です。LidoやRocket Poolなどのスマート・コントラクトベースのステーキング・プールは、必要に応じてバリデータの完全な引き出しをトリガーできるようになります。

EIP-7251 — 最大有効残高の増加。これは本当に問題となっています。開発者がビーコン・チェーンについて考えていたとき、バリデータ・セットがこれほど急速に成長するとは予想していませんでした。現在、約120万から130万のバリデータが存在します。多くのアクティブなバリデータが存在し、ネットワーキング・レイヤーで多くのメッセージがやり取りされており、負荷が大きすぎます。ノードに負担をかけており、放置すればイーサリアムの健全性にとって大きな問題となるでしょう。EIP-7251は、バリデータがETHを統合し、32 ETHを超える最大有効残高を持つことを奨励するように設計されており、イーサリアム上のアクティブなバリデータの数を減らします。

EIP-7549 — コミッティのインデックスをアテステーションの外部に移動する。これは、イーサリアムのネットワーキング負荷を軽減し、ノードの帯域幅を節約するために、アテステーションが集約される方法を再構築およびリファクタリングするものです。開発者がこれをペクトラに含めたとき、素晴らしい利点を持つ優れた変更であり、簡単なものだと考えていました。しかし実際には、予想よりもはるかに実装が難しいことが判明しました。

まとめ (17:19)

ペクトラはさまざまなアップデートの寄せ集めです。主に3つのことを行います。第一に、プルーフ・オブ・ステーク (PoS) ブロックチェーンとしてのイーサリアムの重大な欠点を修正します。MaxEBについて考えてみてください。バリデータ・セットのサイズが制限なく成長し続ける可能性があるため、これは重要な修正です。第二に、ユーザー・エクスペリエンスを向上させます。新しいトランザクション・タイプ、より柔軟な設計、ステーキング・プールのためのよりトラストレスな設計に向けたいくつかの改善などです。そして第三に、イーサリアムのデータ可用性の容量を増やします。これはまだ正式にペクトラに含まれていませんが、その可能性は高いと思われます。

ペクトラから削除されたEIP (18:02)

以下は、ペクトラから削除されたすべてのEIPです。1つのアップグレードでこれほど多くのEIPが削除されるのは、ある意味で初めてのことです。

PeerDAS — 当初、ペクトラではデータ可用性の容量がはるかに大きく増加する予定でした。PeerDASにより、開発者はイーサリアム・ノードを実行するための帯域幅の消費や計算要件に大きな影響を与えることなく、イーサリアムのブロブ・ターゲットを何倍にも増やすことができるはずでした。しかし、これはまだ研究開発の段階にあります。

EOF — EVMオブジェクト・フォーマット。これら11のコード変更のバンドルは、イーサリアムEVMへの主要なアップデートです。PeerDASとEOFはどちらも当初ペクトラに含まれていましたが、別々のデブネットでテストされていました。開発者は、メインネットでの有効化の準備にはるかに多くの時間が必要になると考え、他のペクトラのEIPを遅らせたくありませんでした。そのため、PeerDASとEOFには明らかにさらに時間が必要であると判断し、それらを別のアップグレードに先送りして、他のペクトラのEIPのメインネット導入を妨げないようにしました。

これらは現在フサカに移行されています。Verkleは当初フサカに予定されていましたが、その後さらに延期されました。EOFとPeerDASは今のところフサカに含まれています。開発者がフサカへの追加を再検討する他のEIPもあります。SSZへの移行、インクルージョン・リスト、発行の変更、履歴の失効、ePBS、そしてアカウント抽象化の方向性などです。

Q&A (22:02)

ホスト: EOFはいつになりますか？

Christine Kim: 文字通り今言ったばかりですが、開発者はそれをフサカに入れようとしています。それが実現する可能性が高いと思うか？ おそらくそうではないでしょう。フサカが2025年に実施されると思うか？ 絶対にありません。ペクトラの準備にかかった時間を考えると、フサカにも同じくらい、あるいはそれ以上の時間がかかるでしょう。

ホスト: 今からペクトラの有効化までの間に、ブロブ・ターゲットを増やすための緊急の手段はありますか？

Christine Kim: ありません。ブロブ・ターゲットは、実行レイヤーとコンセンサス・レイヤーにハードコードされたパラメータです。ブロブ容量を変更するには、開発者はハード・フォークを行う必要があります。今からペクトラまでの間に、ハード・フォークなしでブロブ容量を増やす方法はないと思います。

ホスト: 提案はブロブの制限のみを変更するものですか、それともブロブ・ターゲットも変更するものですか？

Christine Kim: 素晴らしい質問です。最も保守的な増加は3から4への変更で、ターゲットのみを変更し、最大値はまったく変更しません。しかし、それはレイヤー2 (L2) の開発者が求めているものではありません。Baseチーム（CoinbaseのBaseチーム）の代表者がおり、彼はより積極的な増加を求めて競い合っています。彼は、その増加がイーサリアムの分散化に悪影響を与えないことを示唆するデータを示しています。ターゲットのみを変更するという保守的な提案もあれば、最大値とターゲットの両方を変更するというより野心的な提案（例えば8と4、または6と12など）もあります。さまざまな段階があります。

ホスト: あなたは人々にガバナンスにもっと関与するよう促しました。コミュニティはどのようにしてより深く関与できるのでしょうか？

Christine Kim: ETH ResearchとETH Magiciansは、特定のEIPに賛成票を投じたり、支持を表明したりするための非常に優れた2つのディスカッション・フォーラムです。ACDコールはおそらく最もシグナルが高い場所です。GitHubのACDコールのアジェンダにコメントを残し、これがあなたが話したい、またはプレゼンテーションしたいEIPであると伝えるだけで済みます。コールのモデレーターは通常、快く時間を割いてくれます。ただし、あまり時間をかけすぎないようにしてください。意見を述べるのは5分程度にしましょう。