Solanaへのスラッシング導入

はじめに

スラッシングは、悪意または過失のあるバリデータの行動にペナルティを科し、ネットワークのセキュリティを確保する仕組みです。不正行為が確認されると、違反したバリデータに委任されたステークの一部がバーンされます。

これはSolanaのようなProof of Stake（PoS）ネットワーク特有の機能であり、Proof of Work（PoW）には相当するものがありません。ステーキングされた資産を破棄し、プロトコルが金銭的ペナルティを直接執行できることが前提だからです。PoWでは、ブロックチェーンが不正な参加者の物理的なマイニング機器を没収または破壊できないため、同様の仕組みはありません。

スラッシングには、主に次の利点があります。

• 悪意ある行為に対する直接的な経済的抑止力になります
• ステーカーが信頼できるバリデータへステークを分散する動機となり、分散化が進みます
• 大規模な事業者が、共通障害のリスクを抑える異種混在インフラを構築する動機になります（例：FiredancerとAgaveのクライアントにステークを分割する）。
• スラッシング違反を回避し、他の参加者による悪意ある行為を検知することで、バリデータが差別化し、評判を高めるための新たな指標になります。

Solanaはこれまで、ソーシャルスラッシングと呼ばれる、コミュニティ主導の手動コンセンサス方式に依存してきました。このモデルでは、バリデータがネットワークの可用性や安全性を損なうなどの悪意ある行動を取った場合、誠実な参加者がオフチェーンで連携してハードフォークを開始し、ネットワークを再起動して違反者のステークをスラッシングできます。この方法はケースごとの柔軟な判断を可能にする一方、多大な調整コストを伴い、本質的に事後対応です。

現在まで、Solanaでスラッシングされたバリデータはありません。スラッシングに最も近い出来事は、メインネット公開から2か月後の2020年5月に発生しました。マーケットメーカーへの未開示のトークン貸付に対するコミュニティの懸念を受け、Solana Foundationが自らの割当分から1,136万SOLを自主的にバーンしました。これにより、トークンの総供給量は5億SOLから4億8,864万SOLへと2.3%減少しました。正式なスラッシングではありませんが、このバーンは信頼を回復し、初期コミュニティが提起した透明性の問題に対処するため、自らに科したペナルティとして機能しました。

数年前からSolanaには、プログラムによるスラッシングと呼ばれる、より正式な仕組みを導入すべきだという声があります。これは組み込みプログラムを通じてオンチェーンで直接執行されます。この仕組みでは、バリデータが特定のプロトコルルールに違反すると、その暗号学的証明を生成して専用プログラムへ提出でき、スラッシングが自動的に実行されます。人による調整への依存を減らし、ネットワーク運用を妨げずに軽微な違反も取り締まれるため、拡張性のある分散型の責任追及が可能になります。

近日予定されているSIMD-0204: スラッシング可能イベントの検証のフィーチャーゲート有効化は、Solanaがメインネットに正式なプログラム型スラッシングを実装するための、初めての大きく重要な一歩です。本稿で後述するように、ブロックチェーンネットワークでプログラムによるスラッシングが発生することは幸いにもまれで、通常ペナルティも軽微です。しかし、バリデータのステークがプロトコルによって自動的に破棄される可能性があるだけでも、すべてのステークホルダーが慎重に検討すべき新たなリスクが生じます。Solanaがプログラム型スラッシングを執行する最適な方法には、多くの未解決問題があります。あらゆる経済的変更と同様に、スラッシングのパラメータとペナルティにはコミュニティでの幅広い議論が必要であり、最終的には正式なガバナンス投票で承認されなければなりません。

スラッシング関連のSIMD

複数のSIMDがSolanaでのプログラム型スラッシングの導入に関係しており、最初の2つであるSIMD-180とSIMD-204は、今後数か月以内にメインネットで稼働する予定です。

