階層型決定性ウォレット HD Wallet 徹底解説：設計と実装

著者: Wang Shijun (シニア フロントエンド エンジニア)

ウォレットについて本当に理解していますか？

ブロックチェーンを理解している学生やデジタル通貨 (ビットコインやイーサリアムなど) を保有している学生は、デジタル通貨を自分のウォレットに保存する方法を知っているかもしれません。市場には、単一チェーンをサポートするもの、複数チェーンをサポートするもの、モバイル アプリ、Web ページ、デスクトップ クライアント、MetaMask などのブラウザ プラグインなど、多くのウォレット アプリケーションがあります。

ほとんどのウォレット アプリケーションでは、ウォレットの作成時にニーモニック フレーズのバックアップを作成するように指示されるのはなぜですか?なぜこれらのウォレットは自らを HD ウォレットと呼ぶのでしょうか?なぜ記憶フレーズが漏洩するとコインがすべて失われると言われているのでしょうか？なぜ 1 つのニーモニック フレーズを使用して多くのアカウントを生成し、制御できるのでしょうか?ニーモニックフレーズはどのようにして秘密鍵を生成するのでしょうか?安全性は保証されていますか？クラックするのはどれくらい難しいですか？この記事を辛抱強く読んでいただければ、これらの質問に対する答えは明確になると思います。

さっそく、階層型決定論的ウォレットの設計と実装について段階的に学んでいきましょう。

ウォレットを再発見する

階層的決定論的ウォレットは、HD ウォレットと略されることがよくあります。この略語は、Hierarchical Deterministic Wallet に由来しています。階層的決定論的ウォレットとは何かを徹底的に理解したい場合は、次の名詞句を言語レベルから見てください。

それぞれの単語の技術的な意味と設計の動機を理解することは、HD ウォレットを理解するのに非常に役立ちます。

財布の中に小銭はありますか？

正確に言うと、どのブロックチェーンウォレットにもコインは存在せず、秘密鍵と公開鍵のペアのみが存在します。少し直観に反するかもしれませんが、それは本当です。ウォレットには任意の数の秘密鍵と公開鍵のペアを含めることができ、そのうちの秘密鍵を使用してトランザクションに署名し、秘密鍵によって管理されるコインを使用できますが、コイン自体はブロックチェーン台帳に保管されます。キーはあなたの資産ではなく、資産を管理するための証明書であるため、ブロックチェーンウォレットをキーチェーンとして考えるとより鮮明かもしれません。

ブロックチェーンの技術記事では、秘密鍵、公開鍵、およびアドレスは、以下に示すように特定の記号で表されます。

決定論的ウォレットとは何ですか?

初期のビットコインウォレットクライアントであるSatoshi Clientは、100個の秘密鍵と公開鍵のペアを自動的かつランダムに生成します。これらの秘密キーの間に相関関係はありません。この種のウォレットは、ランダムウォレット (Random Wallet) または非決定的ウォレット (Non-Deterministic Wallet) とも呼ばれます。ウォレットのバックアップとリカバリは、秘密鍵ごとに実行する必要があります。

シードをランダムに生成でき、その後、このシードに基づいて一連の秘密鍵と公開鍵のペアを生成できる場合、ランダムなシードのみをバックアップすればよいため、ウォレットのバックアップがはるかに簡単になります。特定のルールに従ってランダムなシードに基づいて一連のウォレットを生成するこの方法は、シードウォレット (Seeded Wallet) または決定論的ウォレット (Deterministic Wallet) と呼ばれます。シードウォレットは複数の秘密鍵を生成する際にシリアル番号をパラメータとして使用するため、この種のウォレットは線形決定論的​​ウォレット(Sequential Deterministic Wallet)とも呼ばれます。

シードウォレットはバックアップの問題を解決しますが、まだ完全ではありません。ウォレットの一部を他の人が管理できるように共有する方法はありませんが、同時に、あなたは知り、制御する権利を保持します。コミュニティの知恵は無限であり、階層的な決定論的なウォレットが誕生しました。

