Ethereumステーキング：鍵の生成と管理方法
目次
- はじめに
- staking-deposit-cliの詳細
1. new-mnemonic
2. existing-mnemonic
3. deposit_data*.jsonについて
4. keystore-m*.jsonについて - おわりに
1. はじめに
Ethereum 2.0の「Proof of Stake」への移行に伴い、ネットワークを支えるバリデータには安全な鍵管理が求められる。バリデータの鍵管理には、鍵の生成と復旧のためのツールが必要不可欠であり、そのツールの1つとして「staking-deposit-cli」がある。このツールは、バリデータとして参加するための鍵や関連データを生成し、安全に保管するために使用される。本レポートでは、紛失した場合の復旧方法など、安全に活動するためのヒントを提供している。
2. staking-deposit-cliの詳細
staking-deposit-cliは、Validatorとして登録するためのEIP-2335形式のBLS12-381キーストアと対応するdeposit_data*.jsonファイルを作成するツールである。このツールの主な目的は、Ethereum 2.0のstakingに必要なキーを安全に生成することである。以下は、staking-deposit-cliの主な機能とその説明である。
2. (1) new-mnemonic
新しいニーモニックでKeystoreを生成するためのコマンド。
出所：Next Finance Tech社作成
2. (1). a コマンドの実行例
2. (2) existing-mnemonic
既存のニーモニックからKeyStoreを復元する、または、新しいKeyStoreを生成するためのコマンド。
出所：Next Finance Tech社作成
2. (2). a コマンドの実行例
2. (3) deposit_data*.jsonについて
deposit_data-.jsonは、Ethereum Staking LaunchpadのためのEIP-2335形式のBLS12-381Keystoreと対応するファイルだ。このファイルは、Ethereumのステーキングに関する情報を含んでおり、バリデータがEthereum 2.0のネットワークに参加する際に提供する必要がある。また、deposit_data-.jsonファイルはwithdrawal_credentialsを含んでいるため、非常にセキュリティが重要だとされている。withdrawal_credentialsは、Ethereum 2.0のステーキングに関連する特定の情報を指す。具体的には、バリデータがステーキング報酬を受け取るためのアドレスや情報を指定するためのものだ。Ethereum 2.0のステーキングプロセスにおいて、バリデータは特定の量のETHをデポジットとしてロックする。このデポジットは、バリデータが正しく動作することを保証するためのものだ。バリデータが正しく動作すると、ステーキング報酬を受け取ることができる。この報酬は、指定されたwithdrawal_credentialsに関連付けられたアドレスに送られる。これにより、バリデータがステーキング報酬を正しく受け取ることが保証される。
2. (3). a スキーマ
出所：Next Finance Tech社作成
2. (3). b 出力例
2. (4) keystore-m*.jsonについて
keystore-m*.jsonは、秘密鍵を安全に保存するためのフォーマットだが、その中に直接的な秘密鍵は含まれていない。代わりに、暗号化された秘密鍵やその復号に必要な情報（例: サルト、IV、暗号化アルゴリズムなど）が含まれている。
出所：Next Finance Tech社作成
2. (4). a 出力例
これらのファイルは、バリデータとして動作するための重要な情報を含んでいるため、非常に慎重に取り扱う必要がある。特にkeystore-m*.jsonは、秘密鍵を含むため、第三者に知られると資産が盗まれるリスクがあるため、安全な場所に保存し、バックアップを取ることを強くおすすめする。
2.(4).b keystore-m*.jsonの生成と復元
- 暗号化された秘密鍵の位置暗号化された秘密鍵は、crypto オブジェクトの中のcipher セクションのmessageフィールドに格納されている。
- 秘密鍵生成プロセス 1. ニーモニックの生成 a. ニーモニックは、通常、12〜24の単語からなるフレーズとして生成される。これは、暗号的に安全なランダムな方法で行われ、BIP-39（Bitcoin Improvement Proposal 39）の標準に基づいている b. このニーモニックは、ユーザーに提示され、安全な場所に記録されるように指示される 2. ニーモニックからの秘密鍵の導出 a. BIP-32とBIP-44の標準を使用して、ニーモニックから秘密鍵を導出する。このプロセスは、ニーモニックと「導出パス」を組み合わせて行われる b. 例えば、Ethereum stakingの場合、導出パスは通常 m/12381/3600/0/0/0 である 3. 鍵導出関数 (KDF) の選択 a. ユーザーが提供するパスワードとkdfセクションの情報を使用して、一時的な鍵を導出する。 4. 秘密鍵の暗号化 a. 上記で導出した一時的な鍵と、cipherセクションのparamsにあるiv（初期化ベクトル）を使用して、秘密鍵を暗号化する b. 暗号化された秘密鍵は、cipherセクションのmessageフィールドに保存される 5. チェックサムの生成 a. 暗号化された秘密鍵と一部の情報を組み合わせてハッシュを計算し、checksumセクションのmessageフィールドに保存する。 6. その他の情報の追加 a. description, pubkey, path, uuid, version などの追加情報をJSONファイルに追加する 7. JSONファイルの保存 a. 上記のすべての情報を含むJSONファイルを生成し、keystore-m*.jsonとして保存する
- 秘密鍵復元プロセス 1. パスワード a. ユーザーから入力されたパスワードを取得する。このパスワードは、Keystoreの作成時に設定されたものと同じでなければならない。 2. KDF (Key Derivation Function) の使用 a. keystore-m*.jsonには、秘密鍵を導出するためのKDFの情報が含まれている。この情報には、使用されるKDFのタイプ（例: scryptやpbkdf2）、salt、その他のパラメータが含まれる。 b. 上記のパスワードとKDFの情報を使用して、復号キーを導出する。 3. 暗号化された秘密鍵の復号 a. 上記で導出された復号キーと暗号の情報を使用して、暗号化された秘密鍵を復号する。 ① 秘密鍵の復号手順 1. まず、kdf セクションの情報を使用して、ユーザーが提供したパスワードから鍵を導出する。この例では、pbkdf2 関数が使用され、関連するパラメータ（dklen, c, prf, salt）が提供されている。 2. 次に、導出された鍵と cipher セクションの iv（初期化ベクトル）を使用して、cipher セクションの message フィールドに格納されている暗号化された秘密鍵を復号する。 3. 復号が成功すると、元の秘密鍵が取得できる。 4. チェックサムの確認 a. keystore-m*.jsonには、秘密鍵の正確さを確認するためのチェックサムも含まれる。 b. 復号された秘密鍵のチェックサムを計算し、keystore-m*.jsonに保存されているチェックサムと一致するか確認する。一致しない場合、パスワードが間違っているか、Keystoreが破損している可能性がある。 c. 具体的には、復号した秘密鍵と一部の情報を組み合わせてハッシュを計算し、checksum セクションの message フィールドの値と一致するかを確認する。 5. 秘密鍵の取得 a. 上記のステップが正常に完了した場合、復号された秘密鍵が得られる。
- 秘密鍵復元の該当プログラム
出所：Github
3. おわりに
staking-deposit-cliは、Ethereum 2.0のProof of Stakeネットワークに参加するバリデータにとって不可欠なツールであり、その正確な使用が鍵管理の安全性を左右する。本レポートで紹介したstaking-deposit-cliを使用した鍵の生成および復旧方法は、バリデータが効率的かつ安全に活動するための基盤とななる。今後もこのようなツールを活用することで、Ethereum 2.0ネットワークの安定性と持続可能性に貢献し、さらなる技術発展を支えることができるだろう。