JP2023548917A - 鍵導出方法 - Google Patents

鍵導出方法 Download PDF

Info

Publication number
JP2023548917A
JP2023548917A JP2023528164A JP2023528164A JP2023548917A JP 2023548917 A JP2023548917 A JP 2023548917A JP 2023528164 A JP2023528164 A JP 2023528164A JP 2023528164 A JP2023528164 A JP 2023528164A JP 2023548917 A JP2023548917 A JP 2023548917A
Authority
JP
Japan
Prior art keywords
key
child
target
blockchain
keys
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023528164A
Other languages
English (en)
Inventor
クロエ・タータン
ミカエラ・ペティット
アレッシオ・パガーニ
ウェイ・ジャン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nchain Holdings Ltd
Original Assignee
Nchain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nchain Holdings Ltd filed Critical Nchain Holdings Ltd
Publication of JP2023548917A publication Critical patent/JP2023548917A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

階層的鍵構造の鍵を導出するコンピュータによって実施される方法であって、方法が、第1の関係者によって実行され、目標の子鍵の目標のインデックスを生成するステップであって、目標のインデックスが、少なくとも目標のメッセージを第1のハッシュ関数に入力した第1の結果に基づいて生成される、ステップと、a)階層内の先行するレベルの親鍵、ならびにb)少なくともi)親鍵およびii)目標のインデックスを第2のハッシュ関数に入力した第2の結果に基づいて、鍵構造の階層内のレベルの目標の子鍵を導出するステップとを含む、コンピュータによって実施される方法。

Description

