JP2022541323A - ブロックチェーントランザクションを利用したデジタル契約 - Google Patents

ブロックチェーントランザクションを利用したデジタル契約 Download PDF

Info

Publication number
JP2022541323A
JP2022541323A JP2022504625A JP2022504625A JP2022541323A JP 2022541323 A JP2022541323 A JP 2022541323A JP 2022504625 A JP2022504625 A JP 2022504625A JP 2022504625 A JP2022504625 A JP 2022504625A JP 2022541323 A JP2022541323 A JP 2022541323A
Authority
JP
Japan
Prior art keywords
party
hash
transaction
contract
blockchain
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
JP2022504625A
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 JP2022541323A publication Critical patent/JP2022541323A/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/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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/3247—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 digital signatures
    • H04L9/3249—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 digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

ブロックチェーンネットワークの第１当事者と第２当事者との間のデジタル契約をエンコーディングするコンピュータ実装方法であって、本デジタル契約は、契約が履行される条件に基づいて、第１当事者から第２当事者へデジタル資産の総計を移転するためのものである。本方法は、複数のデータ要素を獲得するステップであり、各データ要素は前記契約の異なる条件を表しており、条件のうち少なくとも１つが第２当事者にリンクされているステップ、データ要素に基づいてハッシュツリーを生成するステップであり、ハッシュツリーは、i)それぞれのデータ要素をハッシュすることによって生成される第１リーフハッシュと、信頼される第三者だけに知られている秘密値をハッシュすることによって生成される第２ハッシュキーと、ii)内部ハッシュと、iii)ルートハッシュと、を含む第２リーフハッシュと、を含むステップ、および、ブロックチェーンのトランザクション内に含めるために、ルートハッシュを第１当事者に対して利用可能にするステップ、を含む。【選択図】 図８

Description