生成されたウォレット構造は階層的であるため、階層決定的ウォレットと呼ばれます。

階層的決定論的ウォレットの設計と実装

現在、HD ウォレットは事実上の業界標準となっています。 HDウォレットの意味を理解したら、その設計と実装を見てみましょう。

HD ウォレットのアイデアは最初にビットコイン コミュニティで登場し、ビットコイン コミュニティには新しい機能、プロセス、改善提案を提案するための標準化されたプロセスがあります。開始者はコンテンツをドキュメントの形式で作成し、ディスカッションやデモンストレーションのためにコミュニティに送信する必要があります。この種の文書はBIP（ビットコイン改善提案）と呼ばれます。ビットコインコミュニティは、BIP自体がどのように機能するべきかについても書いています。 BIP 形式とワークフローを定義するメタ BIP は こちら に示されており、HD ではウォレットに密接に関連するいくつかの BIP は次のとおりです。

まず、次の 2 つの内容を定義する BIP32 を見てみましょう。

BIP32 では、親ノードに基づいて子ノードを導出する方法は、子キー導出関数と呼ばれ、CKD と呼ばれます。 CKD は、次の 3 つのパラメータに基づいて子ノードを生成します。

生成プロセスが不可逆であることを保証するために、CKD は一方向ハッシュ関数 HMAC-SHA512 を使用します。 HD ウォレット ツリー全体のどのノードでも秘密キーと公開キーを持つことができ、そのすべてに次のプロパティがあります。

子の秘密鍵を生成するにはどうすればよいですか?

親ノードの秘密鍵 (Parent Private Key) に基づいて子ノードの秘密鍵 (Child Private Key) を生成するプロセスは次のとおりです。

子ノードの秘密鍵と子ノードのチェーン コードを入力として CKD に渡すことができ、孫ノードと任意の深さのノードを生成できます。サブ秘密キー生成関数は、BIP32 では次のようにマークされています。

子の公開鍵を生成するにはどうすればよいですか?

親ノードの公開鍵に基づいて子ノードの公開鍵を生成するプロセスは次のとおりです。

サブ秘密キー生成関数は、BIP32 では次のようにマークされています。

子ノードの秘密鍵と子ノードの公開鍵の生成プロセスが JS コードで実装される場合、コア ロジックは次のようになります。

HDKey.prototype.deriveChild = function(index) {
  var indexBuffer = Buffer.allocUnsafe(4);
  indexBuffer.writeUInt32BE(index, 0);

  var data = Buffer.concat([this.publicKey, indexBuffer]);

  var I = crypto
    .createHmac("sha512", this.chainCode)
    .update(data)
    .digest();
  var IL = I.slice(0, 32);
  var IR = I.slice(32);

  var hd = new HDKey(this.versions);

  if (this.privateKey) {
    hd.privateKey = secp256k1.privateKeyTweakAdd(this.privateKey, IL);
  } else {
    hd.publicKey = secp256k1.publicKeyTweakAdd(this.publicKey, IL, true);
  }

  hd.chainCode = IR;
  hd.index = index;

  return hd;
};

これを読んだ方は、「チェーン コードとは一体何ですか?」という多くの疑問を心に抱いたかもしれません。導入するとどのようなメリットがあるのでしょうか？各親ノードはいくつの子ノードを生成できますか?決定論的ウォレットはシードから始まり、上記では親ノードから子ノードを生成することのみを述べましたが、シードとどのように関係するのでしょうか?ぜひ読んでください。

なぜチェーンコードがあるのか?

ウォレットのセキュリティの中核は秘密キーにありますが、公開キーは比較的簡単に見つけることができます。子ノードの生成プロセスが親ノードの公開鍵と子ノードのシリアル番号のみに依存している場合、ハッカーは親ノードの公開鍵を取得した後にすべての子ノードと孫ノードの公開鍵を回復でき、プライバシーが破壊されます。 CKD で導入されたチェーン コードは、子ノード導出プロセス全体に特定の乱数を導入し、HD ウォレットのプライバシーに保護層を追加します。

