本文へ移動
Financial Context Wiki

バリデーターの退出・出金キュー

バリデータの退出リクエスト、退出キャパシティキュー、アカウンタビリティ遅延、引き出しスイープやクレーム、プロバイダの償還は異なる段階です。資金が利用可能になる時期を見積もる前に、正確なプロトコルの状態機械、権限、スループット、スラッシュ可能性、資産経路を再構築してください。

更新日

教育目的のみに使用されます；投資の助言ではありません。投資は損失をもたらす可能性があります。

直接の答え

バリデーターの出口キューは、コンセンサスウェイトがアクティブなバリデーターセットからどれだけ速く離れられるかの速度を制限します。これは必ずしも、引き出しリクエストキュー、アンボンディングやアカウンタビリティの遅延、対象残高の自動清算、ユーザーによる請求、またはステーキングプロバイダーの償還キューと同じ仕組みではありません。重要な質問は「キューはどれくらい長いか」ではなく、「このポジションはどの状態にあり、次にどのトランジションが行われ、どの条件で資産が所有者によって使用可能となるか」です。

これらの段階と請求を分けてください。

  • リクエスト受理: 署名されたメッセージ、トランザクション、契約呼び出し、またはプロバイダーの指示が正当に含まれ、正しいバリデーター、アカウント、またはポジションに帰属していること。
  • 退出または無効化能力： は、プロトコルが各エポック、セッション、またはその他の間隔で参加を停止できるバリデーターの数や有効ウェイトを制限する方法です。
  • 責任追及またはアンボンディング遅延: の終了済みまたは委任されていないポジションはロックされたままであり、以前の行動に起因するペナルティにさらされ続ける可能性があります。
  • 出金処理： の適格残高は、プロトコルスイープによって押される、請求トランザクションによって引き出される、ステークアカウントから解放される、または満期キューが処理されるときに転送されます。
  • プロバイダーの償還: は、カストディアン、プール、流動性ステーキングトークン、またはリステーキング契約が、基盤となるプロトコルの周囲で独自のバッチ処理、流動性、手数料、為替レート、権限、および遅延を適用することを意味します。

Ethereum は、なぜ区別が重要かを示しています。フルバリデーターの退出は、バリデーターの署名キーで、または現在のルール下では、引き出し権限によって実行レイヤーから開始することができます。退出スケジューリングおよび後の引き出し可能状態の後、実行引き出し資格情報を持つ適格なフル引き出しは自動的に掃き出されます。レガシーType 1バリデーターと複利Type 2バリデーターでは、部分引き出しの動作が異なります。そのため、リクエストトランザクション、コンセンサス退出、引き出し可能エポック、掃き出しは別々の観察項目となります。

これらのEthereumのラベルは普遍的ではありません。Cosmos SDKチェーンでは、デリゲーターのアンデリゲーションにより、チェーンで設定された完了時間を持つアンボンディングエントリが作成され、外部モジュールがアンボンディングを保留にすることができます。Solanaでは、ステークアカウントの権限がデリゲーションを無効化し、ステークはエポックの境界を越えてクールダウンし、引き出し権限はロックアップに従って非アクティブなステークを引き出すことができます。リステーキング契約は、別のキュー入りの引き出しとスラッシャブルウィンドウを追加することができます。常に正確なネットワーク、バージョン、モジュール、契約、およびサービス条件を確認してください。

退出および撤退のタイミングを分析する方法

1. 位置とルールセットを定義する

network、chain ID、アクティブなフォークまたはランタイム、ブロックまたはエポック、クライアント/仕様バージョン、ステーキングモジュールまたはコントラクト、およびサービス条件を記録してください。オブジェクトがバリデータのアイデンティティ、自身のステーク、委任されたシェア、ステークアカウント、プールされた請求、流動ステーキングトークン、または再ステークされた割り当てのいずれであるかを特定してください。バリデータ退出ルールを委任者の償還やプロバイダーのオフチェーン責任に適用しないでください。

2. 権限とリクエストの受理を確認する

バリデーターの署名鍵、出金資格情報または権限、ステーク権限、アカウント所有者、コントラクト呼び出し者、受益者、手数料支払者をマッピングします。必要なメッセージフィールド、署名ドメイン、バリデーターインデックスまたは公開鍵、金額、ナンス、宛先、および手数料を再現します。最終的な包含と結果としての状態を確認してください。ローカルで署名されたファイル、送信されたトランザクション、プロバイダーチケット、または成功したシミュレーションは、プロトコルがリクエストを受理したことの証明にはなりません。

3. 状態機械を再構築する

推定日を1つ書くのではなく、すべての状態と遷移を書きなさい。例示的なバリデータの経路は active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited です。デリゲーターは代わりに bonded -> unbonding -> matured -> transferred を通過することができ、ステークアカウントは active -> deactivating -> inactive -> withdrawn かもしれません。どの遷移が自動で、どの遷移が別のトランザクションまたはサービスアクションを必要とするかを記録してください。

4. 各ボトルネックを定量化する