本開示は、ブロックチェーンネットワークのノードが、いわゆる「スマート契約（“smart contract”）」とも呼ばれる、デジタル契約に合意し、そして、施行することを可能にするための方法に関する。
ブロックチェーンとは、分散データ構造の形態を指し、そこでは、ピアツーピア(P2P)ネットワーク内の複数のノードそれぞれにおいて、ブロックチェーンの重複コピーが維持される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、１つ以上のトランザクションを含む。各トランザクションは、１つ以上のブロックに及ぶ可能性があるシーケンス内の先行トランザクションを指し示すことができる。トランザクションは、「マイニング（“mining”）」として知られているプロセスによって、新しいブロックに含めるようにネットワークに提出され得る。このことは、「プルーフオブワーク（“proof of work”）」を実行するために競合する複数のマイニングノードそれぞれを巻き込み、すなわち、ブロックに含まれるのを待つ保留中（pending）のトランザクションのプールに基づいて、暗号パズルを解決する。
従来、ブロックチェーン内のトランザクションは、デジタル資産、すなわち、価値のストアとして機能しているデータ、を伝達するために使用されている。しかしながら、ブロックチェーンは、また、ブロックチェーンの上に追加の機能をレイヤするためにも利用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションの出力の中に追加のユーザデータを保管することを可能にする。現代のブロックチェーンは、単一トランザクション内に格納できる最大データ容量を増加させており、より複雑なデータが組み込まれることを可能にしている。例えば、このことは、ブロックチェーン内に電子文書を保管するために使用され得るものであり、オーディオまたはビデオデータでさえも保管する。
ネットワーク内の各ノードは、転送（forwarding）、マイニング（mining）、およびストレージ（storage）、の３つの役割のうちいずれか１つ、２つ、または全てを有することができる。転送ノードは、ネットワークのノード全体にトランザクションを伝播させる。マイニングノードは、トランザクションをブロックへとマイニングする。ストレージノードは、それぞれ、ブロックチェーンのマイニングされたブロックのコピーを保管する。トランザクションをブロックチェーンに記録させるために、当事者（party）は、伝搬されるネットワークのノードのうち１つにトランザクションを送信する。トランザクションを受信するマイニングノードは、トランザクションを新しいブロックへとマイニングするために競合（race）し得る。各ノードは、同じノードプロトコルを尊重するように構成されており、プロトコルに、トランザクションが有効（valid）であるための１つ以上の条件を含んでいる。無効なトランザクションは、伝搬されず、または、ブロックへとマイニングされない。トランザクションが検証され、かつ、それによってブロックチェーンに受け入れられたものと仮定すると、追加のユーザデータは、従って、不変の公記録（public record）としてP2Pネットワーク内の各ノードに保管されたままである。
ブロックチェーン技術の最も制調光しているアプリケーションの1つはデジタル(または、スマート)契約である。スマート契約は、コンピュータが実装するプロトコルであり、安全に、かつ、信頼できない（trustless）両方の方法でデジタル契約に合意し、そして、実施することを可能にする。
いくつかのよく知られたブロックチェーン台帳（ledger）は、トランザクションのためにスタックベースのスクリプト言語を使用する。スクリプト言語の現在の原始的な性質およびスクリプトサイズの制限は、スマート契約のためのブロックチェーンベースのプラットフォームの創作に対する障壁（barrier）としてみなされている。スクリプト言語を使ってエンコーディングできるスマート契約の一つの例は、エスクロー（escrow）スマート契約(条件に基づく支払プロトコル)である。ここでは、トランザクションの出力を償還（redeem）する権利は、イベントの結果に依存している。しかしながら、この種の契約をエンコーディングするために必要なスクリプトの量が依存性の数に比例して増減するので、トランザクション内に含まれ得るそうした依存性の数は、いらただしく少ない。
ここにおいて開示される一つの態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約をエンコーディングする、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、信頼される第三者によって実行され、かつ、複数のデータ要素を獲得するステップであり、各データ要素は前記契約の異なる条件を表しており、かつ、前記異なる条件のうち少なくとも１つが前記第２当事者にリンクされている、ステップと、前記複数のデータ要素に基づいて、ハッシュツリーを生成するステップと、を含む。前記ハッシュツリーは、ｉ）リーフ層であり、それぞれのデータ要素をハッシュすることによって、それぞれ生成されるリーフハッシュの第１セット、および、前記信頼される第三者にだけ知られている秘密値をハッシュすることによって生成される、少なくとも１つのハッシュキーを含む、リーフハッシュの第２セット、を含むリーフ層と、ｉｉ）１つ以上の内部層であり、各内部層は、内部ハッシュのそれぞれのセットを含み、それぞれの内部層の各内部ハッシュは、下位層からの少なくとも２つのハッシュの連結をハッシュすることによって生成される内部層と、ｉｉｉ）ルートハッシュを含む、ルート層であり、前記ルートハッシュは、最上位の内部層からの少なくとも２つのハッシュの連結をハッシュすることによって生成され、かつ、前記ブロックチェーンのトランザクション内に含めるために、前記ルートハッシュを前記第１当事者に対して利用可能にするルート層と、を含む。
ここにおいて開示される別の態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を生成する、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、前記第１当事者によって実行され、かつ、信頼される第三者によって生成されたハッシュツリーのルートハッシュを獲得するステップであり、前記ハッシュツリーは、ｉ）複数のデータ要素であり、各データ要素は、前記契約の異なる条件を表しており、前記異なる条件のうち少なくとも１つは前記第２当事者に関連している、複数のデータ要素、および、ｉｉ）前記信頼される第三者だけに知られている秘密値に基づいて生成された１つ以上の異なるハッシュキー、に基づいて生成されている、ステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者に対して前記デジタル資産の総計をロックするためのロッキングスクリプトを含み、かつ、前記ロッキングスクリプトは、前記ルートハッシュを含む、ステップと、を含む。
ここにおいて開示される別の態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実行する、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、前記第２当事者によって実行され、かつ、前記契約の条件を表すデータ要素を獲得するステップであり、前記条件は、前記第２当事者にリンクされているステップと、認証パスを獲得するステップであり、前記認証パスは、信頼される第三者によって生成されたハッシュツリーの候補ルートハッシュを生成するためのものであり、かつ、前記認証パスは、ハッシュのセットを含み、前記ハッシュのセットは、前記信頼される第三者にだけ知られている秘密値に基づいて生成されたハッシュキー、および、内部ハッシュの１つ以上のセットを含み、内部ハッシュのセットそれぞれは、前記ハッシュの異なる内部層に属している、ステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者からの前記デジタル資産の総計をアンロックするためのアンロッキングスクリプトを含み、かつ、前記アンロッキングスクリプトは、前記獲得されたデータ要素および前記獲得された認証パスを含む、ステップと、を含む。
ハッシュツリー(マークルツリーとしても知られている)は、暗号ハッシュを含んでいる。「マークルツリー（“Merkle tree”）」という用語は、ときどき、バイナリハッシュツリーを参照するために文献で使用されるが、マークルによる最初の開示はバイナリハッシュツリーに限定されておらず、そして、文献においてはどこでも「ハッシュツリー」と「マークルツリー」は同義で使用されている。マークルツリーおよびハッシュツリーは、コンテキストにおいて別の意味に解釈されない限り、ここにおいては互換的に使用されている。「ツリー（“tree”）」という用語は、分岐データ構造を参照するものであり、ツリーは、上部に「ルート（“root”）」を有し、下部に「リーフ（“leaf”）」を有する。マークルツリーは、ルートハッシュ、またはマークルルートと呼ばれる、ハッシュが１つだけになるまで、ノードのペアを再帰的にハッシュすることによって構築される。ルートハッシュは、データ要素のセットの全体的なデジタルフィンガープリント（fingerprint）を表し、特定のデータ要素がセットに含まれているか否かを検証する効率的なプロセスを提供している。特定のデータ要素がセットに含まれていることを証明するために、証明側は、比較的に少数のハッシュを生成すること要するだけである。このハッシュは、特定のデータ要素をハッシュツリーのルートハッシュに接続する認証パス、すなわち「マークルパス（“Merkle path”）」を構成している。
本開示は、単一のハッシュ値(マークルルート)を使用するトランザクションにおけるスマート契約の条件を圧縮し、かつ、エンコーディングするために、マークルツリー、または、より一般的にはハッシュツリーを利用することができる方法を認識している。さらに、スマート契約は、信頼される当事者が証明当事者（proving party）によって満たされている条件を証明する場合、証明ノードがデジタル資産にアクセスし、その総計（amount）を支払う（spend）ことができることを確保する。
信頼される相手(例えば、オラクル（oracle）)だけが、１つ以上のリーフハッシュが基づいている秘密の値に対するアクセスを有している。従って、信頼される相手のみがハッシュツリーのマークルルート、および、満たされた条件の有効なマークルパスを生成できる。これに基づいて、証明当事者(または支払当事者)が信頼される当事者によって生成されたのと同じマークルルートを結果として生じる有効なマークルプルーフを提供できる場合に、証明当事者(または支払当事者)は、信頼される当事者が証明当事者にマークルパスを提供したことを確信できる。
本開示は、スクリプト上の必要最小限の条件を用いて、安全なスマート契約の実行を可能にする。検証当事者（verifying party）は、証明当事者が必要なデータを有しており、かつ、信頼される当事者によって正しい鍵ハッシュが与えられていることを検証するために、マークルルートを知る必要だけがある。なぜなら、鍵ハッシュの知識はデータ要素のハッシュとペア化されたリーフハッシュに必要であるが、一方、それ自体はマークルツリーの他のハッシュの計算を可能にしないからである。有効なデータに適用される特定のマークルパスは、信頼される当事者によっても、また、送信され、証明者における計算の要件を最小限にしている。事実上、マークルパスは、データが信頼される当事者によって認証されたことの証拠として機能する。検証者にマークルルートを与えることだけにより、スマート契約は、支払トランザクション（spending transaction）が提出されるまで、データ(支払当事者へデジタル資産を移転するために必要とされるもの)を開示しない方法でエンコーディングすることができる。
信頼される当事者によって構築されたマークルツリーの深さは、データ要素の数(または、条件、結果、等)によって対数的にスケール化する。これにより、多くの条件に依存するスマート契約をより効率的にエンコーディングすることができる。
ここにおいて開示される別の態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約をエンコーディングする、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、信頼される第三者によって実行され、かつ、前記第２当事者にリンクされた前記契約の条件が満たされたと判断することにレスポンスして、前記ブロックチェーンのトランザクションに含めるために、前記第２当事者に前記信頼される第三者の署名を提供するステップであり、前記署名は、前記満たされた条件を表すデータ要素に署名するステップ、を含む。
ここにおいて開示される別の態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を生成する、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、信頼される前記第１当事者によって実行され、かつ、ハッシュツリーのルートハッシュを獲得するステップであり、前記ハッシュツリーは、リーフハッシュの層を含み、前記リーフハッシュのうち少なくともいくつかは、それぞれが、複数のデータ要素のうちそれぞれ一つに基づいて生成され、各データ要素は、前記契約の異なる条件を表しており、かつ、前記異なる条件のうち少なくとも１つは、前記第２当事者にリンクされている、ステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者に対して前記デジタル資産の総計をロックするためのロッキングスクリプトを含み、かつ、前記ロッキングスクリプトは、前記ルートハッシュを含んでおり、前記ロッキングスクリプトは、後のトランザクションのアンロッキングスクリプトと共に実行されるときに、前記アンロッキングスクリプトが、ｉ）信頼される第三者の署名と共に署名された前記契約の条件を表すデータ要素、および、ｉｉ）前記署名されたデータエレメントを使用して、前記獲得されたルートハッシュに一致する候補ルートハッシュを生成するための認証パス、を含むか否かを決定する、ように構成されている、ステップと、を含む。
ここにおいて開示される別の態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実行する、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、前記第２当事者によって実行され、かつ、前記契約の履行条件を表すデータ要素を獲得するステップであり、前記条件は、前記第２当事者にリンクされている、ステップと、前記獲得されたデータ要素を使用して、ハッシュツリーの候補ルートハッシュを生成するための認証パスを獲得するステップであり、前記ハッシュツリーは、リーフハッシュの層を含み、前記リーフハッシュのうち少なくともいくつかは、それぞれが、複数のデータ要素のうちそれぞれ一つに基づいて生成され、各データ要素は、前記契約の異なる条件を表しており、かつ、前記複数のデータ要素は、前記獲得されたデータ要素を含むステップと、信頼される第三者の署名および公開鍵を獲得するステップであり、前記署名は、前記履行について署名するステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者からの前記デジタル資産の総計をアンロックするためのアンロッキングスクリプトを含み、かつ、
前記アンロッキングスクリプトは、前記獲得された認証パス、前記公開鍵、および、前記署名を用いて署名された前記獲得されたデータ要素を含むステップと、を含む。
本開示は、また、信頼される当事者に、同じデータを含む全ての新しいトランザクションについて計算を実行するように要求することなく、条件依存のスマート契約を生成し、かつ、実施するための技術を提供する。
契約の相互に排他的な条件は(例えば、信頼される当事者によって)マークルツリーを構築するために使用され得る。そして、スマート契約を構築するためにはマークルルートだけが支給当事者によって要求される。このことは、契約全体のサイズを低減し、そして、より少ない未使用のスクリプトデータが必要とする。
契約の履行条件は、例えば、ラビン署名を用いて署名されることによって、信頼される第三者によって認証される。認証された条件は、支払(アンロッキング)スクリプトに直接的に含まれ、従って、データプロバイダによって要求される作業量を削減している。
当事者は、それで、トランザクションに明示的に記録された契約全体を必要とすることなく、スマート契約の条件が遵守されることを確保することができる。代わりに、デジタル資産の支払者または勝者は、自分が何らかの条件を満たしていること、および満たされている特定の条件が契約の一部であることを証明する必要があります。
ここにおいて開示される別の態様に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実施するためのトランザクションを含む、コンピュータで読取り可能な記憶媒体が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記トランザクションは、前記デジタル資産の総計を前記第１当事者にロックするためのロッキングスクリプトを含み、前記ロッキングスクリプトは、ルートハッシュを含み、かつ、ハッシュツリーの前記ルートハッシュは、信頼される第三者によって生成され、前記ハッシュツリーは、ｉ）複数のデータ要素であり、各データ要素は、前記契約の異なる条件を表しており、前記異なる条件のうち少なくとも１つは前記第２当事者に関連している、複数のデータ要素、および、ｉｉ）前記信頼される第三者だけに知られている秘密値に基づいて生成された１つ以上の異なるハッシュキー、に基づいて生成されている。
本開示の実施形態の理解を助け、かつ、そうした実施形態がどのように実施され得るかを示すために、例示としのみ、添付の図面を参照する。
図1は、ブロックチェーンを実装するシステムの概略ブロック図である。 図2は、ブロックチェーン内に記録され得るトランザクションの例を模式的に示している。 図3は、ブロックチェーンを実装する別のシステムの概略ブロック図である。 図4は、出力ベースモデルのノードプロトコルに従った、トランザクションを処理するためのノードソフトウェアの部分の概略ブロック図である。 図5は、一つの例示的なマークルツリー（Merkle tree）の概略図である。 図6は、マークルプルーフ（Merkle proof）の概略図である。 図7は、スマート契約を実行する際の当事者間の相互作用を表す一つの例示的なブロック図である。 図8は、スマート契約を実行する際の当事者間の相互作用を表す一つの例示的なブロック図である。 図9は、秘密の値を使用して生成されたハッシュキーがツリーのいくつかのリーフを形成する、一つの例示的なマークルツリーの概略図である。 図10は、マークルツリーのスマート契約の結果がマークルツリーのリーフを形成する、一つの例示的なマークルツリーの概略図である。 図11は、検証者（verifier）および証明者（prover）によって、それぞれに、生成されたトランザクションの例を示しており、それによって、マークルツリーが、スマート契約の条件をエンコーディングするために使用されている。 図12は、検証者および証明者によって、それぞれに、生成されたトランザクションの例を示しており、それによって、マークルツリーが、スマート契約の条件をエンコーディングするために使用されている。
例示的なシステムの概要
図1は、ブロックチェーン150を一般的に実装するための例示的なシステム100を示している。システム100は、パケット交換（packet-switched）ネットワーク101、典型的には、インターネットといった広域インターネットワークを含む。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)オーバーレイネットワーク106を形成するように配置された複数のノード104を含んでいる。各ノード104は、ピア（peer）のコンピュータ機器を含み、ノード104の異なるノードは異なるピアに属している。各ノード104は、１つ以上のプロセッサを含む。例えば、１つ以上の中央処理装置（CPU）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はフィールドプログラマブルゲートアレイ（FPGA）である。各ノードは、また、メモリ、すなわち、非一時的なコンピュータで読取り可能な媒体またはメディアの形態でのコンピュータで読取り可能な記憶装置を備える。メモリは、１つ以上のメモリ媒体を使用する１つ以上のメモリユニットを含み得る。例えば、ハードディスクといった磁気媒体、ソリッドステートドライブ（SSD）、フラッシュメモリ、またはEEPROMといった電子媒体、及び／又は、光ディスクドライブといった光媒体である。
ブロックチェーン150は、データ151のブロックのチェーンを含み、ブロックチェーン150のそれぞれのコピーは、P2Pネットワーク160内の複数のノードそれぞれで維持されている。チェーン内の各ブロック151は、１つ以上のトランザクション152を含み、ここで、このコンテキストにおけるトランザクションは、一種のデータ構造を参照する。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、典型的に、全体を通して、１つの特定のトランザクションプロトコルを使用する。トランザクションプロトコルの１つの一般的なタイプにおいて、各トランザクション152のデータ構造は、少なくとも１つの入力および少なくとも１つの出力を含む。各出力は、出力が暗号的にロックされているユーザ103に属しているデジタル資産の総計を表す総計（amount）を指定する(ロックを解除し、かつ、それによって償還または消費するために、そのユーザの署名を必要とする)。各入力は、先行トランザクション152の出力に戻って指し示し、それによって、トランザクションをリンクしている。
ノード104の少なくとも一部は、転送ノード104Fの役割を担い、トランザクション152を転送し、かつ、それによって伝搬する。ノード104の少なくともいくつかは、ブロック151をマイニングするマイナ（miner）104Mの役割を担う。ノード104の少なくとも一部は、ストレージノード104Sの役割を担い（ときどき、「フルコピー（“full-copy”）」ノードとしても呼ばれる）、各ノードは、それぞれのメモリ内に同じブロックチェーン150のそれぞれのコピーを保管する。各マイナノード104Mは、また、ブロック151へマイニングされるのを待っているトランザクション152のプール154も維持している。所与のノード104は、転送ノード104、マイナ104M、ストレージノード104S、または、これらのうち２つまたは全ての任意の組み合わせであり得る。
所与の現在のトランザクション152jにおいて、入力(または、各入力)は、トランザクションのシーケンスにおいて先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて償還（redeemed）されること、または「支払われる（“spent”）」ことを指定する。一般的に、先行トランザクションは、プール154または任意のブロック151内の任意のトランザクションであり得る。先行トランザクション152iは、必ずしも現在のトランザクション152jが作成される時、またはネットワーク106に送信される時でさえ存在する必要はないが、現在のトランザクションが有効であるために、先行トランザクション152iが、存在し、検証される必要がある。従って、ここにおいては、「先行（“preceding”）」とは、ポインタによってリンクされた論理的な順序での先行を指し、必ずしも時間的な順序で作成または送信する時刻を指すのではない。そして、従って、トランザクション152i、152jがアウトオブオーダー（out-of-order）に作成または送信されることを必ずしも排除しない(孤立（orphan）トランザクションに関する後の説明を参照のこと)。先行トランザクション152iは、同様に、先行トランザクションまたは先行トランザクションと呼ばれ得る。
現在のトランザクション152jの入力は、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。次に、現在のトランザクション152jの出力は、新しいユーザ103bに暗号的（cryptographically）にロックすることができる。従って、現在のトランザクション152jは、先行トランザクション152iの入力に定義された総計を、現在のトランザクション152jの出力に定義された新しいユーザ103bに移転することができる。ある場合に、トランザクション152は、複数のユーザ間で入力総計を分割するために複数の出力を有してもよい(そのうちの一人は、変更を与えるために元のユーザ103aであり得る)。場合によって、トランザクションは、また、複数の入力を有し、１つ以上の先行トランザクションの複数の出力から総計を集め、現在のトランザクションの１つ以上の出力に再配分することもできる。
上記は、「出力ベース（“output-based”）」トランザクションプロトコルと呼ばれ、また、ときどき、未使用トランザクション出力(UTXO)タイプのプロトコルとも呼ばれる(ここで、出力はUTXOとして参照される)。ユーザのトータルバランスは、ブロックチェーン151に保管されたどの１つの番号にも定義されておらず、その代わりに、ユーザは、ブロックチェーン151内の多くの異なるトランザクション152に散在している、そのユーザの全てのUTXOの値を照合（collate）するために、特別な「ウォレット“wallet”」アプリケーション105を必要とする。
代替的なタイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース（“account-based”）」プロトコルと呼ばれ得る。アカウントベースの事例において、各トランザクションは、過去のトランザクションのシーケンスにおいて先行トランザクションのUTXOを戻って参照することによって、移転される総計を定義しない。むしれ、アカウントの絶対的なバランス参照することによる。全てのアカウントの現在の状態は、ブロックチェーンに分離されたマイナによって保管されており、そして、絶えず更新されている。そうしたシステムにおいて、トランザクションは、アカウントの実行中のトランザクション検数（tally）を使用して順序付けされる(「ポジション（“position”）」とも呼ばれる)。この値は、送信者が暗号署名の一部として署名し、そして、トランザクション参照計算の一部としてハッシュ化される。加えて、任意的なデータフィールドも、また、署名されたトランザクションであり得る。このデータフィールドは、例えば、以前のトランザクションIDがデータフィールドに含まれている場合、以前のトランザクションに戻って指し示し得る。
いずれのタイプのトランザクションプロトコルでも、ユーザ103が新しいトランザクション152jを制定することを望む場合に、彼／彼女は、自分のコンピュータ端末102からP2Pネットワーク106のノード104の１つに新しいトランザクションを送信する(それは、今日では、典型的にサーバまたはデータセンタであるが、原理的には他のユーザ端末であり得る)。このノード104は、各ノード104で適用されるノードプロトコルに従って、トランザクションが有効であるか否かをチェックする。ノードプロトコルの詳細は、全体的なトランザクションモデルを形成するとともに、問題のブロックチェーン150で使用されているトランザクションプロトコルのタイプに対応する。ノードプロトコルは、典型的には、新規トランザクション152jにおける暗号署名が、トランザクション152の順序付けされたシーケンスにおける以前のトランザクション152iに依存する、期待される署名と一致することをチェックするために、ノード104を必要とする。出力ベースの事例において、このことは、新しいトランザクション152jの入力に含まれるユーザの暗号署名が、新しいトランザクションが支払う先行トランザクション152iの出力に定義された条件と一致することをチェックすることを含み得る。ここで、この条件は、典型的には、新しいトランザクション152jの入力における暗号署名が、新しいトランザクションの入力が指し示す先行トランザクション152iの出力をアンロックすることを、少なくともチェックすることを含む。いくつかのトランザクションプロトコルにおいて、条件は、少なくとも部分的に、入力及び／又は出力に含まれるカスタムスクリプトによって定義され得る。代替的に、単にノードプロトコルだけで固定され得るし、または、これらの組み合わせによるものであり得る。いずれにせよ、新しいトランザクション152jが有効である場合、現在のノードは、P2Pネットワーク106内のノード104の１つ以上の他のノードに対して、それを移転する。これらのノード104の少なくとも一部は、転送ノード104Fとしても機能し、同じノードプロトコルに従って同じテストを適用し、そして、新しいトランザクション152jを１つ以上のさらなるノード104に移転する、など。このようにして、新しいトランザクションは、ノード104のネットワーク全体に伝搬される。
出力ベースのモデルにおいて、所与の出力(例えば、UTXO)が支払われるか否かの定義は、別の、ノードプロトコルに従った前向き（onward）トランザクション152jの入力によって、いまだ有効に償還されているか否かである。トランザクションが有効であるための別の条件は、それが支払または償還を試みる先行トランザクション152iの出力が別の有効なトランザクションによって既に支払／償還されていないことである。再度、有効でない場合、トランザクション152jは、伝搬されず、または、ブロックチェーンに記録されない。このことは、同じトランザクションのアウトプットを一度ならず支払おうと試みる二重支払を防ぐ。一方で、アカウントベースのモデルは、アカウントバランスを維持することによって、二重支払を防ぐ。再び、トランザクションの定義された順序が存在するので、アカウントバランスは、いつでも単一の定義された状態を有している。
検証に加えて、ノード104Mの少なくとも一部は、また、「プルーフオブワーク」によって支えられている、マイニングとして知られるプロセスにおけるトランザクションのブロックを最初に作成するように競合している。マイニングノード104Mでは、まだブロックに現れていない有効なトランザクションのプールに対して新しいトランザクションが追加される。次いで、マイナは、暗号パズルを解決しようと試みることによって、トランザクションのプール154からトランザクション152の新しい有効なブロック151を組み立てようと競合する。典型的に、このことは、「ナンス（“nonce”）」値を検索することを含み、その結果、ナンスがトランザクションのプール154と連結され、かつ、ハッシュ化されると、ハッシュの出力が規定の条件を満たす。例えば、既定の条件は、ハッシュの出力が、所定の既定数の先頭ゼロ（leading zeros）を有することであり得る。ハッシュ関数の特性は、入力に関して予測不可能な出力を有することである。従って、この探索は、ブルートフォース（brute force）によってのみ実行することができ、従って、パズルを解くように試みている各ノード104Mにおいて、相当量の処理リソースを消費している。
パズルを解くための第１マイナノード104Mは、これをネットワーク106に通知し、その解（solution）を証明として提供し、それは、ネットワーク内の他のノード104によって容易にチェックすることができる(一旦ハッシュに対して解が与えられれば、それがハッシュの出力を条件に合致させることをチェックすることは簡単である)。勝者がパズルを解いたトランザクション154のプールは、次に、そうした各ノードにおいて勝者がアナウンスした解をチェックしたことに基づいて、ストレージノード104Sとして動作しているノード104の少なくとも一部によって、ブロックチェーン150内の新しいブロック151として記録される。ブロックポインタ155は、また、チェーン内の先に生成されたブロック151n-1に戻って指し示す新しいブロック151nにも割り当てられる。プルーフオブワークは、新しいブロック151を作成するために多大な労力を要するので、二重支払のリスクを低減するのに役立つ。そして、二重支払を含む任意のブロックは他のノード104によって拒否される可能性が高いので、マイニングノード104Mは、二重支払がそれらのブロックに含まれるのを許可しないように動機付けされている。一旦生成されると、ブロック151は、同じプロトコルに従ってP2Pネットワーク106内のストレージノード104Sそれぞれで認識され、そして、維持されるので、修正することができない。ブロックポインタ155は、また、ブロック151に対して逐次的な順序を課す。トランザクション152は、P2Pネットワーク106内の各ストレージノード104Sにおいて順序付けられたブロックに記録されるので、このことは、従って、トランザクションの不変の公開台帳（public ledger）を提供する。
異なる104Mのマイナが、任意の所与の時間に競合していることは、彼らがいつ解決策を探し始めたかに応じて、任意の所与の時間に、マイニングされていないトランザクションプール154の異なるスナップショットに基づいて、そうすることができることに留意されたい。それぞれのパズルを誰が最初に解くかは、どのトランザクション152が次の新しいブロック151nに含まれるかを定義し、そして、現在のマイニングされていないトランザクションのプール154が更新される。次いで、マイナ104Mは、新たに定義された保留中のプール154からブロックを生成するために競合を継続する、など。生じ得る任意の「フォーク（“fork”）」を解決するためのプロトコルも、また、存在する。それは、二人のマイナ104Mが相互に非常に短い時間内にパズルを解き、その結果、ブロックチェーンの矛盾した見方が伝播されるものである。要するに、フォークのどの突起が伸びても、最も長いものが最終的なブロックチェーン150になる。
ほとんどのブロックチェーンでは、勝ったマイナ104Mは、(あるユーザから別のユーザにデジタル資産の総計を移転する通常のトランザクションとは対照的に)どこからともなく新しい量のデジタル資産を創出する特別な種類の新しいトランザクションで自動的に報酬を受け取る（rewarded）。従って、勝ったノードが、デジタル資産の総計を「マイニングした（“mined”）」と言える。この特別なタイプのトランザクションは、ときどき、「ジェネレーション（“generation”）」トランザクションと呼ばれる。それは、自動的に新しいブロック151nの一部を形成する。この報酬は、マイナ104Mがプルーフオブワークの競争に参加するようにインセンティブを与える。通常の(非ジェネレーション)トランザクション152は、また、その出力の１つに追加のトランザクション料（fee）も指定し、そのトランザクションが含まれたブロック151nを生成した勝ったマイナ104Mにさらに報酬を与える。
マイニングに関与する計算リソースのため、典型的に、少なくともマイナノード104Mそれぞれは、１つ以上の物理的サーバユニット、または、データセンタ全体を含むサーバの形態をとる。各転送ノード104M及び／又はストレージノード104Sは、また、サーバ又はデータセンタの形態をとることもできる。しかしながら、原則として、任意の所与のノード104は、ユーザ端末、または、一緒にネットワーク接続されたユーザ端末のグループの形態をとることができる。
各ノード104のメモリは、それぞれの役割を実行し、かつ、ノードプロトコルに従ってトランザクション152を処理するために、ノード104の処理装置上で実行するように構成されたソフトウェアを保管する。ここにおいてノード104に帰属された任意の動作（action）は、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されるだろう。また、ここにおいて使用される用語「ブロックチェーン（“blockchain”）」は、一般的な技術の種類を指し、そして、あらゆる特定の専有ブロックチェーンプロトコルまたはサービスに限定されない、一般的な用語である。
また、ネットワーク101に接続されているのは、ユーザを消費する（consuming）役割の複数の当事者103それぞれのコンピュータ機器102である。これらは、トランザクションにおける支払人（payers）および受取人（payee）の役割を果たすが、他の当事者のためにトランザクションのマイニングまたは伝播に必ずしも参加するものではない。それらは、必ずしもマイニングプロトコルを実行するわけではない。二人の当事者103および彼らそれぞれの機器102が、説明のために示されている。第１当事者103aおよび彼／彼女それぞれのコンピュータ機器102a、並びに、第２当事者103bおよび彼／彼女それぞれのコンピュータ機器102bである。より多くのそうした当事者103および彼らそれぞれのコンピュータ機器102がシステムに存在し、かつ、参加することができるが、便宜上、それらは図示されていないことが理解されるだろう。各当事者103は、個人または組織であってよい。純粋に例示として、第１当事者103aは、ここにおいてはアリスとして参照され、そして、第２当事者103bは、ボブとして参照されるが、これは限定的なものではなく、そして、ここにおけるアリスまたはボブに対する参照を、「第１当事者」および「第２当事者」とそれぞれに置き換えることができることが理解されるだろう。
各当事者103のコンピュータ機器102は、１つ以上のプロセッサを含むそれぞれの処理装置を備えている。例えば、１つ以上のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び／又は、である。各当事者103のコンピュータ機器102は、さらに、メモリ、すなわち、非一時的なコンピュータで読取り可能な媒体またはメディアの形態のコンピュータで読取り可能なストレージ装置を備える。このメモリは、１つ以上のメモリ媒体を使用する１つ以上のメモリユニットを含み得る。例えば、ハードディスクといった磁気媒体、SSD、フラッシュメモリ、またはEEPROMといった電子媒体、及び／又は、光ディスクドライブといった光媒体である。各当事者103のコンピュータ機器102上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーション105それぞれのインスタンスを含むソフトウェアを保管する。ここにおいて所与の当事者103に帰属された任意の動作は、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されるだろう。各当事者103のコンピュータ機器102は、少なくとも１つのユーザ端末を備えている。例えば、デスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチといったウェアラブルデバイスである。所与の当事者103のコンピュータ機器102は、また、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースといった、１つ以上の他のネットワーク化されたリソースを含んでもよい。
クライアントアプリケーションまたはソフトウェア105は、最初に、適切なコンピュータで読取り可能な記憶媒体またはメディアにおいて、任意の所与の当事者103のコンピュータ機器102に提供され得る。例えば、サーバからダウンロードされたもの、または、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピー（登録商標）ディスクまたはテープ、CDまたはDVD ROMといった光ディスク、もしくは、リムーバブル光学ドライブ、等である。
クライアントアプリケーション105は、少なくとも「ウォレット（“wallet”）」機能を備える。これは、２つの主な機能を有している。これらの１つは、それぞれのユーザ当事者103が、ノード104のネットワーク全体にわたり伝搬され、そして、それによってブロックチェーン150に含まれるように、トランザクション152を作成し、署名し、かつ、送信することを可能にすることである。他方は、現在所有しているデジタル資産の総計をそれぞれの当事者に戻って報告することである。出力ベースのシステムにおいて、この第２機能は、問題の当事者に属するブロックチェーン150全体にわたり散在する様々なトランザクション152の出力に定義される総計を照合することを含む。
各コンピュータ機器102上のクライアントアプリケーション105のインスタンスは、P2Pネットワーク106の転送ノード104Fの少なくとも１つに動作可能に結合されている。これにより、クライアント105のウォレット機能は、トランザクション152をネットワーク106に送信することができる。クライアント105は、また、ストレージノード104のうちの１つ、一部、または全部にコンタクトして、それぞれの当事者103が受取人である任意のトランザクションについてブロックチェーン150にクエリ（query）することができる(もしくは、実際には、ブロックチェーン150内の他の当事者のトランザクションを検査する。実施形態でブロックチェーン150は、部分的にその公衆の目に触れてトランザクションの信頼を提供する公共施設（public facility）だからである)。各コンピュータ機器102上のウォレット機能は、トランザクションプロトコルに従って、トランザクション152を形成し、かつ、送信するように構成されている。各ノード104は、ノードプロトコルに従って、トランザクション152を検証するように構成されたソフトウェアを実行し、転送ノード104Fの場合は、ネットワーク106全体にトランザクション152を伝播させるためにトランザクション152を移転する。トランザクションプロトコルおよびノードプロトコルは、相互に対応しており、そして、所与のトランザクションプロトコルは、所与のノードプロトコルと共に、所与のトランザクションモデルを一緒に実装する。同じトランザクションプロトコルが、ブロックチェーン150内の全てのトランザクション152について使用される(ただし、トランザクションプロトコルは、トランザクションの異なるサブタイプを許可し得る)。同じノードプロトコルは、ネットワーク106内の全てのノード104によって使用される(ただし、多くのノードは、そのサブタイプに対して定義されたルールに従って、異なるトランザクションのサブタイプを異なるように処理し、そして、また、異なるノードは、異なる役割を引き受け、従って、プロトコルの異なる対応する態様を実装することができる)。
上述のように、ブロックチェーン150は、ブロック151のチェーンを含み、ここで、各ブロック151は、上述のように、プルーフオブワークプロセスによって作成された１つ以上のトランザクション152のセットを含む。各ブロック151は、また、ブロック151への逐次的な順序を規定するように、チェーン内の先に生成されたブロック151に戻って指し示すブロックポインタ155を含む。ブロックチェーン150は、また、プルーフオブワークプロセスによって新しいブロックに含まれることを待っている有効なトランザクション154のプールも含む。各トランザクション152(ジェネレーショントランザクション以外)は、トランザクションの順序を定義するように、以前のトランザクションへ戻るポインタを含む(トランザクション152のシールドは分岐（branch）が許されることに注意する)。ブロック151のチェーンは、チェーン内の最初のブロックであった生成ブロック（genesis block4，Gb）153にはるばる戻る。チェーン150内の初期における１つ以上のオリジナルトランザクション152は、先行トランザクションではなく生成ブロック153を指し示していた。
所与の当事者103、例えばアリス、が、ブロックチェーン150に含まれるように新しいトランザクション152jを送信することを望む場合、彼女は、関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105においてウォレット機能を使用して)、新しいトランザクションを策定する。彼女は、次に、クライアントアプリケーション105からトランザクション152を、彼女が接続されている１つ以上の転送ノード104Fの１つに送信する。例えば、これは、アリスのコンピュータ102に最も近いか、または、最も良好に接続されている転送ノード104Fであってよい。任意の所与のノード104が新しいトランザクション152jを受信すると、それは、ノードプロトコルおよびそれぞれの役割に従って処理する。このことは、新たに受信されたトランザクション152jが「有効（“valid”）」であるための特定の条件を満たすか否かを、最初にチェックすることを含み、その例について、手短に、より詳細が説明される。いくつかのトランザクションプロトコルにおいて、検証のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに設定可能である。代替的に、条件は、単にノードプロトコルの組み込み機能であってよく、または、スクリプトとノードプロトコルの組み合わせによって定義されてもよい。
新たに受信されたトランザクション152jが、有効であるとみなされるテストを通過（pass）するという条件(すなわち、「検証済み（validated）」である条件)で、トランザクション152jを受信する任意のストレージノード104Sは、そのノード104Sに維持されているブロックチェーン150のコピー内のプール154に、新たに有効とされたトランザクション152を追加する。さらに、トランザクション152jを受信する任意の転送ノード104Fは、検証済みトランザクション152をP2Pネットワーク106内の１つ以上の他のノード104へ伝搬する。各転送ノード104Fは同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、このことは、P2Pネットワーク106全体に間もなく伝搬されることを意味する。
一旦、１つ以上のストレージノード104で維持されるブロックチェーン150のコピー内のプール154に入ると、マイナノード104Mは、新しいトランザクション152を含むプール154の最新バージョンのプルーフオブワークのパズルを解くための競合を開始する(他のマイナ104Mは、依然として、プール154の古い見解に基づいてパズルを解こうとしているが、最初にそこに到達した者は誰でも、次の新しいブロック151が終了し、新しいプール154が開始する場所を定義し、そして、最終的には、誰かが、アリスのトランザクション152jを含むプール154の一部のパズルを解く)。一旦、新しいトランザクション152jを含むプール154についてプルーフオブワークが行われると、それはブロックチェーン150内のブロック151のうち１つの不変の一部となる。各トランザクション152は、以前のトランザクションへ戻るポインタを含むので、トランザクションの順序も、また、不変的に記録される。
図2は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略す)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は１つ以上のトランザクション152を含んでいる)。以下は、出力ベースのプロトコルまたは「UTXO」ベースのプロトコルを参照して説明されている。しかしながら、このことは、全ての可能な実施形態に限定されるものではない。
UTXOベースのモデルにおいて、各トランザクション(「Tx」)152は、１つ以上の入力202および１つ以上の出力203を含むデータ構造を備える。各出力203は、未支払（unspent）のトランザクション出力(UTXO)を含んでよく、それは、別の新しいトランザクションの入力202のソースとして使用することができる(UTXOが既に償還されてはいない場合)。UTXOは、デジタル資産の総計(価値のストア)を指定する。また、他の情報の中でも、それが来たトランザクションのトランザクションIDを含んでもよい。トランザクションデータ構造は、また、ヘッダ201を含んでもよく、入力フィールド202および出力フィールド203のサイズの指示（indicator）を含み得る。ヘッダ201は、また、トランザクションのIDを含み得る。実施形態において、トランザクションIDは、トランザクションデータ(トランザクションID自体を除く)のハッシュであり、マイナ104Mに提出された生の（raw）トランザクション152のヘッダ201に保管される。
アリス103aは、問題のデジタル資産の総計をボブ103bに移転するトランザクション152jを作成したいと考えていると仮定する。図2では、アリスの新しいトランザクション152jが「Tx1」とラベル付けされている。これは、先行トランザクション152iの出力203においてアリスにロックされているデジタル資産の総計を順番に取り、そして、これの少なくとも一部をボブに移転する。先行トランザクション152iは、図2では「Tx0」とラベル付けされており、Tx0およびTx1は、単なる任意のラベルである。これらは、必ずしも、Tx0がブロックチェーン151の最初のトランザクションであること、または、Tx1がプール154内で直近の次のトランザクションであることを意味するものではない。Tx1は、アリスにロックされた未支払の出力203を依然として有する、任意の先行する（つまり、先立つ（antecedent））トランザクションに戻って指し示すことができる。
先行トランザクションTx0は、アリスがその新しいトランザクションTx1を作成する時点、または、少なくとも彼女がそれをネットワーク106に送信する時点で、既に検証され、ブロックチェーン150に含まれていてよい。それは、その時点で既にブロック151のうち１つに含まれていてよい。または、プール154内でまだ待機していてもよく、その場合には、そのうちに含まれることになる。代替的に、Tx0およびTx1が作成されて、一緒にネットワーク102に送信され得るし、または、ノードプロトコルが「孤立（“orphan”）」トランザクションのバッファリングを許可する場合、Tx0はTx1の後でさえ送信され得る。用語「先行（“preceding”）」および「後続（“subsequent”）」は、ここにおいてトランザクションのシーケンスのコンテキストにおいて使用されるように、トランザクションで指定されたトランザクションポインタによって定義されるシーケンスにおけるトランザクションの順序を指す(どのトランザクションポインタが他のトランザクションに戻って指し示すか、など)。それらは、「前任者（“predecessor”）」と「後任者（“successor”）」、「前者（“antecedent”）」「後者（“descent”）」、「親（“parent”）」と「子（“child”）」、等と均等に置き換えることができる。これは、必ずしもそれらが生成され、ネットワーク106に送信され、または、任意の所与のノード104に到着する順序を意味するものではない。それにもかかわらず、先行トランザクション(前任者トランザクションまたは「親」)を指し示す後続トランザクション(後任者トランザクションまたは「子」)は、親トランザクションが検証されるまで、および、検証されなければ、検証されない。親の前にノード104に到着した子は、孤立（orphan）とみなされる。それは、ノードプロトコル及び／又はマイナの行動に応じて、破棄され、または、親を待つために一定時間、破棄またはバッファリングされ得る。
先行トランザクションTx0の１つ以上の出力203のうち１つは、ここにおいてUTXO0とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の総計を指定する値、および、後続トランザクションが検証されるため、そして、従って、UTXOが成功裡に償還されるために、後続トランザクションの入力202においてアンロッキングスクリプトによって満足されねばならない条件を定義するロッキングスクリプトを含む。典型的に、ロッキングスクリプトは、特定の当事者(それが含まれているトランザクションの受益者（beneficiary）)に対して総計をロックする。すなわち、ロッキングスクリプトは、アンロッキング条件を定義し、典型的に、後続トランザクションの入力におけるアンロッキングスクリプトは、先行トランザクションがロックされる当事者の暗号署名を含む、という条件を含む。
ロッキングスクリプト(別名、scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの一部である。そうした言語の特定の例は、「スクリプト（“Script”）」(キャピタルS)と呼ばれる。ロッキングスクリプトは、トランザクション出力203を支払うために必要な情報、例えば、アリスの署名の必要条件、を指定する。アンロッキングスクリプトがトランザクションの出力に現れる。アンロッキングスクリプト(別名、scriptSig)は、ロッキングスクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えば、それは、ボブの署名を含んでよい。アンロッキングスクリプトは、トランザクションの入力202に現れる。
図示の例において、Tx0の出力203のUTXO0は、ロッキングスクリプト[Checksig PA]を含み、これは、UTXO0が償還されるために(厳密には、UTXO0を償還しようとする後続トランザクションが有効であるために)、アリスの署名Sig PAを必要とする。[Checksig PA]は、アリスの公開鍵と秘密鍵のペアからの公開鍵PAを含む。Tx1の入力202は、Tx1に戻って指し示すポインタを含む(例えば、そのトランザクションIDである、TxID0を用い、それは実施形態においてトランザクションTx0全体のハッシュである)。Tx1の入力202は、Tx0の任意の他の可能な出力の中でそれを識別するために、Tx0内のUTXO0を識別するインデックス（index）を含む。Tx1の入力202は、さらに、鍵ペアからのアリスの秘密鍵をデータの既定の部分に適用することによって作成された、アリスの暗号署名を含むアンロッキングスクリプト<Sig PA>を含む(ときどき、暗号では「メッセージ（“message”）」と呼ばれる)。有効な署名を提供するためにアリスが署名する必要があるデータ(または「メッセージ」)は、ロッキングスクリプト、ノードプロトコル、またはこれらの組み合わせによって定義される。
新しいトランザクションTx1がノード104に到着すると、ノードは、ノードプロトコルを適用する。これは、ロッキングスクリプトとアンロッキングスクリプトを一緒に実行して、アンロッキングスクリプトがロッキングスクリプト内で定義されている条件を満たしているか否かをチェックすることを含む(ここで、この条件は１つ以上の基準を含み得る)。実施形態において、これは、２つのスクリプトを連結することを含む。
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、そして、「<...>」はデータをスタック上に置くことを意味し、そして、「[...]」はアンロッキングスクリプト(この例においてスタックベースの言語)で構成される関数である。同様に、スクリプトは、スクリプトを連結するのではなく、共通のスタックで、次々と実行されてよい。いずれにせよ、一緒に実行する場合、スクリプトは、Tx0の出力のロッキングスクリプトに含まれるように、アリスの公開鍵PAを使用して、Tx1の入力のロッキングスクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。この認証を実行するためには、データ自体の期待される部分(「メッセージ（“message”）」)も、また、Tx0順序に含める必要がある。実施形態において、署名されたデータは、Tx0の全体を含む(よって、別個の要素は、クリアであるデータ（data in the clear）の署名された部分を指定することに含める必要がある。それが、既に本質的に存在するからである)。
公開－秘密（public-private）暗号による認証の詳細は、当業者にとって周知であろう。基本的に、アリスが秘密鍵を使用して、暗号化することによってメッセージに署名した場合、アリスの公開鍵およびクリアであるメッセージ(暗号化されていないメッセージ)が与えられ、ノード104といった別のエンティティは、そのメッセージの暗号化されたバージョンがアリスによって署名されていなければならないことを認証することができる。署名することは、典型的に、メッセージをハッシュすること、ハッシュに署名すること、および、署名としてメッセージのクリアなバージョンにこれをタグ付けすることを含み、従って、公開鍵の任意の所有者が署名を認証することを可能にしている。
Tx1のアンロッキングスクリプトが、Tx0のロッキングスクリプトで指定された１つ以上の条件を満たす場合(例で示されるように、アリスの署名がTx1で提供され、かつ、認証されている場合)、ノード104は、Tx1が有効であるとみなす。マイニングノード104Mである場合、これは、プルーフオブワークを待っているトランザクションプール154に追加されることを意味する。転送ノード104Fである場合、それは、トランザクションTx1をネットワーク106内の１つ以上の他のノード104に転送し、その結果、ネットワーク全体に伝搬されることになる。一旦、Tx1が検証され、かつ、ブロックチェーン150に含まれると、これは、支払としてTx0からUTXO0を定義する。Tx1は、未払いのトランザクション出力203を支払う場合にだけ有効であることに留意されたい。別のトランザクション152によって既に支払われた出力を支払おうとする場合、Tx1は、たとえ他の全ての条件が満たされていても無効となる。従って、ノード104は、また、先行トランザクションTx0において参照されたUTXOが既に使用されているか否か(既に別の有効なトランザクションへの有効な入力を形成しているか否か)もチェックする必要がある。これが、ブロックチェーン150にとってトランザクション152に定義された順序を課すことが重要である理由の１つである。実際に、所与のノード104は、トランザクション152が支払われたUTXO 203をマーキングしている別個のデータベースを維持することができるが、最終的には、UTXOが支払われたか否かを定義するものは、ブロックチェーン150内の別の有効なトランザクションへの有効な入力が既に形成されているか否かである。
UTXOベースのトランザクションモデルでは、所与のUTXOを全体として使用する必要があることに注意すること。UTXOで定義されている総計のうち、別の小部分（fraction）が支払われている一方で、小部分を「残しておく（“leave behind”）」ことはできない。しかしながら、UTXOの総計は、次のトランザクションの複数の出力に分割できる。例えば、Tx0内のUTXO0で定義された総計は、Tx1内の複数のUTXOに分割できる。従って、アリスがボブにUTXO0で定義されている総計の全てを与えることを望まない場合、彼女は、残りの量を使って、Tx1の第２出力で自分自身にお釣り（change）を与え、または、別の当事者に支払うことができる。
実際には、アリスは、また、たいてい、勝ったマイナのための報酬（fee）を含める必要がある。なぜなら、今日では、ジェネレーショントランザクションの報酬だけでは、典型的に、マイニングを動機付けるために十分ではないからである。アリスがマイナのための報酬を含めない場合、Tx0は、マイナのノード104Mによって拒否される可能性が高く、従って、技術的には有効であるが、それは、未だに伝播されず、そして、ブロックチェーン150に含まれている(マイナプロトコルは、マイナが望まない場合、トランザクション152を受け入れるよう強制しない)。いくつかのプロトコルにおいて、マイニング報酬は、独自の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって示される全ての総計と、所与のトランザクション152の出力203で指定される全ての総計との間の差が、勝ったマイナ104に自動的に与えられる。例えば、UTXO0に対するポインタがTx1への唯一の入力であり、かつ、Tx1は１つの出力UTXO1しか持っていないとする。UTXO0で指定されたデジタル資産の総計がUTXO1で指定された総計より多い場合、その差は、自動的に勝ったマイナ104Mに行く。代替的または追加的に、しかしながら、トランザクション152のUTXO 203のうちの独自のものにおいてマイナ報酬が明示的に指定され得ることは、必ずしも除外されない。
また、所与のトランザクション152の全ての出力203で指定された全ての総計が、その全ての入力202で指定された全ての総計よりも大きい場合、これは、ほとんどのトランザクションモデルにおける無効性の別の根拠であることに留意すること。従って、そうしたトランザクションは、伝搬され、または、ブロック151にマイニングされることはない。
アリスとボブのデジタル資産は、ブロックチェーン150内の任意の場所の任意のトランザクション152において、ロックされている未支払のUTXOで構成されている。従って、典型的に、所与の当事者103の資産は、ブロックチェーン150の全体を通して、様々なトランザクション152のUTXO全体に分散されている。ブロックチェーン150内のどこにも、所与の当事者103の全ての残高（balance）を定義する１つの数字は保管されていない。各当事者に対してロックされており、かつ、別の前向き（onward）トランザクションでまだ支払われていない全ての様々なUTXOの値を一緒に照合することは、クライアントアプリケーション105におけるウォレット機能の役割である。これは、任意のストレージノード104S、例えば、各当事者のコンピュータ機器102に最も近く、または、最も良好に接続されているストレージノード104S、に保管されたブロックチェーン150のコピーをクエリすることによって行うことができる。
スクリプトコードは、しばしば、概略的に表現されることに注意すること(すなわち、正確な言語ではない)。例えば、[Checksig PA]を、[Checksig PA]=OP_DUP OP_HASH160<H(Pa)>OP_EQUALVERIFY OP_CHECKSIGを意味するように書き込むことがあり得る。「OP_...」は、スクリプト言語の特定のオペコードを指している。OP_CHECKSIG(「Checksig」とも呼ばれるもの)は、２つの入力(署名と公開鍵)を取り込み、そして、楕円曲線デジタル署名アルゴリズム(ECDSA)を使用して署名の妥当性を検証する、Scriptオペコードである。ランタイムでは、あらゆる署名(「sig」)の発生はスクリプトから削除されるが、ハッシュパズルといった、追加的な要件は、「sig」入力によって検証されるトランザクション内に残る。別の例として、OP_RETURNは、トランザクション内にメタデータを保管することができる、トランザクションの支払不能な出力を生成するためのスクリプト言語のオペコードであり、そして、それによってメタデータをブロックチェーン150に不変に記録することができる。例えば、メタデータは、ブロックチェーンに保管することが望ましい文書を含み得る。
署名PAは、デジタル署名である。実施形態において、これは、楕円曲線secp256K1を使用するECDSAに基づくものである。デジタル署名は、データの特定なピース（piece）に署名する。実施形態において、所与のトランザクションについて、署名は、トランザクション入力の一部、および、トランザクション出力の全部または一部に署名する。署名する出力のうち特定の部分は、SIGHASHフラグに依存している。SIGHASHフラグは、署名の最後に含まれる4バイトのコードであり、どの出力が署名されるか(従って、署名の時点で固定されること)を選択する。
ロッキングスクリプトは、それぞれのトランザクションがロックされている当事者の公開鍵を含んでいるという事実を参照して、ときどき、「scriptPubKey」と呼ばれる。アンロッキングスクリプトは、対応する署名を提供するという事実を参照して、ときどき、「scriptSig」と呼ばれる。しかしながら、より一般的には、UTXOが償還される条件が署名を認証することを含むことは、ブロックチェーン150の全てのアプリケーションにおいて必須ではない。より一般的に、スクリプト言語は、任意の１つ以上の条件を定義するために使用され得る。従って、より一般的な用語として「ロッキングスクリプト」および「アンロッキングスクリプト」が望ましい。
任意的なサイドチャネル
図3は、ブロックチェーン150を実装するためのさらなるシステム100を示している。システム100は、追加的な通信機能が含まれることを除いて、図1に関連して説明したものと実質的に同じである。アリスとボブのコンピュータ機器102a、120bそれぞれにおけるクライアントアプリケーションは、それぞれに、追加的な通信機能を備えている。すなわち、アリス103aは、(いずれかの当事者または第三者の勧誘（instigation）で)ボブ103bと別個のサイドチャネル301を確立することを可能にする。サイドチャネル301は、P2Pネットワークとは別にデータの交換を可能にする。そうした通信は、ときどき、「オフチェーン（“off-chain”）」と呼ばれる。例えば、これは、当事者の一方がネットワーク106にそれをブロードキャストすることを選択するまで、トランザクションが（未だ）ネットワークP2P 106上に公開されることなく、または、チェーン150上に進むことなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。代替的または追加的に、サイドチャネル301は、キー、交渉された総計または条件、データコンテンツ、等といった、任意の他のトランザクション関連データを交換するために使用することができる。
サイドチャネル301は、P2Pオーバーレイネットワーク106と同じパケット交換（packet-switched）ネットワーク101を介して確立され得る。代替的または追加的に、サイドチャネル301は、移動セルラネットワークといった異なるネットワーク、またはローカル無線ネットワークといったローカルエリアネットワーク、もしくはアリスとボブの装置1021、102bとの間の直接的な有線または無線リンク、を介して確立され得る。一般的に、ここにおいて任意の箇所で言及されるサイドチャネル301は、「オフチェーン」、すなわち、P2Pオーバーレイネットワーク106とは別に、データを交換するための１つ以上のネットワーク技術または通信媒体を介した任意の１つ以上のリンクを含んでよい。２つ以上のリンクが使用される場合、全体としてのオフチェーンリンクのバンドルまたはコレクションは、サイドチャネル301として称されてよい。従って、アリスとボブが、サイドチャネル301を介して、情報またはデータの特定のピース、または、そうしたものを交換すると言われる場合、これは、これらのデータの全てが正確に同じリンクまたは同じタイプのネットワークを介して送信されなければならないことを、必ずしも意味するものではないことに注意すること。
ノードソフトウェア
図4は、UTXOまたは出力ベースのモデルの例において、P2Pネットワーク106の各ノード104上で実行されるノードソフトウェア400の例を示している。ノードソフトウェア400は、プロトコルエンジン401、スクリプトエンジン402、スタック403、アプリケーションレベル決定エンジン404、および、１つ以上のブロックチェーン関連機能モジュールのセット405を備える。任意の所与のノード104において、これらは、(ノードの役割または役割に応じて)マイニングモジュール405M、転送モジュール405F、および、ストレージモジュール405Sのいずれか１つ、２つ、または３つ全てを含み得る。プロトコルエンジン401は、トランザクション152の異なるフィールドを認識し、ノードプロトコルに従って、それらを処理するように構成されている。別の、先行トランザクション152m-1（Txm-1）の、出力(例えば、UTXO)を指す入力を有するトランザクション152m(Txm)が受信されると、プロトコルエンジン401は、Txm内のアンロッキングスクリプトを識別し、そして、スクリプトエンジン402にそれを渡す。プロトコルエンジン401は、また、Txm内の入力のポインタに基づいて、Txm-1を識別し、かつ、検索する。それは、Txm-1が、まだブロックチェーン150上にない場合には、保留中のトランザクションのそれぞれのノード自身のプール154から、もしくは、Txm-1が、既にブロックチェーン150上にある場合には、それぞれのノードまたは別のノード104に保管されたブロックチェーン150内のブロック151のコピーから、検索することができる。いずれにせよ、スクリプトエンジン401は、Txm-1の指し示された出力内のロッキングスクリプトを識別し、そして、これをスクリプトエンジン402に渡す。
従って、スクリプトエンジン402は、Txm-1のロッキングスクリプト、および、Txmの対応する入力からのアンロッキングスクリプトを有する。例えば、Tx1とTx2が図4に示されているが、同様のことが、Tx0とTx1、等といった、トランザクションの任意のペアについて適用され得る。スクリプトエンジン402は、上述のように、２つのスクリプトを一緒に実行する。それは、使用されるスタックベースのスクリプト言語(例えば、スクリプト)に従って、スタック403にデータを配置すること、および、スタック403からデータを取り出すことを含む。
スクリプトを一緒に実行することによって、スクリプトエンジン402は、アンロッキングスクリプトがロッキングスクリプトで定義された１つ以上の基準（criteria）を満たすか否かを決定する。すなわち、ロッキングスクリプトが含まれる出力を「アンロック」するか？である。スクリプトエンジン402は、この決定の結果をプロトコルエンジン401に戻す。スクリプトエンジン402は、対応するロッキングスクリプトで指定された１つ以上の基準を満たすことをアンロッキングスクリプトが決定した場合には、結果「真（“true”）」を返す。そうでなければ、結果「偽（“false”）」を返す。
出力ベースのモデルでは、スクリプトエンジン402からの「真」の結果は、トランザクションの有効性の条件の１つである。典型的には、また、同様に満たされなければならない、さらなる、プロトコルエンジン401によって評価される１つ以上のプロトコルレベルの条件が存在する。
Txmの出力に指定されたデジタル資産の全ての総計が入力によって指し示された全ての総計を超えないこと、および、Txm-1の指し示された出力が別の有効なトランザクションによって未だ支払われてこと、といったものである。プロトコルエンジン401は、スクリプトエンジン402からの結果を、１つ以上のプロトコルレベル条件と一緒に評価し、そして、それらが全て真である場合にだけ、トランザクションTxmを確認する。プロトコルエンジン401は、トランザクションがアプリケーションレベル決定エンジン404に対して有効であるか否かの指示を出力する。Txmが実際に検証された条件においてのみ、決定エンジン404は、Txmに関するそれぞれのブロックチェーン関連機能を実行するために、マイニングモジュール405Mおよび転送モジュール405Fの一方または両方を制御するように選択することができる。このことは、ブロック151へのマイニングのためにノードのそれぞれのプール154に対してTxmを追加するマイニングモジュール405M、及び／又は、P2Pネットワーク106内の別のノード104へTxmを転送する転送モジュール405Fを含むことができる。しかしながら、実施形態において、決定エンジン404は、無効なトランザクションを転送またはマイニングすることを選択しないが、これは、逆に、それが単に有効であるという理由で、有効なトランザクションのマイニングまたは転送をトリガする義務があることを、必ずしも意味するものではないことに留意すること。任意的に、実施形態において、決定エンジン404は、一方または両方の機能をトリガする前に、１つ以上の追加条件を適用することができる。例えば、ノードがマイニングノード104Mである場合、決定エンジンは、トランザクションが有効であり、かつ、十分なマイニング報酬を残していることを条件としてのみ、トランザクションをマイニングするように選択することができる。
また、用語「真」および「偽」は、ここにおいて、必ずしも単一のバイナリーデジット(ビット)のだけの形式で表される結果を返すことに限定されるものではないが、これは、確かに１つの可能な実装であることにも注意すること。より一般的に、「真」は、成功または肯定的な結果を示す任意の状態を指し、そして、「偽」は、失敗または否定的な結果を示す任意の状態を指すことができる。例えば、アカウントベースのモデルにおいて(図4には示されていない)、「真」の結果は、ノード104による署名の暗黙の、プロトコルレベルの検証、および、スマート契約の追加の肯定的な出力の組み合わせによって示され得る(両方の個々の結果が真であれば、全体の結果は真であると見なされる)。
マークルツリー（Merkle tree）
図5は、マークルツリー500の例示的な構造を示している。マークルツリーは、この技術分野では、また、ハッシュツリー（hash tree）としても参照されるものである。用語は、ここにおいて互換的に使用されている。ツリー内の各ノード(円で示されている)には、インデックスペア(i,j)が与えられ、N(i,j)として表わされる。インデックスi,jは、ツリー内の特定の位置に関連する数値ラベルである。マークルツリーの特徴は、ノードそれぞれの構成が、以下の方程式によって支配されることである。
Figure 2022541323000002
 ここで、k=(i+j-1)/2であり、かつ、Hは暗号ハッシュ関数である。
図5は、i=jであるケースが、リーフノード501に対応することを示しており、それは、単に、データDiの対応するi番目ブロックのハッシュである。i≠jであるケースは、内部ノード502またはルートノード503に対応し、それは、特定のノードまたはルートに到達するまでツリー内で子ノード（child node）を再帰的にハッシュし、かつ、連結することによって生成される。ツリーのリーフノードは、また、ここにおいて、リーフハッシュとも呼ばれる。同様に、内部ノード（internal node）およびルートノードは、それぞれ内部ハッシュおよびルートハッシュとも呼ばれる。マークルツリーの構築には、暗号ハッシュ関数の使用が必要である。
大部分のアプリケーションにおけるマークルツリーの主な機能は、あるデータブロックDi504がNデータブロックのリストまたはセットのメンバーであることの証明を容易にすることである、Ｄ∈{D1,…,DN}。ルートハッシュおよび候補データブロックDiが与えられると、これは、セット内のブロックの「存在証明（proof-of-existence）」として扱うことができる。そうした証明のためのメカニズムは、ハッシュツリー証明(またはメルク証明)として知られており、そして、所与のデータブロックDiとルートRに対するハッシュまたは認証パス(または、マークルパス)として知られているハッシュのセットを獲得することを含む。データブロックに対する認証パスは、繰り返されるハッシュと連結によってルートRを再構築するために必要とされるハッシュの最小リストである。
図6は、マークルパスを使用して、ルートRで表されるツリーにおける、データブロックD1のマークル存在証明を示している。マークルルートRが与えられると、データブロックD1がマークルプルーフを実行することにより、Rによって表されるセットＤ∈{D1,…,DN}に属していることが、以下のように証明される。 1)信頼されるソースからマークルルートRを取得する。
2)ソースからマークルパスΓを取得する。この場合、Γはハッシュのセットである。
Γ={N(2,2),N(3,4),N(5,8)}
3)以下のように、D1およびΓを使用してマークルプルーフを計算する。
a.データブロックをハッシュ(または、実装に応じて、ダブルハッシュ)して、以下を得る。
N(1,1)=H(D1)
b.N(2,2)と連結し、かつ、ハッシュして、以下を得る。
N(1,2)=H(N(1,1)||N(2,2))
c.N(3,4)と連結し、かつ、ハッシュして、以下を得る。
N(1,4)=H(N(1,2)||N(3,4))
d.N(5,8)と連結し、かつ、ハッシュして、ルートを得る。
N(1,8)=H(N(1,4)||N(5,8))
R'=N(1,8)
e.計算したルートR'と(1)で求めたルートRを比較する。
I.R'=Rである場合、ツリーにおけるD1の存在、および、従って、データセットＤが確認される。
II.R'≠である場合、プルーフは失敗し、かつ、D1は、Ｄのメンバーであると確認されない。
このことは、所与のブロックD1およびルートRについてマークルプルーフを実行することが、必要なハッシュ値の最小数だけを使用することによって、マークルツリーを「上向き（“upward”）」に効果的に渡ることを示している。これは、マークルツリーおよびそのルートによって表されるデータセットの一部として、いくつかのデータについて存在証明を提供するための効率的なメカニズムである。
ハッシュツリープルーフは、候補データフィールドのハッシュを、ハッシュの順序付けされたセット(ハッシュツリーパス)内の少なくとも１つのリーフハッシュと連結することを含む。このことは、内部ハッシュ(または、ハッシュツリーの内部ノード)を生成する。生成された内部ハッシュは、次いで、ハッシュツリーパス内の１つ以上のハッシュと連結される(ハッシュツリーがバイナリハッシュツリーである場合は単一のハッシュ)。連結された内部ハッシュは、次いで、次のハッシュを生成するためにハッシュされる。ハッシュツリーのサイズ(例えば、データフィールドの数)に応じて、次のハッシュは、別の内部ハッシュまたはルートハッシュであり得る。次のハッシュが別の内部ハッシュである場合、ハッシュツリーパスからの１つ以上の内部ハッシュと連結し、かつ、結果をハッシュするプロセスが、ルートハッシュが生成されるまで続く。ハッシュツリーパスにおける各ハッシュは、１回だけ使用されることに注意すること。
重要なことは、所与のデータパケットがマークルツリーに属することを検証するために必要な操作の数は、リーフノードの数と対数的にスケーリングされる（scaled）ことである。
ラビン署名（RABIN Signature）
現在のブロックチェーンプロトコルにおいて、有効な楕円曲線デジタル署名アルゴリズム(ECDSA)署名は、署名されているメッセージが(シリアライズされた)トランザクションである場合にだけ生成することができる。これは、当事者がトランザクションにおいてエンコーディングされた契約を実行するために署名データを要求する場合、その当事者はトランザクション全体にも署名する必要があることを意味する。その結果、現在のプロトコルは、データ署名の再使用を防止する。
しかしながら、ラビン暗号システムは、ブロックチェーントランザクションで使用される任意のデータタイプの署名を生成し、そして、検証するために使用することができる。ラビン署名それ自体は、当該技術分野の者にはよく知られている。楕円曲線演算を使用するECDSA署名方式とは異なり、ラビン署名はセキュリティのために素因数分解（integer factorisation）の困難性に依存している。ラビン署名アルゴリズムは、以下のようにまとめられる。
鍵の生成:署名者の秘密鍵は、(p,q)である。ここで、p≡3 mod 4、かつ、q≡3 mod 4であり、それらはプライム（prime）である。秘密鍵は、n=p・qである。
署名の生成:メッセージmは、
Figure 2022541323000003
 かつ、