本開示は、外部状態から階層的鍵構造の子鍵(たとえば、プライベート鍵)を導出する方法に関する。たとえば、鍵は、ブロックチェーントランザクションに署名する、および/またはブロックチェーンアドレスを生成するために使用される場合がある。
ブロックチェーンテクノロジーの文脈において、通常、「ウォレットアプリケーション」または単に「ウォレット」は、とりわけ、特定の関係者によって所有される鍵(すなわち、公開鍵および/またはプライベート鍵)の集合を記憶するように構成されるアプリケーションを指す。
パブリックブロックチェーン上でプライバシーを保つためには、プライベート鍵から導出される公開鍵の再利用を避けることが推奨される。これは、ウォレットが、鍵が失われるまたは盗まれることがないことを保証するために安全に記憶され、頻繁にバックアップされる必要があるランダムに生成されたプライベート鍵の集合となることにつながり得る。鍵の再利用を避けることによって、このタイプのウォレットはすぐに「鍵の袋(bag of keys)」問題を生じ得る。
鍵の記憶および再生成の効率を向上させ、この鍵の袋問題を解決するために、階層的決定性(HD: hierarchical deterministic)ウォレットが発明された。HDウォレットは、プライバシーの点、およびウォレットのブランチを異なるシステムまたはサブシステムと共有する能力を有するという点で、さらなる利点をもたらす。このタイプのウォレットは、単一のランダムなシードから多くの鍵を生成することができ、現在使用されているブロックチェーンウォレットの最もありふれたタイプである。
ウォレットの実装は、概して、親鍵から複数の子鍵をどのようにして導出するべきかを説明するビットコイン改善提案32(BIP32)に従う。一部の実装は、ウォレット内のブランチの目的を定義するBIP44も使用する。HDウォレットの実装においては、マスタプライベート鍵が、ランダムなシードから導出される。このマスタプライベート鍵は、何世代もの鍵(子、孫など)を導出するために使用される。
図4は、HDウォレットに現れる結果的なツリー状構造を示す。このデータ構造は、ウォレットのセキュリティと、復旧中に資金を復元するその能力とを管理するための強力なメカニズムである。実装によっては、ユーザ(すなわち、ウォレットの所有者)またはオブザーバが、対応するプライベート鍵なしに公開鍵のシーケンスを作成することができる。より少ない秘密が記憶される必要があるので、露呈のリスクがより少ない。加えて、鍵が失われる場合に、それらの鍵が、シード鍵から復元され得る。
親鍵から子鍵を導出する式は、導出関数への入力として親の公開鍵が使用されるのかまたは親のプライベート鍵が使用されるのかに応じて決まり、親プライベート鍵の使用は、「強化された(hardened)」子鍵をもたらし、親公開鍵の使用は、「通常の」(すなわち、BIP32の用語に従えば、強化されていない(non-hardened))子鍵をもたらす。
子鍵は、子鍵導出(CKD)関数を使用して生成される。CKD関数の特定の形態は、特定のウォレットの実装に依存するが、概して、子鍵は、親鍵およびインデックスに基づく。インデックスは、親鍵が複数の子鍵を生み出すことを可能にする。すなわち、親鍵は複数の子鍵を持つ場合がある。通常、インデックスは、シーケンスの値をとり、親鍵の第1の子鍵がシーケンスの第1の値(たとえば、0)をとり、親鍵の第2の子鍵がシーケンスの次の値(たとえば、1)をとり、以下同様である。
本稿執筆時点では、親公開鍵およびチェーンコード(chain code)の知識のみを有する場合に、強化された子公開鍵を導出することはできないことに留意されたい。通常の子鍵に支払いを要求することは、受信者が親公開鍵(およびチェーンコード)のみを明かすことができ、送信者が複数の通常の(すなわち、強化されていない)子鍵を導出することによって支払いを送信することができることを意味する。このようにして、資金の受信者は、送信者に各アドレスを明示的に与える必要がない。これは、同じ2者間の通信を最小化し、パブリックブロックチェーン上で取引をするときのプライバシーを強化しながら、複数の支払いが送信され得ることを保証する。
通常の子プライベート鍵skiの式は、
ski = skpar + HMAC512L(cpar, pkpar || index) (1)
であり、強化された子プライベート鍵ski'の式は、
ski' = skpar + HMAC512L(cpar, skpar || index') (2)
であり、
・skparは、親のプライベート鍵であり、
・pkparは、親の公開鍵であり、
・
は、SHA512ハッシュ関数を使用するHMAC関数の結果の左32バイトであり、
・cparは、親鍵のチェーンコードであり、cpar = HMAC-SHA512R(cgrandparent, Pgrandparent || indexpar)として定義され、
・indexは、0から始まり、新しい子鍵が計算されるたびに増加する子鍵のカウンタである。慣例として、これは、通常の鍵に関して0≦index<231であり、強化された鍵に関して231≦index'<232である。
英国特許出願第1913667.0号
https://nchain.com/2019/10/22/benfords-wallet/ https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
「ベンフォードのウォレット(Benford's wallet)」(https://nchain.com/2019/10/22/benfords-wallet/および英国特許出願第1913667.0号参照)として知られるプロトコルが、プライバシーを高めるために使用され得る。この背景にある概念は、トランザクションの出力を複数の出力に分けることであり、値の分けは、これらの出力の十分に大きなデータセットの下でベンフォードの法則に従う。ウォレットの狙いは、同じ額の定期的な支払いが隠されるように、ウォレットが支払いの全額を難読化することである。しかし、監査人に支払いの全額を証明することができるように、ベンフォードのウォレットは、このようにして支払いを受ける公開鍵の計算に請求書(invoice)などの外部データが含められることを説明する。これは、請求書に関連するデータが記憶されなければならず、鍵の袋問題が再び持ち込まれることを意味する。
したがって、鍵の袋問題を再び持ち込むことなく、子鍵の導出に外部データを組み込むことが望ましい。
本明細書において開示される一態様によれば、階層的鍵構造の鍵を導出するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルの1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、第1の関係者によって実行され、目標の子鍵の目標のインデックスを生成するステップであって、目標のインデックスが、少なくとも目標のメッセージを第1のハッシュ関数に入力した第1の結果に基づいて生成される、ステップと、a)階層内の先行するレベルの親鍵、ならびにb)少なくともi)親鍵およびii)目標のインデックスを第2のハッシュ関数に入力した第2の結果に基づいて、階層内のレベルの目標の子鍵を導出するステップとを含む、コンピュータによって実施される方法が提供される。
本出願の発明者は、子鍵を外部データにリンクすることが有利であることに気付いた。外部データは、以下で概して「メッセージ」と呼ばれるが、このメッセージは、1人または複数の関係者の間の通信(たとえば、電子メール)の意味でのメッセージであるとは限らず、しかし、それは、除外されない。概して、メッセージは、任意のタイプのユーザまたは機械によって生成されたデータアイテムであってよい。メッセージは、インデックスを生成するために使用され、今度は、そのインデックスが、子鍵を導出するために使用される。すなわち、本発明の実施形態は、インデックスの性質を変更する - シーケンスの次の未使用の値をとる代わりに、インデックスは、今やメッセージのハッシュに基づく。
もはや、子鍵が請求書などの外部データにリンクされている証拠を第三者(たとえば、監査人)に提供することができるように、子鍵の導出に外部データが含められ得る。ベンフォードのウォレットとは異なり、ウォレットの復元は、HDウォレットのシードのみを必要とする。また、方法は、ユーザまたは異なるウォレットプロバイダによって実行されるいかなる余分な作業もない手間のかからないウォレットの移行を促進する。いかなる特定のウォレットプロトコルにも限定されないが、ソリューションは、BIP32で規定されたHDウォレットプロトコルを変更せず、その代わりに、鍵を導出するために使用されるインデックスにさらなる意味を与える。シードおよびメッセージを使用してウォレットデータファイルを決定的に(deterministically)導出することによって、ウォレットユーザにとって現在制限的であるウォレットの移行および復元の面で、いくつかの利点が得られる。これらが、以下で詳細に検討される。
本明細書において提供される例示的なユースケースは主にブロックチェーンに関連するものであるが、説明される実施形態は、任意の関連する状況における鍵の使用に広く当てはまることに留意されたい。たとえば、子鍵は、テクノロジーの多くの分野に応用されているデジタル署名を生成するためのプライベート鍵として使用されてよい。別の例として、子鍵は、任意の状況において暗号鍵として使用されてよい。
本開示の実施形態の理解を助け、そのような実施形態がどのようにして実施されてよいかを示すために、添付の図面が、例としてのみ参照される。
ブロックチェーンを実装するためのシステムの概略的なブロック図である。 ブロックチェーンに記録されてよいトランザクションのいくつかの例を概略的に示す図である。 クライアントアプリケーションの概略的なブロック図である。 図3Aのクライアントアプリケーションによって提示されてよい、例示的なユーザインターフェースの概略的なモックアップの図である。 HDウォレットの鍵のツリー状構造を概略的に示す図である。 子拡張(extended)プライベート鍵およびチェーンコードの生成を概略的に示す図である。 HDウォレットのための例示的な子鍵導出関数を概略的に示す図である。 本発明の一部の実施形態による例示的なシステムを概略的に示す図である。 ランダムな鍵インデックスを使用するときの外部データ階層的決定性(EDHD: external data hierarchical deterministic)ウォレット構造を概略的に示す図である - 図は、何らかの入力(すなわち、外部データ)に対してハッシュ関数が使用されるときに、ランダムな出力(すなわち、EDHDウォレットの鍵インデックス)がどのように生成されるかを示す。 ベンフォードの法則に従って生成されるトランザクションを概略的に示す図である。 鍵導出ブランチがデジタル証明書によって特徴付けられるEDHDウォレット構造の例を概略的に示す図である。
例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。
各ブロックチェーンノード104は、ピアのコンピュータ機器を含み、ノード104のうちの異なるノードは、異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などのその他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをも含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。
ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク106の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。そうではなく、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(下で検討される)を記憶する限り、ブロックチェーン150は、データを刈り込まれる場合がある。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルの種類に依存する。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを使用する。1つのよくある種類のトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、財産としてのデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされるユーザ103である(ロックを解除され、それによって、履行または消費されるためにはそのユーザの署名またはその他の解決策を必要とする)。各入力は、先行トランザクション152の出力を後ろ向きに指し示し、それによって、トランザクションをリンクする。
各ブロック151は、ブロック151までの連続的な順序を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。(コインベーストランザクション以外)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153までさかのぼる。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。
ブロックチェーンノード104の各々は、トランザクション152をその他のブロックチェーンノード104に転送し、それによって、トランザクション152をネットワーク106全体に伝播させるように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれらのブロックチェーンノード104のそれぞれのメモリに記憶するように構成される。また、各ブロックチェーンノード104は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられたセット(または「プール」)154を維持する。順序付けられたプール154は、多くの場合「メムプール(mempool)」と呼ばれる。本明細書におけるこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルにも限定するように意図されていない。この用語は、ノード104が有効であるものとして受け入れ、ノード104が同じ出力を消費しようとするいかなるその他のトランザクションも受け入れないことを義務付けられるトランザクションの順序付けられたセットを指す。
所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことを指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない(孤児(orphan)トランザクションに関する下の議論を参照されたい)。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。
現在のトランザクション152jの入力は、入力の認可、たとえば、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。そして今度は、現在のトランザクション152jの出力が、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行トランザクション152iの入力で定義された額を、現在のトランザクション152jの出力で定義されたように新しいユーザまたはエンティティ103bに送金することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、お釣りを渡すために元のユーザまたはエンティティ103aである可能性がある)の間で入力額を分けるために複数の出力を有する場合がある。場合によっては、トランザクションは、1つまたは複数の先行トランザクションの複数の出力からの金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することも可能である。
ビットコインのような出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの関係者103が新しいトランザクション152jを定めたいとき(手動で、または関係者によって使用される自動化プロセスによって、のいずれかで)、定める者は、そのコンピュータ端末102から受取人に新しいトランザクションを送信する。定める者または受取人は、最終的に、このトランザクションを(現在では概してサーバまたはデータセンターであるが、原理的にはその他のユーザ端末である可能性がある)ネットワーク106のブロックチェーンノード104のうちの1つまたは複数に送信する。また、新しいトランザクション152jを定める関係者103が、トランザクションをブロックチェーンノード104のうちの1つまたは複数に直接送信し、一部の例においては、受取人に送信しない可能性があることも除外されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、概して、新しいトランザクション152jの暗号署名が、トランザクション152の順序付けられたシーケンス内の前のトランザクション152iに依存する期待される署名と一致することをブロックチェーンノード104がチェックすることを要求する。そのような出力ベースのトランザクションプロトコルにおいて、これは、新しいトランザクション152jの入力に含まれる関係者103の暗号署名またはその他の認可が、新しいトランザクションが割り振る先行トランザクション152iの出力で定義された条件と一致することをチェックすることを含む場合があり、この条件は、概して、少なくとも、新しいトランザクション152jの入力の暗号署名またはその他の認可が、新しいトランザクションの入力がリンクされる前のトランザクション152iの出力のロックを解除することをチェックすることを含む。条件は、先行トランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義されてよい。代替的に、条件は、単にブロックチェーンノードプロトコルのみによって決められている可能性があり、またはこれらの組合せによる可能性がある。いずれにせよ、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106の1つまたは複数のその他のブロックチェーンノード104に転送する。これらのその他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用し、したがって、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送し、以下同様である。このようにして、新しいトランザクションは、ブロックチェーンノード104のネットワーク全体に伝播される。
出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り振られる(たとえば、消費される)かどうかの定義は、その出力がブロックチェーンノードプロトコルに従って別のオンワードトランザクション(onward transaction)152jの入力によって既に有効に履行されたかどうかということである。トランザクションが有効であるための別の条件は、それが履行しようと試みる先行トランザクション152iの出力が別のトランザクションによって既に履行されていないことである。やはり、有効でない場合、トランザクション152jは(警告のために無効であるものとしてフラグを立てられ、伝播されるのでない限り)伝播されず、ブロックチェーン150に記録されない。これは、トランザクションを行う者が同じトランザクションの出力を2回以上割り振ろうとする二重支払いを防ぐ。一方、アカウントベースのモデルは、アカウントの残高を維持することによって二重支払いを防止する。やはり、トランザクションの定義された順序が存在するので、アカウントの残高は、常に単一の定義された状態を有する。
トランザクションを承認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうとさらに競争する。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたプール154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスが保留トランザクションの順序付けられたプール154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他のパズルは除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード104において相当大量の処理リソースを消費する。
パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークのその他のブロックチェーンノード104によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード104は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード104の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード104の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に承認されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク106のブロックチェーンノード104の各々において認識され、維持されるので、修正され得ない。また、ブロックポインタ155は、ブロック151に連続的な順序を付与する。トランザクション152がネットワーク106の各ブロックチェーンノード104の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。
任意の所与の時間にパズルを解こうと競争している異なるブロックチェーンノード104は、それらのブロックチェーンノード104がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションのプール154の異なるスナップショットに基づいてそうしている場合があることに留意されたい。最初にそれらのそれぞれのパズルを解いた者は誰でも、どのトランザクション152が次の新しいブロック151nにどの順番で含まれるかを定義し、未公開のトランザクションの現在のプール154が、更新される。それから、ブロックチェーンノード104は、未公開のトランザクションの新たに定義された順序付けられたプール154からブロックを作成しようと競争を続け、以下同様である。発生する可能性があるすべての「フォーク(fork)」を解決するためのプロトコルも存在し、フォークは、ブロックチェーンの相反するビュー(view)がノード104の間で伝播されるように、2つのブロックチェーンノード104が互いに非常に短い時間内にそれらのブロックチェーンノード104のパズルを解く地点である。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最終的なブロックチェーン150となる。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであることに留意されたい。
ビットコインブロックチェーン(およびほとんどのその他のブロックチェーン)によれば、新しいブロック104を成功裏に構築するノードは、(ある額のデジタル資産を、あるエージェントまたはユーザから別のエージェントまたはユーザに送金する、エージェント間またはユーザ間トランザクションとは対照的に)追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、追加の認められた額のデジタル資産を新たに割り振る能力を付与される。この特別な種類のトランザクションは、通常「コインベーストランザクション」と呼ばれるが、「イニシエーション(initiation)トランザクション」または「生成(generation)トランザクション」と呼ばれる場合もある。この特別な種類のトランザクションは、概して、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクショが後で履行されることを可能にするプロトコルの規則に従うという、新しいブロックを構築するノードの意図を知らせる。ブロックチェーンプロトコルの規則は、この特別なトランザクションが履行される前に、満期期間(maturity period)、たとえば、100ブロックを必要とする場合がある。多くの場合、通常の(非生成(non-generation))トランザクション152は、トランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加の取引手数料も指定する。この手数料は、通常「取引手数料」と呼ばれ、下で検討される。
トランザクションの承認および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード104の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード104は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。
各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそのそれぞれの1つの役割または複数の役割を実行し、トランザクション152を処理するために、ブロックチェーンノード104の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード104に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行されてよいことが理解されるであろう。ノードソフトウェアは、アプリケーションレイヤの1つもしくは複数のアプリケーションに、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより下位のレイヤに、またはこれらの任意の組合せで実装されてよい。
ネットワーク101にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワーク106とインタラクションする場合があるが、トランザクションの承認、またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合がある。その他のユーザは、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。
関係者103の一部またはすべては、異なるネットワーク、たとえば、ブロックチェーンネットワーク106の上に重ねられたネットワークの一部として接続される場合がある。ブロックチェーンネットワークのユーザ(多くの場合「クライアント」と呼ばれる)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われる場合があるが、これらのユーザは、ブロックチェーンノードに必要とされる役割を果たさないので、ブロックチェーンノード104ではない。その代わりに、各関係者103は、ブロックチェーンネットワーク106とインタラクションし、それによって、ブロックチェーンノード106に接続すること(すなわち、通信すること)によりブロックチェーン150を利用してよい。例示を目的として、2人の関係者103およびそれらのそれぞれの機器102、すなわち、第1の関係者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の関係者103bおよびそのそれぞれのコンピュータ機器102bが示される。多くのさらなるそのような関係者103およびそれらのそれぞれのコンピュータ機器102が存在し、システム100に参加していてよいが、便宜上、それらは図示されていないことは理解されるであろう。各関係者103は、個人または組織である場合がある。純粋に例示のために、第1の関係者103aは、本明細書においてはAliceと呼ばれ、第2の関係者103bは、Bobと呼ばれるが、これは限定的でなく、AliceまたはBobに対する本明細書のすべての言及は、それぞれ「第1の関係者」および「第2の関係者」によって置き換えられてよいことが理解されるであろう。
各関係者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえば、1つまたは複数のCPU、GPU、その他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを含むそれぞれの処理装置を含む。各関係者103のコンピュータ機器102は、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに含む。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。各関係者103のコンピュータ機器102のメモリは、処理装置上で実行されるように配置された少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の関係者103に帰せられるすべてのアクションは、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実行されてよいことが理解されるであろう。各関係者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の関係者103のコンピュータ機器102は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの1つまたは複数のその他のネットワーク化されたリソースも含む場合がある。
クライアントアプリケーション105は、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103のコンピュータ機器102に提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。
クライアントアプリケーション105は、少なくとも「ウォレット」機能を含む。これは、2つの主な機能を有する。これらのうちの一方は、それぞれの関係者103が、トランザクション152を作成し、承認し(たとえば、署名し)、その後ブロックチェーンノード104のネットワーク全体に伝播され、それによって、ブロックチェーン150に含められるように1つまたは複数のビットコインノード104に送信することを可能にすることである。他方は、それぞれの関係者が現在所有しているデジタル資産の額の報告をその関係者に返すことである。出力ベースのシステムにおいて、この第2の機能は、問題にしている関係者に属する、ブロックチェーン150全体に散在する様々な152トランザクションの出力に定義された額を照合することを含む。
注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIによってインターフェースをとる、または1つがそれ以外に対するプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。
各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能なように結合される。これは、クライアント105のウォレット機能がネットワーク106にトランザクション152を送信することを可能にする。また、クライアント105は、それぞれの関係者103が受信者である任意のトランザクションに関してブロックチェーン150に問い合わせる(または実施形態において、ブロックチェーン150は、その公開された可視性(public visibility)によって部分的にトランザクションに対する信頼を提供する公共機関(public facility)であるので、ブロックチェーン150内のその他の関係者のトランザクションを確かに検査する)ためにブロックチェーンノード104に連絡することができる。各コンピュータ機器102のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を組み立て、送信するように構成される。上述のように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を承認し、ブロックチェーンネットワーク106全体にトランザクション152を伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは、互いに対応し、所与のトランザクションプロトコルが、所与のノードプロトコルと一緒になって、所与のトランザクションモデルを実装する。ブロックチェーン150のすべてのトランザクション152のために、同じトランザクションプロトコルが使用される。ネットワーク106のすべてのノード104によって同じノードプロトコルが使用される。
所与の関係者103、たとえば、Aliceが、ブロックチェーン150に含められるように新しいトランザクション152jを送信したいとき、その関係者103は、(その関係者103のクライアントアプリケーション105のウォレット機能を使用して)関連するトランザクションプロトコルに従って新しいトランザクションを組み立てる。そして、その関係者103は、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最良に接続されているブロックチェーンノード104である可能性がある。任意の所与のブロックチェーンノード104は、新しいトランザクション152jを受信するとき、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってその新しいトランザクション152jを処理する。これは、新しく受信されたトランザクション152jが「有効」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例は、まもなくより詳細に検討される。一部のトランザクションプロトコルにおいて、承認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能である場合がある。代替的に、条件は、単にノードプロトコルの組み込まれた特徴であるか、またはスクリプトとノードプロトコルとの組合せによって定義される可能性がある。
新たに受信されたトランザクション152jが有効とみなされるためのテストに合格することを条件に(すなわち、新たに受信されたトランザクション152jが「承認される」ことを条件に)、トランザクション152jを受信するすべてのブロックチェーンノード104は、そのブロックチェーンノード104において維持されるトランザクション154の順序付けられたセットに、新しい承認されたトランザクション152を追加する。さらに、トランザクション152jを受信するすべてのブロックチェーンノード104は、承認されたトランザクション152をネットワーク106の1つまたは複数のその他のブロックチェーンノード104に向かって伝播させる。各ブロックチェーンノード104が同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、トランザクション152jがネットワーク106全体にすぐに伝播されることを意味する。
所与のブロックチェーンノード104において維持される保留トランザクションの順序付けられたプール154に入れられると、そのブロックチェーンノード104は、新しいトランザクション152を含むそれらのそれぞれのプール154の最新バージョンに関するプルーフオブワークのパズルを解く競い合いを開始する(その他のブロックチェーンノード104はトランザクションの異なるプール154に基づくパズルを解こうとしている可能性があるが、誰であれ最初に成功する者が最新のブロック151に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたプール154の一部に関するパズルを解く)。新しいトランザクション152jを含むプール54に関してプルーフオブワークが行われると、順序付けられたセット154は、変更不可能であるようにしてブロックチェーン150のブロック151のうちの1つの一部となる。各トランザクション152は、それ以前のトランザクションに戻るポインタを含み、したがって、トランザクションの順序も変更不可能であるようにして記録される。
異なるブロックチェーンノード104は、最初に、所与のトランザクションの異なるインスタンスを受信し、したがって、1つのインスタンスが新しいブロック151で公開される前は、どのインスタンスが「有効」であるかについての相反するビューを有する可能性があり、1つのインスタンスが新しいブロック151で公開された時点で、すべてのブロックチェーンノード104は、公開されたインスタンスが唯一の有効なインスタンスであると合意する。ブロックチェーンノード104が1つのインスタンスを有効であるものとして受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されたことを発見する場合、そのブロックチェーンノード104は、これを受け入れなければならず、そのブロックチェーンノード104が最初に受け入れたインスタンス(すなわち、ブロック151で公開されなかったインスタンス)を破棄する(すなわち、無効であるものとして扱う)。
一部のブロックチェーンネットワークによって運用される代替的な種類のトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」のプロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムにおいて、トランザクションは、アカウントの実行中の取引勘定(running transaction tally)(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、送信者によって送信者の暗号署名の一部として署名され、トランザクション参照計算(transaction reference calculation)の一部としてハッシュされる。さらに、オプションのデータフィールドが、トランザクションに署名される場合もある。このデータフィールドは、たとえば、前のトランザクションIDがデータフィールドに含まれる場合、前のトランザクションを後ろ向きに指し示す場合がある。
UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は、1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、すべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルは、ビットコインに関連して説明されるが、その他の例示的なブロックチェーンネットワークに同様に実装されてよいことに留意されたい。
UTXOベースのモデルにおいて、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を含むデータ構造を含む。各出力203は、未使用トランザクション出力(UTXO)を含んでよく、UTXOは、(UTXOが既に履行されていない場合)別の新しいトランザクションの入力202のソースとして使用され得る。UTXOは、デジタル資産の額を指定する値を含む。これは、分散台帳上のトークンの設定された数を表す。UTXOは、情報の中でもとりわけ、そのUTXOが由来するトランザクションのトランザクションIDも含んでよい。トランザクションデータ構造は、入力フィールド202および出力フィールド203のサイズのインジケータを含む場合があるヘッダ201も含んでよい。ヘッダ201は、トランザクションのIDも含んでよい。実施形態において、トランザクションIDは、(トランザクションID自体を除く)トランザクションデータのハッシュであり、ノード104に提出される生のトランザクション152のヘッダ201に記憶される。
Alice103aが、問題にしているデジタル資産の額をBob103bに送金するトランザクション152jを作成したいものとする。図2において、Aliceの新しいトランザクション152jは、「Tx1」とラベル付けされている。トランザクション152jは、シーケンス内の先行トランザクション152iの出力203においてAliceにロックされているデジタル資産の額を取得し、このうちの少なくとも一部をBobに送金する。先行トランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、任意のラベルであるに過ぎない。それらは、必ずしも、Tx0がブロックチェーン151の最初のトランザクションであることも、Tx1がプール154内のすぐ次のトランザクションであることも意味しない。Tx1は、Aliceにロックされた未使用の出力203をまだ持っている任意の先行する(すなわち、先祖)トランザクションを後ろ向きに指し示す可能性がある。
先行トランザクションTx0は、Aliceが自身の新しいトランザクションTx1を作成するときに、または少なくともAliceがその新しいトランザクションTx1をネットワーク106に送信するまでに、既に承認され、ブロックチェーン150のブロック151に含められている可能性がある。先行トランザクションTx0は、そのとき、既にブロック151のうちの1つに含められている可能性があり、または順序付けられたセット154内でまだ待っている可能性があり、その場合は、先行トランザクションTx0は、すぐに新しいブロック151に含められる。代替的に、Tx0およびTx1は、一緒に作成され、ネットワーク106に送信される可能性があり、またはノードプロトコルが「孤児」トランザクションをバッファリングすることを許す場合、Tx0がTx1の後に送信される可能性さえある。本明細書においてトランザクションのシーケンスの文脈で使用される用語「先行」および「後続」は、トランザクションにおいて指定されたトランザクションポインタによって定義されるシーケンス内のトランザクションの順序(どのトランザクションがどのその他のトランザクションを後ろ向きに指し示すかなど)を指す。それらの用語は、「先任者」および「後任者」、または「先祖」および「子孫」、「親」および「子」などによって等しく置き換えられる可能性がある。それは、必ずしも、それらのトランザクションが作成される、ネットワーク106に送信される、または任意の所与のブロックチェーンノード104に到着する順序を示唆しない。しかしながら、先行トランザクション(先祖トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまで、また承認されない限り、承認されない。その親の前にブロックチェーンノード104に到着する子は、孤児とみなされる。その子は、ノードプロトコルおよび/またはノードの挙動に応じて、廃棄されるか、または親を待つために特定の時間バッファリングされる場合がある。
先行トランザクションTx0の1つまたは複数の出力203のうちの1つは、ここではUTXO0とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが承認され、したがって、UTXOが成功裏に履行されるために後続のトランザクションの入力202内のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。概して、ロックスクリプトは、額を特定の関係者(そのロックスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、概して、後続のトランザクションの入力のロック解除スクリプトが先行トランザクションがロックされている関係者の暗号署名を含むという条件を含むロック解除条件を定義する。
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で記述されたコード片である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、どの情報がトランザクション出力203を消費するために必要とされるか、たとえば、Aliceの署名の必要を指定する。ロック解除スクリプトは、トランザクションの出力に現れる。ロック解除スクリプト(別名scriptSig)は、ロックスクリプトの基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で記述されたコード片である。たとえば、ロック解除スクリプトは、Bobの署名を含む場合がある。ロック解除スクリプトは、トランザクションの入力202に現れる。
したがって、図示された例において、Tx0の出力203のUTXO0は、UTXO0が履行されるために(厳密には、UTXO0を履行しようと試みる後続のトランザクションが有効であるために)Aliceの署名Sig PAを必要とするロックスクリプト[Checksig PA]を含む。[Checksig PA]は、Aliceの公開-プライベート鍵のペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、(たとえば、実施形態においてはトランザクションTx0全体のハッシュであるTx0トランザクションID、TxID0によって、)Tx1を後ろ向きに指し示すポインタを含む。Tx1の入力202は、Tx0の任意のその他の可能な出力の中でUTXO0を特定するために、Tx0内のUTXO0を特定するインデックスを含む。Tx1の入力202は、さらに、Aliceが鍵ペアからの自身のプライベート鍵をデータの予め定義された部分(暗号技術においては「メッセージ」と呼ばれることがある)に適用することによって作成されたAliceの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにAliceによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義される場合がある。
新しいトランザクションTx1がブロックチェーンノード104に到着するとき、ノードは、ノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトにおいて定義された条件(この条件は1つまたは複数の基準を含む場合がある)を満たすかどうかをチェックすることを含む。実施形態において、これは、2つのスクリプトを連結すること、すなわち、
<Sig PA> <PA> || [Checksig PA]
を含み、「||」は、連結を表し、「<...>」は、スタックにデータを置くことを意味し、「[...]」は、ロックスクリプト(この例においては、スタックベースの言語)によって含まれる関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順々に実行されてよい。いずれにせよ、一緒に実行されるとき、スクリプトは、Tx0の出力のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx1の入力のロック解除スクリプトがデータの期待される部分に署名するAliceの署名を含むことを認証する。データの期待される部分自体(「メッセージ」)も、この認証を実行するために含められる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、平文のデータの署名された部分を指定する別個の要素は、それが既に本質的に存在するので含められる必要がない)。
公開-プライベート暗号技術による認証の詳細は、当業者によく知られているであろう。基本的に、Aliceが自身のプライベート鍵を使用してメッセージに署名した場合、Aliceの公開鍵および平文のメッセージがあれば、ノード104などの別のエンティティは、そのメッセージがAliceによって署名されたに違いないことを認証することができる。署名は、通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって、公開鍵のすべての保有者が署名を認証することを可能にする。したがって、特定のデータまたはトランザクションの一部などに署名することへの本明細書におけるすべての言及は、実施形態においては、そのデータまたはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
Tx1のロック解除スクリプトがTx0のロックスクリプトにおいて指定された1つまたは複数の条件を満たす場合(したがって、図示された例では、Aliceの署名がTx1において提供され、認証される場合)、ブロックチェーンノード104、はTx1を有効とみなす。これは、ブロックチェーンノード104が、Tx1を保留トランザクションの順序付けられたプール154に追加することを意味する。また、ブロックチェーンノード104は、トランザクションTx1がネットワーク106全体に伝播されるように、ネットワーク106の1つまたは複数のその他のブロックチェーンノード104にトランザクションTx1を転送する。Tx1が承認され、ブロックチェーン150に含められると、これは、Tx0からのUTXO0を使用済みとして定義する。Tx1は、未使用トランザクション出力203を消費する場合にのみ有効であり得ることに留意されたい。Tx1が別のトランザクション152によって既に消費された出力を消費しようと試みる場合、Tx1は、たとえすべてのその他の条件が満たされるとしても無効となる。したがって、ブロックチェーンノード104は、先行トランザクションTx0の参照されたUTXOが既に消費されているかどうか(すなわち、そのUTXOが別の有効なトランザクションへの有効な入力を既に形成したかどうか)をチェックする必要もある。これは、ブロックチェーン150がトランザクション152に定義された順序を付与することが重要である理由の1つである。実際には、所与のブロックチェーンノード104は、どのトランザクション152のどのUTXO203が消費されたかを示す別個のデータベースを維持する場合があるが、結局、UTXOが消費されたかどうかを定義するのは、それがブロックチェーン150内の別の有効なトランザクションへの有効な入力を既に形成したかどうかということである。
所与のトランザクション152のすべての出力203において指定された総額が、そのトランザクション152のすべての入力202によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効の別の根拠となる。したがって、そのようなトランザクションは、伝播されず、ブロック151に含められることもない。
UTXOベースのトランザクションモデルにおいて、所与のUTXOは、丸ごと使用される必要があることに留意されたい。所与のUTXOは、UTXOにおいて使用済みとして定義された額の一部分を「残しておく」ことができない一方で、別の部分が消費される。ただし、UTXOからの額は、次のトランザクションの複数の出力の間で分けられ得る。たとえば、Tx0のUTXO0において定義された額が、Tx1の複数のUTXOの間で分けられ得る。したがって、Aliceは、BobにUTXO0において定義された額のすべてを与えたくない場合、残りを使ってTx1の第2の出力において自分自身にお釣りを与えるかまたは別の関係者に支払いをすることができる。
実際には、Aliceは、通常さらに、ブロック151に自分のトランザクション104を成功裏に含めるビットコインノード104への手数料も含める必要がある。Aliceがそのような手数料を含めない場合、Tx0は、ブロックチェーンノード104によって拒否される場合があり、したがって、厳密に言えば有効であるが、伝播されず、ブロックチェーン150に含められない場合がある(ノードプロトコルは、ブロックチェーンノード104が望まない場合に、ブロックチェーンノード104にトランザクション152を受け入れるように強制しない)。一部のプロトコルにおいて、取引手数料は、それ自体の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。その代わりに、所与のトランザクション152の入力202によって指し示される総額と出力203において指定される総額との間のすべての差が、そのトランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1が1つの出力UTXO1のみを有するものとする。UTXO0において指定されたデジタル資産の額がUTXO1において指定された額よりも大きい場合、UTXO1を含むブロックを作成するプルーフオブワークの競争に勝つノード104によって差が割り振られてよい。しかし、代替的または追加的に、取引手数料がトランザクション152のUTXO203のうちのそれ自体のUTXO203において明示的に指定される可能性があることは、必ずしも除外されない。
AliceおよびBobのデジタル資産は、ブロックチェーン150の任意の場所の任意のトランザクション152においてAliceおよびBobにロックされたUTXOから成る。したがって、典型的には、所与の関係者103の資産は、ブロックチェーン150全体の様々なトランザクション152のUTXO全体に散在している。ブロックチェーン150のどこにも、所与の関係者103の総残高を定義する1つの数字は記憶されていない。それぞれの関係者にロックされ、別のオンワードトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を照合することは、クライアントアプリケーション105内のウォレット機能の役割である。ウォレット機能は、ビットコインノード104のいずれかに記憶されたブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。
スクリプトコードは、概略的に表現されることが多い(つまり、正確な言語を使用しない)ことに留意されたい。たとえば、特定の機能を表現するためにオペレーションコード(オペコード)を使用する場合がある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの始めにOP_FALSEが先にあるとき、トランザクション内にデータを記憶することができ、それによって、ブロックチェーン150にデータを変更不可能であるようにして記録することができるトランザクションの消費不可能な出力を作成するScript言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を含む可能性がある。
概して、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。一部の実施形態において、所与のトランザクションに関して、署名は、トランザクション入力の一部と、トランザクション出力の一部またはすべてに署名する。署名が署名する出力の特定の部分は、SIGHASHフラグに応じて決まる。SIGHASHフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名する時点で決まっている)4バイトのコードである。
ロックスクリプトは、概してそれがそれぞれのトランザクションがロックされている関係者の公開鍵を含むという事実を示して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、通常、それが対応する署名を供給するという事実を示して、「scriptSig」と呼ばれることがある。しかし、より広く、UTXOが履行されるための条件が署名を認証することを含むことは、ブロックチェーン150のすべての応用において必須ではない。より広く、スクリプト言語が、任意の1つまたは複数の条件を定義するために使用される可能性がある。したがって、より広い用語「ロックスクリプト」および「ロック解除スクリプト」が、好ましい場合がある。
サイドチャネル
図1に示されたように、AliceおよびBobのコンピュータ機器102a、120bの各々のクライアントアプリケーションは、追加の通信機能を含む場合がある。この追加の機能は、Alice103aが、(どちらかの関係者または第三者の勧めによって)Bob103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別にデータのやりとりを可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、関係者の一方がトランザクション152をネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されていない、またはチェーン150に向かって進んでいない状態で、AliceとBobとの間でトランザクション152をやりとりするために使用される場合がある。このようにしてトランザクションを共有することは、「トランザクションテンプレート(transaction template)」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる1つまたは複数の入力および/または出力を欠いている場合がある。代替的または追加的に、サイドチャネル107は、鍵、交渉された額または条項、データ内容などの任意のその他のトランザクション関連データをやりとりするために使用される場合がある。
サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立されてよい。代替的または追加的に、サイドチャネル301は、モバイルセルラネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはAliceおよびBobのデバイス102a、102bの間の直接有線もしくは無線リンクなどの異なるネットワークを介して確立されてよい。概して、本明細書のどこで言及されるサイドチャネル107も、「オフチェーン」、すなわち、ブロックチェーンネットワーク106とは別でデータをやりとりするための1つまたは複数のネットワーキングテクノロジーまたは通信媒体を介した任意の1つまたは複数のリンクを含んでよい。2つ以上のリンクが使用される場合、オフチェーンリンクの束または集合が全体としてサイドチャネル107と呼ばれる場合がある。したがって、AliceおよびBobがサイドチャネル107を介して特定の情報またはデータなどをやりとりすると言われる場合、これは、これらのデータすべてがまったく同じリンクまたはさらには同じ種類のネットワーク上で送信されなければならないことを必ずしも示唆しないことに留意されたい。
クライアントソフトウェア
図3Aは、今開示されている方式の実施形態を実施するためのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を含む。トランザクションエンジン401は、上で検討された方式に従っておよびまもなくさらに詳細に検討されるように、トランザクション152を組み立てること、サイドチャネル301を介してトランザクションおよび/もしくはその他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて伝播するように1つもしくは複数のノード104にトランザクションを送信することなどの、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。
UIレイヤ402は、機器102のユーザ出力手段を介してそれぞれのユーザ103に情報を出力すること、および機器102のユーザ入力手段を介してそれぞれのユーザ103から返ってくる入力を受け取ることを含め、それぞれのユーザのコンピュータ機器102のユーザ入力/出力(I/O)手段を介してユーザインターフェースを提供するように構成される。たとえば、ユーザ出力手段は、視覚的出力を提供するための1つもしくは複数のディスプレイスクリーン(タッチスクリーンもしくは非タッチスクリーン)、音声出力を提供するための1つもしくは複数のスピーカ、および/または触覚的出力を提供するための1つもしくは複数の触覚出力デバイスなどを含む可能性がある。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーン(出力手段に使用されるものと同じもしくは異なる)、マウス、トラックパッド、もしくはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、スピーチもしくは発声入力を受け取るための1つもしくは複数のマイクロフォンおよび音声もしくは声認識アルゴリズム、手もしくは体のジェスチャの形態の入力を受け取るための1つもしくは複数のジェスチャベースの入力デバイス、または1つもしくは複数の機械式ボタン、スイッチ、もしくはジョイスティックなどの入力アレイ(input array)を含む可能性がある。
注:本明細書における様々な機能は同じクライアントアプリケーション105に統合されるものとして説明される場合があるが、これは、必ずしも限定的ではなく、その代わりに、それらの機能は、たとえば、一方が他方に対するプラグインであるか、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースをとる、2つ以上の異なるアプリケーションのスイートに実装される可能性がある。たとえば、トランザクションエンジン401の機能は、UIレイヤ402とは別個のアプリケーションに実装されてよく、またはトランザクションエンジン401などの所与のモジュールの機能は、2つ以上のアプリケーションの間で分けられる可能性がある。説明される機能の一部またはすべてが、たとえば、オペレーティングシステムレイヤに実装される可能性があることも排除されない。本明細書の任意の箇所で単一のまたは所与のアプリケーション105などへの言及がなされる場合、これは単なる例示であり、より広く、説明された機能は任意の形態のソフトウェアで実装される可能性があることが理解されるであろう。
図3Bは、Aliceの機器102aのクライアントアプリケーション105aのUIレイヤ402によってレンダリングされる場合があるユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、Bobの機器102bのクライアント105b、または任意のその他の関係者の機器のクライアントによってレンダリングされてよいことは理解されるであろう。
例示として、図3Bは、Aliceの観点でUI500を示す。UI500は、ユーザ出力手段を介して異なるUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を含んでよい。
たとえば、UI要素は、異なる画面上のボタン、またはメニューの異なる選択肢などである場合がある1つまたは複数のユーザが選択可能な要素501を含んでよい。ユーザ入力手段は、ユーザ103(この場合、Alice103a)が、画面上のUI要素をクリックもしくはタッチするか、または所望の選択肢の名前を言うことによるなどして、選択肢のうちの1つを選択するかまたはそれ以外の方法で操作することを可能にするように配置される(本明細書において使用される用語「手動」は、自動と対照を成すことを意図されているに過ぎず、必ずしも1つの手または複数の手の使用に限定されないことに注意されたい)。選択肢は、ユーザ(Alice)が、実施形態によって子鍵を導出するときに使用されるメッセージを選択することを可能にする。
代替的または追加的に、UI要素は、1つまたは複数のデータ入力フィールド502を含んでよく、それらのデータ入力フィールド502を通じて、ユーザは、実施形態によって子鍵を導出するときに使用されるメッセージを入力することができる。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえば、画面上にレンダリングされ、データは、ユーザ入力手段、たとえば、キーボードまたはタッチスクリーンを通じてフィールドに入力され得る。代替的に、データは、たとえば、音声認識に基づいて口述でデータを受け取る可能性がある。
代替的または追加的に、UI要素は、ユーザに対して情報を出力するための1つまたは複数の情報要素503の出力を含んでよい。たとえば、これ/これらは、画面上にまたは聞こえるようにレンダリングされる可能性がある。
様々なUI要素をレンダリングし、選択肢を選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能は、まもなくより詳細に検討される。図3に示されたUI500は図式化されたモックアップであるに過ぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を含む場合があることも理解されるであろう。
HDウォレット
BIP32
BIP32仕様に準拠したHDウォレットプロトコルは、2つのコアメカニズム、すなわち、
1.鍵の導出 - 単一のシードから鍵ペアのツリーを導出するためのシステム。
2.派生パス(derivation path) - そのようなツリーの上にウォレット構造を定義する。
を詳述する。
以下で、BIP32プロトコルによるHDウォレットの作成に含まれるステップの概要を提供する。完全な検討に関しては、https://github.com/bitcoin/bips/blob/master/bip-0032.mediawikiを参照されたい。
鍵の導出
I.バイナリシードを生成する。ユーザは、まず、シードS、通常は12単語のフレーズ(128～512ビット)を選択する。BIP39に概説されている仕様が、ニーモニックコード(mnemonic code)からバイナリシードを生成するためによく使用される。ユーザは、自分のニーモニックをパスフレーズで保護すると決める場合もある(さらなる詳細に関してはBIP39参照)。
II.マスタ拡張プライベート鍵を生成する。マスタプライベート鍵mは、以下のようにシードから導出される。
1.
を計算し、式中、opadは、値0x5cの繰り返されるバイトからなる128バイトのサイズの外側パディング(outer padding)であり、ipadは、値0x36の繰り返されるバイトからなる128バイトのサイズの内側パディング(inner padding)である。
2.Iを2つの32バイトのシーケンス、ILおよびIRに分ける。
3.parse256(IL)使用して、32バイトのシーケンスを(最上位バイトが最初に来る)256ビット数のマスタ拡張プライベート鍵mとして解釈し、IRを256ビット数のマスタチェーンコードとして解釈する。
III.子拡張プライベート鍵を生成する。親拡張鍵および鍵インデックスiが与えられれば、対応する子拡張鍵を計算することができる。公開およびプライベート親鍵から公開子鍵を導出するための追加的なCKD関数に関しては、BIP32を参照されたい。子プライベート鍵skiは、親プライベート鍵skparおよびそれらの対応するチェーンコードcparから、関数
CKDpriv((skpar, cpar), i)→(ski, ci) (3)
を使用して導出される。関数CKDprivを実行するとき、以下のステップが行われる。
1.鍵インデックスi≧231であるかどうか、すなわち、子が強化された鍵であるかどうかをチェックする。
i. はい=>強化された子の場合、関数
I = HMAC_SHA512(Key = cpar, Data = 0x00 || ser256(skpar) || ser32(i))
を使用し、式中、ser256(skpar)は、整数skparを32バイトのシーケンスとしてシリアル化し、ser32(i)は、32ビットの符号なし整数iを最上位バイトが最初に来る4バイトのシーケンスとしてシリアル化する。
ii. いいえ=>通常の子の場合、関数
I = HMAC_SHA512(Key = cpar, Data = serP(skpar・G) || ser32(i))
を使用し、式中、serP(skpar・G)は、座標ペアskpar・G = (x, y)をSEC1の圧縮された形態、すなわち、(0x02または0x03) || ser256(x)を使用してバイトシーケンスとしてシリアル化し、ヘッダバイトは、省略されたy座標のパリティに応じて決まる。
2.Iを2つの32バイトのシーケンス、ILおよびIRに分ける。
3.返される子鍵ski = parse256(IL) + skpar(mod n)。
4.返されるチェーンコードci = IR。
このプロセスは、図5に概略的に示される。
IV.拡張鍵フォーマットをシリアル化する。拡張公開(xpub)または拡張プライベート(xprv)鍵は、78バイトのデータ構造
[マジック(magic)][深さ(depth)][親のフィンガープリント][鍵インデックス][チェーンコード][鍵]
のbase58で符号化されたシリアル化である。個々のデータ要素の説明は、Table 1(表1)にまとめられている。
親のフィンガープリントは、ウォレットソフトウェアにおいて親および子ノードを検出するための高速な方法であることに留意されたい。内部的には、完全な160ビットの識別子が、フィンガープリントにおけるすべてのハッシュの衝突に対処するために使用される可能性がある。
base58表現に変換する前に(ダブルSHA-256(double SHA-256)チェックサムから導出された)32ビットのチェックサムがまず追加され、これは、メインネットで「xprv」もしくは「xpub」で始まるかまたはテストネットで「tprv」もしくは「tpub」で始まるかのどちらかの最大112文字の文字列をもたらす。
シリアル化されたxpubをインポートするとき、実装は、公開鍵データのX座標が曲線上の点に対応するかどうかも検証しなければならない。公開鍵データのX座標が曲線上の点に対応しない場合、拡張公開鍵は無効とみなされる。
派生パス
32ビットの鍵インデックスiは、通常の鍵に関して0x00から0x7fffffffまで(0から231 - 1まで)、強化された鍵に関して0x80000000から0xffffffffまで(231～232)の範囲である。下付き文字表記(ih)、またはより普通にはプライム記号が、強化された鍵を示すために使用される。ブロックチェーンの開発者は、通常、Unicodeのプライム記号ではなく、ASCIIのアポストロフィーを使用する。たとえば、第1の通常の鍵(0x00)は、i = 0であり、第1の強化された鍵(0x80000000)は、i' = 0'である。
図6は、BIP32仕様から抜粋された概略図で子鍵派生パスを示す。派生パスは、「/」によって区切られたn個の鍵インデックスのnタプルとして定義される。BIP32 HDウォレットに関して、パスは、3つのレベルまたは深さからなり(m/i/j/k)、
m / account' / change / address_index
として定義される。
マスタプライベート鍵mの後の第1のレベルiは、開示されるBIP32ウォレット構造を包含する。ここで、鍵空間は、たとえば、組織の異なる部門のための通常の銀行口座と同様に、ユーザが自分の資金を異なる「アカウント」に整理することができるように分けられ得る。デフォルトのアカウントは、番号0'(強化された鍵インデックス)であり、連続的に増やされる。
第2のレベルjにおいて、各アカウントは、2つの鍵ペアチェーン、すなわち、内部鍵ペアチェーンおよび外部鍵ペアチェーンから構成される。外部鍵チェーン(一定のインデックスj = 0)は、新しい公開受信アドレスを生成するために使用され、一方、内部鍵チェーン(一定のインデックスj = 1)は、アドレスの変更または外部に伝達される必要がないすべてのことなどのすべてのその他の動作のために使用される。
最後のレベルkは、インデックス0から付番され、連続的に増加するアドレスを表す。
BIP43 - 目的フィールド
BIP32で定義されたツリー構造のフィールドを標準化するために、BIP43仕様(https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)が導入された。特に、BIP43仕様は、マスタ鍵に続く第1のレベルを特別な目的のフィールドとして再定義する。派生パスは、
m / purpose' / *
として定義され、*は、目的フィールドのデータに応じた後続のレベルを表す。これがゼロに設定される場合(i = 0')、これがデフォルトのBIP32ウォレット構造であるので、派生パスにさらに2つのレベルが存在すると予想することができる。
BIP44 - マルチアカウント階層
目的フィールドが44'に設定されているBIP43のアプリケーションは、BIP44(https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)によれば、あらかじめ定義された5層ツリー構造に対応する。特に、それは、HDウォレットの異なるブランチ内で複数のコインを扱うことを導入し、デフォルト値は、ビットコインに割り振られている(j = 0')。ここで、派生パスは、
m / purpose' / coin_type' / account' / change / address_index
として定義される
アドレスギャップ限度(address gap limit)
BIP44は、アカウントの発見を目的としたアドレスギャップ限度の概念を導入する。ウォレットのソフトウェアは、ある限度を超えた連続する未使用アドレスの検索を止めるようにプログラミングされ得る。これは、アドレスインデックスが連続的に増やされるからである。ギャップ限度は、標準化されておらず、多くの場合、ユーザが構成可能である。通常、ギャップ限度は、20個の鍵に設定されるが、一部のウォレットは、100個の鍵または1000個もの鍵の限度を設定する。ギャップ限度は、親子鍵ではなく兄弟鍵にのみ適用されることに留意されたい。標準的な派生パスが使用されると仮定すると、検索は、2レベルの深さに制限されることが多い。
アカウントの発見
ユーザが外部ソースから自分のシードをインポートするとき、ウォレットのソフトウェアは、以下の方法でアカウントを発見するためにアドレスギャップ限度を使用することができる。
1.インデックス= 0と設定する。
2.インデックスに対応するアカウントのノードを導出する。
3.このアカウントの外部チェーンノードを導出する。
4.外部チェーンのアドレスをスキャンし、ギャップ限度を守る。
5.外部チェーン上でトランザクションが見つからない場合、発見を停止する。
6.いくつかのトランザクションが存在する場合、アカウントインデックスを1増やし、ステップ2から繰り返す。
内部チェーンは、関連する外部チェーンから来るコインを受け取るだけなので、ブロックチェーンのスキャンは、外部チェーンのみを含む。ウォレットソフトウェアは、ユーザが新しいアドレスを生成することによって外部チェーンのギャップ限度を超えようとしているとき、警告をするべきである。
ウォレットの復元
異なるウォレットプロバイダは、ウォレットの復旧中に資金を復元するために異なるプロトコルを備えている。取引所にHDウォレットサービスを提供する企業は、数千の未使用の連続したアドレスを容易に持つことができ、概して、BIP44において開示されたギャップ限度を無視し得る。それらは、その代わりに、すべての生成されたアドレスのリストを保持し、HDウォレットのデータ構造ではなくそれらのアドレスを個々にインデックス付けする。このようにして、知られているトランザクションのキャッシュを保持することは、ユーザがソフトウェアにログインするたびにブロックチェーンに再問い合わせする必要をなくし、軽量クライアントがほんの一握りのノードでそれらのユーザ収容能力をスケールアップすることも可能にしながら、プロセスをより時間効率的にする。
UTXOまたはトランザクション全体を追跡するウォレットプロバイダは、この情報をウォレットサーバに記憶する傾向がある。フルノードに依拠するHDウォレットが、トランザクションの完全なインデックスを保持することができる一方、サーバのシステムは、新しいアドレスごとに付加されるランニングインデックス(running index)を維持する可能性が高い。公開されるあらゆるブロックに関して、ウォレットソフトウェアは、新しいブロック内の各トランザクションをウォレットサーバ内の各アドレスと照合する。このプロセスは、あらかじめインデックス付けされたデータを使用して、および/またはブルームフィルタの助けを借りてより効率化される。
子鍵の導出
本発明の実施形態は、階層的鍵構造の子鍵を導出する新規の方法を提供する。概して、階層的鍵構造は、複数のレベルを含み、各レベルは、先行するレベルの少なくとも1つの鍵にリンクされる1つまたは複数の鍵を含む。これに対する例外は、マスタ鍵を含む、通常はマスタレベルと呼ばれる本当に最初のレベルである。マスタ鍵は、通常、任意のデータであってよいシードから導出される。マスタレベルの後に、1つまたは複数の子レベルがある。第n-1のレベルの鍵は、第nのレベルの1つまたは複数の子鍵の親鍵である場合がある。同様に、第nのレベルの鍵は、第n-1のレベルの親鍵の子鍵であると同時に、第n+1のレベルの1つまたは複数の子鍵の親鍵でもある場合がある。所与のレベルのすべての鍵が、親鍵でなければならないわけではない。たとえば、鍵構造は、マスタ鍵に遡る鍵の多くのブランチを有していてよい。一部のブランチは、その他のブランチよりも長い場合があり、つまり、それらのブランチは、その他のブランチよりも高い(すなわち、より大きい、より遠い、またはより深い)レベルに属する鍵を含む。
図7は、本発明の実施形態を実装するための例示的なシステム700を示す。システムは、鍵構造の1つまたは複数の子鍵を導出するように構成された鍵導出エンティティ701を含む。BIP32が鍵構造を導出するための例示的なプロトコルとして提供されるが、鍵導出エンティティ701は、そのプロトコルに準拠する鍵を導出することに限定されない。たとえば、鍵導出エンティティ701によって導出される鍵の長さは、BIP32によって必要とされる長さと異なってよい。逆に、鍵導出エンティティ701は、あらゆる要件においてBIP32に確かに準拠する鍵を導出する場合がある。さらに、鍵導出エンティティ701によって導出された鍵は、ブロックチェーントランザクションに署名するための署名鍵として、またはブロックチェーンアドレスとして使用するため、たとえば、pay-to-public-keyハッシュ(P2PKH)アドレスのための公開鍵として使用されるとは限らない。
一部の例において、鍵導出エンティティ701は、図1から図3を参照して説明されたように、Alice 103a(または実際にはBob 103b)に帰せられる動作の一部またはすべてを実行するように構成されてよい。システムは、ブロックチェーンネットワーク106の1つまたは複数のノード104を含んでよい。追加的または代替的に、システムは、1つまたは複数の第三者702、たとえば、ユーザ、組織、機械などを含んでよい。一部の例においては、少なくとも1つの第三者702が、図1から図3を参照して説明されたように、Alice 103a(または実際にはBob 103b)に帰せられる動作の一部またはすべてを実行するように構成されてよい。
鍵導出エンティティ701は、1つまたは複数の親鍵を含む既存の鍵構造を有する。マスタ鍵は、1つまたは複数の子鍵に対する親鍵である。鍵構造のより深いレベルに属する1つまたは複数の子鍵は、それら自体が1つまたは複数の子鍵の親鍵である場合がある。たとえば、子鍵の親は、それ自体がマスタ鍵の子鍵である場合がある。代替的に、鍵導出エンティティ701は、初めて鍵構造を生成し、生成された鍵構造は、少なくとも1つの親鍵を含む。鍵構造は、シードに基づいて生成される。特に、マスタ鍵が、シードに基づいて生成され、すべてのその他の鍵は、少なくとも間接的にマスタ鍵から導出される。
鍵導出エンティティ701は、その鍵導出エンティティ701が鍵構造の子鍵にリンクしたいメッセージを有する。メッセージは、任意のタイプの外部データであってよい。ここで、外部データは、子鍵を導出するために通常必要とされないデータを意味する。たとえば、親鍵は、子鍵を導出するために常に必要とされるので外部データとして分類されない。外部データの例は、通信メッセージ(テキスト、電子メールなど)、個人識別子(たとえば、名前、生年月日、住所、パスポート番号など)、請求書、テキスト文書(たとえば、法律文書)などを含む。
メッセージは、インデックスを導出するために使用され、今度は、そのインデックスが、子鍵を導出するために使用される。インデックスは、メッセージのハッシュに基づく(すなわち、その関数である)。言い換えると、メッセージが、ハッシュ化され、結果が、インデックスを生成するために使用される。一部の例においては、結果がインデックスである。その他の例においては、インデックスを生成するために結果に対して1つまたは複数の追加の演算が実行される。追加の演算の例は、必要に応じて、ハッシュ結果を特定のサイズのインデックスに変換するために使用されてよいモジュロ演算である。ハッシュ結果を特定のサイズに変換するために、その他の演算が実行される場合があることも、排除されない。たとえば、4バイトのインデックスが必要とされる場合、ハッシュ結果の最初の4バイトを選択される場合がある。別の選択、たとえば、最後の4バイトをとることが行われる場合がある。
任意のハッシュ関数(たとえば、SHA256)が、メッセージをハッシュするために使用されてよい。一部の例においては、2つ以上のハッシュ関数がメッセージに適用される場合があり、および/または所与のハッシュ関数がメッセージに2回以上適用される場合がある。
インデックスを生成した後、鍵導出エンティティ701は、親鍵およびインデックスに基づいて(すなわち、それらの関数として)子鍵を導出する。より詳細には、子鍵は、親鍵と、少なくとも親鍵およびインデックスのハッシュとに基づく。つまり、概して、子鍵skiは、
ski = f(skpar, hash(skpar, i))
として導出され、式中、f( )は、子導出関数であり、skparは、親鍵である。通常、skiはプライベート鍵を表すが、その他のタイプの鍵、たとえば、公開鍵が使用される場合があることに留意されたい。
一部の例において、子鍵は、親鍵およびハッシュ結果を合計すること、すなわち、
ski = skpar + hash(skpar, i)
によって導出され、式中、+は、楕円曲線加算(elliptic curve addition)を表す。
ハッシュ関数は、任意のハッシュ関数であってよく、インデックスを生成するために使用されるハッシュ関数と同じであってよく、または同じでなくてよい。一部の例において、子鍵は、ハッシュ結果の一部(すなわち、構成要素)に基づく場合がある。たとえば、ハッシュ結果は、鍵導出エンティティ701によって必要とされる鍵サイズよりも大きい場合がある。その場合、鍵導出エンティティ701は、ハッシュ結果の一部(たとえば、左nバイト)をとり、その部分を子鍵として使用する場合がある。(次に検討される)鍵を導出するためにチェーンコードが必要とされる例においては、ハッシュ結果の別の部分(たとえば、残りの部分)が、子鍵のチェーンコードとして使用される場合がある。
子鍵は、親鍵のチェーンコードcparの関数、すなわち、
ski = f(skpar, hash(skpar, cpar, i))
である場合がある。
概して、鍵構造の鍵は、親鍵およびハッシュ結果に基づいて導出される(ハッシュ結果は、親鍵およびインデックスと、この例においては、親鍵のチェーンコードとに基づく)。子鍵のチェーンコードは、ハッシュ結果の一部であり、ハッシュ結果のその他の部分は、子鍵自体を導出するために使用される。チェーンコードは、子鍵がその親鍵に直接依存しないことを保証する追加されたエントロピーである。
子鍵を導出した後、鍵導出エンティティ701は、(インデックスを生成するために使用された)メッセージを記憶するかまたはメッセージを破棄するかを選択してよい。同様に、特定の目的で子鍵を使用した後、鍵導出エンティティ701は、子鍵(および/もしくはチェーンコード)を記憶するかまたはそれを廃棄するかを選択してよい。
上述のように、任意の好適なハッシュ関数が、子鍵を生成するために使用されてよい。特定の例として、ハッシュ関数は、HMAC関数、たとえば、HMAC-512であってよい。必要とされる鍵長に応じて、その他のHMACが使用されてよい。HMACは、2つの入力をとる。例として、一方の入力は、親チェーンコードであってよく、他方の入力は、親鍵およびインデックスを連結したものであってよい。たとえば、親鍵を一方の入力とし、インデックスと連結されたチェーンコードを他方の入力とする、または親鍵を一方の入力とし、インデックスを他方の入力とする、入力のその他の組合せが使用される場合がある。
当業者であれば、公開・プライベート鍵ペアについて熟知しているであろう。簡潔に言えば、プライベート鍵に関数、たとえば、生成元(generator point)の楕円曲線乗算(elliptic curve multiplication)を適用することによって公開鍵が生成される。鍵導出エンティティ701は、プライベート鍵または公開鍵を生成するために、説明された技術を使用してよい。
一部の例において、子鍵を導出するために使用される親鍵は、プライベート鍵である。結果として得られる子鍵も、プライベート鍵である。そのような鍵は、強化された鍵と呼ばれることが多く、
skchild = skparent + HMAC-SHA512L(cparent, skparent || index)
によって与えられる場合がある。ハッシュ関数は、その他の形態をとる場合があることに留意されたい。
その他の例において、子鍵を導出するために使用される親鍵は、公開鍵である。この場合、子鍵は、親鍵と、ハッシュ結果に対応する公開鍵とに基づいて導出される。つまり、ハッシュ結果が、公開鍵に変換され、子鍵は、その公開鍵に基づく、すなわち、
pkchild = pkparent + HMAC-SHA512L(cparent, pkparent || index)・G
であり、式中、・Gは、生成元による楕円曲線乗算を表す。
さらにその他の例においては、ハッシュ関数の外の親鍵が、プライベート鍵である場合があり、ハッシュ関数に入力される親鍵が、公開鍵である場合がある。結果として得られる子鍵は、プライベート鍵である。そのような鍵は、強化されていない鍵と呼ばれることが多く、
skchild = skparent + HMAC-SHA512L(cparent, pkparent || index)
によって与えられる場合がある。
鍵導出エンティティ701は、子プライベート鍵に対応する公開鍵、たとえば、
pkchild = skchild・G
を導出してよい。
非対称暗号方式の鍵であるのではなく、代わりに、鍵は、対称方式の鍵である場合がある。
概して、鍵導出エンティティ701によって導出された子鍵は、任意の好適なアプリケーション、たとえば、メッセージの暗号化および復号化のために使用されてよい。たとえば、子公開鍵が、メッセージを暗号化するために使用されてよく、または子プライベート鍵が、対応する子プライベート鍵で暗号化されたメッセージを復号するために使用されてよい。子鍵が対称鍵である場合、メッセージを暗号化し、復号するために同じ子鍵が使用されてよい。
子鍵は、デジタル署名を生成するために使用されてもよい。すなわち、子鍵は、メッセージおよびプライベート鍵に基づいてデジタル署名を生成するために使用されるプライベート鍵であってよい。署名は、対応する公開鍵を使用して検証されてよい。
子鍵が使用されてよい1つのアプリケーションは、ブロックチェーントランザクションに関連している。たとえば、子鍵は、たとえば、P2PKまたはP2PKH出力を使用してブロックチェーントランザクションの出力がロックされる公開鍵である場合がある。鍵導出エンティティ701は、子鍵にロックされている出力を含むトランザクションを生成してよい。代替的に、鍵導出エンティティ701は、子鍵を第三者702に提供してよく、その第三者702が、子鍵にロックされた出力を含むトランザクションを生成してよい。鍵導出エンティティ701は、子鍵自体、または子鍵に基づくブロックチェーンアドレス、たとえば、子鍵のハッシュを第3者702に提供してよい。トランザクションを生成することは、少なくとも1つのフィールドを欠いているトランザクションテンプレートを生成することを含む場合があることに留意されたい。トランザクションテンプレートは、誰がトランザクションテンプレートを生成したかに応じて、完成のために第三者702または鍵導出エンティティ701に渡されてよい。それから、完全なトランザクションが、ブロックチェーンネットワーク106に送信されてよい。
ブロックチェーンが子公開鍵にロックされたトランザクションを含む場合、鍵導出エンティティ701は、その出力を参照し、ロックを解除するように構成される入力を含むトランザクションを生成してよい。入力は、対応する子プライベート鍵を使用して生成された署名を含んでよい。参照される出力のロックスクリプトに応じて、入力は、子公開鍵も含んでよい。
鍵導出エンティティ701は、メッセージに基づいて子鍵が生成されたことを第三者702に証明したい、または証明することを要求される場合がある。リンクを証明するために必要な情報は、子鍵がどのように導出されたかに依存する。少なくとも、親鍵およびメッセージが必要とされる。鍵導出エンティティ701は、たとえば、第三者702が既に親鍵またはメッセージにアクセスすることができるかどうかに応じて、一方または両方のデータアイテムを第三者702に送信してよい。たとえば、親鍵は、第三者702に知られている公開鍵である場合がある。第三者702は、メッセージに基づいて、すなわち、少なくともメッセージをハッシュすることによってインデックスを生成してよい。それから、親鍵およびインデックスがハッシュされ、子鍵を導出するために親鍵と組み合わされてよい。子鍵が親鍵のチェーンコードを使用して導出される場合、第三者702は、鍵導出エンティティ701によって提供される場合があるチェーンコードの知識も必要とする。
任意の機能として、鍵導出エンティティ701は、デジタル証明書を鍵構造に埋め込む場合がある。デジタル証明書は、認証局によって関係者に発行され、データアイテムが特定の関係者に属するかまたはそれ以外の方法で関連することを証明する。この場合、デジタル証明書は、鍵導出エンティティ701(または少なくとも鍵導出エンティティ701を運用する関係者)に発行される。デジタル証明書は、鍵が鍵導出エンティティ701に属することを証明する可能性がある。証明される鍵は、鍵構造の鍵、たとえば、マスタ鍵である場合がある。デジタル証明書は、デジタル証明書に基づいて子鍵のインデックスを生成することによって鍵構造に埋め込まれてよい。言い換えると、子鍵のインデックスを生成するために使用されるメッセージが、デジタル証明書を含んでよい。デジタル証明書は、鍵の所有者(すなわち、鍵導出エンティティ701)もしくは資金の送信者に属する場合があり、および/または、たとえば監査上の理由から請求書と請求書を支払う人との間のリンクを作成するために、証明書に加えてメッセージを含む場合がある。鍵を証明することが、アイデンティティ(identity)の暗号学的証明を提供する一方、デジタル証明書を(インデックスを介して)鍵導出関数に埋め込むことは、アイデンティティの暗号学的証明を提供しないが、それは、たとえば、監査目的で鍵と誰かのアイデンティティとの間のリンクを作成する。
追加的または代替的に、マスタ鍵が、証明される鍵であってよい。すなわち、マスタ鍵は、証明されてよいが、鍵構造に埋め込まれるとは限らない。鍵が証明されている関係者は自分のプライベート鍵を明かしたくないので、認証される鍵は、通常、公開鍵であることに留意されたい。これは、鍵の所有者のアイデンティティをウォレットにリンクすることによって、HDウォレットを介して請求書を監査するという考え方に全体的なソリューションを提供する。
ここで子鍵の導出に戻ると、鍵導出エンティティ701は、複数の異なる子鍵を導出する場合がある。各子鍵は、上記のように導出されてよい。すなわち、各子鍵は、それぞれのインデックスに基づいて導出されてよく、そのインデックスは、メッセージに基づく。一部の例においては、それぞれの新しく導出される子鍵のために異なるメッセージが使用される。代替的に、異なる鍵のために同じメッセージが使用される場合がある。しかし、その場合、どの2つの子鍵も同じでないことを保証するために、子鍵は異なる親鍵を持っていなければならない。
子鍵の一部が、同じ親鍵を持つ場合がある。すなわち、説明された技術を用いて導出された子鍵の一部は、鍵構造の同じレベルで導出され、同じ親鍵にリンクされる場合がある。子鍵の一部が、異なる親鍵を持つ場合があるが、異なる親鍵は、それらの子鍵が同じレベルに属するように鍵構造の同じレベルに属する。子鍵の一部が、鍵構造の異なるレベルに属する親鍵を持つ場合がある。この場合、メッセージに基づいて直接導出された子鍵は、鍵構造の異なるレベルに存在する。新しく導出される子鍵の一部が前に導出された子鍵の子である場合があることも、排除されない。すなわち、メッセージに基づいて直接導出された子鍵が、やはりそれぞれのメッセージに基づいて直接生成される1つまたは複数の子鍵の親である場合がある。
一部の例においては、同じ親鍵に基づいて複数の子鍵を導出するとき、同じメッセージが、インデックスを生成するために使用される場合があるが、メッセージは、異なるデータアイテムと連結されるかまたはその他の方法で組み合わされてよい。すなわち、インデックスは、メッセージおよびデータアイテムのハッシュに基づく。データアイテムは、追加の子鍵ごとにインクリメントされるカウンタ値であってよい。たとえば、第1の子鍵のインデックスは、第1のカウンタ値(たとえば0)と連結されたメッセージのハッシュであってよく、第2の子鍵のインデックスは、第2のカウンタ値(たとえば1)と連結されたメッセージのハッシュであってよく、以下同様である。
その他の例においては、異なる子鍵のインデックスを生成するために使用されるそれぞれのメッセージが、同じより大きなメッセージ全体のそれぞれの部分であってよい。たとえば、メッセージ全体が、いくつかのチャンクに分けられてよく、メッセージの各チャンクが、それぞれの子鍵を導出するために使用されるそれぞれのインデックスを生成するために使用される。
一部のその他の例においては、インデックスがメッセージのハッシュに基づく子鍵が、たとえば、BIP32と同様に、シーケンスのインクリメント値を使用するという通常の意味でそれぞれのインデックスが生成される1つまたは複数の子鍵の親である場合がある。これらの例において、鍵導出エンティティ701は、メッセージに基づいて、鍵構造の単一のレベルのみの子鍵を導出することを選択する場合がある。
鍵導出エンティティ701は、複数の子鍵のうちの1つまたは複数を第三者702に送信する場合がある。鍵導出エンティティ701は、追加的または代替的に、複数の子鍵の各々に関してそれぞれのブロックチェーンアドレスを生成し、それらのアドレスを第三者702に送信する場合がある。アドレスは、1つまたは複数のトランザクションテンプレート、たとえば、各アドレスにつき1つのテンプレートに含まれる場合がある。
鍵導出エンティティ701は、それぞれが導出された子鍵のうちの1つにロックされた少なくとも1つの出力を有する(トランザクションテンプレートである場合がある)1つまたは複数のブロックチェーントランザクションを生成してよい。各トランザクションは、子鍵のうちのそれぞれの子鍵にロックされた単一の出力を含む場合があり、または1つもしくは複数のトランザクションは、子鍵のうちのそれぞれの子鍵にロックされた2つ以上の出力を含む場合がある。鍵導出エンティティ701は、ブロックチェーンネットワークまたは第三者702にトランザクションを送信してよい。トランザクションおよびそれらのトランザクションの出力の数は、英国特許出願第1913667.0号に記載された技術に基づいてよい。
説明された実施形態のさらなる特定の例が、以降で検討される。
外部データHDウォレット
HDウォレットの鍵の導出に外部データ(ED)を含める新しい方法(「EDHDウォレット」)を開示する。外部メッセージをプライベート・公開鍵ペアの計算に明示的に含める代わりに、外部メッセージがHDウォレット内の鍵派生パスのインデックスにマッピングされることを開示する。
ユーザ(すなわち、鍵導出エンティティ701)は、外部データに依存する鍵のためにのみ使用されるHDウォレットを割り当てるか、またはブランチ全体を外部データに対応する鍵専用とすることによって既存のウォレットに外部データを組み込むかのどちらかが可能である。図6の例において、ブランチは、マスタノード(すなわち、マスタ鍵)から始まって左から右へ伸びる。たとえば、図6に示される1つのブランチは、以下のノード、すなわち、m、m/0、m/0/0、m/0/0/0から構成される。別のブランチは、以下のノード、すなわち、m、m/i、m/i/1、m/i/1/1から構成される。
たとえば、派生パスがBIP44に従う場合、ユーザは、そのブランチのすべての導出された子鍵にアカウントに関連する外部データを組み込むために、アカウントインデックス(深さ3)を選択する可能性がある。代替的に、ブランチ内でアドレスインデックス(深さ5)を個々の請求書に関連付ける可能性がある。以下で、HDウォレットの異なる深さで、および異なるブランチに沿って、外部データを組み込むことの意味あいを探る。
ウォレット内の特定の鍵を導出するために、以下の計算を開示する。公開鍵に関するフィンガープリントを残すために使用したいメッセージがあると仮定して、まず、メッセージmのハッシュ(たとえば、SHA256ハッシュ関数を使用する)のモジュロ232、
index = hash(m) mod 232 (4)
を計算し、その結果、これが、HDウォレットの導出において子鍵のインデックスとしてその後使用され得る。ハッシュされたメッセージのモジュロ232は、SHA256ハッシュ関数の結果の右4バイトによって与えられることに留意されたい。鍵を復元する目的で、結果を範囲0≦index<232に制限する。これはBIP32ウォレットに固有のものであり、その他のプロトコルに関しては、可能なインデックス値の異なる範囲が選択される場合があることに留意されたい。たとえば、インデックスが5バイトによって与えられる範囲の値をとることができる場合、インデックスは、index = hash(m) mod 240によって与えられる。
次いで、通常の鍵および強化された鍵に関してそれぞれ式(1)または式(2)として定義される、このメッセージに依存する鍵を選択する。ここでは、HDウォレットプロトコルを変更しておらず、インデックスに意味を与えているだけであることに注意されたい。
HDウォレットプロトコルにおいては、最大231までのインデックスが、通常の鍵のために予約され、231を超えるインデックスが、強化された鍵のために使用されることに留意されたい。範囲を232に制限することを選択したので、このプロトコルにおいて、子鍵が強化されているかまたは通常であるかの可能性は等しい。強化された鍵が欲しいのかまたは通常の鍵が欲しいのかを明示的に選択したい場合は、単純に、インデックスの計算を、通常の鍵に関して、
index = hash(m) mod 231 (5)
強化された鍵に関して、
index' = (hash(m) mod 231) + 231 (6)
となるように修正する。これらの範囲は、インデックスが常に正確に32ビットの長さであるので、バイナリ表現において、通常の鍵インデックスが常に0から始まり、一方、強化された鍵インデックスは常に1から始まることを意味する。以上で、外部データを特定の鍵にどのようにしてマッピングすべきかの説明を終わる。
図8は、このようにして鍵インデックスを生成するときの結果として得られるウォレット構造を示す。一部のデータのハッシュは予測不可能な出力を生成するので、EDHDウォレットの鍵インデックスは、通常のHDウォレットの場合のように順次インクリメントされるのではなくランダムに生成される。
外部データの監査
上記の例示的な定義に基づいて、商業者(鍵導出エンティティ701の例)は、年間20億個を超える請求書を生成するための空間を有する。これは、年間およそ数億台のデバイスを販売する場合がある、たとえば、デスクトップおよびラップトップコンピュータ、タブレット、スマートフォン、ならびにスマートスピーカを製造する大規模な消費者向けデバイス企業または「巨大テクノロジー企業」にとって十分すぎるほどである。大企業は、毎年、その課税年度のそれらの会計監査を完了すると、新しいEDHDウォレットを作成する可能性がある。
鍵ペアの計算に外部データを導入する理由の1つは、監査目的で外部データとデジタル鍵との間の証明可能なリンクを提供することであることを思い出されたい。この場合に、子鍵が外部データから導出されることを証明するためには、子鍵の導出に使用されたインデックスを監査人(たとえば、第三者702)に提供する必要がある。これは、HMAC512関数の原像(preimage)を共有することを必要とし、したがって、親鍵も共有されなければならない。強化された鍵に関して、これは、親プライベート鍵を共有することを意味するが、そのような共有はブロックチェーンの規格において勧められておらず、我々は、これが行われないことを推奨する。この問題を解決する1つの手法は、単純に、すべての鍵が容易に監査され得るように、EDHDウォレットが通常の鍵のみを含むことを課すことである。これは、式(5)に示されたように、結果の範囲を通常の鍵だけを含むように制限することによって行われる。
第2の手法は、強化された鍵の監査を簡略化するためにBIP32の手順を変更することである。これはベンフォードのウォレットで実証されており、HMAC256の計算に請求書メッセージを含めるために追加のステップが追加された。この方法は、公開鍵と請求書との間に証明可能なリンクを作成するが、子鍵が親鍵にリンクされることを証明するために使用され得ない。
第3の手法は、HDウォレットプロトコルが安全であると仮定することである。事実上、これは、HDウォレットがどのように導出されるかには業界標準があり、誰もこれを変更し得ないことを意味する。現在、(ウォレットソフトウェアに記憶されるが、オンチェーントランザクションには現れない)HDウォレットの鍵のシリアル化フォーマットには、その鍵の親鍵からのその鍵の導出に関してその鍵に対応するインデックスを示す4バイトを含む。このインデックスが正しいと仮定し得る場合、この位置に与えられたインデックスが正しい外部データに対応することを検証することによって、強化された鍵が監査されることが可能である。この仮定は、ウォレットプロバイダがその評判を維持するために正直に行動するインセンティブを与えられるという期待にもつながっている。
概して、監査人の要件は、暗号学的証明の要件よりもはるかに低い。結局のところ、監査人は商業者によって提供された請求書が有効であるという何らか形態の証拠を必要とするだけである。強化された鍵を持つEDHDウォレットを使用することは、商業者に、特定の請求書に関連する自分の公開鍵を特定するための手段をやはり与える。商業者は、これらを請求書と一緒に監査人に与え、出力値が合計で請求書の値になるので、監査人にそれらの有効性を十分に納得させることができる。したがって、監査目的で上記の提案された手法のいずれかを採用したいかどうかは、ユーザの裁量に委ねられる。
開示したソリューションは、HDウォレットが監査され得るようにHDウォレットが外部データに依存することを可能にする。とりわけ、このソリューションは、紛失した場合に、関連する外部データを知る必要なしに鍵が復元されることを依然として可能にする。
ギャップ限度の制限
EDHDウォレットプロトコルは、すべてのプライベート/公開鍵ペアがシードのみから再生成され得るHDウォレットの復元の利点を採用する。ウォレットが失われないことを保証するために、シードを安全に記憶する(またはセキュリティのためにシードをシェア(share)に分け、シェアを分散させる)ことができる。ウォレットの鍵を再生成するために、ほとんどのウォレットの実装は、BIP44のガイドラインに従って通常20に設定されているアドレスギャップ限度に達するまで、ウォレットサーバに記憶されたUTXOセット(ユーザの取引履歴を保存することはブロックチェーンをスキャンする必要をなくす)を検索する。これは、支払いを受けていない20個の連続したアドレスが存在する場合、ウォレットソフトウェアが検索プロセスを停止し、ウォレット内にさらなる鍵が存在しないとみなすことを意味する。
法人向けHDウォレットのユーザのAliceが、20個の受信アドレスを生成し、自分のクライアントに配布する(ギャップ限度20に関して可能な最大)シナリオを考える。Aliceは、自分のクライアントからの支払いを待っているが、それらのクライアントの誰もAliceの支払い要求に応じず、Aliceは、幾人かの新しい潜在的なクライアントのためにさらなるアドレスを生成する必要がある。
ユーザがこのようにして立て続けに20個のアドレス生成する場合、ウォレットソフトウェアは、21番目に生成されたアドレスが最初に戻り、1番目に生成されたアドレスを再利用するようにプログラミングされなければならない。
通常の状態では、アドレスは再利用されず、あらゆる支払いに新しいアドレスが割り当てられる。これは、安全なデジタル鍵管理のための暗号技術のベストプラクティスに従ったものである。
上記のこの単純な例は、アドレスギャップ限度を実装するウォレットの中核的な要件である連続したアドレス生成の制限的な性質を強調する。しかし、ウォレットのソフトウェアは、暗号セキュリティにおけるトレードオフによってこの問題を回避することができる。
アドレスギャップ限度は、各ウォレットプロバイダの復元プロセスの違いが原因で、異なるウォレットサービス間でシードを移行するときに依然として問題となる。結果として、ユーザが新しいウォレットプロバイダを使用すると決定する場合、ウォレットサーバ内のアドレスの追跡が機能しない可能性がある。したがって、ギャップ限度の制限的な性質は、ウォレットの移行が可能であるかどうかを事前に調査する必要があるユーザにとって厄介であると判明し得る。
EDHDウォレットの復元
ここで、EDHDウォレットおよび請求書の集合を持つ商業者を考える。商業者は、信頼できる第三者702によって自分のシードをバックアップし、日常業務に自分のウォレットを使用する。商業者が自分のウォレットデータファイルを失うが、請求書はまだ持っている場合、商業者は、自分のバックアップされたシードおよび請求書のセットを使用して、ベンフォードEDHDウォレット(Benford-EDHD wallet)の場合のどの公開鍵または鍵のどのセットが各請求書のために使用されたかを直ちに特定することができる。
商業者がウォレットデータファイルと請求書との両方を失う場合、ウォレットの復元は、チェックすべきものが232個のインデックスのリストだけであるので、どの公開鍵が使用されたかを総当たりでチェックすることによって依然として可能である。すなわち、商業者は、すべての可能なアドレスを生成し、それらのアドレスのいずれかに支払われたUTXOが存在するかどうかをチェックしてよい。すべての請求書が失われる場合、EDHDウォレットのすべての鍵の完全な復元は、ソフトウェアが4バイトの範囲のすべてのアドレスを検索するようにアドレスギャップ限度を解除することを必要とすることに留意されたい。セキュリティの点では、請求書を漏洩することは、商業者にとって不利益にならないいくらかのプライバシーが失われことになるだけなので、請求書自体は、ウォレットのシードほど安全でなくてもよい。
導出されるべきインデックスのリストが存在するように、子鍵の導出に使用された外部データを記憶するというさらなる選択肢がある。BIP39によって説明されたように、インデックスを明示的に記憶するか、または各インデックスに対応するニーモニックを記憶する可能性がある。このデータが侵害される場合、攻撃者は、派生パスの親鍵を知らない限り、特定のアドレスまたはトランザクションを特定する術はない。請求書に対応する外部データの場合、これらは、監査の目的で、いずれにしても記憶されなければならず、外部データを記憶するのための余分な作業はない。
ウォレットの移行の点では、ウォレットデータファイルがシードおよび請求書から決定的に導出されるという事実が、ウォレット間の移行を非常に簡単にする。これは、鍵を計算するために使用されたインデックスが知られているか、または請求書から計算され得るからである。これは、必要とされるデータがシードおよび請求書だけであり、それ以外のすべて(すなわち、鍵の再生)は決定的についてくるからである。これは、現在、上述のように鍵派生パスの違いが原因で、異なるウォレットプロバイダから自分のシードを移行したいユーザにとって厳しい制限となっている。
特徴および利点
ウォレットデータファイルがシードおよび請求書(またはより広く、その他の外部データ)から決定的に導出されるとき、ウォレットユーザが現在得られないいくつかの特有の利点が生じる。上述のように、これらのうちの1つは、異なるウォレットプロバイダ間を簡単に移行する能力である。もうひとつは、鍵が何らかの連続した順序で使用されたかどうかに依存する代わりに、請求書を使用して鍵を生成したので、今や、資金を受け取る前に鍵を特定することができることである。本発明の実施形態は、以下の例のうちのいずれか1つまたは複数を提供するために利用され得る。
・スケーラブル - 通常のHDウォレットの連続的性質によって制限されない。
・カスタマイズ可能 - 異なる目的のための外部データを含めるさらなる柔軟性。
・復元可能 - トランザクションおよび請求書がシードのみから復元され得る。
・相互運用可能 - 異なるウォレットプロバイダ間のデータの簡単な転送。
・監査可能 - ウォレット内の鍵を特定し、構造化する新規の方法を提示する。
理論上のベンチマーキング
ここで、外部データのための我々の開示されたインデックス付けソリューションを使用するときの、ウォレットの復元に関連する問題および潜在的なハッシュの衝突のリスクに応えて、一連の理論的分析を提供する。明記されていない限り、以後の理論的検討は、4つの仮定に基づく。
a)アドレスギャップ限度を知らない、
b)鍵派生パスを知らない、
c)アドレスを生成するために常にP2PKHスクリプトしか使用しない、および
d)ウォレットサーバに記憶されているUTXOセット全体にアクセスすることができる
ウォレットの復元
EDHDウォレットで使用されるプライベート・公開鍵ペアの復元は、2つのステップを含む。
1.すべての可能な派生パスを使用してすべての可能な鍵を生成する、および
2.どの鍵がアクティブであるか(未使用トランザクションに関連付けられている鍵)を検証する
以下で、2つの手法、すなわち、アカウント/インデックス総当たりおよびメッセージ総当たりを使用してウォレットのすべての可能な鍵を総当たりするための計算複雑性を分析する。
アカウント/インデックス総当たり
理論上は、派生パスに新しいレベルを追加することによって、無限の数の鍵が生成され得る。アクティブな鍵の特定においては、最初の3レベルが決まっているBIP44が使用されると仮定する。たとえば、ビットコインの場合、最初の3レベルは、m/44'/0'であり、その後に、account(強化されたアドレスのみ)、change(常に0)、およびaddress indexが続く。このため、この手法を使用してウォレットを総当たりすることは、派生パスのすべての可能なアカウントおよびインデックスを探索することを必要とする。
アクティブな鍵の検索を中断するためにアドレスギャップ限度を使用しない場合、すべての可能なアカウント(31ビット、すなわち、約20億個のアカウント)を総当たりする必要がある。各アカウントは、32ビットの鍵、すなわち、約40億個のアドレスインデックス、約20億個の強化された鍵、および約20億個の通常の鍵を有する。したがって、20億個のアカウントの各々に関して、40億個のアドレスを生成し、それから、どれがUTXOセット内の未使用トランザクションを有するかをチェックしなければならない。
バニティアドレス(vanity address)を検索するために使用される「期待鍵検索レート(expected keysearch rate)」をベンチマークとすると、最新のGPUは、毎秒1500万個から20億個までの鍵(Mkey/s)を処理することができると仮定し得る。したがって、アカウント毎に40億個の可能な鍵を生成するのに必要とされる時間は、2秒から5分(鍵の数/GPUの処理能力)である。
それから、各鍵に関して、それがUTXOセット内の未使用トランザクションを有するかどうかを検証し、UTXOセットがRAMに記憶されており、したがって、テストが非常に迅速に済むと仮定して、鍵の生成およびUTXOのチェックのプロセス全体が、使用されるGPUに応じて5秒から5分を必要とすると推定する。すべての可能なインデックスを探索しなければならないので、アクティブなアドレスの数を知っていない限り、1個のアクティブなアドレスを検索していようが、1000個のアクティブなアドレスを検索していようが、このプロセスを完了する時間は一定である(アクティブなアドレスの数を知っている場合は、その数が達せられたとき早期停止を行うことができる)。
アカウントに関するいかなる情報も知らないと仮定したので、(231ビットで構成される)アカウント空間もすべて探索しなければならない。したがって、約20億個の可能なアカウントに対して総当たりプロセスを繰り返さなければならない。最速のGPU(約40億個のアドレスインデックスを総当たりするのに5秒)を用いて、1アカウントあたり5秒必要とし、したがって、約20億個のアカウントを探索することは、約340年を必要とする。
たとえば、100個のGPUを並列に実行することによってプロセスを並列化する場合、時間は、3.4年まで短くなる可能性がある1つのそのようなGPUは、3年間の電気代を除いて2000ポンドから3000ポンドかかり得るので、それは、1つのウォレットを復元するためには大きな投資であり、おそらく、ユーザのほとんどにとって実行不可能であることに留意されたい。
20個の非アクティブなアドレスというギャップ限度を再び持ち込む場合、総当たりプロセスは5秒よりもはるかに迅速になり、それが1アカウントあたり1ミリ秒未満で済むと支障なく仮定し得る。すべてのアカウントに関してこれをテストしたい場合、1ミリ秒×20億個の可能なアカウントで、合計約25日を必要とする。
ギャップ限度がアカウントの生成にも導入される場合、20億の可能なアカウントすべてではなく、おそらく、数百個のアカウントをチェックしさえすればよい。この場合、プロセス全体が1秒程度で完了され得る。これは、より高いギャップ限度(たとえば、100)に関してさえも同様であることに留意されたい。
鍵の総当たりの例
ここで、2つの広く使用されているGPUを使用してHDウォレットの鍵を総当たりするのに必要とされる時間を比較する。第1の実験においては、高レベルのGPU、GeForce RTX 2080 SUPER(2000Mkey/s)を検討し、第2の実験においては、中レベルのGeForce GTX 780 Ti(50Mkey/s)を検討した。「サイズ」列は、ランダムに生成された派生パスの鍵インデックスビットの総数を指す(たとえば、派生パスの1つの深さは32ビットであり、2つの深さは64ビットであるなど)ことに留意されたい。検討の結果が、Table 2(表2)に示される。
計算は、単一の32ビットの鍵インデックスが、どちらのタイプのGPUを使用しても容易に総当たりされ得ることを示す(上記の我々の例では2秒または85秒)。これは、選択されたインデックス、すなわち、アドレスインデックスまたはアカウントとは無関係であることに留意されたい。
しかし、2つのインデックス(たとえば、アドレスインデックスとアカウントとの両方)がランダムに生成されるときは、それはより複雑である。実際、アドレスインデックス(32ビット)にアカウント(32ビット)を足すと合計サイズ64ビットとなり、これは、トップレベルのGPUを使用するときでさえ、計算コストが高すぎて総当たりすることができない。これは、どの公開鍵が有効な未使用トランザクションを有するかをチェックする時間を除いて、すべての鍵を生成するだけで292年を必要とする。
ハイブリッドソリューションは、インデックスの一部の部分空間のみをランダムに作成することである可能性がある。たとえば、アカウントインデックスが、残りのビットが決定的に生成されるかまたは単に0に設定されるようにして、8ビットまたは16ビットに制限される可能性がある。概して、ハイブリッド鍵インデックスを、通常の鍵に関して、
indexhybrid = hash(m) mod 216 (7)
として計算し、先頭に0を付け加えて32ビット整数を生成し、強化された鍵に関して、
indexhybrid' = (hash(m) mod 216) + 231 (8)
として計算することができる。
Table 3(表3)は、ランダムなアドレスインデックス、アカウント、およびハイブリッドソリューションを総当たりするために必要とされる時間をまとめる。結果は、ランダムなインデックスから導出された鍵を総当たりする時間と、ハッシュの衝突の可能性との間のトレードオフを明らかにし、ハッシュの衝突の可能性は、ハイブリッドインデックスのランダムな構成要素により小さいビット空間を使用するとき高められる。外部データを複数の導出の深さに(たとえば、アドレスおよびアカウントレベルで)埋め込みたいユーザのために、任意の追加のランダムな鍵インデックスにハイブリッドソリューションを選択することを推奨する。たとえば、32ビットのランダムに生成されたアドレスインデックスが、8ビットまたは16ビットのハイブリッドランダムアカウントインデックスと併せて使用される可能性がある。これらの鍵インデックスは、たとえば、任意の監査プロセス中に一緒に提供される可能性がある。しかし、たとえば、アイデンティティの検証中にインデックスが別々に考慮される必要がある場合は、ハッシュの衝突の可能性を最小化するために、より大きな16ビットのハイブリッドランダムインデックスを使用することが得策である。
メッセージ総当たり
アカウント/インデックス総当たりの代替は、アカウント全体、すなわち、インデックス空間の代わりにメッセージmを総当たりすることである。メッセージ総当たりは、鍵自体の代わりに、鍵を生成するために使用された請求書または任意のその他の情報などの、すべての可能なメッセージを生成することに本質がある。この手法は、小さいメッセージ空間から生成される可能な鍵が可能な鍵全体のサブセットであるので、メッセージ空間がアカウント/インデックス空間より小さいとき、網羅的な鍵検索より効率的である。たとえば、請求書メッセージが、以下、すなわち、
m = 'Sold bicycle for 3 BSV with frame number XXXX and date YY/YY/YYYY'
のように一定の部分およびいくつかの変数を持つ文字列として表現されることを知っている場合、約40億個のアドレスインデックスを総当たりする代わりに、メッセージの可変部分XXXXおよびYY/YY/YYYYを総当たりする可能性がある。
過去10年の請求書をマイニングしたいと仮定すると、変数YY/YY/YYYY(365日×10年)には3650個の異なる値が存在する。また、何らかの論理で生成される1年あたり最大1,000,000個の請求書を仮定すると、変数XXXXに関して1,000,000個の異なる値を有する。したがって、探索される空間は、1,000,000×3650 =約36億個の組合せであり、これは、アドレスインデックスを総当たりするのと同規模である。この場合、インデックスまたはメッセージを総当たりすることは、同様の複雑さを有し、したがって、同様の量の時間を必要とする。
探索される空間を小さくすることができる場合、請求書をマイニングすることは、便利であり得る。たとえば、最大1,000個の可能な請求書を有し、1年だけを考える場合、(5秒ではなく)約0.2ミリ秒で総当たりされ得る1,000×365 = 365,000個の組合せを持つ。すべてのアカウントを総当たりすることは、完了されるのに(340年ではなく)約5日を必要とする。1つのHDウォレットを総当たりするためだけに高価なGPUを5日間フル稼働させることは、やはり費用対効果に優れた選択肢ではなく、したがって、アカウント管理は、決定的な手法を使用して解決されるべきであることに留意されたい。
ハッシュの衝突
ここで、2つのメッセージm(外部データ)が同じ32ビットのインデックスを生成し、したがって、EDHDウォレットの同じ子鍵にマッピングされる確率を評価する。この問題は、誕生日のパラドックスの一般化であり、したがって、範囲[1, d]のn個のメッセージが与えられたときに、少なくとも2つの鍵インデックスが同じである確率を計算するために次の(近似された)式を使用することができる。
したがって、範囲d = 232での衝突確率は、
である。
Table 4(表4)にいくつかの例が与えられ、たとえば、10,000個のメッセージが1.1%の衝突確率で挿入される一方、100,000個のメッセージは約68.8%の衝突確率で挿入される(これは、平均で、メッセージのうちの31.2%だけが一意の派生パスを持つことを意味する)。衝突を避けたい場合、概して、10-6未満の衝突確率が、許容範囲であり、したがって、ウォレットの実装のために妥当であると考えられ、これは、アカウントあたり100個以下の鍵がメッセージm(たとえば、請求書)を使用して生成されるべきであることを意味する。アカウントあたりの鍵の数を増やすために、衝突管理ツールが実装される可能性がある。例として、メッセージmは、それが既に使用されているインデックスを生成する場合、わずかに修正される可能性がある(たとえば、カウンタをインクリメントする)。
代替的に、衝突は、許容されることが可能である。これは、唯一の影響がアドレスが再利用されることである(これは、プライバシーがごくわずかに失われる結果となる場合がある)ので、いかなる資金も失われる結果とならない。請求書をトランザクションに一意にリンクするために、公開鍵の他に、請求書の金額および時間などのその他の因子も使用される可能性がある。推定される衝突回数は、n個の鍵を挿入する場合、以下のように計算され得る。
Table 4(表4)の最後の列に示されるように、メッセージ数が増えるにつれて、いくらかの衝突を予想し、たとえば、50,000個のメッセージが使用されるとき、0.29回の繰り返しを予想し、100,000個のメッセージが使用されるとき、予想される繰り返し回数は1.16回に上昇する。これは、100,000個の異なるメッセージから開始して鍵を生成するとき、平均で、それらのメッセージのうちの2つが同じ公開鍵を共有する(つまり、2つの請求書が同じアドレスを共有する)ことを意味する。
ベンフォードのウォレット
ベンフォードのウォレットとして知られるウォレットの設計は、規制の遵守を保証しながら、パブリックブロックチェーン上で取引をする商業者とユーザとの両方のプライバシーを保護するメカニズムを提供する。手短に言えば、請求書データが、出力アドレスの導出に利用され、これは、監査に有用である。同時に、請求書の値が、複数のトランザクションのこれらの複数の出力アドレスにその値を分散することによって難読化され、これは、オンチェーンのプライバシーを促進する。
プロトコルは、請求書メッセージmを異なる出力アドレスにわたってリンクするために、チェーンコードまたは共有された秘密を交換可能なように使用する。どちらの方法も、
としてmのハッシュから通常のまたは強化されたプライベート鍵を導出するために、式(1)または(2)の後に追加のステップを導入することによって、(3)に示された一般化されたBIP32のCKD関数を修正する。
どちらの方法も、子鍵派生パスに追加のステップを追加することによって外部データが含められるので、鍵の袋問題を再び持ち込む。上記のEDHDウォレットに関して説明された方法は、鍵の袋のシナリオにつながる可能性がある、いかなる追加のステップも導入せずに既存のBIP32フレームワーク内で働くので、この問題を解決する。
両方の利点を得るために、ベンフォードのウォレットをEDHDウォレットと組み合わせることができる。たとえば、ベンフォードの法則に従って異なる出力アドレスにトランザクションを分けることによって請求書の値を難解化しながら、上述のインデックスのマッピングに従ってHDウォレットに請求書が埋め込まれ得る。
ベンフォードのウォレットは1つの請求書を取得し、そこからいくつかの出力アドレスを生成するので、既に示されたように、1つの請求書を1つの出力アドレスにマッピングするEDHDウォレット方式にこれを調整するために少し注意する必要がある。
これを行うためのいくつかの選択肢がある。
1.カウンタを追加する - mBenford = n || invoiceであるように請求書メッセージmの始めで整数nと連結することによって、各出力アドレスのために新しい請求書メッセージが生成される。カウンタは、単一の請求書に帰属する出力アドレスの総数まで徐々に増やされる。たとえば、n = 3である場合、鍵導出エンティティ701は、3つのインデックスおよび対応する鍵を、
indexi = hash(mBenford,i) mod 231
を使用して生成し、
mBenford,0 = 0 || invoice
mBenford,1 = 1 || invoice
mBenford,2 = 2 || invoice
である。
2.請求書を分ける - メッセージが、n個の異なる出力アドレスにわたってデータのn個の等しいチャンクに分けられる。
3.派生パスの2つの深さを持つ - 単一の請求書に関する出力の値が、派生パスの2つの深さに分けられ得る。たとえば、請求書メッセージ(mBenford = invoice)が、親鍵を導出するために使用されることが可能であり、次いで、残りの出力アドレスが、最初のn - 1個の子鍵である。この方法は、派生パスの異なる深さにわたって外部データを埋め込むときにも、ウォレットの回復時間で不利益を被らないことも意味する。
これらの技術は、記載されているように、請求書の値のn個の分割(partition)の知識を必要とする。nによって表されるランダムな分割は、式(4)で鍵インデックスが導出されるのと同じ方法で、ただし、モジュロを請求書の分割の数の現実的な上限(たとえば、10個の分割)に修正して、請求書メッセージ自体から決定的に導出される可能性がある。これは、ベンフォードEDHDウォレットの説明を与える。
ベンフォードの法則を実現するランダムな分割
Bob(すなわち、鍵導出エンティティ701)が3 BSVの請求書を多くの出力および多くのトランザクションにわたってランダムに分けるためには、2つの行うべきタスクがある。
1.使用する出力の数およびトランザクションの数をランダムに選択する。
2.BSVの請求書の値を選択された数の出力にわたってランダムに分ける。
2つの異なるランダムな分割方法を使用して、2つのステップでこれらの目標を達成する。第1のステップは、小さな整数を分割することと、このセットの一様でランダムな選択を取得することとを含む。第2のステップは、足し合わせると大きな数(サトシを単位とする請求書の値)になる分割のセットを作成するために、大きな値の一様でランダムなスライス(slice)を使用する。両方のステップに含まれるランダム化は、トランザクション番号(transaction number)、出力あたりのトランザクションの数、および出力値自体にベンフォードの法則が適用される結果となる。
以下では、1つのパラメータNがユーザBobによって事前に選択される必要があることのみを求める。これは、N = 最大出力数であるように定義される。現実のシナリオでは、この数は小さく、たとえば、20未満であると予想する。
I.トランザクションおよび出力の分散。ユーザBobは、上記のように整数Nを定義し、これは、Bobが請求書を分けても構わない最大出力数を表す。n≦Nである合計n個の出力を持つm個のトランザクションテンプレートを出力するプロセスを説明する。
ステップ1:1≦k≦Nを満たす各整数kの整分割(integer partition)を特定するかまたは探す。整分割は、合計でnになる(順序のない)数の異なる組合せである。たとえば、k = 3およびk = 4の整分割は、
3, 4,
2+1, 3+1,
1+1+1, 2+2,
2+1+1,
1+1+1+1
である。3の3つの可能な整分割、および4の5つの可能な整分割が存在することが分かる。整分割の数は、線形に変わらない。次の表は、各整数k≦50の分割の数を示す。
ステップ2:1≦k≦Nを満たす各kのすべての可能な分割から一様でランダムに単一の分割を選ぶ。1≦m≦n≦Nである何らかの整数m、nに関して、この分割をn1+ … + nm = nと書くことができる。各項を、ni個の出力を持つトランザクションを定義するものと解釈する。すなわち、m個のトランザクションが構築され、1≦i≦mに関して、トランザクションiがni個の出力を有する。図9は、これを図式的に示す。出力の総数は、nである。
これらの2つのステップは、次節の我々の値分割プロセスの初期セットアップを完成させる。必要とされる単一の整数入力のNに加えて、ユーザBobが与えることができるいくつかの任意の入力を提案する。
1.トランザクションまたは出力の最小数:これは、自明なケース(trivial case)を避けるために使用され得る。
2.トランザクションの最大数:これは、取引手数料によるオーバーヘッドまたは送信者と受信者との間で送信されるデータの量に上限を設けるために使用され得る。場合によっては、トランザクションの数は、送信者から必要とされる入力の最小限の数を定義し、それが、この任意のパラメータによって上限を決められ得る。
II.請求書の値の分散。請求書の値L BSVおよび前のプロセスにおいて取得されたm個のトランザクションテンプレートのリストが与えられると、n個の出力を埋めるために以下の手順が使用されてよい。
1.(最小単位が1サトシ、10-8BSVであるので)10-8の精度でn - 1個の数U1, U2, ..., Un-1∈(0,1)を一様でランダムに生成する。
2.Uiを昇順に並べる、0<U(1)<U(2)<…<U(n-1)<1。
3.分割を、i = 1, 2, ..., nに関してXi = U(i) - U(i-1)として計算し、ここで、U(0) = 0およびU(n) = 1である。
今や、n個の値を形成するためにXi'として比例分割された請求書の値Lと、n個の値の各々につき1つずつ、合計n個の出力を持つm個のトランザクションテンプレートとを有している。
分割Xi'は、その一般的解釈においてベンフォードの法則に従う。すなわち、Xiの先頭の桁が小さいほど、そのXiが出現する可能性が高い。倍率Lは、先頭の桁の分布に影響しない。L = 1として詳細な証明を与え、結果を0より大きいLの任意の値に拡張する。
アイデンティティ証明書へのリンク
デジタル証明書は、CAによって署名され、発行され、CAは、ユーザのアイデンティティと証明書において指定された対象公開鍵との間のリンクを検証する際に、信頼できる第三者702として働く。ユーザがいくつかの鍵を証明したいとすれば、商用CAに証明を要求することは、かなり高コストになり得る。しかし、デジタル鍵管理の暗号技術のベストプラクティスは、公開鍵の再利用を避けることを推奨する。したがって、ブロックチェーンネットワーク上で取引をするユーザが、自分のアイデンティティデータを鍵のウォレット全体にリンクするときに、決定的な方法を採用する方がはるかに効率的で費用対効果に優れている。
親鍵の証明
HDウォレットの鍵のセットにアイデンティティデータをリンクするための最も簡単な方法は、それぞれのアカウント保有者のアイデンティティ証明書へのリンクが存在するように、マスタ公開鍵、またはマスタ鍵から導出されたアカウント鍵を証明することである。通常の(すなわち、強化されていない)子鍵から生成されるアドレスのために、ウォレット、つまり、アカウント所有者のアイデンティティへの証明可能なリンクが確立され得る。したがって、通常の子であるアドレス鍵は、アイデンティティ証明書が発行された親に証明可能なようにリンクされ得るので、それらのアドレス鍵に対してアイデンティティ監査を実施することができる。
子鍵がその親鍵が証明された後に使用されたこと(すなわち、デジタル証明書があらかじめ存在したこと)を、以下のようにして検証することもできる。
1.タイムスタンプ - デジタル証明書は、通常、タイムスタンプを含む。タイムスタンプは、子鍵がチェーン上で使用される前に証明書が作成された証拠として使用される可能性がある。
2.オンチェーンのデジタル証明書 - 証明書自体がオンチェーンで発行されるか、またはハッシュコミット(hash commit)がオンチェーンで登録された場合、これは、証明書が子鍵よりも前(または少なくとも子鍵がオンチェーンで使用される前、これは機能的には同等である)には存在したという証拠も提供する。
外部データへのリンクの証拠で事足りる、請求書の監査の比較的厳密でないケースとのここでの相違に留意されたい。アイデンティティ監査のために、HDウォレットの子鍵に関してユーザのアイデンティティを正しく検証するための暗号学的証明を探す。次いで、親鍵のアイデンティティ証明書を提供し、請求書に基づくインデックスを用いて子鍵を導出することによって、監査し易いシステムを得る。
鍵インデックスへのデジタル証明書のマッピング
HDウォレットの鍵にユーザのアイデンティティをリンクする代替的な方法は、上述の方法を使用してデジタル証明書を鍵インデックスにマッピングすることである。これは、単純に式4の外部データをm = digital certificateに設定することによって実現され得る。ただし、この方法を使用することが、上記の同じ理由で、ユーザのアイデンティティの暗号学的証明を提供しないことは強調されるべきである。
したがって、ウォレットの所有者がデジタル証明書において指定された対象公開鍵のプライベート鍵を知っていることをチェックするために、追加のプロトコルが導入されなければならない。そのようなプロトコルは、ユーザが証明されたプライベート・公開鍵ペアの所有権を暗号学的に証明するために、デジタル署名、ハッシュの原像の知識(適切な場合)、またはゼロ知識証明に基づく様々な証明方法を利用する可能性がある。
アイデンティティデータをアカウントレベルにマッピングすることは、異なるデジタル証明書に応じて鍵のブランチ全体を分割することを可能にする。図10は、EDHDウォレットを「アイデンティティ」ブランチ、「商業者」ブランチ、および「教育」ブランチによって構造化するために異なるデジタル証明書がどのようにして使用される可能性があるかを示す。アカウントレベルの鍵インデックスは、それぞれのデジタル証明書のハッシュから計算されるので今やランダムである。アカウントレベルの何らかの外部データのハッシュから生じるランダムなインデックスは、ウォレットの復元に関する上記の検討に基づいて、より小さなビット空間に制限されるべきであることを思い出されたい。
BIP44ビットコインのEDHDウォレットの完全な派生パスは、
m / 44' / 0' / (hybrid_random_account') / 0 / (random_address_index)
と書かれる可能性があり、hybrid_random_account'鍵インデックスは、m = digital certificateであるときの式8を使用して生成され、random_address_indexは、m = invoice messageであるときの式5を使用して生成される。各ブランチの構造を、異なるビジネスアプリケーションに合うようにさらに発展させることができる。「商業者」ブランチを考える場合、商業者は、返金に対応するように深さ4の子鍵を割り振ることができ、特に返金するために生成される深さ4の子鍵に請求書鍵からUTXOの額を送金することによって返金が認可される可能性があるように、深さ3の子鍵を作成するためにハッシュの原像(すなわち、元の請求書)が必要とされる。
デジタル証明書を鍵インデックスにマッピングする方法は、異なるアイデンティティの間のリンクを作成するために拡張される可能性もある。たとえば、他人のアイデンティティ証明書を自分のウォレットに組み込む可能性があり、たとえば、受取人のアイデンティティ証明書および請求書が、商業者のウォレットによって使用される出力アドレスにマッピングされる可能性がある。証明書および請求書は、以下のように組み合わされる可能性がある。
index = hash(digital certificate || invoice) mod 232 (13)
今や、商業者のウォレットソフトウェア内すべてでユーザ(買い手)のアイデンティティを販売(請求書)にリンクする手段を得た。これは、高額なトランザクション、たとえば、車または家の販売に特に有用である。
結論
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104の観点で説明された。しかし、ビットコインブロックチェーンは、ブロックチェーン150の1つの特定の例であり、上の説明は、任意のブロックチェーンに広く当てはまる可能性があることが理解されるであろう。すなわち、本発明は、ビットコインブロックチェーンに決して限定されない。より広く、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のすべての言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104への言及に置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された特性の一部またはすべてを共有する場合がある。
本発明の好ましい実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークであり、ビットコインノード104が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。これらの機能のうちの1つまたは一部だけを実行するが、すべては実行しないその他のネットワークエンティティ(またはネットワーク要素)が存在する可能性があることは、排除されない。すなわち、ネットワークエンティティが、ブロックを作成および公開することなく、ブロックを伝播および/または記憶する機能を実行する場合がある(これらのエンティティは、好ましいビットコインネットワーク106のノードとはみなされないことを思い出されたい)。
本発明のその他の実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークはない可能性がある。これらの実施形態においては、ノードが、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたは一部を実行するが、すべては実行しない場合があることは排除されない。たとえば、それらのその他のブロックチェーンネットワーク上で、「ノード」は、ブロック151を作成および公開するように構成されるが、それらのブロック151を記憶および/またはその他のノードに伝播するように構成されないネットワークエンティティを指すために使用される場合がある。
さらに一層広く、上記の用語「ビットコインノード」104へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックの作成し、発行し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関連して上で説明された同じ方法でハードウェアに実装されてよい。
上記の実施形態は、例としてだけ説明されたことが理解されるであろう。より広く、以下のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供されてよい。
ステートメント1.
階層的鍵構造の鍵を導出するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、第1の関係者によって実行され、
目標の子鍵の目標のインデックスを生成するステップであって、目標のインデックスが、少なくとも目標のメッセージを第1のハッシュ関数に入力した第1の結果に基づいて生成される、ステップと、
a)階層内の先行するレベルの親鍵、ならびにb)少なくともi)親鍵およびii)目標のインデックスを第2のハッシュ関数に入力した第2の結果に基づいて、階層内のレベルの目標の子鍵を導出するステップとを含む、コンピュータによって実施される方法。
ステートメント2.
目標の子鍵が、第2の結果の第1の部分に基づくステートメント1の方法。
ステートメント3.
目標の子鍵の目標のチェーンコードを生成するステップであって、目標のチェーンコードが、第2の結果の第2の部分に基づく、ステップを含むステートメント2の方法。
ステートメント4.
目標の子鍵が、iii)親鍵のそれぞれのチェーンコードを第2のハッシュ関数に入力することによって導出されるいずれかの前述のステートメントの方法。
ステートメント5.
第2のハッシュ関数が、ハッシュベースメッセージ認証コード(hash-based message authentication code)HMAC関数であるいずれかの前述のステートメントの方法。
ステートメント6.
親鍵がプライベート鍵であり、目標の子鍵がプライベート鍵であるいずれかの前述のステートメントの方法。
ステートメント7.
第2のハッシュ関数に入力される親鍵が、親鍵に対応する公開鍵であるステートメント6の方法。
ステートメント
目標の子鍵に対応する目標の公開鍵を生成するステップを含むステートメント6またはステートメント7の方法。
ステートメント9.
親鍵が公開鍵であり、目標の子鍵が公開鍵であり、目標の子鍵が、第2の結果に対応する公開鍵に基づいて導出されるステートメント1から5のいずれかの方法。
ステートメント10.
目標の子鍵にロックされた出力を含むブロックチェーントランザクションを生成し、ブロックチェーンネットワークおよび/もしくは第2の関係者にブロックチェーントランザクションを送信するステップ、
目標の子鍵に基づいて目標のブロックチェーンアドレスを計算し、第2の関係者に目標のブロックチェーンアドレスを送信するステップ、ならびに/または
目標のブロックチェーンアドレスを生成するために、第2の関係者に目標の子鍵を送信するステップのいずれか1つまたは複数を含むいずれかの前述のステートメントの方法。
ステートメント11.
ブロックチェーンが、目標のブロックチェーンアドレスに送信された出力を含むブロックチェーントランザクションを含み、方法が、
候補子鍵および対応する候補ブロックチェーンアドレスのシーケンスを導出するステップであって、各候補子鍵が、親鍵、ならびにb)少なくともi)親鍵およびii)それぞれの候補インデックスを第2のハッシュ関数に入力した第2の結果に基づいて導出され、それぞれの候補インデックスが、インデックスがとってよい可能な値のシーケンスのそれぞれの値であり、候補子鍵ごとに異なる、ステップと、
候補ブロックチェーンアドレスのうちの少なくとも1つに送信された出力を含むブロックチェーントランザクションを特定するステップと、
前記特定に基づいて、目標の子鍵が、特定されたブロックチェーントランザクションの出力がロックされている、対応する候補ブロックチェーンアドレスを有する候補子鍵であると決定するステップとを含むステートメント10の方法。
ステートメント12.
ブロックチェーンが、目標のブロックチェーンアドレスに送信された出力を含むブロックチェーントランザクションを含み、方法が、ブロックチェーントランザクションを特定するために目標のブロックチェーンアドレスを使用するステップを含むステートメント10の方法。
ステートメント13.
目標の子鍵が公開鍵であり、方法が、メッセージを暗号化するために目標の子鍵を使用するステップを含むか、または目標の子鍵がプライベート鍵であり、方法が、対応する公開鍵を用いて暗号化されたメッセージを復号するために目標の子鍵を使用するステップを含むいずれかの前述のステートメントの方法。
暗号化されたメッセージは、異なる関係者に送信されるかまたは異なる関係者から受信される場合がある。
ステートメント14.
少なくとも親鍵および目標のメッセージを第3の関係者に提供することによって、目標の子鍵とメッセージとの間のリンクを証明するステップを含むいずれかの前述のステートメントの方法。
目標の子鍵が親鍵のチェーンコードに基づいて生成される場合、前記チェーンコードも提供されてよい。
ステートメント15.
目標のメッセージが、認証局によって発行されたデジタル証明書を含むいずれかの前述のステートメントの方法。
ステートメント16.
マスタ鍵が、認証局によって発行されたデジタル証明書によって証明された証明された公開鍵であるいずれかの前述のステートメントの方法。
ステートメント17.
目標のメッセージが、証明された公開鍵を証明するデジタル証明書を含むステートメント15およびステートメント16の方法。
ステートメント18.
デジタル証明書が、第3の関係者によって所有された公開鍵を証明するステートメント15の方法。
たとえば、第3の関係者は、目標のメッセージに基づいて導出された子鍵にロックされた出力を含むブロックチェーントランザクションを生成する顧客であってよい。
ステートメント19.
1つまたは複数の追加の子鍵を導出するステップを含み、それぞれの追加の子鍵を生成することが、
それぞれの子鍵のそれぞれのインデックスを生成することであって、それぞれのインデックスが、少なくともそれぞれのメッセージを第1のハッシュ関数に入力した、それぞれの第1の結果に基づいて生成される、生成することと、
a)階層内の先行するレベルのそれぞれ親鍵、ならびにb)少なくともi)それぞれの親鍵およびii)それぞれのインデックスを第2のハッシュ関数に入力したそれぞれの第2の結果に基づいて、階層内のレベルのそれぞれの子鍵を導出することとを含むいずれかの前述のステートメントの方法。
ステートメント20.
追加の子鍵の一部またはすべてが、目標の子鍵と同じ親鍵に基づいて導出されるステートメント18の方法。
ステートメント21.
追加の子鍵の一部またはすべてが、目標の子鍵と比較して異なる親鍵に基づいて導出されるステートメント18またはステートメント19の方法。
ステートメント22.
目標の子鍵が、追加の子鍵のうちの1つまたは複数の親鍵であるステートメント20の方法。
ステートメント23.
追加の子鍵の一部またはすべてが、階層の、目標の子鍵と同じレベルにあるステートメント18またはステートメント19の方法。
ステートメント24.
目標の子鍵および追加の子鍵のうちの1つまたは複数の各々を導出するために使用されるそれぞれのインデックスが、少なくともメッセージおよびそれぞれのカウンタ値を第1のハッシュ関数に入力した、それぞれの第1の結果に基づいて導出されるステートメント19の方法。
ステートメント25.
メッセージ全体を複数の構成要素に分けるステップを含み、目標の子鍵および追加の子鍵のうちの1つまたは複数の各々を導出するために使用されるそれぞれのインデックスが、少なくともメッセージ全体の異なる構成要素を第1のハッシュ関数に入力したそれぞれの第1の結果に基づいて導出されるステートメント19の方法。
ステートメント26.
1つまたは複数の追加の子鍵を導出するステップを含み、それぞれの追加の子鍵を導出することが、
a)目標の子鍵、ならびにb)少なくともi)目標の子鍵およびii)それぞれのインデックスを第2のハッシュ関数に入力した、それぞれの第2の結果に基づいてそれぞれの子鍵を導出することであって、それぞれのインデックスが、シーケンスのそれぞれの値である、導出することを含むステートメント1から17のいずれかの方法。
ステートメント27.
それぞれの生成された子鍵に対応するそれぞれのブロックチェーンアドレスを生成するステップと、
異なる関係者にそれぞれのブロックチェーンアドレスを送信するステップとを含むステートメント18から26のいずれかの方法。
ステートメント28.
それぞれが1つまたは複数の出力を含む1つまたは複数のブロックチェーントランザクションを生成するステップであって、各出力が、生成された子鍵のうちのそれぞれの生成された子鍵にロックされる、ステップと、
ブロックチェーンネットワークに1つまたは複数のブロックチェーントランザクションを送信するステップ、および/あるいは異なる関係者に1つまたは複数のブロックチェーントランザクションを送信するステップとを含むステートメント18から27のいずれかの方法。
ステートメント29.
目標の子鍵の前記導出が、目標の子鍵を復元することを含み、目標の子鍵の前記復元が、
対応するシードに基づいてマスタ鍵を生成することと、
マスタ鍵に基づいて目標の子鍵の親鍵を導出することとを含むいずれかの前述のステートメントの方法。
親鍵は、マスタ鍵から直接導出されてよく、すなわち、目標の子鍵の親鍵は、それ自体がマスタ鍵の子鍵である。代替的に、親鍵は、鍵構造の異なるそれぞれのレベルに属する1つまたは複数の鍵を導出することによって、マスタ鍵から間接的に導出されてよい。
ステートメント30.
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、メモリが、処理装置上で実行されるように配置されたコードを記憶し、コードが、処理装置上にあるときに、いずれかの前述のステートメントの方法を実行するように構成される、処理装置とを含むコンピュータ機器。
ステートメント31.
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、いずれかの前述のステートメントの方法を実行するように構成されたコンピュータプログラム。
100 システム
101 パケット交換ネットワーク
102 コンピュータ端末、コンピュータ機器、機器
102a コンピュータ機器
102b コンピュータ機器
103 ユーザ、エージェント、関係者
103a ユーザ、第1の関係者、Alice
103b 新しいユーザまたはエンティティ、第2の関係者、Bob
104 ブロックチェーンノード、ビットコインノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、ビットコインネットワーク、ブロックチェーンネットワーク
107 サイドチャネル
150 ブロックチェーン、ビットコインブロックチェーン
151 データのブロック、最新のブロック
152 トランザクション、新しいトランザクション
152i 先行トランザクション、新しいトランザクション
152j 現在のトランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット、プール
155 ブロックポインタ
201 ヘッダ
202 入力
203 出力
400 システム
401 トランザクションエンジン、要求者
402 ユーザインターフェース(UI)レイヤ、確認者
403 機能
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素、データ入力フィールド
700 システム
701 鍵導出エンティティ
702 第三者

