海外ステーキングサービスの失敗事例から学ぶべきこと

はじめに

本記事では、海外で実際に起きたステーキングサービスに関連するインシデントをもとに、 ステーキングのリスクと規制について で説明したステーキングにおけるリスクがどのように現れたのか、ステーキングサービスの運用においてどういったことを注意しなければならないか説明します。本記事では、①カストディ型②セルフカストディ型のステーキングサービス、加えて、ステーキングする資産を外部のコントラクトにロックすることで、ステーキングを行いながら債権トークン(リキッドステーキングトークン, LSTと呼ぶ)を取得でき、追加の利回りを追求できるリキッドステーキングに関連する事例の中で、以下のような事象が起きたものを扱います。

• 顧客資産の直接喪失
• スラッシングによる損失
• ノード停止による報酬損失
• リキッドステーキングトークンの価格乖離・流動性低下
• 顧客損失はないが、運用上の障害

直近5年程度の主なステーキング関連インシデント

まず、全体像をつかむために、直近5年におけるインシデントの事例集を記載します。サービス類型については、バリデータの署名鍵及び顧客資産の秘密鍵を保有するかどうかで判断します。

1. カストディ型：バリデータの運用事業者は、バリデータの署名鍵及び顧客資産の秘密鍵を保有する
2. セルフカストディ型：バリデータの運用事業者は、バリデータの署名鍵を保有するが顧客資産の秘密鍵は保有しない

リキッドステーキングトークンはほとんどが特定事業者のコントラクトに預け入れを行うため、本記事ではカストディ型（リキッドステーキング）とします。 なお、セルフカストディ型においては、バリデータの署名鍵を運用事業者に預けバリデータの運用を委託することができます。サービス類型として”-“を付しているものはバリデータのソフトウェアのバグ等、全類型に影響するものを指します。

以下一覧から、上で記載したどの類型についても幅広く障害が起きていること、またソフトウェアのバグ等の全類型に影響するものも起きていることがわかります。

主要3類型の事例の深堀

表の中から、それぞれの類型ごとに事例を時系列も含め深堀します。 各事例は、セキュリティインシデントを追うときと同じように、①概要、②時系列情報、③原因、④対策の順に整理します。

カストディ型：StakeHound-Fireblocks

概要

カストディ型ステーキングでよくある事例は顧客資産や引き出し権限に関わる鍵に関する不備です。StakeHound / Fireblocks の事例を元に、カストディ型でどういったことを留意する必要があるか議論します。

StakeHound は 2021年、署名鍵が利用できなくなる問題により、38,178 ETH にアクセスできなくなったインシデントを公表しました。StakeHound は署名鍵のバックアップを Fireblocks が怠ったと指摘している一方、Fireblocks は、当該署名鍵は Fireblocks の本番ウォレットやバックアップ手順の外で管理されており、バックアップの責務はStakeHoundにあったと説明しています。本件はイスラエル裁判所での訴訟案件に発展しています。

真実がどちらかではなく、カストディ型においては委託先との責任分界が重要であり、特に秘密鍵の管理・処理のタスクを分割し、それぞれの分担を明確にしておくことが必要です。

時系列情報

• 2020年12月：Fireblocks は、StakeHound の依頼により、バリデータ署名鍵の作成に協力した(Fireblocks談)。
• 2021年4月29日：Fireblocks は復旧訓練の中で、バックアップから一部のバリデータ署名鍵を復号できないことを確認した(Fireblocks談)。
• 2021年5月2日：StakeHound は、Fireblocks から 38,178 ETH がアクセス不能になった可能性を通知された(StakeHound談)。

原因

StakeHound は、Fireblocks が 3-of-4 の閾値署名(管理者が4人おり、そのうち3人の署名が必要)を用いた引出しアドレスを管理できなくなったと主張しています。具体的には、Fireblocks が本番環境以外で秘密鍵を生成し、必要な秘密鍵をバックアップに含めず、鍵を失ったと説明しています。

これに対し Fireblocks 側は、 Fireblocks 管理外でのプロジェクトであり、StakeHound側が適切にバックアップしていなかったと説明しています。

対策

