TL;DR
- 秘密鍵は署名を作成するためのもので、秘密にしておく必要があります。その公開鍵は秘密鍵から導出され、それらの署名を検証します。共有するアドレスは、公開鍵、スクリプト、または契約ロジックから導出される可能性のある、ネットワーク固有の独立した識別子です。リカバリーフレーズは、ウォレットが複数の秘密鍵を導出するためのバックアップソースです。
- 秘密鍵とは、署名アルゴリズムで使用される秘密の暗号入力です。一般的な楕円曲線システムでは、大きな秘密の数値として表現されるか、32バイトの秘密のシードから生成されます。ウォレットソフトウェアは、暗号学的に安全な乱数源を使用してこれを生成すべきであり、ユーザーが独自に作成してはなりません。
- 公開鍵とは、秘密鍵から導出された数学的な検証データです。これにより、誰でも、その秘密鍵を知ることなく、署名が対応する秘密鍵と一致するかどうかを検証できます。公開鍵を公開しても、署名する権限は付与されません。ただし、ネットワークによっては、アカウント間の関係や活動内容が明らかになる場合があります。
- 場合によってはそうですが、一般的にはそうではありません。ウォレットアドレスはネットワーク固有の識別子です。これには、公開鍵、公開鍵のハッシュ、スクリプトのハッシュ、ウィットネスプログラム、コントラクトアドレス、あるいは秘密鍵を持たないプログラムから生成されたアドレスがエンコードされている可能性があります。常に、特定のネットワークおよびアドレスタイプのルールに従ってください。
1つのブロックで
ブロックチェーンの鍵ペアは、主にデジタル署名に使用されます。これらは、取引を自動的に暗号化したり、残高を隠したり、アドレスを匿名化したりするものではありません。 秘密鍵はパスワードではありません。これは、署名アルゴリズムで使用される秘密の暗号素材です。その形式や正確な構成は、方式やウォレットによって異なります。 公開鍵は署名を検証するために使用されます。資金は通常、アドレス、出力スクリプト、アカウント、またはプログラムによって生成された識別子に割り当てられ、公開鍵に対して一意の方法で割り当てられるわけではありません。 アドレスはチェーンごとに異なります。ビットコインのアドレスには、公開鍵のハッシュ、スクリプト、ウィットネスプログラム、またはTaprootキーがエンコードされる場合があります。イーサリアムのコントラクトアドレスには対応する秘密鍵が存在…
秘密鍵と公開鍵の違いは何ですか?
簡単な回答
秘密鍵は署名を作成するためのもので、秘密にしておく必要があります。その公開鍵は秘密鍵から導出され、それらの署名を検証します。共有するアドレスは、公開鍵、スクリプト、または契約ロジックから導出される可能性のある、ネットワーク固有の独立した識別子です。リカバリーフレーズは、ウォレットが複数の秘密鍵を導出するためのバックアップソースです。
公開鍵暗号は、意図的な非対称性を生み出します。ある情報は秘密に保たれ、アクションを承認するために使用され、もう一方の情報は広く配布することができ、誰でもその結果としての証明を確認できるようにします。ブロックチェーンはこの非対称性を利用して、銀行やアカウント管理者に顧客の身元確認を求めずに、支出の有効性を検証します。
初心者向けの簡略表現である「公開鍵は受け取り、秘密鍵は支出する」は、正しい方向性を示していますが、技術的にはあまりにも大雑把です。通常、公開鍵は署名を検証し、アドレス、出力、またはアカウントが価値を受け取ります。秘密鍵は、単純なアカウントにおける唯一の権限である場合もあれば、マルチシグネチャ方式における署名者の一人である場合もあれば、しきい値システムにおけるシェアである場合もあり、あるいはコードによって制御が定義されるコントラクトアドレスには無関係である場合もあります。
| 項目 | 主な役割 | 共有可能か? | 侵害されたり紛失したりした場合はどうなるか? |
|---|---|---|---|
| 秘密鍵 | 1つの鍵ペアで署名を作成します。 | いいえ。他人、ウェブサイト、信頼できないデバイスからは秘密にしておく必要があります。 | 漏洩すると、不正な署名が行われる可能性があります。バックアップや代替の認証機関が存在しない場合にのみ、紛失は致命的となります。 |
| 公開鍵 | 署名を検証し、場合によってはアドレスの導出に役立ちます。 | 通常、支出のセキュリティの観点からは「はい」です。 | 公開しても署名権限は付与されませんが、プライバシーが損なわれたり、将来の暗号方式の移行に伴うリスクにさらされたりする可能性があります。 |
| アドレス/出力識別子 | 価値や状態が割り当てられる場所をネットワークに伝えます。 | はい。通常、ユーザーが交換するのはこれです。 | 開示すると、履歴が明らかになったり、標的型詐欺の標的になったりする可能性があります。間違ったアドレスへの送信は、通常、取り消すことができません。 |
| リカバリーフレーズ | 決定論的なウォレットシードとそのキー階層を再生成します。 | 絶対にしないでください。 | これが漏洩すると、現在および将来の多くのアカウントが危険にさらされる可能性があります。紛失した場合、他のバックアップが存在しなければ復元できなくなる可能性があります。 |
| ウォレットのパスワードまたは PIN | ローカルウォレットのインターフェースやデバイスのロックを解除、または復号化します。 | いいえ。ただし、通常はブロックチェーンの権限そのものではありません。 | 多くの場合、リカバリー方法による復元でリセット可能ですが、製品の設計によって異なります。 |
| ウォレット | 鍵素材、署名者、ポリシー、アドレス、およびトランザクションを管理します。 | ソフトウェアは公開可能ですが、その秘密情報は公開できません。 | ウォレットには、1つの鍵、複数の鍵、エクスポート可能な鍵がない場合、あるいは分散型署名ポリシーが含まれている場合があります。 |
秘密鍵とは正確には何でしょうか?
簡単な回答
秘密鍵とは、署名アルゴリズムで使用される秘密の暗号入力です。一般的な楕円曲線システムでは、大きな秘密の数値として表現されるか、32バイトの秘密のシードから生成されます。ウォレットソフトウェアは、暗号学的に安全な乱数源を使用してこれを生成すべきであり、ユーザーが独自に作成してはなりません。
秘密鍵は、ユーザー名、アカウントのパスワード、サポートコードではありません。これは、署名者が公開鍵と一致する証明を作成することを可能にする、秘密の数学的入力です。 ビットコインやイーサリアムでは、一般ユーザーの署名にsecp256k1楕円曲線が使用されています。有効なsecp256k1秘密鍵は、曲線群内のスカラーであり、通常は32バイトで保存されます。SolanaなどのEd25519システムでは、通常32バイトの秘密シードから始まり、EdDSAの規則に従って署名用スカラーと公開鍵が導出されます。
「ランダムな256ビットの数値」といった説明はsecp256k1には有用ですが、普遍的なウォレットの定義として扱うべきではありません。鍵は、16進数、ウォレットインポート形式、暗号化されたキーストア、ハードウェアで保護された鍵オブジェクト、またはエクスポート不可能なオペレーティングシステムの認証情報など、さまざまなエンコーディングで現れます。エンコーディングはコンテナまたは表現形式であり、署名権限は根底にある秘密鍵そのものです。
生成の質が重要
鍵空間は膨大ですが、それはウォレットが信頼できる乱数と正しい暗号コードを使用している場合に限られます。人間が選んだフレーズ、覚えやすい数字、あるいは即興の「ブレインウォレット」は、エントロピーがはるかに低く、検索される可能性があります。BIP39は、コンピュータ生成の乱数を転送する方法を明示的に記述しており、ユーザーが作成した文を安全なウォレットに変える方法ではありません。
署名の実装では、メッセージごとのノンスも正しく処理する必要があります。ECDSAにおいて、その秘密のノンスを再利用したり、不適切に偏らせたりすると、長期鍵が完璧に生成されていたとしても、秘密鍵が漏洩する可能性があります。RFC 6979のような決定論的ECDSA手順は、新しいランダムなノンスへの依存度を低減しますが、実装には依然としてサイドチャネルや障害に対する保護が必要です。
秘密鍵は必ずしもアカウント全体を意味するわけではない
単純なイーサリアムの外部所有アカウントの場合、プロトコルで許可されているあらゆるトランザクションに署名するには、鍵を保有していれば十分です。ビットコインの出力については、その鍵が出力スクリプトを満たしている場合にのみ有効です。マルチシグ出力には、複数の鍵が必要になる場合があります。イーサリアムのコントラクトアカウントには独自の秘密鍵がなく、どの呼び出しや署名が受け入れられるかはコードによって決定されます。ソラナのプログラム由来のアドレスには、秘密鍵が一切存在しません。
要点:「秘密鍵を所有する者が資金を所有する」というのは、単一鍵のアカウントについては正しいが、ブロックチェーン上の所有権に関する普遍的な定義ではない。実際の権限は、アカウント、出力スクリプト、またはプログラムが有効と認めるものによって決まる。
公開鍵とは正確には何でしょうか?
簡単な回答
公開鍵とは、秘密鍵から導出された数学的な検証データです。これにより、誰でも、その秘密鍵を知ることなく、署名が対応する秘密鍵と一致するかどうかを検証できます。公開鍵を公開しても、署名する権限は付与されません。ただし、ネットワークによっては、アカウント間の関係や活動内容が明らかになる場合があります。
楕円曲線暗号において、公開鍵の導出には、標準的な曲線上の点に秘密のスカラーを乗算する処理が含まれます。順方向の計算は効率的です。結果として得られる点からスカラーを復元することは、楕円曲線離散対数問題となりますが、適切に選択された現代のパラメータに対しては、既知の古典的手法を用いても計算上不可能です。この一方向の関係こそが、ECDSA、シュノール、EdDSAの背後にあるセキュリティの前提となっています。
公開鍵にはいくつかのエンコーディング形式があります。ビットコインのsecp256k1鍵は、33バイトの圧縮された点、古い形式の65バイトの非圧縮された点、またはBIP340シュノールの32バイトのxのみの鍵として表示される場合があります。イーサリアムのツールは、ユーザーが20バイトのアドレスを操作している場合でも、内部的には通常、非圧縮のsecp256k1公開鍵を導出します。 SolanaのEd25519公開鍵は32バイトで、通常はBase58形式で表示されます。
公開鍵が証明しないこと
公開鍵は、それ自体では自動的に法的名称や個人の身元を証明するものではありません。署名は、署名時点における対応する署名権限の管理を証明するものであり、デバイスを物理的に保持していたのが誰であるか、マルウェアがリクエストを発信したかどうか、署名者がペイロードを理解していたかどうか、あるいは鍵が盗まれていたかどうかまでは証明しません。身元は、鍵ペアそのものではなく、証明書、アカウント登録、ソーシャル認証、その他の証拠といった周辺システムから導き出されるものです。
ウォレットアドレスは公開鍵と同じものですか?
簡単な回答
場合によってはそうですが、一般的にはそうではありません。ウォレットアドレスはネットワーク固有の識別子です。これには、公開鍵、公開鍵のハッシュ、スクリプトのハッシュ、ウィットネスプログラム、コントラクトアドレス、あるいは秘密鍵を持たないプログラムから生成されたアドレスがエンコードされている可能性があります。常に、特定のネットワークおよびアドレスタイプのルールに従ってください。
「アドレスは短縮された公開鍵である」という表現は、過度に一般化したものです。アドレスは、ネットワークのアカウントまたは出力モデル、チェックサム、および支出ルールに合わせて設計されています。同じチェーン上の2つのアドレスでさえ、異なる種類の権限を表す場合があります。
| ネットワーク/タイプ | ユーザー向けのアドレスが表すもの | 対応する秘密鍵は必ず存在するのでしょうか? |
|---|---|---|
| ビットコイン P2PKH / P2WPKH | secp256k1公開鍵のハッシュをエンコードしたものです。 | 関連する署名を生成するには秘密鍵が必要ですが、アドレス自体は公開鍵ではありません。 |
| ビットコイン P2SH / P2WSH | スクリプトハッシュまたはウィットネス・スクリプトハッシュのエンコード形式です。 | 必ずしも 1 つの鍵である必要はなく、スクリプトによっては複数の鍵やその他の条件が必要になる場合があります。 |
| ビットコイン P2TR | 調整された x のみの Taproot 出力鍵を含む SegWit v1 ウィットネスプログラム。 | キーパスによる支出では、秘密鍵または集約/しきい値権限を使用する場合があり、スクリプトパスでは他の条件を使用できる。 |
| イーサリアム EOA | 非圧縮の secp256k1 公開鍵の Keccak-256 ハッシュの最後の 20 バイト。 | はい、EOA 署名権限用です。 |
| イーサリアム契約アカウント | コントラクトのデプロイ規則によって作成されるアドレス。 | 固有の秘密鍵は存在せず、コントラクトコードによって制御が定義される。 |
| Solana オンカーブ署名者 | 32バイトのEd25519公開鍵で、通常はBase58でエンコードされています。 | はい、対応する秘密鍵が存在します。 |
| Solana PDA | プログラムIDとシードから導出された、曲線外のアドレス。 | いいえ。指定されたプログラムは、ランタイムルールを通じてそのアドレスに対する承認を行うことができます。 |
ビットコインの開発者向けドキュメントでは、公開鍵の配布について一般的に言及している一方で、ウォレットでは通常、公開鍵のハッシュやスクリプトのハッシュが配布されることに言及しています。イーサリアムは、外部所有のアカウントとコントラクトアカウントを区別しています。Solanaは、Ed25519公開鍵アドレスと、プログラムから派生したオフカーブアドレスの両方を明示的にサポートしています。
アドレスの形式だけでは不十分
アドレスは、対象となるネットワーク、資産、および必要に応じてメモやタグと組み合わせる必要があります。同じ16進数のEVMアドレスが複数のネットワークに存在することは可能ですが、間違ったネットワークで送信された資産は、受取人が期待するサービスを通じてアクセスできない場合があります。また、アドレスの有効性は、意図した人物による所有権を証明するものではありません。独立したチャネルを通じて宛先を確認してください。
デジタル署名はどのように機能し、何を証明するのでしょうか?
簡単な回答
ウォレットは、正確なトランザクションまたはメッセージをシリアライズし、ネットワークの署名ルールを適用して、秘密鍵を用いて署名を生成します。ノードやアプリケーションは、公開鍵を用いてその署名を検証します。署名されたペイロードを変更すると証明は無効になりますが、有効な署名があっても、要求されたアクションが安全であったことや理解されていたことが保証されるわけではありません。
デジタル署名は、秘密鍵とパブリックブロックチェーンをつなぐ運用上の架け橋です。署名者は秘密鍵そのものを送信するのではなく、署名と、検証者が署名されたペイロードを再構築し、関連する公開鍵またはアドレスを特定するのに十分なコンテキストを送信します。NISTは、デジタル署名を、不正な改ざんを検出し、周囲の鍵管理システムの下で署名者を認証するためのメカニズムと定義しています。
| 有効な署名によって確立できるのは | 有効な署名だけでは、以下のことを確立することはできません |
|---|---|
| 署名が、指定された公開鍵または復元可能な署名者と一致すること。 | 鍵の背後にある法的または個人の身元。 |
| 署名後の署名済みバイトが変更されていないこと。 | ウォレットの表示が、それらのバイトを正確に説明していたこと。 |
| アルゴリズムに従って、必要な署名権限が関与したこと。 | 鍵が盗まれたり、遠隔操作されたり、マルウェアによって使用されたりしていないこと。 |
| トランザクションまたはメッセージが、署名レベルの承認要件を満たしていること。 | 受信者アドレス、スマートコントラクト、または経済的結果が安全であること。 |
| 署名者が、その正確な暗号ペイロードを承認したこと。 | 署名者が、そこに埋め込まれたすべての権限、承認、許可、または委任を理解していたこと。 |
署名は暗号化ではない
ほとんどのパブリックブロックチェーン上のトランザクションは公開されています。署名はトランザクションを認証するものであり、金額、受取人、またはコントラクト呼び出しを隠蔽するものではありません。一部のシステムでは、暗号化や鍵合意のために公開鍵暗号を使用することもありますが、それは別のアルゴリズムと前提条件に基づく独立した操作です。
ガス代不要の署名でも、後で価値を移動させることは可能
ウォレットは、トークンの許可、マーケットプレイスの注文、ログイン認証、または型付きデータの承認など、オフチェーンのメッセージに署名する場合があります。署名の中には、単にセッションを認証するものもあれば、第三者やコントラクトが後で資産を支出することを承認するものもあります。署名時にネットワーク手数料がかからないからといって、そのリクエストが無害であるとは限りません。承認する前に、ドメイン、チェーン、支出者、資産、金額、有効期限、およびアクションを確認してください。
暗号鍵はどこから来るのか?
簡単な回答
信頼できるウォレットは、コンピュータで生成された乱数を入手し、秘密情報を生成し、ネットワークのアルゴリズムに従って1つ以上の鍵ペアを導出します。現代のウォレットでは一般的に階層的決定論的導出が採用されており、1つのルートシードから多くのアカウントやアドレスを生成できるため、それぞれに独立したランダムなバックアップを保存する必要がありません。
初期のウォレットは、互いに関連のない多数の秘密鍵を生成・バックアップしていました。階層的決定論的ウォレットはこのモデルを一変させました。ルートシードとチェーンコードから、子鍵のツリーが導出されるのです。BIP32は、ビットコイン互換システム向けにこのアプローチを標準化しました。これには、支出用鍵を公開することなく受信アドレスを生成できる「公開専用ブランチ」も含まれます。
ウォレットはその後、導出パスを使用して、アカウント、ネットワーク、受信アドレス、および変更アドレスを分離します。BIP44および関連規格では一般的な規約が定義されていますが、実装の選択肢は依然として様々です。別の製品で復元されたフレーズは、正しい導出スキーム、アカウントインデックス、およびネットワークが選択されるまで、ウォレットが空の状態として表示される場合があります。

