スラッシング

スラッシングとは？

スラッシングとは、バリデーターが重要なネットワークルールに違反した場合に、そのステーキングした暗号資産の一部を削減、バーン、没収、または再分配するProof of Stakeのペナルティです。

暗号資産では、ブロックチェーンのセキュリティ、ファイナリティ、稼働率、コンセンサスの完全性を損なう可能性のある行為について、バリデーターに経済的責任を負わせるためにスラッシングが使用されます。

公式のEthereum Proof of Stakeドキュメントでは、バリデーターは価値をリスクにさらしており、不正行為をした場合にはその価値が失われる可能性があると説明されています。

スラッシングイベントは、バリデーター自身のステークに影響し、一部のネットワークでは、そのバリデーターを選んだユーザーの委任ステークにも影響する場合があります。

スラッシングは、二重署名、矛盾する投票、無効な行為、重大なコンセンサスルール違反などのバリデーター不正行為と最も関連します。

一部のProof of Stakeネットワークでは、ダウンタイム、投票漏れ、ライブネス障害に対して、より小さいペナルティまたはジェイリングを用いることもあります。

スラッシングルールはすべてのブロックチェーンで同一ではありません。

Ethereum、Solana、Cosmos SDKチェーン、Polkadot形式のNominated Proof of Stakeシステム、その他のステーキングネットワークでは、それぞれ異なるペナルティモデルが使用されています。

簡単に言えば、スラッシングは、実際の資本をリスクにさらすことでバリデーターの約束に信頼性を持たせる、暗号資産ステーキングにおける処罰です。

スラッシングが重要な理由

スラッシングが重要なのは、Proof of Stakeのセキュリティが、バリデーターに失うべき意味のあるものがあることに依存しているためです。

Proof of Workシステムでは、マイナーが電力とハードウェア資源を使ってチェーンを保護します。

Proof of Stakeシステムでは、バリデーターが資本をロックし、有害なメッセージに署名したりコンセンサスルールに違反したりした場合、その一部を失うリスクを負います。

この経済的リスクは、バリデーターが複数の矛盾するチェーン履歴を同時に支持することを抑止するのに役立ちます。

また、確定したチェーンに矛盾するには高いコストが伴うべきであるため、ファイナリティの保護にも役立ちます。

公式のEthereumの報酬とペナルティに関するドキュメントでは、スラッシングはバリデーターをネットワークから除外し、ステーキングされたETHの損失を生じさせる重大な措置と説明されています。

ネットワークのステーキング設計によっては、委任者もバリデーターリスクを共有する可能性があるため、スラッシングは委任者にとっても重要です。

信頼性の低い、または悪意のあるバリデーターに委任したユーザーは、一部のチェーンでステークの一部を失う可能性があります。

このため委任者には、単に表示報酬が最も高いバリデーターを選ぶのではなく、慎重に選ぶインセンティブが生じます。

したがって、スラッシングはコンセンサスのセキュリティツールであると同時に、ユーザーが資産を委任する前に理解すべきステーキングリスクでもあります。

スラッシングの仕組み

スラッシングでは、バリデーターがルールに違反した証拠を検出し、プロトコルで定められたペナルティを適用します。

証拠は、ブロックチェーンに応じて、署名済みメッセージ、矛盾するブロック提案、矛盾する投票、ライブネス閾値未達、その他の証明である場合があります。

バリデーターのメッセージは暗号学的に署名されているため、ネットワークは問題のメッセージを生成したバリデーターを証明できることがよくあります。

違反がプロトコルにより受理されると、バリデーターはステークの喪失、アクティブバリデーターセットからの除外、ジェイリング、トゥームストーニング、出金遅延などを受ける場合があります。

ペナルティは、固定、変動、比例、または同一インシデントに関与したバリデーター数と相関する形で設定される可能性があります。

スラッシュされたトークンをバーンするシステムもあります。

スラッシュされたトークンをトレジャリーへ送るシステムもあります。

スラッシングを主に抑止策として用い、重大なコンセンサス障害にのみ適用するシステムもあります。

通常のステーキング活動に対しては現在自動スラッシングを使用しないシステムもあります。

正確な結果は、チェーンのコンセンサスプロトコルとステーキングモジュールによって異なります。

Proof of Stakeにおけるスラッシング

Proof of Stakeでは、マイナーの代わりにバリデーターがブロック提案、ブロック投票、ネットワーク保護を支援します。

バリデーターは通常、コンセンサスに参加するためにトークンをロックまたはボンドする必要があります。

ロックされたステークは、誠実な行動のための担保として機能します。

バリデーターがルールに従う場合、ステーキング報酬を得る可能性があります。

重大なルールに違反した場合、ネットワークはステークの一部をスラッシュする可能性があります。

これにより、バリデーターの行動とコストの間に直接的な経済的関係が生まれます。

スラッシングは、バリデーターが矛盾するチェーンに署名してもほとんどコストを負わない可能性がある「nothing at stake」問題の解決に役立ちます。

矛盾した行為によってステーキングトークンが失われ得る場合、あらゆるフォークに署名することは無料の戦略ではなくなります。

スラッシングは、不正行為を観測可能、証明可能、かつ高コストにします。