カストディ型ステーキングでは、鍵管理と復旧体制がどれだけ明確に文書化・管理されているかが重要です。

• 引出しアドレス・バリデータの署名鍵を分けて管理主体を確認する
• 鍵生成、鍵のバックアップ、復旧テストの責任分界（外部委託先を含める）を確認する
• 復旧訓練の頻度、復旧不能時の通知手順、顧客向け説明の範囲を確認する

セルフカストディ型：Staked.us

概要

セルフカストディ型では、利用者が預ける資産や引出アドレスを自分で管理しつつ、バリデータ運用だけを外部事業者に委託することができます。Staked.us の事象は、バリデータ運用の委託リスクを示す事例です。Staked は、2021年2月2日に同社が運用する75バリデーターがスラッシュされたと公表し、顧客への補填方針を説明しました。

時系列情報

• 2020年12月から2021年1月頃：Staked は署名率改善を目的とし、複数の性能向上策をテスト環境で行い、本番環境に展開した。
• 2021年2月2日：Staked が運用する75バリデーターでスラッシングが発生した。
• 2021年2月3日：Staked は説明記事を公開し、性能改善を優先した結果、二重署名の保護を犠牲にしたと説明した。
• 記事公開後：Staked は、Prysmスラッシング保護DBの永続化を復旧させ、ノードが同期しきるまでバリデータソフトウェアと接続できないようにする運用変更を公表した。

原因

Staked は、自社のバリデータの署名失敗の改善対応の中、Prysm の スラッシング保護DBが I/O 負荷を生んでいたことから、別の二重署名保護機能として Hashicorp Consul を使い、Prysm のスラッシング保護DBを利用しない構成にしていたと説明しています。しかしながら、本番環境では負荷状況がテスト環境と異なり、バリデータソフトウェアの再起動が想定より頻繁に発生した結果、Prysm 側のスラッシング保護DBを無効化していたバリデータが二重署名を行いスラッシングにつながりました。

ステーキングサービスを運営する場合は、短期的な署名失敗を減らすことより、二重署名を可能な限り起こさない設計・運用を優先する必要があります。

対策

セルフカストディ型でバリデータ運用を第三者に委任する場合、どういった方針で運用しているかの確認が必要です。

• 二重署名保護機能の運用方針を確認する
• ソフトウェア標準の保護機能にカスタムを行う場合、ノードやバリデータソフトウェアの変更を、本番規模に近い負荷で検証しているかを確認する
• スラッシング時に運用者が補填するのか、利用者が負担するのかを確認する

カストディ型（リキッドステーキング）：Lido-stETH

概要

Lido stETH はLidoが管理するスマートコントラクトにETHをロックすることで、ステーキングの利回りを受け取りつつ、stETHとして送金可能な債権トークンです。本トークンの2022年の価格乖離は、ステーキング自体が正常でも、流動性の影響で利用者の損失が発生することを示しています。Lido のバリデータ運用が停止したわけではなく、ステークしているETHは毀損していません。stETHをETHに変換するには、一定期間の待機の後請求するか、即座に売却する方法があります。今回の事象においては、待機後の請求と即座の売却との乖離が大きくなりました。

時系列情報

• 2022年5月7日から5月16日：Terraチェーンの崩壊後、615,980 bETH が Terra から Ethereum にブリッジされ、多くがstETHに変換されました。
• 2022年5月9日から5月12日：Curve stETH/ETH プールの TVL は 約40億ドルから約19億ドルへ半分に低下した。Celsius と Three Arrows Capital が 5月12日に合計約8億ドルの流動性を引き出しました。
• 2022年5月12日：Lido は一時的な流動性追加を行い、100万$LDOの流動性報酬を付けました。
• 2022年6月11日：stETH/ETH の価格は 0.94 まで低下した。

原因

直接の原因は、Lido のステーキングサービスの運用の障害や、バリデータ運用の障害等ではなく、流動性でした。stETH は、ステーキングしたETHの代わりに得られる債権トークンであり、当時(2022年時点)ではstETHを償還する機能が実装されておらず、二次市場で直接stETHをETHに変換するしかありませんでした(2026年現在では、約10日ほどでstETHをETHにプロトコルの機能で償還することができます)。Terraチェーン崩壊時、bETH(Terraチェーン上でのstETHのブリッジトークン)がEthereumチェーン上のstETHにブリッジされ、大量に売却されることでその直前時点でのstETH/ETH価格から大幅に乖離することとなりました。これには、レンディングプロトコル等で担保として利用されていたこと、Celsius, 3ACによる流動性回収の影響があったといわれています。