Claims (31)

  1. 階層的鍵構造の鍵を導出するコンピュータによって実施される方法であって、前記鍵構造が、レベルの階層を含み、レベルの前記階層が、マスタレベルおよび1つまたは複数の子レベルを含み、前記マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、前記先行するレベルの前記1つの鍵が、前記それぞれの子鍵のそれぞれの親鍵であり、前記方法が、第1の関係者によって実行され、
    目標の子鍵の目標のインデックスを生成するステップであって、前記目標のインデックスが、少なくとも目標のメッセージを第1のハッシュ関数に入力した第1の結果に基づいて生成される、ステップと、
    a)前記階層内の先行するレベルの親鍵、ならびにb)少なくともi)前記親鍵およびii)前記目標のインデックスを第2のハッシュ関数に入力した第2の結果に基づいて、前記階層内のレベルの前記目標の子鍵を導出するステップとを含む、コンピュータによって実施される方法。
  2. 前記目標の子鍵が、前記第2の結果の第1の部分に基づく請求項1に記載の方法。
  3. 前記目標の子鍵の目標のチェーンコードを生成するステップであって、前記目標のチェーンコードが、前記第2の結果の第2の部分に基づく、ステップを含む請求項2に記載の方法。
  4. 前記目標の子鍵が、iii)前記親鍵のそれぞれのチェーンコードを前記第2のハッシュ関数に入力することによって導出される請求項1から3のいずれか一項に記載の方法。
  5. 前記第2のハッシュ関数が、HMAC関数である請求項1から4のいずれか一項に記載の方法。
  6. 前記親鍵がプライベート鍵であり、前記目標の子鍵がプライベート鍵である請求項1から5のいずれか一項に記載の方法。
  7. 前記第2のハッシュ関数に入力される前記親鍵が、前記親鍵に対応する公開鍵である請求項6に記載の方法。
  8. 前記目標の子鍵に対応する目標の公開鍵を生成するステップを含む請求項6または請求項7に記載の方法。
  9. 前記親鍵が公開鍵であり、前記目標の子鍵が公開鍵であり、前記目標の子鍵が、前記第2の結果に対応する公開鍵に基づいて導出される請求項1から5のいずれか一項に記載の方法。
  10. 前記目標の子鍵にロックされた出力を含むブロックチェーントランザクションを生成し、ブロックチェーンネットワークおよび/もしくは第2の関係者に前記ブロックチェーントランザクションを送信するステップ、
    前記目標の子鍵に基づいて目標のブロックチェーンアドレスを計算し、前記第2の関係者に前記目標のブロックチェーンアドレスを送信するステップ、ならびに/または
    前記目標のブロックチェーンアドレスを生成するために、前記第2の関係者に前記目標の子鍵を送信するステップのいずれか1つまたは複数を含む請求項1から9のいずれか一項に記載の方法。
  11. ブロックチェーンが、前記目標のブロックチェーンアドレスに送信された出力を含むブロックチェーントランザクションを含み、前記方法が、
    候補子鍵および対応する候補ブロックチェーンアドレスのシーケンスを導出するステップであって、各候補子鍵が、前記親鍵、ならびにb)少なくともi)前記親鍵およびii)それぞれの候補インデックスを第2のハッシュ関数に入力した第2の結果に基づいて導出され、前記それぞれの候補インデックスが、前記インデックスがとってよい可能な値のシーケンスのそれぞれの値であり、候補子鍵ごとに異なる、ステップと、
    前記候補ブロックチェーンアドレスのうちの少なくとも1つに送信された出力を含むブロックチェーントランザクションを特定するステップと、
    前記特定に基づいて、前記目標の子鍵が、特定されたブロックチェーントランザクションの前記出力がロックされている前記対応する候補ブロックチェーンアドレスを有する前記候補子鍵であると決定するステップとを含む請求項10に記載の方法。
  12. ブロックチェーンが、前記目標のブロックチェーンアドレスに送信された出力を含むブロックチェーントランザクションを含み、前記方法が、前記ブロックチェーントランザクションを特定するために前記目標のブロックチェーンアドレスを使用するステップを含む請求項10に記載の方法。
  13. 前記目標の子鍵が公開鍵であり、前記方法が、メッセージを暗号化するために前記目標の子鍵を使用するステップを含むか、または前記目標の子鍵がプライベート鍵であり、前記方法が、対応する公開鍵を用いて暗号化されたメッセージを復号するために前記目標の子鍵を使用するステップを含む請求項1から12のいずれか一項に記載の方法。
  14. 少なくとも前記親鍵および前記目標のメッセージを第3の関係者に提供することによって、前記目標の子鍵と前記メッセージとの間のリンクを証明するステップを含む請求項1から13のいずれか一項に記載の方法。
  15. 前記目標のメッセージが、認証局によって発行されたデジタル証明書を含む請求項1から14のいずれか一項に記載の方法。
  16. 前記マスタ鍵が、認証局によって発行されたデジタル証明書によって証明された、証明された公開鍵である請求項1から15のいずれか一項に記載の方法。
  17. 前記目標のメッセージが、証明された公開鍵を証明する前記デジタル証明書を含む請求項15または請求項16に記載の方法。
  18. 前記デジタル証明書が、第3の関係者によって所有された公開鍵を証明する請求項15に記載の方法。
  19. 1つまたは複数の追加の子鍵を導出するステップを含み、それぞれの追加の子鍵を生成することが、
    前記それぞれの子鍵のそれぞれのインデックスを生成することであって、前記それぞれのインデックスが、少なくともそれぞれのメッセージを前記第1のハッシュ関数に入力した、それぞれの第1の結果に基づいて生成される、生成することと、
    a)前記階層内の先行するレベルのそれぞれ親鍵、ならびにb)少なくともi)前記それぞれの親鍵およびii)前記それぞれのインデックスを前記第2のハッシュ関数に入力した、それぞれの第2の結果に基づいて、前記階層内のレベルの前記それぞれの子鍵を導出することとを含む請求項1から18のいずれか一項に記載の方法。
  20. 追加の子鍵の一部またはすべてが、前記目標の子鍵と同じ親鍵に基づいて導出される請求項18に記載の方法。
  21. 追加の子鍵の一部またはすべてが、前記目標の子鍵と比較して異なる親鍵に基づいて導出される請求項18または請求項19に記載の方法。
  22. 前記目標の子鍵が、前記追加の子鍵のうちの1つまたは複数の前記親鍵である請求項20に記載の方法。
  23. 追加の子鍵の一部またはすべてが、前記階層の、前記目標の子鍵と同じレベルにある請求項18または請求項19に記載の方法。
  24. 前記目標の子鍵および前記追加の子鍵のうちの1つまたは複数の各々を導出するために使用される前記それぞれのインデックスが、少なくとも前記メッセージおよびそれぞれのカウンタ値を前記第1のハッシュ関数に入力した、それぞれの第1の結果に基づいて導出される請求項19に記載の方法。
  25. メッセージ全体を複数の構成要素に分けるステップを含み、前記目標の子鍵および前記追加の子鍵のうちの1つまたは複数の各々を導出するために使用される前記それぞれのインデックスが、少なくとも前記メッセージ全体の異なる構成要素を前記第1のハッシュ関数に入力した、それぞれの第1の結果に基づいて導出される請求項19に記載の方法。
  26. 1つまたは複数の追加の子鍵を導出するステップを含み、それぞれの追加の子鍵を導出することが、
    a)前記目標の子鍵、ならびにb)少なくともi)前記目標の子鍵およびii)それぞれのインデックスを前記第2のハッシュ関数に入力した、それぞれの第2の結果に基づいて前記それぞれの子鍵を導出することであって、前記それぞれのインデックスが、シーケンスのそれぞれの値である、導出することを含む請求項1から17のいずれか一項に記載の方法。
  27. それぞれの生成された子鍵に対応するそれぞれのブロックチェーンアドレスを生成するステップと、
    異なる関係者に前記それぞれのブロックチェーンアドレスを送信するステップとを含む請求項18から26のいずれか一項に記載の方法。
  28. それぞれが1つまたは複数の出力を含む1つまたは複数のブロックチェーントランザクションを生成するステップであって、各出力が、生成された子鍵のうちのそれぞれの生成された子鍵にロックされる、ステップと、
    ブロックチェーンネットワークに前記1つまたは複数のブロックチェーントランザクションを送信するステップ、および/あるいは異なる関係者に前記1つまたは複数のブロックチェーントランザクションを送信するステップとを含む請求項18から27のいずれか一項に記載の方法。
  29. 前記目標の子鍵の前記導出が、前記目標の子鍵を復元することを含み、前記目標の子鍵の前記復元が、
    対応するシードに基づいて前記マスタ鍵を生成することと、
    前記マスタ鍵に基づいて前記目標の子鍵の前記親鍵を導出することとを含む請求項1から28のいずれか一項に記載の方法。
  30. 1つまたは複数のメモリユニットを含むメモリと、
    1つまたは複数の処理ユニットを含む処理装置であって、前記メモリが、前記処理装置上で実行されるように配置されたコードを記憶し、前記コードが、前記処理装置上にあるときに、請求項1から29のいずれか一項に記載の方法を実行するように構成される、処理装置とを含むコンピュータ機器。
  31. コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、請求項1から29のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。