これが、スラッシングが多くの現代的なProof of Stakeセキュリティモデルの中心となる理由です。

バリデーター

バリデーターとは、ブロック提案、ブロック投票、データ検証、その他のプロトコル業務を行い、Proof of Stakeコンセンサスの維持を支援するネットワーク参加者です。

バリデーターには、ノードソフトウェアの正しい運用、署名鍵の安全な保管、オンライン状態の維持、必要に応じたソフトウェア更新、矛盾する署名の回避が求められます。

署名済みメッセージはスラッシング可能な証拠となり得るため、バリデーターのミスは大きなコストにつながる可能性があります。

バリデーターは誠実であっても、インフラ設定の不備によりスラッシュされる場合があります。

たとえば、2台のアクティブなマシンで重複したバリデーター鍵を稼働させると、二重署名を引き起こす可能性があります。

ダウンタイムに対してスラッシングまたはジェイリングを行うネットワークでは、必要な参加閾値を満たせない場合にもペナルティを受ける可能性があります。

ステークを委任するユーザーは、バリデーターのパフォーマンス、インフラ品質、履歴、手数料、コミュニケーション、リスク管理を評価する必要があります。

バリデーターは単なる報酬生成者ではありません。

その行動が委任されたステークに影響し得るセキュリティ運用者です。

スラッシングにより、バリデーターの選択は重要なステーキング判断になります。

委任者

委任者とは、必ずしもバリデーターインフラを直接運用せずに、バリデーターへステークを割り当てるトークン保有者です。

委任により、一般ユーザーもステーキング報酬とネットワークセキュリティに参加できます。

ネットワークのルールがスラッシング損失を委任者に転嫁する場合、委任はユーザーをバリデーターリスクにさらす可能性もあります。

一部のネットワークでは、バリデーターの不正行為により、そのバリデーター自身のステークと委任されたステークの両方が減少する可能性があります。

公式のPolkadotステーキングドキュメントでは、攻撃が発生した場合、Nominated Proof of Stakeにおいてバリデーターとノミネーターの両方がスラッシュされ得ると説明されています。

これは、ユーザーがトークンのカストディを維持していても、委任がリスクフリーではないことを意味します。

委任者は、高い報酬や低い手数料だけを基にバリデーターを選ぶべきではありません。

稼働率、スラッシング履歴、インフラ運用の規律、自己ステーク、透明性、ガバナンス参加、分散化への影響も考慮する必要があります。

ネットワークが対応している場合、複数のバリデーターに分散することで単一バリデーターへのエクスポージャーを抑えられる可能性があります。

委任は単なる利回り設定ではなく、セキュリティ上の関係です。

二重署名

二重署名は、スラッシングの最も重要な原因の1つです。

二重署名は、バリデーターが同じコンセンサス上の役割、高さ、スロット、ラウンド、または投票コンテキストについて、2つの矛盾するメッセージに署名する場合に発生します。

Ethereumでは、同じスロットに対して異なる2つのブロックを提案すること、または矛盾するアテステーションを行うことがスラッシング可能な行為に含まれます。

公式のEthereumコンセンサス仕様のバリデーターガイダンスでは、Proposer SlashingとAttester Slashingが主要なスラッシング分類として説明されています。

Cosmos SDKシステムでは、二重署名は重大な処罰およびトゥームストーニングにつながる可能性があります。

公式のCosmos SDKスラッシングモジュールのドキュメントでは、トゥームストーン上限により、バリデーターは二重署名障害について一度だけスラッシュされ、その後トゥームストーン化されると説明されています。

二重署名は、重複鍵、安全でないフェイルオーバー、不適切な移行手順、スナップショットのミス、アクティブ・アクティブ構成のバリデーター設定によって起こることがよくあります。

バリデーターは、安全な署名アーキテクチャなしに、同一のコンセンサス署名鍵を2か所で同時に稼働させるべきではありません。

二重署名は、コンセンサスの安全性を直接脅かす可能性があるため危険です。

このため、多くのネットワークは単純なダウンタイムよりも二重署名を厳しく処罰します。

ダウンタイム

ダウンタイムとは、バリデーターがオフライン、到達不能、必要なメッセージへの未署名、または期待される参加の不履行となっている状態です。

一部のネットワークでは、ダウンタイムを二重署名より重大度の低い問題として扱います。

長時間のダウンタイムに対してスラッシングを行うネットワークもあります。

非アクティブなバリデーターをジェイルし、問題修正後の再参加を求めるネットワークもあります。

参加漏れに対し、それをスラッシングと呼ばずにペナルティを適用するネットワークもあります。

Ethereumでは、通常の業務漏れは一般にスラッシングではなくペナルティにつながります。スラッシングは、特定の不正な提案またはアテステーション行為に限定されます。

Cosmos SDKチェーンでは、スラッシングモジュールがバリデーターのライブネスを追跡し、ネットワークパラメーターに応じてペナルティまたはジェイリングを適用できます。

報酬が停止し、評判が損なわれる可能性があるため、ダウンタイムもコストが高くなり得ます。

委任者は、ダウンタイムを繰り返すバリデーターから再委任する可能性があります。