拡張キーとは何ですか?

子ノードの生成プロセスでは親ノードの公開キーと親ノードのチェーン コードの両方が使用されるため、BIP32 では、この 2 つを結合し、特定の構造をエンコードした結果を拡張キーと呼び、拡張可能キーとも呼ばれます。名前が示すように、拡張キーに基づいて子ノードの導出を開始できます。親ノードの公開鍵、秘密鍵、チェーンコードの組み合わせによって生成される拡張鍵は次のとおりです。

親ノードの秘密キー、公開キー、チェーン コードは拡張キーからデコードできるため、拡張キーは HD ウォレットのブランチ、サブツリーのルートまたは開始点を表すと言えます。まさにこの特性のため、拡張キーのデータを機密に保つために特別な注意を払う必要があります。

マスターキーとは何ですか?

CKD を明確に定義した後、どこからノードの生成を開始すればよいでしょうか?マスターノードが存在する必要があります。マスター ノードを生成するには 2 つの解決策が考えられます。

2 番目のソリューションのプロセスは、次の図で表すことができます (BIP32 では、マスター ノードの秘密キーはマスター秘密キーと呼ばれ、マスター ノードのチェーン コードはマスター チェーン コードと呼ばれます)。

セキュリティを強化したCKD機能

ブロックチェーンウォレットに保存されている秘密キーはユーザーの資産を転送できるため、セキュリティはいくら強調してもしすぎることはありません。上記のサブノードの秘密鍵と公開鍵の生成機能は十分安全ですか?次のシナリオを想像してみましょう。

セキュリティ上の問題を完全に回避する方法がない場合、特定のサブノードの秘密鍵が漏洩した場合、被害を最小限に抑えるにはどうすればよいでしょうか?これには、BIP32 でセキュリティが強化されたサブ秘密キー導出関数と呼ばれる CKD 関数を若干改善する必要があり、HCKD (Hardened Child Key Derivation) として記録されます。オリジナルの CKD 関数 (Normal Child Key Derivation) とセキュリティが強化された CKD 関数のフローの比較は次のとおりです。

セキュリティが強化された CKD 機能によって生成されるノード属性名も、それに応じて変更されます。

違いは、セキュリティ強化された CKD 機能の子ノードの秘密鍵は、親ノードの公開鍵を使用せず、親ノードの秘密鍵を直接使用することです。これは、公開鍵が秘密鍵よりもハッカーによって傍受されやすいためです。このようにして、子ノードの秘密キーは親ノードの秘密キーを使用して導出する必要があります。拡張された子ノードの公開キーは、親ノードの公開キーとチェーン コードに依存するだけでは導出できません。これにより、子ノード間の兄弟関係が分かりにくくなり、強化された子ノードの秘密鍵が漏洩しても親ノードに影響を与えることはありません。

BIP32 では、CKD 関数のノード番号の範囲が 0 ～ 2^31 であるのに対し、HCKD のノード番号の範囲は 2^31 ～ 2^32 であるため、各ノードは 2^32 の子ノードを生成できます。

ノード導出パスマーカー

理論的には、HD ウォレット内のどのノードの生成にもパスが存在します。メイン ノードからノードまでのさまざまな深さでノードのシーケンス番号を見つけることができるため、各ノードを統一されたパス シンボルでマークすることができ、ノードを導出するときにパスを宣言するだけで済みます。以下に、一般的な導出プロセスと対応する導出パスをいくつか示します。

ここで、m は秘密キーを表し、M は公開キーを表します。 m/3/2/5 は、マスター ノードから派生した 4 番目の子ノードの 3 番目の孫の 6 番目の曾孫ノードを表します。 CKD 関数は導出プロセスで使用され、m/3'/2'/5' は導出プロセスで使用される HCKD 関数を表します。

