---
title: シークレット・リーダー・エレクション
description: シークレット・リーダー・エレクションがバリデータを攻撃から保護する仕組みについての説明
lang: ja
template: roadmap
summaryPoints:
  - ブロック・プロポーザーのIPアドレスは事前に知られる可能性があり、攻撃に対して脆弱になります。
  - シークレット・リーダー・エレクションは、バリデータの身元を隠し、事前に知られないようにします。
  - このアイデアの拡張として、各スロットでのバリデータ選択をランダムにする方法があります。
---

現在の[プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos)ベースのコンセンサス・メカニズムでは、今後のブロック・プロポーザーのリストは公開されており、そのIPアドレスをマッピングすることが可能です。これは、攻撃者がどのバリデータがブロックを提案する予定であるかを特定し、時間内にブロックを提案できなくなるようなDoS（サービス拒否）攻撃の標的にできることを意味します。

これにより、攻撃者が利益を得る機会が生まれる可能性があります。例えば、スロット`n+1`に選ばれたブロック・プロポーザーが、スロット`n`のプロポーザーにDoS攻撃を仕掛け、ブロックを提案する機会を逃させることができます。これにより、攻撃を行うブロック・プロポーザーは両方のスロットのMEVを抽出したり、本来2つのブロックに分割されるべきトランザクションをすべて1つのブロックに含めて、関連するすべての手数料を獲得したりすることが可能になります。これは、DoS攻撃から身を守るための高度な手法を使用できる洗練された機関バリデータよりも、ホームバリデータに大きな影響を与える可能性が高く、結果として中央集権化を促進する要因になり得ます。

この問題にはいくつかの解決策があります。1つは[分散型バリデータ技術 (DVT)](https://github.com/ethereum/distributed-validator-specs)であり、バリデータの実行に関連するさまざまなタスクを複数のマシンに冗長性を持たせて分散させることで、攻撃者が特定のスロットでブロックが提案されるのを防ぐことをはるかに困難にすることを目的としています。しかし、最も堅牢な解決策は**シングル・シークレット・リーダー・エレクション (SSLE)**です。

## シングル・シークレット・リーダー・エレクション {#secret-leader-election}

SSLEでは、巧妙な暗号技術を使用して、選ばれたバリデータだけが自分が選ばれたことを知ることができるようにします。これは、各バリデータが全員で共有するシークレットに対するコミットメントを提出することで機能します。コミットメントはシャッフルおよび再構成され、誰もコミットメントをバリデータにマッピングできないようになりますが、各バリデータはどのコミットメントが自分のものであるかを知っています。その後、1つのコミットメントがランダムに選ばれます。バリデータは自分のコミットメントが選ばれたことを検出すると、自分がブロックを提案する番であることを知ります。

このアイデアの主要な実装は[Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763)と呼ばれています。その仕組みは以下の通りです。

1. バリデータは共有シークレットにコミットします。このコミットメントスキームは、バリデータの身元に結び付けることができると同時にランダム化されるように設計されており、第三者がその結び付きをリバースエンジニアリングして特定のコミットメントを特定のバリデータにリンクさせることはできません。
2. エポックの開始時に、RANDAOを使用して16,384人のバリデータからコミットメントをサンプリングするために、ランダムなバリデータのセットが選ばれます。
3. 次の8182スロット（1日）の間、ブロック・プロポーザーは自身のプライベートなエントロピーを使用して、コミットメントのサブセットをシャッフルおよびランダム化します。
4. シャッフルが完了した後、RANDAOを使用してコミットメントの順序付きリストが作成されます。このリストはイーサリアムのスロットにマッピングされます。
5. バリデータは自分のコミットメントが特定のスロットに割り当てられていることを確認し、そのスロットが来たらブロックを提案します。
6. コミットメントのスロットへの割り当てが常に現在のスロットよりもはるかに先になるように、これらの手順を繰り返します。

これにより、攻撃者が次にどの特定のバリデータがブロックを提案するかを事前に知ることができなくなり、DoS攻撃を防ぐことができます。

## シークレット・ノンシングル・リーダー・エレクション (SnSLE) {#secret-non-single-leader-election}

また、プルーフ・オブ・ワーク (PoW) の下でブロック提案が決定されていた方法と同様に、各バリデータが各スロットでブロックを提案するランダムな機会を持つシナリオを作成することを目的とした別の提案もあり、これは**シークレット・ノンシングル・リーダー・エレクション (SnSLE)**として知られています。これを行う簡単な方法の1つは、現在のプロトコルでバリデータをランダムに選択するために使用されているRANDAO機能を利用することです。RANDAOのアイデアは、多くの独立したバリデータによって提出されたハッシュを混合することで、十分にランダムな数値を生成するというものです。SnSLEでは、これらのハッシュを使用して、例えば最も値の小さいハッシュを選択することで、次のブロック・プロポーザーを選ぶことができます。有効なハッシュの範囲を制限することで、各スロットで個々のバリデータが選ばれる可能性を調整できます。ハッシュが`2^256 * 5 / N`未満でなければならないとアサートすることで（ここで`N` = アクティブなバリデータの数）、各スロットで個々のバリデータが選ばれる確率は`5/N`になります。この例では、各スロットで少なくとも1人のプロポーザーが有効なハッシュを生成する確率が99.3%になります。

## 現在の進捗状況 {#current-progress}

SSLEとSnSLEはどちらも研究段階にあります。どちらのアイデアについても、まだファイナライズ済みの仕様はありません。SSLEとSnSLEは競合する提案であり、両方を実装することはできません。リリースする前に、さらなる研究開発、プロトタイピング、およびパブリックテストネットでの実装が必要です。

## 参考文献 {#further-reading}

- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)