優れたバリデーターは、ダウンタイムリスクを抑えるため、監視、冗長化、アラート、安全なバックアップ、管理されたアップグレードを使用します。

エクイボケーション

エクイボケーションとは、コンセンサスルールの下で両立しない矛盾する記述にバリデーターが署名することです。

平易に言えば、プロトコルが一貫した回答を求めている場面で、異なる2つの回答を示すことです。

エクイボケーションは、二重のブロック提案、矛盾する投票、一貫しないファイナリティメッセージによって発生することがあります。

公式のPolkadotの違反に関するドキュメントでは、バリデーターがコンセンサスシステムで矛盾する投票を行うエクイボケーション違反が説明されています。

エクイボケーションは、フォーク選択を混乱させ、ファイナリティを弱め、チェーン履歴への攻撃を支援し得るため重大です。

スラッシングは、矛盾する署名を経済的損失に結び付けることで、エクイボケーションを高コストにします。

バリデーターソフトウェアには、偶発的なエクイボケーションを防ぐためのスラッシング保護が含まれることがよくあります。

ただし、不適切な鍵管理または安全でないフェイルオーバーは、依然としてエクイボケーションリスクを生む可能性があります。

委任者は、重複署名と鍵侵害をどのように防止しているかを説明するバリデーターを選ぶべきです。

エクイボケーションは、Proof of Stakeにスラッシング可能な証拠が必要な理由を最も明確に示す例の1つです。

Ethereumのスラッシング

Ethereumのスラッシングは、特定のコンセンサス違反を行ったバリデーターに適用されます。

Ethereumの報酬とペナルティに関するドキュメントでは、主なスラッシング可能行為として、同じスロットに対して異なる2つのブロックを提案・署名すること、surround voteを行うこと、同じターゲットに二重投票することの3つが挙げられています。

Ethereumバリデーターがスラッシュされると、バリデーターセットから強制的に除外され、ステーキングしたETHの一部を失います。

Ethereumのスラッシングには出金遅延期間中のペナルティも含まれ、多数のバリデーターが同時期にスラッシュされる場合、相関スラッシングはより厳しくなる可能性があります。

Ethereumのダウンタイムは、一般にスラッシングと同じではありません。

オフラインのEthereumバリデーターは報酬を失い、非アクティビティペナルティを受ける可能性がありますが、スラッシング可能なメッセージに署名しない限りスラッシュされません。

この区別は、Ethereumのスラッシングが主に署名の完全性に関する障害であることを示すため重要です。

最も一般的な運用上の教訓は、バリデーターが同じバリデーター鍵で矛盾するメッセージに決して署名してはならないということです。

Ethereumバリデーター運用者は、スラッシング保護データベース、安全な移行手順、慎重なフェイルオーバー設計を使用すべきです。

プール型またはサービス型ステーキングを利用する委任者は、誰がバリデーター鍵を運用し、スラッシングリスクをどのように扱うかを理解する必要があります。

Solanaのスラッシング

Solanaは、多くのProof of Stakeネットワークとは異なる形でスラッシングを説明しています。

公式のSolanaステーキングページでは、スラッシングは悪意あるバリデーター行為への処罰として、バリデーターに委任されたステークが破棄される可能性があるプロセスと説明されています。

同じSolanaページでは、Solanaにおけるスラッシングは自動ではないとも記載されています。

つまり、Solanaのステーキングリスクは、一般的なバリデーター障害に対して自動のプロトコルレベル・スラッシングを適用するネットワークと同じように説明すべきではありません。

Solanaの委任者には、パフォーマンス不良、報酬の逸失、手数料変更、カストディのミス、流動性タイミング、SOL価格のボラティリティなど、他のステーキングリスクが依然としてあります。

パフォーマンスが弱いSolanaバリデーターは、自動スラッシングがなくても低いステーキング報酬しか生み出さない可能性があります。

バリデーターの質は報酬とネットワークの分散化に影響するため、委任者は引き続き慎重に選ぶ必要があります。

Solanaの現在のスラッシングモデルは、スラッシングルールがチェーンごとに異なることを示しています。

ユーザーは、すべてのProof of Stakeシステムが同じように機能すると考えるのではなく、特定ネットワークの公式ステーキングドキュメントを読む必要があります。

ステーキングにおいてスラッシングという言葉は、常に使用するチェーンの文脈で解釈する必要があります。

Cosmos SDKのスラッシング

Cosmos SDKチェーンでは、二重署名やライブネス障害などのバリデーター障害を処罰するためにスラッシングモジュールを使用できます。

Cosmos SDKのスラッシングモジュールのドキュメントでは、バリデーターの署名情報、ライブネス追跡、二重署名の証拠、ジェイリング、トゥームストーニング、違反処理が説明されています。

多くのCosmos形式のステーキングシステムでは、バリデーターの不正行為がバリデーターと委任者の両方に影響する可能性があります。

二重署名はコンセンサスの安全性を脅かす可能性があるため、通常は重大な障害として扱われます。

ダウンタイムまたは参加漏れは、チェーンのパラメーターに応じて、より小さいペナルティまたはジェイリングを伴うライブネス障害として扱われることがよくあります。

Cosmos SDKチェーンはスラッシングパラメーターをカスタマイズできるため、Cosmos SDKを使用するすべてのチェーンのペナルティ率が同一であると想定すべきではありません。

