▼目次
前提
2025年5月7日、イーサリアムの大型アップグレード「ペクトラ」の実装が完了しました。
本レポートは、イーサリアム（ETH）をステーキングしている投資家や、イーサリアムホルダーのうち、暗号資産（仮想通貨）イーサリアム（ETH）の価格の動向を予測するためにイーサリアムの技術動向を把握しておきたいというユーザーを対象に、今回実施された「ペクトラ（Pectra）」と呼ばれるイーサリアムのアップデートの概要を紹介します。
加えて、技術的に大きな影響をもたらす変更点と、投資家に与える影響についても考察します。
今回のペクトラアップデートは、過去のアップデートと比較しても非常に大規模なものであり、このような大規模なアップデートの概要を理解することは、イーサリアムが今後どのような方向に向かっているのかを知るうえで重要です。
また、投資家やイーサリアム（ETH）ホルダーにとっては、イーサリアムの技術的進化が市場価格やエコシステム全体に与える影響を予測するための手掛かりとなるでしょう。
イーサリアムのアップグレード・ペクトラ（Pectra） の概要
Ethereum Improvement Proposal（EIP）の作成者は主に開発者であり、イーサリアムのプロトコルに変更を提案し、議論の上で採用が決定されます。
これらの提案が採用されると、ネットワーク全体に実装され、イーサリアムクライアントに適用されることになります。
ネットワークアップグレードは、こうしたEIPの集合体で構成され、最終的に合意されたものがイーサリアムネットワーク全体に反映されます。
ペクトラ（Pectra）アップグレードも同様に、複数のEIPで構成されており、その内容はイーサリアムのパフォーマンスやセキュリティ、スケーラビリティを大きく向上させることを目的としています。
以下に、ペクトラに含まれる主なEIPを紹介します。
イーサリアムアップグレード・ペクトラ（Pectra）に含まれるEIPの一覧
- EIP-2537：楕円曲線の一種である BLS12-381 曲線上での演算を行うプレコンパイルコントラクト
- EIP-2935：ブロックハッシュをストレージに保存する
- EIP-6110：オンチェーンでのバリデーターデポジット
- EIP-7002：実行レイヤーでのバリデーターデポジットの引き出し
- EIP-7251：バリデーターデポジットの上限増加
- EIP-7549：Attestationデータから委員会インデックスを移動
- EIP-7594：PeerDAS - Peer Data Availability Sampling
- EIP-7685： 実行レイヤーにおける汎用的なリクエストの処理
- EIP-7702：EOAアカウントにコードを設定する
- EIP-7692：EOF v1 を達成するためのEIPのリスト
- EIP-7623：calldataコスト再調整
- EIP-7691：Blobスループット倍増
- EIP-7840：Blob伝搬スケジュール設定
参考：EIP-7600: Hardfork Meta - Pectra
1. EIP-2537
楕円曲線上での演算はEVMによるオペコードを用いると非常に高コストとなります。このEIPは、BLS12-381という楕円曲線上での演算をプレコンパイルコントラクトで効率的に行う提案です。
バリデーターがブロック提案や認証を行う際、BLS12-381を使用した署名を行います。BLS12-381は集約署名に特化しており、ゼロ知識証明（ZK-SNARKs）でよく使われる楕円曲線であるため、効率的な署名集約とゼロ知識証明の普及を可能にするため、この提案が行われました。
2. EIP-2935
このEIPは、ノードクライアントがブロックハッシュをストレージに保存することで、ステートレスクライアントへの対応を容易にする提案です。
現在、ノードクライアントが最新のブロックハッシュを保持していますが、Verkleによるステートレスクライアントの実装後、ノードがステートを保持しなくなるため、将来的には対応できなくなってしまいます。コントラクトストレージを拡張し、ブロックハッシュをストレージに保存することで、スムーズにステートレスクライアントへ移行する手助けになります。また、ロールアップがブロックハッシュを効率的に問い合わせられるようにすることで恩恵を受けられます。
3. EIP-6110
この提案は、バリデーターデポジットの処理をコンセンサスレイヤーから実行レイヤーに移すものです。
イーサリアムのコンセンサスにProof of Work（PoW）が使用されていた時代は、デポジットが実行レイヤーで処理され、コンセンサスレイヤーで投票を行ったのち、デポジットが確定されていました。しかし、Proof of Stake（PoS）に移行したことで、もはやコンセンサスレイヤーでの投票は必要なくなり、これを実行レイヤーに戻すことで、デポジット処理の遅延を削減します。この提案により、デポジットの確認時間が約12時間から約13分に短縮されます。
筆者作成
4. EIP-7002
バリデータが実行レイヤーを介して直接、部分的な引き出しや退出を行えるようにする提案です。
イーサリアムのバリデータには2つの鍵が存在します：
- アクティブキー（Active Key）: バリデータがブロック提案や検証などを行うために使われる「ホット」な鍵。
- 引き出し資格情報（Withdrawal Credentials）: ステーキングされたイーサリアム（ETH）を引き出すために使われる「コールド」な鍵。
これまで、バリデータの退出や引き出しは主にコンセンサスレイヤーで管理されており、アクティブキーを持つ者しか退出を制御できませんでしたが、EIP-7002は引き出し資格情報（Withdrawal Credentials）にもこの権限を与えることで、バリデータの資金管理の柔軟性を高めています。
5. EIP-7251
このEIPは、バリデータの「最大有効ステーク量（Max Effective Balance: MaxEB）」を32 ETHから2,048 ETHに引き上げる提案です。これにより、小規模なバリデーターを統合し、ネットワークの効率を向上させます。ステーキングプロセスが簡素化され、ネットワーク負荷も軽減されることが期待されます。
6. EIP-7549
ブロック構築時に必要なアテステーションメッセージ（投票）の署名数を減らすことで、ペアリングと呼ばれる重い演算を軽減する提案です。これにより、zkEVMなどゼロ知識証明回路での計算が効率化されます。
具体的には、アテステーションメッセージには主に3つの要素が含まれます。
- LMD GHOST投票: Beacon Block Root（ビーコンブロックのハッシュ値）やスロットの情報。
- Casper FFG投票: 過去のチェーンの「ソース」や最新の「ターゲット」に関する情報。
- 委員会インデックス: どの委員会に属するバリデーターがこのアテステーションを行っているか。
例えば、一つのエポック（32スロット）で、各スロットに64の委員会がある場合、それぞれの委員会がアテステーションに署名します。これにより、エポックごとに最大で32 x 64 = 2,048個の署名が行われます。また、2/3以上のバリデーターからアテステーションを得ることで、そのエポック内のブロックが最終的に確定されます。
よって、32 x 64 x 2/3 = 1366、これはつまり、1つのエポック内で検証されるべきアテステーションの最低数を表しています。
EIP7549では、委員会インデックスをアテステーションメッセージから外すことで、署名の効率化と検証コストの削減を目指しています。委員会インデックスをアテステーションメッセージの外に移動すれば、検証する必要のあるアテステーション数は32 x 2/3 = 22まで減少し、これにより62倍の効率化が可能になります。現在の設計では、委員会インデックスが含まれることで、同じ投票内容であっても異なる委員会に属するバリデーターが異なる署名を生成し、結果として多くのアテステーションを検証する必要があります。しかし、委員会インデックスをメッセージから外すことにより、同じ内容の投票であれば、異なる委員会に属していても同じの署名を使えるようになります。これにより、検証すべきアテステーションの数が大幅に減少し、ネットワーク全体の効率が向上します。
7. EIP-7594
PeerDAS（Peer Data Availability Sampling）の導入を提案しています。これにより、すべてのノードが全データをダウンロードする必要がなく、一部のデータを確認するだけでデータの可用性を確保できます。
この仕組みは、EIP-4844（Proto-Danksharding）で導入されたBlobデータに適用され、各ノードがBlobデータの一部を検証するだけでよくなります。
8. EIP-7685
スマートコントラクトが実行レイヤーに対して直接リクエストを発行し、それをコンセンサス層で処理できる仕組みを導入する提案です。
これにより、スマートコントラクトによるバリデーターの管理が自動化され、仲介者を介さずに安全なトリガー動作が可能となります。ステーキングプール管理などのユースケースにおいて、特に効果的です。
9. EIP-7702
Externally Owned Accounts（EOA）を一時的にスマートコントラクトウォレットのように動作させる新しいトランザクションタイプの導入を提案しています
新しいオペコードを追加せず、既存のイーサリアムの機能を利用してEOAを一時的にスマートコントラクト化し、トランザクションが終了するとそのコードを元に戻す仕組みです。これにより、EIP-3074が提案していた複雑な新しいオペコードの導入を避け、ネットワーク全体の互換性を保ちながら効率を向上させます。
この提案により、イーサリアムの将来的なアカウント抽象化（Account Abstraction）への移行がスムーズになります。
10. EIP-7692
Ethereum Object Format（EOF）を導入し、EVMの効率とセキュリティを向上させる提案です。EOFでは、コードとデータを分離し、デプロイ時にコードを検証する仕組みを導入することで、パフォーマンスを向上させます。また、バージョン管理の仕組みにより、将来的な拡張にも対応可能です。
https://www.youtube.com/watch?v=NMRLOwVkh88 のスライド4ページ目
追加の経緯
ペクトラ（Pectra）アップグレードの最終調整段階にて、L2スケーリング強化とネットワーク運用負荷のバランスを両立させる必要が生じ、以下の観点から3件のEIPが追加導入されました。
1. Blobスループット倍増に伴う帯域負荷の懸念
- EIP-7691でBlob数（平均3→6／最大6→9）の大幅増強案が提示され、L2ユーザーにとっての手数料低減効果は期待される一方で、ノード間伝搬およびストレージ負荷が急増するリスクが浮上したため。
- （Motivation: https://eips.ethereum.org/EIPS/eip-7691#motivation）
2. ブロックサイズ最悪ケースの抑制要請
- Blob増強によってcalldata主体のトランザクションと併用した際、ブロックあたりのデータ量が過度に膨らみ得る点が指摘され、最悪ケースでの帯域飽和や検証遅延を防ぐ仕組みが必要とされたため。
- （Motivation: https://eips.ethereum.org/EIPS/eip-7623#motivation）
3. クライアント運用の柔軟性向上
- ネットワーク状況や運用ポリシーに応じてBlob処理パラメータを動的に切り替えられるよう、EL（実行レイヤー）設定ファイルにスケジュール機能を組み込む提案がなされたため。
- （Motivation: https://eips.ethereum.org/EIPS/eip-7840#motivation）
追加されたEIPの概要
以下、最終段階で追加された3件のEIPについて、目的と主要な変更点をまとめます。
EIP-7623：calldataコスト再調整
●目的：Rollupのcalldata増加とBlob併用時におけるブロックサイズ最悪ケース（最大7.15 MB超）がノード運用を圧迫しないよう、calldataのコストモデルを再設計し、データ量に上限を設ける。
●変更点：
- zeroバイト・nonzeroバイト双方に「floor cost」を新設し、ガス計算に上限制御を追加
- 通常時のデータ送信への影響を最小化しつつ、最悪ケースの帯域使用量を約0.72 MBに抑制
●参照：https://eips.ethereum.org/EIPS/eip-7623
EIP-7691：Blobスループット倍増
●目的：Dencun導入後のL2向けデータ可用性機能（Blob）をさらに強化し、L2ユーザーの手数料削減効果を拡大。
●変更点：
- 1ブロックあたりのBlob数目標値を3→6に、最大値を6→9に引き上げ
- ネットワーク全体のデータ処理能力向上を図りつつ、EIP-7623と組み合わせて過負荷リスクを緩和
●参照：https://eips.ethereum.org/EIPS/eip-7691
EIP-7840：Blob伝搬スケジュール設定
●目的：実行レイヤー設定ファイル内でBlob伝搬パラメータ（target／max／baseFeeUpdateFraction）を定義可能とし、ネットワーク状況に応じた動的調整を実現。
●変更点：
- EL設定ファイルに blobSchedule オプションを追加
- クライアント起動時の設定のみで各フォーク後のBlob設定を自動適用
●参照：https://eips.ethereum.org/EIPS/eip-7840
イーサリアム（ETH）の課題を解決する技術的に影響の大きいEIP
ここでは、特に技術的なアプローチでイーサリアムの課題を解決しているEIPについて詳しく紹介します。
イーサリアムは、継続的に技術的なアップデートを行うことで、そのパフォーマンスやセキュリティ、スケーラビリティを向上させてきました。
これらのアップデートにより、イーサリアムのエコシステム全体が進化し、イーサリアム（ETH）価格や関連するプロジェクトの価値に大きな影響を与えることが多々あります。
そこで、技術的に影響の大きいEIPを理解することで、投資家はイーサリアムの動向を把握し、より賢明な投資判断を下すことが可能になります。
EIP-7594：データ可用性問題へのアプローチ
L2（レイヤー2）ソリューションの普及に伴い、データ可用性の問題が注目されています。
データ可用性とは、ブロックの検証に必要なデータがネットワーク参加者に利用可能であることを意味します。
従来のアプローチでは、全データを各ノードが保存し、ネットワーク全体で同期させる必要がありました。
しかし、これではデータ量が増大し、検証コストやノードの必要ストレージ容量が増えるため、分散性を損なう可能性があります 。
参考：https://ethereum.org/ja/developers/docs/data-availability/#the-data-availability-problem
EIP-7594は、PeerDAS（Peer Data Availability Sampling）というソリューションを用いてこの問題を解決しようとしています。
DASは、データ全体を分割し、各ノードがデータの一部分のみを検証することで、全体の可用性を確認する技術です。
この方法により、全データを保持する必要がなくなり、ノードのストレージ要件が大幅に減少します。
分割したデータはP2P（Peer to Peer）でやり取りされますが、既存のP2Pライブラリを用いて行われるので、比較的少ない変更で運用することができます。
PeerDAS（Peer-to-Peer Data Availability Sampling）の原理
PeerDASの原理について簡単に紹介します。
PeerDASでは、データを冗長に符号化し、少なくともデータの50%以上が利用可能であれば、全体を復元できるように設計されています。
また、分割されたデータをネットワーク全体に伝搬する際に、既存のP2Pコンポーネントを使って行われます。
この仕組みによって、各ノードは他のノードがどれだけのデータ可用性を持っているかを把握できるため、最適なノードと接続して必要なデータを効率的に取得できます。
これにより、無駄な通信を削減し、データ伝搬の効率を高めることが可能です。
データの可用性の検証においては、すべてのデータセルを確認する必要はありません。
PeerDASでは、各ノードが最低でもランダムに選ばれた8つのセルを検証する必要があります。
これらのセルは決定論的に決められるため、各ノードが別々のセルを選んでも、ネットワーク全体で統計的にデータ全体の可用性を確認することができます。
筆者作成
各ノードが自分の担当するセルを検証し、それが正しいことを確認した場合、そのセルに対するKZGコミットメント（データの正確性を保証する暗号的証明）によって、他のノードにもそのセルの正当性が証明されます。
これにより、全ノードが同じデータの正確性に合意でき、効率的なデータ可用性の検証が行われる仕組みです。
このプロセスにより、分散ネットワーク全体でデータ可用性が保証されつつ、全データを保持する必要がなくなるため、ノード運用の負担が軽減されます。
参考：https://medium.com/gaudiy-web3-and-ai-lab-jp/ef5bea05cf00
考察：L2ソリューションの促進
EIP-7594の導入により、各ノードが保持すべきL2トランザクションデータ（blob）の量が大幅に減少するため、ノード運用に必要なストレージや帯域幅の要件が引き下げられます。
これにより、個人や小規模な組織でもノードを運用しやすくなり、ネットワーク全体の分散性が向上します。
また、現在1ブロックに1MBと決められているblobデータの上限を引き上げることも可能で、L2のスループットが向上する可能性もあります。
EIP-7702：EOAにスマートアカウントの機能を追加
EIP-7702はAA（Account Abstraction：アカウント抽象化）の実現に向けた取り組みです。
AAとは、従来のExternally Owned Account（EOA）とコントラクトアカウントの機能差をなくし、コントラクトアカウントからもトランザクションを発行できるようにする技術です。
これにより、ウォレットのセキュリティが強化され、柔軟なトランザクション処理が可能となります 。
ウォレットのセキュリティ問題として、EOAではインターネット接続中に秘密鍵が流出すると、全資産が盗まれるリスクがあります。
また、EOAで使われるECDSA署名方式は量子コンピュータの発展により破られる可能性が指摘されています。
このため、AAでは、柔軟かつ安全な署名方式を採用できるようにし、こうしたリスクに対処します。
AAを完全に実現するためには、コントラクトアカウントから直接トランザクションを発行できるようなアップデートが必要です。
しかし、EIP-7702の目的はそのような完全なAAの実現ではありません。
この提案は、現在のExternally Owned Account（EOA）に新たな機能を追加し、スマートアカウント（コントラクトアカウント）と同じような機能を提供することを目指しています。
EIP-3074との関連
従来の提案であるEIP-3074では、AuthとAuthCallオペコードを導入し、EOAが一時的にスマートコントラクトに権限を委任できる仕組みを提案しています。
しかし、このアプローチではいくつかの問題が発生します。AUTHとAUTHCALLというオペコードを導入することで互換性の問題が生じることと、将来的にAAが完全に実現された際にはこれらのオペコードが不要になる可能性があります。
EOAから一時的に権限を委託されて実行される「invokerコントラクト」と、スマートコントラクトウォレットの仕組みが分断され、別々に進化するリスクがあります。
そこで、EIP-7702は、オペコードを変更せずに、EIP-3074と同様の機能を提供することを目的としています。
EIP-7702が提供する機能
EIP-7702は、以下の3つの主要な機能をEOAに追加します：
- トランザクションのバッチ処理: 複数の操作を1つのトランザクションにまとめて実行できるようにすることで、ガス代の削減を実現します。
- ガス代のスポンサーシップ: 他のアカウントのガス代を肩代わりできる仕組みを提供します。これにより、ユーザーが自分でガス代を支払うことなくトランザクションを実行できる場面が増えます。
- 権限の階層化: 特定の権限を持つサブキーを使って、安全にアカウントの一部の機能のみを実行できるようにします。
EIP-7702の技術的実装
EIP-7702では、トランザクションフィールドに新たにcontract_codeというフィールドが追加されます。
このフィールドにスマートコントラクトのコードをエンコードして入力することで、通常はコードを持たないEOAに一時的なスマートコントラクト機能を与えることができます。
具体的な流れは次の通りです：
- スマートコントラクトコードへの署名：ユーザーのウォレットは、トランザクションに含まれるスマートコントラクトコードにデジタル署名を行います。この署名によって、そのコードに対する一時的な操作権限を与えます。これにより、EOAが通常のトランザクションに加え、スマートコントラクトのロジックを実行できる状態となります。
- トランザクション実行中の動作： 署名されたスマートコントラクトコードは、トランザクション中にEthereum Virtual Machine（EVM）によって実行されます。このプロセスで、EOAは一時的にスマートコントラクトとしての機能を持ち、トランザクションに含まれる複雑なロジックを実行可能です。例えば、バッチトランザクションやガス代の肩代わり、あるいは特定の権限を委譲したサブキーを用いた操作が含まれる場合でも、これを実行できます。
- トランザクション完了後の復帰： トランザクションが完了すると、そのスマートコントラクトコードは破棄され、EOAは再び通常の状態に戻ります。これにより、トランザクション中のみスマートコントラクトの機能を提供し、トランザクション終了後は元のシンプルなEOAに復帰するため、セキュリティと柔軟性を維持できます。
投資家に影響の大きいEIP
ステーキングや流動性と市場参加者の増加など、投資リターンやリスクへの影響が大きいEIPを選択し、考察していきます。
EIP-7002：イーサリアム（ETH）のステーキング資産の流動性と安全性向上
イーサリアム（ETH）におけるステーキングは、バリデーターがブロックの検証作業を行い、報酬を受け取る仕組みですが、ステーキングされたイーサリアムを引き出す際には2つの重要なデータがあります。
- アクティブキー（バリデーターキー）：バリデーターがネットワークでの活動（ブロック提案や検証など）を行う際に使用する暗号鍵。これがあることで、バリデーターはネットワーク内で有効に動作し、報酬を得ることができます。しかし、このキーを使って直接引き出しを行うことはできません。
- 引き出し資格情報（withdrawal credential）： ステーキングされたイーサリアム（ETH）を引き出す際に必要な情報で、実質的に資金の引き出し権限を持つ者が保持します。この資格情報には「0x00形式」と「0x01形式」があり、特に「0x01形式」はスマートコントラクトで制御可能です。
現在のイーサリアム（ETH）のステーキングサービスの問題点
現在、イーサリアムのステーキングサービスでは、バリデーターの退出を制御できるのはアクティブキーのみです。
しかし、アクティブキーと引き出し資格情報が別々の主体によって管理されている場合（Staking as a Serviceなど）、実質的な資金の所有者である引き出し資格情報を持つ者が、自分の意思で資金を引き出せないという問題が生じています。
また、アクティブキーを紛失した場合、資金の引き出しが困難になるため、アクティブキー紛失による資金喪失リスクを抱えることになります。
EIP-7002の提案内容
この状況を改善するため、EIP-7002では以下の変更が提案されています。
- 引き出し資格情報による退出トリガー機能： これにより、「0x01形式の引き出し資格情報」を持つ者がアクティブキーを使用せずに、バリデーターの退出をトリガーしてイーサリアム（ETH）を引き出すことができるようになります。引き出し資格情報を持つ資金の最終所有者（ユーザーやスマートコントラクト）が、アクティブキーに依存することなく資金をコントロールできるため、資金の安全性と流動性が大幅に向上します。
- 部分的な引き出しのサポート： 従来はバリデーター全体が退出しないとイーサリアム（ETH）を引き出せませんでしたが、この提案により、バリデーターの一部のイーサリアム（ETH）だけを引き出すことができるようになります。これにより、ユーザーは必要に応じて流動性を確保しつつ、ステーキングを続けることが可能になります。
考察：イーサリアム（ETH）のステーキング資産の流動性向上とリスクの低減
EIP-7002の導入により、イーサリアムのステーキングにおける資産の流動性とリスク管理が大幅に改善されることが期待されます。
まず、引き出し資格情報を保持する投資家は、アクティブキーに依存せずにステーキングされたイーサリアム（ETH）を自由に引き出せるようになり、市場の変動や資金需要に迅速に対応できます。
従来のようにアクティブキーの管理者に依存することなく、自らの資産を制御できるため、投資家の柔軟性が向上します。
また、部分的な引き出しが可能になることで、必要な資金だけを引き出し、残りのイーサリアム（ETH）はステーキングで運用を続けるといった、より効率的で柔軟な資産運用が実現します。
この提案により、アクティブキーの紛失や第三者による管理によるリスクも大幅に軽減されます。
仮にアクティブキーを紛失しても、引き出し資格情報を保持していれば、資金へのアクセスが可能なため、資産喪失のリスクが低くなります。
さらに、Staking as a Service (SaaS)のように第三者にアクティブキーを管理されている場合でも、投資家は引き出し資格情報を使って資産をコントロールできるため、サービスプロバイダーへの過度な依存が解消されます。
投資家が資金の制御権を直接持てるようになることで、ステーキングサービスの透明性と信頼性も向上し、投資家は複数のサービスから安心して選択できるようになります。
これにより、業界全体の競争が活発化し、サービスの質が向上するでしょう。
加えて、サービス提供者による不正な資金凍結や引き出し拒否といったリスクも減少し、投資家保護が強化されます。
この流動性の向上は、イーサリアム（ETH）市場全体にもポジティブな影響をもたらします。
投資家がステーキングと市場取引を自由に行き来できることで、イーサリアム（ETH）の市場流動性が向上し、取引量の増加が期待されます。
また、資金の出し入れが容易になることで市場の急激な価格変動が抑制され、価格の安定性にも寄与する可能性があります。
このように、EIP-7002はイーサリアムエコシステム全体において、投資家の利便性や安全性を高める重要な提案であり、市場の成長と健全な発展に大きく貢献するでしょう。
EIP-7251：バリデーターの効率向上とリスク低減
EIP-7251は、イーサリアムネットワークのステーキング業務において、バリデーターの最大ステーク量を引き上げる提案です。
この変更により、特に交換業者（取引所やステーキングサービスプロバイダー）の役割が拡大し、効率的に流動性を提供する重要なプレイヤーとなることが期待されています。
交換業者のステーキングプールと流動性
交換業者はステーキングプールを利用して、投資家のイーサリアム（ETH）を統合し、効率的に運用するため、投資家は自分がステーキングしたイーサリアム（ETH）の一部を柔軟に取引できるようになります。
これにより、資金をステーキングしつつも、必要な時に一部を引き出して流動的に管理する手段が増え、資産管理がより柔軟になります。
EIP-7251によってバリデーターの最大ステーク量が引き上げられることで、交換業者の役割が一層重要となり、ネットワーク全体の流動性と効率性が向上することが期待されています。
スラッシュペナルティの軽減
従来のスラッシュペナルティでは、違反を犯したバリデータは、ステーキングしているイーサリアム（ETH）の1/32が罰則として差し引かれる仕組みが提案されていました。
しかし、このペナルティは特に小規模バリデータにとって大きな負担となり、新規参加者がステーキングに参入することを躊躇させる要因となっていました。
そこで、EIP-7251ではペナルティを1/4,096にまで軽減することが提案されています。
具体的には、バリデータが違反を犯した場合、2,048ETHをステーキングしているバリデータであれば、従来のペナルティが約64ETHだったのに対し、新しい提案では0.5ETHのペナルティに抑えられます（計算式: 1/4096 × 2048 = 0.5ETH）。
考察：ステーキング参加のハードル低下と分散化促進
EIP-7251によってバリデーターの最大ステーク量が引き上げられ、EIP-7002で部分的なステークの引き出しもサポートされることで、個人投資家や小規模バリデーターがステーキングに参加しやすくなります。
ステーキングはこれまで高いリスクが伴うものでしたが、スラッシュペナルティの軽減により、バリデーターは過度なリスクを負わずにネットワークに参加できるようになり、特に小規模なバリデーターや新規参加者にとって、リスクが大幅に低減されます。
これにより、ステーキングへの参入ハードルが下がり、イーサリアムネットワーク全体の分散化が促進されるでしょう。
結果として、より多くの参加者が分散型ネットワークの維持に貢献し、ネットワークのセキュリティと安定性が向上することが期待されます。
EIP-7702：ガス代の肩代わりと柔軟な資産管理
EIP-7702は、従来の資産管理とトランザクション実行の仕組みを大幅に改善し、より柔軟で効率的な運用を可能にする提案です。
CeFiでの応用
特に、これまでのCeFi（中央集権型金融）サービスでは、ユーザーごとにForwardコントラクトをデプロイして、イーサリアム（ETH）を管理する手法が一般的でした。
しかし、このForwardコントラクトはETHしか扱えず、ERC20トークンやNFTなど、イーサリアムエコシステム内で利用されるさまざまな資産を柔軟に扱うことができませんでした。
さらに、ユーザーごとにコントラクトをデプロイする必要があったため、コストと運用の複雑さが増していました。
https://speakerdeck.com/0xys/cefishi-ye-zhe-nimoxi-siipectraatupuguredo の12,13,14スライド目を参考に作成
しかし、EIP-7702が登場した後では、柔軟にコントラクトのロジックを変更することができ、特に資産の移動は柔軟に行うことができます。
また、他のアカウントにガス代の肩代わりをしてもらうことも可能であるため、Gas Station Network（GSN）のようなガス代の代理支払いを行うプロトコルを使用する必要もありません。
参考：https://speakerdeck.com/0xys/cefishi-ye-zhe-nimoxi-siipectraatupuguredo
考察：ガス代の肩代わりによるイーサリアムユーザーの増加
イーサリアムのネットワーク利用時、ガス代の計算や支払いは、ブロックチェーンに不慣れなユーザーにとって大きなハードルとなってきました。
特にガス代はネットワークの混雑状況に応じて変動するため、費用が高騰することがあり、少額取引が非現実的になる場合も少なくありません。
また、ガス代の支払いにはイーサリアム（ETH）を保有している必要があるため、新規ユーザーにとっては参入障壁が高くなっていました。
このような課題を解決する手段として、ガス代の肩代わり（ガス代スポンサーシップ）が注目されています。
これは、ユーザーに代わって第三者（サービス提供者やプラットフォーム運営者など）がガス代を支払う仕組みです。
これにより、ユーザーはガス代を意識することなくサービスを利用できるようになり、操作の簡略化と経済的負担の軽減が実現します。
また、イーサリアム（ETH）を保有していないユーザーでもサービスを利用できるため、新規ユーザーの獲得が期待できます。
さらに、ガス代が無料になることで、スパム取引や不正行為が増加するリスクも考えられます。
この問題に対しては、ユーザー認証の強化や取引量の適切な制限などのセキュリティ対策が求められます。
総論
本レポートでは、イーサリアムのペクトラ（Pectra）アップグレードの概要を整理し、投資家に向けたイーサリアムにおける変化について考察しました。
ただし、技術的なアップデートが与える影響は、テストネットやシミュレーションだけでは完全に予測できません。実際にメインネットで稼働してから初めて見えてくる問題や予期せぬ挙動がある可能性もあるため、投資家は今後の動向にも注視する必要があります。
ペクトラ（Pectra）の次回アップグレードには、「Verkleツリー」が含まれる可能性が高いと期待されています。
Verkleツリーは、イーサリアムノードがより効率的に大量のデータを保存できるようにする新しいデータ構造で、ノードの負担軽減とスケーラビリティ向上に寄与する技術です。
このアップデートにより、イーサリアムのネットワークパフォーマンスやセキュリティが大幅に向上することが期待されます。
【ご注意事項】
本記事は執筆者の見解です。本記事の内容に関するお問い合わせは、株式会社HashHub（https://hashhub.tokyo/）までお願いいたします。また、HashHub Researchの各種レポート（https://hashhub-research.com/）もご参照ください。
提供：HashHub Research
執筆者：HashHub Research