Figure 2022541323000004
 であるように、ランダムにUを選択し、ラビン署名は以下のように与えられる。
Figure 2022541323000005
 ここで、Hは、nとして出力のビット数と同じ数のハッシュ関数である。
署名の検証: (S,U,n)が提供され、そして、メッセージmは以下をチェックする。
Figure 2022541323000006
ラビン署名の検証は計算上容易であり、そして、スタック演算を使用してスクリプトで行うことができる。重要なことは、より大きなトランザクションの一部として使用される場合、検証プロシージャは、署名されているメッセージのコンテンツのあらゆる知識を必要としないことである(任意のサイズのデータ配列であること以外)。これは、ロッキングスクリプトの作成者は、データソースのパブリックアドレスを知る必要があるだけであることを意味する。ラビンデジタル署名アルゴリズムの別の特徴は、署名者は、署名鍵のビットサイズについて完全な制御を有することによりセキュリティのレベルを選択できることである。
少数の演算およびスタック操作オペコードが、ラビン署名を検証するために必要である。以下に示すオペコードは、当業者にとっては周知である。ラビン署名を検証するための「償還スクリプト（“Redeem script”）」は、以下のとおりである。
Figure 2022541323000007
この場合、スクリプトは失敗せずに実行され、入力と共に提供された場合にだけ、署名されたメッセージをスタックに残す。
<S><U><m><n>
ここで、mはメッセージであり、そして、(S,U)は有効なラビン署名である。代替的に、以下のスクリプトを使用する場合、償還スクリプトは、先頭スタック項目として真（TRUE）(または、真の表現)を残すように設計され得る。
Figure 2022541323000008
このバージョンのラビン署名チェックは、成功したラビン署名検証がOP_IFブランチを実行するために使用される場合に(ブロックチェーン・エスクロー（escrow）契約の場合のように)、使用され得る。簡潔さのために、上記のラビン署名検証オペコードの例は、以降では、[RABIN SIG CHECK]として参照される。
デジタル(スマート)契約
本開示の実施形態は、デジタル契約、または、いわゆるスマート契約を構築および実行するため、並びに、これらの契約の構築および実行を容易にするための技術を提供する。
デジタル契約は、契約の条件が満たされた場合にだけ、第１当事者103aがデジタル資産を第２当事者103bに移転することを可能にする。同様に、デジタル契約は、第２当事者103bが、条件が満たされた場合に、契約を執行（enforce）できることを保証する。これは、いずれかの当事者が、契約を破り、または、契約の条件が満たされたか否かについて同意しないことができる、伝統的な契約とは対照的である。
実施形態は、最初に、図7を参照して説明される。図7は、第１当事者(アリス)103a、第２当事者(ボブ)103b、および、信頼される第三者(オラクル（Oracle）)701を含むシステム700を示している。アリスとボブは、ブロックチェーンネットワークの各ユーザであり、そして、ここにおいて説明される方法を実行するように構成されたコンピュータ機器102a、102bを操作する。オラクル701は、ブロックチェーンネットワークのユーザであっても、なくてもよい。また、オラクル701は、ここにおいて説明される方法を実行するように構成されたコンピュータ機器(図示せず)を操作する。第三者(オラクル)は、アリス103aおよびボブ103bが第三者によって生成及び／又は公開されたデータを信頼するという意味で信頼されている。例えば、第三者701は、特定の都市の日ごとの平均温度測定値などの、温度測定値を公表する気象サービスであり得る。
オラクルは、１つ以上の物理的なサーバユニット、または、データセンタ全体から構成されるサーバの形態をとり得る。代替的に、オラクルは、ユーザ端末または互いにネットワーク化されたユーザ端末のグループの形態をとり得る。つまり、オラクルは、個人ユーザ、または、組織、例えば、会社、学術機関、慈善団体、等といった、ユーザのグループであってよい。一般的に、オラクルは、コンピュータ機器を含んでいる。コンピュータ機器は、１つ以上のプロセッサ、例えば、１つ以上の中央処理装置（CPU）、加速器プロセッサ、特定用途向けプロセッサ、及び／又は、フィールドプログラマブルゲートアレイ（FPGA）を含む、処理装置を含んでいる。コンピュータ機器は、また、メモリ、すなわち、非一時的なコンピュータ読取り可能な媒体またはメディアの形態のコンピュータ読取り可能な記憶装置を備える。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、固体ドライブ、フラッシュメモリまたはEEPROMなどの電子媒体、及び／又は、光ディスクドライブなどの光媒体を使用する１つ以上のメモリユニットを含んでよい。オラクルのメモリは、それぞれの役割を実行するために、ノードコンピュータ機器の処理装置上で実行するように構成されたソフトウェアを保管する。ここにおいてオラクルに帰属されたいずれの動作も、オラクルのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されるだろう。
オラクルは、例えばインターネット101を介して、アリスとボブと通信することができる。アリスとボブは、それぞれ、ブロックチェーンネットワーク106のノードに対してトランザクションを送信するように構成される。アリスとボブは、また、サイドチャネル301(図7には示されていない)を介しても通信し得る。
アリスとボブは、契約の複数の可能な条件Vのいずれかが満たされた場合に、アリスがデジタル資産の総計を移転することを確保する、デジタル契約を構築したい。例えば、可能な条件は、商品（commodity）の価格、または、保険付きイベントの結果であり得る。アリスは、デジタル資産がボブによって請求される前に、契約の条件が満たされていることを確保したい。アリスとボブは、また、信頼される当事者が条件が満たされているか否かの仲裁人であることも確保したい。
アリスとボブ両方のプライバシーレベルを維持するために、アリスは、トランザクションに契約の条件を含めたくない場合がある。トランザクションは、検証されると、ブロックチェーン150の一部を形成し、そして、ブロックチェーンのユーザによってアクセス可能できるからである。従って、アリスは、ブロックチェーン150のいかなる不必要な第三者ユーザによっても決定され得ないような方法で、トランザクション内で契約の条件をエンコーディングしたい。
追加的、または代替的に、契約は、より多くの条件を含み得る。スクリプトを使用するスマート契約の実行を妨げる主なハードルの１つは、個々のスクリプトに適用される厳格なサイズ制限である。ペイツースクリプトハッシュ(pay to script hash、P2SH)について520バイト制限が存在しており、かつ、あり、裸の（bare）スクリプトについては10,000バイト制限である。これらの制限は、マイナ104Mに対するサービス拒否(DoS)タイプの攻撃の可能性を排除することによってセキュリティリスクを低減するが、スマート契約を表すために使用できる生の（raw）スクリプトの量について非常に厳しい制限を課している。従って、アリスは、スクリプトのサイズを小さくする効率的な方法で、契約の条件をエンコーディングしたい。
一旦、条件が合意されると、アリス及び／又はボブは、条件のセットV(または、条件を表すデータ)をオラクルに送信する。オラクルは、マークルツリー500を生成するために、契約の異なる条件を使用する。すなわち、各条件は、ツリーのリーフハッシュ501を生成するために、ハッシュ関数を使用してハッシュ(またはダブルハッシュ)される。ハッシュツリーのルート503(マークルルートR)は、契約の条件をエンコーディングするハッシュ値である。マークルルートRは、条件を獲得するために、リバースエンジニアリングすることができない。
アリスとボブが、データ要素のみを使用して、彼ら自身でマークルルートRを構築できないことを確保するために、オラクルは、ハッシュツリー500の１つ以上のリーフとしてハッシュキーKを含んでいる。
各ハッシュキーKは、オラクルのみが知っている秘密S(例えば、ランダムに生成された数字または文字列)から派生したハッシュ値である。各ハッシュキーKは、同じハッシュキーであってよい。代替的に、各ハッシュキーKは、異なるハッシュキーであってよい。例えば、第１ハッシュキーK1は秘密鍵Sのハッシュであってよく、そして、第２ハッシュキーK2は第１ハッシュキーK1のハッシュであってよい。代替的に、第１ハッシュ鍵K1は秘密および第１値(例えば、S+i)のハッシュであってよく、そして、第２ハッシュ鍵K2は秘密および第２値、異なる値(例えばS+2i)のハッシュであってよい、等である。秘密はオラクルだけに知られているので、オラクルだけがマークルルートRを再構成できる。
オラクルは、デジタル契約に含めるために、マークルルートRをアリスに送信する。代替的に、オラクルは、マークルルートRを、アリスがアクセスできるように、例えば、インターネット101上で公開することができる。アリスは、今や、マークルルートを利用するトランザクションTx1を構築することができる。アリスは、デジタル資産の総計をアリスに対してロックするロッキングスクリプトを含むトランザクションTx1を構築する。ロッキングスクリプトは、マークルルートを含んでいる。ロッキングスクリプトは、以下でより詳しく説明される。一旦、トランザクションが構築されると、アリスは、ブロックチェーンに含めるために、すなわち、マイニングノードによって、トランザクションTx1をネットワークに送信する。
後に、契約の条件V1が満たされ、そして、ボブは、合意されたデジタル資産の総計を受け取りたい。例えば、条件V1は、ボブが支払いを受け取ることを可能にする保険可能な結果をエンコーディングしているデータパケットであってよい。そうするために、ボブは、アリスのトランザクションTx1のロッキングスクリプトをアンロックするアンロッキングスクリプトを有しているトランザクションTx2を生成する必要がある。上述のように、アリスとボブは、条件が満たされているか否かを決定するためにオラクルが信頼されていることに同意した。条件V1が満たされたと決定すると、オラクルは、認証パス(マークルパス)Γをボブに送信する。マークルパスΓは、マークルツリーの生成の最中にオラクルによって生成されたハッシュキーK、および、マークルルートを再構成するために必要とされるマークルツリーの１つ以上のハッシュを含む。オラクルから獲得されたマークルパスΓは、また、V1(または、V1を表すデータ要素)も含んでよい。代替的に、ボブは、既にV1へのアクセス権を持っている。今や、ボブは、V1、ハッシュキーK、および１つ以上のハッシュ値を含む、Tx2のアンロッキングスクリプトを構築する。一緒に、これらの値は、マークルプルーフを実行するため、すなわち、マークルルート候補を生成し、かつ、オラクルによって生成された(かつ、Tx1に含まれている)マークルルートと比較するために、使用することができる。ボブは、ブロックチェーンに含めるために、トランザクションTx2をネットワークに送信する。
これから、アリスによって構築されたロッキングスクリプトに戻る。図4に示されるように、Tx2の検証の最中に、Tx1のロッキングスクリプトは、Tx2と共に実行される。アリスによって生成されたロッキングスクリプトは、Tx1のロッキングスクリプトに含まれるマークルルートおよびTx2のアンロッキングスクリプトに含まれる要素を使用して、マークルプルーフを実行するように構成されている。Tx2のアンロッキングスクリプトの要素を使用して生成された候補マークルルートが、Tx1のアンロッキングスクリプトに含まれるマークルルートと一致する(すなわち、同一である)場合、デジタル資産は、アリスからアンロックされ、そして、ボブの選択する当事者に移転される。言い換えれば、デジタル資産のアンロックされた総計(例えば、総計の一部または全部)は、Tx2の未支払トランザクション出力に含めることができる。
図7は、これらの実施形態に従った、アリス103a、ボブ103b、およびオラクル701間の情報の流れの一つの例を示している。示されるように、オラクルは、アリスから契約の条件Vを獲得する。オラクルは、マークルルートRを有しているマークルツリーを構築するために、これらの条件および秘密を使用する。オラクルは、マークルルートRをアリスに送信し、その結果、アリスは、そのトランザクションTx1のロッキングスクリプト内にルートRを組み込んだトランザクションTx1を構築することができる。アリスは、トランザクションをP2Pネットワークにブロードキャストする。トランザクションTx1は、有効であれば、ブロックチェーンにマイニングされる。契約の条件V1が満たされたとオラクルがみなす場合、オラクルは、ボブにマークルパスΓおよびハッシュキーK(秘密を使用して生成される)を提供する。マークルパスΓおよびハッシュキーKが一緒に使用され、マークルルートRを生成することができる。ボブは、次に、トランザクションTx2のアンロッキングスクリプト内に、マークルパスΓ、条件V1、およびハッシュキーKを組み込んだトランザクションTx2を構築する。有効であれば、トランザクションTx2は、ブロックチェーン150にマイニングされる。
これから、図9を参照して実施形態が説明される。オラクルは、マークルツリーを使用して、大量のインデックス付きデータを認証および圧縮の両方を行うプロトコルを動作させる。そうすることにより、オラクルは、外部データを実行する必要のある複数のトランザクションの作成を可能にする。オラクルは、スマート契約またはブロックチェーントランザクションのいずれに対しても当事者ではない。アリスとボブは、ブロックチェーントランザクションのスマート契約における当事者であり、ここで、アリスは支払人であり、かつ、ボブはデジタル資産の意図された受取人である。デジタル資産を支払うために、ボブは、彼が契約で要求されているいくつかの条件を満たしていることを証明する必要があり、そして、この証明の一部は外部データを含んでいる。従って、ボブは証明者（prover）と呼ばれ、かつ、アリスは検証者（verifier）と呼ばれる。
オラクルで開始することは、ビットの秘密文字列、または、全く共有されることのない秘密番号を作成する。例えば、秘密は、数字の10であってよい。SHA256といった、暗号ハッシュ関数を使用して、秘密をハッシュすることにより、鍵が安全に生成される。
H(secret)=Key
ハッシュダイジェスト(Keyで示されている)は、適切な場合、証明者に対して送信され得る。さらに、鍵ハッシュのシーケンスは、決定論的鍵生成プロトコルを使用して生成することができる。例えば、以下のようである。
H(secret+1)=Keyi i={0,1,…,N}
図9に示されるように、オラクルは、各右リーフノードKeyi901、および、データVkでインデックス付けされている、各左リーフノード902を用いて、マークルツリー900を構成することができる、k∈{1,…,N}。マークルツリー900の目的は、データが使用される前にデータ自体をブロックチェーン上に公開することなく、アリスが、証明者からのデータを要求しているという証拠を提供することである。オラクルから要求された場合には、マークルルートRを公開し、これは、データの真正性を検証するために、将来のブロックチェーントランザクションにおいて使用され得る。
一旦、いったんKeyiが獲得されると、ハッシュ値がマークルツリー900の一部であることを証明することができる。証明者は、マークルパスを提供することができ、これは、オラクルによって既に公開されている(例えば、アリスに送信された)マークルルートに対して検証することができる。この場合、マークルプルーフは、データおよびデータの真正性の検証を可能にする。
上記の利点は、マークルツリーを使用してデータが認証され得ること、鍵およびマークルツリーの生成が容易であり、かつ、計算効率が良いこと、および、単一の鍵を用いて大量の独立したデータが予め署名され得ること、である。さらに、マークルツリー深さ(従って、マークルプルーフ)は、可能な値の数と対数的にスケーリングされ、大量のインデックス付きデータが署名され得ることを意味している。
一旦、有効なマークルプルーフが証明者によって提供されると、マークルツリーリーフに関連する鍵ハッシュが明らかにされるので、鍵ハッシュが廃棄される必要があり、そして、各新たなトランザクションについて新しいマークルツリーが構築されることを要する。しかしながら、左リーフノードのデータが同じままであるので、これは、最小限の計算を必要とする。
例えば、オラクルは４つの条件V1,…,V4を有しており、それらは公知であるか、また、アリスから送信されたものであるとする。始めに、オラクルは、検証者が検証(つまり、ロッキング)スクリプトを作成できるように、マークルルートを公開する。一旦、検証者がマークルルートを用いてロッキングスクリプトを構築すると、すなわち、スマート契約をエンコーディングするトランザクションが作成されると、オラクルは、アリスが正しいマークルルートを使用しているか否かをチェックできる。一旦、オラクルが結果を決定すると、鍵およびマークルプルーフが、証明者(ボブ)へ送信され得る。
例えば、データV1-V4は、ボブがアリスのアウトプットを支払うのを可能にするボクシングの試合の結果を表しているとする。V1についてマークルプルーフを検証する、以下のスクリプトスニペット（snippet）を考える。
てみよう。
ステップ１:アリスは、スマート契約に同意しており、それにより、結果V1が発生した場合に、アリスは、デジタル資産の総計をボブに移転する。アリスとボブは、このデータをオラクルに送信する。
ステップ2:オラクルは、このデータV1-V4および秘密鍵を、リーフとして使用して、マークルツリーを構築する(図9を参照のこと)。オラクルは、次に、アリスの検証アルゴリズムの一部として含めるように、アリスにRを送信する。
アリスのロッキングスクリプト(スニペット):
Figure 2022541323000009
オラクルは、アリスのトランザクションでこのスクリプトについて検索し、そして、正しいマークルルートが含まれていることを確保することができる。正しいマークルルートが含まれていない場合、オラクルは、アリスがまだ(正しい)契約スクリプトを作成していないことをボブ及び／又は一般の人々に知らせることができる。これは、最初に正しいトランザクションを作成するようアリスに依頼することより(アリスはスクリプトを使ってトランザクションを作成して、署名しなければならない)、セキュリティ上の脆弱性ではない。この方法は、契約が作成されたことを、単にオラクルが検証できるようにする。
ステップ3:V1は有効な結果である。オラクルは、鍵Key1およびマークルパスをボブに送信する。ボブは、V1のマークルを作ることができる。
ボブのアンロッキングスクリプト(スニペット):
<Z2><Z4><Key1><V1>
このプルーフを実行すると、証明者は、キーハッシュデータとリーフデータの両方を知っていること、および、データ自体も、また、アンロッキングスクリプトに含まれていることを知る。
明示的に、アリスのロッキングスクリプトはV1をハッシュし、そして、Key1と連結する（つまり、Z3を生成する)。結果は、Z4と連結され、次いで、ハッシュされる、(つまり、Z1を生成する)。結果は、Z2と連結され、ハッシュされます(すなわち、Rを生成する)。次いで、結果がRと等しいかについてチェックされる。
データおよびマークルパスは、一緒に存在証明であり、データが契約に含まれていたことを示している。鍵ハッシュは、オラクルが、ボブにデータの使用を許可したことを示している。キーハッシュを含めることも、また、データの真正性を提供する。オラクルは、結果が有効である場合に、キーハッシュをボブに単に与え得るからである。
図8は、アリス103a、ボブ103b、および信頼される第三者(オラクル)701を含む、図7と同様のシステム800を示す。
上記で詳述したように、アリスとボブは、契約の複数の可能な条件Vのいずれかが満たされた場合に、アリスがデジタル資産の総計を移転することを確保するデジタル契約を構築したい。アリスとボブは、また、信頼される当事者が条件が満たされているか否かの仲裁人であることを確保したい。
これらの実施形態において、アリスとボブは、契約の条件について合意することができ、そして、彼らの間で、それらの条件をエンコーディングするマークルツリーについて合意することができる。つまり、マークルツリーは、オラクルと関わることなく構築することができる。例えば、アリスは、マークルルートを有しているマークルツリーを生成することができる。ボブも、また、マークルルートを有しているマークルツリーを生成することができる。ボブは、次いで、アリスがマークルルートを正しく生成したことを検証できる。これを実現するためには、アリスとボブは、マークルツリーを生成するために使用される方法(すなわち、アルゴリズム)について合意しなければならない。代替的に、アリスとボブは、マークルツリーを生成し、マークルルートをアリスへ、そして、任意的にボブへ送信するように、オラクルに依存し得る。
これらの実施形態で使用されるマークルツリーは、秘密値を使用することなく構築することができる。マークルツリーのリーフは、契約の条件のハッシュ(すなわち、それらの条件を表すデータ要素のハッシュ)であってよい。条件の数に応じて、１つ以上のパディング要素がマークルツリーのノード(例えば、リーフ)として使用され得る。例えば、契約の条件が7個ある場合、8個のハッシュリーフを有しているマークルツリーを形成するために、ハッシュリーフの１つがパディングされ得る(例えば、ゼロのハッシュ)。これは、ここにおいて説明される実施形態のいずれに対しても適用され得る。
一旦、アリスがマークルルートRを取得すると(例えば、マークルルートを生成することによる)、アリスは、デジタル契約の条件が満たされるという要件に基づいて、デジタル資産の総計をボブに移転するという、トランザクションTx3を生成することができる。アリスは、信頼される当事者である、オラクルが、条件が満たされたのを証明することを確保したい。そこで、アリスは、トランザクション出力をアンロックするように試みるアンロッキングスクリプトがオラクルの署名Rsを使用して署名されたデータ要素を含むか否か、を決定するロッキングスクリプトを有するトランザクションTx3を生成する。図7を参照して説明したトランザクションと同様に、アリスのトランザクションのロッキングスクリプトは、また、アンロッキングスクリプトが、データ要素を使用してマークルプルーフを実行するためのマークルパスΓを含むか否かも決定する。つまり、ロッキングスクリプトは、(署名された)データ要素とマークルパスΓが、アリスのトランザクションTx3のロッキングスクリプトに含まれるマークルルートRと同一のマークルルート候補を生成することができるか否かを決定するように構成されている。
オラクルの署名Rsは、ラビン署名であってよい。ラビン署名、および、データ要素に署名するためにそれを使用する方法については、上記で詳細に説明してきた。アリスのロッキングスクリプトは、ラビン署名チェックを実行するように設定することができる。例えば、ボブのアンロッキングスクリプトに含まれるデータにおける[RABIN SIG CHECK]。
代替的に、オラクルの署名はECDSA署名であってよい。
いくつかの例において、アリスは、また、トランザクションにおいて追加情報、例えば、デジタル契約に関連するメタデータ、を含んでもよい。例えば、メタデータは、契約の説明を含むことができる。例えば、メタデータが、トランザクションのOP_RETURN出力に含まれてよい。
いくつかの例において、アリスは、ボブが既定の時間内にデジタル資産の所有権を成功裡に移転しない場合、デジタル資産の総計を償還するための時間ベースの償還オプションを含むことができる。例えば、ロッキングスクリプトは、トランザクションが生成またはブロックチェーンにマイニングされてから１ヶ月、２ヶ月３3ヶ月などの期間が経過した後に、アリスが(アリスによって生成された異なるトランザクションのアンロッキングスクリプトを使用して)ロッキングスクリプトのアンロックを可能にするように構成され得る。例えば、契約の条件が満たされなかった、または、オラクルが有効な署名をボブに提供しなかったので、ボブがデジタル資産を請求しなかった場合、アリスは、ブロックチェーンネットワークに、彼女の以前のトランザクションのロッキングスクリプトをアンロックするように構成されたアンロッキングスクリプトを有する、トランザクションを送信し得る。アンロッキングスクリプトは、アリスの署名および公開鍵(または、そのハッシュ)を含んでよい。
一旦、トランザクションが生成されると、アリスは、ブロックチェーンに含めるために、トランザクションをブロックチェーンネットワークの１つ以上のノードに送信する。
契約の条件が満たされる場合、オラクルは、署名されたデータ要素をボブに送信する。データ要素は、満たされた条件を表しており、かつ、マークルルートRを構築するために使用されたのと同じデータ要素である。データ要素は、オラクルの署名Rs、例えばオラクルのラビン署名、を用いて署名される。オラクルは、また、例えば、(ラビン)公開鍵を公開すること、または、(ラビン)公開鍵をボブに直接送信することにより、オラクルの(ラビン)公開鍵をボブに提供することもできる。
ボブは、今や、アリスのトランザクションTx3の出力をアンロックする、すなわち、アリスのトランザクションにおけるロッキングスクリプトをアンロックするように構成された、アンロッキングスクリプトを有するトランザクションTx4を生成することができる。ボブのトランザクションTx4のアンロッキングスクリプトは、署名されたデータ要素、オラクルの公開鍵、および、マークルプルーフを実行するためのマークルパスΓを含んでいる。ボブは、(例えば、アリス及び／又はオラクルがマークルツリーを生成した例において)アリス及び／又はオラクルからマークルパスを取得することができる。別の例として、ボブは、マークルパスを生成することによって(例えば、アリスとボブがマークルツリーのリーフを形成するデータ要素について合意した例において)、マークルパスΓを獲得することができる。一旦生成されると、ボブは、ブロックチェーン150に含めるために、ネットワークの１つ以上のノードにトランザクションを送信することができる。
図8は、これらの実施形態に従った、アリス、ボブ、およびオラクル間の情報の流れの一つの例を示している。アリスとボブは、マークルツリーについて合意することができる。このことは、彼らの間でマークルルートRを共有することを含み得る(例えば、アリスはマークルルートRをボブに送信し得る。かつ／あるいは、その逆も同様である)。いくつかの例において、オラクルは、マークルツリー(または、それらの条件を表すデータ要素)を生成するために使用された契約の条件Vを生成してきた。これらの例において、オラクルは、これらの条件Vを公開し、または、条件Vをアリス及び／又はボブに直接送信することができる。つまり、他の第三者に対して公開することはない。アリスは、P2PネットワークにトランザクションTx3をブロードキャストする。トランザクションTx3は、有効であれば、ブロックチェーンにマイニングされる。オラクルが、契約の条件V1が満たされたとみなす場合、オラクルは、満たされた条件V1に署名する署名Rをボブに提供する。ボブは、次いで、マークルルートRを生成するために使用され得る条件のためのマークルパスΓを獲得する。マークルパスΓは、アリスまたはオラクルによって送信され、または、ボブ自身によって生成され得る。ボブは、次いで、そのトランザクションTx4のアンロッキングスクリプト内にマークルパスΓおよび署名された条件V1を組み込んだ、トランザクションTx4を構築する。有効であれば、トランザクションTx4は、ブロックチェーンにマイニングされる。
条件依存の支払スクリプト(スマート契約)は、以下の態様を使用することができる。一番に、マークルツリーを構築するためにスマート契約スクリプトの相互に排他的なセクションが使用されてよく、そして、支払人によってマークルルートだけが使用される。このことは、契約および未使用のスクリプトデータの全体的なサイズを低減する。完全なスクリプトは、マークルルートで置き換えることができる。二番に、ラビン署名またはマークルプルーフを用いて認証された、第三者からの生データが、支払スクリプトで直接的に使用され、データプロバイダによって要求される作業量を低減している。三番に、第三者のデータプロバイダは、公開されたインデックスシステムを使用することによって、複雑なメッセージをエンコーディングすることができる。当事者は、次いで、トランザクションに明示的に記録された契約全体を必要とすることなく、スマート契約の条件が遵守されることを確保することができる。その代わりに、デジタル資産の支払人または勝者は、彼／彼女が何らかの条件を満たしていること、および、満たされている特定の条件が契約の一部であることを証明する必要がある。
場合によっては、オラクルが署名とともに平文メッセージを送信することは不可能であり、または、実際的でないことがある。このことは、オラクルが大量のメモリと処理能力を有するように要求し得るからである。代わりに、オラクルの可能な状態の数(および、従ってワークロード)は、連続データの特定の範囲を表すためにバイナリ／16進値を使用することによって、最小化され得る。いくつかの例において、オラクルは、クエリの特定のセットに関連するデータ(例えば、気温)報告するためだけに使用され得る。オラクル条件は、事前に公開をされたインデックスを用いて、インデックス化され得る。一つの例示的なスキームが、以下の表に示されている。
Figure 2022541323000010
このスキームを使用して、A≦x<B、A=a0かつB=a255の範囲内で、最大256個のオラクル条件が、1バイトを使用して表現できる。この精度は、バイト数が増加するにつれて増加され得る。例えば、スクリプトで許容される最大バイトプッシュ数が520である場合、理論的には、前の表を拡張して、連続データの最大で概ね3.4×10153間隔までを表すことができる。
一つの例として、オラクルが白金抵抗温度計からのデータをレポートしている場合、オラクルは、適切な範囲で温度を表すために、バイナリ値の設定された範囲を使用し得る。次の表に示されるように、例えば、単位間隔で-50℃から50℃の間である。
Figure 2022541323000011
この単純なエンコーディングシステムは、ほとんど無限の範囲のオラクル条件をスクリプトで直接的に表現することができる。
図10を参照して、これから、実施形態が説明される。これらの実施形態において、第三者(オラクル)はデータを認証することができるが、データを含む全ての新たなトランザクションについて計算を実行する必要はない。
ボクシングの試合の結果に基づいて、アリスとボブとの間の契約を考えてみる。例えば、ボクサーAが3、5、7、または11、もしくは12ラウンドでボクサーBを倒した場合に、アリスは、デジタル資産をボブに移転することに同意するまのとする。そうするために、彼女は、P2SHトランザクションの形式で、スマート契約を設定する。さらに、条件の妥当性が独立して検証されることを確実にするために、アリスとボブは、オラクルによって提供されたデータ(ボクシングの試合結果に関連するもの)を使用することに同意する。アリスとボブは、前もってスマート契約の形式について合意しなければならないので、彼らは、また、「マークル化契約（“Merklized contract”）」の構造、および、具体的にマークルルートについても合意することができる。オラクルのラビン公開鍵は、スマート契約を含むトランザクションが作成された時点で、アリスとボブの両方に知られていなければならない。代替的に、キャロル（Carol）は、関連するデータおよび署名の代わりに、まずは、インデックスの公開を望み得る。
一定の時間内に出力がボブに移転されない場合、デジタル資産がアリスに戻される条件を課すことによって、追加的なセキュリティを提供することができる。これは、キャロルが協力しない(すなわち、署名を提供しない)と決定する場合に、追加的なセキュリティを提供する。
上述のインデックス付けシステムを使用して、オラクルメッセージに対する結果に関連する以下の表を公開することができる。
Figure 2022541323000012
異なる条件(この場合、ボクシング試合における特定のラウンド)は、16進数データとしてエンコーディングされている。次に、図10に示されるように、16進値1001をリーフとして使用して、マークルツリー1000を構成することができる。
Z6=H(01), Z7=H(02), Z9=H(04), Z10=H(05),
Z3=H(Z7||Z8), Z4=H(Z7||Z10), Z5=H(Z11||Z11),
Z1=H(Z3||Z4), Z2=H(Z5||0),かつ
R=H(Z1||Z2).
ここで、H(・)は、ダブルSHA-256ハッシュ関数を示す。つまり、H(x)=SHA256(SHA256(x))である。代替的に、単一のハッシュが使用されてよい。この例において、パディング値1002が、ツリーのノードとして使用される。アリスは、デジタル資産の総計を勝者に移転するためのトランザクションを作成する(トランザクションが成立した時点で勝者は知られていないかもしれない)。これは、非標準トランザクション出力か、または、契約作成者がさらに圧縮を望む場合は、ペイツースクリプトハッシュ（P2SH）出力のいずれかになる。
例えば、ボクサーAが第3ラウンドでボクサーBを打ち負かし、そして、ボブは彼の勝利を支払いたい、つまり、デジタル資産を別のアドレスに移転したいとする。彼は、成功裡の結果が合意された契約の一部であったという証拠と同様に、キャロルからの有効な署名を提供する必要がある。
マークル化スマート契約により、当事者は、効率的かつ安全な方法で契約を保管し、そして、実行することができる。完全な契約をスクリプトにおいて明示的に表現する代わりに、アリスとボブは、のマークル化形式の契約に合意した。ボブは、今や、オラクルから署名を取得しており、そして、以下のことをデモンストレーションしたい。