まず前提となるのが、SIMD-0180: リーダースケジュールのキーに投票アカウントアドレスを使用です。このSIMDでは、リーダースケジュールに使用するキーを、バリデータのアイデンティティアドレスから投票アカウントアドレスへ変更します。バリデータのブロック生成責務と委任されたステークの間に直接的で明確な関連付けが作られるため、スラッシング対象を正確に特定するうえで不可欠です。

SIMD-0204: スラッシング可能イベントの検証では、新しいSlashing Programの概要が示されています。誰でもスラッシング対象行為の証拠を提出して記録できるオンチェーンの仕組みを導入し、バリデータの不正行為について検証可能で改ざん不能な記録を作成します。

最後に、SIMD-0212: スラッシングでは、Solanaプロトコル内でのスラッシング実装が示されています。SIMD-0204が築いた基盤を利用し、検証済みの違反にペナルティを適用します。この提案はまだ未確定で、活発な議論が続いています。

障害の検知と帰属

Slashing Programは、純粋な観測レイヤーとして設計されています。ステークや報酬は変更せず、違反の検証と記録のみを行います。初期プロトタイプはすでにTestnetで稼働しており、提出例（DuplicateBlockProofトランザクションなど）から、違反がどのように記録されるかを確認できます。

重複ブロック生成

初期導入時には、プログラムは1種類の悪意ある行為、すなわち重複ブロック生成の検知に注力します。これは、リーダーが同じスロットに対して異なるバージョンのブロックを2つ以上提出する行為であり、明白かつ客観的なコンセンサス違反です。 

以前、2022年9月には、あるバリデータが同じブロック高で誤って重複ブロックを生成し、ネットワーク障害が発生しました。バリデータのプライマリノードと予備のフォールバックノードが同時に稼働し、同一のノードIDを使用しながら異なるブロックを提案したことが原因です。

この問題はその後修正されました。現在のバリデータクライアントには、事業者がホットスペアを運用している場合でも、複数のインスタンスが検出されると停止する安全策があります。そのため、バリデータソフトウェアを意図的かつ悪意をもって改変しない限り、重複ブロックが生成される可能性は極めて低いです。

重複ブロック生成は、リアルタイムでの検知は難しいものの、事後の検証は容易なプロトコル違反の一例です。ネットワークを停止し、重複を全体で確認する同期的な対応を取ろうとすると、非常に複雑になります。代わりに、検知とスラッシングを遡及的に処理する方がはるかに現実的です。

提出される重複ブロックの証明には、同じスロットに対する競合する2つのshredが含まれ、いずれも同一のバリデータによって署名されています。Slashing Programは、shredが有効な重複ブロック証明を形成していること、同じスロットに属すること、違反したバリデータによって正しく署名されていることを確認して証明を検証します。このロジックは、Solanaのgossipプロトコルがフォーク選択プロセスで重複ブロック証明を処理する方式と同様です。

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

報告者は証明を作成してオンチェーンのバッファアカウントに保存し、そのバッファアカウントを参照するトランザクションをアドレス`S1ashing11111111111111111111111111111111111`のSlashing Programへ提出します。証明が正常に検証されると、結果は将来参照できるよう、Slashing Programが所有する`report_account` Program Derived Address（PDA）に保存されます。Slashing ProgramでgetProgramAccountsを呼び出すだけで、スラッシング関連データを表示するダッシュボードを簡単に構築できます。バリデータはこれを利用して、違反が報告されていないか確認し、必要に応じて是正措置を講じられます。

Anzaは、これらのイベントの観測、証明の作成、オンチェーンへの証明提出を可能にするツールを公開すると見込まれています。バリデータソフトウェアに組み込まれるバージョンを含め、複数の実装が登場する可能性があります。違反者とスロットの一意な組み合わせは1回しか報告できないため、1エポック以内に1人の誠実な参加者が違反を報告すれば十分です。プログラムは、同じスロットと違反者に対する報告がすでに存在するか検証します。一致する報告が見つかると、新しい提出は拒否されます。報告は違反が発生したスロットを基準として、発生から最大1エポック後まで提出できます（つまり、`Clock` sysvarで追跡される最大432,000スロット後まで）。