リクエスト・イングレスの制限、バリデータの退出変動、固定遅延、引き出しスイープ容量、契約キュー、プロバイダのバッチ処理、および最終性または確認を分離します。容量がバリデータの記録、実効ステーク、残高、リクエスト、ガス、または経過時間で測定されるかどうかを判断します。queue_ahead、capacity_per_interval、アクティブセットのサイズまたは残高、および同じ最終化観測ポイントでのあらゆる上限を照会します。単純な推定 ceil((work_ahead + own_work) / capacity) は、順序付けと容量に関する前提条件が成り立つ場合にのみ有効です。

5. 義務、報酬、スラッシュ可能性を確認する

提案と投票の任務が終了する正確なエポック、高さ、または状態、通常の報酬が停止する時点、ペナルティがまだ適用可能な時点、および残高がスラッシュ対象でなくなる時点を確認してください。これらの時間は必ずしも一致する必要はありません。プロトコルの状態が任務の終了を示すまでは、バリデータをオンラインかつ正しく設定された状態に保ってください。ブロードキャストされた退出要求やフロントエンドのステータスだけでは、停止する十分な権限とはなりません。

6. 資産およびクレームのレイヤーを追跡する

ネイティブユニットを、ボンド済みまたはアクティブなアカウンティングから保留中、アンボンディング、引き出し可能、契約エスクロー、プロバイダー保管、そして宛先アカウントに至るまで追跡します。株式、受取トークン、または流動ステーキングトークンは、それぞれの為替レートと市場価格を使用して個別に評価します。プロトコルの報酬、ペナルティ、スラッシング、手数料、償還手数料、ガス、ブリッジコスト、および端数処理を照合します。権利を売却すると流動性リスクが買い手に移転されますが、基本プロトコルの移行が早まることはありません。

7. 完了を確認し、流動性を計画する

各遷移を証明するために、最終状態、プロトコルイベント、キュー記録、引き出しオブジェクト、宛先アカウントの残高、およびプロバイダーの負債を使用してください。見積もりに使用したリクエスト識別子とパラメータのスナップショットを保存してください。キャッシュプランは単一の日付ではなく、範囲と予備バッファを持って構築し、スイープの欠落、契約の一時停止、誤った資格情報、プロバイダーの破産、または期待される照合と異なる残高の場合のエスカレーションを定義してください。

実例

多段階タイミング計算

block_time = 12 secondsおよびepoch = 30 blocks = 6 minutesを使用した例示的なプロトコルを考えます。要求は選択された確認ポイントに到達するのに4 blocksかかり、出口容量を待つのに72 epochsかかり、その後に8 epochsの責任遅延があり、転送処理までに予想される時間は12 blocksです:

4 * 12 = 48 seconds.

72 * 6 = 432 minutes.

8 * 6 = 48 minutes.

12 * 12 = 144 seconds = 2.4 minutes.

総合的な所要時間は 48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours です。ステージは順次であるため加算されます。これは Ethereum の予測ではありません：実際のルールでは、異なる間隔、状態依存の解約、最小遅延、スイープアルゴリズム、および最終性の仮定を使用することができます。

容量が変化するウェイトベースのキュー

work_ahead = 50,000 の有効ユニットを仮定すると、この出口は own_work = 320 を表し、初期 capacity_per_epoch = 640 です。容量が一定の場合：

ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs.

1エポックあたり6 minutesであり、それは79 * 6 = 474 minutes = 7.9 hoursです。しかし、エポック30以降、容量が512に低下すると仮定します。最初の30エポックで30 * 640 = 19,200を処理し、50,320 - 19,200 = 31,120が残ります。残りはceil(31,120 / 512) = 61 epochsかかるため、修正後の合計は30 + 61 = 91 epochs = 9.1 hoursとなります。ライブ見積もりでは、容量と順序を再計算する必要があり、1つのダッシュボードのレートを固定するわけではありません。

退出による残高照合

例示的なバリデーターは 32 ユニットで始まり、義務が終了する前に 0.40 を稼ぎ、0.05 の通常のペナルティを負い、その後プロトコルの露出ウィンドウに基づく 1.20 のスラッシュを受けます。プロバイダー手数料や税金が差し引かれる前に利用可能な金額は次のとおりです:

32 + 0.40 - 0.05 - 1.20 = 31.15 units.

このリクエストは32単位の支払いを確定するものではありません。プロトコルの残高変更、プロバイダーの会計、および市場価格の変動は別々の台帳です。宛先が31.15を受け取った場合、それはネイティブ単位の経路の照合にはなりますが、法定通貨価値や補償権については何も示しません。

流動請求とキュー待ち償還

100 のリクイッドステーキングトークンを今、1つあたり 0.965 ネイティブ単位で売却できると仮定すると、得られるのは次の通りです:

100 * 0.965 = 96.5 units.

あるプロバイダーは、キューに0.2%の手数料がかかった後、または100 * (1 - 0.002) = 99.8 unitsで、トークンあたり1つのネイティブユニットで償還すると見積もります。その差は99.8 - 96.5 = 3.3 unitsであり、見積もられたキュー済み収益に対する即時売却割引は3.3 / 99.8 = 3.3066%です。3.3ユニットのスプレッドは、このスナップショットにおいてのみ、時間、不確実性、流動性に対して補償するものです。スラッシング、為替レートの変動、契約の損失、またはキューの一時停止により、後の収益は変わる可能性があります。