i)ボブがUTXOを支払うことを可能にする条件が満たされていること、および、
ii)満たされた条件は、契約における特定の条項を満足すること。

メルク化スマート契約の一つの例が以下に示されている。ここで、ロッキングスクリプトは、アリスのトランザクションから、そして、アンロッキングスクリプトはボブのトランザクションからのものである。
Figure 2022541323000013
ロッキングスクリプトの第１部分(<Merkle path length>...OP_CHECKSIG OP_ENDIF)は、アンロッキングスクリプトがマークルルートを生成するためのマークルパスを含むか否か、オラクルのラビン署名を用いて署名された契約の条件、および、契約はデジタル資産の所有権をボブに移転するものであるか否か、をチェックする。
ボブは、(i)「第3ラウンド」が、彼が預託された（escrowed）資産を支払うために必要な条件であること、および(ii)「第3ラウンド」が実際にその結果であったこと、をデモンストレーションすることによって、デジタル資産を支払うことができる。ボブが(i)と(ii)を示した場合、スクリプトの第２部分(OP_ELSE...OP_ENDIF)は使用されないデータになる。スクリプトの第２部分により、ボブが1ヶ月以内に所有権を移転しない場合、アリスは、デジタル資産を取り戻す（reclaim）ことができる。
ボブのアンロッキングスクリプトは、マークルパス、オラクルの公開鍵で署名された条件、ボブの公開鍵、および、ボブの署名を含んでいる。
ロッキングスクリプトのサイズが低減され、そして、使用されないスクリプトと実行されないスクリプトが最小化される。ロッキングスクリプトのサイズのさらなる圧縮は、P2SHを使用して達成することができ、契約の実行コストを契約作成者から支払人へシフトさせている。例えば、以下のトランザクション・テンプレートを使用することによるものである。