内部告発者への報酬

スラッシング設計でよく問われるのが、違反を報告した人（内部告発者）に報酬を与えるべきかどうかです。報酬は単純なインセンティブの仕組みに見えますが、無視できない課題があります。

リーダーがトランザクションの取り込みを制御するSolanaでは、内部告発者への報酬によってフロントランニングのリスクが生じます。バリデータが有効なスラッシング証明を現在のブロックリーダーに提出したとします。この場合、リーダーは証明をコピーして自ら提出し、元のトランザクションを検閲するだけで、作業せずに報酬を獲得できます。これはインセンティブモデルを損ない、悪用を招きます。

Ethereumでは少額の内部告発者報酬が用意されています。スラッシングされたバリデータの有効残高の1/512です。最大の32 ETHを持つバリデータの場合、0.0625 ETHに相当します。報酬は新しいETHとして発行されますが、スラッシングされたバリデータのステークから、より多くの額がバーンされることで相殺されます。報酬額が低いのは意図的であり、利益目的の投機的行動ではなく、誠実さと正直な参加を促すためです。

投票違反

Slashing Programの将来のバージョンでは、ロックアウト違反や切り替え証明違反など、さまざまな投票違反への対応が拡大される見込みです。

ロックアウト違反は、バリデータがtowerのロックアウトが失効するまで適切な時間待たず、2つの異なるフォークに投票すると発生します。Solanaの現行コンセンサスアルゴリズムであるTowerBFTでは、バリデータがあるスロットで特定のフォークに投票すると、一定期間、競合するフォークへの投票が「ロックアウト」されます。ロックアウト期間の終了前に別のフォークへ投票すると、ロックアウトルールへの違反となります。

Solana共同創業者のMichael Vines氏が開発したVotalizer botは、現在Solana Tech Discordで稼働し、ネットワーク上で発生するロックアウト違反を追跡しています。実際には、バリデータが意図せずこの違反を犯すことはまれです。通常はバリデータクライアントを意図的に改変しなければ発生しないためです。組み込みの安全策により、クライアントは最新のオンチェーン投票を取得し、ロックアウト違反につながる操作を防止します。

ロックアウト違反は、Slashing SIMDと初期ドキュメントでSlashing Programが対処し得る投票違反の例として明記されています。しかし、予定されているAlpenglowコンセンサスアップデートではTower BFTが廃止され、ロックアウトの概念もなくなります。このため、投票違反はAlpenglowの公開後に導入される見込みです。

Slashing Programが検知するよう設計される可能性のある、新しいAlpenglowの投票違反には、同じスロットに対して競合する投票を提出する行為が含まれます。たとえば、`NotarVote`と`SkipVote`の両方を投じる場合です。

将来の違反類型

プログラム型スラッシングは、検証可能で明確な不正行為に結び付いていなければなりません。残念ながら、この要件により、意図的に遅いブロック生成や有害なMEV抽出など、より主観的または構造的な問題の取り締まりは大幅に難しくなります。

類似するブロックチェーンネットワークでは、スラッシング対象となる行動はプロトコルによって異なります。一般的な例は次のとおりです。

• 二重署名：同じブロック高またはスロットで競合する2つのブロックを生成する行為。
• ダウンタイム：オフラインになり、コンセンサスに参加しない状態。
• サラウンド投票：ネットワークの操作や不安定化を目的として、以前の投票と競合する投票を行う行為。