stETHはあくまでステーキングしたETHに対する債権ですが、その償還の有無や市場の状況により、大きく価格変動の可能性があることを示した事例です。

対策

カストディ型のリキッドステーキングを使う場合は、バリデータ運用品質に加えて、LST の償還設計と二次市場流動性を確認する必要があります。

• LST をステーキング元資産に戻す方法が①プロトコルの償還機能なのか②二次市場での売却なのかを確認する
• 償還ができない期間や償還にかかる期間がある場合、その間の価格乖離リスクを確認する
• ②二次市場での売却の場合、主な流動性がどのDEXのプール、CEX、OTC、市場参加者に依存しているかを確認する
• LST がレンディングプロトコルの担保やレバレッジ取引に使われているかを確認する
• 乖離時の対応として、プロトコルの運営チームによる流動性の追加、乖離縮小方向のトレードに対するインセンティブ、リスク開示、清算連鎖への注意喚起が準備されているかを確認する

事例から得られる教訓

各事例の対策において、特に重要な項目は以下の通りです。

1. 鍵管理と責任分界の粒度

鍵の管理というタスクだけを各事業者に分散するのではなく、必須タスクである生成・バックアップ、障害時の鍵復旧まで含め、誰が実施するかを確認できる必要があります。

2. クライアント選定とクライアント集中

セルフカストディ型であっても、クライアントソフトウェアのバグというリスクが存在します。Ethereumのステーキングにおいては、コンセンサスクライアント、エグゼキューションクライアント、バリデータクライアントの3種を全て動作させておく必要がありますが、どれがとまっても、報酬損失につながります。バリデータの多くが同一のクライアントを用いていれば、ある一種類のソフトウェアのバグでも影響は致命的となります。ステーキングサービスの提供においては、単独のソフトウェアの仕様のみに固執せず、複数のクライアントを切り替え可能なことが望ましいです。

3. アップグレード・作業手順の検討における二重署名への留意

Staked.us、RockLogic、Launchnodes、SSV の事例では、稼働率改善や障害復旧のための変更が、結果として二重署名につながっています。各種作業手順（フェイルオーバー等）、移行前リハーサルにおいても、二重署名が起こる可能性をできうる限り最小化する必要があります。

4. 報酬損失と補填方針

2のソフトウェアのバグやデータセンター障害によるバリデータの停止では、スラッシングは発生しないことが多いですが、署名の失敗により報酬損失が発生します。これについても補填するのか、補填する場合原資はオペレーターなのかその他保険的なファンドなのか条件を確認する必要があります。

5. LST の流動性

Lido stETH、Renzo ezETH の事例では、LSTの償還の期間の長短に応じ、資金ロック期間が発生するため、二次市場価格が割安になることが一般的です。償還待ち期間や二次市場の流動性の厚みやレンディングプロトコルでの利用状態を確認し、どれくらい急激な価格変動が起きうるのか見積もる必要があります。

まとめ

以上の事例では、カストディ型では複数の事業者が一体としてサービスを提供しているとき、責務の分担、責任分界が不十分であるときにスラッシングや顧客資産の損失につながりました。セルフカストディ型では、バリデータの署名鍵のみ保有するバリデータの運用事業者の運用指針により、スラッシングが発生しました。カストディ型（リキッドステーキング）においては、運用自体には一切の不手際がなくとも、他チェーンでのイベントに応じ、流動性が毀損されることで、LST自体の価値が毀損しました。

自身にほぼ非がなく事故が発生することもあります。重要な点は、ステーキングサービスの運用指針や、責任帰属が明確であるか、顧客資産の損失が起きうるのか、補填がなされるかです。

今回実例として挙げた、ステーキングに伴う技術・運用上のリスクについては、ステーキングのリスクについてで整理しています。