バリデーターは、安全な鍵管理、セントリーアーキテクチャ、監視、安全な移行手順を使用すべきです。

委任者は、委任前にバリデーターの信頼性とスラッシング履歴を確認する必要があります。

Cosmos形式のスラッシングは、プロトコルレベルの強制がバリデーター運用を委任者の結果に直接結び付け得ることを示しています。

このため、委任型ステーキングではバリデーターのデューデリジェンスが特に重要です。

Polkadot形式のスラッシング

Polkadot形式のNominated Proof of Stakeでは、バリデーターとノミネーターがネットワークを保護します。

Polkadotの違反に関するドキュメントでは、バリデーターが不正行為をした場合、そのバリデーターとノミネーターがスラッシュされ得ると説明されています。

また、スラッシング率は重大度に応じて変化し、ごく少額から非常に厳しいペナルティまで及び得ると説明されています。

このモデルでは、ノミネーターは支持するアクティブバリデーターとリスクを共有します。

これは、ノミネーターが永続的に1つを受動的に選ぶのではなく、バリデーターを監視することを促します。

ネットワークルールに応じて、エクイボケーションやより深刻な紛争などの違反でスラッシングが発生する可能性があります。

Polkadotのドキュメントでは、一部のスラッシュに適用前の猶予期間があり、一定の状況ではガバナンスによる取り消しの可能性があることも記載されています。

これは、スラッシングに自動的なプロトコル証拠とガバナンスに関連する審査プロセスの両方が含まれ得ることを示します。

ノミネーターは、アクティブな指名、バリデーター選択、分散化、手数料、運用履歴を理解する必要があります。

ステーキング報酬は判断の一面にすぎず、スラッシングリスクがもう一面です。

スラッシングとペナルティの違い

スラッシングは重大なペナルティですが、すべてのステーキングペナルティがスラッシングであるわけではありません。

一部のネットワークでは、バリデーターはスラッシュされなくても、オフラインであることで報酬を失う可能性があります。

ネットワークにより、バリデーターはジェイル、無効化、チルド、またはアクティブセットから除外される場合があります。

スラッシングは通常、ステークの一部が取り上げられ、バーンされ、没収され、または転用されることを意味します。

通常のペナルティは、単に報酬を減らす、または少額の残高控除を適用するだけの場合があります。

ユーザーはすべてのバリデーター損失を同じ分類として扱うべきではありません。

ダウンタイムペナルティは二重署名によるスラッシングより小さく、回復しやすい可能性があるため、この違いは重要です。

一部のペナルティは報酬に影響する一方、他のペナルティは元本ステークを減少させる可能性があるため、この違いは委任者にとっても重要です。

ステーキングページとバリデーターダッシュボードでは、リスクが報酬逸失、非アクティビティペナルティ、ジェイリング、スラッシングのどれに当たるのかを説明すべきです。

明確な表現は、ユーザーがステーキングリスクを誤解することを防ぐのに役立ちます。

スラッシングとジェイリングの違い

ジェイリングとは、ネットワークルールに基づいてアンジェイルまたは復帰されるまで、バリデーターが一時的にアクティブな検証から除外またはブロックされることです。

スラッシングとは、処罰としてステークが減額されることです。

一部のネットワークでは、同じインシデントでバリデーターがジェイルされ、スラッシュされる場合があります。

チェーンに応じて、バリデーターはダウンタイムにより少額のペナルティまたは大きなステーク損失なしでジェイルされる場合もあります。

ジェイリングは、信頼性の低いバリデーターをアクティブなコンセンサスから除外することでネットワークを保護します。

スラッシングは、有害な行為に経済的コストを課すことでネットワークを保護します。

委任者にとって、ジェイリングはバリデーターが非アクティブな間の報酬逸失を意味する可能性があります。

バリデーターにとって、ジェイリングは評判を損ない、委任者の流出につながる可能性があります。

ユーザーは委任前に、バリデーターがアクティブ、ジェイル、トゥームストーン、退出中のどれであるかを確認する必要があります。

ジェイリングとスラッシングは関連する強制手段ですが、同一ではありません。

スラッシングとInactivity Leakの違い

Inactivity Leakは、ネットワークがファイナリティを失った際に参加できないバリデーターを段階的に処罰する仕組みです。

Ethereumは、十分なバリデーターがオフラインである、またはアテステーションを適切に行わない場合に、チェーンがファイナリティを回復するため、非アクティビティペナルティを使用します。

これは、矛盾する提案や矛盾するアテステーションなどの特定のスラッシング可能な行為を必要とするスラッシングとは異なります。

公式のEthereumの報酬とペナルティに関するドキュメントでは、通常の報酬、ペナルティ、スラッシングを、より広範なProof of Stakeインセンティブシステムから区別しています。

オフラインのバリデーターは、スラッシュされずにペナルティを受けることがあります。

矛盾するメッセージに署名したバリデーターは、他の点ではオンラインであってもスラッシュされる可能性があります。

軽減策が異なるため、この区別は運用者にとって重要です。

非アクティビティリスクは、稼働率、監視、クライアントの健全性、ネットワークのレジリエンスによって抑えられます。