鍵の生成は検証可能かつ再現可能であるべき
ウォレットは、暗号学的に安全な乱数生成器を使用し、十分なバックアップ情報を保持し、復元方法を明確に説明する必要があります。ハードウェアウォレットは、専用のデバイス内で秘密鍵を生成・保管する場合があります。モバイルウォレットは、オペレーティングシステムのセキュアストレージに依存する場合があります。スレッショルドウォレットは、完全な秘密鍵が決して組み立てられないように、シェアを共同で生成する場合があります。これらは単なるインターフェースの違いではなく、異なるカストディ設計です。
リカバリーフレーズは秘密鍵と同じものですか?
簡単な回答
いいえ。BIP39の下では、これらの単語はウォレットのエントロピーとチェックサムを符号化したものです。ニーモニックとオプションのパスフレーズはバイナリシードに変換され、BIP32のような決定論的ウォレットの標準では、そのシードから多数の秘密鍵が導出されます。完全な復元入力を持つ者であれば、通常、ウォレットの階層全体を再現できます。
このフレーズを「言葉で表した秘密鍵」と呼ぶのは覚えやすいですが、技術的には誤解を招く表現です。一般的な決定論的ウォレットには多くの秘密鍵が含まれています。このフレーズは、それらの鍵が導出されるルートに対する、人間が読み取れるバックアップ入力です。 BIP39では、エントロピーのサイズに応じて12、15、18、21、または24語が許可されていますが、一般消費者向けには12語と24語が一般的な形式です。すべてのウォレットがBIP39を採用しているわけではなく、一部のカストディアルウォレットやスマートアカウントシステムでは、ニーモニックが一切公開されない場合もあります。
| 認証情報 | 通常管理対象となるもの | 復旧手順 |
|---|---|---|
| 1つの生の秘密鍵 | 1つの鍵ペアまたは1つの署名者ロール。 | その鍵に関連付けられた権限のみを復元します。他のウォレットアカウントでは異なる鍵が使用される場合があります。 |
| リカバリーフレーズ/ニーモニック | 決定論的なウォレットシードと、場合によっては多数のアカウント。 | 復元は、オプションのパスフレーズ、ウォレットの標準、導出パス、およびサポートされているネットワークにも依存します。 |
| BIP39 パスフレーズ | 同じ単語から導出されるシードを変更します。 | どのパスフレーズでも、有効ではあるが異なるウォレットが生成されます。暗号学的レベルでは、「不正なパスフレーズ」という警告は表示されません。 |
| ウォレットのパスワードまたはデバイスの PIN | ローカル暗号化またはデバイスへのアクセス。 | 通常、ブロックチェーンの鍵は再生成されません。パスワードを忘れた場合、シードまたは復旧ポリシーによってウォレットを復元できる場合があります。 |
| 拡張公開鍵(xpub) | 支出を伴わずに、公開鍵とアドレスの分岐を生成します。 | 通常は署名には使用されません。プライバシー保護の観点から極めて重要であるため、決して軽率に公開してはなりません。 |
オプションのパスフレーズを忘れないでください
BIP39パスフレーズは「25番目の単語」として宣伝されることもありますが、サポートされている任意の文字列でよく、ニーモニック内部には保存されません。これを失うと、単語が正しくてもウォレットを復元できなくなる可能性があります。したがって、ウォレットの種類、パスフレーズの方針、復元手順を記載せずに単語を記録すると、一見完全に見えるが実際には不完全なバックアップを作成することになります。
1つのウォレットには1組の鍵ペアしか含まれていないのでしょうか?
簡単な回答
通常はそうではありません。現代のウォレットは、1つのルートシードから多数のアカウントやアドレスを生成したり、インポートされた鍵を管理したり、複数の署名者を調整したり、ポリシーが変更可能なスマートアカウントを制御したりすることがあります。「ウォレット」、「アカウント」、「アドレス」、「鍵ペア」は、それぞれ異なるレイヤーです。
ビットコインウォレットは、アドレスの再利用を減らし、UTXOモデルを管理するために、新しい受信アドレスやお釣り用アドレスを生成することがよくあります。各アドレスは、異なる子キーやスクリプトに対応している場合があります。イーサリアムウォレットは通常、1つのフレーズから派生した複数の外部所有アカウントを表示し、それぞれに独自の秘密鍵とアドレスを持っています。ソラナウォレットは、複数のキーペアやトークンアカウントを管理できます。取引所のアカウントは、顧客にブロックチェーンの秘密鍵を一切提供することなく、残高を表示する場合があります。
| 用語 | 実用的な意味 |
|---|---|
| ウォレットアプリケーション | トランザクションを構築し、署名者を管理し、残高を追跡するソフトウェアまたはハードウェアのインターフェース。 |
| ウォレットファイル/キーストア | ウォレットアプリケーションで使用される、保存された鍵データまたは暗号化されたメタデータ。 |
| アカウント | ネットワークまたはアプリケーションレベルのレコード。鍵管理型、契約管理型、またはカストディアル型である場合がある。 |
| アドレス | アカウント、出力、スクリプト、コントラクト、またはプログラムによって導出された位置を示す、ネットワーク固有の識別子。 |
| 鍵ペア | 1つの秘密署名鍵と、それに対応する公開検証鍵。 |
| シード/復元用データ | キーペアの決定論的な階層を再生成するために使用される入力。 |
| 署名者ポリシー | どの鍵、シェア、パスキー、またはコントラクトがアクションを承認しなければならないかを定義するルール。 |
要点:「私のウォレットには1つの秘密鍵がある」と言うのは、多くの場合誤りです。セキュリティ計画では、ウォレットを承認または再生成できるすべてのルートシークレット、署名者、デバイス、バックアップ、および復旧パスを特定する必要があります。
ビットコイン、イーサリアム、ソラナの違いは?
簡単な回答
これらは、大まかな公開鍵の概念は共通していますが、署名アルゴリズム、アカウントモデル、アドレスのルールが異なります。ビットコインは出力タイプに応じてECDSAとシュノールを併用しています。イーサリアムのEOA(外部所有アカウント)はECDSAを使用しますが、コントラクトではコードで定義された制御が使用されます。ソラナの標準キーペアはEd25519を使用し、プログラムは秘密鍵なしでアドレスを制御できます。
| プロパティ | ビットコイン | イーサリアム | ソラナ |
|---|---|---|---|
| 一般的なユーザー署名 | レガシーおよびSegWit v0キーによる支出にはsecp256k1上のECDSAを、Taprootにはsecp256k1上のBIP340 Schnorrを使用します。 | 外部所有アカウントの取引および EIP-7702 による承認には、secp256k1 上の ECDSA を使用。 | 標準的な鍵ペア署名にはEd25519 / EdDSAを使用します。 |
| 「アドレス」の意味 | 出力タイプのエンコーディング:キーハッシュ、スクリプトハッシュ、ウィットネスプログラム、またはTaproot出力キー。 | 20バイトのEOAまたはコントラクト識別子。EOAアドレスは公開鍵から導出されますが、コントラクトアドレスはそうではありません。 | 32 バイトのアカウントアドレス:多くの場合、Ed25519 公開鍵、またはオフカーブプログラムから導出されたアドレスです。 |
| レジャーモデル | スクリプトによってロックされたUTXO。 | アカウントの状態:EOA およびコントラクト。 | アカウントには、lamport、データ、所有者プログラム、その他のフィールドが含まれます。 |
| 1つのアドレスに複数の署名者を必要とすることは可能ですか? | はい、スクリプトポリシー、Taprootスクリプトパス、または集約/閾値構造を通じて可能です。 | はい、スマートコントラクトアカウントまたはウォレットポリシーを通じて可能です。 | はい、プログラムロジックやマルチシグネチャプログラムを通じて可能です。 |
| アドレスに秘密鍵がなくてもよいですか? | はい、スクリプトコミットメントは必ずしも1つの鍵に対応する必要はありません。 | はい、コントラクトアカウントには秘密鍵がありません。 | はい、PDAは意図的に曲線から外れています。 |
Pectra以降のイーサリアム:委任は鍵の置き換えではない
EIP-7702により、イーサリアムのEOAは実行をコードに委任できるようになり、スマートアカウントのような機能が実現されます。とはいえ、EOAの秘密鍵は完全な権限を保持しており、委任の置き換えや解除を行うことができます。EOAをマルチシグ形式のコードに委任しても、その基盤となるEOAの鍵が真のしきい値要件になるわけではありません。
アルゴリズム名の重要性
ECDSA、Schnorr、EdDSAはいずれもデジタル署名を生成しますが、それらのエンコーディング、ノンスのルール、集約特性、検証手順は異なります。ある方式の鍵や署名が、単に両方が32バイトの値を使用しているという理由だけで、別の方式と互換性があると仮定することはできません。どのアルゴリズムやエンコーディングが有効であるかは、ネットワークソフトウェアが正確に決定します。
公開鍵やウォレットアドレスを共有しても安全か?
簡単な回答
現在の暗号学的仮定の下では、通常、アドレスや公開鍵を共有しても、支出権限が与えられることはありません。ただし、残高、取引の関連性、身元情報が露見する可能性があり、フィッシング、アドレスポイズニング、スパムトークン、あるいは物理的な脅迫の標的となる恐れがあります。
公開鍵は公開されるために存在し、アドレスは配布されるために存在します。あなたのビットコインアドレス、イーサリアムアドレス、またはソラナの公開鍵を知っている者が、現在の古典的な計算手法では、単に秘密鍵を導き出すことはできません。しかし、その識別子に関連する公開活動を観察し、それを取引所の記録、ソーシャルメディアの投稿、ドメイン名、または漏洩したデータと組み合わせることは可能です。
アドレスが何を明らかにするかは、その使用方法によって異なります
アカウント形式のアドレスを再利用すると、長い取引履歴や現在のトークン残高が露呈する可能性があります。ビットコインウォレットは、多くの場合、新しい受信アドレスを生成するため、単純な再利用は減りますが、それでもグラフ分析による関連付けの痕跡は残ります。拡張公開鍵を公開することは、はるかに多くの情報を露呈することになります。これにより、観察者は公開ブランチ全体を導き出し、将来の多くのアドレスを監視できるようになる可能性があります。
安全な受信方法
- リスクに見合った適切なチャネルを通じてアドレスを共有し、高額な送金先は個別に確認してください。
- 単なる文字列だけでなく、ネットワークと資産を明示してください。同じEVMアドレスが複数のネットワーク上に存在する場合があります。
- 確認せずに取引履歴から繰り返し受取人をコピーしないでください。アドレスポイズニングによる送金は、類似したエントリを仕込むことを目的としています。
- 高額な送金については、信頼できるディスプレイ上で宛先全体を検証してください。標的型の一見似たようなアドレスに対しては、先頭と末尾の数文字のみを確認するだけでは不十分です。
- 運用上適切であればテスト取引を行い、残高を送金する前に別のチャネルを通じて受領を確認してください。
- 多額の保有資産を、本名、居住地、または旅行スケジュールと公に結びつけることは避けてください。
秘密鍵やリカバリーフレーズが漏洩した場合はどうすればよいですか?
簡単な回答
影響を受けた権限は恒久的に侵害されたものとみなしてください。クリーンで信頼できる環境から、真に新しい復元用素材または新しいアカウントポリシーを作成し、安全に可能な限り迅速に資産を移動または再割り当てしてください。漏洩したフレーズを別のウォレットにインポートして、それを新しいウォレットと呼んではいけません。
対応策は、何が漏洩したかによって異なります。1つの子秘密鍵が漏洩した場合、関連するアカウントのみが侵害される可能性がありますが、チェーン間の再利用や高度なHD関係により、被害が拡大する可能性があります。リカバリーフレーズが漏洩した場合、通常はそこから派生したすべてのアカウント(まだ表示されていないアカウントを含む)が侵害されます。マルチシグやスマートアカウントの署名鍵については、侵害されていない署名者が十分に残っていれば、置き換え可能な場合があります。
直ちに行うべき対応手順
- 侵害された可能性のあるデバイスやブラウザセッションの使用を中止してください。連絡してきた人物から送られてきた復旧リンクには絶対に従わないでください。
- 安全な端末で、新しい秘密鍵を使用して新しいウォレットまたは署名ポリシーを初期化してください。ソフトウェア、ネットワーク、復元用バックアップを個別に検証してください。
- アカウントの設計に従って、価値のある資産を移動するか、署名者をローテーションしてください。鍵が侵害されると競合状態が生じるため、資産やネイティブ手数料トークンの優先順位を慎重に決定してください。
- イーサリアムトークンの承認については、承認の取り消しだけでは秘密鍵の漏洩問題は解決しないことに留意してください。攻撃者は新しいトランザクションに署名できる可能性があります。権限または資産を移管してください。
- テストアカウント、レイヤー2ネットワーク、目立たないトークン残高を含め、同じ鍵やフレーズが使用されたすべてのネットワークを確認してください。
- トランザクションのハッシュ、アドレス、メッセージ、およびデバイスの証拠を保存してください。盗難については、関連するカストディアン、取引所、および法執行機関に速やかに報告してください。
- 前払いの手数料で確実な復旧を約束する者には応じないでください。復旧詐欺師は、既知の被害者を組織的に標的にしています。
秘密鍵を紛失するとどうなるか?
簡単な回答
単純な自己管理型アカウントの場合、唯一の秘密鍵とすべての有効なバックアップを紛失すると、資金にアクセスできなくなります。ブロックチェーンには残高が表示され続けますが、本人確認窓口やパスワード再設定の仕組みはありません。他のカストディモデルでは、アカウントの復旧、署名者のローテーション、またはしきい値による再構築が可能な場合があります。
ネットワークは、鍵が紛失したのか、破壊されたのか、あるいは意図的に放棄されたのかを認識しません。ネットワークが認識するのは、有効な認証が提示されたかどうかのみです。それがなければ、ロックされた資産は半永久的に台帳に残ったままとなります。だからこそ、バックアップの設計は単なるオプションの利便性ではなく、所有権の一部なのです。
| カストディモデル | 1つの認証情報が紛失した場合 |
|---|---|
| 単一鍵による自己管理 | 有効なバックアップまたはリカバリーフレーズから復元します。これがない場合、通常はアクセス権を永久に失います。 |
| カストディ型取引所またはサービス | プロバイダーはブロックチェーンの鍵を保有しているため、本人確認およびセキュリティチェックを経て、アカウントへのアクセスを復元できる場合があります。 |
| オンチェーンのマルチシグ | 残りの署名者が閾値を満たせば、資金の移動や新しいポリシーの設定が可能です。 |
| スマートコントラクトアカウント | 事前に設計されていれば、リカバリーモジュール、ガーディアン、パスキー、タイムロック、または管理者ルールが署名者の代わりとなる可能性があります。 |
| しきい値/MPCウォレット | プロトコルおよび閾値が許容する場合、残りのシェアは署名を継続するか、再シェアリングプロセスを実行することができます。 |
| EIP-7702 委任された EOA | 元のEOAキーは依然として権威あるものとして扱われます。紛失前にあらかじめ定められた別の仕組みが作動しない限り、その紛失は依然として根本的な障害となります。 |
後継者指定および判断能力喪失
復旧計画は、盗難だけでなく、死亡、判断能力の喪失、紛失にも対応すべきである。その計画は、現在において単一の標的となりやすい状態を作り出すことなく、権限のある者が復旧に必要な十分な情報を得られるようにしなければならない。資産の価値や管轄区域によっては、マルチシグネチャ、専門業者による保管、封印された指示書、法的文書、あるいは入念にテストされたスマートアカウントの復旧ポリシーなどが含まれる場合がある。技術的な復旧と法的権利は別個の問題である。
秘密鍵を変更、分割、または置き換えることは可能か?
簡単な回答
従来の単一鍵アカウントにおいて、同じ鍵ペアを維持したまま、運用上、独立した新しい秘密鍵に切り替えることはできません。新しい鍵ペアを作成し、資産を移動させる必要があります。その代わり、スクリプト、マルチシグ契約、スマートアカウント、およびしきい値システムを利用すれば、アカウントやポリシーを維持したまま、権限を分散させたり、署名者を置き換えたりすることができます。
実用的なウォレットのセキュリティにおいて、独立して生成された代替鍵は異なる公開鍵を持ち、意図されたセキュリティの前提条件下では、切り詰められたアドレス識別子を保持する別の鍵を見つけることは計算上不可能です。 したがって、通常の単一鍵のビットコイン出力やイーサリアムのEOAにおいて、鍵のローテーションとは、資金を新しい宛先に転送することを意味します。アップグレード可能なスマートアカウントのポリシーでは、アカウントアドレスを変更することなく、承認された署名者を置き換えることができます。マルチシグネチャのポリシーでは、新しい署名者セットを確立するためのトランザクションが必要になる場合があります。

