プルーフ・オブ・ステークのイーサリアムにおける鍵
イーサリアムは、公開鍵・秘密鍵暗号技術を使用してユーザーの資産を保護します。公開鍵はイーサリアムのアドレスの基礎として使用されます。つまり、一般に公開され、一意の識別子として使用されます。秘密鍵（または「シークレット」キー）は、アカウントの所有者のみがアクセスできるようにする必要があります。秘密鍵は、トランザクションやデータに「署名」するために使用され、暗号技術によって、特定の秘密鍵の保持者が何らかのアクションを承認したことを証明できます。
イーサリアムの鍵は、楕円曲線暗号技術 (opens in a new tab)を使用して生成されます。
しかし、イーサリアムがプルーフ・オブ・ワーク (PoW)からプルーフ・オブ・ステーク (PoS)に移行した際、新しいタイプの鍵がイーサリアムに追加されました。元の鍵は以前とまったく同じように機能します。アカウントを保護する楕円曲線ベースの鍵に変更はありませんでした。しかし、ユーザーがETHをステーキングし、バリデータを実行してプルーフ・オブ・ステーク (PoS) に参加するためには、新しいタイプの鍵が必要でした。この必要性は、多数のバリデータ間で多くのメッセージがやり取りされることに関連するスケーラビリティの課題から生じました。ネットワークがコンセンサスに達するために必要な通信量を減らすために、簡単に集約できる暗号技術的手法が求められたのです。
この新しいタイプの鍵は、Boneh-Lynn-Shacham (BLS) 署名スキーム (opens in a new tab)を使用しています。BLSは署名の非常に効率的な集約を可能にするだけでなく、集約された個々のバリデータ鍵のリバースエンジニアリングも可能にし、バリデータ間のアクションを管理するのに理想的です。
2種類のバリデータ鍵
プルーフ・オブ・ステーク (PoS) への移行前、イーサリアムのユーザーは資金にアクセスするために単一の楕円曲線ベースの秘密鍵しか持っていませんでした。プルーフ・オブ・ステーク (PoS) の導入により、ソロでステーキングを行いたいユーザーには、バリデータ鍵と引き出し鍵も必要になりました。
バリデータ鍵
バリデータの署名鍵は、次の2つの要素で構成されています。
- バリデータの秘密鍵
- バリデータの公開鍵
バリデータの秘密鍵の目的は、ブロックの提案やアテステーションなどのオンチェーン操作に署名することです。このため、これらの鍵はホット・ウォレットに保持する必要があります。
この柔軟性には、バリデータの署名鍵をあるデバイスから別のデバイスへ非常に迅速に移動できるという利点がありますが、紛失したり盗まれたりした場合、窃盗犯はいくつかの方法で悪意のある行動をとる可能性があります。
- 以下の方法でバリデータにスラッシングを受けさせる：
- プロポーザーとして、同じスロットに対して2つの異なるビーコンブロックに署名する
- アテスターとして、別のアテステーションを「囲む (surrounds)」アテステーションに署名する
- アテスターとして、同じターゲットを持つ2つの異なるアテステーションに署名する
- 自発的なエグジットを強制し、バリデータのステーキングを停止させ、引き出し鍵の所有者にETH残高へのアクセスを許可する
ユーザーがステーキング・デポジット・コントラクトにETHをデポジットする際、トランザクションデータにはバリデータの公開鍵が含まれます。これは_デポジットデータ_として知られており、これによりイーサリアムはバリデータを識別できます。
出金クレデンシャル
すべてのバリデータには、_出金クレデンシャル_として知られるプロパティがあります。この32バイトのフィールドの最初のバイトは、アカウントのタイプを識別します。0x00 は元のBLS（シャペラ以前、引き出し不可）クレデンシャルを表し、0x01 は実行アドレスを指すレガシークレデンシャルを表し、0x02 は最新の複利型クレデンシャルを表します。
0x00 のBLS鍵を持つバリデータは、超過残高の支払いやステーキングからの全額引き出しを有効にするために、これらのクレデンシャルを実行アドレスを指すように更新する必要があります。これは、初期の鍵生成時にデポジットデータに実行アドレスを提供するか、_または_後で引き出し鍵を使用して BLSToExecutionChange メッセージに署名してブロードキャストすることで実行できます。
引き出し鍵
初期デポジット時に設定されていない場合、出金クレデンシャルを実行アドレスを指すように更新するために引き出し鍵が必要になります。これにより、超過残高の支払いの処理が開始され、ユーザーはステーキングしたETHを全額引き出すこともできるようになります。
バリデータ鍵と同様に、引き出し鍵も2つのコンポーネントで構成されています。
- 引き出しの秘密鍵
- 引き出しの公開鍵
出金クレデンシャルを 0x01 タイプに更新する前にこの鍵を紛失すると、バリデータの残高へのアクセスを失うことになります。アテステーションやブロックへの署名にはバリデータの秘密鍵が必要なため、バリデータは引き続きこれらのアクションを実行できますが、引き出し鍵を紛失した場合、インセンティブはほとんど、あるいはまったくありません。
バリデータ鍵をイーサリアムのアカウント鍵から分離することで、単一のユーザーが複数のバリデータを実行できるようになります。
注: ステーキングの義務からエグジットし、バリデータの残高を引き出すには、現在、バリデータ鍵を使用して自発的エグジットメッセージ (VEM) (opens in a new tab)に署名する必要があります。しかし、EIP-7002 (opens in a new tab)は、将来的にユーザーが引き出し鍵でエグジットメッセージに署名することで、バリデータのエグジットをトリガーし、その残高を引き出すことができるようにする提案です。これにより、ETHをStaking-as-a-Serviceプロバイダーにデリゲートするステーカーが資金のコントロールを維持できるようになり、トラスト前提が軽減されます。
シード・フレーズからの鍵の導出
ステーキングされた32 ETHごとに完全に独立した2つの鍵の新しいセットが必要になると、特に複数のバリデータを実行しているユーザーにとって、鍵の管理はすぐに手に負えなくなります。代わりに、単一の共通のシークレットから複数のバリデータ鍵を導出でき、その単一のシークレットを保存することで複数のバリデータ鍵にアクセスできるようになります。
ニーモニック (opens in a new tab)とパスは、ユーザーがウォレットにアクセスする (opens in a new tab)際によく目にする重要な機能です。ニーモニックは、秘密鍵の初期シードとして機能する単語のシーケンスです。追加のデータと組み合わせることで、ニーモニックは「マスターキー」として知られるハッシュを生成します。これはツリーのルート（根）と考えることができます。このルートからのブランチ（枝）は階層的なパスを使用して導出できるため、子ノードは親ノードのハッシュとツリー内のインデックスの組み合わせとして存在できます。ニーモニックベースの鍵生成に関するBIP-32 (opens in a new tab)およびBIP-19 (opens in a new tab)標準についてお読みください。
これらのパスは次のような構造を持っており、ハードウェアウォレットを操作したことのあるユーザーにはおなじみでしょう。
m/44'/60'/0'/0`
このパスのスラッシュは、秘密鍵のコンポーネントを次のように区切ります。
master_key / purpose / coin_type / account / change / address_index
ツリーのルートを共通にし、ブランチで区別できるため、このロジックにより、ユーザーは単一のニーモニックフレーズに可能な限り多くのバリデータを関連付けることができます。ユーザーはニーモニックフレーズから任意の数の鍵を導出できます。
[m / 0]
/
/
[m] - [m / 1]
\
\
[m / 2]
各ブランチは / で区切られているため、m/2 はマスターキーから開始してブランチ2をたどることを意味します。以下の図では、単一のニーモニックフレーズを使用して3つの引き出し鍵を保存し、それぞれに2つのバリデータが関連付けられています。