スラッシングリスクは、署名規律、鍵の隔離、スラッシング保護、安全なフェイルオーバーによって抑えられます。

ユーザーは、ステーキング商品が非アクティビティ損失について説明しているのか、真のスラッシング損失について説明しているのかを理解する必要があります。

スラッシングとステーキング報酬

スラッシュされたバリデーターはステーク、評判、多くの場合アクティブバリデーターの地位を失うため、スラッシングはステーキング報酬に影響します。

スラッシュされたバリデーターは、除外、ジェイリング、非アクティブ期間中に報酬を得られなくなる可能性があります。

委任されたステークがスラッシング可能なネットワークでは、委任者が元本の一部を失う可能性があります。

スラッシングイベントが小規模でも、委任者が離脱したりバリデーターがアクティブセットから除外されたりすれば、将来の報酬損失につながる場合があります。

高いステーキング報酬は、スラッシングリスクとあわせて評価すべきです。

高い報酬を表示するバリデーターでも、運用が弱い、または行動がリスクの高い場合には適切な選択でない可能性があります。

小さな手数料差よりも、信頼性の高いバリデーターのパフォーマンスが重要になる場合があります。

ユーザーは、見出し上の利回りだけでなく、ネットのステーキング結果を比較する必要があります。

スラッシングは、ステーキング報酬がリスクフリーの利息と同じではない理由の1つです。

ステーキング報酬は、プロトコル、バリデーター、市場、流動性リスクを受け入れながらネットワーク保護に貢献することに対する対価です。

スラッシングとバリデーター鍵

バリデーター鍵は、スラッシングリスクにおいて最も重要な領域の1つです。

バリデーター署名鍵は、ブロック提案、投票、アテステーションなどのコンセンサスメッセージへの署名に使用されます。

同じ署名鍵が2か所でアクティブになると、バリデーターが誤って矛盾するメッセージに署名する可能性があります。

署名鍵が盗まれた場合、攻撃者がスラッシング可能なメッセージを作成したり、バリデーター運用を妨害したりできる可能性があります。

運用者は、このリスクを抑えるため、リモート署名者、鍵管理システム、ハードウェアセキュリティモジュール、スラッシング保護データベース、厳格な移行手順書を利用することがよくあります。

Lighthouseのスラッシング保護ドキュメントでは、スラッシング保護データベースが署名済みブロックとアテステーションを記録し、スラッシング可能なメッセージへの署名を避けると説明されています。

署名履歴なしに古いバリデーター状態を復元するとリスクが生じ得るため、鍵のバックアップは慎重に扱う必要があります。

フェイルオーバーは、同時に1つの署名者だけがバリデーター鍵に署名できるよう設計すべきです。

バリデーター鍵の管理は、単なる運用上の詳細ではありません。

これはスラッシングに対する主要な防御策の1つです。

スラッシングとフェイルオーバー

フェイルオーバーとは、問題発生時にバリデーター運用を1つのサーバー、リージョン、クライアント、またはマシンから別のものへ切り替えることです。

フェイルオーバーは稼働率を高めますが、安全でないフェイルオーバーはスラッシングリスクを高める可能性があります。

危険なパターンは、2つのシステムが同時に同じバリデーター鍵で署名できるアクティブ・アクティブ署名です。

より安全なパターンは、プライマリシステムが安全に停止し、署名状態が同期されるまでバックアップシステムが署名できないアクティブ・パッシブフェイルオーバーです。

バリデーター運用者は、代替署名者を起動する前に古いノードが停止していることを確認すべきです。

また、バリデーター移行時にはスラッシング保護データを保持する必要があります。

迅速な復旧は有用ですが、急ぎすぎた復旧は危険になり得ます。

多くのスラッシングインシデントは、意図的な攻撃ではなく運用ミスによって発生します。

優れたバリデーターは、無謀に稼働率を追求するよりも安全な復旧を重視します。

フェイルオーバーでは、ライブネスと署名の完全性の両方を保護すべきです。

スラッシングとリキッドステーキング

リキッドステーキングでは、ユーザーはステーキング資産またはステーキング資産への請求権を表すトークンや受領証を受け取ります。

リキッドステーキングでは、原資産がステーキングされたままでも受領トークンをDeFiで利用できる場合があるため、ステーキングの柔軟性が高まる可能性があります。

ただし、リキッドステーキングシステムの背後にあるバリデーターを通じて、スラッシングへのエクスポージャーが追加される可能性があります。

基礎となるバリデーターがスラッシュされた場合、設計に応じて、リキッドステーキングトークンの価値、交換レート、裏付け、償還価値に影響する可能性があります。

リキッドステーキングには、スマートコントラクトリスク、オラクルリスク、流動性リスク、ガバナンスリスク、デペッグリスクも追加されます。

ユーザーは、スラッシング損失が全参加者に社会化されるのか、特定のバリデーター配分に割り当てられるのかを理解する必要があります。

バリデーターの分散化、運用者選定、保険メカニズム、出金ルールも確認する必要があります。

リキッドステーキングトークンはProof of Stakeリスクをなくすものではありません。

リスクがパッケージ化され、移転される方法を変えるものです。