各ノードの派生パスがわかったら、同じプレフィックスを持つパスをマージすることで、次のツリー状の HD ウォレット ノード構造図を取得することは難しくありません。

なぜBIP44が必要なのでしょうか?

明らかに、BIP32 はウォレットのセキュリティと使いやすさの点で良好なバランスを実現していますが、さまざまなウォレット アプリケーション開発者が独自のノード構造をカスタマイズできるため、HD ウォレット A を使用するユーザーがシードを HD ウォレット B にインポートして正常に動作することを 100% 保証することは簡単にできません。また、HD ウォレットが複数のチェーンの秘密キー管理をサポートできることを保証する方法もありません。

このため、ビットコイン コミュニティは、BIP32 に基づいて、より一般的な BIP43 とより具体的な BIP44 を提案しました。両方の目的は、HD ウォレットのサブノードの派生パス モードと各セクションの意味について具体的な規制を作成し、合意を形成することです。実際、今日の HD ウォレットはすべて BIP32 および BIP44 の規制に従っており、これら 2 つの仕様に従うウォレット アプリケーションのみが完全な互換性を持つ可能性が最も高くなります。

春秋時代と戦国時代、中国の小国ごとに馬車の文字とホイールベースが異なるため、社会取引コストが高くなりました。秦の始皇帝は六国を統一した後、「自動車は同じ軌道に、書籍は同じテキストに」という政策を実行した。 BIP44 が BIP32 に及ぼす影響は、「同じコース上の自動車と同じテキスト上の書籍」ポリシーの影響と非常によく似ています。この 2 つの組み合わせにより、BIP ウォレットが事実上の業界標準になりました。

BIP44 の内容は BIP32 よりもはるかに単純です。これは、サブノード導出パスのパラダイムを規定します。

m / purpose' / coin_type' / account' / chain / address_index

例は次のとおりです。

m/44'/60'/0'/0/0

各段落の意味は次のとおりです。

ウォレットをより使いやすくするにはどうすればよいでしょうか?

ここまででHDウォレットの基本原理は明らかになりましたが、冒頭のニーモニックフレーズについてはどうでしょうか？

インターネットは 20 年以上にわたって発展しており、すべてのインターネット ユーザーはアカウントのパスワードを入力する必要があることをよく知っています。同時に、セキュリティのために複雑なパスワードを設定する必要があるが、複雑なパスワードは覚えるのがそれほど簡単ではないため、人々がパスワードを生成、設定、記憶することが困難になってきています。ブロックチェーンウォレットで管理される秘密鍵は、ランダムに生成されたパスワードと考えることができます。このパスワードをもっと使いやすくする方法はありますか?

BIP39 によって提案されたニーモニック フレーズ メカニズムは、この問題を非常にうまく解決し、ウォレットの秘密キー (HD ウォレットの場合はシード) をセキュリティの面で危険にさらさず、覚えやすくします。 BIP39 では主に次の 2 つのプロセスについて説明します。

乱数からニーモニックまで

記憶に残る単語はランダムに生成されるという誤解が広く広まっています。実際、記憶語はランダムに生成されるのではなく、ランダムに生成されたシードの提示方法です。ニーモニックはどのように生成されるのでしょうか?全体のプロセスは次のとおりです。

プロセス全体のコード実装は次のとおりです。

function generateMnemonic(strength, rng, wordlist) {
  strength = strength || 128;
  if (strength % 32 !== 0) throw new TypeError(INVALID_ENTROPY);
  rng = rng || randomBytes;

  return entropyToMnemonic(rng(strength / 8), wordlist);
}
function entropyToMnemonic(entropy, wordlist) {
  if (!Buffer.isBuffer(entropy)) entropy = Buffer.from(entropy, "hex");
  wordlist = wordlist || DEFAULT_WORDLIST;

  var entropyBits = bytesToBinary([].slice.call(entropy));
  var checksumBits = deriveChecksumBits(entropy);

  var bits = entropyBits + checksumBits;
  var chunks = bits.match(/(.{1,11})/g);
  var words = chunks.map(function(binary) {
    var index = binaryToByte(binary);
    return wordlist[index];
  });

  return wordlist === JAPANESE_WORDLIST
    ? words.join("\u3000")
    : words.join(" ");
}

