[ACP41] ステーク期間管理の新ルールの仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、ステーカーが自由に指定していた開始時刻を廃止し、ステーキングした瞬間から自動的に開始されるようにする仕組みを提案しているACP41についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/41-remove-pending-stakers/README.md

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

ACP41は、ステーカー（stakingを行う人やノード）が自分で指定するStartTime（ステーキング開始時刻）を廃止し、ステーキング取引がP-chainで「受理（accept）」された瞬間にステーキングを開始するという変更案です。これによりP-chain上の計算負荷が大幅に削減され、AvalancheNetworkの全バリデータ（ブロック検証者）の効率が向上します。

用語

用語	説明
P-chain	Avalancheのプラットフォームチェーン。バリデータの登録やステーク管理などネットワーク運用の基盤となるチェーンです。
ステーカー（staker）	自身で検証に参加するバリデータ、またはバリデータに資産を委任するデリゲータ（delegator）の総称です。
バリデータ（validator）	ブロックの検証に参加するノードです。自身のステークと、他者からの委任ステークを合わせた有効ステークで検証に参加します。
デリゲータ（delegator）	自分は検証せず、資産を特定のバリデータに委任して、そのバリデータの検証に参加させる人です。
`StartTime`	ステーカーが従来は任意に指定できた、ステーキングの開始時刻です。
受理（accept）	ステーキング取引が検証を終えてブロックに取り込まれ、ステートとして確定することです。
検証（verify）	取引を受理する前に正当性をチェックする処理です。
pending set	まだ開始時刻が来ておらず、将来アクティブになる予定のステーカー集合です。
current set	すでに開始してアクティブ状態にあるステーカー集合です。
`MaxValidatorStake`	あるバリデータが保持できる総ステーク（自己＋委任）の上限値です。
`O(1)`	計算量が入力規模に依存せず一定時間で終わることを示す表現です。

ACP41のコアは「StartTimeをユーザーが指定する仕組みを廃止し、ステーキング取引が受理されたら直ちにそのステーカーの期間を開始する」ことです。これにより、P-chain側で将来の開始時刻を待つステーカーを追跡する必要がなくなります。具体的には、従来pending setとして保持していた「まだ開始していないステーカーのリスト」を丸ごと削除でき、current set（現在アクティブな集合）だけを見ればよくなります。

この変更の効果として、MaxValidatorStakeのチェックが大幅に簡素化されます。従来は「将来の期間が重なったときの総ステークが上限を超えないか」を時刻付きで検査する必要がありましたが、提案後は「いま現在の総ステーク」を見るだけで足ります。したがってMaxValidatorStakeの判定はO(1)で済むようになります。

動機

これまでステーカーは自由にStartTimeを設定できました。この仕組みは柔軟ですが、P-chainには次のような継続的な負担を生みます。

検証時の将来チェック新しいデリゲータ取引を検証するときには、対象バリデータがすでに受理している他のステーク取引（まだ開始していないものを含む）をすべて考慮し、そのバリデータに委任された総ステーク量がMaxValidatorStakeを超えないかを確認する必要があります。つまり、将来のある時点で複数のステーク期間が同時にアクティブになった場合に、合計が上限を超えていないかを見通してチェックする、ということです。
受理時の保留登録新しいステーカー取引を受理したら、その開始時刻までpending setに追加・保持し続けます。
時刻前進時の集合移動 P-chainの現在時刻が進むたびに、StartTime <= 現在時刻となったステーカーをpending setからcurrent setへ移し替える処理が必要です。

これらはすべて、StartTimeという将来の予定を支えるための管理コストです。取引受理と同時に開始してしまえば、上記の管理が不要になります。結果として、各バリデータがP-chain検証で行う計算量が下がり、ネットワーク全体の効率が上がります。

計算量

従来は、将来の開始・終了を跨いでpending setとcurrent setを横断的に確認し、期間が重なる箇所での総ステークがMaxValidatorStakeを超えないかを調べる必要がありました。これはデータサイズや重なり状況に応じて計算量が増大します。提案後は、「現在アクティブな集合」だけを見て総ステークを判定すればよく、MaxValidatorStakeのチェックはO(1)で完結します。

処理フローのイメージ

従来（StartTimeあり）の流れ

sequenceDiagram
  participant Staker as ステーカー
  participant P as P-chain
  Staker->>P: ステーキング取引を送信（StartTime付き）
  P->>P: 取引を検証（将来の重なりもチェック）
  P->>Staker: 取引を受理
  P->>P: pending setへ登録
  Note over P: 現在時刻が進む
  P->>P: StartTime到来でcurrent setへ移動

変更後（受理と同時開始）の流れ

sequenceDiagram
  participant Staker as ステーカー
  participant P as P-chain
  Staker->>P: ステーキング取引を送信（StartTimeなし）
  P->>P: 取引を検証（現在の総ステークのみ確認）
  P->>Staker: 取引を受理
  P->>P: 受理と同時にcurrent setでアクティブ化

互換性

ACP41は、取引タイプのステート遷移（state transition）を変更する提案です。ステート遷移の変更は「実行時の挙動そのもの」を変えるため、必ずネットワーク全体でのアップグレードが必要になります。つまり、あるノードが新しい挙動を採用し、別のノードが古い挙動を続けてしまうと検証結果に食い違いが生じ、合意が崩れてしまう可能性があるためです。そのため、有効化前に挙動を変えることは絶対に避けなければならないと明記されています。

ACP41では、新しい取引形式を導入したり既存の形式を変更したりしているわけではありません。したがって、ウォレットの実装において、署名方式やトランザクション構造を変更する必要はなく、基本的にこれまで通り動作します。

ただし注意点があります。ウォレットが生成する取引のEndTimeが、CurrentChainTime + MaxStakeDuration以上となってしまう場合、その取引は新しい仕様のもとでは拒否されます。つまり、ウォレット側は「取引が拒否される条件」を理解し、適切な終了時刻を設定する必要があります。

ここで登場するCurrentChainTimeは、P-chain上の最新ブロックのタイムスタンプ以上であることが保証されている値です。したがって、ネットワークの共通基準時刻として信頼できます。

参考実装

ACP41で提案されているのは「ステート管理の方法」であり、新しい取引形式や追加フィールドの導入ではありません。そのため、まだリファレンス実装は存在していません。各AvalancheNetworkClient（ANC：Avalancheネットワークのクライアントソフトウェア）は、自分たちの実行ステップを提案に沿うよう修正する必要があります。

Avalanche公式のクライアント実装であるAvalancheGoについては、以下のプルリクエストで対応が進められています。 ava-labs/avalanchego/pull/2175