ペクトラのアップグレードは、イーサリアムネットワークの次の重要なマイルストーンであり、2025年の第1四半期に実装される予定です。このアップグレードは、Prague (実行層) アップグレードと Electra (プロトコル層) アップグレードの 2 つの主要コンポーネントで構成されています。
Pectraは、以前の主要なアップグレードとは異なり、単一の優れた目標を持たず、代わりに複数の技術的な改善と最適化に焦点を当てています。これは、L2手数料を大幅に削減したDencunアップグレードや、ステークされたETHの引き出しが可能になり、EthereumのProof of Stake(PoS)への移行が完了したShapellaアップグレードとは対照的です。
最近、Ethereumのコア開発者(ACD、All Core Developers)は、会議の通話中にPectraアップグレードを2つのフェーズに分割する可能性について議論しました。この提案によれば、
この段階的なアプローチは、各アップグレードの規模と複雑さを管理可能な状態に保ちながら、さまざまなテクノロジの徹底的なテストと改良に十分な時間を確保することを目的としています。
この提案ではBLS12-381曲線上の事前コンパイルされた操作を導入し、BLS署名検証などの操作の効率を大幅に向上させます。既存のBN254事前コンパイルされた操作と比較して、BLS12-381はより高いセキュリティ(120ビット以上)を提供します(BN254は80ビットしか提供しません)。この改善には、基本的な曲線操作だけでなく、多重指数関数も統合されており、公開鍵と署名の効率的な集約の基盤を築いています。
この提案は、主にステートレスクライアントの実行をサポートするために、最新の8,192ブロックのハッシュをシステムコントラクトに格納することを提案しています。これにより、ステートレスクライアントは、既存のBLOCKHASHオペコードとの互換性を維持しながら、必要な履歴情報に簡単にアクセスできます。この変更により、ブロックハッシュ履歴のストレージメカニズムが簡素化され、履歴データにアクセスするための新しいアプローチが提供されます。
この提案は、バリデーターの入金プロセスをイーサリアム実行レイヤーのブロック構造に直接統合するものです。この変更により、デポジットの包含と検証の責任がコンセンサスレイヤーから実行レイヤーに移り、コンセンサスレイヤーがデポジット(またはeth1data)に投票する必要がなくなります。この方法は、預金取引の契約ログイベントを分析して預金のリストを生成することで、預金処理の安全性と効率を高めるだけでなく、ユーザーエクスペリエンスも向上させます。さらに、クライアントソフトウェアの設計が簡素化され、システム全体の複雑さが軽減されます。
この提案は、新しいメカニズムを導入し、バリデータが実行レイヤー(0x01)を介して自分の資格情報を引き出し、引き出しと脱退の操作をトリガーすることを可能にするものです。具体的には、引き出しメッセージは実行レイヤーブロックに添付され、それをコンセンサスレイヤーで処理します。このアプローチにより、バリデータはより柔軟な脱退オプションを提供されつつ、システムのセキュリティと一貫性を維持することができます。
この提案は、最大有効残高(MAX_EFFECTIVE_BALANCE)を増やすことを目的としていますが、最小ステーキング残高は32 ETHのままです。この変更には複数の利点があります:
この提案では、同じコンセンサス投票を集約するために、委員会のインデックスフィールドを署名済み証明メッセージから削除することを提案しています。この変更の主な目的は、コンセンサスルールを検証するために必要なペアリングの平均数を減らすことにより、Casper FFGクライアントの効率を向上させることです。この改善による恩恵を受けることができるすべての種類のクライアントですが、Casper FFGのコンセンサスを証明する必要があるZK回路にとって最も重要なパフォーマンス向上が期待されています。
この提案は、スマートコントラクトによってトリガーされたリクエストを保存および処理するための一般的なフレームワークを定義しています。具体的な実装では、実行ヘッダーと本文の両方にリクエスト情報を保存するフィールドが追加され、これによりこれらのリクエストがコンセンサスレイヤーに公開され、各リクエストを処理することが可能となります。このメカニズムは、主にスマートコントラクトによる検証者の制御の増加する需要に対処し、将来的により複雑なオンチェーンの相互作用の基盤を提供することを目的としています。
Vitalik Buterin 他によって提案されたEIP-7702は、イーサリアム上でのアカウント抽象化を最適化することを目的としています。この提案では、外部所有アカウント(EOA)が認可メカニズムを介してアカウントコードを設定できる新しいトランザクションタイプが導入されます。この改善により、いくつかの新機能がサポートされます。
新しいトランザクション構造を採用することで、この提案はEOAの機能性と使いやすさを向上させるだけでなく、将来のアカウント抽象化技術に対しても良好な互換性と拡張性を提供します。
Pectraのアップグレードには目立った主要目標はありませんが、一連の技術的な改善と最適化を通じて、Ethereumネットワークの機能性、セキュリティ、効率をさらに向上させます。アップグレード計画が進むにつれて、より多くのEIPが組み込まれたり調整される可能性があります。
参考文献
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.イーサリアム.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]EIP-7251:https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685:https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702:https://eips.イーサリアム.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]EIP-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]EIP-7742: https://eips.ethereum.org/EIPS/eip-7742
[12]EIP-7600:Pectra ハードフォークメタデータ:https://eips.ethereum.org/EIPS/eip-7600
[13]Ethereum コア開発者コンセンサスレイヤーミーティング#197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
この記事は[から転載されていますdwong], original title “Interpreting Ethereum Pectra: The Next Major Upgrade”, copyright Attribution to original author [ドウォン], if you have any objection to the reprint, please contact Gate Learnチーム、チームは関連手続きに従ってできるだけ早く処理します。
免責事項:この記事で表現されている見解や意見は、著者個人の見解を表しており、いかなる投資アドバイスを構成するものではありません。
記事の他の言語バージョンはGate Learnチームによって翻訳され、言及されていません。Gate.io、翻訳された記事は転載、配布、または盗用されていない可能性があります。
ペクトラのアップグレードは、イーサリアムネットワークの次の重要なマイルストーンであり、2025年の第1四半期に実装される予定です。このアップグレードは、Prague (実行層) アップグレードと Electra (プロトコル層) アップグレードの 2 つの主要コンポーネントで構成されています。
Pectraは、以前の主要なアップグレードとは異なり、単一の優れた目標を持たず、代わりに複数の技術的な改善と最適化に焦点を当てています。これは、L2手数料を大幅に削減したDencunアップグレードや、ステークされたETHの引き出しが可能になり、EthereumのProof of Stake(PoS)への移行が完了したShapellaアップグレードとは対照的です。
最近、Ethereumのコア開発者(ACD、All Core Developers)は、会議の通話中にPectraアップグレードを2つのフェーズに分割する可能性について議論しました。この提案によれば、
この段階的なアプローチは、各アップグレードの規模と複雑さを管理可能な状態に保ちながら、さまざまなテクノロジの徹底的なテストと改良に十分な時間を確保することを目的としています。
この提案ではBLS12-381曲線上の事前コンパイルされた操作を導入し、BLS署名検証などの操作の効率を大幅に向上させます。既存のBN254事前コンパイルされた操作と比較して、BLS12-381はより高いセキュリティ(120ビット以上)を提供します(BN254は80ビットしか提供しません)。この改善には、基本的な曲線操作だけでなく、多重指数関数も統合されており、公開鍵と署名の効率的な集約の基盤を築いています。
この提案は、主にステートレスクライアントの実行をサポートするために、最新の8,192ブロックのハッシュをシステムコントラクトに格納することを提案しています。これにより、ステートレスクライアントは、既存のBLOCKHASHオペコードとの互換性を維持しながら、必要な履歴情報に簡単にアクセスできます。この変更により、ブロックハッシュ履歴のストレージメカニズムが簡素化され、履歴データにアクセスするための新しいアプローチが提供されます。
この提案は、バリデーターの入金プロセスをイーサリアム実行レイヤーのブロック構造に直接統合するものです。この変更により、デポジットの包含と検証の責任がコンセンサスレイヤーから実行レイヤーに移り、コンセンサスレイヤーがデポジット(またはeth1data)に投票する必要がなくなります。この方法は、預金取引の契約ログイベントを分析して預金のリストを生成することで、預金処理の安全性と効率を高めるだけでなく、ユーザーエクスペリエンスも向上させます。さらに、クライアントソフトウェアの設計が簡素化され、システム全体の複雑さが軽減されます。
この提案は、新しいメカニズムを導入し、バリデータが実行レイヤー(0x01)を介して自分の資格情報を引き出し、引き出しと脱退の操作をトリガーすることを可能にするものです。具体的には、引き出しメッセージは実行レイヤーブロックに添付され、それをコンセンサスレイヤーで処理します。このアプローチにより、バリデータはより柔軟な脱退オプションを提供されつつ、システムのセキュリティと一貫性を維持することができます。
この提案は、最大有効残高(MAX_EFFECTIVE_BALANCE)を増やすことを目的としていますが、最小ステーキング残高は32 ETHのままです。この変更には複数の利点があります:
この提案では、同じコンセンサス投票を集約するために、委員会のインデックスフィールドを署名済み証明メッセージから削除することを提案しています。この変更の主な目的は、コンセンサスルールを検証するために必要なペアリングの平均数を減らすことにより、Casper FFGクライアントの効率を向上させることです。この改善による恩恵を受けることができるすべての種類のクライアントですが、Casper FFGのコンセンサスを証明する必要があるZK回路にとって最も重要なパフォーマンス向上が期待されています。
この提案は、スマートコントラクトによってトリガーされたリクエストを保存および処理するための一般的なフレームワークを定義しています。具体的な実装では、実行ヘッダーと本文の両方にリクエスト情報を保存するフィールドが追加され、これによりこれらのリクエストがコンセンサスレイヤーに公開され、各リクエストを処理することが可能となります。このメカニズムは、主にスマートコントラクトによる検証者の制御の増加する需要に対処し、将来的により複雑なオンチェーンの相互作用の基盤を提供することを目的としています。
Vitalik Buterin 他によって提案されたEIP-7702は、イーサリアム上でのアカウント抽象化を最適化することを目的としています。この提案では、外部所有アカウント(EOA)が認可メカニズムを介してアカウントコードを設定できる新しいトランザクションタイプが導入されます。この改善により、いくつかの新機能がサポートされます。
新しいトランザクション構造を採用することで、この提案はEOAの機能性と使いやすさを向上させるだけでなく、将来のアカウント抽象化技術に対しても良好な互換性と拡張性を提供します。
Pectraのアップグレードには目立った主要目標はありませんが、一連の技術的な改善と最適化を通じて、Ethereumネットワークの機能性、セキュリティ、効率をさらに向上させます。アップグレード計画が進むにつれて、より多くのEIPが組み込まれたり調整される可能性があります。
参考文献
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.イーサリアム.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]EIP-7251:https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685:https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702:https://eips.イーサリアム.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]EIP-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]EIP-7742: https://eips.ethereum.org/EIPS/eip-7742
[12]EIP-7600:Pectra ハードフォークメタデータ:https://eips.ethereum.org/EIPS/eip-7600
[13]Ethereum コア開発者コンセンサスレイヤーミーティング#197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
この記事は[から転載されていますdwong], original title “Interpreting Ethereum Pectra: The Next Major Upgrade”, copyright Attribution to original author [ドウォン], if you have any objection to the reprint, please contact Gate Learnチーム、チームは関連手続きに従ってできるだけ早く処理します。
免責事項:この記事で表現されている見解や意見は、著者個人の見解を表しており、いかなる投資アドバイスを構成するものではありません。
記事の他の言語バージョンはGate Learnチームによって翻訳され、言及されていません。Gate.io、翻訳された記事は転載、配布、または盗用されていない可能性があります。