トランザクション１(アリス) P2SH:
Figure 2022541323000014
 トランザクション２(勝者) P2PKH:
Figure 2022541323000015
マークル化スマート契約について、ロッキングスクリプトは、リーフノードの数、N、と対数的にスケール化される。オペコードシーケンス(OP_SWAP OP_IF OP_SWAP OP_ENDIF OP_CAT OP_SHA256)は、マークルツリーの各レベルに対して繰り返される必要があるからである。小規模契約については、[RABIN SIG CHECK]シーケンスが、スクリプト内のバイトの最大の割合を作り上げる。契約をメルク化することによってラビン署名チェックシーケンスの繰り返しを避けることは、トランザクションのサイズを大幅に減少させる。
償還スクリプトを検証するには、マークルパスを指定するためにレスポンスが必要とされる。これは、レスポンスのサイズがリーフノードの数と対数的にスケール化されることを意味している。レスポンスに含まれるデータの大部分は、ラビン署名と公開鍵である(最もセキュアな署名について、それぞれ概ね300－400バイトである)。
以下の表は、マークル化契約を使用する場合のトランザクションサイズの節約を示している。
Figure 2022541323000016
図11は、アリスによって使用され得るトランザクション・テンプレート1100の例である。アリスの契約は、単一のトランザクション出力1101へとエンコーディングされ得る。契約に対する追加メタデータは、OP_RETURN出力1102に埋め込む（embedded）ことができる。
アリスのトランザクションのロッキングスクリプトは、3個の別個の要素1103、1104、1105を含み得る。第１要素1103は、アリスのトランザクションのアンロックを試みるアンロッキングスクリプト内のデータが、実際に契約の条件であることをチェックする。第２要素1104は、ボブがデジタル資産の意図された受取人であることをチェックする。第３要素1105により、既定の期間(この例にでは1ヶ月)内にボブによって請求されない場合、アリスは、デジタル資産を取り戻すことができる。
図12は、図11に示される例示的なトランザクションを使用して、アリスに対してロックされたデジタル資産をアンロックするためにボブによって使用され得るトランザクションの例である。ボブは、マークルパス、データ(満たされた条件を表すもの)、および、彼自身の(ECDSA)署名と公開鍵と一緒に、オラクルからのラビン署名、を提供する。
上記の実施形態は、単なる例示として説明されたものであることが理解されるだろう。
より一般的に、ここにおいて開示された教示に係る第１のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約をエンコーディングする、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。本方法は、信頼される第三者によって実行され、かつ、複数のデータ要素を獲得するステップであり、各データ要素は前記契約の異なる条件を表しており、かつ、前記異なる条件のうち少なくとも１つが前記第２当事者にリンクされているステップと、前記複数のデータ要素に基づいて、ハッシュツリーを生成するステップとを含む。前記ハッシュツリーは、ｉ）リーフ層であり、それぞれのデータ要素をハッシュすることによって、それぞれ生成されるリーフハッシュの第１セット、および、前記信頼される第三者にだけ知られている秘密値をハッシュすることによって生成される、少なくとも１つのハッシュキーを含む、リーフハッシュの第２セット、を含む、リーフ層と、ｉｉ）１つ以上の内部層であり、各内部層は、内部ハッシュのそれぞれのセットを含み、それぞれの内部層の各内部ハッシュは、下位層からの少なくとも２つのハッシュの連結をハッシュすることによって生成される、内部層と、ｉｉｉ）ルートハッシュを含む、ルート層であり、前記ルートハッシュは、最上位の内部層からの少なくとも２つのハッシュの連結をハッシュすることによって生成され、かつ、前記ブロックチェーンのトランザクション内に含めるために、前記ルートハッシュを前記第１当事者に対して利用可能にする、ルート層と、を含む。
方法。
第２の、任意的なインスタンス化に従って、上記第１のインスタンス化による方法が提供され得る。ここで、前記データ要素の獲得するステップは、前記第１当事者及び／又は第２当事者から、前記データ要素を受信ステップ、を含む。
第３の、任意的なインスタンス化に従って、上記第１および第２のインスタンス化による方法が提供され得る。ここで、前記ルートハッシュを利用可能にするステップは、前記ルートハッシュを前記第１当事者に送信するステップ、を含む。
第４の、任意的なインスタンス化に従って、上記第１乃至第３いずれかのインスタンス化による方法が提供され得る。前記方法は、前記第１当事者によって生成された前記ブロックチェーンのトランザクションを識別するステップであり、前記トランザクションは、前記デジタル契約を含み、かつ、前記デジタル契約は、前記第１当事者に対して前記デジタル資産の総計をロックしているロッキングスクリプトを含むステップと、前記ロッキングスクリプトが前記ルートハッシュを含むか否かを決定するステップと、前記ロッキングスクリプトが前記ルートハッシュを含まない場合には、第２当事者に通知するステップと、を含む。
第５の、任意的なインスタンス化に従って、上記第１乃至第４いずれかのインスタンス化による方法が提供され得る。前記方法は、前記第２当事者に関連する契約の条件が満たされていること決定するステップと、決定にレスポンスして、前記第２当事者に対して認証パスを送信するステップであり、前記認証パスはハッシュのセットを含み、前記ハッシュのセットは、ハッシュキー、および、内部ハッシュの１つ以上のセットを含み、内部ハッシュの各セットは、前記ハッシュツリーの異なる内部層に属しているステップと、を含む。
第６の、任意的なインスタンス化に従って、上記第１乃至第５いずれかのインスタンス化による方法が提供され得る。ここで、前記リーフハッシュの第２セットは、複数の異なるハッシュキーを含み、それぞれのハッシュキーは前記秘密値に基づいて生成される。
第７の、任意的なインスタンス化に従って、上記第６のインスタンス化による方法が提供され得る。ここで、前記リーフハッシュの第１セットそれぞれは、前記ハッシュキーのうち異なる１つとペアになっており、かつ、前記ハッシュツリーの最下層の内部ハッシュそれぞれは、リーフハッシュの異なるペアの連結をハッシュすることによって生成される。
第８の、任意的なインスタンス化に従って、上記第７かつ第５のインスタンス化による方法が提供され得る。ここで、前記認証パスは、第２ノードに関連する前記条件のリーフハッシュとペアにされた前記ハッシュキーを含む。
ここにおいて開示された教示に係る第９のインスタンス化に従って、前記信頼される第三者のコンピュータ機器が提供される。本コンピュータ機器は、１つ以上のメモリユニットを含むメモリと、１つ以上の処理ユニットを含む処理装置と、を含み、前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、前記コードは、前記処理装置において、第１乃至第８いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第１０のインスタンス化に従って、コンピュータプログラムが提供される。本コンピュータプログラムは、コンピュータで読取り可能なストレージ装置において具現化され、かつ、信頼される第三者のコンピュータ機器上で実行されると、第１乃至第８いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第１１のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を生成する、コンピュータで実装される方法が提供される。本デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、前記第１当事者によって実行され、かつ、信頼される第三者によって生成されたハッシュツリーのルートハッシュを獲得するステップであり、前記ハッシュツリーは、ｉ）複数のデータ要素であり、各データ要素は、前記契約の異なる条件を表しており、前記異なる条件のうち少なくとも１つは前記第２当事者に関連している、複数のデータ要素、および、ｉｉ）前記信頼される第三者だけに知られている秘密値に基づいて生成された１つ以上の異なるハッシュキー、に基づいて生成されているステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者に対して前記デジタル資産の総計をロックするためのロッキングスクリプトを含み、かつ、前記ロッキングスクリプトは、前記ルートハッシュを含むステップと、を含む。
第１２の、任意的なインスタンス化に従って、上記第１１のインスタンス化による方法が提供され得る。ここで、前記方法は、前記ブロックチェーンに含めるために、前記ブロックチェーンネットワークのうち１つ以上のノードに対して前記トランザクションを送信するステップ、を含む。
第１３の、任意的なインスタンス化に従って、上記第１２または第１３のインスタンス化による方法が提供され得る。ここで、前記ルートハッシュの獲得するするステップは、前記信頼される第三者から前記ルートハッシュを受信するステップ、を含む。
第１４の、任意的なインスタンス化に従って、上記第１２または第１３のインスタンス化による方法が提供され得る。ここで、前記第２当事者によって生成される前記ブロックチェーンの後のトランザクションは、ｉ）前記契約の条件を表すデータ要素と、ｉｉ）ハッシュキー、および、前記ハッシュツリーのうち１つ以上の内部ハッシュを含む認証パスと、を含む、アンロッキングスクリプトを備え、かつ、前記ロッキングスクリプトは、ロッキングスクリプト一緒に実行されると、前記データ要素および前記認証パスを使用して、ハッシュツリープルーフを実行することによって、候補ルートハッシュを生成し、かつ、前記ルートハッシュが候補のルートハッシュツリーと一致するか否かに応じて、真または偽のいずれかを表す値を生成する、ように構成されている。
ここにおいて開示された教示に係る第１５のインスタンス化に従って、前記第１当事者のコンピュータ機器が提供される。本コンピュータ機器は、１つ以上のメモリユニットを含むメモリと、１つ以上の処理ユニットを含む処理装置と、を含み、前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、前記コードは、前記処理装置において、第１１乃至第１４いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第１６のインスタンス化に従って、コンピュータプログラムが提供される。本コンピュータプログラムは、コンピュータで読取り可能なストレージ装置において具現化され、かつ、前記第１当事者のコンピュータ機器上で実行されると、第１１乃至第１４いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第１７のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実行する、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、前記第２当事者によって実行され、かつ、前記契約の条件を表すデータ要素を獲得するステップであり、前記条件は、前記第２当事者にリンクされているステップと、認証パスを獲得するステップであり、前記認証パスは、信頼される第三者によって生成されたハッシュツリーの候補ルートハッシュを生成するためのものであり、かつ、前記認証パスは、ハッシュのセットを含み、前記ハッシュのセットは、前記信頼される第三者にだけ知られている秘密値に基づいて生成されたハッシュキー、および、内部ハッシュの１つ以上のセットを含み、内部ハッシュのセットそれぞれは、前記ハッシュの異なる内部層に属している、ステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者からの前記デジタル資産の総計をアンロックするためのアンロッキングスクリプトを含み、かつ、前記アンロッキングスクリプトは、前記獲得されたデータ要素および前記獲得された認証パスを含む、ステップと、を含む。
第１８の、任意的なインスタンス化に従って、上記第１７のインスタンス化による方法が提供され得る。前記方法は、前記ブロックチェーンに含めるために、前記ブロックチェーンネットワークの１つ以上のノードに前記トランザクションを送信する。
ここにおいて開示された教示に係る第１９のインスタンス化に従って、前記第２当事者のコンピュータ機器が提供される。本コンピュータ機器は、１つ以上のメモリユニットを含むメモリと、１つ以上の処理ユニットを含む処理装置と、を含み、前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、前記コードは、前記処理装置において、第１７または第１８のインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第２０のインスタンス化に従って、コンピュータプログラムが提供される。本コンピュータプログラムは、コンピュータで読取り可能なストレージ装置において具現化され、かつ、前記第２当事者のコンピュータ機器上で実行されると、第１７または第１８のインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第２１のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約をエンコーディングする、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、信頼される第三者によって実行され、かつ、前記第２当事者にリンクされた前記契約の条件が満たされたと判断することにレスポンスして、前記ブロックチェーンのトランザクションに含めるために、前記第２当事者に前記信頼される第三者の署名を提供するステップであり、前記署名は、前記満たされた条件を表すデータ要素に署名するステップ、を含む。
第２２の、任意的なインスタンス化に従って、上記第２１のインスタンス化による方法が提供され得る。ここで、前記署名は、ラビン署名である。
第２３の、任意的なインスタンス化に従って、上記第２２のインスタンス化による方法が提供され得る。前記方法は、前記第２当事者にラビン公開鍵を提供するステップ、を含む。
第２４の、任意的なインスタンス化に従って、上記第２１乃至第２３いずれかのインスタンス化による方法が提供され得る。ここで、前記署名を提供するステップは、前記第２当事者に対して前記署名を直接的に送信するステップ、を含む。
第２５の、任意的なインスタンス化に従って、上記第２１乃至第２４いずれかのインスタンス化による方法が提供され得る。前記方法は、複数のデータ要素を前記第１当事者に提供するステップであり、各データ要素は、前記契約の異なる条件を表しており、かつ、前記複数のデータ要素は、前記第２当事者にリンクされた条件を表すデータ要素を含む、ステップ、を含む。
第２６の、任意的なインスタンス化に従って、上記第２５のインスタンス化による方法が提供され得る。前記方法は、ハッシュツリーのルートハッシュを生成するステップであり、前記ハッシュツリーは、リーフハッシュの層を含み、かつ、前記リーフハッシュのうち少なくともいくつかは、前記複数のデータ要素のそれぞれ１つに基づいて生成される、ステップと、前記第１当事者に前記ルートハッシュを提供するステップと、を含む。
第２７の、任意的なインスタンス化に従って、上記第２６のインスタンス化による方法が提供され得る。前記方法は、前記満たされた条件を表すデータ要素を使用して、前記ハッシュツリーの候補ルートハッシュを生成するために、前記第２当事者に認証パスを提供するステップ、を含む。
第２８の、任意的なインスタンス化に従って、上記第２１乃至第２６いずれかのインスタンス化による方法が提供され得る。ここで、各データ要素は、前記契約の異なる条件を表している、異なるバイナリまたは１６進数値である。
ここにおいて開示された教示に係る第２９のインスタンス化に従って、前記信頼される第三者のコンピュータ機器が提供される。本コンピュータ機器は、１つ以上のメモリユニットを含むメモリと、１つ以上の処理ユニットを含む処理装置と、を含み、前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、前記コードは、前記処理装置において、第２１乃至第２８いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第３０のインスタンス化に従って、コンピュータプログラムが提供される。本コンピュータプログラムは、コンピュータで読取り可能なストレージ装置において具現化され、かつ、第２１乃至第２８いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第３１のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を生成する、コンピュータで実装される方法が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、信頼される前記第１当事者によって実行され、かつ、ハッシュツリーのルートハッシュを獲得するステップであり、前記ハッシュツリーは、リーフハッシュの層を含み、前記リーフハッシュのうち少なくともいくつかは、それぞれが、複数のデータ要素のうちそれぞれ一つに基づいて生成され、各データ要素は、前記契約の異なる条件を表しており、かつ、前記異なる条件のうち少なくとも１つは、前記第２当事者にリンクされている、ステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者に対して前記デジタル資産の総計をロックするためのロッキングスクリプトを含み、かつ、前記ロッキングスクリプトは、前記ルートハッシュを含んでおり、前記ロッキングスクリプトは、後のトランザクションのアンロッキングスクリプトと共に実行されるときに、前記アンロッキングスクリプトが、ｉ）信頼される第三者の署名と共に署名された前記契約の条件を表すデータ要素、および、ｉｉ）前記署名されたデータエレメントを使用して、前記獲得されたルートハッシュに一致する候補ルートハッシュを生成するための認証パス、を含むか否か、を決定する、ように構成されている、ステップと、を含む。
第３２の、任意的なインスタンス化に従って、上記第３１のインスタンス化による方法が提供され得る。ここで、前記ルートハッシュを獲得するステップは、
前記ルートハッシュを生成するステップ、を含む。
第３３の、任意的なインスタンス化に従って、上記第３１のインスタンス化による方法が提供され得る。ここで、前記ルートハッシュを得る獲得するステップは、前記第２当事者及び／又は前記信頼される第三者から前記ルートハッシュを獲得するステップ、を含む。
第３４の、任意的なインスタンス化に従って、上記第３１乃至第３３いずれかのインスタンス化による方法が提供され得る。ここで、前記署名は、ラビン署名である。
第３５の、任意的なインスタンス化に従って、上記第３１乃至第３４いずれかのインスタンス化による方法が提供され得る。ここで、前記認証パスは、それぞれ前記ハッシュツリーの各層からのものである、ハッシュ値のシーケンスを含み、かつ、前記ロッキングスクリプトは、前記獲得されたルートハッシュと前記ハッシュ値のシーケンスを使用して、ハッシュツリープルーフを実行するためのオペコードのシーケンスを含む。
第３６の、任意的なインスタンス化に従って、上記第３１乃至第３５いずれかのインスタンス化による方法が提供され得る。ここで、前記ロッキングスクリプトは、既定の時間内に前記総計が前記第２当事者に移転されない場合に、前記第１当事者が前記デジタル資産の前記総計を償還できる、ように構成されている。
第３７の、任意的なインスタンス化に従って、上記第３１乃至第３６いずれかのインスタンス化による方法が提供され得る。ここで、前記ロッキングスクリプトは、ｉｉｉ）前記第２当事者の有効な署名および公開鍵、を含むか否かを、決定する、ように構成されている。
第３８の、任意的なインスタンス化に従って、上記第３１乃至第３７いずれかのインスタンス化による方法が提供され得る。ここで、前記トランザクションは、第１出力と第２出力とを含み、前記第１出力は、前記ロッキングスクリプトを含み、かつ、前記第２出力は、前記デジタル契約に基づくメタデータを含む。
第３９の、任意的なインスタンス化に従って、上記第３１乃至第３８いずれかのインスタンス化による方法が提供され得る。前記方法は、前記ブロックチェーンに含めるために、前記トランザクションを前記ブロックチェーンネットワークの１つ以上のノードに送信するステップ、を含む。
第４０の、任意的なインスタンス化に従って、上記第３１乃至第３６いずれかのインスタンス化による方法が提供され得る。前記方法は、前記ブロックチェーンに含めるために、第２トランザクションを生成するステップであり、前記第２トランザクションは、前記ロッキングスクリプトをアンロックするように構成されているアンロッキングスクリプトを含み、前記アンロッキングスクリプトは、前記第１当事者の公開鍵および署名を含む、。
ここにおいて開示された教示に係る第４１のインスタンス化に従って、前記第１当事者のコンピュータ機器が提供される。本コンピュータ機器は、１つ以上のメモリユニットを含むメモリと、１つ以上の処理ユニットを含む処理装置と、を含み、前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、前記コードは、前記処理装置において、第３１乃至第４０いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第４２のインスタンス化に従って、コンピュータプログラムが提供される。本コンピュータプログラムは、コンピュータで読取り可能なストレージ装置において具現化され、かつ、信頼される第三者のコンピュータ機器上で実行されると、第３１乃至第４０いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第４３のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実行する、コンピュータで実装される方法が開示される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記方法は、前記第２当事者によって実行され、かつ、前記契約の履行条件を表すデータ要素を獲得するステップであり、前記条件は、前記第２当事者にリンクされている、ステップと、前記獲得されたデータ要素を使用して、ハッシュツリーの候補ルートハッシュを生成するための認証パスを獲得するステップであり、前記ハッシュツリーは、リーフハッシュの層を含み、前記リーフハッシュのうち少なくともいくつかは、それぞれが、複数のデータ要素のうちそれぞれ一つに基づいて生成され、各データ要素は、前記契約の異なる条件を表しており、かつ、前記複数のデータ要素は、前記獲得されたデータ要素を含む、ステップと、信頼される第三者の署名および公開鍵を獲得するステップであり、前記署名は、前記履行について署名する、ステップと、前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、前記トランザクションは、前記第１当事者からの前記デジタル資産の総計をアンロックするためのアンロッキングスクリプトを含み、かつ、前記アンロッキングスクリプトは、前記獲得された認証パス、前記公開鍵、および、前記署名を用いて署名された前記獲得されたデータ要素、を含む、ステップと、を含む。
第４４の、任意的なインスタンス化に従って、上記第４３のインスタンス化による方法が提供され得る。ここで、前記署名は、ラビン署名である。
第４５の、任意的なインスタンス化に従って、上記第４３または第４４のインスタンス化による方法が提供され得る。ここで、前記認証パスを獲得するステップは、前記信頼される第三者から前記認証パスを獲得するステップを含む。
第４６の、任意的なインスタンス化に従って、上記第４３または第４４のインスタンス化による方法が提供され得る。ここで、前記信頼される第三者の前記署名及び／又は前記公開鍵を獲得するステップは、前記信頼される第三者から、前記署名及び／又は前記公開鍵を直接的に取得するステップを含む。
第４７の、任意的なインスタンス化に従って、上記第４１乃至第４６いずれかのインスタンス化による方法が提供され得る。ここで、前記認証パスは、それぞれが、前記ハッシュツリーのうちそれぞれの層からの、ハッシュ値のシーケンスを含む。
第４８の、任意的なインスタンス化に従って、上記第４３乃至第４７いずれかのインスタンス化による方法が提供され得る。前記方法は、前記ブロックチェーンに含めるために、前記ブロックチェーンネットワークの１つ以上のノードに対して前記トランザクションを送信する、ステップを含む。
ここにおいて開示された教示に係る第４９のインスタンス化に従って、前記第２当事者のコンピュータ機器が提供される。本コンピュータ機器は、１つ以上のメモリユニットを含むメモリと、１つ以上の処理ユニットを含む処理装置と、を含み、前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、前記コードは、前記処理装置において、第４３乃至第４８いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第５０のインスタンス化に従って、コンピュータプログラムが提供される。本コンピュータプログラムは、コンピュータで読取り可能なストレージ装置において具現化され、かつ、信頼される第三者のコンピュータ機器上で実行されると、第４３乃至第４８いずれかのインスタンス化に従った教示を実行するように構成されている。
ここにおいて開示された教示に係る第５１のインスタンス化に従って、ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実施するためのトランザクションを含む、コンピュータで読取り可能な記憶媒体が提供される。前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものである。前記トランザクションは、前記デジタル資産の総計を前記第１当事者にロックするためのロッキングスクリプトを含み、前記ロッキングスクリプトは、ルートハッシュを含み、かつ、ハッシュツリーの前記ルートハッシュは、信頼される第三者によって生成される。前記ハッシュツリーは、ｉ）複数のデータ要素であり、各データ要素は、前記契約の異なる条件を表しており、前記異なる条件のうち少なくとも１つは前記第２当事者に関連している、複数のデータ要素、および、ｉｉ）前記信頼される第三者だけに知られている秘密値に基づいて生成された１つ以上の異なるハッシュキー、に基づいて生成されている。
ここにおいて開示された教示に係る別のインスタンス化に従って、第１当事者、第２当事者、信頼される第三者の動作を含む方法が提供され得る。
ここにおいて開示された教示に係る別のインスタンス化に従って、第１当事者、第２当事者、信頼される第三者のコンピュータ機器を含むシステムが提供され得る。
開示された技術の他の変形例または使用事例は、一旦ここにおいて開示されると、当業者にとって明らかになり得る。本開示の範囲は、説明された実施形態によって限定されるものではなく、添付の請求項によってのみ限定されるものである。

