現在イーサリアムのネイティブステーキングに参加する際、なぜまず1ヶ月も待たなければならないのか？

最近、イーサリアムのネイティブステーキングに直接参加したことがあるなら、ETH を入金してオンチェーン取引も成功したのに、バリデータがいつまでも稼働を始めず、「待機中」のままになっていることに気づいたかもしれない。

しかも、この待機はおそらく1か月以上に及ぶ。

9月16日時点で、イーサリアムには依然として180万枚以上のETHがバリデータセットへの参加を待っており、予想待機時間は約32日。今年7月には待機時間が一時43日を超え、3月のキューのピーク時には約340万枚のETHが入口で詰まり、待機時間は60日に近づいた。

つまり、「1か月待ち」は決して誇張ではない。

しかし、そこに問題も生じる。

イーサリアムは平均12秒ごとに1つのSlotを生成し、通常の取引はすぐに確認される。なぜステーキングとなると、数十億ドル相当のETHが何十日もその場で待たなければならないのか？さらに重要なのは、この何十日間に収益はあるのか？なぜ今ステーキングに入るには1か月以上待つのに、退出はわずか数分で済むことがあるのか？

その答えは、イーサリアムの非常に重要でありながら一般ユーザーにはほとんど気づかれないメカニズム、Validator Queue（バリデータキュー）の中にある。

一、「1か月待ち」は一体どうやって計算されるのか？

まず最も誤解されやすい点を言っておくと、イーサリアムは新しくステーキングされたETHが40日間ロックされなければ稼働できないとは規定していない。

1か月はあくまで動的な結果である。

簡単に言えば、前に待っているETH ÷ イーサリアムが1日に入場を許可するETH = おおよその待機時間、と理解できる。

イーサリアムPoSはすべての新規バリデータが一度にネットワークに入ることを許可せず、Churn Limitと呼ばれる速度制限メカニズムを設け、各Epochで最大どれだけのステーキング残高がバリデータセットに参加できるかを制御している。

1つのEpochは32のSlotを含み、各Slotは約12秒なので、1つのEpochは約6.4分、1日で約225のEpochを経ることになる。

Pectra / Electra以降、イーサリアムはこの制限を単純なバリデータ数ではなく「ETH残高」で計算するようになり、現在の新規ステーキングの処理上限は1Epochあたり256 ETH。すべて従来の32 ETHバリデータに換算すると、6.4分ごとに最大8つの標準バリデータを通過させることに相当する。

こうして1日に入場できるETH量も簡単に計算できる：256 ETH × 225 ≈ 57600 ETH/日。

したがって、前に約183万枚のETHが入場を待っているなら、183万 ÷ 5.76万 ≈ 32日。これが「1か月待ち」の最も核心的な根拠である。

そのため、この数字は毎日変動する。

毎日新たにキューに入るETHが57,600枚を下回れば、滞留は徐々に解消され、40日が30日、20日になることもある。逆に、毎日この数を超えるETHが流入し続ければ、列は短くなるどころかますます長くなる。

今年3月に約340万ETHが待機し、待ち時間が60日に近づいたのは極端な例である。

つまり、これは普段私たちが理解する「イーサリアムが混雑しているかどうか」とはまったく別物である。

Gasが低く、ブロックスペースが潤沢であっても、バリデータがすぐに参加できるわけではない。それを制限しているのは実行層の取引容量ではなく、イーサリアムが能動的に設けたバリデータ入口の速度制限器だからだ。

二、なぜ入口を一気に開いて、すべてのETHを一度に入れないのか？

何十日もの待機が資金がステーキング収益を生み出せないことを意味するなら、最も直接的な解決策は簡単に思える。256 ETH / Epochの上限を引き上げればいいのではないか？

問題は、バリデータが普通のアカウントではないことだ。

1件のETH送金が完了すれば、基本的にネットワーク全体に継続的な負担をかけることはない。しかし、1つのバリデータが一度アクティブ化されると、長期的にイーサリアムのコンセンサスシステムに入り、ブロック証明、委員会の割り当て、ネットワークコンセンサスに参加することになる。

現在、イーサリアムにはすでに90万以上のアクティブバリデータがあり、ステーキングされたETHは4200万枚を超えている。新たに追加される各バリデータは、この巨大なコンセンサスシステムの一部となる。

これが、イーサリアムがバリデータセットの変化速度を能動的に制御し続けている理由である。

2023年に提案されたEIP-7514は、まさにバリデータのアクティブ化速度に上限を設けた。その背景にある懸念は「ステーキングする人が多すぎるのは良くない」ということでは決してなく、むしろ逆である。バリデータ数が短期間に無制限に増加すると、コンセンサス層の状態規模、バリデータ管理、ネットワーク通信と処理の負荷がそれに伴って上昇する。

Pectra以降、イーサリアムは単一の複利バリデータの有効残高を最大2048 ETHまで引き上げることを許可した。これは部分的には、大量のステーキング資金を何千もの32 ETHバリデータに分割する必要をなくし、バリデータ数の継続的な膨張による追加負担を軽減するためでもある。

しかしそれ以外にも、Churn Limitにはより根本的な目的がある。それは、イーサリアムのセキュリティを維持する人々が短期間に激変しないようにすることだ。

何しろPoSネットワークのセキュリティは、現在のアクティブバリデータセットに依存している。

もし大量のステーキング資金が瞬時に入場または退出できるなら、誰がコンセンサスに参加する資格を持つか、どれだけの経済的セキュリティがシステムに残っているかを判断する基盤も急速に変化してしまう。そのためイーサリアムは、こうした変化に人為的な速度上限を設ける必要がある。

これが、「待機」が修正すべきBugではない理由である。