基礎となるステーキングシステムにスラッシング可能なバリデーターが存在する限り、スラッシングリスクは残ります。

スラッシングとリステーキング

リステーキングでは、ステーキング資産またはバリデーターのコミットメントが、基本となるProof of Stakeネットワークを超えた追加サービスにさらされる可能性があります。

これにより追加の報酬機会が生じる可能性がありますが、追加のスラッシング条件が導入される可能性もあります。

公式のEigenLayerのスラッシングドキュメントでは、リステーキングされたセキュリティを利用するサービスのルールに違反した運用者を処罰できる仕組みとしてスラッシングが説明されています。

バリデーターまたは運用者が複数のルールセットを同時に満たす必要があるため、リステーキングリスクは通常のステーキングより複雑になる可能性があります。

1つの追加サービスでの障害が、ユーザーがすでに別の場所でステーキングされていると考えていた資産に影響する可能性があります。

ユーザーは、リステーキング資産がどのサービスを保護しているのか、どの条件でペナルティが発生するのかを理解する必要があります。

運用者は、リステーキングの責任を受け入れる前に、すべての署名、可用性、サービスレベルの義務を理解する必要があります。

リステーキングは資本効率を高める可能性がありますが、相関スラッシングリスクも高める可能性があります。

報酬源が増えるほど、運用上およびプロトコル上の前提も増えることがよくあります。

ユーザーは、リステーキングのスラッシングリスクを、ベースチェーンのステーキングリスクとは別のデューデリジェンス項目として扱う必要があります。

スラッシングと市場リスク

スラッシングは市場リスクとは異なりますが、どちらもステーキング結果に影響します。

スラッシングは、トークン数またはステーキングポジションを裏付ける価値を減少させます。

市場リスクは、トークン自体の法定通貨建てまたは市場価値を変化させます。

ユーザーはスラッシングを回避しても、トークン価格が下落すれば価値を失う可能性があります。

ステーキング報酬を得ても、市場価格の下落が報酬を上回れば、合計リターンがマイナスになる可能性があります。

したがって、ステーキングリスクは複数の層で評価する必要があります。

その層には、バリデーターリスク、プロトコルリスク、流動性リスク、スマートコントラクトリスク、カストディリスク、税務リスク、市場価格リスクが含まれます。

スラッシングは主要な層の1つですが、唯一のリスクではありません。

スラッシングの確率が低いからといって、ステーキングがリスクフリーになると考えるべきではありません。

暗号資産ステーキングには常に運用上および市場上の不確実性が伴います。

スラッシングとアンボンディング

アンボンディングとは、ユーザーがステーキングを停止してから資産が再び完全に移転可能になるまでの待機期間です。

一部のネットワークでは、バリデーターが関連するリスク期間の前または期間中にスラッシング可能な違反を行った場合、アンボンディング期間中のステークにもスラッシングを適用できます。

これにより、バリデーターが不正行為後にすぐアンボンドすることで処罰を免れることを防ぎます。

アンボンディング期間はネットワークによって異なります。

アンボンディング中、ユーザーは報酬の獲得を停止し、資産をすぐに移動できない場合があります。

ユーザーは、選択したチェーンでアンボンディング中にもスラッシングリスクが継続するかを理解する必要があります。

また、再委任によって旧バリデーター、新バリデーター、またはその両方への一時的なエクスポージャーが生じるかも理解する必要があります。

アンボンディングは流動性リスクであり、場合によってはスラッシングリスクが継続する期間でもあります。

ステーキングからの退出は常に即時ではありません。

安全なステーキングには、参加ルールと退出ルールの両方への理解が必要です。

バリデーターがスラッシングリスクを抑える方法

バリデーターは、各バリデーター鍵についてアクティブな署名者を1つだけ維持することでスラッシングリスクを抑えます。

スラッシング保護データベースを使用し、移行時に署名履歴を保持します。

安全でないアクティブ・アクティブのフェイルオーバー設計を避けます。

バリデーターのパフォーマンス、業務漏れ、ピア接続、ディスクの健全性、クライアントの健全性、チェーンアップグレードを監視します。

必要に応じて、リモート署名者、安全な鍵保管、ハードウェアセキュリティモジュール、または厳格なアクセス制御で署名鍵を保護します。

本番環境でのアップグレード前に、アップグレード手順をテストします。

移行、復旧、インシデント対応、緊急停止の明確な手順書を使用します。

1つのミスですべてのバリデーター鍵が危険にさらされないよう、インフラの役割を分離します。

インシデントとリスク管理について、委任者と透明にコミュニケーションを取ります。

優れたバリデーター運用は、偶発的なスラッシングに対する最も強力な実務上の防御です。

委任者がスラッシングリスクを抑える方法

委任者は、バリデーターを慎重に選ぶことでスラッシングリスクを抑えます。

バリデーターの稼働率、スラッシング履歴、公開コミュニケーション、インフラの成熟度、手数料、ガバナンス参加、自己ステーク、コミュニティでの評判を確認する必要があります。

最高の推定報酬だけを理由にバリデーターを選ぶことは避けるべきです。

ネットワークが複数バリデーターへの委任を認める場合は、分散化を検討すべきです。

委任後もポジションを放置せず、バリデーターの状態を監視する必要があります。