図3。「秘密鍵」は、あり得る承認モデルの一つに過ぎない。スクリプト、コントラクト、および閾値プロトコルによって、制御権を分散またはローテーションさせることができる。
オンチェーンのマルチシグ
ブロックチェーンは、複数の独立した署名またはコントラクトの承認を必要とするポリシーを検証する。ポリシーはオンチェーン上で可視化される可能性があるが、Taprootでは支出が行われるまで未使用のスクリプトパスを非表示にすることができる。マルチシグは透明性の高いルール適用とチェーン固有の復旧オプションを提供するが、コストが高くなり、運用構造が露呈する可能性がある。
しきい値署名とMPC
しきい値プロトコルは、署名シェアを分散させ、必要なサブセットが協力して1つの通常の署名を生成するようにします。適切な分散鍵生成設計では、完全な秘密鍵が1つのメモリに存在する必要は一切ありません。ブロックチェーンには、マルチシグポリシーではなく通常の署名が表示される場合があります。その場合、セキュリティはプロトコルの選択、独立したシェア環境、および実装の品質に大きく依存します。
スマートアカウントとパスキー
契約ベースのアカウントは、複数の署名方式、パスキー、支出限度額、セッション、ガーディアン、または遅延復旧を検証できます。これにより、ユーザビリティと鍵のローテーションが向上する一方で、コード、アップグレード、ガバナンスに関するリスクも生じます。したがって、契約アドレスは、固有の公開鍵・秘密鍵ペアではなく、ポリシーによって制御されます。
ハードウェアウォレットは何を保護するのか?
簡単な回答
ハードウェアウォレットは、秘密鍵の素材を汎用コンピュータから隔離し、信頼できるディスプレイに取引の詳細を表示するように設計された署名デバイスです。これにより、リモートでの鍵抽出のリスクは低減されますが、漏洩したリカバリーフレーズを保護したり、所有者が悪意のある取引を承認するのを阻止したりすることはできません。
ハードウェアウォレットの最大の利点は「分離」です。コンピュータやスマートフォンで未署名のトランザクションを準備する一方で、デバイスが秘密鍵を保持し、内部で署名処理を行います。たとえホストが侵害されたとしても、攻撃者は依然としてユーザーによるデバイス上での承認を必要とします。これは、ユーザーが信頼できる画面上で、宛先、金額、ネットワーク、および関連するコントラクトの権限を確認した場合にのみ機能します。
重要な制限事項
- リカバリーフレーズが漏洩すると、デバイスは無力化されます。フレーズを所持する者なら誰でも、別の場所で鍵を再作成できます。
- ブラインド署名や判読不能な署名では、鍵がデバイスから一切外に出ない場合でも、悪意のある承認、許可、またはスマートコントラクトの呼び出しが許可されてしまう可能性があります。
- コンピュータ上で宛先がすり替えられていても、ユーザーがハードウェアの表示を確認せずに確認を行えば、その操作が成立してしまう可能性があります。
- ファームウェア、サプライチェーン、物理的アクセス、およびバックアップ手順は、依然として脅威モデルの一部です。
- 単一のハードウェアウォレットと1つのフレーズだけでは、依然として単一障害点となり得ます。マルチシグやしきい値方式の設計は、別の問題に対処するものです。
- 資産価格のリスク、不正な取引相手、侵害されたスマートコントラクト、あるいは誤ったネットワークの選択から保護できるデバイスはありません。
要点:ハードウェアの隔離は重要ですが、「鍵がオフラインのままだった」ことと「取引が安全だった」ことは同義ではありません。信頼できるディスプレイとユーザーの検証判断は、セキュリティ境界の一部です。
量子コンピュータは暗号鍵にとってどのような意味を持つのか?
簡単な回答
ECDSA、シュノール、Ed25519は、十分に大規模な耐故障性を持つ量子コンピュータに対抗するよう設計されていません。そのようなマシンは、原理的にはショアのアルゴリズムを用いて、公開鍵から楕円曲線秘密鍵を復元できる可能性があります。現時点でこれを実行できる公に知られた量子コンピュータは存在せず、実用上のリスクは将来のハードウェア、プロトコルの移行、および公開鍵が露出するタイミングに依存します。
NISTのFIPS 186-5は、その古典的署名アルゴリズムが大規模な量子コンピュータに対して耐性を持つとは期待されていないことを明示的に指摘している。NISTは別途、ML-DSAやSLH-DSAを含むポスト量子署名を標準化している。これらの標準はブロックチェーンを自動的にアップグレードするものではない。各ネットワークには、互換性のあるアドレス、署名検証、ウォレットのサポート、および既存の資金のための移行パスが必要となる。
「ハッシュのみが公開されているため、未使用のアドレスは量子安全である」というよく繰り返される主張は、普遍的に信頼できるものではありません。アドレスの種類は様々です。Taprootの出力キーやSolanaの署名者の公開鍵は可視化されており、Ethereumの公開鍵は使用後に署名から復元できることが多く、資金は様々な方法で移動されたり公開されたりする可能性があります。ハッシュ化によって公開鍵の公開を遅らせることはできますが、完全な移行戦略とは言えません。
ユーザーが今すべきこと
- パニックに陥ったり、緊急性を煽って販売されている検証済みのない「量子安全」な製品に資金を移動したりしないでください。
- 将来のネットワーク移行ツールを採用できるよう、ウォレットソフトウェアと署名デバイスのサポートを維持してください。
- ネットワークのウォレットモデルが新しいアドレスの使用を推奨している場合は、不必要なアドレスの再利用を避けてください。
- 移行が発表された場合は、公式のプロトコルおよびウォレットのガイダンスに従い、移行先や期限を独自に確認してください。
- 長期にわたる機関向けカストディについては、ガバナンス計画に暗号技術の柔軟性と移行権限を盛り込んでください。
よくある質問
秘密鍵とは、一言で言えば何ですか?
秘密鍵とは、アカウントや出力の承認ルールを満たす署名を作成するために使用される、秘密の暗号素材のことです。シングルキー設計では、秘密鍵を所有しているだけで資産を移動できる可能性があるため、秘密鍵は秘密にしておく必要があります。
公開鍵を一文で説明すると?
公開鍵とは、秘密鍵から導出された検証用データです。これにより、誰でも秘密鍵を知ることなく、また署名する能力を得ることなく、署名の整合性を確認することができます。
ウォレットアドレスは公開鍵と同じものですか?
一般的には違います。アドレスには、公開鍵、公開鍵のハッシュ、スクリプトやウィットネスプログラム、コントラクト識別子、あるいはプログラムによって生成されたアドレスなどがエンコードされている場合があります。Solanaでは、標準的な署名者アドレスは公開鍵そのものですが、Ethereumでは、コントラクトアドレスに対応する秘密鍵は存在しません。
ウォレットアドレスだけを知られた場合、誰かが私の暗号資産を盗むことはありますか?
通常はできません。アドレスだけでは署名権限は付与されません。アドレスからは残高や取引履歴が判明したり、標的型詐欺が可能になったり、アドレスポイズニングの試みに利用されたりする可能性があるため、公開されているとはいえ、必ずしもプライバシーが保護されているわけではありません。
公開鍵から秘密鍵を計算されることはありますか?
安全なサポート対象曲線と正しい実装が使用されている場合、既知の実用的な古典的手法では不可能です。現在のセキュリティレベルでは、この問題は計算上不可能です。将来、大規模で耐故障性の高い量子コンピュータが登場すれば、この前提は覆されることになるため、移行計画が重要となります。
シードフレーズは秘密鍵と同じものですか?
いいえ。リカバリーフレーズは通常、シードを導出するために使用されるエントロピーを符号化したものであり、決定論的ウォレットはそのシードから多数の秘密鍵を導出します。このフレーズは、ウォレットの階層構造全体を再構築できるため、単一の生の秘密鍵よりも強力な場合が多いのです。
ウォレットのパスワードと秘密鍵の違いは何ですか?
ウォレットのパスワードやPINは、通常、ローカルソフトウェアのロックを解除したり、キーストアを復号化したり、デバイスを認証したりするために使用されます。一方、秘密鍵はブロックチェーン上の署名権限そのものです。パスワードを忘れても、ウォレットのバックアップがあれば復旧できる場合がありますが、唯一の署名鍵を失った場合は復旧できません。
アドレスを変更せずに秘密鍵を変更することはできますか?
従来の数学的な鍵ペアとは異なります。異なる秘密鍵からは、異なる公開鍵が生成されます。スマートコントラクトウォレットやその他のポリシー管理型アカウントでは、同じアカウントアドレスを維持したまま、承認権限を持つ署名者を変更することが可能です。
なぜ私のビットコインウォレットは新しいアドレスを生成するのですか?
階層的決定論的(HD)ビットコインウォレットは、1つのルートシードから多数の受信アドレスや変更アドレスを生成します。新しいアドレスを使用することで、単純なアドレスの再利用を減らし、毎回新しい独立したバックアップを作成することなく、ウォレットが個別のUTXOを管理できるようになります。
拡張公開鍵を共有すべきですか?
プライバシーへの影響を十分に理解した上で、信頼できるシステムとのみ共有してください。拡張公開鍵は、通常は資金を支出することはできませんが、アドレスの公開ブランチ全体を監視・導出することを可能にする可能性があります。
ハードウェアウォレットはコインを保管しますか?
いいえ。資産はブロックチェーンに記録されます。ハードウェアウォレットは署名用素材を保管・保護し、取引を承認する役割を果たします。そのリカバリーフレーズやその他のバックアップを使用すれば、互換性のある別のデバイス上で権限を再構築することができます。
要点
秘密鍵、公開鍵、アドレス、リカバリーフレーズは相互に関連していますが、互いに置き換え可能なものではありません。秘密鍵または署名シェアが権限を生み出します。公開鍵はそれを検証します。アドレスはネットワーク上の宛先や支出条件を特定します。リカバリーシステムは、元のデバイスが故障した際に権限を再生成または置き換えます。これらの層を混同すると、不適切な説明や多大な損失を招くミスを招きます。
持続可能なセキュリティ習慣とは、単一の文字列ではなく、署名システム全体を保護することです。信頼できるソフトウェアやハードウェアで鍵を生成してください。リカバリー情報を秘密に保ち、動作確認を行ってください。信頼できるディスプレイ上で、正確な取引内容を確認してください。オフチェーンのものを含め、署名を強力な承認権限として扱ってください。リカバリー方法や障害時の対応を実際に理解しているカストディモデルを利用してください。
出典および参考文献
本記事の主要な参考文献(2026年7月現在)。
- NIST FIPS 186-5 - デジタル署名規格。https://csrc.nist.gov/pubs/fips/186-5/final
- ビットコイン開発者ガイド - ウォレット。 https://developer.bitcoin.org/devguide/wallets.html
- ビットコイン開発者ガイド - トランザクション。 https://developer.bitcoin.org/devguide/transactions.html
- BIP 340 - secp256k1 用のシュノール署名。 https://bips.dev/340/
- BIP 341 - Taproot: SegWit バージョン 1 の支出ルール。 https://bips.dev/341/
- BIP 32 - 階層的決定論的ウォレット。 https://bips.dev/32/
- BIP 39 - 決定論的鍵を生成するためのニーモニックコード。 https://bips.dev/39/
- Ethereum.org - イーサリアムアカウント。 https://ethereum.org/developers/docs/accounts/
- Ethereum.org - セキュリティと詐欺防止。 https://ethereum.org/security/
- Ethereum.org - Pectra EIP-7702 ガイドライン。 https://ethereum.org/roadmap/pectra/7702/
- Solana ドキュメント - アカウント構造。 https://solana.com/docs/core/accounts
- Solana ドキュメント - プログラムによる派生アドレスの生成。 https://solana.com/docs/core/pda
- RFC 8032 - エドワーズ曲線デジタル署名アルゴリズム。 https://www.rfc-editor.org/info/rfc8032/
- NIST FIPS 204 - モジュール格子ベースのデジタル署名規格。 https://csrc.nist.gov/pubs/fips/204/final
制作上の注記:内部リンクマップ
公開前にこのセクションを削除してください。
| この記事内のアンカー位置 | リンク先 |
|---|---|
| 署名の検証に関するセクション | 暗号通貨は実際にどのように機能するのか? 鍵、コンセンサス、およびトランザクション |
| 鍵の分割と閾値に関するセクション | 第一原理に基づく閾値暗号とMPC |
| 情報漏洩とインシデント対応のセクション | 暗号通貨詐欺と脅威:見分け方と回避策 |
| トランザクションの署名に関する言及 | 暗号資産取引がどのように確認されるか |
| 基礎知識が必要な読者 | 仮想通貨とは?完全ガイド |
| xpub、派生パス、鍵ペアの初出 | 仮想通貨用語集:50の必須用語 |
簡単なクイズ: 定着しましたか?
基本的な事項を確認するためのいくつかの質問がありました。解説付きの解答が続きますが、あなたの将来のポートフォリオを除いて誰もあなたを採点しません。
「秘密鍵と公開鍵の解説」のクイズを完了しました!成果をソーシャルメディアで共有しましょう。