ユーザーの観点から見れば、確かに資金効率の一部を犠牲にしている。しかしプロトコルの観点から見れば、これはむしろ意図的に設けられた減速帯のようなもので、イーサリアムは数百万枚のETHを入口で何十日も待たせることを選んでも、バリデータセットが数日間で突然膨張したり収縮したりすることを望んでいないことを示している。

甚至、将来のロードマップから見ても、この考え方は変わっていない。

現在Glamsterdamに含めることが計画されているEIP-8061は、退出とバリデータ統合の処理能力を大幅に引き上げ、退出渋滞を緩和する準備をしているが、アクティブ化側の256 ETH / Epochの上限は依然として維持する計画である。

言い換えれば、イーサリアムは「出る」ことをより柔軟にしようと考えているが、当面は「入る」の門を完全に開放する準備はしていない。

三、待機期間中に収益はあるのか？なぜ今は退出がこんなに速いのか？

では、ETHを入金して待っているこの1か月はステーキングに含まれるのか？

プロトコル報酬の観点から言えば、含まれない。

バリデータが実際にActive、つまり「アクティブ」状態になって初めて、証明の実行やブロック提案などの検証作業を行い、対応するイーサリアムプロトコル報酬を得る。

それ以前は、ステーキング取引が完了し、ETHがステーキングプロセスに入っていても、バリデータがPendingのままであれば、通常のバリデータステーキング報酬は発生しない。Ethereum.orgは「Active」をバリデータが稼働し収益を生み出し始める時点としている。

これが、長い列が一般ユーザーに実際に影響を与える点である。

現在のネットワーク全体のステーキングAPR約2.6%で概算すると、32 ETHのバリデータ1台が40日待つ場合、約0.09 ETHの潜在的なプロトコル収益を失うことに相当する。

単独で見ればそれほど誇張されたものではないが、数万、数十万枚のETHを展開する必要がある機関にとっては、40日間の資金遊休コストは急速に拡大する。

これも、最近イーサリアムのステーキングキューが機関やETHトレジャリー企業からますます注目されている理由である。以前は異なるステーキング方案を比較する際、最も目につきやすかったのはAPRが数ポイント違うとか、手数料がいくらかといったことだった。しかし待機自体が1か月以上に及ぶ可能性があると、「いつ実際に収益を生み出し始められるか」も資金効率の一部となる。

ただし、ここには非常に興味深い対照がある。

退出キューを確認すると、待機時間はわずか数分から数時間であることが多い。まさかイーサリアムは素早い逃げ出しは許可するが、素早い参入は許可しないのか？

実はそうではない。参入と退出にはどちらもChurn Limitがあり、両方ともプロトコルによる速度制限を受ける。ただ、キューの長さは最終的に何人が並んでいるかに依存する。

現在200万枚以上のETHが参入を望んでいる一方、実際に退出を待っているETHは非常に少ない。そのため同じ速度制限された道路でも、片側は数十キロの長蛇の列ができ、もう片側はほぼ渋滞がない。

また、「退出キューが短い」ことは、ETHが数分後にすぐウォレットに戻ることを意味しない。バリデータが退出を完了した後も、固定の256 Epoch、約27時間待って引き出し可能状態になる必要があり、その後さらにイーサリアムの自動Withdrawal Sweepが資金を引き出しアドレスに送るのを待つため、プロセス全体でさらに数日かかる可能性がある。

一般ユーザーにとって、これは異なるステーキング方法の間に見落とされがちな差異が生じることも意味する。

自分でバリデータを運用する場合、またはimTokenのような非カストディアルETHステーキングサービスを通じて独立したバリデータを作成する場合、基盤としては実際にイーサリアムのバリデータセットに参加する必要があるため、このプロトコルキューを経験しなければならない。例えばimTokenの非カストディアルステーキングでは、ユーザーが引き出しキーを保持し、ノードサービスプロバイダーがバリデータの運用を担当する。ページに「待機中」と表示される時、本質的にはバリデータがイーサリアムの通過許可を待っており、状態が「アクティブ」に変わって初めてプロトコル収益が発生し始める。

一方、一部のリキッドステーキングプールは、すでに大量のアクティブバリデータと流動性トークンが存在するため、製品レベルでこの待機をある程度抽象化でき、ユーザーが何十日もの「ゼロ収益待機期間」を直接感じるとは限らない。

ただし、その代償として別の信頼境界が導入される。スマートコントラクト、LST流動性、プロトコルガバナンス、資産交換などの追加リスクである。これもAPRにしばしば覆い隠される問題である。つまり、Stakingの真のコストは決して手数料と利回りだけではない。

資金がいつ入り、いつ実際に稼働し始め、いつ退出でき、その過程で誰が資産の制御権を握るかは、それ自体がステーキング製品の一部である。

最後に

表面上は、イーサリアムが数百万枚のETHを入口に1か月以上並ばせるのは、かなり非効率な設計に見える。

しかし視点をネットワーク全体に切り替えると、むしろ理解できる。何しろ通常の取引が追求するのはできるだけ早い実行であり、バリデータが関わるのは誰が次の瞬間のイーサリアムコンセンサスを維持するかである。

前者はますます速くなることを追求できるが、後者はむしろ節度が必要である。

つまり、これはステーキング需要がプロトコル設定の参入速度をはるかに超えた結果、本来目に見えなかった安全柵が、肉眼で見える長い列として並んでしまったのである。

ある意味で、この列が長ければ長いほど、少なくともこの段階ではイーサリアムのバリデータセットに参入したいステーキング需要がプロトコルが許容する参入速度を継続的に超えていることを示している。

しかし外にどれだけの人が立っていようと、イーサリアムは依然として自分のペースで、1つのEpoch、また1つのEpochと門を開くだけである。