Claims (51)

  1. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約をエンコーディングする、コンピュータで実装される方法であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記方法は、信頼される第三者によって実行され、かつ、
    複数のデータ要素を獲得するステップであり、各データ要素は前記契約の異なる条件を表しており、かつ、前記異なる条件のうち少なくとも１つが前記第２当事者にリンクされている、ステップと、
    前記複数のデータ要素に基づいて、ハッシュツリーを生成するステップと、
    を含み、
    前記ハッシュツリーは、
    ｉ）リーフ層であり、
    それぞれのデータ要素をハッシュすることによって、それぞれ生成されるリーフハッシュの第１セット、および、
    前記信頼される第三者にだけ知られている秘密値をハッシュすることによって生成される、少なくとも１つのハッシュキーを含む、リーフハッシュの第２セット、
    を含む、リーフ層と、
    ｉｉ）１つ以上の内部層であり、
    各内部層は、内部ハッシュのそれぞれのセットを含み、
    それぞれの内部層の各内部ハッシュは、下位層からの少なくとも２つのハッシュの連結をハッシュすることによって生成される、
    内部層と、
    ｉｉｉ）ルートハッシュを含む、ルート層であり、
    前記ルートハッシュは、最上位の内部層からの少なくとも２つのハッシュの連結をハッシュすることによって生成され、かつ、
    前記ブロックチェーンのトランザクション内に含めるために、前記ルートハッシュを前記第１当事者に対して利用可能にする、
    ルート層と、
    を含む、
    方法。
  2. 前記データ要素の獲得するステップは、
    前記第１当事者及び／又は第２当事者から、前記データ要素を受信ステップ、
    を含む、請求項１に記載の方法。
  3. 前記ルートハッシュを利用可能にするステップは、
    前記ルートハッシュを前記第１当事者に送信するステップ、
    を含む、請求項１または２に記載の方法。
  4. 前記方法は、
    前記第１当事者によって生成された前記ブロックチェーンのトランザクションを識別するステップであり、
    前記トランザクションは、前記デジタル契約を含み、かつ、
    前記デジタル契約は、前記第１当事者に対して前記デジタル資産の総計をロックしているロッキングスクリプトを含む、
    ステップと、
    前記ロッキングスクリプトが前記ルートハッシュを含むか否かを決定する、ステップと、
    前記ロッキングスクリプトが前記ルートハッシュを含まない場合には、第２当事者に通知する、ステップと、
    を含む、請求項１乃至３いずれか一項に記載の方法。
  5. 前記方法は、
    前記第２当事者に関連する契約の条件が満たされていること決定するステップと、
    決定にレスポンスして、前記第２当事者に対して認証パスを送信するステップであり、
    前記認証パスはハッシュのセットを含み、
    前記ハッシュのセットは、ハッシュキー、および、内部ハッシュの１つ以上のセットを含み、
    内部ハッシュの各セットは、前記ハッシュツリーの異なる内部層に属している、
    ステップと、
    を含む、請求項１乃至４いずれか一項に記載の方法。
  6. 前記リーフハッシュの第２セットは、複数の異なるハッシュキーを含み、それぞれのハッシュキーは前記秘密値に基づいて生成される、
    請求項１乃至５いずれか一項に記載の方法。
  7. 前記リーフハッシュの第１セットそれぞれは、前記ハッシュキーのうち異なる１つとペアになっており、かつ、
    前記ハッシュツリーの最下層の内部ハッシュそれぞれは、リーフハッシュの異なるペアの連結をハッシュすることによって生成される、
    請求項６に記載の方法。
  8. 前記認証パスは、第２ノードに関連する前記条件のリーフハッシュとペアにされた前記ハッシュキーを含む、
    請求項５に従属する場合の請求項７に記載の方法。
  9. 前記信頼される第三者のコンピュータ機器であって、
    １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置と、を含み、
    前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、
    前記コードは、前記処理装置において、請求項１乃至８いずれか一項に記載の方法を実行するように構成されている、
    コンピュータ機器。
  10. コンピュータプログラムであって、
    コンピュータで読取り可能なストレージ装置において具現化され、かつ、
    信頼される第三者のコンピュータ機器上で実行されると、請求項１乃至８いずれか一項に記載の方法を実行するように構成されている、
    コンピュータプログラム。
  11. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を生成する、コンピュータで実装される方法であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記方法は、前記第１当事者によって実行され、かつ、
    信頼される第三者によって生成されたハッシュツリーのルートハッシュを獲得するステップであり、前記ハッシュツリーは、
    ｉ）複数のデータ要素であり、各データ要素は、前記契約の異なる条件を表しており、前記異なる条件のうち少なくとも１つは前記第２当事者に関連している、複数のデータ要素、および、
    ｉｉ）前記信頼される第三者だけに知られている秘密値に基づいて生成された１つ以上の異なるハッシュキー、
    に基づいて生成されている、ステップと、
    前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、
    前記トランザクションは、前記第１当事者に対して前記デジタル資産の総計をロックするためのロッキングスクリプトを含み、かつ、
    前記ロッキングスクリプトは、前記ルートハッシュを含む、
    ステップと、を含む、
    方法。
  12. 前記方法は、
    前記ブロックチェーンに含めるために、前記ブロックチェーンネットワークのうち１つ以上のノードに対して前記トランザクションを送信するステップ、
    を含む、請求項１１に記載の方法。
  13. 前記ルートハッシュの獲得するするステップは、
    前記信頼される第三者から前記ルートハッシュを受信するステップ、
    を含む、請求項１１または１２記載の方法。
  14. 前記第２当事者によって生成される前記ブロックチェーンの後のトランザクションは、
    ｉ）前記契約の条件を表すデータ要素と、
    ｉｉ）ハッシュキー、および、前記ハッシュツリーのうち１つ以上の内部ハッシュを含む認証パスと、
    を含む、アンロッキングスクリプトを備え、かつ、
    前記ロッキングスクリプトは、ロッキングスクリプト一緒に実行されると、
    前記データ要素および前記認証パスを使用して、ハッシュツリープルーフを実行することによって、候補ルートハッシュを生成し、かつ、
    前記ルートハッシュが候補のルートハッシュツリーと一致するか否かに応じて、真または偽のいずれかを表す値を生成する、
    ように構成されている、
    請求項１１乃至１３いずれか一項に記載の方法。
  15. 前記第１当事者のコンピュータ機器であって、
    １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置と、を含み、
    前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、
    前記コードは、前記処理装置において、請求項１１乃至１４いずれか一項に記載の方法を実行するように構成されている、
    コンピュータ機器。
  16. コンピュータプログラムであって、
    コンピュータで読取り可能なストレージ装置において具現化され、かつ、
    前記第１当事者のコンピュータ機器上で実行されると、請求項１１乃至１４いずれか一項に記載の方法を実行するように構成されている、
    コンピュータプログラム。
  17. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実行する、コンピュータで実装される方法であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記方法は、前記第２当事者によって実行され、かつ、
    前記契約の条件を表すデータ要素を獲得するステップであり、前記条件は、前記第２当事者にリンクされている、ステップと、
    認証パスを獲得するステップであり、
    前記認証パスは、信頼される第三者によって生成されたハッシュツリーの候補ルートハッシュを生成するためのものであり、かつ、
    前記認証パスは、ハッシュのセットを含み、
    前記ハッシュのセットは、前記信頼される第三者にだけ知られている秘密値に基づいて生成されたハッシュキー、および、内部ハッシュの１つ以上のセットを含み、
    内部ハッシュのセットそれぞれは、前記ハッシュの異なる内部層に属している、
    ステップと、
    前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、
    前記トランザクションは、前記第１当事者からの前記デジタル資産の総計をアンロックするためのアンロッキングスクリプトを含み、かつ、
    前記アンロッキングスクリプトは、前記獲得されたデータ要素および前記獲得された認証パスを含む、
    ステップと、
    を含む、方法。
  18. 前記方法は、
    前記ブロックチェーンに含めるために、前記ブロックチェーンネットワークの１つ以上のノードに前記トランザクションを送信する、
    請求項１７に記載の方法。
  19. 前記第２当事者のコンピュータ機器であって、
    １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置と、を含み、
    前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、
    前記コードは、前記処理装置において、請求項１７または１８に記載の方法を実行するように構成されている、
    コンピュータ機器。
  20. コンピュータプログラムであって、
    コンピュータで読取り可能なストレージ装置において具現化され、かつ、
    前記第２当事者のコンピュータ機器上で実行されると、請求項１７または１８に記載の方法を実行するように構成されている、
    コンピュータプログラム。
  21. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約をエンコーディングする、コンピュータで実装される方法であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記方法は、信頼される第三者によって実行され、かつ、
    前記第２当事者にリンクされた前記契約の条件が満たされたと判断することにレスポンスして、前記ブロックチェーンのトランザクションに含めるために、前記第２当事者に前記信頼される第三者の署名を提供するステップであり、前記署名は、前記満たされた条件を表すデータ要素に署名する、ステップ、
    を含む、
    方法。
  22. 前記署名は、ラビン署名である、
    請求項２１に記載の方法。
  23. 前記方法は、
    前記第２当事者にラビン公開鍵を提供するステップ、
    を含む、請求項２２に記載の方法。
  24. 前記署名を提供するステップは、
    前記第２当事者に対して前記署名を直接的に送信するステップ、
    を含む、請求項２１乃至２３いずれか一項に記載の方法。
  25. 前記方法は、
    複数のデータ要素を前記第１当事者に提供するステップであり、
    各データ要素は、前記契約の異なる条件を表しており、かつ、
    前記複数のデータ要素は、前記第２当事者にリンクされた条件を表すデータ要素を含む、
    ステップ、
    を含む、請求項２１乃至２４いずれか一項に記載の方法。
  26. 前記方法は、
    ハッシュツリーのルートハッシュを生成するステップであり、
    前記ハッシュツリーは、リーフハッシュの層を含み、かつ、
    前記リーフハッシュのうち少なくともいくつかは、前記複数のデータ要素のそれぞれ１つに基づいて生成される、
    ステップと、
    前記第１当事者に前記ルートハッシュを提供するステップと、
    を含む、請求項２５に記載の方法。
  27. 前記方法は、
    前記満たされた条件を表すデータ要素を使用して、前記ハッシュツリーの候補ルートハッシュを生成するために、前記第２当事者に認証パスを提供するステップ、
    を含む、請求項２６に記載の方法。
  28. 各データ要素は、前記契約の異なる条件を表している、異なるバイナリまたは１６進数値である、
    請求項２１乃至２６いずれか一項に記載の方法。
  29. 前記信頼される第三者のコンピュータ機器であって、
    １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置と、を含み、
    前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、
    前記コードは、前記処理装置において、請求項２１乃至２８いずれか一項に記載の方法を実行するように構成されている、
    コンピュータ機器。
  30. コンピュータプログラムであって、
    コンピュータで読取り可能なストレージ装置において具現化され、かつ、
    前記第１当事者のコンピュータ機器上で実行されると、請求項２１乃至２８いずれか一項に記載の方法を実行するように構成されている、
    コンピュータプログラム。
  31. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を生成する、コンピュータで実装される方法であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記方法は、信頼される前記第１当事者によって実行され、かつ、
    ハッシュツリーのルートハッシュを獲得するステップであり、
    前記ハッシュツリーは、リーフハッシュの層を含み、
    前記リーフハッシュのうち少なくともいくつかは、それぞれが、複数のデータ要素のうちそれぞれ一つに基づいて生成され、
    各データ要素は、前記契約の異なる条件を表しており、かつ、
    前記異なる条件のうち少なくとも１つは、前記第２当事者にリンクされている、
    ステップと、
    前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、
    前記トランザクションは、前記第１当事者に対して前記デジタル資産の総計をロックするためのロッキングスクリプトを含み、かつ、
    前記ロッキングスクリプトは、前記ルートハッシュを含んでおり、
    前記ロッキングスクリプトは、後のトランザクションのアンロッキングスクリプトと共に実行されるときに、
    前記アンロッキングスクリプトが、ｉ）信頼される第三者の署名と共に署名された前記契約の条件を表すデータ要素、および、ｉｉ）前記署名されたデータエレメントを使用して、前記獲得されたルートハッシュに一致する候補ルートハッシュを生成するための認証パス、を含むか否か、
    を決定する、ように構成されている、
    ステップと、
    を含む、方法。
  32. 前記ルートハッシュを獲得するステップは、
    前記ルートハッシュを生成するステップ、
    を含む、請求項３１に記載の方法。
  33. 前記ルートハッシュを得る獲得するステップは、
    前記第２当事者及び／又は前記信頼される第三者から前記ルートハッシュを獲得するステップ、
    を含む、請求項３１に記載の方法。
  34. 前記署名は、ラビン署名である、
    請求項３１乃至３３いずれか一項に記載の方法。
  35. 前記認証パスは、それぞれ前記ハッシュツリーの各層からのものである、ハッシュ値のシーケンスを含み、かつ、
    前記ロッキングスクリプトは、前記獲得されたルートハッシュと前記ハッシュ値のシーケンスを使用して、ハッシュツリープルーフを実行するためのオペコードのシーケンスを含む、
    請求項３１乃至３４いずれか一項に記載の方法。
  36. 前記ロッキングスクリプトは、
    既定の時間内に前記総計が前記第２当事者に移転されない場合に、前記第１当事者が前記デジタル資産の前記総計を償還できる、
    ように構成されている、請求項３１乃至３５いずれか一項に記載の方法。
  37. 前記ロッキングスクリプトは、
    ｉｉｉ）前記第２当事者の有効な署名および公開鍵、を含むか否かを、決定する、
    ように構成されている、請求項３１乃至３６いずれか一項に記載の方法。
  38. 前記トランザクションは、第１出力と第２出力とを含み、
    前記第１出力は、前記ロッキングスクリプトを含み、かつ、
    前記第２出力は、前記デジタル契約に基づくメタデータを含む、
    請求項３１乃至３７いずれか一項に記載の方法。
  39. 前記方法は、
    前記ブロックチェーンに含めるために、前記トランザクションを前記ブロックチェーンネットワークの１つ以上のノードに送信するステップ、
    を含む、請求項３１乃至３８いずれか一項に記載の方法。
  40. 前記方法は、
    前記ブロックチェーンに含めるために、第２トランザクションを生成するステップであり、
    前記第２トランザクションは、前記ロッキングスクリプトをアンロックするように構成されているアンロッキングスクリプトを含み、
    前記アンロッキングスクリプトは、前記第１当事者の公開鍵および署名を含む、
    請求項３６に従属する場合の請求項３９に記載の方法。
  41. 前記第１当事者のコンピュータ機器であって、
    １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置と、を含み、
    前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、
    前記コードは、前記処理装置において、請求項３１乃至４０いずれか一項に記載の方法を実行するように構成されている、
    コンピュータ機器。
  42. コンピュータプログラムであって、
    コンピュータで読取り可能なストレージ装置において具現化され、かつ、
    信頼される第三者のコンピュータ機器上で実行されると、請求項３１乃至４０いずれか一項に記載の方法を実行するように構成されている、
    コンピュータプログラム。
  43. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実行する、コンピュータで実装される方法であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記方法は、前記第２当事者によって実行され、かつ、
    前記契約の履行条件を表すデータ要素を獲得するステップであり、前記条件は、前記第２当事者にリンクされている、ステップと、
    前記獲得されたデータ要素を使用して、ハッシュツリーの候補ルートハッシュを生成するための認証パスを獲得するステップであり、
    前記ハッシュツリーは、リーフハッシュの層を含み、
    前記リーフハッシュのうち少なくともいくつかは、それぞれが、複数のデータ要素のうちそれぞれ一つに基づいて生成され、
    各データ要素は、前記契約の異なる条件を表しており、かつ、
    前記複数のデータ要素は、前記獲得されたデータ要素を含む、
    ステップと、
    信頼される第三者の署名および公開鍵を獲得するステップであり、前記署名は、前記履行について署名する、ステップと、
    前記ブロックチェーンに含めるためのトランザクションを生成するステップであり、
    前記トランザクションは、前記第１当事者からの前記デジタル資産の総計をアンロックするためのアンロッキングスクリプトを含み、かつ、
    前記アンロッキングスクリプトは、前記獲得された認証パス、前記公開鍵、および、前記署名を用いて署名された前記獲得されたデータ要素、を含む、
    ステップと、
    を含む、方法。
  44. 前記署名は、ラビン署名である、
    請求項４３に載の方法。
  45. 前記認証パスを獲得するステップは、
    前記信頼される第三者から前記認証パスを獲得するステップ、
    を含む、請求項４３または４４に記載の方法。
  46. 前記信頼される第三者の前記署名及び／又は前記公開鍵を獲得するステップは、
    前記信頼される第三者から、前記署名及び／又は前記公開鍵を直接的に取得するステップ、
    を含む、請求項４３乃至４５いずれか一項に記載の方法。
  47. 前記認証パスは、それぞれが、前記ハッシュツリーのうちそれぞれの層からの、ハッシュ値のシーケンスを含む、
    請求項４３乃至４６いずれか一項に記載の方法。
  48. 前記方法は、
    前記ブロックチェーンに含めるために、前記ブロックチェーンネットワークの１つ以上のノードに対して前記トランザクションを送信する、ステップ、
    を含む、請求項４３乃至４７いずれか一項に記載の方法。
  49. 前記第２当事者のコンピュータ機器であって、
    １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置と、を含み、
    前記メモリは、前記処理装置上で実行するように構成されたコードを保管しており、
    前記コードは、前記処理装置において、請求項４３乃至４８いずれか一項に記載の方法を実行するように構成されている、
    コンピュータ機器。
  50. コンピュータプログラムであって、
    コンピュータで読取り可能なストレージ装置において具現化され、かつ、
    信頼される第三者のコンピュータ機器上で実行されると、４３乃至４８いずれか一項に記載の方法を実行するように構成されている、
    コンピュータプログラム。
  51. ブロックチェーンネットワークの第１当事者と、前記ブロックチェーンネットワークの第２当事者との間のデジタル契約を実施するためのトランザクションを含む、コンピュータで読取り可能な記憶媒体であって、
    前記デジタル契約は、契約が履行される条件に基づいて、前記第１当事者から前記第２当事者へデジタル資産の総計を移転するためのものであり、
    前記トランザクションは、前記デジタル資産の総計を前記第１当事者にロックするためのロッキングスクリプトを含み、
    前記ロッキングスクリプトは、ルートハッシュを含み、かつ、
    ハッシュツリーの前記ルートハッシュは、信頼される第三者によって生成され、
    前記ハッシュツリーは、
    ｉ）複数のデータ要素であり、各データ要素は、前記契約の異なる条件を表しており、前記異なる条件のうち少なくとも１つは前記第２当事者に関連している、複数のデータ要素、および、
    ｉｉ）前記信頼される第三者だけに知られている秘密値に基づいて生成された１つ以上の異なるハッシュキー、
    に基づいて生成されている、
    コンピュータで読取り可能な記憶媒体。
