イーサリアムのペクトラ・アップグレード:ステーカーが知っておくべきこと
ステーカーの視点からペクトラ・アップグレードを解説し、バリデータやステーキング運用への実質的な影響、およびイーサリアム・プロトコルにおけるステーキングに影響を与える主要なEIPについて説明します。
Date published: 2025年1月22日
Blockdaemonが主催し、ブロックチェーンエンジニアのJulia Schmidt氏(Alluvial)とFreddy Tänzer氏(Blockdaemon)を迎えたウェビナーでは、ペクトラ・アップグレードがETHステーキングに与える影響について議論しています。このウェビナーでは、実行レイヤーからトリガー可能な引き出し、最大エフェクティブ・バランスの増加、バリデータの統合、およびリキッド・ステーキングへの影響について取り上げています。
このトランスクリプトは、Blockdaemonが公開した元の動画のトランスクリプト (opens in a new tab)のアクセシブルなコピーです。読みやすさを考慮して軽く編集されています。
はじめに (0:00)
ホスト: こんにちは。イーサリアムの次期ペクトラ・アップグレードに焦点を当てた、Blockdaemon主催のウェビナーへようこそ。本日は、AlluvialのブロックチェーンエンジニアであるJulia Schmidt氏と、Blockdaemonのイーサリアム・エコシステム・リードであるFreddy Tänzer氏をお迎えし、ペクトラの変更がETHステーキング、ネットワーク全体、リキッド・ステーキング・サービスなどにどのような影響を与えるかについて議論します。まずはFreddyさん、ペクトラ・アップグレードの概要と、それがステーカーに与える影響について簡単に教えていただけますか?
ペクトラとは (1:28)
Freddy Tänzer: ペクトラは、2025年の第1四半期後半(3月頃、あるいは少し遅れて4月頃になるかもしれません)に予定されているイーサリアムのアップグレードです。当初は小規模なフォークになる予定でしたが、徐々に多くの機能が追加されたため、現在では2つに分割されています。
最初の部分には多くの内容が含まれています。例えば、スマートアカウントやアカウント抽象化などに関するものですが、ここでは視聴者の皆様に関連するステーキングの変更点に焦点を当てたいと思います。主に2つの大きな変更があります。
1つ目は、実行レイヤー(出金クレデンシャル)を介してバリデータからの引き出しやエグジットをトリガーできるようになることです。これにより、基本的にはノードオペレーターへの依存が解消されます。2つ目は、おそらくさらに大きな影響を与えるものですが、バリデータの最大エフェクティブ・バランスが変更可能になることです。これまでは32 ETHの固定額のみでしたが、今後は32 ETHから2,048 ETHの間で設定できるようになります。
また、小規模な変更として、デポジットがはるかに迅速になるという点もあります。オンチェーンでの登録が約14時間から1時間未満に短縮されますが、ここでの議論に最も関連するのは先ほどの2つだと思います。
EIP-7002: 実行レイヤーからトリガー可能なエグジット (2:58)
ホスト: 最初の大きな変更について、Juliaさん、ペクトラ後のプロセスが、現在のイーサリアムのステーキング・エコシステムにおける引き出しの開始方法と比べてどのように変わるのか説明していただけますか?
Julia Schmidt: ブロックを提案し、証明(アテスト)するためには、バリデータは常にオンラインであり、32 ETHのステーク残高を持っている必要があります。コンセンサス・メカニズムに参加するためにバリデータを設定する際、2つの鍵を設定します。1つはバリデータ鍵で、ブロックの証明への署名など、バリデータの役割を果たすために使用されます。2つ目は引き出し鍵で、ステークされたETHの所有権を表します。
ステーキングには2つの方法があります。ソロ・ステーキングか、Blockdaemonや私たちがLiquid Collectiveで行っているようなマルチカストディアルのセットアップです。後者では、ノードオペレーターを選択して、バリデータの役割や運用をすべて代行してもらうことができます。これにより、オペレーターにはバリデータ鍵が渡され、あなたは引き出し鍵のみにアクセスすることになります。
バリデータをエグジットするための実際のメッセージは、ノードオペレーターが管理するバリデータ鍵からしか送信できません。そのため、ノードオペレーターを信頼し、バリデータのエグジットを彼らに依存する必要があります。彼らが実行してくれれば素晴らしいですが、常にこの第三者に頼らざるを得ません。
これまで行われていたのは、このマルチカストディアルのステーキング・セットアップを行う際に、エグジット・メッセージの事前署名に同意することでした。後でバリデータをエグジットするために使用できるメッセージを受け取りますが、そのエグジット・メッセージが実際に機能するかどうかはわかりませんでした。イーサリアムのアップグレードでバージョン番号が変更されるたびに、エグジット・メッセージが機能しなくなる可能性があったからです。
前回のデンクン・アップグレードでは、新しいEIPによってこれらのエグジット・メッセージの有効期限が変更されましたが、それは対症療法に過ぎず、根本的な問題の解決にはなりませんでした。実際の問題は、ステークされたETHの所有者が引き出しをトリガーできないことです。資金は実質的にノードオペレーターによって人質に取られる可能性があります。
これがEIP-7002によって解決されます。これにより、バリデータ鍵と引き出し鍵の両方が実行レイヤーからエグジットをトリガーできるようになります。特別な引き出しコントラクトにトランザクションを送信し、引き出しリクエストを送って、バリデータの完全なエグジットか、ステーク残高からの部分的な引き出しのいずれかを指定するだけで済みます。
EIP-7251: 最大エフェクティブ・バランス (4:15)
ホスト: Freddyさん、ペクトラ以降の最大エフェクティブ・バランスの概要と、それが現在ステークしている人々にどのような影響を与えるか教えていただけますか?
Freddy Tänzer: 補足ですが、当社の機関投資家のお客様にとって、このノードオペレーターへの依存は、主に規制当局からの懸念や事業継続性の懸念に対処するため、通常は事前署名されたエグジット・メッセージで対応されていました。また、彼らはそれらのエグジット・メッセージを安全に保管する必要がありました。したがって、その依存関係が排除されることで、プロセスが明確に簡素化されます。
さて、最大エフェクティブ・バランスについてですが、多くのことは変わらず、これらはすべてオプトイン(任意)です。何も変更する必要はありません。イーサリアムのコア開発者やエコシステム全体の目標は、ネットワーク上のバリデータの数を減らすことです。現在、バリデータは100万を超えており、それぞれが証明やコンセンサスについて他のバリデータと通信する必要があります。これは膨大なネットワーク・トラフィックであり、テストでは200万バリデータに達すると問題が生じる可能性があることが示されています。
目標は、ネットワークのセキュリティに影響を与えることなくバリデータの数を減らすことです。ステークされるETHの総量は一定に保たれ、平均してバリデータあたりのETHが増えるだけだからです。
顧客にとって、これは主に新しいバリデータ・タイプを使用するか、古いものを使用するかを決定する必要があることを意味します。これは流動性のニーズに依存します。32 ETHのバリデータを使用する現在のセットアップでは、プロトコルの報酬は9〜10日ごとに出金クレデンシャルにプッシュされ、定期的な流動性が得られます。
しかし、多くのセットアップでは、報酬がステークの複利運用に使用されることを想定しています。過去には、複利運用を行う場合、報酬が32 ETHに達するまで待ってから、手動で新しいバリデータを立ち上げる必要がありました。新しいバリデータ・タイプでは、報酬が自動的に複利運用されます。つまり、より多くの報酬をより少ない手間で得ることができます。
トレードオフとして、定期的に報酬を受け取ることができなくなり、報酬を回収するためのプロセスを設定する必要があります。引き出しのトリガーは、古いモデルのように無料で報酬を受け取るのではなく、ガス代が発生する通常のトランザクションになります。
スラッシングに関しても良いニュースがあります。初期のスラッシング・ペナルティが劇的に(約128分の1に)下がります。32 ETHのバリデータの場合、初期ペナルティは1 ETHでした。ペクトラ後は、ETHのほんの一部(おそらく20ドルか25ドル程度)になります。これはソロ・ステーキングにプラスの副次的効果をもたらし、イーサリアムの信頼できる中立性にとって明らかに重要です。
自動複利運用のメリットは、主に少額のステークに恩恵をもたらします。1,000個のバリデータを持っていれば、毎月手動で新しいバリデータを立ち上げることができます。しかし、バリデータを1つしか持っていない場合、複利運用を行うには実質的に32年待つ必要があります。
リキッド・ステーキングへの影響 (11:25)
ホスト: Juliaさん、大規模なバリデータの統合は、リキッド・ステーキングのメリットと比べてどうでしょうか?ペクトラ後、ステーカーの頭の中でこれらの決定はどのように比較検討されるのでしょうか?
Julia Schmidt: Alluvialでは、これらの変更を注意深く追跡しており、両方のソリューションを提供したいと考えています。ペクトラにおける統合リクエストは暫定的なソリューションであり、エフェクティブ・バランスの収益獲得時間に影響を与えるべきではありません。複数のバリデータを統合する際に、再び有効化キューを通過する必要はありません。プロセスは非常にスムーズです。
初期のスラッシング・ペナルティが引き下げられたことで、高残高のバリデータを運用するリスクが軽減されます。イーサリアム財団からの推進は、ネットワークの負荷を減らすために可能な限り統合することです。小さな欠点もあります。2,048 ETHの最大エフェクティブ・バランスを持つバリデータがスラッシングされるという非常にまれなケースでは、エグジット・キューに入り、資金が長期間ロックされることになります。これは、64個のバリデータが一度にスラッシングされるようなものです。そのため、クライアントのリスク許容度に応じて、柔軟なバリデータの上限を提供しようと考えています。
ユーティリティの面では、リキッド・ステーキング・トークンは明らかに流動性を追加します。実行レイヤーからの部分的な引き出しであっても、即座には行われません。トランザクションを送信し、キューに入れられ、その後エグジット・エポックと引き出しエポックがあります。リキッド・ステーキング・トークンは、部分的な引き出しでは実現できない即時の流動性を引き続き提供します。
ステーカーの次のステップ (16:20)
Freddy Tänzer: 私たちが見ているところでは、金融機関は通常、カストディ下にあるETHの65%から85%をステークします。残りは償還のための流動性バッファーとして必要だからです。リキッド・ステーキングを利用すれば、ステークするETHの量を増やすことができ、より高い報酬を生み出す可能性があります。
ペクトラからは両者が恩恵を受けます。リキッド・ステーキングは実行レイヤーからの引き出しオプションを得られ、従来のステーキングは、特に少額のステークにおいて、32 ETHの増分問題が解消されます。
Julia Schmidt: Liquid Collectiveプロトコルでは、単一のノードオペレーターにステーキングを提供するだけでなく、ラウンドロビン方式でステークを割り当てるさまざまなノードオペレーターのコンソーシアムを持っています。これにより、ステークされたETHの分散化が向上します。また、これらのノードオペレーターはNORS(ノードオペレーター・リスク基準)に従っているため、スラッシングが発生した場合の補償も保証しています。
まだ触れていない重要な利点は、部分的な引き出しです。実行レイヤーからステークされたETHを引き出せるようになったことで、EigenLayerなどのプロトコルが引き出しやエグジットをトリガーする新たな道が開かれます。機能性とインターオペラビリティが大幅に向上し、分散型金融 (DeFi) がデポジットからエグジットまでのバリデーターのライフサイクル全体にうまく組み込めるようになります。ブロックチェーンエンジニアとして、ワークフロー全体を自動化できることは非常にエキサイティングです。
おわりに (19:50)
ホスト: Juliaさん、Liquid CollectiveやAlluvialについてもっと知りたい場合、どこを見ればよいでしょうか?
Julia Schmidt: Twitter、X、LinkedIn、またはAlluvialのウェブサイトでAlluvialとLiquid Collectiveをフォローできます。ペクトラ・アップグレードに関する変更点と、それがイーサリアムの状況にどのような影響を与えるかを詳しく説明した記事を共有する予定です。
ホスト: Freddyさん、ペクトラに関して共有すべき最新情報はありますか?
Freddy Tänzer: 今後多くの情報を提供予定です。当社のウェブサイトblockdaemon.comに専用ページを設ける予定で、そこがすべてのリソースの中心的なハブになります。ブログ記事、FAQ、そしてどのタイプのバリデータを選ぶべきか、どのサイズにするべきかに関するガイダンスやモデリングの推奨事項を掲載します。2,000 ETHのバリデータを1つにするか、1,000 ETHを2つにするか、500 ETHを4つにするかなど、これらはすべて一般的に可能であり、トレードオフの決定を下す必要があります。私たちは、お客様がこれを乗り越えられるようサポートします。
ホスト: 素晴らしいですね。Freddyさん、Juliaさん、本日はお時間をいただきありがとうございました。非常に興味深い議論であり、ペクトラの素晴らしい入門となりました。