昨年、Heliusの0xIchigo氏が提示した新しいスラッシング提案では、正式なガバナンス投票に参加しないスーパーマジョリティ内のバリデータにペナルティを科し、参加を促すことが提案されました。この方法は客観的に検証可能という要件を満たしますが、複数のコメントで懸念が示されました。法的制約により、一部のバリデータは投票できない可能性があるという指摘もあります。また、スラッシングはネットワークのセキュリティまたは完全性を直接脅かす行為に厳しく限定すべきだという意見もありました。

ペナルティの執行

Solanaにスラッシング対象の違反を報告・検証する信頼性の高いオンチェーンの仕組みが整えば、次の優先事項はスラッシングを経済的に執行し、違反の種類ごとに正確なパラメータとペナルティ計算式を定めることです。

ガイドラインは現在も活発に議論されており、本セクションの内容は、情報提供と対話の促進を目的とし、コミュニティの意見に基づいて発展していく現行案を反映しています。これらの決定はSolanaバリデータ運営の経済性に直接影響するため、すべての変更はコミュニティで公開討議され、正式なガバナンスプロセスで承認される必要があります。

スラッシングのペナルティを決める際の重要な原則は、まれな一度限りの運用ミスを過度に厳しく罰しないことです。誠実なミスに厳罰を科すのではなく、適切な安全策のもと、コンセンサスに影響しない軽微な事案を許容する余地を設けることが理想です。

現在、この許容範囲にはナカモト係数（NC）ラインの採用が検討されています。これはスーパーマイノリティ内で最小のバリデータが持つステーク量（ステーク全体の約1%）に設定されます。 

投票アカウントごとに各委任からスラッシングする額を決める提案中の関数では、違反したステークの合計がNCライン未満なら、ステークはスラッシングされません。反対に、ステーク総量の3分の1超が違反に関与してコンセンサスが危険にさらされている場合、プロトコルは違反ステークの100%をスラッシングして断固とした対応を取るべきです。

この両極端の間に該当する場合、現行案では増加率の緩やかな二次関数型ペナルティを導入します。各投票アカウントからスラッシングするステークの割合は、次の式で計算します。

v = スラッシング可能な投票アカウント

TSS = スラッシング可能なステークの合計

TS = ステークの合計

NC line = ナカモト係数ライン

この式では、違反したバリデータからスラッシングされるステークの割合を次のように計算できます。

• ステークの4.66%が違反した場合は1.2%（すなわち、(3 * (0.0466 - 0.01) / 1)²）
• ステークの10%が違反した場合は7.3%（すなわち、(3 * (0.1 - 0.01) / 1)²）

以下のグラフは、提案されている曲線と2つの代替案（積極型と線形型）を示しています。

スラッシング可能なステークの合計（TSS）は、違反の種類に応じた重みを使用して計算されます。投票違反は重大性が低いため、重みは1です。重複ブロック違反はより重大と見なされ、重みは10です。

現在提案されているような、相関性を考慮した二次関数型スラッシングペナルティの主な利点は、取引所やstaking-as-a-serviceプロバイダーなど、複数のバリデータを運営する事業者に対し、高品質で独立したインフラを維持し、広範囲に及ぶ相関障害のリスクを最小化する動機を与えることです。

従来型スラッシングの代替案

委任されたステークのスラッシングには、公平性と責任に関する重要な問題があります。現在のステーキングモデルでは、非公開型でないほとんどのバリデータで、ステークの大半またはすべてが委任されたものです。つまり、スラッシングが発生すると、多くの場合、違反したバリデータ運営者ではなく、委任者がペナルティの大部分を負担します。信頼できるバリデータを慎重に選んだステーカーでも、バリデータが悪意ある行為をしたり、ノードを誤設定したりすれば、自身に落ち度がなくてもスラッシングされる可能性があります。

この不均衡に対処するため、複数の代替設計が提案されています。その1つは、すべてのバリデータに最低限の自己ステークを義務付ける方法です。これにより、運営者も自らリスクを負い、スラッシングの全コストを委任者に転嫁できなくなります。より厳格な方式では、自己ステークのみをスラッシングし、対象バリデータに委任している全委任者のステークを自動的に解除します。委任者は報酬を失いますが元本は維持され、長期的な影響を最小限に抑えながら別のバリデータへステークを再配分できます。