JP2022504625A 2019-07-25 2020-06-25 ブロックチェーントランザクションを利用したデジタル契約 Pending JP2022541323A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1910649.1 2019-07-25
GB1910649.1A GB2592338A (en) 2019-07-25 2019-07-25 Digital contracts using blockchain transactions
PCT/IB2020/055999 WO2021014233A1 (en) 2019-07-25 2020-06-25 Digital contracts using blockchain transactions

Publications (1)

Publication Number Publication Date
JP2022541323A true JP2022541323A (ja) 2022-09-22

Family

ID=67990357

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022504625A Pending JP2022541323A (ja) 2019-07-25 2020-06-25 ブロックチェーントランザクションを利用したデジタル契約

Country Status (6)

Country Link
US (1) US20220278859A1 (ja)
EP (1) EP4005144A1 (ja)
JP (1) JP2022541323A (ja)
CN (1) CN114982193A (ja)
GB (1) GB2592338A (ja)
WO (1) WO2021014233A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220337424A1 (en) * 2021-04-16 2022-10-20 Portable Data Corp Apparatuses And Methods For Facilitating Cryptographically Mediated Organizations And Tokens And Related Interactions
GB2606527A (en) 2021-05-10 2022-11-16 Nchain Licensing Ag Multi-party blockchain address scheme
GB2606526A (en) 2021-05-10 2022-11-16 Nchain Licensing Ag Multi-party blockchain address scheme
GB2606528A (en) 2021-05-10 2022-11-16 Nchain Licensing Ag Multi-party blockchain address scheme
GB2609194A (en) * 2021-07-19 2023-02-01 Nchain Licensing Ag Enforcing conditions on blockchain transactions
GB202114285D0 (en) * 2021-10-06 2021-11-17 Nchain Licensing Ag Layer 2 token protocol
WO2023064557A1 (en) * 2021-10-15 2023-04-20 Chia Network Inc. Method for securing private structured databases within a public blockchain
US12010239B2 (en) * 2022-02-11 2024-06-11 Avaworks Incorporated Talking head digital identity authentication
GB2615598A (en) * 2022-02-15 2023-08-16 Nchain Licensing Ag Attesting to a set of unconsumed transaction outputs
GB2616433A (en) * 2022-03-08 2023-09-13 Nchain Licensing Ag Translucent blockchain database
US20240232204A1 (en) * 2023-01-09 2024-07-11 Walmart Apollo, Llc Systems and methods for compressing data for distributed ledgers

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001011843A1 (en) * 1999-08-06 2001-02-15 Sudia Frank W Blocked tree authorization and status systems
US10841097B2 (en) * 2016-07-08 2020-11-17 Mastercard International Incorporated Method and system for verification of identity attribute information
US11265147B2 (en) * 2016-12-16 2022-03-01 Nokia Technologies Oy Secure document management
US11316696B2 (en) * 2017-09-29 2022-04-26 R3 Ltd. Hash subtrees for grouping components by component type
GB201720946D0 (en) * 2017-12-15 2018-01-31 Nchain Holdings Ltd Computer-implemented system and method
CN111737728A (zh) * 2020-04-08 2020-10-02 北京瑞策科技有限公司 基于业务数据区块链的自媒体数据存储方法及系统