JP2023528164A 2020-11-13 2021-10-15 鍵導出方法 Pending JP2023548917A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2017904.0A GB2600970A (en) 2020-11-13 2020-11-13 Key derivation method
GB2017904.0 2020-11-13
PCT/EP2021/078601 WO2022100958A1 (en) 2020-11-13 2021-10-15 Key derivation method

Publications (1)

Publication Number Publication Date
JP2023548917A true JP2023548917A (ja) 2023-11-21

Family

ID=74045998

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023528164A Pending JP2023548917A (ja) 2020-11-13 2021-10-15 鍵導出方法

Country Status (7)

Country Link
US (1) US20230396450A1 (ja)
EP (1) EP4193565A1 (ja)
JP (1) JP2023548917A (ja)
KR (1) KR20230101892A (ja)
CN (1) CN116547942A (ja)
GB (1) GB2600970A (ja)
WO (1) WO2022100958A1 (ja)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012170130A1 (en) * 2011-06-10 2012-12-13 Certicom (U.S.) Limited Implicitly certified public keys
US10951401B2 (en) * 2018-03-30 2021-03-16 Bitnomial, Inc. Digital asset transfer system for secure digital asset transactions
KR20200064017A (ko) * 2018-11-28 2020-06-05 주식회사 코인즈월렛 블록체인 기법을 이용한 fido2.0 암호키를 생성하는 방법