別の方法は、一定期間アカウントを凍結し、その間は報酬の獲得、所有権の変更、資金の引き出しを禁止することです。凍結期間は違反の重大度に応じて延長されます。あるいは、元本のステークには触れず、一定期間にわたりバリデータと委任者の収益を減らすことで、将来の報酬をスラッシングする方法もあります。

バーンする代わりに、スラッシングされたステークを誠実なバリデータへ再分配し、積極的な強化策とする提案もあります。しかし、SOLをバーンすれば総供給量が減り、各保有者が占めるネットワーク所有権の相対的割合が増えるため、実質的には同様の結果になります。

検討事項

Solanaへのスラッシング導入には、いくつかの重要な影響があります。本セクションでは、クールダウン期間と、それによってエコシステム参加者に生じるリスク、保険、運用負担という2つの重要分野を検討します。

クールダウン期間

現在のステーキングモデルでは、バリデータがスラッシング対象の違反を犯した後、その違反が発見・報告される前にステークを解除すると、重大な脆弱性が生じます。引き出しを遅らせる仕組みがなければ、悪意ある参加者がこの時間差を悪用して処罰を逃れる可能性があります。

無効化後もステークをスラッシング対象として維持するクールダウン期間を設ければ、この問題を軽減できます。特にネットワーク規模のDDoS攻撃や悪意あるバリデータ間の共謀など、敵対的な状況を考慮し、クールダウン期間はバリデータや外部観測者がスラッシング対応を検知・調整するのに必要な最悪ケースの時間を超えなければなりません。実際には、複数日に及ぶ必要があります。

Solanaが事前計算されたステークのスナップショットに依存していることも、この問題を悪化させます。リーダースケジュールやフォーク選択ルールなど、複数の重要なプロトコル要素が事前に計算されたステーク値に依存しています。そのため、無効化済み、さらには全額引き出し済みのステークでも、コンセンサスに影響を及ぼす可能性があります。

たとえば、リーダースケジュールは、1エポック前のエポック境界で取得されたステークのスナップショットから算出されます。そのため、バリデータは前のエポックですでにステークを無効化し、現在のエポック開始時に引き出した後で、スラッシング対象の違反を犯せる時間帯が生まれます。違反が発覚した時点では、ペナルティを科す有効なステークはすでに残っていません。

解決策は、ステークがスラッシング対象には残るものの、プロトコルのステーク加重には算入されない追加のクールダウン期間を導入することです。エポックNでステークを無効化したステーカーは、エポックN+3の開始時に初めて引き出せます。セキュリティは向上しますが、ステークを完全に引き出すまでさらに~2〜4日待たなければならず、ユーザー体験が悪化します。対処法の1つは、エポックを短縮し、実時間でのステーク解除待機時間を現在の標準と同程度に保つことです。ただし、エポック期間の短縮はプロトコルに予期せぬ影響を及ぼす可能性があり、慎重な評価が必要です。

リスク、保険、運用負担

Solanaへのスラッシング導入は、ステーキングされたSOLを保管・管理する参加者や、その上に金融商品を構築する参加者など、幅広いエコシステム関係者に影響します。スラッシングの可能性だけでも、特に受託者責任や規制上の制約を受ける機関にとって、財務リスク、運用の複雑化、評判への懸念が生じます。こうしたリスクには、保険や保証金などの安全策で対処できます。

影響を受ける可能性があるステークホルダーは次のとおりです。

• リキッドステーキングプロトコル
• ステークプール
• カストディ型ステーキングプロバイダー
• リステーキングプロトコル
• DeFiプロトコル
• ステーキングETF