Also Published As

Publication number Publication date
US20220278859A1 (en) 2022-09-01
WO2021014233A1 (en) 2021-01-28
GB2592338A (en) 2021-09-01
CN114982193A (zh) 2022-08-30
GB201910649D0 (en) 2019-09-11
EP4005144A1 (en) 2022-06-01

Similar Documents

Publication Publication Date Title
JP2022541323A (ja) ブロックチェーントランザクションを利用したデジタル契約
CN111566649A (zh) 使用公有侧链验证存储在联盟区块链中的数据的完整性
CN113924747A (zh) 区块链交易数据字段验证
JP2022533753A (ja) 知識証明
JP7551658B2 (ja) 知識証明
JP7536796B2 (ja) プルーフ・オブ・ワーク
JP7543313B2 (ja) 複数インプットトランザクション
JP7532414B2 (ja) サイドチャネル上でのデータの部分のストリーミング
US20230316272A1 (en) Divisible tokens
US20220337427A1 (en) Cryptographically linked identities
JP2023515368A (ja) ブロックチェーンネットワークと共に使用される証明サービス
JP2022533752A (ja) 知識証明
JP2023532211A (ja) ブロックチェーン上の合意
KR20240096559A (ko) 분산된 블록체인 기능들을 위한 방법들 및 시스템들
JP2022533845A (ja) 知識証明
JP2023513950A (ja) 階層化ネットワーク
JP2022548173A (ja) マルチ基準ブロックチェーンプロトコル
KR20240100373A (ko) 분산된 블록체인 기능들을 위한 방법들 및 시스템들
KR20240100377A (ko) 분산된 블록체인 기능들을 위한 방법들 및 시스템들
CN118044151A (zh) 传播锁定脚本
CN117561697A (zh) 部分基于sha的哈希函数
JP2023529467A (ja) カスタムトランザクションスクリプト
WO2024156510A1 (en) Proof and verification of data storage
WO2024041866A1 (en) Blockchain transaction
KR20240093714A (ko) 분산된 블록체인 기능들을 위한 방법들 및 시스템들

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230526

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240516

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240702

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20241001