Also Published As

Publication number Publication date
WO2022100958A1 (en) 2022-05-19
GB202017904D0 (en) 2020-12-30
GB2600970A (en) 2022-05-18
EP4193565A1 (en) 2023-06-14
CN116547942A (zh) 2023-08-04
US20230396450A1 (en) 2023-12-07
KR20230101892A (ko) 2023-07-06

Similar Documents

Publication Publication Date Title
CN109314636B (zh) 用于从区块链中安全提取数据的密码方法和系统
JP2021153341A (ja) 統合ブロックチェーンに基づくデータ転送制御方法及びシステム
WO2021176283A1 (en) Method of generating a public key
JP2023508088A (ja) ブロックチェーンオーバーレイネットワークへの鍵のマッピング
US20220337427A1 (en) Cryptographically linked identities
JP2023532211A (ja) ブロックチェーン上の合意
CN116508291A (zh) 默克尔证明实体
WO2023072965A1 (en) Methods and systems for distributed blockchain functionalities
JP2023554148A (ja) 機密データのブロック
US20230308292A1 (en) Digital signatures
US20230134619A1 (en) Method of generating a hash-based message authentication code
EP3973661B1 (en) Knowledge proof
CN114514550A (zh) 将请求分区成区块链的交易
WO2023110551A1 (en) Zero knowledge proof based child key authenticity
WO2023012127A1 (en) A computer implemented method and system
WO2023117230A1 (en) Blockchain transaction
JP2024518079A (ja) マルチパーティブロックチェーンアドレス方式
US20230396450A1 (en) Key derivation method
CN116547945A (zh) 默克尔证明实体
US20230421366A1 (en) Key generation method
US20240214179A1 (en) Blockchain-implemented hash function
WO2023194187A1 (en) Statement proof and verification
WO2023169865A1 (en) Translucent blockchain database
JP2024516895A (ja) マルチパーティブロックチェーンアドレス方式
JP2024524688A (ja) メッセージ交換システム