一部の組織では、スラッシングが連鎖的な影響を引き起こす可能性があります。たとえば、リキッドステーキングトークン（LST）は、基盤となるバリデータが安全に運用されるという前提に支えられています。バリデータがスラッシングされると、そのLSTの価格が急激に見直される可能性があります。極端な場合、基盤となるSOLをステーキングしているバリデータへの信頼が崩れ、ペッグが外れることもあります。LSTがレンディングプロトコルの担保として使われていれば、清算につながる可能性があります。

他のエコシステムでは、ステーキングプロバイダーがこうしたリスクを軽減するスラッシング保険を提供するのが一般的です。たとえばEthereumでは、多くのプロバイダーがスラッシング損失を補償する手頃な保険を提供しており、補償水準はプランによって異なります。

スラッシングリスクにより、ステーキングのバリューチェーン全体に新たな運用責任も生じます。影響を受けるのは次の関係者です。

• バリデータの行動を監視し、リスクを事前に軽減する必要があるステーキングサービス事業者
• 第三者事業者に依存し、バリデータ群の審査と分散が必要になる可能性があるカストディプラットフォームと暗号資産取引所
• 外部事業者に起因するスラッシング損失を補償する自己損失保険を求める可能性がある機関投資家向け資産運用会社

類似ネットワークとの比較

本セクションでは、EthereumやCosmosなど、類似するProof of Stakeネットワークでのスラッシング実装を検証します。これらのネットワークは長年にわたりプログラム型スラッシングを執行しており、発生頻度やネットワークセキュリティ、バリデータの行動への影響について、貴重な実データを提供しています。

Ethereum

2020年12月のBeacon Chain公開で導入されたEthereumのProof of Stakeプロトコルでは、初日からスラッシングが中核的な執行機構として組み込まれています。Ethereumでは4つのスラッシング対象違反が定義されており、すべて二重投票を中心としています。

• 同じスロットに対して複数のブロックを提案する
• 同じターゲットチェックポイントに対して競合するアテステーションを提出する
• 同じソースおよびターゲットチェックポイントで、異なるヘッドブロックを証明する
• ソース投票とターゲット投票の関係において、一方が他方を「囲む」2つのアテステーションを作成する

これらの違反には、すべて同じペナルティ構造が適用されます。バリデータがスラッシングされると、有効残高の1/32が即時にペナルティとして科されます。有効残高の上限が32 ETHのため、ペナルティは最大1 ETHです。その後、バリデータはアクティブセットから強制退出させられ、約36日間の退出キューに入ります。

この期間中、バリデータは非アクティブとなり、資金を引き出せません。アクティブであれば得られたはずの報酬を失い続けるため、継続的な機会費用が発生します。18日後には追加の相関ペナルティが適用されます。これは36日間にスラッシングされたバリデータ数に比例して増加するよう設計されています。対象が少数ならペナルティは軽微です。しかし、組織的な不正行為や共通インフラの障害による大規模スラッシングでは、ペナルティが急激に増加し、最悪の場合、バリデータのステーキング残高のほぼ全額を失う可能性があります。

Ethereumプロトコルで中核的な役割を持つにもかかわらず、実際のスラッシングは極めてまれです。2025年5月時点で、スラッシングされたバリデータは131件の事案を通じて484台のみで、全バリデータの0.05%未満でした。これらの事案は、1つのエラーが複数のバリデータに影響したケースが多く、通常は悪意ではなく、運用ミスやソフトウェアのバグが原因でした。

最大のスラッシングは2023年11月に発生しました。Bitcoin Suisseでは、非稼働に関連する違反により100台のバリデータがスラッシングされ、それぞれ1 ETHを失いました。

現在まで、Ethereumでプロトコル全体の完全性を脅かしたスラッシング事案はありません。これは、スラッシングが重要な抑止力である一方、実際に執行されることは少なく、バリデータエコシステムではペナルティを避けるために必要な行動が広く定着していることを示します。