ステーキング前に、チェーンの正確なスラッシングルールを理解する必要があります。

一般的なステーキング概要に頼らず、公式ステーキングドキュメントを読む必要があります。

アンボンディング期間と再委任ルールを理解する必要があります。

リキッドステーキングまたはリステーキング商品を使用する場合、それらの追加リスクを考慮する必要があります。

委任者のリスク管理は委任前に始まり、資産が完全に出金されるまで続きます。

ステーキング前にスラッシングリスクを確認する方法

まず、ネットワークの公式ステーキングドキュメントを読んでください。

スラッシングが自動、手動、ガバナンス審査付き、または通常のバリデーター障害に対して現在有効でないかを確認してください。

どの行為がスラッシング可能かを確認してください。

委任者がバリデーターのスラッシング損失を共有するかを確認してください。

ダウンタイムがスラッシュ、ジェイル、または報酬逸失だけで処罰されるのかを確認してください。

アンボンディング期間と、その期間中にスラッシングが適用される可能性を確認してください。

エクスプローラー、ステーキングダッシュボード、公式エコシステムツールを通じてバリデーター履歴を確認してください。

バリデーターに明確なインフラおよびインシデント対応の実務があるかを確認してください。

ネイティブ、リキッド、カストディ型、リステーキング型のどれであるかを確認してください。各モデルでリスクプロファイルが変化します。

適切なステーキング判断では、報酬とスラッシング、流動性、カストディ、市場、スマートコントラクトリスクを比較検討します。

よくあるスラッシングの誤解とミス

よくあるミスの1つは、すべてのProof of Stakeネットワークが同じ方法でスラッシュすると考えることです。

2つ目は、ダウンタイムペナルティとスラッシングを混同することです。

3つ目は、表示報酬だけでバリデーターを選ぶことです。

4つ目は、委任者がバリデーターのスラッシング損失を共有するかを無視することです。

5つ目は、リキッドステーキングがスラッシングリスクをなくすと考えることです。

6つ目は、同じバリデーター鍵を2台のマシンで同時に運用することです。

7つ目は、スラッシング保護データを保持せずにバリデーターインフラを移行することです。

8つ目は、アンボンディング期間のリスクを無視することです。

9つ目は、過去のバリデーター評判が将来の安全性を保証すると考えることです。

10個目は、ステーキング報酬をリスクフリーの収入として扱うことです。

スラッシングのメリット

1つ目のメリットは、Proof of Stakeのセキュリティが強化されることです。

2つ目は、証明可能な有害行為によりバリデーターがステークを失う可能性があるため、説明責任が高まることです。

3つ目は、矛盾する確定済み履歴に経済的な高コストが生じるため、ファイナリティが強化されることです。

4つ目は、安全でない署名と不適切な運用に結果が伴うため、バリデーターの規律が改善されることです。

5つ目は、ユーザーが信頼できるバリデーターを選ぶよう促されるため、委任者のインセンティブが改善されることです。

6つ目は、nothing-at-stake問題への対策となることです。

7つ目は、コンセンサスメッセージが経済的リスクに裏付けられるため、ネットワークへの信頼が強化されることです。

8つ目は、委任者が報酬だけでなくバリデーターを評価する場合、長期的な分散化が改善することです。

9つ目は、署名済みメッセージにより違反を証明できるため、証拠に基づく明確な強制が可能になることです。

10個目は、スラッシングによりProof of Stakeのセキュリティが社会的な約束以上のものとなることです。

スラッシングのリスクと限界

1つ目のリスクは、設定不備のバリデーターインフラによる偶発的なスラッシングです。

2つ目は、委任者がバリデーターのペナルティを共有する場合の委任ステーク損失です。

3つ目は、多くのバリデーターが類似のインフラまたは同じ運用者設定を使う場合の相関スラッシングです。

4つ目は、ユーザーが最も安全と認識される運用者だけに委任する場合のバリデーターの中央集権化です。

5つ目は、多くのユーザーがチェーンごとに異なるスラッシングルールを理解していないという複雑性です。

6つ目は、ペナルティへのエクスポージャーを単純化または隠すステーキング商品による不明確な説明です。

7つ目は、リキッドステーキングまたはリステーキングの複雑性によりスラッシングへのエクスポージャーが追跡しにくくなることです。

8つ目は、審査プロセスがあるネットワークで、スラッシュを取り消すべきかを巡るガバナンスまたは社会的な紛争です。

9つ目は、二重署名を恐れるあまりバリデーターが有用な冗長化を避けるという運用上の過剰反応です。

10個目は、スラッシングが一部の攻撃を抑えても、すべてのステーキング、市場、スマートコントラクトリスクをなくすわけではないことによる誤った安心感です。

バリデーターのベストプラクティス

同じバリデーター署名鍵を2つのアクティブな場所で同時に使用しないでください。

スラッシング保護を利用し、移行時に署名履歴を保持してください。

重複署名を防ぐフェイルオーバーシステムを設計してください。

バリデーターの健全性、業務漏れ、コンセンサス参加、ソフトウェアバージョンを継続的に監視してください。

安全な鍵管理を使用し、署名インフラへのアクセスを制限してください。