リスクとレビューの失敗

  • キューの取り違え: バリデーター退出、出金リクエスト受付、アンボンディング、スイープ、コントラクト、事業者の償還キューは、それぞれ状態と処理能力が異なります。
  • ルールセットの取り違え: 別のチェーン、フォーク、ランタイム、モジュール版、テストネット、コントラクトのデプロイでは異なる遷移が使われることがあります。
  • 古いパラメータ: チャーン、固定遅延、スイープ上限、手数料、ロックアップ、事業者条件は見積もり後に変わる可能性があります。
  • 未受理のリクエスト: 署名、送信、シミュレーション、チケット発行だけでは、プロトコルが最終的に受理した証拠になりません。
  • 権限の混同: バリデーター、出金、ステーク、所有者、カストディアン、コントラクト管理者の各キーは異なる操作を許可します。
  • 認証情報または送金先の誤り: 取り消せない認証情報の変換や誤った出金先は、資産の支配権を恒久的に移すおそれがあります。
  • 早すぎる停止: 記録上の退出状態になる前に稼働を止めると、報酬を失ったりペナルティを受けたりする可能性があります。
  • 報酬終了時点の誤認: リクエスト、退出予定、実際の退出、出金可能、送金の各時点で報酬計上ルールが異なる場合があります。
  • 残存するスラッシングリスク: 退出済み、アンボンディング中、またはキュー内の資金も、過去の帰責可能な違反により処罰されることがあります。
  • 件数とウェイトの不一致: バリデーター件数で表示されたキューは、有効残高やシェアで制限される処理能力を正しく示さないことがあります。
  • 動的キューの誤差: 後続リクエストが追い越せなくても、後のパラメータ変更やアクティブセットの変化で処理能力は変わり得ます。
  • スイープと請求の混同: 対象になった後、自動送金される場合、請求操作が必要な場合、巡回スイープを待つ場合があります。
  • 部分と全部の混同: 超過残高の出金、部分的な委任解除、バリデーターの完全退出は同じではありません。
  • ロックアップと保留: 口座ロック、ガバナンス制御、セキュリティ停止、外部モジュールの保留は名目上の満期を超えることがあります。
  • 事業者との不一致: 基礎プロトコルが完了しても、事業者は償還を遅延、一括処理、制限、相殺、または拒否できます。
  • リステーキングの重複: ベースチェーンから退出しても、別サービスに割り当てたステークやそのペナルティ期間が解放・終了するとは限りません。
  • 流動性請求権のベーシスリスク: リキッドステーキングトークンは、ストレス時に請求価値を下回って取引されたり、交換不能になったりする可能性があります。
  • 手数料と丸め損失: ガス、動的リクエスト手数料、コミッション、シェア換算、ブリッジ手数料、小数桁の変更は受取額に影響します。
  • カストディとコントラクトの障害: キー侵害、支払不能、アップグレード権限、バグ、ブリッジ障害は資産を凍結または流出させる可能性があります。
  • 可観測性とファイナリティの誤り: ダッシュボードは遅延し、保留項目を省略し、推定状態と確定状態を混同し、後でリオーグされるイベントを表示することがあります。

一般的な誤解

イグジットを提出すると、バリデーターの義務はすぐに停止しますか？

いいえ。リクエストの包含、退出のスケジューリング、および義務が終了する状態はそれぞれ別です。最終状態がバリデーターの参加が不要であることを確認するまで、プロトコルに従って運用を続けてください。

引き出し可能とは、送金先のウォレットに入金されたという意味ですか？

いいえ。withdrawable は通常、適格性を示します。プロトコルはまだバリデーターをスイープする必要があるかもしれませんし、ユーザーが請求する必要があるかもしれませんし、アカウントが明示的な引き出しを必要とするかもしれませんし、プロバイダーがその責任を解除する必要があるかもしれません。送金先の残高を確認してください。

キューの長さを今日のレートで割ると、正確な日付を出すことができますか？

いいえ。ディスプレイは誤った単位を表示するかもしれませんし、容量は状態に依存する可能性があります。固定遅延やスイープ時間が続くこともあり、プロバイダ段階が省略される場合もあります。すべての仮定を明記し、範囲を計算してください。

流動型ステーキングトークンを売ると、退出キューを回避できますか？

もし買い手が存在すれば、それは売り手に即時の市場流動性を提供します。基礎となる持ち分や他の保有者の償還請求権は依然としてプロトコルおよびプロバイダーの規則に従いますが、売り手は市場価格と取引コストを受け入れます。

広告されているアンボンディングまたは出金期間は保証された最大値ですか？

いいえ。それはリクエストの包含、混雑、最終性、スイープ、保留、契約の一時停止、プロバイダーのバッチ処理、またはインシデント対応を除外した最小または予想される遅延である可能性があります。完了を定義するのは、アクティブなルールと観測された状態のみです。

関連するトピック

情報源

ナビゲーション

Wiki を検索...