Cosmos

CosmosとCosmos HubなどのCosmos SDKベースのチェーンは、二重署名と長時間のダウンタイムという2つの主要な障害を対象とする、組み込みのセキュリティ機構としてスラッシングを実装しています。これらのルールは、プロトコルの安全性と可用性の両方を確保します。

同じブロック高で異なる2つのブロックに署名したバリデータには、即時に処罰が科されます。どの参加者でも違反の証拠をオンチェーンで提出できます。検証されると、バリデータがステーキングしたトークンの5%が自動的にスラッシングされ、tombstoned状態になります。これはアクティブなバリデータセットから永久に除外され、再参加できないことを意味します。tombstoned状態になると、バリデータとその委任者は、ステークを再委任できるようになるまでアンボンディング期間の終了を待つ必要があります。運営者は新しいキーで再開できますが、評判と委任をゼロから再構築しなければなりません。

Cosmosは、長時間のダウンタイムに対する自動スラッシングでも可用性を確保します。バリデータが直近10,000ブロックの5%未満にしか署名していない場合、非アクティブと見なされ、ステークの0.01%がスラッシングされます。比較的軽微ですが、この執行は厳格で例外がなく、バリデータの稼働率とコンセンサスへの確実な参加を維持します。

興味深いことに、一部のバリデータは損失を無視できる程度と考え、運用を自主的に停止するコストとして、この軽微なペナルティを受け入れています。

Cosmos SDKネットワークには標準のデフォルトスラッシングパラメータがありますが、各チェーンは独自のセキュリティ前提とリスクモデルに合わせてルールを変更または拡張できます。この柔軟性により、各ネットワークはバリデータセットの規模、分散化の目標、想定する耐障害性に応じてスラッシングの仕組みを調整できます。Cosmos SDKベースの57のメインネットにおけるスラッシング状況から、エコシステム全体の執行状況を広く把握できます。

• ダウンタイム関連のスラッシング：12,143件
• 二重署名によるスラッシング：111件
• その他の違反：326件
• スラッシング総数：12,580件

これらの数値は、二重署名はまれで重いペナルティが科される一方、ダウンタイムによるスラッシングはより頻繁で、主に通常の運用コストと見なされていることを示します。 

まとめ

スラッシングは、ブロックチェーン業界で最も議論が多く、感情的な反応を招くテーマの1つです。バリデータによる新たな不正行為やインセンティブの不整合が生じるたび、すぐにスラッシングを求める声が上がります。その理由は容易に理解できます。表面的には、スラッシングは悪意ある参加者を罰し、ネットワークの完全性を維持するための直接的なオンチェーン機構を提供する強力な抑止力に見えるからです。

しかし、本稿で示したとおり、プログラム型スラッシングは不正行為を解決する万能薬ではありません。その有効性は、違反が明確かつ立証可能であることに依存しますが、複雑な現実の状況でこれらの条件を満たすのは必ずしも容易ではありません。証拠が不明確または解釈の余地がある状況でスラッシングを行うと、誠実な参加者を罰し、信頼を不安定にし、防ごうとする違反以上の害を及ぼすおそれがあります。

自動スラッシングがネットワークにもたらす最大の価値は、ステークホルダーへの心理的影響だとも考えられます。どれほどまれでも、何らかの違反によって経済的損失を被る可能性があるだけで、リスクを避けるステーカーが委任先を複数のバリデータへ分散し、運営者が多様で独立したインフラへ投資する動機になります。

関連資料

• スラッシング：万能薬か、パンドラの箱か？ - Tim Roughgarden、Accelerate Conference
• パーミッションレスコンセンサスの経済的限界 - Eric Budish、Andrew Lewis-Pye、Tim Roughgarden 
• 責任を追及できる可用性 - Andrew Lewis-Pye、Joachim Neu、Tim Roughgarden、Luca Zanolini