MaxEB

tl;dr: Pectraハードフォークによってイーサリアムのバリデータは、引き出し資格情報をType 1からType 2に変換することで、より高い最高有効残高および複利運用にオプトインできるようになりました。 このオプトインできる公式ツールは、ローンチパッドです。 この操作を一旦行うと戻せません。

概要

影響範囲

バリデータを運用しているすべての人 - これは、自分が管理しているバリデータのインデックス(例：Validator #12345 (opens in a new tab))を知っている人である可能性が高いです。 Lido CSMやRocket Poolなどのプロトコルを使用してバリデータを運用している場合は、それらがmaxEBをいつ、どのようにサポートするかを確認する必要があります。

リキッドステーキングトークン(例：rETHやstETH)を使用してステークしている場合、アクションは不要または推奨されません。

「MaxEB」とは

maxEBは、バリデータのMAXimum Effective Balance(最大有効残高)を省略したものを指しています。 Pectraハードフォークまで、各バリデータは最大32ETHをステークして利息を得ることができました。 Pectraの後は、バリデータにオプションが設けられ、32ETHから2048ETHの間で、1ETH単位で有効残高を変更することができます。

バリデータのオプトイン方法は？

バリデータがmaxEBの変更をできるようにするには、引き出し資格情報を Type 1 から Type 2 に変換する必要があります。 これは、Pectraハードフォークが有効になった後、Launchpad (Validator Actions) (opens in a new tab)で実行できます。 Type 0 から Type 1 に変更するのと同じで、Type 1 から Type 2 へ変更すると、戻すことができません。

引き出し資格情報とは？

バリデータを実行すると、引き出し資格情報のセットを取得できます。 この引き出し資格情報のセットは、デポジットデータのjson、または beaconcha.in のあなたが管理するバリデータの デポジットタブ (opens in a new tab) で確認できます。

1. Type 0 引き出し資格情報: バリデータの引き出し資格情報が0x00...で始まる場合は、Shapellaハードフォーク以前にデポジットしています。そのため、引き出しアドレスが設定されていません。

2. Type 1 引き出し資格情報: バリデータの引き出し資格情報が0x01...で始まる場合は、Shapellaハードフォークの後にデポジットしたか、すでにType 0資格情報をType 1に変換したものです。

3. Type 2 出金認証情報：この新しい出金認証情報タイプは0x02...で始まり、Pectraの後に有効になります。 Type 2 出金認証情報を持つバリデータは、「複利バリデータ」と呼ばれることがあります。

リスク

MaxEBにより、バリデータはその全残高を別のバリデータに送信できます。 統合リクエストを送信するユーザーは、署名するトランザクションのソースと内容を確認する必要があります。 maxEB機能を利用するための公式ツールはLaunchpadです。 サードパーティ製のツールを使用することにした場合は、以下を確認する必要があります。

• ソースバリデータの公開鍵と出金アドレスが、自身が管理するバリデータと一致していること
• ターゲットバリデータの公開鍵が正しく、それが自身のものであること
• 別のバリデータに資金を送るつもりがない場合、リクエストが統合ではなく変換であること
• トランザクションが正しい出金アドレスによって署名されていること

使用を計画しているサードパーティ製のツールについては、EthStakerコミュニティ (opens in a new tab)と議論することを強く推奨します。 それは、あなたのアプローチを健全性チェックし、間違いを避けるために役立つ場所です。 悪意のある、または設定が間違っているツールを使用した場合、バリデータの残高全体が、あなたが管理していないバリデータに送られてしまう可能性があります — そして、それを取り戻す方法はありません。

詳細技術

フロー

ConsolidationRequest操作には2つの用途があります:

1. 既存のバリデータをType 1からType 2バリデータへ変換する
2. 他のバリデータを既存のType 2バリデータへ統合する

Type 1からType 2バリデータへの変換では、_ソース_と_ターゲット_の両方が変換対象のバリデータになります。 この操作にはガス代がかかり、他の統合リクエストの後ろのキューに追加されます。 このキューはデポジットキューとは別であり、新規バリデータのデポジットの影響を受けず、pectrified.com (opens in a new tab)で表示できます。

バリデータを統合するには、Type 2出金認証情報を持つ_ターゲットバリデータ_が必要です。 これは統合されるバリデータ残高の宛先であり、保存されるインデックスです。

Type 2に変換するための要件

これは、最初にType 2に変換するバリデータに対して必要になります。 このバリデータのインデックスは保存され、アクティブなままです。 変換の場合、ソースバリデータ == _ターゲットバリデータ_です。

バリデータは...

• アクティブであること
• Type 1出金認証情報を持っていること
• 終了状態(またはスラッシュされた状態)にないこと
• 手動でトリガーされた保留中の出金がないこと(スイープには適用されません)

統合するための要件

これは変換と_同じ操作_ですが、_ソースバリデータ_が_ターゲットバリデータ_と異なる場合です。 ターゲットバリデータのインデックスは保存され、ソースバリデータからの残高を受け入れます。 ソースバリデータのインデックスはEXITED状態になります。

この場合、ソースバリデータは上記のすべての要件に加えて、以下の要件を満たす必要があります。

• 少なくとも約27.3時間(SHARD_COMMITTEE_PERIOD 1回分)アクティブであること

ターゲットバリデータは...でなければなりません

• Type 2出金認証情報を持っていること
• 終了状態にないこと。

統合リクエスト

統合リクエストは、ソースバリデータに関連付けられた出金アドレスによって署名され、以下を含みます:

1. ソースバリデータのアドレス(例：0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b)
2. ソースバリデータの公開鍵(例：0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c)
3. そのターゲットバリデータの公開鍵

変換では、2と3は同じになります。 この操作はthe Launchpad (opens in a new tab)で実行できます。

署名要件

ConsolidationRequestを送信するには、ソースバリデータの出金アドレスがリクエストに署名する必要があります。 これはバリデータの資金に対する管理権を証明します。

何が署名されるのか？

ConsolidationRequestオブジェクトのドメイン分離された署名ルート (opens in a new tab)が使用されます。

• ドメイン: DOMAIN_CONSOLIDATION_REQUEST
• 署名ルートのフィールド:
  • source_pubkey: BLSPubkey
  • target_pubkey: BLSPubkey
  • source_address: ExecutionAddress

結果として得られるBLS署名は、リクエストとともに送信されます。

注：署名はバリデータキーではなく、出金アドレスによって行われます。

部分的な出金

Type 1認証情報を持つバリデータは、超過残高(32 ETHを超える分)を自動的に、ガス代なしで出金アドレスにスイープします。 Type 2ではバリデータが1 ETH単位で残高を複利運用できるため、残高が2048 ETHに達するまで自動的にスイープされません。 Type 2バリデータの部分的な出金は、手動でトリガーする必要があり、ガス代がかかります。

統合ツール

統合を管理するために利用できるツールがいくつかあります。 イーサリアム・ファウンデーションによって作成された公式ツールは、Launchpad (opens in a new tab)です。 また、ステーキングコミュニティのエンティティによって作成されたサードパーティツールもあり、Launchpadでは提供されていない機能を提供する場合があります。 ここにあるツールはイーサリアム・ファウンデーションによって監査または承認されていませんが、以下はコミュニティの著名なメンバーによるオープンソースツールです。

よくある質問

オプトインすると、提案の運や報酬が変わりますか？

できません。 オプトインしても提案の機会が減ることはありません。あなたの責務と提案の選出は変わりません。 例えば、32 ETHのバリデータを2つ持つ場合と、64 ETHのバリデータを1つ持つ場合では、ブロックを提案して報酬を得るために選ばれる合計のチャンスは同じです。

オプトインすると、スラッシングのリスクは変わりますか？

小規模または非専門のオペレーターにとって、短い答えは「いいえ」です。 より長い答えとしては、高速なアラート機能を持つノードごとに多くのバリデータを運用する専門オペレーターにとって、バリデータを少数に統合することは、スラッシングに反応して連鎖的なイベントを防ぐ能力を低下させる可能性があります。 このリスクを相殺するために、すべてのバリデータに対する初期のスラッシング_ペナルティ_は、1 ETH (32 ETHあたり)から0.0078125 ETH (32 ETHあたり)に大幅に引き下げられました。

変換するためにバリデータを終了させる必要がありますか？

できません。 終了せずに、その場で変換できます。

変換/統合にはどのくらい時間がかかりますか？

最低27.3時間ですが、統合はキューの対象にもなります。 このキューはデポジットと出金のキューから独立しており、それらの影響を受けません。

バリデータのインデックスを維持できますか？

その場での変換では、同じバリデータインデックスが維持されます。 複数のバリデータを統合する場合、_ターゲットバリデータ_のインデックスのみを維持できます。

アテステーションを逃すことになりますか？

別のバリデータへの統合中、ソースバリデータは終了し、ターゲットバリデータで残高が有効になるまで約27時間の待機期間があります。 この期間はパフォーマンス指標に影響しません。

ペナルティが発生しますか？

できません。 バリデータがオンラインである限り、ペナルティは発生しません。

統合されるバリデータの出金アドレスは一致する必要がありますか？

できません。 ただし、_ソース_は自身のアドレスからリクエストを承認する必要があります。

変換後、報酬は複利になりますか？

Type 2認証情報では、32 ETHを超える報酬は自動的に再ステークされますが、即時ではありません。 小さなバッファ(ヒステリシス (opens in a new tab)と呼ばれる)のため、超過分が再ステークされる前に、残高が約1.25 ETH多くなる必要があります。 そのため、33.0 ETHで複利になるのではなく、33.25 (実効残高 = 33 ETH)、次に34.25 (実効残高 = 34 ETH)といった具合に発生します。

変換後も自動スイープは利用できますか？

自動スイープは、2048を超える超過残高でのみ発生します。 他のすべての部分的な出金については、手動でトリガーする必要があります。

心変わりしてType 2からType 1に戻すことはできますか？

できません。 Type 2への変換は元に戻せません。

複数のバリデータを統合したい場合、それぞれを最初にType 2に変換する必要がありますか？

必要ありません！ 1つのバリデータをType 2に変換し、それをターゲットとして使用します。 そのType 2ターゲットに統合される他のすべてのバリデータは、Type 1またはType 2のいずれかです。

私のバリデータはオフラインか32 ETH未満ですが、それでも変換できますか？

アクティブ(終了していない)であり、その出金アドレスで署名できる限り、変換できます。

参考リソース

• Electraコンセンサス仕様 (opens in a new tab)：これは信頼すべき「最も正確な」バージョンです。 迷ったら、スペックを読んでください
• 誰もがコードを読み解くのが得意なわけではないため、このmaxEB-GPT (opens in a new tab)が仕様の解釈を助けることができます。 免責事項：AIが情報を誤解したり、幻覚の答えを出したりする可能性があるため、真実として信頼すべきはAIではなく仕様です
• pectrified.com (opens in a new tab)：統合、デポジット、キューの待機時間の状態を表示します
• Ethereal (opens in a new tab)：一般的なバリデータタスクを管理するためのコミュニティ作成のCLIツール
• batch-validator-depositor (opens in a new tab)：複数のイーサリアムバリデータを単一のトランザクションでデポジットできるコミュニティ作成のコントラクト

最終更新： 2026年2月1日

s (opens in a new tab)

q (opens in a new tab)

p (opens in a new tab)

+4

貢献者を表示