(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-12-19
(54)【発明の名称】鍵生成方法
(51)【国際特許分類】
H04L 9/08 20060101AFI20231212BHJP
【ＦＩ】
H04L9/08 C
H04L9/08 F
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023528738
(86)(22)【出願日】2021-10-28
(85)【翻訳文提出日】2023-07-14
(86)【国際出願番号】 EP2021079948
(87)【国際公開番号】W WO2022101023
(87)【国際公開日】2022-05-19
(31)【優先権主張番号】2017883.6
(32)【優先日】2020-11-13
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＴＷＩＴＴＥＲ
２．ビットコイン
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ジャック・オーウェン・デイヴィーズ
(72)【発明者】
【氏名】サイモン・オーディッシュ
(57)【要約】
階層的鍵構造の鍵を生成するコンピュータによって実施される方法であって、方法が、鍵生成器によって実行され、子鍵派生パスを取得するステップであって、子鍵派生パスが、要素のシーケンスを含み、要素のシーケンスが、1つまたは複数の要素の1つまたは複数のセットを含み、要素の各セットが、データパスのそれぞれのデータアイテムに基づいて生成され、シーケンスの各要素が、鍵構造のそれぞれのレベルにおける鍵のそれぞれの位置に対応する、ステップと、子鍵派生パスに基づいて1つまたは複数の子鍵を生成するステップであって、それぞれの子鍵が、それぞれの位置でシーケンスのそれぞれの要素に基づいて生成され、それぞれの要素に対応するそれぞれのレベルのものである、ステップとを含む、コンピュータによって実施される方法。
【特許請求の範囲】
【請求項1】
階層的鍵構造の鍵を生成するコンピュータによって実施される方法であって、前記鍵構造が、レベルの階層を含み、レベルの前記階層が、マスタレベルおよび1つまたは複数の子レベルを含み、前記マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、前記先行するレベルの前記1つの鍵が、前記それぞれの子鍵のそれぞれの親鍵であり、前記方法が、鍵生成器によって実行され、子鍵派生パスを取得するステップであって、前記子鍵派生パスが、要素のシーケンスを含み、要素の前記シーケンスが、1つまたは複数の要素の1つまたは複数のセットを含み、要素の各セットが、データパスのそれぞれのデータアイテムに基づいて生成され、前記データパスが、複数のデータアイテムを含み、前記シーケンスの各要素が、前記鍵構造のそれぞれのレベルにおける鍵のそれぞれの位置に対応する、ステップと、
前記子鍵派生パスに基づいて1つまたは複数の子鍵を生成するステップであって、それぞれの子鍵が、前記それぞれの位置で前記シーケンスのそれぞれの要素に基づいて生成され、前記それぞれの要素に対応する前記それぞれのレベルのものである、ステップとを含む、コンピュータによって実施される方法。
【請求項2】
前記生成された子鍵のうちの1つまたは複数を記憶および/または出力するステップを含む請求項1に記載の方法。
【請求項3】
前記子鍵派生パスが、要素の各セットにつき1つずつ複数の下位パスを含み、各下位パスが、同じ最初の要素および異なるそれぞれの最終の要素を含み、前記1つまたは複数の生成された子鍵の前記記憶および/または前記出力が、下位パスごとに1つの子鍵を記憶および/または出力することを含み、前記子鍵が、前記それぞれの最終の要素に基づいて生成される請求項2に記載の方法。
【請求項4】
前記子鍵派生パスを取得するステップが、前記子鍵派生パスを受信することを含む請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記データパスを取得するステップを含み、前記子鍵派生パスを取得するステップが、前記取得されたデータパスに基づいて前記子鍵派生パスを生成することを含む請求項1から3のいずれか一項に記載の方法。
【請求項6】
前記子鍵派生パスを生成することが、前記データパスのそれぞれのデータアイテムに関して要素のそれぞれのセットを生成することであって、要素のそれぞれのセットが、前記データアイテムを一緒に表し、要素の各セットの各要素が、整数である、生成することを含む請求項5に記載の方法。
【請求項7】
各整数が、10進表現としてまたは16進表現として表される請求項6に記載の方法。
【請求項8】
各整数が、固定長の整数である請求項6または請求項7に記載の方法。
【請求項9】
各親鍵が、最大2n個の子鍵を持つことができ、nが、前記固定長の整数である請求項8に記載の方法。
【請求項10】
前記データパスを取得するステップが、前記データパスを受信することを含む請求項5から9のいずれか一項に記載の方法。
【請求項11】
前記受信されたデータパスが、難読化されていないデータパスの難読化されたバージョンであり、難読化されたデータパスの各データアイテムが、前記難読化されていないデータパスのそれぞれの難読化されていないデータアイテムの難読化されたバージョンである請求項10に記載の方法。
【請求項12】
前記データパスを取得するステップが、前記データパスを生成することを含む請求項5から9のいずれか一項に記載の方法。
【請求項13】
前記データパスの難読化されたバージョンを生成するステップを含み、前記取得されたデータパスに基づく前記子鍵派生パスの前記生成が、難読化されたデータパスに基づいて前記子鍵派生パスを生成することを含み、前記データパスのそれぞれのデータアイテムに関する要素の前記それぞれのセットの前記生成が、前記難読化されたデータパスのそれぞれのデータアイテムに関して要素の前記それぞれのセットを生成することを含む請求項10または請求項12に記載の方法。
【請求項14】
前記データパスの各データアイテムが、別々に難読化される請求項11または請求項13に記載の方法。
【請求項15】
前記データパスの各データアイテムが、ランダム化、
暗号鍵を使用する暗号化、
XOR鍵を使用するXOR暗号化、
マッピング関数を使用する置換、および/または
ハッシュ関数
のうちの任意の1つまたは複数を使用して難読化される請求項11、13、または14のいずれか一項に記載の方法。
【請求項16】
前記データパスが、フォルダ構造に対応し、各データアイテムが、前記フォルダ構造の異なるフォルダに属する請求項1から15のいずれか一項に記載の方法。
【請求項17】
前記出力が、前記1つまたは複数の生成された子鍵を、前記1つまたは複数の生成された子鍵のうちの少なくとも1つに基づいてデータを暗号化するように構成された暗号化関数に出力することと、
前記1つまたは複数の生成された子鍵を、前記1つまたは複数の生成された子鍵のうちの少なくとも1つに基づいてデジタル署名を生成するように構成された署名関数に出力することと、
前記1つまたは複数の生成された子鍵を異なる関係者に送信することと、
前記1つまたは複数の生成された子鍵の各々に関してそれぞれのブロックチェーンアドレスを生成し、前記それぞれのブロックチェーンアドレスを前記異なる関係者に出力することと、
前記1つまたは複数の生成された子鍵のうちの少なくとも1つにロックされた出力を含むブロックチェーントランザクションを生成することとのうちの少なくとも1つを含む、請求項2または請求項2に従属する請求項のいずれか一項に記載の方法。
【請求項18】
階層的鍵構造の鍵を生成するための鍵生成器による使用のためにデータパスを生成するコンピュータによって実施される方法であって、前記鍵構造が、レベルの階層を含み、レベルの前記階層が、マスタレベルおよび1つまたは複数の子レベルを含み、前記マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、前記先行するレベルの前記1つの鍵が、前記それぞれの子鍵のそれぞれの親鍵であり、前記方法が、パス生成器によって実行され、複数のデータアイテムを含むデータパスを取得するステップと、
前記データパスのそれぞれのデータアイテムに関して1つまたは複数の要素のそれぞれのセットを生成するステップであって、要素のそれぞれのセットが、前記データアイテムを一緒に表し、要素の各セットの各要素が、整数である、ステップと、
1つまたは複数の要素の前記それぞれのセットに基づいて子鍵派生パスを生成するステップと、
前記子鍵派生パスを出力するステップとを含む、コンピュータによって実施される方法。
【請求項19】
前記子鍵派生パスの前記出力が、前記子鍵派生パスを前記鍵生成器に出力することを含み、前記鍵生成器が、前記子鍵派生パスに基づいて1つまたは複数の子鍵を生成するように構成される請求項18に記載の方法。
【請求項20】
各整数が、10進表現としてまたは16進表現として表される請求項18または請求項19に記載の方法。
【請求項21】
各整数が、固定長の整数である請求項18から20のいずれか一項に記載の方法。
【請求項22】
各親鍵が、最大2n個の子鍵を持つことができ、nが、前記固定長の整数である請求項21に記載の方法。
【請求項23】
データを取得するステップが、前記データパスを受信することを含む請求項18から22のいずれか一項に記載の方法。
【請求項24】
データを取得するステップが、前記データパスを生成することを含む請求項18から22のいずれか一項に記載の方法。
【請求項25】
取得されたデータパスが、難読化されていないデータパスの難読化されたバージョンである請求項18から24のいずれか一項に記載の方法。
【請求項26】
1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置であって、前記メモリが、前記処理装置上で実行されるように配置されたコードを記憶し、前記コードが、前記処理装置上にあるときに、請求項1から25のいずれか一項に記載の方法を実行するように構成される、処理装置とを含むコンピュータ機器。
【請求項27】
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、請求項1から25のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、階層的鍵構造の鍵(たとえば、プライベート鍵)を生成する方法に関する。たとえば、鍵は、データを暗号化する、ブロックチェーントランザクションに署名する、およびブロックチェーンアドレスを生成するために使用される場合がある。
【背景技術】
【0002】
ブロックチェーンテクノロジーの文脈において、通常、「ウォレットアプリケーション」または単に「ウォレット」は、とりわけ、特定の関係者によって所有される鍵(すなわち、公開鍵および/またはプライベート鍵)の集合を記憶するように構成されるアプリケーションを指す。
【0003】
パブリックブロックチェーン上でプライバシーを保つためには、プライベート鍵から導出される公開鍵の再利用を避けることが推奨される。これは、ウォレットが、鍵が失われるまたは盗まれることがないことを保証するために安全に記憶され、頻繁にバックアップされる必要があるランダムに生成されたプライベート鍵の集合となることにつながり得る。鍵の再利用を避けることによって、このタイプのウォレットはすぐに「鍵の袋(bag of keys)」問題を生じ得る。
【0004】
鍵の記憶および再生成の効率を向上させ、この鍵の袋問題を解決するために、階層的決定性(HD: hierarchical deterministic)ウォレットが提案された。HDウォレットは、プライバシーの点、およびウォレットのブランチを異なるシステムまたはサブシステムと共有する能力を有するという点で、さらなる利点をもたらす。このタイプのウォレットは、単一のランダムなシードから多くの鍵を生成することができ、現在使用されているブロックチェーンウォレットの最もありふれたタイプである。
【0005】
ウォレットの実装は、概して、親鍵から複数の子鍵をどのようにして導出するべきかを説明するビットコイン改善提案32(BIP32)、およびウォレット内のブランチの目的を定義するBIP44に従う。HDウォレットの実装においては、マスタプライベート鍵が、ランダムなシードから導出される。このマスタプライベート鍵は、何世代もの鍵(子、孫など)を導出するために使用される。
【0006】
図4は、HDウォレットに現れる結果的なツリー状構造を示す。このデータ構造は、ウォレットのセキュリティと、復旧中に資金を復元するその能力とを管理するための強力なメカニズムである。実装によっては、オブザーバが、対応するプライベート鍵なしに公開鍵のシーケンスを作成することができる。より少ない秘密が記憶される必要があるので、露呈のリスクがより少ない。加えて、鍵が失われる場合に、それらの鍵が、シード鍵から復元され得る。
【0007】
親鍵から子鍵を導出する式は、親の公開鍵が使用されるのかまたは親のプライベート鍵が使用されるのかに応じて決まり、親プライベート鍵の使用は、「強化された(hardened)」子鍵をもたらし、親公開鍵の使用は、「通常の」(すなわち、BIP32の用語に従えば、強化されていない(non-hardened))子鍵をもたらす。
【0008】
子鍵は、子鍵導出(CKD)関数を使用して生成される。CKD関数の特定の形態は、特定のウォレットの実装に依存するが、概して、子鍵は、親鍵およびインデックスに基づく。インデックスは、親鍵が複数の子鍵を生み出すことを可能にする。すなわち、親鍵は複数の子鍵を持つ場合がある。通常、インデックスは、シーケンスの値をとり、親鍵の第1の子鍵がシーケンスの第1の値(たとえば、0)をとり、親鍵の第2の子鍵がシーケンスの次の値(たとえば、1)をとり、以下同様である。
【0009】
本稿執筆時点では、親公開鍵およびチェーンコード(chain code)の知識のみを有する場合に、強化された子公開鍵を導出することはできないことに留意されたい。通常の子鍵に支払いを要求することは、受信者が親公開鍵(およびチェーンコード)のみを明かすことができ、送信者が複数の強化されていない子鍵を導出することによって支払いを送信することができることを意味する。このようにして、資金の受信者は、送信者に各アドレスを明示的に与える必要がない。これは、同じ2者間の通信を最小化し、パブリックブロックチェーン上で取引をするときのプライバシーを強化しながら、複数の支払いが送信され得ることを保証する。
【0010】
BIP32プロトコルによれば、通常の子プライベート鍵skiの式は、
ski = skpar + HMAC512L(cpar,pkpar//index) (1)
であり、強化された子プライベート鍵ski'の式は、
ski' = skpar + HMAC512L(cpar,skpar//index') (2)
であり、
・skparは、親プライベート鍵であり、
・pkparは、親公開鍵であり、
・
ski = skpar + HMAC512L(cpar,pkpar//index) (1)
であり、強化された子プライベート鍵ski'の式は、
ski' = skpar + HMAC512L(cpar,skpar//index') (2)
であり、
・skparは、親プライベート鍵であり、
・pkparは、親公開鍵であり、
・
【0011】
【数1】
【0012】
は、SHA512ハッシュ関数を使用するHMAC関数の結果の左32バイトであり、
・cparは、親鍵のチェーンコードであり、
・indexは、0から始まり、新しい子鍵が計算されるたびに増加する子鍵のカウンタである。慣例として、これは、通常の鍵に関して0≦index < 231であり、強化された鍵に関して231≦index' < 232である。
・cparは、親鍵のチェーンコードであり、
・indexは、0から始まり、新しい子鍵が計算されるたびに増加する子鍵のカウンタである。慣例として、これは、通常の鍵に関して0≦index < 231であり、強化された鍵に関して231≦index' < 232である。
【先行技術文献】
【非特許文献】
【0013】
【非特許文献1】https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
【非特許文献2】https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
【非特許文献3】https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
【発明の概要】
【発明が解決しようとする課題】
【0014】
近年、データ指向アプリケーションへのブロックチェーンテクノロジーの応用が、ますます盛んになってきた。アプリケーションのデータをブロックチェーン上に不変的に記録されることを可能にするためのデータ包み込みメカニズム(data-enveloping mechanism)としてブロックチェーントランザクションを利用するアプリケーションを見かけることは、今やめずらしくない。これは、データ自体を、そのデータに関連する場合があるマイクロペイメントと組み合わせる能力にさらなる有益性を有する。
【0015】
ブロックチェーントランザクションに署名するために使用される暗号鍵(たとえば、ECDSA鍵ペア)は、上で検討されたBIP-32の階層的決定性鍵導出規格を使用して導出されるのが最も普通である。この規格は、ウォレットが単一のシードから復元されることを可能にし、シードは、さらにBIP-39のニーモニック(mnemonic)規格を使用して人間が読むことができるようにされ得る。BIP-32規格は、マスタシードのエントロピー(entropy)から個々の鍵を導出するために階層的パスを利用し、鍵の階層を資金の異なる分割(partition)(すなわち、別々の「アカウント」)のために使用される別々のブランチに分けるという概念が、BIP-44規格で普及された。
【0016】
データ指向のブロックチェーンアプリケーションと、これまで概して金銭的な意味での階層を提供するためにしか使用されてこなかったBIP規格などのまたは同様の、階層的鍵導出プロトコルとの間の相互運用性を向上させることが望ましい。
【課題を解決するための手段】
【0017】
本明細書において開示される一態様によれば、階層的鍵構造の鍵を生成するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、鍵生成器によって実行され、子鍵派生パス(derivation path)を取得するステップであって、子鍵派生パスが、要素のシーケンスを含み、要素のシーケンスが、1つまたは複数の要素の1つまたは複数のセットを含み、要素の各セットが、データパスのそれぞれのデータアイテムに基づいて生成され、シーケンスの各要素が、鍵構造のそれぞれのレベルにおける鍵のそれぞれの位置に対応する、ステップと、子鍵派生パスに基づいて1つまたは複数の子鍵を生成するステップであって、それぞれの子鍵が、それぞれの位置でシーケンスのそれぞれの要素に基づいて生成され、それぞれの要素に対応するそれぞれのレベルのものである、ステップとを含む、コンピュータによって実施される方法が提供される。
【0018】
本明細書において開示される一態様によれば、階層的鍵構造の鍵を生成するための鍵生成器による使用のためにデータパスを生成するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、パス生成器によって実行され、1つまたは複数のデータアイテムを含むデータパスを取得するステップと、データパスのそれぞれのデータアイテムに関して1つまたは複数の要素のそれぞれのセットを生成するステップであって、要素のそれぞれのセットが、データアイテムを一緒に表し、要素の各セットの各要素が、整数である、ステップと、1つまたは複数の要素のそれぞれのセットに基づいて子鍵派生パスを生成するステップと、子鍵派生パスを出力するステップとを含む、コンピュータによって実施される方法が提供される。
【0019】
子鍵派生パスの各要素は、鍵構造における特定の鍵の位置に対応する。各要素は、データパスからのデータアイテムに基づいて生成される。たとえば、データパスは、階層的データ構造を表す場合があり、各データアイテムが、階層の異なるレベルに属する。たとえば、データ構造は、地理的性質のものである場合があり、データパスは、国から特定の住所、たとえば、国、都市、通り住所(street address)、家番号(house number)までたどって行く。代替的に、データパスは、階層的ではないが、データアイテムを特定の順序で記憶するデータ構造を表す場合がある。たとえば、データ構造は、個人識別子、たとえば、名前、年齢、性別、国籍などを含む場合がある。データアイテムが何を表すかにかかわらず、各データアイテムは、鍵派生パスの要素を生成するために使用される。したがって、要素に対応する鍵構造内の位置に基づいて生成される鍵は、データアイテムに直接基づく。
【0020】
鍵は、鍵派生パスの各要素に関して生成される。すなわち、鍵派生パスの要素のシーケンスに対応する鍵のシーケンスが、生成される。鍵派生パスのn番目の要素に対応する鍵は、(生成される最後の鍵以外の)シーケンスのn+1番目の要素に対応する鍵の親鍵である。したがって、それぞれの生成された鍵は、それぞれのその他の生成された鍵にリンクされ、親-子リンクか、または間接的に、たとえば、祖父母-孫リンクかのどちらかを有する。
【0021】
このようにして鍵を生成する1つ利点は、たとえば、それらの鍵が失われるかまたは使用後に削除される場合に、後で同じ鍵を再生成することが迅速で容易であることである。すなわち、同じデータパスが、同じ鍵派生パスを生成するために使用されることが可能であり、それが、ひいては、同じ鍵が生成することを可能にする。鍵が再生成されると、それらの鍵は、意図されたように使用され得る。
【0022】
一部の実施形態は、アプリケーションにおいて使用されているデータの特定のアイテムに関連するデータパスを生成することと、このデータパスを鍵派生パスに変換することとを含み、その鍵派生パスから、後続の鍵が導出される。次いで、これらの鍵は、ブロックチェーントランザクションに署名するためのECDSA鍵ペアの生成、またはデータアイテムがブロックチェーントランザクションに追加される前のデータアイテムの暗号化のための対称鍵(たとえば、AES鍵)の生成を含む、複数の目的で使用される場合がある。
【0023】
さらに、一部の実施形態においては、データパス自体が、それが派生パスに変換される前に難読化される。これは、パス変換および鍵導出のプロセスがある関係者によって実行されることを、その関係者が基礎データにアクセスすることができること、またはアプリケーションのデータベースの全体的な構造を明らかにすることなしに可能にする。
【0024】
階層的鍵構造はBIP32プロトコルによって提案された階層的鍵構造に限定されないが、それは1つの選択肢であることに留意されたい。本明細書において提供される例示的なユースケースは主にブロックチェーンに関連するものであるが、説明される実施形態は、任意の関連する状況における鍵の使用に広く当てはまることも留意されたい。たとえば、子鍵は、テクノロジーの多くの分野に応用されているデジタル署名を生成するためのプライベート鍵として使用されてよい。別の例として、子鍵は、任意の状況において暗号鍵として使用されてよい。
【0025】
本開示の実施形態の理解を助け、そのような実施形態がどのようにして実施されてよいかを示すために、添付の図面が、例としてのみ参照される。
【図面の簡単な説明】
【0026】
【図1】ブロックチェーンを実装するためのシステムの概略的なブロック図である。
【図2】ブロックチェーンに記録されてよいトランザクションのいくつかの例を概略的に示す図である。
【図3A】クライアントアプリケーションの概略的なブロック図である。
【図4】HDウォレットの鍵のツリー状構造を概略的に示す図である。
【図5】子拡張(extended)プライベート鍵およびチェーンコードの生成を概略的に示す図である。
【図6】HDウォレットのための例示的な子鍵導出関数を概略的に示す図である。
【図7】子鍵を生成するための例示的なシステムを概略的に示す図である。
【図8】パス変換プロセスを概略的に示す図である。
【図9】パス変換の後に発生する鍵導出プロセスを概略的に示す図である。
【図10】パス難読化プロセスを概略的に示す図である。
【図11】データパスから、生成された鍵のセットまでのプロセスフローを概略的に示す図である。
【図12a】データを暗号化し、ブロードキャストするための例示的なプロセスを概略的に示す図である。
【図12b】データを暗号化し、ブロードキャストするための例示的なプロセスを概略的に示す図である。
【発明を実施するための形態】
【0027】
例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。
【0028】
各ブロックチェーンノード104は、ピアのコンピュータ機器を含み、ノード104のうちの異なるノードは、異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などのその他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをも含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。
【0029】
ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク106の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。そうではなく、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(下で検討される)を記憶する限り、ブロックチェーン150は、データを刈り込まれる場合がある。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルの種類に依存する。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを使用する。1つのよくある種類のトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、財産としてのデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされるユーザ103である(ロックを解除され、それによって、履行または消費されるためにはそのユーザの署名またはその他の解決策を必要とする)。各入力は、先行トランザクション152の出力を後ろ向きに指し示し、それによって、トランザクションをリンクする。
【0030】
各ブロック151は、ブロック151までの連続的な順序を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。(コインベーストランザクション以外)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153まで遡る。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。
【0031】
ブロックチェーンノード104の各々は、トランザクション152をその他のブロックチェーンノード104に転送し、それによって、トランザクション152をネットワーク106全体に伝播させるように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれらのブロックチェーンノード104のそれぞれのメモリに記憶するように構成される。また、各ブロックチェーンノード104は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられたセット(または「プール」)154を維持する。順序付けられたプール154は、多くの場合「メムプール(mempool)」と呼ばれる。本明細書におけるこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルにも限定するように意図されていない。この用語は、ノード104が有効であるものとして受け入れ、ノード104が同じ出力を消費しようとするいかなるその他のトランザクションも受け入れないことを義務付けられるトランザクションの順序付けられたセットを指す。
【0032】
所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことを指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない(孤児(orphan)トランザクションに関する下の議論を参照されたい)。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。
【0033】
現在のトランザクション152jの入力は、入力の認可、たとえば、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。そして今度は、現在のトランザクション152jの出力が、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行トランザクション152iの入力で定義された額を、現在のトランザクション152jの出力で定義されたように新しいユーザまたはエンティティ103bに送金することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、お釣りを渡すために元のユーザまたはエンティティ103aである可能性がある)の間で入力額を分けるために複数の出力を有する場合がある。場合によっては、トランザクションは、1つまたは複数の先行トランザクションの複数の出力からの金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することも可能である。
【0034】
ビットコインのような出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの関係者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のネットワーク全体に伝播される。
【0035】
出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り振られる(たとえば、消費される)かどうかの定義は、その出力がブロックチェーンノードプロトコルに従って別のオンワードトランザクション(onward transaction)152jの入力によって既に有効に履行されたかどうかということである。トランザクションが有効であるための別の条件は、それが履行しようと試みる先行トランザクション152iの出力が別のトランザクションによって既に履行されていないことである。やはり、有効でない場合、トランザクション152jは(警告のために無効であるものとしてフラグを立てられ、伝播されるのでない限り)伝播されず、ブロックチェーン150に記録されない。これは、トランザクションを行う者が同じトランザクションの出力を2回以上割り振ろうとする二重支払いを防ぐ。一方、アカウントベースのモデルは、アカウントの残高を維持することによって二重支払いを防止する。やはり、トランザクションの定義された順序が存在するので、アカウントの残高は、常に単一の定義された状態を有する。
【0036】
トランザクションを承認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうとさらに競争する。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたプール154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスが保留トランザクションの順序付けられたプール154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他のパズルは除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード104において相当大量の処理リソースを消費する。
【0037】
パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークのその他のブロックチェーンノード104によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード104は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード104の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード104の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に承認されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク106のブロックチェーンノード104の各々において認識され、維持されるので、修正され得ない。また、ブロックポインタ155は、ブロック151に連続的な順序を付与する。トランザクション152がネットワーク106の各ブロックチェーンノード104の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。
【0038】
任意の所与の時間にパズルを解こうと競争している異なるブロックチェーンノード104は、それらのブロックチェーンノード104がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションのプール154の異なるスナップショットに基づいてそうしている場合があることに留意されたい。最初にそれらのそれぞれのパズルを解いた者は誰でも、どのトランザクション152が次の新しいブロック151nにどの順番で含まれるかを定義し、未公開のトランザクションの現在のプール154が、更新される。それから、ブロックチェーンノード104は、未公開のトランザクションの新たに定義された順序付けられたプール154からブロックを作成しようと競争を続け、以下同様である。発生する可能性があるすべての「フォーク(fork)」を解決するためのプロトコルも存在し、フォークは、ブロックチェーンの相反するビュー(view)がノード104の間で伝播されるように、2つのブロックチェーンノード104が互いに非常に短い時間内にそれらのブロックチェーンノード104のパズルを解く地点である。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最終的なブロックチェーン150となる。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであることに留意されたい。
【0039】
ビットコインブロックチェーン(およびほとんどのその他のブロックチェーン)によれば、新しいブロック104を成功裏に構築するノードは、(ある額のデジタル資産を、あるエージェントまたはユーザから別のエージェントまたはユーザに送金する、エージェント間またはユーザ間トランザクションとは対照的に)追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、追加の認められた額のデジタル資産を新たに割り振る能力を付与される。この特別な種類のトランザクションは、通常「コインベーストランザクション」と呼ばれるが、「イニシエーション(initiation)トランザクション」または「生成(generation)トランザクション」と呼ばれる場合もある。この特別な種類のトランザクションは、概して、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクショが後で履行されることを可能にするプロトコルの規則に従うという、新しいブロックを構築するノードの意図を知らせる。ブロックチェーンプロトコルの規則は、この特別なトランザクションが履行される前に、満期期間(maturity period)、たとえば、100ブロックを必要とする場合がある。多くの場合、通常の(非生成(non-generation))トランザクション152は、トランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加の取引手数料も指定する。この手数料は、通常「取引手数料」と呼ばれ、下で検討される。
【0040】
トランザクションの承認および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード104の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード104は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。
【0041】
各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそのそれぞれの1つの役割または複数の役割を実行し、トランザクション152を処理するために、ブロックチェーンノード104の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード104に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行されてよいことが理解されるであろう。ノードソフトウェアは、アプリケーションレイヤの1つもしくは複数のアプリケーションに、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより下位のレイヤに、またはこれらの任意の組合せで実装されてよい。
【0042】
ネットワーク101にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワーク106とインタラクションする場合があるが、トランザクションの承認、またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合がある。その他のユーザは、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。
【0043】
関係者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の関係者」によって置き換えられてよいことが理解されるであろう。
【0044】
各関係者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つまたは複数のその他のネットワーク化されたリソースも含む場合がある。
【0045】
クライアントアプリケーション105は、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103のコンピュータ機器102に提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。
【0046】
クライアントアプリケーション105は、少なくとも「ウォレット」機能を含む。これは、2つの主な機能を有する。これらのうちの一方は、それぞれの関係者103が、トランザクション152を作成し、承認し(たとえば、署名し)、その後ブロックチェーンノード104のネットワーク全体に伝播され、それによって、ブロックチェーン150に含められるように1つまたは複数のビットコインノード104に送信することを可能にすることである。他方は、それぞれの関係者が現在所有しているデジタル資産の額の報告をその関係者に返すことである。出力ベースのシステムにおいて、この第2の機能は、問題にしている関係者に属する、ブロックチェーン150全体に散在する様々なトランザクション152の出力に定義された額を照合することを含む。
【0047】
注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIによってインターフェースをとる、または1つがそれ以外に対するプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。
【0048】
各コンピュータ機器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によって同じノードプロトコルが使用される。
【0049】
所与の関係者103、たとえば、Aliceが、ブロックチェーン150に含められるように新しいトランザクション152jを送信したいとき、その関係者103は、(その関係者103のクライアントアプリケーション105のウォレット機能を使用して)関連するトランザクションプロトコルに従って新しいトランザクションを組み立てる。そして、その関係者103は、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最良に接続されているブロックチェーンノード104である可能性がある。任意の所与のブロックチェーンノード104は、新しいトランザクション152jを受信するとき、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってその新しいトランザクション152jを処理する。これは、新しく受信されたトランザクション152jが「有効」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例は、まもなくより詳細に検討される。一部のトランザクションプロトコルにおいて、承認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能である場合がある。代替的に、条件は、単にノードプロトコルの組み込まれた特徴であるか、またはスクリプトとノードプロトコルとの組合せによって定義される可能性がある。
【0050】
新たに受信されたトランザクション152jが有効とみなされるためのテストに合格することを条件に(すなわち、新たに受信されたトランザクション152jが「承認される」ことを条件に)、トランザクション152jを受信するすべてのブロックチェーンノード104は、そのブロックチェーンノード104において維持されるトランザクション154の順序付けられたセットに、新しい承認されたトランザクション152を追加する。さらに、トランザクション152jを受信するすべてのブロックチェーンノード104は、承認されたトランザクション152をネットワーク106の1つまたは複数のその他のブロックチェーンノード104に向かって伝播させる。各ブロックチェーンノード104が同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、トランザクション152jがネットワーク106全体にすぐに伝播されることを意味する。
【0051】
所与のブロックチェーンノード104において維持される保留トランザクションの順序付けられたプール154に入れられると、そのブロックチェーンノード104は、新しいトランザクション152を含むそれらのそれぞれのプール154の最新バージョンに関するプルーフオブワークのパズルを解く競い合いを開始する(その他のブロックチェーンノード104はトランザクションの異なるプール154に基づくパズルを解こうとしている可能性があるが、誰であれ最初に成功する者が最新のブロック151に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたプール154の一部に関するパズルを解く)。新しいトランザクション152jを含むプール54に関してプルーフオブワークが行われると、順序付けられたセット154は、変更不可能であるようにしてブロックチェーン150のブロック151のうちの1つの一部となる。各トランザクション152は、それ以前のトランザクションに戻るポインタを含み、したがって、トランザクションの順序も変更不可能であるようにして記録される。
【0052】
異なるブロックチェーンノード104は、最初に、所与のトランザクションの異なるインスタンスを受信し、したがって、1つのインスタンスが新しいブロック151で公開される前は、どのインスタンスが「有効」であるかについての相反するビューを有する可能性があり、1つのインスタンスが新しいブロック151で公開された時点で、すべてのブロックチェーンノード104は、公開されたインスタンスが唯一の有効なインスタンスであると合意する。ブロックチェーンノード104が1つのインスタンスを有効であるものとして受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されたことを発見する場合、そのブロックチェーンノード104は、これを受け入れなければならず、そのブロックチェーンノード104が最初に受け入れたインスタンス(すなわち、ブロック151で公開されなかったインスタンス)を破棄する(すなわち、無効であるものとして扱う)。
【0053】
一部のブロックチェーンネットワークによって運用される代替的な種類のトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」のプロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムにおいて、トランザクションは、アカウントの実行中の取引勘定(running transaction tally)(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、送信者によって送信者の暗号署名の一部として署名され、トランザクション参照計算(transaction reference calculation)の一部としてハッシュされる。さらに、オプションのデータフィールドが、トランザクションに署名される場合もある。このデータフィールドは、たとえば、前のトランザクションIDがデータフィールドに含まれる場合、前のトランザクションを後ろ向きに指し示す場合がある。
【0054】
UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は、1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、すべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルは、ビットコインに関連して説明されるが、その他の例示的なブロックチェーンネットワークに同様に実装されてよいことに留意されたい。
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は、1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、すべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルは、ビットコインに関連して説明されるが、その他の例示的なブロックチェーンネットワークに同様に実装されてよいことに留意されたい。
【0055】
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に記憶される。
【0056】
Alice103aが、問題にしているデジタル資産の額をBob103bに送金するトランザクション152jを作成したいものとする。図2において、Aliceの新しいトランザクション152jは、「Tx1」とラベル付けされている。トランザクション152jは、シーケンス内の先行トランザクション152iの出力203においてAliceにロックされているデジタル資産の額を取得し、このうちの少なくとも一部をBobに送金する。先行トランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、任意のラベルであるに過ぎない。それらは、必ずしも、Tx0がブロックチェーン151の最初のトランザクションであることも、Tx1がプール154内のすぐ次のトランザクションであることも意味しない。Tx1は、Aliceにロックされた未使用の出力203をまだ持っている任意の先行する(すなわち、先祖)トランザクションを後ろ向きに指し示す可能性がある。
【0057】
先行トランザクションTx0は、Aliceが自身の新しいトランザクションTx1を作成するときに、または少なくともAliceがその新しいトランザクションTx1をネットワーク106に送信するまでに、既に承認され、ブロックチェーン150のブロック151に含められている可能性がある。先行トランザクションTx0は、そのとき、既にブロック151のうちの1つに含められている可能性があり、または順序付けられたセット154内でまだ待っている可能性があり、その場合は、先行トランザクションTx0は、すぐに新しいブロック151に含められる。代替的に、Tx0およびTx1は、一緒に作成され、ネットワーク106に送信される可能性があり、またはノードプロトコルが「孤児」トランザクションをバッファリングすることを許す場合、Tx0がTx1の後に送信される可能性さえある。本明細書においてトランザクションのシーケンスの文脈で使用される用語「先行」および「後続」は、トランザクションにおいて指定されたトランザクションポインタによって定義されるシーケンス内のトランザクションの順序(どのトランザクションがどのその他のトランザクションを後ろ向きに指し示すかなど)を指す。それらの用語は、「先任者」および「後任者」、または「先祖」および「子孫」、「親」および「子」などによって等しく置き換えられる可能性がある。それは、必ずしも、それらのトランザクションが作成される、ネットワーク106に送信される、または任意の所与のブロックチェーンノード104に到着する順序を示唆しない。しかしながら、先行トランザクション(先祖トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまで、また承認されない限り、承認されない。その親の前にブロックチェーンノード104に到着する子は、孤児とみなされる。その子は、ノードプロトコルおよび/またはノードの挙動に応じて、廃棄されるか、または親を待つために特定の時間バッファリングされる場合がある。
【0058】
先行トランザクションTx0の1つまたは複数の出力203のうちの1つは、ここではUTXO0とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが承認され、したがって、UTXOが成功裏に履行されるために後続のトランザクションの入力202内のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。概して、ロックスクリプトは、額を特定の関係者(そのロックスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、概して、後続のトランザクションの入力のロック解除スクリプトが先行トランザクションがロックされている関係者の暗号署名を含むという条件を含むロック解除条件を定義する。
【0059】
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で記述されたコード片である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、どの情報がトランザクション出力203を消費するために必要とされるか、たとえば、Aliceの署名の必要を指定する。ロック解除スクリプトは、トランザクションの出力に現れる。ロック解除スクリプト(別名scriptSig)は、ロックスクリプトの基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で記述されたコード片である。たとえば、ロック解除スクリプトは、Bobの署名を含む場合がある。ロック解除スクリプトは、トランザクションの入力202に現れる。
【0060】
したがって、図示された例において、Tx0の出力203のUTXO0は、UTXO0が履行されるために(厳密には、UTXO0を履行しようと試みる後続のトランザクションが有効であるために)Aliceの署名Sig PAを必要とするロックスクリプト[Checksig PA]を含む。[Checksig PA]は、Aliceの公開-プライベート鍵のペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、(たとえば、実施形態においてはトランザクションTx0全体のハッシュであるTx0トランザクションID、TxID0によって、)Tx0を後ろ向きに指し示すポインタを含む。Tx1の入力202は、Tx0の任意のその他の可能な出力の中でUTXO0を特定するために、Tx0内のUTXO0を特定するインデックスを含む。Tx1の入力202は、さらに、Aliceが鍵ペアからの自身のプライベート鍵をデータの予め定義された部分(暗号技術においては「メッセージ」と呼ばれることがある)に適用することによって作成されたAliceの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにAliceによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義される場合がある。
【0061】
新しいトランザクションTx1がブロックチェーンノード104に到着するとき、ノードは、ノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトにおいて定義された条件(この条件は1つまたは複数の基準を含む場合がある)を満たすかどうかをチェックすることを含む。実施形態において、これは、2つのスクリプトを連結すること、すなわち、
<Sig PA> <PA> || [Checksig PA]
を含み、「||」は、連結を表し、「<...>」は、スタックにデータを置くことを意味し、「[...]」は、ロックスクリプト(この例においては、スタックベースの言語)によって含まれる関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順々に実行されてよい。いずれにせよ、一緒に実行されるとき、スクリプトは、Tx0の出力のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx1の入力のロック解除スクリプトがデータの期待される部分に署名するAliceの署名を含むことを認証する。データの期待される部分自体(「メッセージ」)も、この認証を実行するために含められる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、平文のデータの署名された部分を指定する別個の要素は、それが既に本質的に存在するので含められる必要がない)。
<Sig PA> <PA> || [Checksig PA]
を含み、「||」は、連結を表し、「<...>」は、スタックにデータを置くことを意味し、「[...]」は、ロックスクリプト(この例においては、スタックベースの言語)によって含まれる関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順々に実行されてよい。いずれにせよ、一緒に実行されるとき、スクリプトは、Tx0の出力のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx1の入力のロック解除スクリプトがデータの期待される部分に署名するAliceの署名を含むことを認証する。データの期待される部分自体(「メッセージ」)も、この認証を実行するために含められる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、平文のデータの署名された部分を指定する別個の要素は、それが既に本質的に存在するので含められる必要がない)。
【0062】
公開-プライベート暗号技術による認証の詳細は、当業者によく知られているであろう。基本的に、Aliceが自身のプライベート鍵を使用してメッセージに署名した場合、Aliceの公開鍵および平文のメッセージがあれば、ノード104などの別のエンティティは、そのメッセージがAliceによって署名されたに違いないことを認証することができる。署名は、通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって、公開鍵のすべての保有者が署名を認証することを可能にする。したがって、特定のデータまたはトランザクションの一部などに署名することへの本明細書におけるすべての言及は、実施形態においては、そのデータまたはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
【0063】
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内の別の有効なトランザクションへの有効な入力を既に形成したかどうかということである。
【0064】
所与のトランザクション152のすべての出力203において指定された総額が、そのトランザクション152のすべての入力202によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効の別の根拠となる。したがって、そのようなトランザクションは、伝播されず、ブロック151に含められることもない。
【0065】
UTXOベースのトランザクションモデルにおいて、所与のUTXOは、丸ごと使用される必要があることに留意されたい。所与のUTXOは、UTXOにおいて使用済みとして定義された額の一部分を「残しておく」ことができない一方で、別の部分が消費される。ただし、UTXOからの額は、次のトランザクションの複数の出力の間で分けられ得る。たとえば、Tx0のUTXO0において定義された額が、Tx1の複数のUTXOの間で分けられ得る。したがって、Aliceは、BobにUTXO0において定義された額のすべてを与えたくない場合、残りを使ってTx1の第2の出力において自分自身にお釣りを与えるかまたは別の関係者に支払いをすることができる。
【0066】
実際には、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において明示的に指定される可能性があることは、必ずしも除外されない。
【0067】
AliceおよびBobのデジタル資産は、ブロックチェーン150の任意の場所の任意のトランザクション152においてAliceおよびBobにロックされたUTXOから成る。したがって、典型的には、所与の関係者103の資産は、ブロックチェーン150全体の様々なトランザクション152のUTXO全体に散在している。ブロックチェーン150のどこにも、所与の関係者103の総残高を定義する1つの数字は記憶されていない。それぞれの関係者にロックされ、別のオンワードトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を照合することは、クライアントアプリケーション105内のウォレット機能の役割である。ウォレット機能は、ビットコインノード104のいずれかに記憶されたブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。
【0068】
スクリプトコードは、概略的に表現されることが多い(つまり、正確な言語を使用しない)ことに留意されたい。たとえば、特定の機能を表現するためにオペレーションコード(オペコード)を使用する場合がある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの始めにOP_FALSEが先にあるとき、トランザクション内にデータを記憶することができ、それによって、ブロックチェーン150にデータを変更不可能であるようにして記録することができるトランザクションの消費不可能な出力を作成するScript言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を含む可能性がある。
【0069】
概して、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。一部の実施形態において、所与のトランザクションに関して、署名は、トランザクション入力の一部と、トランザクション出力の一部またはすべてに署名する。署名が署名する出力の特定の部分は、SIGHASHフラグに応じて決まる。SIGHASHフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名する時点で決まっている)4バイトのコードである。
【0070】
ロックスクリプトは、概してそれがそれぞれのトランザクションがロックされている関係者の公開鍵を含むという事実を示して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、通常、それが対応する署名を供給するという事実を示して、「scriptSig」と呼ばれることがある。しかし、より広く、UTXOが履行されるための条件が署名を認証することを含むことは、ブロックチェーン150のすべての応用において必須ではない。より広く、スクリプト言語が、任意の1つまたは複数の条件を定義するために使用される可能性がある。したがって、より広い用語「ロックスクリプト」および「ロック解除スクリプト」が、好ましい場合がある。
【0071】
サイドチャネル
図1に示されたように、AliceおよびBobのコンピュータ機器102a、120bの各々のクライアントアプリケーションは、追加の通信機能を含む場合がある。この追加の機能は、Alice103aが、(どちらかの関係者または第三者の勧めによって)Bob103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別にデータのやりとりを可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、関係者の一方がトランザクション152をネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されていない、またはチェーン150に向かって進んでいない状態で、AliceとBobとの間でトランザクション152をやりとりするために使用される場合がある。このようにしてトランザクションを共有することは、「トランザクションテンプレート(transaction template)」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる1つまたは複数の入力および/または出力を欠いている場合がある。代替的または追加的に、サイドチャネル107は、鍵、交渉された額または条項、データ内容などの任意のその他のトランザクション関連データをやりとりするために使用される場合がある。
図1に示されたように、AliceおよびBobのコンピュータ機器102a、120bの各々のクライアントアプリケーションは、追加の通信機能を含む場合がある。この追加の機能は、Alice103aが、(どちらかの関係者または第三者の勧めによって)Bob103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別にデータのやりとりを可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、関係者の一方がトランザクション152をネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されていない、またはチェーン150に向かって進んでいない状態で、AliceとBobとの間でトランザクション152をやりとりするために使用される場合がある。このようにしてトランザクションを共有することは、「トランザクションテンプレート(transaction template)」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる1つまたは複数の入力および/または出力を欠いている場合がある。代替的または追加的に、サイドチャネル107は、鍵、交渉された額または条項、データ内容などの任意のその他のトランザクション関連データをやりとりするために使用される場合がある。
【0072】
サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立されてよい。代替的または追加的に、サイドチャネル301は、モバイルセルラネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはAliceおよびBobのデバイス102a、102bの間の直接有線もしくは無線リンクなどの異なるネットワークを介して確立されてよい。概して、本明細書のどこで言及されるサイドチャネル107も、「オフチェーン」、すなわち、ブロックチェーンネットワーク106とは別でデータをやりとりするための1つまたは複数のネットワーキングテクノロジーまたは通信媒体を介した任意の1つまたは複数のリンクを含んでよい。2つ以上のリンクが使用される場合、オフチェーンリンクの束または集合が全体としてサイドチャネル107と呼ばれる場合がある。したがって、AliceおよびBobがサイドチャネル107を介して特定の情報またはデータなどをやりとりすると言われる場合、これは、これらのデータすべてがまったく同じリンクまたはさらには同じ種類のネットワーク上で送信されなければならないことを必ずしも示唆しないことに留意されたい。
【0073】
クライアントソフトウェア
図3Aは、今開示されている方式の実施形態を実施するためのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を含む。トランザクションエンジン401は、上で検討された方式に従っておよびまもなくさらに詳細に検討されるように、トランザクション152を組み立てること、サイドチャネル301を介してトランザクションおよび/もしくはその他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて伝播するように1つもしくは複数のノード104にトランザクションを送信することなどの、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。
図3Aは、今開示されている方式の実施形態を実施するためのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を含む。トランザクションエンジン401は、上で検討された方式に従っておよびまもなくさらに詳細に検討されるように、トランザクション152を組み立てること、サイドチャネル301を介してトランザクションおよび/もしくはその他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて伝播するように1つもしくは複数のノード104にトランザクションを送信することなどの、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。
【0074】
UIレイヤ402は、機器102のユーザ出力手段を介してそれぞれのユーザ103に情報を出力すること、および機器102のユーザ入力手段を介してそれぞれのユーザ103から返ってくる入力を受け取ることを含め、それぞれのユーザのコンピュータ機器102のユーザ入力/出力(I/O)手段を介してユーザインターフェースを提供するように構成される。たとえば、ユーザ出力手段は、視覚的出力を提供するための1つもしくは複数のディスプレイスクリーン(タッチスクリーンもしくは非タッチスクリーン)、音声出力を提供するための1つもしくは複数のスピーカ、および/または触覚的出力を提供するための1つもしくは複数の触覚出力デバイスなどを含む可能性がある。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーン(出力手段に使用されるものと同じもしくは異なる)、マウス、トラックパッド、もしくはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、スピーチもしくは発声入力を受け取るための1つもしくは複数のマイクロフォンおよび音声もしくは声認識アルゴリズム、手もしくは体のジェスチャの形態の入力を受け取るための1つもしくは複数のジェスチャベースの入力デバイス、または1つもしくは複数の機械式ボタン、スイッチ、もしくはジョイスティックなどの入力アレイ(input array)を含む可能性がある。
【0075】
注:本明細書における様々な機能は同じクライアントアプリケーション105に統合されるものとして説明される場合があるが、これは、必ずしも限定的ではなく、その代わりに、それらの機能は、たとえば、一方が他方に対するプラグインであるか、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースをとる、2つ以上の異なるアプリケーションのスイートに実装される可能性がある。たとえば、トランザクションエンジン401の機能は、UIレイヤ402とは別個のアプリケーションに実装されてよく、またはトランザクションエンジン401などの所与のモジュールの機能は、2つ以上のアプリケーションの間で分けられる可能性がある。説明される機能の一部またはすべてが、たとえば、オペレーティングシステムレイヤに実装される可能性があることも排除されない。本明細書の任意の箇所で単一のまたは所与のアプリケーション105などへの言及がなされる場合、これは単なる例示であり、より広く、説明された機能は任意の形態のソフトウェアで実装される可能性があることが理解されるであろう。
【0076】
図3Bは、Aliceの機器102aのクライアントアプリケーション105aのUIレイヤ402によってレンダリングされる場合があるユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、Bobの機器102bのクライアント105b、または任意のその他の関係者の機器のクライアントによってレンダリングされてよいことは理解されるであろう。
【0077】
例示として、図3Bは、Aliceの観点でUI500を示す。UI500は、ユーザ出力手段を介して異なるUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を含んでよい。
【0078】
たとえば、UI要素は、異なる画面上のボタン、またはメニューの異なる選択肢などである場合がある1つまたは複数のユーザが選択可能な要素501を含んでよい。ユーザ入力手段は、ユーザ103(この場合、Alice103a)が、画面上のUI要素をクリックもしくはタッチするか、または所望の選択肢の名前を言うことによるなどして、選択肢のうちの1つを選択するかまたはそれ以外の方法で操作することを可能にするように配置される(本明細書において使用される用語「手動」は、自動と対照を成すことを意図されているに過ぎず、必ずしも1つの手または複数の手の使用に限定されないことに注意されたい)。選択肢は、ユーザ(Alice)が、実施形態によって子鍵を生成するときに使用されるメッセージを選択することを可能にする。
【0079】
代替的または追加的に、UI要素は、1つまたは複数のデータ入力フィールド502を含んでよく、それらのデータ入力フィールド502を通じて、ユーザは、実施形態によって子鍵を生成するときに使用されるメッセージを入力することができる。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえば、画面上にレンダリングされ、データは、ユーザ入力手段、たとえば、キーボードまたはタッチスクリーンを通じてフィールドに入力され得る。代替的に、データは、たとえば、音声認識に基づいて口述でデータを受け取る可能性がある。
【0080】
代替的または追加的に、UI要素は、ユーザに対して情報を出力するための1つまたは複数の情報要素503の出力を含んでよい。たとえば、これ/これらは、画面上にまたは聞こえるようにレンダリングされる可能性がある。
【0081】
様々なUI要素をレンダリングし、選択肢を選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能は、まもなくより詳細に検討される。図3に示されたUI500は図式化されたモックアップであるに過ぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を含む場合があることも理解されるであろう。
【0082】
HDウォレット
BIP32
BIP32仕様に準拠したHDウォレットプロトコルは、2つのコアメカニズム、すなわち、
1.鍵の導出 - 単一のシードから鍵ペアのツリーを導出するためのシステム。
2.派生パス(derivation path) - そのようなツリーの上にウォレット構造を定義する。
を詳述する。
BIP32
BIP32仕様に準拠したHDウォレットプロトコルは、2つのコアメカニズム、すなわち、
1.鍵の導出 - 単一のシードから鍵ペアのツリーを導出するためのシステム。
2.派生パス(derivation path) - そのようなツリーの上にウォレット構造を定義する。
を詳述する。
【0083】
以下で、BIP32プロトコルによるHDウォレットの作成に含まれるステップの概要を提供する。完全な検討に関しては、https://github.com/bitcoin/bips/blob/master/bip-0032.mediawikiを参照されたい。
【0084】
鍵の導出
I.バイナリシードを生成する。ユーザは、まず、シードS、通常は12単語のフレーズ(128～512ビット)を選択する。BIP39に概説されている仕様が、ニーモニックコード(mnemonic code)からバイナリシードを生成するためによく使用される。ユーザは、自分のニーモニックをパスフレーズで保護すると決める場合もある(さらなる詳細に関してはBIP39参照)。
I.バイナリシードを生成する。ユーザは、まず、シードS、通常は12単語のフレーズ(128～512ビット)を選択する。BIP39に概説されている仕様が、ニーモニックコード(mnemonic code)からバイナリシードを生成するためによく使用される。ユーザは、自分のニーモニックをパスフレーズで保護すると決める場合もある(さらなる詳細に関してはBIP39参照)。
【0085】
II.マスタ拡張プライベート鍵を生成する。マスタプライベート鍵mは、以下のようにシードから導出される。
1.
1.
【0086】
【数2】
【0087】
を計算し、式中、opadは、値0x5cの繰り返されるバイトからなる128バイトのサイズの外側パディング(outer padding)であり、ipadは、値0x36の繰り返されるバイトからなる128バイトのサイズの内側パディング(inner padding)である。
2.Iを2つの32バイトのシーケンス、ILおよびIRに分ける。
3.parse256(IL)使用して、32バイトのシーケンスを(最上位バイトが最初に来る)256ビット数のマスタ拡張プライベート鍵mとして解釈し、IRを256ビット数のマスタチェーンコードとして解釈する。
2.Iを2つの32バイトのシーケンス、ILおよびIRに分ける。
3.parse256(IL)使用して、32バイトのシーケンスを(最上位バイトが最初に来る)256ビット数のマスタ拡張プライベート鍵mとして解釈し、IRを256ビット数のマスタチェーンコードとして解釈する。
【0088】
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に概略的に示される。
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に概略的に示される。
【0089】
IV.拡張鍵フォーマットをシリアル化する。拡張公開(xpub)または拡張プライベート(xprv)鍵は、78バイトのデータ構造
[マジック(magic)][深さ(depth)][親のフィンガープリント][鍵インデックス][チェーンコード][鍵]
のbase58で符号化されたシリアル化である。個々のデータ要素の説明は、Table 1(表1)にまとめられている。
[マジック(magic)][深さ(depth)][親のフィンガープリント][鍵インデックス][チェーンコード][鍵]
のbase58で符号化されたシリアル化である。個々のデータ要素の説明は、Table 1(表1)にまとめられている。
【0090】
親のフィンガープリントは、ウォレットソフトウェアにおいて親および子ノードを検出するための高速な方法であることに留意されたい。内部的には、完全な160ビットの識別子が、フィンガープリントにおけるすべてのハッシュの衝突に対処するために使用される可能性がある。
【0091】
【表1】
【0092】
base58表現に変換する前に(ダブルSHA-256(double SHA-256)チェックサムから導出された)32ビットのチェックサムがまず追加され、これは、メインネットで「xprv」もしくは「xpub」で始まるかまたはテストネットで「tprv」もしくは「tpub」で始まるかのどちらかの最大112文字の文字列をもたらす。
【0093】
シリアル化されたxpubをインポートするとき、実装は、公開鍵データのX座標が曲線上の点に対応するかどうかも検証しなければならない。公開鍵データのX座標が曲線上の点に対応しない場合、拡張公開鍵は無効とみなされる。
【0094】
派生パス
32ビットの鍵インデックスiは、通常の鍵に関して0x00から0x7fffffffまで(0から231 - 1まで)、強化された鍵に関して0x80000000から0xffffffffまで(231～232)の範囲である。下付き文字表記(ih)、またはより普通にはプライム記号が、強化された鍵を示すために使用される。ブロックチェーンの開発者は、通常、Unicodeのプライム記号ではなく、ASCIIのアポストロフィーを使用する。たとえば、第1の通常の鍵(0x00)は、i = 0であり、第1の強化された鍵(0x80000000)は、i' = 0'である。
32ビットの鍵インデックスiは、通常の鍵に関して0x00から0x7fffffffまで(0から231 - 1まで)、強化された鍵に関して0x80000000から0xffffffffまで(231～232)の範囲である。下付き文字表記(ih)、またはより普通にはプライム記号が、強化された鍵を示すために使用される。ブロックチェーンの開発者は、通常、Unicodeのプライム記号ではなく、ASCIIのアポストロフィーを使用する。たとえば、第1の通常の鍵(0x00)は、i = 0であり、第1の強化された鍵(0x80000000)は、i' = 0'である。
【0095】
図6は、BIP32仕様から抜粋された概略図で子鍵派生パスを示す。派生パスは、「/」によって区切られたn個の鍵インデックスのnタプルとして定義される。BIP32 HDウォレットに関して、パスは、3つのレベルまたは深さからなり(m/i/j/k)、
m / account' / change / address_index
として定義される。
m / account' / change / address_index
として定義される。
【0096】
マスタプライベート鍵mの後の第1のレベルiは、開示されるBIP32ウォレット構造を包含する。ここで、鍵空間は、たとえば、組織の異なる部門のための通常の銀行口座と同様に、ユーザが自分の資金を異なる「アカウント」に整理することができるように分けられ得る。デフォルトのアカウントは、番号0'(強化された鍵インデックス)であり、連続的に増やされる。
【0097】
第2のレベルjにおいて、各アカウントは、2つの鍵ペアチェーン、すなわち、内部鍵ペアチェーンおよび外部鍵ペアチェーンから構成される。外部鍵チェーン(一定のインデックスj = 0)は、新しい公開受信アドレスを生成するために使用され、一方、内部鍵チェーン(一定のインデックスj = 1)は、アドレスの変更または外部に伝達される必要がないすべてのことなどのすべてのその他の動作のために使用される。
【0098】
最後のレベルkは、インデックス0から付番され、連続的に増加するアドレスを表す。
【0099】
BIP43 - 目的フィールド
BIP32で定義されたツリー構造のフィールドを標準化するために、BIP43仕様(https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)が導入された。特に、BIP43仕様は、マスタ鍵に続く第1のレベルを特別な目的のフィールドとして再定義する。派生パスは、
m / purpose' / *
として定義され、*は、目的フィールドのデータに応じた後続のレベルを表す。これがゼロに設定される場合(i = 0')、これがデフォルトのBIP32ウォレット構造であるので、派生パスにさらに2つのレベルが存在すると予想することができる。
BIP32で定義されたツリー構造のフィールドを標準化するために、BIP43仕様(https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)が導入された。特に、BIP43仕様は、マスタ鍵に続く第1のレベルを特別な目的のフィールドとして再定義する。派生パスは、
m / purpose' / *
として定義され、*は、目的フィールドのデータに応じた後続のレベルを表す。これがゼロに設定される場合(i = 0')、これがデフォルトのBIP32ウォレット構造であるので、派生パスにさらに2つのレベルが存在すると予想することができる。
【0100】
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
として定義される
目的フィールドが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
として定義される
【0101】
アドレスギャップ限度(address gap limit)
BIP44は、アカウントの発見を目的としたアドレスギャップ限度の概念を導入する。ウォレットのソフトウェアは、ある限度を超えた連続する未使用アドレスの検索を止めるようにプログラミングされ得る。これは、アドレスインデックスが連続的に増やされるからである。ギャップ限度は、標準化されておらず、多くの場合、ユーザが構成可能である。通常、ギャップ限度は、20個の鍵に設定されるが、一部のウォレットは、100個の鍵または1000個もの鍵の限度を設定する。ギャップ限度は、親子鍵ではなく兄弟鍵にのみ適用されることに留意されたい。標準的な派生パスが使用されると仮定すると、検索は、2レベルの深さに制限されることが多い。
BIP44は、アカウントの発見を目的としたアドレスギャップ限度の概念を導入する。ウォレットのソフトウェアは、ある限度を超えた連続する未使用アドレスの検索を止めるようにプログラミングされ得る。これは、アドレスインデックスが連続的に増やされるからである。ギャップ限度は、標準化されておらず、多くの場合、ユーザが構成可能である。通常、ギャップ限度は、20個の鍵に設定されるが、一部のウォレットは、100個の鍵または1000個もの鍵の限度を設定する。ギャップ限度は、親子鍵ではなく兄弟鍵にのみ適用されることに留意されたい。標準的な派生パスが使用されると仮定すると、検索は、2レベルの深さに制限されることが多い。
【0102】
アカウントの発見
ユーザが外部ソースから自分のシードをインポートするとき、ウォレットのソフトウェアは、以下の方法でアカウントを発見するためにアドレスギャップ限度を使用することができる。
1.インデックス= 0と設定する。
2.インデックスに対応するアカウントのノードを導出する。
3.このアカウントの外部チェーンノードを導出する。
4.外部チェーンのアドレスをスキャンし、ギャップ限度を守る。
5.外部チェーン上でトランザクションが見つからない場合、発見を停止する。
6.いくつかのトランザクションが存在する場合、アカウントインデックスを1増やし、ステップ2から繰り返す。
ユーザが外部ソースから自分のシードをインポートするとき、ウォレットのソフトウェアは、以下の方法でアカウントを発見するためにアドレスギャップ限度を使用することができる。
1.インデックス= 0と設定する。
2.インデックスに対応するアカウントのノードを導出する。
3.このアカウントの外部チェーンノードを導出する。
4.外部チェーンのアドレスをスキャンし、ギャップ限度を守る。
5.外部チェーン上でトランザクションが見つからない場合、発見を停止する。
6.いくつかのトランザクションが存在する場合、アカウントインデックスを1増やし、ステップ2から繰り返す。
【0103】
内部チェーンは、関連する外部チェーンから来るコインを受け取るだけなので、ブロックチェーンのスキャンは、外部チェーンのみを含む。ウォレットソフトウェアは、ユーザが新しいアドレスを生成することによって外部チェーンのギャップ限度を超えようとしているとき、警告をするべきである。
【0104】
ウォレットの復元
異なるウォレットプロバイダは、ウォレットの復旧中に資金を復元するために異なるプロトコルを備えている。取引所にHDウォレットサービスを提供する企業は、数千の未使用の連続したアドレスを容易に持つことができ、概して、BIP44において提案されたギャップ限度を無視し得る。それらは、その代わりに、すべての生成されたアドレスのリストを保持し、HDウォレットのデータ構造ではなくそれらのアドレスを個々にインデックス付けする。このようにして、知られているトランザクションのキャッシュを保持することは、ユーザがソフトウェアにログインするたびにブロックチェーンに再問い合わせする必要をなくし、軽量クライアントがほんの一握りのノードでそれらのユーザ収容能力をスケールアップすることも可能にしながら、プロセスをより時間効率的にする。
異なるウォレットプロバイダは、ウォレットの復旧中に資金を復元するために異なるプロトコルを備えている。取引所にHDウォレットサービスを提供する企業は、数千の未使用の連続したアドレスを容易に持つことができ、概して、BIP44において提案されたギャップ限度を無視し得る。それらは、その代わりに、すべての生成されたアドレスのリストを保持し、HDウォレットのデータ構造ではなくそれらのアドレスを個々にインデックス付けする。このようにして、知られているトランザクションのキャッシュを保持することは、ユーザがソフトウェアにログインするたびにブロックチェーンに再問い合わせする必要をなくし、軽量クライアントがほんの一握りのノードでそれらのユーザ収容能力をスケールアップすることも可能にしながら、プロセスをより時間効率的にする。
【0105】
UTXO/トランザクション全体を追跡するウォレットプロバイダは、この情報をウォレットサーバに記憶する傾向がある。フルノードに依拠するHDウォレットが、トランザクションの完全なインデックスを保持することができる一方、サーバのシステムは、新しいアドレスごとに付加されるランニングインデックス(running index)を維持する可能性が高い。公開されるあらゆるブロックに関して、ウォレットソフトウェアは、新しいブロック内の各トランザクションをウォレットサーバ内の各アドレスと照合する。このプロセスは、予めインデックス付けされたデータを使用して、および/またはブルームフィルタの助けを借りてより効率化される。
【0106】
子鍵の生成
本発明の実施形態は、階層的鍵構造の子鍵を生成する新規の方法を提供する。概して、階層的鍵構造は、複数のレベルを含み、各レベルは、先行するレベルの少なくとも1つの鍵にリンクされる1つまたは複数の鍵を含む。これに対する例外は、マスタ鍵を含む、通常はマスタレベルと呼ばれる本当に最初のレベルである。マスタ鍵は、通常、任意のデータであってよいシードから導出される。マスタレベルの後に、1つまたは複数の子レベルがある。第n-1のレベルの鍵は、第nのレベルである1つまたは複数の子鍵の親鍵である場合がある。同様に、第nのレベルの鍵は、第nのレベルの親鍵の子鍵であると同時に、第n+1のレベルの1つまたは複数の子鍵の親鍵でもある場合がある。所与のレベルのすべての鍵が、親鍵でなければならないわけではない。たとえば、鍵構造は、マスタ鍵に遡る鍵の多くのブランチを有していてよい。一部のブランチは、その他のブランチよりも長い場合があり、つまり、それらのブランチは、その他のブランチよりも高い(すなわち、より大きい、より遠い、またはより深い)レベルに属する鍵を含む。
本発明の実施形態は、階層的鍵構造の子鍵を生成する新規の方法を提供する。概して、階層的鍵構造は、複数のレベルを含み、各レベルは、先行するレベルの少なくとも1つの鍵にリンクされる1つまたは複数の鍵を含む。これに対する例外は、マスタ鍵を含む、通常はマスタレベルと呼ばれる本当に最初のレベルである。マスタ鍵は、通常、任意のデータであってよいシードから導出される。マスタレベルの後に、1つまたは複数の子レベルがある。第n-1のレベルの鍵は、第nのレベルである1つまたは複数の子鍵の親鍵である場合がある。同様に、第nのレベルの鍵は、第nのレベルの親鍵の子鍵であると同時に、第n+1のレベルの1つまたは複数の子鍵の親鍵でもある場合がある。所与のレベルのすべての鍵が、親鍵でなければならないわけではない。たとえば、鍵構造は、マスタ鍵に遡る鍵の多くのブランチを有していてよい。一部のブランチは、その他のブランチよりも長い場合があり、つまり、それらのブランチは、その他のブランチよりも高い(すなわち、より大きい、より遠い、またはより深い)レベルに属する鍵を含む。
【0107】
図7は、本発明の実施形態を実装するための例示的なシステム700を示す。システムは、鍵構造の1つまたは複数の子鍵を生成するように構成された鍵生成器701を含む。BIP32が鍵構造を生成するための例示的なプロトコルとして提供されるが、鍵生成器701は、そのプロトコルに準拠する鍵を生成することに限定されない。たとえば、鍵生成器701によって生成される鍵の長さは、BIP32によって必要とされる長さと異なってよい。逆に、鍵生成器701は、あらゆる要件においてBIP32に確かに準拠する鍵を生成する場合がある。さらに、鍵生成器701によって生成される鍵は、ブロックチェーントランザクションに署名するための署名鍵として、またはブロックチェーンアドレスとして使用するため、たとえば、pay-to-public-keyハッシュ(P2PKH)アドレスのための公開鍵として使用される目的で生成されるとは限らない。
【0108】
言い換えると、本明細書の実施形態がBIPプロトコルへの例示的な応用の観点で説明されるが、より広く、本明細書において開示される原理は、1つまたは複数のレベルの子鍵が親鍵から導出される任意の階層的鍵導出プロトコルに適用され得る。
【0109】
鍵生成器701は、独立した機能もしくはエンティティであってよく、または鍵生成器701は、異なるエンティティ、たとえば、Alice 103aもしくはBob 103bによって構成されてよい。システム700は、パス生成器702も含んでよい。鍵生成器701とは別に示されているが、パス生成器702は、その代わりに、鍵生成器701の構成要素であってよく、たとえば、単一のエンティティが、鍵生成器701およびパス生成器702に帰属するアクションを実行してよい。
【0110】
システムは、ブロックチェーンネットワーク106の1つまたは複数のノード104も含んでよい。追加的または代替的に、システムは、1つまたは複数の第三者、たとえば、Alice 103aおよびBob 103bなどのユーザ、組織、機械などを含んでよく、それらの第三者の任意の役割が、下で検討される。
【0111】
鍵生成器701は、少なくとも1つの親鍵を含む既存の鍵構造を有する。親鍵は、マスタ鍵、またはより深いレベルに属する子鍵(たとえば、マスタ鍵の子鍵)であってよい。代替的に、鍵生成器701は、初めて鍵構造を生成し、生成された鍵構造は、少なくとも1つの親鍵を含む。鍵構造は、シードに基づいて生成される。特に、マスタ鍵が、シードに基づいて生成され、すべてのその他の鍵は、少なくとも間接的にマスタ鍵から導出される。
【0112】
鍵生成器701は、子鍵派生(CKD)パスを取得する。CKDパスは、(下で説明されるように)鍵生成器701によって生成されてよく、またはパス生成器702から受信されてよい。CKDパスは、要素のシーケンスを含む。要素のシーケンスは、要素の1つまたは複数のグループまたはセットによって構成される。一部の例において、グループは、何らかの方法で区別される場合があり、その他の例において、要素がどのようにグループに分けられるかは、要素だけから見分けることができない場合がある。単に鍵を生成する目的であれば、個々のグループが認識可能であるかどうかは重要でない。CKDパスの各要素は、データアイテムに基づいて生成される。すなわち、各要素は、データアイテムの関数である。データアイテムは、下で説明されるデータパスに属している。各グループの要素は、同じデータアイテムに基づいて生成され、異なるグループは、異なるデータアイテムに基づいて生成される。鍵生成器701は、要素がどのようにして生成されたかを知っている可能性があり、または知らない可能性がある。この場合も、鍵を生成する目的であれば、鍵生成器701が要素がどのようにして生成されたかを知っているかどうかは重要ではない。
【0113】
CKDパスの各要素は、鍵構造における生成される鍵の位置に対応する。CKDパスを取得した後、鍵生成器701は、CKDパスの要素に対応する位置でそれぞれの鍵を生成する。
【0114】
たとえば、CKDパスは、4つの要素(m/i/j/k)=(m/2/1/3)を含んでよい。鍵生成器701は、それらの要素に対応する鍵構造内の位置に鍵を生成する。一部の例において、鍵生成器701は、それらの鍵のうちの少なくとも1つにアクセスすることができ、したがって、それらの鍵を再生成する必要がない場合があり、たとえば、鍵生成器701は、マスタ鍵mを記憶する場合がある。この例において、鍵生成器701は、以下の鍵、すなわち、m/2、m/2/1、およびm/2/1/3を生成する。鍵m/2/1/3は、鍵m/2/1の子であり、鍵m/2/1は、鍵m/2/の子であり、鍵m/2/は、鍵mの子である。m/2/1/3は実際には鍵ではなく、正しくは、鍵構造内の鍵の位置を示すことに留意されたい。当業者は、鍵m/2/1/3が、親鍵、祖父母鍵(grandparent key)、およびマスタ鍵が生成された場合にのみ生成され得ることに気付くであろう。
【0115】
CKDパスに基づいて子鍵を生成した後、鍵生成器701は、それらの鍵を記憶してよく、および/またはそれらの鍵を出力してよい。鍵生成器は、それらの鍵の一部のみを記憶または出力する場合がある。鍵を出力することは、鍵を第三者に送信すること、および/または鍵生成器701もしくは鍵生成器701を含むエンティティによって制御される機能に鍵を出力することを含んでよい。鍵生成器701は、どの鍵を出力するかのインジケーション、たとえば、シーケンス内の要素に対応するインデックスを受信する場合がある。すなわち、(CKDパスまたはデータパスの提供者などの)第三者が、CKDパス内の3番目、7番目、および13番目の要素に対応する鍵を要求する場合がある。
【0116】
当業者であれば、公開・プライベート鍵ペアについて熟知しているであろう。簡潔に言えば、プライベート鍵に関数、たとえば、生成元(generator point)の楕円曲線乗算(elliptic curve multiplication)を適用することによって公開鍵が生成される。鍵生成器701は、プライベート鍵または公開鍵を生成するために、説明された技術を使用してよい。
【0117】
一部の例において、子鍵を生成するために使用される親鍵は、プライベート鍵である。結果として得られる子鍵も、プライベート鍵である。そのような鍵は、強化された鍵と呼ばれることが多く、
skchild = skparent + HMAC-SHA512L(cparent, skparent || index)
によって与えられる場合がある。ハッシュ関数は、その他の形態をとる場合があることに留意されたい。
skchild = skparent + HMAC-SHA512L(cparent, skparent || index)
によって与えられる場合がある。ハッシュ関数は、その他の形態をとる場合があることに留意されたい。
【0118】
その他の例において、子鍵を生成するために使用される親鍵は、公開鍵である。この場合、子鍵は、親鍵と、ハッシュ結果に対応する公開鍵とに基づいて生成される。つまり、ハッシュ結果が、公開鍵に変換され、子鍵は、その公開鍵に基づく、すなわち、
pkchild = pkparent + HMAC-SHA512L(cparent, pkparent || index)・G
であり、式中、・Gは、生成元による楕円曲線乗算を表す。
pkchild = pkparent + HMAC-SHA512L(cparent, pkparent || index)・G
であり、式中、・Gは、生成元による楕円曲線乗算を表す。
【0119】
さらにその他の例においては、ハッシュ関数の外の親鍵が、プライベート鍵である場合があり、ハッシュ関数に入力される親鍵が、公開鍵である場合がある。結果として得られる子鍵は、プライベート鍵である。そのような鍵は、強化されていない鍵と呼ばれることが多く、
skchild = skparent + HMAC-SHA512L(cparent, pkparent || index)
によって与えられる場合がある。
skchild = skparent + HMAC-SHA512L(cparent, pkparent || index)
によって与えられる場合がある。
【0120】
鍵生成器701は、子プライベート鍵に対応する公開鍵、たとえば、
pkchild = skchild・G
を生成してよい。
pkchild = skchild・G
を生成してよい。
【0121】
非対称暗号方式の鍵であるのではなく、代わりに、鍵は、対称方式の鍵である場合がある。
【0122】
概して、鍵生成器701によって生成された子鍵は、任意の好適なアプリケーション、たとえば、メッセージの暗号化および復号化による使用のために出力されてよい。たとえば、子公開鍵が、メッセージを暗号化するために使用されてよく、または子プライベート鍵が、対応する子プライベート鍵で暗号化されたメッセージを復号するために使用されてよい。子鍵が対称鍵である場合、メッセージを暗号化し、復号するために同じ子鍵が使用されてよい。
【0123】
子鍵は、デジタル署名を生成するために使用されてもよい。すなわち、子鍵は、メッセージおよびプライベート鍵に基づいてデジタル署名を生成するために使用されるプライベート鍵であってよい。署名は、対応する公開鍵を使用して検証されてよい。
【0124】
子鍵が使用されてよい1つのアプリケーションは、ブロックチェーントランザクションに関連している。たとえば、子鍵は、たとえば、P2PKまたはP2PKH出力を使用してブロックチェーントランザクションの出力がロックされる公開鍵である場合がある。鍵生成器701は、子鍵にロックされている出力を含むトランザクションを生成してよい。代替的に、鍵生成器701は、子鍵を第三者に提供してよく、その第三者が、子鍵にロックされた出力を含むトランザクションを生成してよい。鍵生成器701は、子鍵自体、または子鍵に基づくブロックチェーンアドレス、たとえば、子鍵のハッシュを第3者に提供してよい。トランザクションを生成することは、少なくとも1つのフィールドを欠いているトランザクションテンプレートを生成することを含む場合があることに留意されたい。トランザクションテンプレートは、誰がトランザクションテンプレートを生成したかに応じて、完成のために第三者または鍵生成器701に渡されてよい。それから、完全なトランザクションが、ブロックチェーンネットワーク106に送信されてよい。
【0125】
ブロックチェーンが子公開鍵にロックされたトランザクションを含む場合、鍵生成器701は、その出力を参照し、ロックを解除するように構成される入力を含むトランザクションを生成してよい。入力は、対応する子プライベート鍵を使用して生成された署名を含んでよい。参照される出力のロックスクリプトに応じて、入力は、子公開鍵も含んでよい。
【0126】
鍵生成器701は、複数の子鍵のうちの1つまたは複数を第三者に送信する場合がある。鍵生成器701は、追加的または代替的に、複数の子鍵の各々に関してそれぞれのブロックチェーンアドレスを生成し、それらのアドレスを第三者に送信する場合がある。アドレスは、1つまたは複数のトランザクションテンプレート、たとえば、各アドレスにつき1つのテンプレートに含まれる場合がある。
【0127】
鍵生成器701は、それぞれが生成された子鍵のうちの1つにロックされた少なくとも1つの出力を有する(トランザクションテンプレートである場合がある)1つまたは複数のブロックチェーントランザクションを生成してよい。各トランザクションは、子鍵のうちのそれぞれの子鍵にロックされた単一の出力を含む場合があり、または1つもしくは複数のトランザクションは、子鍵のうちのそれぞれの子鍵にロックされた2つ以上の出力を含む場合がある。鍵生成器701は、ブロックチェーンネットワークまたは第三者にトランザクションを送信してよい。
【0128】
ここでCKDパスに戻ると、CKDパスは、1つまたは複数の下位パスを含んでよい。CKDパスの要素のグループごとに1つの下位パスが存在する場合があり、または等価的に、データパスのデータアイテムごとに1つの下位パスが存在する場合がある。所与のCKDパスの各下位パスは、同じ要素、すなわち、シーケンス内の最初の要素から始まり、それぞれの「終端要素(terminal element)」で終わる。言い換えると、終端要素は、下位パス内の最後の(すなわち、最終の)要素である。CKDパスの各要素は、異なるレベルに属し、各下位パスは、本明細書においては「終端レベル」と呼ばれるシーケンス内の異なるレベルに属する終端要素で終わる。たとえば、ある下位パスの終端要素が、シーケンスの第3のレベルに属す場合がある一方、別の下位パスの終端要素は、シーケンスの第6のレベルに属する場合がある。
【0129】
各終了要素は、鍵構造の異なるレベルの鍵の位置に対応する。したがって、レベルが初期値、たとえば、0から増加すると仮定すると、所与の下位パス内の要素が多いほど、その鍵のレベル(すなわち、深さ)は大きくなる。鍵生成器701は、一部の例において、これらの下位パスの終わりに対応する鍵のみを記憶および/または出力する場合がある。これは、鍵生成器が、データアイテムごとに1つの鍵を記憶および/または出力する場合があることを意味する。CKDパスが4つの要素(m/i/j/k)=(m/2/1/3)を含む上記の例を使用すると、CKDパスは、2つの下位パス(m/i/j)および(m/i/j/k)を含む場合がある。どちらの下位パスも、同じ要素mから始まるが、それぞれ、異なるレベルjおよびkの終端要素で終わる。鍵生成器は、2つの下位パスに対応する2つの鍵を記憶および/または出力する場合がある。下位パスの終端要素は異なるレベルで終わるが、終端要素の実際の値は同じである場合があることに留意されたい。
【0130】
上で簡潔に述べたように、CKDパスは、鍵生成器以外のエンティティ、たとえば、パス生成器702によって生成される場合がある。代替的に、鍵生成器が、データパスに基づいてCKDパスを生成する場合がある。
【0131】
データパスは、1つまたは複数のデータアイテムを含む。CKDパスは、各データアイテムを、所与のデータアイテムを表す要素のグループに変換することによって生成される。一部の例において、所与のデータアイテムは、単一の要素に変換またはマッピングされる場合がある。一部の例において、所与のデータアイテムは、そのデータアイテムを一緒に表す複数の要素に変換される場合がある。言い換えると、要素の所与のグループは、所与のデータアイテムを符号化する。
【0132】
データアイテムを1つまたは複数の要素に変換する1つの特定の方法は、データアイテムを一緒に符号化するいくつかの固定長の整数(すなわち、固定ビット長)を生成することである。たとえば、各要素は、31ビットまたは32ビットの整数であってよい。31ビットの整数の例を挙げて、データアイテムは、31ビット以下のサイズであってよく、その場合、そのデータアイテムは、1つの要素で表される場合がある。代替的に、データアイテムは、31ビットを超えるサイズであってよく、その場合、そのデータアイテムを表すために複数の要素が必要とされる。概して、要素を表すために必要とされる要素の数nは、n=d/iによって与えられ、dは、データアイテムのビット長であり、iは、要素のビット長である。BIP32ウォレットを含む一部の鍵構造において、親鍵は、最大で2n個の子鍵を持つことができる。その場合、固定長の整数は、最大でnビットである。
【0133】
鍵生成器701がデータパスに基づいてCKDパスを生成する実施形態において、データパスは、異なるエンティティから受信されるか、または鍵生成器701によって生成されるかのどちらかであってよい。たとえば、鍵生成器は、フォルダ構造に対応するデータアイテムの特定のセットに基づいてデータパスを構築してよい。すなわち、データアイテムが、固有の構造を有する場合がある。代替的に、鍵生成器は、データパスを生成するための構造にデータアイテムを配列する場合がある。
【0134】
任意で、CKDを生成するために使用されるデータパスは、難読化されていないデータパスの難読化されたバージョンである場合がある。すなわち、元の難読化されていないデータパスのデータアイテムが、難読化される場合がある。次いで、CKDの要素が、難読化されたデータ項目に基づいて生成される。鍵生成器は、データパスの代わりに、難読化されたデータパスを受信する場合がある。代替的に、鍵生成器は、元のデータパスを受信し、CKDを生成する前にデータアイテムを難読化する場合がある。一部の例においては、各データアイテムが、別々に難読化される。
【0135】
図7に示されるように、パス生成器702は、鍵生成器701とはっきり分かれていてよい。これらの実施形態において、パス生成器702は、データパスに基づいてCKDを生成し、CKDを鍵生成器701に出力するように構成される。データパスは、第三者、たとえば、Alice 103aなどのユーザから受信される場合がある。パス生成器702は、上述の技術を使用してCKDを生成する。
【0136】
説明された実施形態のさらなる特定の例が、以降で検討される。
【0137】
多くのデータ指向のブロックチェーンアプリケーションにおいて、ブロックチェーントランザクションにパッケージングされ、ブロックチェーン150に記録されるデータは、多くの場合、アプリケーションの論理自体によって定義されたより大きなデータ構造の一部である。
【0138】
これらのトランザクションに署名するために使用される鍵を生成するために使用される鍵導出プロセスは、通常、この包括的なデータ構造から独立しており、これは、アプリケーションが独自のデータベースに関連する構造だけでなく、関連するブロックチェーントランザクションに署名するために使用される鍵の階層的構造も、監視および追跡しなければならないことを意味する。
【0139】
本節では、これらの2つの構造を統一することを目的とし、それによって、データベース構造が鍵導出メカニズムに組み込まれる鍵導出プロトコルを説明する。これは、大きく分けて2つの段階を含む。
・パス変換 -- データベースの構造に基づくデータパスが、BIP-32規格と互換性のある鍵派生パスに変換される段階。
・鍵導出 -- 変換されたパスが、それから、署名、暗号化、またはその他の目的で使用される鍵のセットを生成するために使用される段階。
・パス変換 -- データベースの構造に基づくデータパスが、BIP-32規格と互換性のある鍵派生パスに変換される段階。
・鍵導出 -- 変換されたパスが、それから、署名、暗号化、またはその他の目的で使用される鍵のセットを生成するために使用される段階。
【0140】
これらの2つの段階の基本的な説明に続いて、パス難読化という任意の前処理段階も規定し、この段階によって、パス変換を実行する責任を負う誰もデータベース構造自体についての情報を得ることがないように、パス変換プロセスの前に、データベース構造に基づくデータパスが難読化される。これは、パス変換よび鍵導出のステップを実行するために第三者のサービスプロバイダを呼び出す場合があるアプリケーションに有用である。
【0141】
パス変換
方法の第1の段階は、パス変換である。この段階において、アプリケーションは、ブロックチェーントランザクションに含められ、ブロックチェーンに記録されるデータを選択する(たとえば、ブロックチェーンベースのTwitterアプリケーション)。
方法の第1の段階は、パス変換である。この段階において、アプリケーションは、ブロックチェーントランザクションに含められ、ブロックチェーンに記録されるデータを選択する(たとえば、ブロックチェーンベースのTwitterアプリケーション)。
【0142】
また、アプリケーションは、そのデータアイテムに対応するデータパスを生成し、そのデータパスは、そのアプリケーションが使用するデータ構造により決定される。ブロックチェーンベースのTwitterの例に関して、データパスは、BitTweet/AliceID/PostID/CommentID/Timestampの形態である場合があり、これは、ブロックチェーンTwitterアプリケーション「BitTweet」上の特定の投稿に対してユーザAliceによってなされたコメントであるデータアイテムに対応する。このデータパスは、パーソナルコンピュータに見られるフォルダおよびファイル構造にも似ている。
【0143】
それから、アプリケーションは、下の表に示されるように派生パスを生成するためにパス変換を実行する。
【0144】
【表2】
【0145】
上の表は、ASCII符号化された形態などの単純なテキストベースの形態であってよいデータパスが、数字またはインデックスのみからなる鍵派生パスにどのようにして変換され得るかの例を示す。
【0146】
ここで留意すべき重要な点は、2.1節において示されたBIP-32鍵派生パスフォーマットと互換性を持つために、派生パスの各インデックスが31ビット(または強化された鍵が含められるべきである場合は32ビット)のサイズでなければならないことである。これは、データパスの各要素を鍵派生パスの対応する要素に変換するときに考慮されなければならない。
【0147】
上の表に示された例に関して、UserIDは長さが180ビットであると仮定した。これは、データパスのUserID要素に一意に対応する派生パスの下位パス6/300/5/1945/3/2を生成することが、合計で[180/31]=6個のインデックスを必要とすることを意味する。この下位パス内のインデックス6、300、5、1945、3、2は、ここでは単に31ビットの整数の10進表現であることに留意されたい。
【0148】
ここで重要な点は、データパスの任意の要素が鍵派生パスの複数の要素をもたらす場合があることである。これは、一意のデータアイテムに対応する各データパスがやはり一意の派生パスに対応することを保証するために極めて重要である。この点の重要性は、3.2節で派生パスを使用してこれらの鍵を導出するときに明確にされる。
【0149】
アプリケーションによって実行されるこのパス変換プロセスの例示的な実装は、以下の通りである。
1.データアイテムおよびその対応するデータパスを選択する。
2.データパスの各要素を、それぞれ31ビットの長さのチャンクに分ける。
3.派生パスを生成する。
1.各要素に関して、そのチャンクの各々を次のように連結する:"Chunk1" + "Chunk2" + ...。
2.3.1において生成された下位パスを次のように連結する:"Elm1Chunks" + "Elm2Chunks" + ...。
ここで、+は連結を意味することに留意されたい。
1.データアイテムおよびその対応するデータパスを選択する。
2.データパスの各要素を、それぞれ31ビットの長さのチャンクに分ける。
3.派生パスを生成する。
1.各要素に関して、そのチャンクの各々を次のように連結する:"Chunk1" + "Chunk2" + ...。
2.3.1において生成された下位パスを次のように連結する:"Elm1Chunks" + "Elm2Chunks" + ...。
ここで、+は連結を意味することに留意されたい。
【0150】
このプロセスは、供給されたデータパスに一意に対応する鍵派生パスをもたらし、このプロセスの全体的な効果が、図8に示される。このプロセスは、特化した「パス変換器」エンティティによって実行される場合がある。
【0151】
変換されたパスからの鍵の導出
データパスを鍵派生パスに変換したならば、今や、その派生パスを使用して鍵のセットを生成することができる。これらの鍵は、データを暗号化すること、またはブロックチェーンにその後記録されるデータを含むトランザクションに署名することなどの、データに関連する任意の暗号化の動作を実行するために使用されてよい。
データパスを鍵派生パスに変換したならば、今や、その派生パスを使用して鍵のセットを生成することができる。これらの鍵は、データを暗号化すること、またはブロックチェーンにその後記録されるデータを含むトランザクションに署名することなどの、データに関連する任意の暗号化の動作を実行するために使用されてよい。
【0152】
【表3】
【0153】
上の表に示されるように、UserIDおよびTimeフィールドにそれぞれ対応する、より長い下位パスの各々から、1つのキーを生成することを選択しただけである。
【0154】
データパスの各要素に関して、ちょうど1つの鍵が導出される
という決まりを採用する。
という決まりを採用する。
【0155】
この理由は、元のデータパスから導出された各鍵がそのデータパスに一意であることを望むからである。これが、前節で説明されたようにデータパスから取得されたデータのすべてのチャンクに依存するパス全体に基づく鍵を導出する理由である。
【0156】
これらの下位パスの中間構成要素の鍵を導出するとすれば、異なる(たとえば)UserIDデータを使用して同じ鍵を生成することを見かける可能性がある。たとえば、次のような形態の2つのデータパス
App/UserID1/Post/Comment/Time
App/UserID2/Post/Comment/Time
および対応する完全な派生パス
0/6/300/5/1945/3/2/0/42/4/68/495/31/7
0/6/300/5/2000/4/6/0/42/4/68/495/31/7
があるとする。4番目のインデックス位置を含んで4番目のインデックス位置までのインデックスのみを使用してこれらの2つのパスの各々に関する鍵を導出するとすれば、パスが、2つの異なるユーザの一意IDに部分的に基づくにもかかわらず、同一の0/6/300/5であることに気付く。これは、2人のユーザに関して同じ鍵を導出させる結果となる。
App/UserID1/Post/Comment/Time
App/UserID2/Post/Comment/Time
および対応する完全な派生パス
0/6/300/5/1945/3/2/0/42/4/68/495/31/7
0/6/300/5/2000/4/6/0/42/4/68/495/31/7
があるとする。4番目のインデックス位置を含んで4番目のインデックス位置までのインデックスのみを使用してこれらの2つのパスの各々に関する鍵を導出するとすれば、パスが、2つの異なるユーザの一意IDに部分的に基づくにもかかわらず、同一の0/6/300/5であることに気付く。これは、2人のユーザに関して同じ鍵を導出させる結果となる。
【0157】
これは、最初の2つのデータパス要素App/UserIDのみに基づいて鍵を生成するときに完全な下位パスを使用する動機付けとなり、ここで、最初の2つのデータパス要素App/UserIDは、派生パスの6番目のインデックスを含んで6番目のインデックスまでの下位パスに対応する。これは、2つの一意のパス
0/6/300/5/1945/3/2
0/6/300/5/2000/4/6
から導出された2つの一意の鍵をもたらす。
0/6/300/5/1945/3/2
0/6/300/5/2000/4/6
から導出された2つの一意の鍵をもたらす。
【0158】
パス変換プロトコルとともに使用するこの鍵導出の決まりは、図9に可視化される。
【0159】
変換プロセスの難読化
パス変換および鍵導出機能が第三者のサービスプロバイダにオフロードされてよいアプリケーションにおいては、平文のデータパス自体がパス変換におけるその使用の前に難読化される、追加の段階をパス変換プロセスに追加したい場合がある。
パス変換および鍵導出機能が第三者のサービスプロバイダにオフロードされてよいアプリケーションにおいては、平文のデータパス自体がパス変換におけるその使用の前に難読化される、追加の段階をパス変換プロセスに追加したい場合がある。
【0160】
【表4】
【0161】
難読化のこの追加のステップは、パス変換動作を呼び出す前に実行され、その結果、パス変換器は、データパスの元の形態とは対照的に、難読化されたデータパスに対して動作することになる。ここで難読化ステップを導入する主な利点は、それが、パス変換および鍵導出プロセスならびにブロックチェーン上のブロックチェーントランザクションの最終的な包含が、アプリケーションのデータの構造についてのいかなる情報も漏らさないことを保証することである。これは、アプリケーションデータを含むブロックチェーントランザクションの、完全にプライベートでありながらより効率的な管理を可能にする。
【0162】
派生パスと、ひいては導出された鍵のセットとは、データパスを難読化した効果で、初期データパスに基づくものとは異なることに留意されたい。
【0163】
元のデータパスに対して実行される実際の難読化動作は、データパスの要素に対して要素ごとに実行されるべきであり、以下のプロセスのいずれかを含む可能性がある。
・ランダム化、
・秘密XOR鍵を用いるXOR暗号化、
・マッピング関数を使用する置換、
・暗号化、および/または
・ハッシュ関数の使用。
・ランダム化、
・秘密XOR鍵を用いるXOR暗号化、
・マッピング関数を使用する置換、
・暗号化、および/または
・ハッシュ関数の使用。
【0164】
図10および図11は、実施中のパス難読化ステップを示す。図10は、黒い四角として視覚化された、第三者のサービスプロバイダなどのパス難読化エンティティによって実行されるパス難読化プロセスを示す。図11は、データパスの選択から鍵の生成までの全体的なプロセスフローの中でのパス難読化器の使用の状況を示す。
【0165】
例示的なユースケース:暗号化されたデータトランザクション
アプリケーションの所有者のAliceが、自分のアプリケーションデータをブロックチェーン150に記録したいが、自分自身のデータの暗号化を実施する、またはブロックチェーントランザクションを正しく生成するための技術的専門知識を持たないシナリオを考える。Aliceは、これらの機能を支援するための第三者Bobのサービスを利用したい。ここで、AliceおよびBobは便宜的なラベルとして使用されているだけであり、それらが上述のAlice 103aおよびBob 103bと同じ役割を果たすことを必ずしも示唆しないが、それは排除されないことに留意されたい。
アプリケーションの所有者のAliceが、自分のアプリケーションデータをブロックチェーン150に記録したいが、自分自身のデータの暗号化を実施する、またはブロックチェーントランザクションを正しく生成するための技術的専門知識を持たないシナリオを考える。Aliceは、これらの機能を支援するための第三者Bobのサービスを利用したい。ここで、AliceおよびBobは便宜的なラベルとして使用されているだけであり、それらが上述のAlice 103aおよびBob 103bと同じ役割を果たすことを必ずしも示唆しないが、それは排除されないことに留意されたい。
【0166】
最終的な目標は、Aliceのデータが鍵のセットk1,k2, ..., k5を使用して合計5回暗号化される、下の表に示される形態のブロックチェーントランザクションを生成することである。
【0167】
【表5】
【0168】
AliceおよびBobによって引き受けられるプロセスは、上述のパス難読化、パス変換、および鍵生成を使用し、図12aおよび図12bに可視化される。これらの図は、全体的なワークフローと、例示的なデータを投入されたワークフローとをそれぞれ示す。
【0169】
結論
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
【0170】
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104の観点で説明された。しかし、ビットコインブロックチェーンは、ブロックチェーン150の1つの特定の例であり、上の説明は、任意のブロックチェーンに広く当てはまる可能性があることが理解されるであろう。すなわち、本発明は、ビットコインブロックチェーンに決して限定されない。より広く、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のすべての言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104への言及に置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された特性の一部またはすべてを共有する場合がある。
【0171】
本発明の好ましい実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークであり、ビットコインノード104が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。これらの機能のうちの1つまたは一部だけを実行するが、すべては実行しないその他のネットワークエンティティ(またはネットワーク要素)が存在する可能性があることは、排除されない。すなわち、ネットワークエンティティが、ブロックを作成および公開することなく、ブロックを伝播および/または記憶する機能を実行する場合がある(これらのエンティティは、好ましいビットコインネットワーク106のノードとはみなされないことを思い出されたい)。
【0172】
本発明のその他の実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークはない可能性がある。これらの実施形態においては、ノードが、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたは一部を実行するが、すべては実行しない場合があることは排除されない。たとえば、それらのその他のブロックチェーンネットワーク上で、「ノード」は、ブロック151を作成および公開するように構成されるが、それらのブロック151を記憶および/またはその他のノードに伝播するように構成されないネットワークエンティティを指すために使用される場合がある。
【0173】
さらに一層広く、上記の用語「ビットコインノード」104へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックの作成し、発行し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関連して上で説明された同じ方法でハードウェアに実装されてよい。
【0174】
上記の実施形態は、例としてだけ説明されたことが理解されるであろう。より広く、以下のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供されてよい。
【0175】
ステートメント1.
階層的鍵構造の鍵を生成するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、鍵生成器によって実行され、
子鍵派生パスを取得するステップであって、子鍵派生パスが、要素のシーケンスを含み、要素のシーケンスが、1つまたは複数の要素の1つまたは複数のセットを含み、要素の各セットが、データパスのそれぞれのデータアイテムに基づいて生成され、シーケンスの各要素が、鍵構造のそれぞれのレベルにおける鍵のそれぞれの位置に対応する、ステップと、
子鍵派生パスに基づいて1つまたは複数の子鍵を生成するステップであって、それぞれの子鍵が、それぞれの位置でシーケンスのそれぞれの要素に基づいて生成され、そのそれぞれの要素に対応するそれぞれのレベルのものである、ステップとを含む、コンピュータによって実施される方法。
階層的鍵構造の鍵を生成するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、鍵生成器によって実行され、
子鍵派生パスを取得するステップであって、子鍵派生パスが、要素のシーケンスを含み、要素のシーケンスが、1つまたは複数の要素の1つまたは複数のセットを含み、要素の各セットが、データパスのそれぞれのデータアイテムに基づいて生成され、シーケンスの各要素が、鍵構造のそれぞれのレベルにおける鍵のそれぞれの位置に対応する、ステップと、
子鍵派生パスに基づいて1つまたは複数の子鍵を生成するステップであって、それぞれの子鍵が、それぞれの位置でシーケンスのそれぞれの要素に基づいて生成され、そのそれぞれの要素に対応するそれぞれのレベルのものである、ステップとを含む、コンピュータによって実施される方法。
【0176】
[各要素のセットは、データパスのそれぞれのデータアイテムに基づいて生成され、つまり、各要素のセットは、それぞれのデータアイテムの関数である。]
【0177】
ステートメント2.
生成された子鍵のうちの1つまたは複数を記憶および/または出力するステップを含むステートメント1の方法。
生成された子鍵のうちの1つまたは複数を記憶および/または出力するステップを含むステートメント1の方法。
【0178】
ステートメント3.
子鍵派生パスが、要素の各セットにつき1つずつ複数の下位パスを含み、各下位パスが、同じ最初の要素および異なるそれぞれの最終の要素を含み、
1つまたは複数の生成された子鍵の前記記憶および/または前記出力が、下位パスごとに1つの子鍵を記憶および/または出力することを含み、子鍵が、それぞれの最終の要素に基づいて生成されるステートメント2の方法。
子鍵派生パスが、要素の各セットにつき1つずつ複数の下位パスを含み、各下位パスが、同じ最初の要素および異なるそれぞれの最終の要素を含み、
1つまたは複数の生成された子鍵の前記記憶および/または前記出力が、下位パスごとに1つの子鍵を記憶および/または出力することを含み、子鍵が、それぞれの最終の要素に基づいて生成されるステートメント2の方法。
【0179】
ステートメント4.
子鍵派生パスを取得するステップが、子鍵派生パスを受信することを含むいずれかの前述のステートメントの方法。
子鍵派生パスを取得するステップが、子鍵派生パスを受信することを含むいずれかの前述のステートメントの方法。
【0180】
ステートメント5.
データパスを取得するステップを含み、子鍵派生パスを取得するステップが、取得されたデータパスに基づいて子鍵派生パスを生成することを含むステートメント1から3のいずれかの方法。
データパスを取得するステップを含み、子鍵派生パスを取得するステップが、取得されたデータパスに基づいて子鍵派生パスを生成することを含むステートメント1から3のいずれかの方法。
【0181】
ステートメント6.
子鍵派生パスを生成することが、
データパスのそれぞれのデータアイテムに関して要素のそれぞれのセットを生成することであって、要素のそれぞれのセットが、データアイテムを一緒に表し、要素の各セットの各要素が、整数である、生成することを含むステートメント5の方法。
子鍵派生パスを生成することが、
データパスのそれぞれのデータアイテムに関して要素のそれぞれのセットを生成することであって、要素のそれぞれのセットが、データアイテムを一緒に表し、要素の各セットの各要素が、整数である、生成することを含むステートメント5の方法。
【0182】
ステートメント7.
各整数が、10進表現としてまたは16進表現として表されるステートメント6の方法。
各整数が、10進表現としてまたは16進表現として表されるステートメント6の方法。
【0183】
ステートメント8.
各整数が、固定長の整数であるステートメント6またはステートメント7の方法。
各整数が、固定長の整数であるステートメント6またはステートメント7の方法。
【0184】
ステートメント9.
各親鍵が、最大2n個の子鍵を持つことができ、nが、固定長の整数であるステートメント8の方法。
各親鍵が、最大2n個の子鍵を持つことができ、nが、固定長の整数であるステートメント8の方法。
【0185】
ステートメント10.
データパスを取得するステップが、データパスを受信することを含むステートメント5から9のいずれかの方法。
データパスを取得するステップが、データパスを受信することを含むステートメント5から9のいずれかの方法。
【0186】
ステートメント11.
受信されたデータパスが、難読化されていないデータパスの難読化されたバージョンであり、難読化されたデータパスの各データアイテムが、難読化されていないデータパスのそれぞれの難読化されていないデータアイテムの難読化されたバージョンであるステートメント10の方法。
受信されたデータパスが、難読化されていないデータパスの難読化されたバージョンであり、難読化されたデータパスの各データアイテムが、難読化されていないデータパスのそれぞれの難読化されていないデータアイテムの難読化されたバージョンであるステートメント10の方法。
【0187】
ステートメント12.
データパスを取得するステップが、データパスを生成することを含むステートメント5から9のいずれかの方法。
データパスを取得するステップが、データパスを生成することを含むステートメント5から9のいずれかの方法。
【0188】
ステートメント13.
データパスの難読化されたバージョンを生成するステップを含み、子鍵派生パスが、難読化されたデータパスに基づいて生成されるステートメント10またはステートメント12の方法。
データパスの難読化されたバージョンを生成するステップを含み、子鍵派生パスが、難読化されたデータパスに基づいて生成されるステートメント10またはステートメント12の方法。
【0189】
実施形態において、方法は、データパスを取得するステップと、データパスの難読化されたバージョンを生成するステップとを含んでよい。方法は、難読化されたデータパスのそれぞれの難読化されたデータアイテムに関して要素のそれぞれのセットを生成するステップであって、要素のそれぞれのセットが、難読化されたデータアイテムを一緒に表す、ステップを含んでよい。
【0190】
ステートメント14.
データパスの各データアイテムが、別々に難読化されるステートメント11またはステートメント13の方法。
データパスの各データアイテムが、別々に難読化されるステートメント11またはステートメント13の方法。
【0191】
ステートメント15.
データパスの各データアイテムが、
ランダム化、
暗号鍵を使用する暗号化、
XOR鍵を使用するXOR暗号化、
マッピング関数を使用する置換、および/または
ハッシュ関数
のうちの任意の1つまたは複数を使用して難読化されるステートメント11、13、または14のいずれか1つの方法。
データパスの各データアイテムが、
ランダム化、
暗号鍵を使用する暗号化、
XOR鍵を使用するXOR暗号化、
マッピング関数を使用する置換、および/または
ハッシュ関数
のうちの任意の1つまたは複数を使用して難読化されるステートメント11、13、または14のいずれか1つの方法。
【0192】
ステートメント16.
データパスが、フォルダ構造に対応し、各データアイテムが、フォルダ構造の異なるフォルダに属するいずれかの前述のステートメントの方法。
データパスが、フォルダ構造に対応し、各データアイテムが、フォルダ構造の異なるフォルダに属するいずれかの前述のステートメントの方法。
【0193】
ステートメント17.
前記出力が、
1つまたは複数の生成された子鍵を、1つまたは複数の生成された子鍵のうちの少なくとも1つに基づいてデータを暗号化するように構成された暗号化関数に出力することと、
1つまたは複数の生成された子鍵を、1つまたは複数の生成された子鍵のうちの少なくとも1つに基づいてデジタル署名を生成するように構成された署名関数に出力することと、
1つまたは複数の生成された子鍵を異なる関係者に送信することと、
1つまたは複数の生成された子鍵の各々に関してそれぞれのブロックチェーンアドレスを生成し、それぞれのブロックチェーンアドレスを異なる関係者に出力することと、
1つまたは複数の生成された子鍵のうちの少なくとも1つに、ロックされた出力を含むブロックチェーントランザクションを生成することとのうちの少なくとも1つを含む、ステートメント2またはステートメント2に従属するいずれかのステートメントの方法。
前記出力が、
1つまたは複数の生成された子鍵を、1つまたは複数の生成された子鍵のうちの少なくとも1つに基づいてデータを暗号化するように構成された暗号化関数に出力することと、
1つまたは複数の生成された子鍵を、1つまたは複数の生成された子鍵のうちの少なくとも1つに基づいてデジタル署名を生成するように構成された署名関数に出力することと、
1つまたは複数の生成された子鍵を異なる関係者に送信することと、
1つまたは複数の生成された子鍵の各々に関してそれぞれのブロックチェーンアドレスを生成し、それぞれのブロックチェーンアドレスを異なる関係者に出力することと、
1つまたは複数の生成された子鍵のうちの少なくとも1つに、ロックされた出力を含むブロックチェーントランザクションを生成することとのうちの少なくとも1つを含む、ステートメント2またはステートメント2に従属するいずれかのステートメントの方法。
【0194】
ステートメント18.
階層的鍵構造の鍵を生成するための鍵生成器による使用のためにデータパスを生成するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、パス生成器によって実行され、
1つまたは複数のデータアイテムを含むデータパスを取得するステップと、
データパスのそれぞれのデータアイテムに関して1つまたは複数の要素のそれぞれのセットを生成するステップであって、要素のそれぞれのセットが、データアイテムを一緒に表し、要素の各セットの各要素が、整数である、ステップと、
1つまたは複数の要素のそれぞれのセットに基づいて子鍵派生パスを生成するステップと、
子鍵派生パスを出力するステップとを含む、コンピュータによって実施される方法。
階層的鍵構造の鍵を生成するための鍵生成器による使用のためにデータパスを生成するコンピュータによって実施される方法であって、鍵構造が、レベルの階層を含み、レベルの階層が、マスタレベルおよび1つまたは複数の子レベルを含み、マスタレベルが、マスタ鍵を含み、各子レベルが、1つまたは複数の子鍵を含み、所与のレベルのそれぞれの子鍵が、先行するレベルの1つの鍵にリンクされ、先行するレベルのその1つの鍵が、それぞれの子鍵のそれぞれの親鍵であり、方法が、パス生成器によって実行され、
1つまたは複数のデータアイテムを含むデータパスを取得するステップと、
データパスのそれぞれのデータアイテムに関して1つまたは複数の要素のそれぞれのセットを生成するステップであって、要素のそれぞれのセットが、データアイテムを一緒に表し、要素の各セットの各要素が、整数である、ステップと、
1つまたは複数の要素のそれぞれのセットに基づいて子鍵派生パスを生成するステップと、
子鍵派生パスを出力するステップとを含む、コンピュータによって実施される方法。
【0195】
ステートメント19.
子鍵派生パスの前記出力が、子鍵派生パスを鍵生成器に出力することを含み、鍵生成器が、子鍵派生パスに基づいて1つまたは複数の子鍵を生成するように構成されるステートメント18の方法。
子鍵派生パスの前記出力が、子鍵派生パスを鍵生成器に出力することを含み、鍵生成器が、子鍵派生パスに基づいて1つまたは複数の子鍵を生成するように構成されるステートメント18の方法。
【0196】
ステートメント20.
各整数が、10進表現としてまたは16進表現として表されるステートメント18またはステートメント19の方法。
各整数が、10進表現としてまたは16進表現として表されるステートメント18またはステートメント19の方法。
【0197】
ステートメント21.
各整数が、固定長の整数であるステートメント18から20の方法。
各整数が、固定長の整数であるステートメント18から20の方法。
【0198】
ステートメント22.
各親鍵が、最大2n個の子鍵を持つことができ、nが、固定長の整数であるステートメント21の方法。
各親鍵が、最大2n個の子鍵を持つことができ、nが、固定長の整数であるステートメント21の方法。
【0199】
ステートメント23.
データを取得するステップが、データパスを受信することを含むステートメント18から22のいずれかの方法。
データを取得するステップが、データパスを受信することを含むステートメント18から22のいずれかの方法。
【0200】
ステートメント24.
データを取得するステップが、データパスを生成することを含むステートメント18から22のいずれかの方法。
データを取得するステップが、データパスを生成することを含むステートメント18から22のいずれかの方法。
【0201】
ステートメント25.
取得されたデータパスが、難読化されていないデータパスの難読化されたバージョンであるステートメント18から24のいずれかの方法。
取得されたデータパスが、難読化されていないデータパスの難読化されたバージョンであるステートメント18から24のいずれかの方法。
【0202】
ステートメント26.
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、メモリが、処理装置上で実行されるように配置されたコードを記憶し、コードが、処理装置上にあるときに、いずれかの前述のステートメントの方法を実行するように構成される、処理装置とを含むコンピュータ機器。
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、メモリが、処理装置上で実行されるように配置されたコードを記憶し、コードが、処理装置上にあるときに、いずれかの前述のステートメントの方法を実行するように構成される、処理装置とを含むコンピュータ機器。
【0203】
ステートメント27.
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、いずれかの前述のステートメントの方法を実行するように構成されたコンピュータプログラム。
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、いずれかの前述のステートメントの方法を実行するように構成されたコンピュータプログラム。
【0204】
本明細書において開示される別の態様によれば、鍵生成器およびパス生成器のアクションを含む方法が提供される可能性がある。
【0205】
本明細書において開示される別の態様によれば、鍵生成器およびパス生成器のコンピュータ機器を含むシステムが提供される可能性がある。
【符号の説明】
【0206】
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 出力
401 トランザクションエンジン、要求者
402 ユーザインターフェース(UI)レイヤ、確認者
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素、データ入力フィールド
700 システム
701 鍵生成器
702 パス生成器
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 出力
401 トランザクションエンジン、要求者
402 ユーザインターフェース(UI)レイヤ、確認者
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素、データ入力フィールド
700 システム
701 鍵生成器
702 パス生成器
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12a】
【図12b】
【国際調査報告】