本番変更前にアップグレードと移行をテストしてください。

明確なインシデント対応手順を維持してください。

停止またはリスク発生後は、委任者とオープンにコミュニケーションを取ってください。

運用する各ネットワークの正確なスラッシングルールを理解してください。

スラッシング防止を後回しにせず、中核的なセキュリティ機能として扱ってください。

委任者のベストプラクティス

資産を委任する前に公式ステーキングドキュメントを読んでください。

報酬だけでなく、信頼性、透明性、履歴、運用を基にバリデーターを選んでください。

ネットワークが対応しており、かつ自身のステーキング戦略に適する場合は、バリデーターへのエクスポージャーを分散してください。

委任後もバリデーターの状態を監視してください。

委任したステークがスラッシュされ得るかを理解してください。

アンボンディング、再委任、出金のタイミングを理解してください。

リキッドステーキングまたはリステーキング商品を利用する前に、追加リスクを確認してください。

会計および税務上の目的で、ステーキング入金、報酬、再委任、出金の記録を保管してください。

ステーキングを保証された収入として扱わないでください。

ステーキング報酬と、スラッシング、流動性、市場、カストディ、プロトコルリスクを比較検討してください。

よくある質問

暗号資産におけるスラッシングとは何ですか？

スラッシングとは、Proof of Stakeのバリデーターが重要なネットワークルールに違反したため、ステーキングした暗号資産の一部を失うことです。

ブロックチェーンはなぜスラッシングを使用するのですか？

ブロックチェーンは、バリデーターが矛盾するメッセージに署名すること、コンセンサスを攻撃すること、重要なプロトコル責任を果たさないことを抑止するためにスラッシングを使用します。

委任者もスラッシュされる可能性がありますか？

はい。委任先のバリデーターがスラッシング可能な違反を行った場合、一部のネットワークでは委任者もスラッシュされる可能性があります。

ダウンタイムはスラッシングと同じですか？

いいえ。ダウンタイムは報酬逸失、ペナルティ、ジェイリングの原因となる場合がありますが、真のスラッシングは通常、ステークの一部が削減または没収されることを意味します。

Ethereumのスラッシングの原因は何ですか？

Ethereumのスラッシングは、二重提案、二重投票、surround voteなど、特定のコンセンサス署名違反によって発生します。

Solanaはステーカーを自動的にスラッシュしますか？

公式のSolanaステーキングページでは、Solanaにおけるスラッシングは自動ではないと記載されています。

二重署名とは何ですか？

二重署名とは、1つの有効なメッセージだけに署名すべきコンテキストで、バリデーターが矛盾するコンセンサスメッセージに署名することです。

偶発的にスラッシングされることはありますか？

はい。重複したバリデーター鍵、安全でないフェイルオーバー、不適切な移行手順、不十分な署名鍵管理により、偶発的なスラッシングが発生する可能性があります。

ユーザーはどのようにスラッシングリスクを抑えられますか？

ユーザーは、信頼できるバリデーターの選択、適切な場合の分散化、バリデーター状態の監視、ネットワークの正確なステーキングルールの理解により、スラッシングリスクを抑えられます。

スラッシングがまれなら、ステーキングはリスクフリーですか？

いいえ。スラッシングがまれであっても、ステーキングにはバリデーターリスク、市場リスク、流動性リスク、カストディリスク、スマートコントラクトリスク、プロトコルリスクが含まれます。

結論

スラッシングは、重大なルール違反を行ったバリデーターのステークの一部を削減または没収することで処罰する、Proof of Stakeの強制メカニズムです。

ブロックチェーン履歴の決定に関与するバリデーターが実際の資本をリスクにさらすことが、Proof of Stakeのセキュリティに不可欠であるため重要です。

ネットワークに応じて、スラッシングは二重署名、矛盾するアテステーション、エクイボケーション、重大なコンセンサス障害、ライブネス障害などを処罰する場合があります。

正確なスラッシングモデルはチェーンごとに異なるため、ユーザーは資産を委任する前に必ず公式ステーキングドキュメントを確認する必要があります。

Ethereumでは特定のコンセンサス署名違反にスラッシングが使用される一方、通常のダウンタイムは一般にスラッシングではなくペナルティとして扱われます。

Solanaの公式ステーキングページではスラッシングは自動ではないとされており、チェーン固有の文脈が重要であることを示しています。

Cosmos SDKおよびPolkadot形式のネットワークは、異なるステーキング設計を通じ、スラッシングがバリデーターと委任者に影響し得ることを示しています。

バリデーターにとって、スラッシング防止は安全な鍵管理、スラッシング保護、安全なフェイルオーバー、監視、規律ある運用に依存します。

委任者にとって、スラッシングリスクの管理は、バリデーター選定、分散化、監視、アンボンディングおよびステーキング商品のルールの理解に依存します。

暗号資産用語集の文脈で、Slashingは、バリデーターの不正行為またはプロトコルで定められたステーキング違反によってステーキングトークンを失うことを意味します。

重要なポイントは、スラッシングがProof of Stakeのセキュリティを強化する一方、ステーキングを、慎重なバリデーター運用と十分な情報に基づく委任判断を必要とするリスクを伴う活動にするということです。