次の表に示すように、ニーモニック生成プロセス中、長さの異なる乱数には異なるチェック コードが必要となり、生成される最終的なニーモニック ワードの長さは異なります。

このテーブルは現在、BIP39 の複数の言語でサポートされており、各単語テーブルの長さは 2^11 = 2048 です。

一見すると、記憶フレーズはランダムに配置された 12 個の単語であるように見えますが、力ずくで簡単に解読できるのでしょうか? と疑問に思う生徒もいるかもしれません。ブルート フォース クラッキングの難易度を分析するために、長さ 12 のニーモニック フレーズを例に挙げてみましょう。

言うまでもなく、ニーモニック フレーズの長さは可変であり、各ニーモニック フレーズの下にあるウォレットの数はほぼ無制限です。総当たりクラックの難易度は言うまでもなく難しいです。ニーモニックフレーズを理解した後、HD ウォレットを生成するにはどうすればよいでしょうか? HD ウォレットの鍵はシードです。ニーモニックフレーズからシードを復元するだけです。全体のプロセスは次のとおりです。

JS コードは次のように実装されます。

function mnemonicToSeed(mnemonic, password) {
  var mnemonicBuffer = Buffer.from(unorm.nfkd(mnemonic), "utf8");
  var saltBuffer = Buffer.from(salt(unorm.nfkd(password)), "utf8");

  return pbkdf2(mnemonicBuffer, saltBuffer, 2048, 64, "sha512");
}

ニーモニックワードからシードへのプロセスでは、ブルートフォースクラッキングの難易度を高めるために 2 つのメカニズムが追加されていることがわかります。

ニーモニックフレーズからHDウォレットまで

現時点で、BIP32、BIP44、BIP39 の中核となる内容が明らかになりました。ニーモニックワードから HD ウォレットを生成するプロセスは次のとおりです。

{幅=100%}

イーサリアムを例に取ると、ニーモニック HD ウォレットの生成プロセスは次のように簡略化されます (ここでは、bip39、hdkey、ethereumjs-util およびその他のライブラリが使用されます)。

const bip39 = require("bip39");
const HDKey = require("hdkey");
const EthUtil = require("ethereumjs-util");

const mnemonic = bip39.generateMnemonic(128);
const seed = bip39.mnemonicToSeed(mnemonic, "");
const master = HDKey.fromMasterSeed(seed);

const account = master.derive("m/44'/60'/0'");
const addr = account.deriveChild(0).deriveChild(0);
const pubKey = EthUtil.privateToPublic(addr.privateKey);
const address = EthUtil.publicToAddress(pubKey).toString("hex");

ウォレットを取得した後、それを使用してトランザクションに署名したり、トランザクションをブロードキャストしたりすることは、この記事の範囲外です。興味のある学生は自分で勉強することができます。

これを読んだ後、いくつかの中心的な提案、セキュリティリスク、および HD ウォレットのニーモニックの基本原則について比較的よく理解できたと思います。まだ質問がある場合、または詳細を知りたい場合は、次の情報をよく読んでください。

もうひとつ

ブロックチェーン技術の出現は偶然ではありません。長い目で見れば、それはあなたの想像を超えて世界を変えるでしょう。ブロックチェーン業界に興味がある方、ブロックチェーンの方向性について楽観的である方、または当社のやり方を評価してくださる方は、北京とシアトルの両方でフロントエンドおよびバックエンドのエンジニアを引き続き大量に募集しています。チャットへようこそ。お仕事紹介はこちらをご覧ください。もちろん、履歴書を私に直接送っていただくことも可能です (WeChat: feweekly)。