イーサリアムのネイティブステーキングはなぜ"32日待ち"になるのか

最近、イーサリアムのネイティブステーキング（自前でのバリデータ参加）を行った人の中には、ETHのデポジットは完了しオンチェーン取引も成功しているのに、バリデータ状態が"Queueing"（待機）から進まず稼働しないケースに直面しているだろう。この待ち時間は1カ月超になることも珍しくない。 9月16日時点で、バリデータ集合への参加を待つETHは180万ETH超。推定待機時間は約32日となっている。7月には待機時間が43日超まで伸び、3月のピーク時には約340万ETHが入口で滞留し、待機は60日近くに達した。つまり"1カ月並ぶ"は誇張ではない。 平均12秒ごとに新しいスロットが生成され、通常の送金や取引は比較的速く確定する。では、なぜステーキングだけが何十億ドル規模のETHを何週間も待たせるのか。待っている間に利回りは発生するのか。さらに、参加に1カ月以上かかる一方で、退出は数分で済むことがあるのはなぜか。鍵になるのは、見落とされがちな"バリデータ・キュー"という仕組みだ。 ■ "1カ月待ち"はどう計算されるのか よくある誤解は、"新たに預けたETHは40日ロックされないと稼働できない"というものだ。実際の待ち期間は固定ではなく、日々変動する。 考え方は単純で、"列に並ぶETH量"÷"1日に処理できる参加上限"≒"待機日数"となる。 イーサリアムのPoSは、新規バリデータの同時大量参加を許さない。代わりにChurn Limit（流入出上限）で、1エポック当たりにバリデータ集合へ加えられるステーク量に上限を設けている。1エポックは32スロットで、1スロットは約12秒。したがって1エポックは約6.4分、1日当たり約225エポックとなる。 Pectra/Electra以降、この上限は単なる"バリデータ数"ではなく、より"ETH残高"に基づいて算定されるようになった。現在の新規参加の処理上限は1エポック当たり256ETH。これを従来の32ETHバリデータに換算すると、6.4分ごとに最大8体が承認される計算だ。 1日に処理できるETHは、256ETH×225≒57,600ETH/日。待機が約183万ETHなら、183万÷57,600≒32日となり、"約1カ月"の根拠になる。 この数字はキューへの流入次第で毎日変わる。1日当たりの新規流入が57,600ETHを下回れば滞留は解消に向かい、待機は40日から30日、20日へ短縮し得る。反対に流入が上回れば列は短くならず、むしろ伸びる。3月の約340万ETH・約60日待ちは、その極端な例だ。 重要なのは、これは一般に言う"ネットワーク混雑"とは別物だという点である。ガス代が低くブロックスペースに余裕があっても、バリデータ参加が即時になるわけではない。制約しているのは実行レイヤーの処理能力ではなく、プロトコルが意図的に設けた参加速度の上限だ。 ■ なぜ入口を全開にしないのか 何週間も待てば、その間はステーキング報酬を得られない。直感的には"上限（256ETH/エポック）を引き上げればよい"と思える。 だが、バリデータは単なるアカウントではない。ETH送金は完了後にネットワークへ継続的負荷をほぼ残さない一方、バリデータが有効化されると、長期にわたり合意形成へ参加し、アテステーションや委員会割当、ネットワーク通信・処理を継続的に担う。 現在イーサリアムには90万超のアクティブバリデータが存在し、ステークは4,200万ETH超。新規バリデータはこの巨大な合意システムの一員となるため、プロトコル側はバリデータ集合の変化速度を積極的に管理してきた。 2023年に提案されたEIP-7514は、バリデータ有効化ペースに上限を設けた代表例である。狙いは"ステーキングが増えるのは悪"ではなく、無制限に急増すると、コンセンサス層の状態サイズ拡大、運用・管理コスト増、通信・処理の圧力上昇を招く点にある。 Pectraアップグレード後は、単一バリデータの有効残高を最大2,048ETHまで引き上げられるようになった。大口のステークを32ETH単位に細切れして数千体のバリデータを作る必要を減らし、バリデータ数の増加がもたらす負担を抑える意図がある。 それでもChurn Limitには、より根本的な役割がある。短期間に"イーサリアムの安全性を担う主体の構成"が急変するのを防ぐことだ。PoSの安全性は、稼働中のバリデータ集合に依存する。巨額のステークが瞬時に流入・流出できると、合意参加資格や経済的安全性の水準が急激に変動し得る。そこでイーサリアムは、人為的に変化速度の上限を置いている。 この意味で"待機"は不具合ではなく、意図された減速帯に近い。資本効率は落ちるが、プロトコルとしては、数日で集合が急拡大・急縮小するリスクを負うより、何百万ETHが数週間入口で待つ方を選ぶ設計になっている。 将来計画でも基本姿勢は変わらない。Glamsterdamで計画されるEIP-8061は、退出処理やバリデータ統合（マージ）の処理能力を大幅に高め、退出側の混雑を緩和する狙いとされる。一方で参加側は256ETH/エポックの上限維持が想定され、"出る"柔軟性は上げても"入る"門戸を全面開放する段階ではない。 ■ 待機中に利回りは発生するのか、なぜ退出は速いのか デポジット後、1カ月待つ間もステーキング扱いになるのか。プロトコル報酬の観点ではならない。バリデータが本当に"Active"状態に入って初めて、アテステーションやブロック提案を行い、報酬を得る。Pendingの間は、手続きが進んでいても通常のバリデータ報酬は発生しない。Ethereum.orgも報酬発生の起点を"Active"としている。 この待機がユーザーに与える影響は現実的だ。ネットワーク全体のステーキングAPRが約2.6%という前提では、32ETHバリデータが40日待つと、機会損失は概算で約0.09ETHになる。個人には小さく見えても、数万〜数十万ETHを配分する機関投資家にとって、40日分の遊休コストは無視できない。近頃、機関やETHトレジャリー企業がステーキング・キューに注目する理由でもある。 一方、退出キューを見ると、待機が数分〜数時間に収まることが多い。"退出はすぐ許すが参加は遅い"ように見えるが、実際には参加・退出の双方にChurn Limitがあり、どちらもレート制限されている。最終的な待機時間の差は、単に"並ぶ人（ETH）が多いか少ないか"で決まる。現在は参加待ちが200万ETH超なのに対し、退出待ちは少ないため、片側だけ渋滞している状態だ。 また、"退出キューが短い"ことは、数分でウォレットへ戻ることを意味しない。バリデータが退出を完了しても、引き出し可能状態になるまで固定で256エポック（約27時間）待つ必要がある。その後も、イーサリアムの自動Withdrawal Sweepで引き出しアドレスへ送られるまで、さらに数日かかる場合がある。 この点はステーキング手段の違いとしても現れる。自前でバリデータを運用する場合や、imTokenのようなノンカストディアル型サービスで独立バリデータを作る場合、いずれも最終的にはイーサリアムのバリデータ集合へ正式参加する必要があり、プロトコルのキューを通過しなければならない。たとえばimTokenのノンカストディアル・ステーキングでは、ユーザーが出金鍵を保持し、ノード事業者が運用を担う。画面で"Queuing"と表示されるのは、承認待ちで稼働前の状態を示し、"Active"に変わって初めてプロトコル報酬が発生する。 一部のリキッドステーキングは、多数の稼働中バリデータと流動性トークンを背景に、この待機をプロダクト側で吸収し、ユーザーが"無報酬の待ち"を体感しにくい設計になっている場合がある。その代償として、スマートコントラクト、LSTの流動性、プロトコルガバナンス、スワップなど別の信頼境界とリスクが増える。APRや手数料だけでは見えにくいが、ステーキングのコストは利回りとフィーに限られない。資金がいつ働き始め、いつ引き出せ、プロセスのどこで誰が資産をコントロールするかも、商品性の一部だ。 ■ まとめ 表面的には、何百万ETHを1カ月以上も入口で待たせる設計は非効率に映る。だがネットワーク全体で見れば、通常取引は迅速な実行が目標である一方、バリデータは次の瞬間の合意形成そのものを支える存在だ。前者は速度を追求できても、後者は抑制が必要になる。 現在の長い列は、ステーキング需要がプロトコルの参加許容量を大きく上回ったことで、これまで目立たなかった安全装置が可視化された結果と言える。待機が長いほど、現時点で"バリデータとして参加したい需要"が、プロトコルが許容する参加ペースを上回っていることを示す。 どれだけ外に人が並んでも、イーサリアムが扉を開けるのは自ら定めた速度のまま。1エポックずつ、着実に、である。