知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-08-17
(54)【発明の名称】ブロックチェーンベースの税金メカニズム
(51)【国際特許分類】
G06Q 30/04 20120101AFI20230809BHJP
H04L 9/32 20060101ALI20230809BHJP
【ＦＩ】
G06Q30/04
H04L9/32 200Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023502992
(86)(22)【出願日】2021-06-29
(85)【翻訳文提出日】2023-01-16
(86)【国際出願番号】 EP2021067806
(87)【国際公開番号】W WO2022022928
(87)【国際公開日】2022-02-03
(31)【優先権主張番号】2011858.4
(32)【優先日】2020-07-30
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジョーゼフ，ダニエル
(72)【発明者】
【氏名】ライト，クレイグ，スティーヴン
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049BB11
(57)【要約】
買い手による売り手からの１つまたは複数の商品および／またはサービスの購入に対する消費税を容易にするコンピュータ実装方法であって、少なくとも買い手は、上記商品および／またはサービスに基づいてオンワード販売を行う買い手－売り手である、方法。方法は、購入の売り手によって、少なくとも第２のブロックチェーントランザクションが買い手の暗号署名で署名されることを要求する第１の条件と、少なくとも第２のブロックチェーントランザクションが税務当局の少なくとも暗号署名で署名されることを要求する第２の条件という２つの代替条件のいずれかを第２のブロックチェーントランザクションが満たすによって償還することができる第１のブロックチェーントランザクションを取得することと、買い手から消費税の支払いを受けたことに応答して、ブロックチェーン上に記録されるべき第１のブロックチェーントランザクションを送信することとを含む。
【特許請求の範囲】
【請求項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】
コンピュータ可読ストレージ上に具現化され、コンピュータ機器上で実行されると、請求項３８に記載の方法を実行するように構成されたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、税金システムにおけるブロックチェーンの適用に関する。
【背景技術】
【0002】
ブロックチェーンは、分散型データ構造の形態を指し、ブロックチェーンの複製コピーが、分散型ピアツーピア（Ｐ２Ｐ）ネットワーク（以下では「ブロックチェーンネットワーク」と呼ばれる）内の複数のノードの各々において維持され、広く公開されている。ブロックチェーンはデータブロックのチェーンを含み、各ブロックは１つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の各トランザクションは、１つまたは複数のコインベーストランザクションまで遡る１つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指し示す。コインベーストランザクションについては以下でさらに説明する。ブロックチェーンネットワークにサブミットされるトランザクションは、新しいブロックに含まれる。新しいブロックは、「マイニング（mining）」と呼ばれることが多いプロセスによって作成され、このプロセスは、複数のノードの各々が「プルーフオブワーク（proof-of-work）」を実行しようと競うこと、すなわち、ブロックチェーンの新しいブロックに含まれるのを待っている、順序付けられ妥当性確認（validate）された保留中のトランザクションのプールに基づいて暗号パズルを解くことを伴う。ブロックチェーンはいくつかのノードでプルーニング（prune）され得、ブロックの公開は、単なるブロックヘッダの公開を通して達成され得ることに留意されたい。
【0003】
ブロックチェーン内のトランザクションは、デジタル資産（すなわち、いくつかのデジタルトークン）を伝達すること、仮想台帳またはレジストリにおけるエントリのセットを順序付けること、タイムスタンプエントリを受信および処理すること、および／またはインデックスポインタを時間順にすることという目的のうちの１つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンの上に追加の機能を重ねるために活用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータへのインデックスの記憶を可能にし得る。単一のトランザクション内に記憶することができる最大データ容量に対してあらかじめ指定された制限はなく、したがって、より複雑なデータを組み込むことができる。例えば、これを使用して、ブロックチェーンに電子文書を記憶したり、オーディオまたはビデオデータを記憶したりすることができる。
【0004】
ブロックチェーンネットワークのノード（「マイナー（miner）」と呼ばれることが多い）は、以下でより詳細に説明する分散型のトランザクション登録および検証プロセスを実行する。要するに、このプロセスの間に、ノードは、トランザクションを妥当性確認し、ノードが有効なプルーフオブワークの解を識別しようとするブロックテンプレートにそれらを挿入する。有効な解が見つかると、ネットワークの他のノードに新しいブロックが伝搬され、これにより、各ノードが、新しいブロックをブロックチェーンに記録することができる。トランザクションをブロックチェーンに記録させるために、ユーザ（例えば、ブロックチェーンクライアントアプリケーション）は、ネットワークのノードの１つにトランザクションを送信して、伝搬させる。トランザクションを受信したノードは、妥当性確認済みトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけようと競い合い得る。各ノードは、同じノードプロトコルを実施するように構成され、そのノードプロトコルには、トランザクションが有効であるための１つまたは複数の条件が含まれる。無効なトランザクションは、伝搬もブロックへの組込みもされない。トランザクションが妥当性確認され、それによってブロックチェーン上に受け入れられたと仮定すると、トランザクション（任意のユーザデータを含む）は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々において登録およびインデックス付けされたままになる。
【0005】
プルーフオブワークパズルを解くのに成功して最新のブロックを作成したノードは、典型的には、ある額のデジタル資産、すなわちいくつかのトークンを配布する「コインベーストランザクション」と呼ばれる新しいトランザクションで報酬が与えられる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして働き、不正を報告および阻止するようにインセンティブが与えられる競合ノードのアクションによって実施される。情報の広範な公開により、ユーザは、ノードの性能を連続的に監査することができる。単なるブロックヘッダの公開により、参加者は、ブロックチェーンの継続的な完全性を確実にすることができる。
【0006】
「出力ベースの」モデル（ＵＴＸＯベースモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つまたは複数の入力と１つまたは複数の出力とを含む。任意の使用可能な出力は、トランザクションの先行するシーケンスから導出可能なデジタル資産の額を指定する要素を含む。使用可能な出力は、ＵＴＸＯ（「未使用トランザクション出力」）と呼ばれることがある。出力は、出力を将来償還するための条件を指定するロックスクリプトをさらに含み得る。ロックスクリプトは、デジタルトークンまたは資産を妥当性確認および転送するために必要な条件を定義する述語（predicate）である。トランザクション（コインベーストランザクション以外）の各入力は、先行するトランザクションにおけるそのような出力へのポインタ（すなわち、参照）を含み、指し示された出力のロックスクリプトをロック解除するためのロック解除スクリプトをさらに含み得る。そのため、トランザクションのペアを考慮して、それらを第１のトランザクションおよび第２のトランザクション（または「ターゲット」トランザクション）と呼ぶ。第１のトランザクションは、デジタル資産の額を指定する少なくとも１つの出力を含み、出力をロック解除する１つまたは複数の条件を定義するロックスクリプトを含む。第２の、ターゲットトランザクションは、第１のトランザクションの出力へのポインタを含む少なくとも１つの入力と、第１のトランザクションの出力をロック解除するためのロック解除スクリプトとを含む。
【0007】
そのようなモデルでは、第２のターゲットトランザクションがブロックチェーンネットワークに送信されて伝搬されブロックチェーンに記録されるとき、各ノードで適用される有効性の基準のうちの１つは、ロック解除スクリプトが第１のトランザクションのロックスクリプトで定義された１つまたは複数の条件のすべてを満たすことである。もう１つは、第１のトランザクションの出力が別の先の有効なトランザクションによってまだ償還されていないということである。これらの条件のいずれかにしたがってターゲットトランザクションが無効であることを発見したノードは、（無効なトランザクションを登録するために伝搬する可能性はあるが、有効なトランザクションとしては）それを伝搬することも、ブロックチェーンに記録されるように新しいブロックにそれを含めることもしない。
【0008】
トランザクションモデルの別のタイプは、アカウントベースのモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にノードによって記憶され、絶えず更新される。
【0009】
ブロックチェーン技術の１つの提案される用途は、税金システムでの使用である。
【0010】
政府の公共支出に資金を供給するために、一般に、個人およびとりわけ企業などの法人に対して金銭的な請求が課される。この課税は、所得税、財産税、資本利得税などを含む多くの形態で行われ得る。
【0011】
政府は、政府の経済目標に基づいて、これらの課税システムのうちの１つまたは複数を実施し得る。これは、各システムの利点および欠点を考慮したものである。例として、富および貯蓄の変化は、消費税をではなく所得税を介してより容易に把握することができる。
【0012】
消費税は、売上税だけでなく、税関、物品税などの税である。これらのタイプの税は、商品またはサービスの購入に直接結びついている。
【0013】
税徴収システムにおけるブロックチェーンの役割は、以前から検討されている。例として、https://www.pwc.co.uk/issues/futuretax/assets/documents/how-blockchain-could-improve-the-tax-system.pdfには、ブロックチェーンの以下の特性をどのように税に適用することができるかが説明されている。
・ トランスペアレンシ（transparency）－ブロックチェーンは、トランザクションの出所、トレーサビリティ、およびトランスペアレンシを提供する。
・ 制御－許可されたネットワークへのアクセスは、識別されたユーザに制限される。
・ セキュリティ－デジタル台帳は、データが入力されると、変更または改ざんが不可能である。不正の可能性は低く、発見しやすい。
・ リアルタイム情報－情報が更新されると、ネットワーク内の全員に対して同時に更新される。https://cloudblogs.microsoft.com/industry-blog/government/2019/04/16/could-blockchain-become-governments-best-ally-in-driving-tax-compliance/もまた、特定の税収入をリングフェンシングする際のスマートコントラクトの利用の可能性について言及している。
・ トランスペアレンシ（transparency）－ブロックチェーンは、トランザクションの出所、トレーサビリティ、およびトランスペアレンシを提供する。
・ 制御－許可されたネットワークへのアクセスは、識別されたユーザに制限される。
・ セキュリティ－デジタル台帳は、データが入力されると、変更または改ざんが不可能である。不正の可能性は低く、発見しやすい。
・ リアルタイム情報－情報が更新されると、ネットワーク内の全員に対して同時に更新される。https://cloudblogs.microsoft.com/industry-blog/government/2019/04/16/could-blockchain-become-governments-best-ally-in-driving-tax-compliance/もまた、特定の税収入をリングフェンシングする際のスマートコントラクトの利用の可能性について言及している。
【0014】
したがって、例えば、会社は、トランザクション、購入、および給与支払いのようなイベントを自動的に記録し、会計士に何千もの記録から数字を導出させるのではなく、実際に発生した内容に基づいてその税金（tax bill）を支払うことができる。政府および組織の両方にとって相当な時間を短縮することができる。同時に、ブロックチェーン指向の税金システムを実施し得る前に、法律などの非技術的な考慮事項に対処する必要がある。
【発明の概要】
【0015】
税そのものは行政の問題であり得るが、税を実施するシステムには、技術で解決することができる明らかな問題がある可能性がある。特に、買い手がチェーンの買い手－売り手である場合、すなわち、買い手自身が事業者であり、売り手に支払ったＶＡＴなどの消費税の還付（refund）を受ける権利がある場合、現在のシステムを使用すると、買い手に消費税が還付可能になるまでに、買い手は、典型的に、所定の期間の終了まで待たなければならない。既存のシステムのアカウンタビリティを依然として保持しつつ（または、さらに向上させつつ）、買い手に消費税をより迅速に還付することを可能にするメカニズムを提供するために技術を使用することが望ましいであろう。
【0016】
本明細書で開示される一態様によれば、買い手による売り手からの１つまたは複数の商品および／またはサービスの購入に対する消費税を容易にするコンピュータ実装方法であって、少なくとも買い手は、上記商品および／またはサービスに基づいてオンワード販売（onward sale）を行う買い手－売り手である、方法が提供される。方法は、上記購入の売り手によって、（ｉ）少なくとも第２のブロックチェーントランザクションが買い手の暗号署名で署名されることを要求する第１の条件と、（ｉｉ）少なくとも第２のブロックチェーントランザクションが税務当局（tax authority）の少なくとも暗号署名で署名されることを要求する第２の条件という２つの代替条件のいずれかを第２のブロックチェーントランザクションが満たすによって償還することができる第１のブロックチェーントランザクションを取得することを含む。方法は、買い手から消費税の支払いを受けたことに応答して、売り手が、ブロックチェーン上に記録されるべき第１のブロックチェーントランザクションを送信することをさらに含む。
【0017】
したがって、開示される技術は、実施形態において、売上税およびＶＡＴなどの消費税のためのより高速なリアルタイムの税徴収システムを可能にするブロックチェーンのための用途を提供する。この税徴収および管理を容易にする開示されるシステム（その例は、以下で「ＳＴＡＸＲＴ」および「ＶＴＡＸＲＴ」と呼ばれる）は、買い手が、以前に支払ったＶＡＴまたは売上税に対する還付を得ることができるようになるのに、一定期間（例えば、３ヶ月、１２ヶ月）待つ必要がないという点で、買い手への消費税のリアルタイム還付を可能にするように設計される。買い手が還付を受ける権利があることを証明することができる限り、還付を入手することができるべきである。
【図面の簡単な説明】
【0018】
本開示の実施形態の理解を支援し、そのような実施形態がどのように実施され得るかを示すために、ほんの一例として、添付の図面を参照する。
【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。
【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。
【図3】農家が綿を販売してから顧客のドレスになるまでの例示的なチェーンにおける売上税の運用を概略的に示す。
【図4】農家が綿を販売してから顧客のドレスになるまでの例示的なチェーンにおける付加価値税（ＶＡＴ）の運用を概略的に示す。
【図5】売上税または付加価値税などの消費税の買い手－売り手へのリアルタイム還付を可能にするメカニズムの一部として使用するための例示的なブロックチェーントランザクションを概略的に示す。
【図6】購入のチェーンにおける参加者間のＶＡＴ支払いの別の例を概略的に示す。
【図7】ＶＡＴ支払いを回収するための例示的なプロトコルにおける参加者のアクションを示すシグナリングチャートである。
【図8】入力および出力を示すＶＡＴトランザクションの概略的な視覚的表現である。
【図9】ＶＡＴのエスクローのためのコミットメントチャネルを概略的に示す。
【図10】ＶＡＴのためのコミットメントチャネルのフローチャートである。
【図11】ＶＡＴ支払いを回収するための別の例示的なプロトコルにおける参加者のアクションを示すシグナリングチャートである。
【図12】購入のチェーンにおける参加者間の売上税支払いの別の例を概略的に示す。
【図13】売上税支払いのための例示的なプロトコルにおける参加者のアクションを示すシグナリングチャートである。
【図14】入力および出力を示す売上税トランザクションの概略的な視覚的表現である。
【図15】売上税のエスクローのためのコミットメントチャネルを概略的に示す。
【図16】当事者間の通信を概略的に示す。
【発明を実施するための形態】
【0019】
例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１で構成され得る。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）ネットワーク１０６を形成するように構成され得る複数のブロックチェーンノード１０４を含む。図示されていないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして構成され得る。したがって、各ブロックチェーンノード１０４は、他のブロックチェーンノード１０４に高度に接続される。
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１で構成され得る。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）ネットワーク１０６を形成するように構成され得る複数のブロックチェーンノード１０４を含む。図示されていないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして構成され得る。したがって、各ブロックチェーンノード１０４は、他のブロックチェーンノード１０４に高度に接続される。
【0020】
各ブロックチェーンノード１０４は、ピアのコンピュータ機器を含み、ノード１０４の異なるものは、異なるピアに属する。各ブロックチェーンノード１０４は、１つまたは複数のプロセッサ、例えば、１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ならびに特定用途向け集積回路（ＡＳＩＣ）などの他の機器を備える処理装置を含む。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。
【0021】
ブロックチェーン１５０は、データブロック１５１のチェーンを含み、ブロックチェーン１５０のそれぞれのコピーは、分散型またはブロックチェーンネットワーク１０６内の複数のブロックチェーンノード１０４の各々で維持される。上述したように、ブロックチェーン１５０のコピーを維持することは、ブロックチェーン１５０を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン１５０は、各ブロックチェーンノード１５０が各ブロック１５１のブロックヘッダ（後述する）を記憶している限り、データがプルーニングされ得る。チェーン内の各ブロック１５１は、１つまたは複数のトランザクション１５２を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つの入力および少なくとも１つの出力を含む。各出力は、プロパティとしてデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされている（ロック解除され、それによって償還または使用されるためにはそのユーザの署名または他のソリューションを必要とする）ユーザ１０３である。各入力は、先行するトランザクション１５２の出力を指し示し、それによってトランザクションをリンクする。
【0022】
各ブロック１５１はまた、ブロック１５１への順番を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。各トランザクション１５２（コインベーストランザクション以外）は、トランザクションのシーケンスへの順序を定義するために、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであった発生ブロック（Ｇｂ：genesis block）１５３までずっと戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなく発生ブロック１５３を指し示していた。
【0023】
ブロックチェーンノード１０４の各々は、トランザクション１５２を他のブロックチェーンノード１０４にフォワードし、それによってトランザクション１５２をネットワーク１０６全体に伝搬させるように構成される。各ブロックチェーンノード１０４は、ブロック１５１を作成し、同じブロックチェーン１５０のそれぞれのコピーをそれらのそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待っているトランザクション１５２の順序付きセット（または「プール」）１５４を維持する。順序付きプール１５４は、「メムプール（ｍｅｍｐｏｏｌ）」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図していない。これは、ノード１０４が有効であるとして受け入れたトランザクションの順序付きセットを指し、それに対して、ノード１０４は、同じ出力を使用しようとする他のトランザクションを受け入れないように義務付けられている。
【0024】
所与の現在のトランザクション１５２ｊにおいて、その入力（または各入力）は、トランザクションのシーケンスにおける先行するトランザクション１５２ｉの出力を参照するポインタを含み、この出力が現在のトランザクション１５２ｊにおいて償還または「使用」されるべきであることを指定する。一般に、先行するトランザクションは、順序付きセット１５４または任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２ｉは、現在のトランザクションが有効となるためには存在および妥当性確認される必要があるが、先行するトランザクション１５２ｉは、現在のトランザクション１５２ｊが作成されるときまたはネットワーク１０６に送信されるときに必ずしも存在する必要はない。したがって、本明細書における「先行する（preceding）」は、ポインタによってリンクされた論理シーケンスにおける先行するものを指し、必ずしも時間シーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション１５２ｉ、１５２ｊが順不同に作成または送信されることを必ずしも除外するものではない（オーファントランザクションに関する以下の説明を参照）。先行するトランザクション１５２ｉは、同様に、先のトランザクション（antecedent transaction）または先行したトランザクション（predecessor transaction）とも呼ばれる。
【0025】
現在のトランザクション１５２ｊの入力はまた、入力認可、例えば、先行するトランザクション１５２ｉの出力がロックされている先のユーザ１０３ａの署名を含む。次に、現在のトランザクション１５２ｊの出力は、新しいユーザまたはエンティティ１０３ｂに暗号的にロックされ得る。したがって、現在のトランザクション１５２ｊは、先行するトランザクション１５２ｉの入力において定義された額を、現在のトランザクション１５２ｊの出力において定義されたように、新しいユーザまたはエンティティ１０３ｂに転送することができる。場合によっては、トランザクション１５２は、複数のユーザまたはエンティティ（そのうちの１つは残り（change）を与えるために元のユーザまたはエンティティ１０３ａであり得る）間で入力額を分割するために複数の出力を有し得る。場合によっては、トランザクションはまた、１つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの１つまたは複数の出力に再分配するために複数の入力を有することができる。
【0026】
ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは組織などの当事者１０３が（手動でまたは当事者によって採用される自動プロセスによって）新しいトランザクション１５２ｊを制定することを望むとき、制定を行う当事者は、新しいトランザクションをそのコンピュータ端末１０２から受信者に送信する。制定を行う当事者または受信者は、最終的に、このトランザクションをネットワーク１０６のブロックチェーンノード１０４の１つまたは複数（これは、現在では、典型的にはサーバまたはデータセンタであるが、原則として他のユーザ端末であってもよい）に送信する。新しいトランザクション１５２ｊを制定する当事者１０３がトランザクションをブロックチェーンノード１０４の１つまたは複数に直接送信し、いくつかの例では、受信者に送信しないことも除外されない。トランザクションを受信するブロックチェーンノード１０４は、ブロックチェーンノード１０４の各々で適用されるブロックチェーンノードプロトコルにしたがって、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付きシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにブロックチェーンノード１０４に求める。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション１５２ｊの入力に含まれる当事者１０３の暗号署名または他の認可が、新しいトランザクションが割り当てる先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名または他の認可が、新しいトランザクションの入力がリンクされている前のトランザクション１５２ｉの出力をロック解除することを少なくともチェックすることを含む。条件は、先行するトランザクション１５２ｉの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替的に、単にブロックチェーンノードプロトコルのみによって固定されてもよく、またはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、ブロックチェーンノード１０４は、それをブロックチェーンネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードする。これらの他のブロックチェーンノード１０４は、同じブロックチェーンノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはブロックチェーンノード１０４のネットワーク全体に伝搬される。
【0027】
出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が割り当てられる（例えば、使用される）かどうかの定義は、それがブロックチェーンノードプロトコルにしたがって別の前方のトランザクション１５２ｊの入力によって有効に償還されたかどうかである。トランザクションが有効であるための別の条件は、それが償還しようとする先行するトランザクション１５２ｉの出力が、別のトランザクションによってまだ償還されていないことである。この場合も同様に、有効ではない場合、トランザクション１５２ｊは、（無効としてフラグ付けされ、警告のために伝搬されない限り）伝搬されることも、ブロックチェーン１５０内に記録されることもない。これは、トランザクタ（transactor）が同じトランザクションの出力を複数回割り当てようとする二重支出を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重支出を防止する。ここでも、トランザクション順序が定義されているので、アカウント残高は常に単一の定義された状態にある。
【0028】
トランザクションを妥当性確認することに加えて、ブロックチェーンノード１０４はまた、「プルーフオブワーク」によって支持される、一般にマイニングと呼ばれるプロセスにおいてトランザクションのブロックを最初に作成しようと競い合う。ブロックチェーンノード１０４において、新しいトランザクションが、ブロックチェーン１５０上に記録されたブロック１５１内にまだ現れていない有効なトランザクションの順序付きプール１５４に追加される。次いで、ブロックチェーンノードは、暗号パズルを解こうとすることで、トランザクションの順序付きセット１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てようと競い合う。典型的には、これは、ナンスが保留中のトランザクションの順序付きプール１５４の表現と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。例えば、所定の条件とは、ハッシュの出力が特定の所定の数の先行ゼロを有することであり得る。これは、プルーフオブワークパズルの１つの特定のタイプにすぎず、他のタイプが除外されないことに留意されたい。ハッシュ関数の特性は、その入力に対して予測不可能な出力を持つことである。したがって、この探索は、総当たりでしか実行することができないので、パズルを解こうとしている各ブロックチェーンノード１０４でかなりの量の処理リソースを消費する。
【0029】
最初にパズルを解いたブロックチェーンノード１０４は、これをネットワーク１０６に公表し、後にネットワーク内の他のブロックチェーンノード１０４によって容易にチェックすることができるその解を証明として提供する（ハッシュの解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。この最初のブロックチェーンノード１０４は、ブロックを、このブロックを受け入れる他のノードのしきい値コンセンサスに伝搬し、プロトコルルールを実施する。次いで、トランザクション１５４の順序付きセットは、ブロックチェーンノード１０４の各々によってブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークの解を作成するために必要とされる、例えばハッシュの形態の、かなりの量の労力は、ブロックチェーンプロトコルのルールに従うという最初のノード１０４の意図を示す。そのようなルールは、別名二重支出としても知られている、前に妥当性確認されたトランザクションと同じ出力の割当てを行う場合、トランザクションを有効として受け入れないことを含む。ブロック１５１は、一旦作成されると、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々において認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１に順番を付与する。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。
【0030】
任意の所与の時間にパズルを解こうと競い合う異なるブロックチェーンノード１０４は、それらがいつ解を探索し始めたかまたはトランザクションが受信された順序に応じて、任意の所与の時間に、まだ公開されていないトランザクション１５４のプールの異なるスナップショットに基づいてそれを行っていてもよいことに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎにどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール１５４が更新される。次いで、ブロックチェーンノード１０４は、新たに定義された、公開されていないトランザクション１５４の順序付きプールからブロックを作成しようと競い合い続け、以下同様である。２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解がノード１０４間で伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどちらのプロングが最も長く成長しても、確定的なブロックチェーン１５０となる。同じトランザクションが両方のフォークに現れるので、これがネットワークのユーザまたはエージェントに影響を与えないことに留意されたい。
【0031】
ビットコインブロックチェーン（およびほとんどの他のブロックチェーン）によれば、新しいブロック１０４の構築に成功したノードには、（あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を転送するエージェント間またはユーザ間のトランザクションとは対照的に）追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、受け入れられた追加の額のデジタル資産を新たに割り当てる能力が与えられる。この特別なタイプのトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション（initiation transaction）」または「生成トランザクジョン（generation transaction）」と呼ばれることもある。これは典型的に、新しいブロック１５１ｎの最初のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードが、この特別なトランザクションが後に償還されることを可能にするプロトコルルールに従うという意図を示す。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還され得る前に、満期期間、例えば１００個のブロックを必要とし得る。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが公開されたブロック１５１ｎを作成したブロックチェーンノード１０４にさらに報酬を与えるために、その出力のうちの１つにおいて追加のトランザクション手数料を指定する。この手数料は通常「トランザクション手数料」と呼ばれ、以下に説明する。
【0032】
トランザクション妥当性確認および公開に関与するリソースに起因して、典型的には、ブロックチェーンノード１０４の少なくとも各々は、１つまたは複数の物理サーバユニットを含むサーバの形態をとるか、さらにはデータセンタ全体の形態をとる。しかしながら、原則として、任意の所与のブロックチェーンノード１０４は、ユーザ端末または互いにネットワーク化されたユーザ端末のグループの形態をとることができる。
【0033】
各ブロックチェーンノード１０４のメモリは、そのそれぞれの１つまたは複数の役割を実行し、ブロックチェーンノードプロトコルにしたがってトランザクション１５２を処理するために、ブロックチェーンノード１０４の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード１０４に帰する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーション層、またはオペレーティングシステム層もしくはプロトコル層などの下位層、またはこれらの任意の組合せにおける１つまたは複数のアプリケーションにおいて実装され得る。
【0034】
消費ユーザの役割を果たす複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらのユーザは、ブロックチェーンネットワーク１０６と対話し得るが、トランザクションの妥当性確認にもブロックの構築にも参加しない。これらのユーザまたはエージェント１０３のうちのいくつかは、トランザクションの送信者および受信者として動作し得る。他のユーザは、必ずしも送信者または受信者として動作することなくブロックチェーン１５０と対話し得る。例えば、いくつかの当事者は、（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）ブロックチェーン１５０のコピーを記憶するストレージエンティティとして動作し得る。
【0035】
当事者１０３のうちのいくつかまたはすべては、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上にオーバーレイされたネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれことが多い）は、ブロックチェーンネットワーク１０６を含むシステムの一部であるといえるが、これらのユーザは、ブロックチェーンノードに求められる役割を果たさないので、ブロックチェーンノード１０４ではない。代わりに、各当事者１０３はブロックチェーンネットワーク１０６と対話してもよく、ブロックチェーンノード１０６に接続する（すなわち通信する）ことでブロックチェーン１５０を利用し得る。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。そのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２ははるかに多く存在し、システム１００に参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと呼ばれ、第２の当事者１０３ｂはボブと呼ばれるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。
【0036】
各当事者１０３のコンピュータ機器１０２は、１つまたは複数のプロセッサ、例えば、１つまたは複数のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および／またはＦＰＧＡを含むそれぞれの処理装置を備える。各当事者１０３のコンピュータ機器１０２は、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに備える。このメモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。各当事者１０３のコンピュータ機器１０２上のメモリは、処理装置上で実行されるように構成された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の当事者１０３に帰する任意のアクションは、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各当事者１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の当事者１０３のコンピュータ機器１０２はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの１つまたは複数の他のネットワーク化されたリソースを含み得る。
【0037】
クライアントアプリケーション１０５は、最初に、１つまたは複数の適切なコンピュータ可読記憶媒体上で任意の所与の当事者１０３のコンピュータ機器１０２に提供され得、例えば、サーバからダウンロードされ得るか、またはリムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、ＣＤもしくはＤＶＤ ＲＯＭなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブル記憶デバイス上で提供され得る。
【0038】
クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これは２つの主要な機能を有する。これらのうちの１つは、それぞれの当事者１０３が、トランザクション１５２を作成し、認可し（例えば署名し）、１つまたは複数のビットコインノード１０４に送信することを可能にして、トランザクション１５２を、ブロックチェーンノード１０４のネットワーク全体に伝搬させ、それによってブロックチェーン１５０に含まれるようにすることである。もう１つは、それぞれの当事者に、その当事者が現在所有しているデジタル資産の額を報告することである。出力ベースのシステムでは、この第２の機能は、当該当事者に属するブロックチェーン１５０全体に散在している様々なトランザクション１５２の出力において定義された額を照合することを含む。
【0039】
様々なクライアント機能は、所与のクライアントアプリケーション１０５に統合されるものとして説明され得るが、必ずしもこれに限定されず、代わりに、本明細書で説明される任意のクライアント機能が、例えば、ＡＰＩを介してインターフェースする、または一方が他方へのプラグインである２つ以上の別個のアプリケーション一式において実装され得ることに留意されたい。より一般的には、クライアント機能は、アプリケーション層もしくはオペレーティングシステムなどの下位層、またはこれらの任意の組合せにおいて実装され得る。以下では、クライアントアプリケーション１０５に関して説明するが、これに限定されないことが理解されよう。
【0040】
各コンピュータ機器１０２上のクライアントアプリケーションまたはソフトウェア１０５のインスタンスは、ネットワーク１０６のブロックチェーンノード１０４のうちの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能はトランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５はまた、それぞれの当事者１０３が受信者である任意のトランザクションについてブロックチェーン１５０にクエリを行うためにブロックチェーンノード１０４にコンタクトすることができる（または、実施形態では、ブロックチェーン１５０は、部分的にその公開性（public visibility）を通じてトランザクションにおける信頼を提供する公共施設であるので、実際にブロックチェーン１５０における他の当事者のトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルにしたがってトランザクション１５２を定式化し、送信するように構成される。上述したように、各ブロックチェーンノード１０４は、ブロックチェーンノードプロトコルにしたがってトランザクション１５２を妥当性確認し、トランザクション１５２をフォワードして、それらをブロックチェーンネットワーク１０６全体に伝搬するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルに従い（go with）、一緒に所与のトランザクションモデルを実装する。ブロックチェーン１５０内のすべてのトランザクション１５２に対して同じトランザクションプロトコルが使用される。ネットワーク１０６内のすべてのノード１０４によって同じノードプロトコルが使用される。
【0041】
所与の当事者１０３、例えばアリスが、ブロックチェーン１５０に含まれるべき新しいトランザクション１５２ｊを送信することを望むとき、アリスは、関連トランザクションプロトコルにしたがって（アリスのクライアントアプリケーション１０５内のウォレット機能を使用して）新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション１０５から、アリスが接続されている１つまたは複数のブロックチェーンノード１０４にトランザクション１５２を送信する。例えば、これは、アリスのコンピュータ１０２に最良に接続されたブロックチェーンノード１０４であり得る。任意の所与のブロックチェーンノード１０４は、新しいトランザクション１５２ｊを受信すると、ブロックチェーンノードプロトコルおよびそのそれぞれの役割にしたがってそれを処理する。これは、新たに受信されたトランザクション１５２ｊが「有効」であるための特定の条件を満たすかを最初にチェックすることを含み、その例については、以下でより詳細に説明する。いくつかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替的に、条件は、単にノードプロトコルの組込み特徴であってもよく、またはスクリプトとノードプロトコルとの組合せによって定義されてもよい。
【0042】
新たに受信されたトランザクション１５２ｊが、有効であるとみなされるためのテストにパスすることを条件として（すなわち、それが「妥当性確認される」ことを条件として）、トランザクション１５２ｊを受信する任意のブロックチェーンノード１０４は、そのブロックチェーンノード１０４において維持されるトランザクション１５４の順序付きセットに新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２ｊを受信する任意のブロックチェーンノード１０４は、妥当性確認済みトランザクション１５２をネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４へと前方に伝搬する。各ブロックチェーンノード１０４は同じプロトコルを適用するので、トランザクション１５２ｊが有効であると仮定すると、これは、ネットワーク１０６全体にわたってすぐに伝搬されることを意味する。
【0043】
所与のブロックチェーンノード１０４において維持される保留中のトランザクション１５４の順序付きプールに承認されると、そのブロックチェーンノード１０４は、新しいトランザクション１５２を含むそれぞれのプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のブロックチェーンノード１０４が、トランザクション１５４の異なるプールに基づいてパズルを解こうと試みている可能性があるが、どのノードでも最初に解いたものが、最新のブロック１５１に含まれるトランザクションのセットを定義することを想起されたい。最終的に、ブロックチェーンノード１０４は、アリスのトランザクション１５２ｊを含む順序付きプール１５４の一部についてパズルを解くことになる）。新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは普遍的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、先のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。
【0044】
異なるブロックチェーンノード１０４は、最初、所与のトランザクションの異なるインスタンスを受信し得るので、１つのインスタンスが新しいブロック１５１において公開される（この時点で、公開されたインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード１０４が同意している）までは、どのインスタンスが「有効」であるかについて相反する見解を有する。ブロックチェーンノード１０４が１つのインスタンスを有効として受け入れ、次いで、別のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、そのブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（すなわち、ブロック１５１で公開されていないもの）を破棄する（すなわち、無効として扱う）。
【0045】
いくつかのブロックチェーンネットワークによって動作される代替タイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと呼ばれ得る。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー（「ポジション」とも呼ばれる）を使用して順序付けられる。この値は、送信者によってその暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。加えて、トランザクションにおけるオプションのデータフィールドも署名することができる。このデータフィールドは、例えば、前のトランザクションＩＤがデータフィールドに含まれている場合、前のトランザクションを指し示し得る。
【0046】
ＵＴＸＯベースのモデル
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されない。例示的なＵＴＸＯベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実装され得ることに留意されたい。
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されない。例示的なＵＴＸＯベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実装され得ることに留意されたい。
【0047】
ＵＴＸＯベースのモデルでは、各トランザクション（「Ｔｘ」）１５２は、１つまたは複数の入力２０２および１つまたは複数の出力２０３を含むデータ構造を含む。各出力２０３は、未使用トランザクション出力（ＵＴＸＯ）を含み得、これは、（ＵＴＸＯがまだ償還されていない場合）別の新しいトランザクションの入力２０２のソースとして使用され得る。ＵＴＸＯは、デジタル資産の額を指定する値を含む。これは、分散型台帳上のトークンの設定数を表す。ＵＴＸＯはまた、他の情報の中でも、元となるトランザクションのトランザクションＩＤを含み得る。トランザクションデータ構造は、入力フィールド（複数可）２０２および出力フィールド（複数可）２０３のサイズを示すインジケータを含み得るヘッダ２０１も含み得る。ヘッダ２０１はまた、トランザクションのＩＤを含み得る。実施形態では、トランザクションＩＤは、（トランザクションＩＤ自体を除く）トランザクションデータのハッシュであり、ノード１０４にサブミットされる生のトランザクション１５２のヘッダ２０１に記憶される。
【0048】
アリス１０３ａが、当該デジタル資産の額をボブ１０３ｂに転送するトランザクション１５２ｊを作成することを望むとする。図２では、アリスの新しいトランザクション１５２ｊは「Ｔｘ1」とラベル付けされている。これは、シーケンス内の先行するトランザクション１５２ｉの出力２０３においてアリスにロックされたデジタル資産の額を取り、これのうちの少なくとも一部をボブに転送する。先行するトランザクション１５２ｉは、図２では「Ｔｘ0」とラベル付けされている。Ｔｘ0およびＴｘ1は、単なる任意のラベルである。それらは、Ｔｘ0がブロックチェーン１５１内の最初のトランザクションであること、またはＴｘ1がプール１５４内のすぐ次のトランザクションであることを必ずしも意味するものではない。Ｔｘ1は、アリスにロックされた未使用の出力２０３を依然として有する任意の先行する（すなわち先の）トランザクションを指し示すことができる。
【0049】
先行するトランザクションＴｘ0は、アリスが新しいトランザクションＴｘ1を作成した時点では、または少なくともアリスがそれをネットワーク１０６に送信する時点までには、すでに妥当性確認されブロックチェーン１５０のブロック１５１に含まれている可能性がある。それは、その時点でブロック１５１のうちの１つにすでに含まれていてもよいし、順序付きセット１５４で依然として待機していてもよく、この場合、すぐに新しいブロック１５１に含まれることになる。代替的に、Ｔｘ0およびＴｘ1を作成してネットワーク１０６に一緒に送信することもできるし、ノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合には、Ｔｘ0をＴｘ1の後に送信することさえもできる。トランザクションのシーケンスの文脈において本明細書で使用される「先行する」および「後続の」という用語は、トランザクション内で指定されているトランザクションポインタ（どのトランザクションがどの他のトランザクションを指し示すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、同様に、「先行するもの（predecessor）」および「後続するもの（successor）」、または「先の」および「後の」、「親」および「子」などと置き換えられ得る。これは、それらの作成、ネットワーク１０６への送信、または任意の所与のブロックチェーンノード１０４への到着の順序を必ずしも意味するものではない。それにもかかわらず、先行するトランザクション（先のトランザクションまたは「親」）を指し示す後続するトランザクション（後のトランザクションまたは「子」）は、親トランザクションが妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード１０４に到着する子は、オーファンとみなされる。それは、ノードプロトコルおよび／またはノード挙動に応じて、親を待つために特定の時間バッファされるかまたは破棄され得る。
【0050】
先行するトランザクションＴｘ0の１つまたは複数の出力２０３のうちの１つは、本明細書ではＵＴＸＯ0とラベル付けされた特定のＵＴＸＯを含む。各ＵＴＸＯは、ＵＴＸＯによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを含み、ロックスクリプトは、後続のトランザクションが妥当性確認され、したがってＵＴＸＯが正常に償還されるために、後続のトランザクションの入力２０２内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者（それが含まれるトランザクションの受益者）にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を含むロック解除条件を定義する。
【0051】
ロックスクリプト（通称scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの一部分である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「スクリプト（Script）」（大文字Ｓ）と呼ばれる。ロックスクリプトは、トランザクション出力２０３を使用するためにどの情報が必要とされるか、例えばアリスの署名の必要性、を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト（通称scriptSig）は、ロックスクリプト基準を満たすのに必要な情報を提供するドメイン固有言語で書かれたコードの一部分である。例えば、それはボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力２０２に現れる。
【0052】
つまり、図示の例では、Ｔｘ0の出力２０３内のＵＴＸＯ0は、ＵＴＸＯ0が償還されるために（厳密には、ＵＴＸＯ0を償還しようとする後続のトランザクションが有効となるために）アリスの署名Ｓｉｇ ＰAを必要とするロックスクリプト[Checksig PA]を含む。[Checksig PA]は、アリスの公開鍵－秘密鍵ペアの公開鍵ＰAの表現（すなわち、ハッシュ）を含む。Ｔｘ1の入力２０２は、（例えば、実施形態ではトランザクションＴｘ0全体のハッシュであるそのトランザクションＩＤ、ＴｘＩＤ0によって）Ｔｘ1を指し示すポインタを含む。Ｔｘ1の入力２０２は、Ｔｘ0の任意の他の可能な出力の中からＵＴＸＯ0を識別するために、Ｔｘ0内のＵＴＸＯ0を識別するインデックスを含む。Ｔｘ1の入力２０２は、アリスが鍵ペアのアリスの秘密鍵をデータの所定の部分（暗号では「メッセージ」と呼ばれることもある）に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにアリスによって署名される必要があるデータ（または「メッセージ」）は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
【0053】
新しいトランザクションＴｘ1がブロックチェーンノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトで定義されている条件（この条件は１つまたは複数の基準を含み得る）を満たすかどうかをチェックすることを含む。実施形態では、これは２つのスクリプトを連結することを含む：
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<…>」はデータをスタックに置くことを意味し、「[…]」はロックスクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されるとき、スクリプトは、Ｔｘ0の出力内のロックスクリプトに含まれるようなアリスの公開鍵ＰAを使用して、Ｔｘ1の入力内のロック解除スクリプトが、データの予想される部分に署名したアリスの署名を含むことを認証する。データの予想される部分自体（「メッセージ」）はまた、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータは、Ｔｘ1の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要はない）。
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<…>」はデータをスタックに置くことを意味し、「[…]」はロックスクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されるとき、スクリプトは、Ｔｘ0の出力内のロックスクリプトに含まれるようなアリスの公開鍵ＰAを使用して、Ｔｘ1の入力内のロック解除スクリプトが、データの予想される部分に署名したアリスの署名を含むことを認証する。データの予想される部分自体（「メッセージ」）はまた、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータは、Ｔｘ1の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要はない）。
【0054】
公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の秘密鍵を使用してメッセージに署名した場合、アリスの公開鍵および平文のメッセージが与えられると、ノード１０４などの別のエンティティは、メッセージがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができる。したがって、データの特定の部分またはトランザクションの一部などに署名することへの本明細書におけるいかなる言及も、実施形態では、データのその部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
【0055】
Ｔｘ1内のロック解除スクリプトが、Ｔｘ0のロックスクリプト内で指定されている１つまたは複数の条件を満たす場合（つまり、図示の例では、アリスの署名がＴｘ1内で提供され、認証された場合）、ブロックチェーンノード１０４は、Ｔｘ1が有効であるとみなす。これは、ブロックチェーンノード１０４が、保留中のトランザクション１５４の順序付きプールにＴｘ1を追加することとなることを意味する。ブロックチェーンノード１０４はまた、トランザクションＴｘ1をネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードして、トランザクションＴｘ1がネットワーク１０６全体に伝搬されるようにする。Ｔｘ1が妥当性確認されてブロックチェーン１５０に含まれると、これは、Ｔｘ0からのＵＴＸＯ0を使用済みとして定義する。Ｔｘ1は、未使用トランザクション出力２０３を使用する場合にのみ有効になり得ることに留意されたい。別のトランザクション１５２によってすでに使用された出力を使用しようとする場合、Ｔｘ1は、他のすべての条件が満たされたとしても無効になる。したがって、ブロックチェーンノード１０４はまた、先行するトランザクションＴｘ0内の参照されたＵＴＸＯがすでに使用済みであるかどうか（すなわち、それが別の有効なトランザクションへの有効な入力をすでに形成したかどうか）をチェックする必要がある。これは、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である１つの理由である。実際には、所与のブロックチェーンノード１０４は、どのトランザクション１５２内のどのＵＴＸＯ２０３が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、ＵＴＸＯが使用されたかどうかを定義するものは、ブロックチェーン１５０内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。
【0056】
所与のトランザクション１５２のすべての出力２０３において指定された総額が、そのすべての入力２０２によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効性の別の根拠となる。したがって、そのようなトランザクションは、伝搬されることも、ブロック１５１に含まれることもないであろう。
【0057】
ＵＴＸＯベースのトランザクションモデルでは、所与のＵＴＸＯが全体として使用される必要があることに留意されたい。ＵＴＸＯにおいて使用済みとして定義された額の一部は、別の一部が使用されていても、「後に残す」ことはできない。しかしながら、次のトランザクションの複数の出力間でＵＴＸＯからの額を分割することはできる。例えば、Ｔｘ0内のＵＴＸＯ0において定義された額を、Ｔｘ1内の複数のＵＴＸＯ間で分割することができる。したがって、アリスが、ＵＴＸＯ0において定義された額のすべてをボブに与えたくない場合、アリスは、リマインダを使用して、Ｔｘ1の第２の出力において自分自身に残りを与えるか、または別の当事者に支払うことができる。
【0058】
実際には、アリスはまた、通常、アリスのトランザクション１０４をブロック１５１に成功裏に含めるビットコインノード１０４に対する手数料を含める必要がある。アリスがそのような手数料を含めない場合、Ｔｘ0は、ブロックチェーンノード１０４によって拒否され得、したがって、技術的に有効であっても、伝搬されず、ブロックチェーン１５０に含まれない可能性がある（ノードプロトコルは、ブロックチェーンノード１０４が望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、トランザクション手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の任意の差が、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、ＵＴＸＯ0へのポインタがＴｘ1への唯一の入力であり、Ｔｘ1は唯一の出力ＵＴＸＯ1を有するとする。ＵＴＸＯ0において指定されたデジタル資産の額がＵＴＸＯ1において指定された額よりも大きい場合、その差分は、ＵＴＸＯ1を含むブロックを生成するためのプルーフオブワーク競争に勝つノード１０４によって割り当てられ得る。しかしながら、代替的にまたは追加的に、トランザクション手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることは必ずしも除外されない。
【0059】
アリスおよびボブのデジタル資産は、ブロックチェーン１５０内のどこかで任意のトランザクション１５２においてそれらにロックされたＵＴＸＯから構成される。したがって、典型的には、所与の当事者１０３の資産は、ブロックチェーン１５０全体にわたる様々なトランザクション１５２のＵＴＸＯ全体に散在している。ブロックチェーン１５０内のどこにも、所与の当事者１０３の総残高を定義する数字は記憶されない。クライアントアプリケーション１０５におけるウォレット機能の役割は、それぞれの当事者にロックされ、別の前方のトランザクションでまだ使用されていない様々なＵＴＸＯのすべての値を一緒に照合することである。これは、ビットコインノード１０４のいずれかに記憶されたブロックチェーン１５０のコピーにクエリを行うことによって行うことができる。
【0060】
スクリプトコードは、多くの場合、概略的に（すなわち、正確な言語を使用せずに）表されることに留意されたい。例えば、特定の機能を表すためにオペレーションコード（オペコード）が使用され得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。例として、ＯＰ＿ＲＥＴＵＲＮは、ロックスクリプトの最初にＯＰ＿ＦＡＬＳＥが先行するときに、トランザクション内にデータを記憶することができ、それによってデータをブロックチェーン１５０内に不変的に記録することができる、トランザクションの使用不可能な出力を作成するスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに記憶することが望まれる文書を含み得る。
【0061】
典型的には、トランザクションの入力は、公開鍵ＰAに対応するデジタル署名を含む。実施形態において、これは、楕円曲線ｓｅｃｐ２５６ｋ１を使用するＥＣＤＳＡに基づく。デジタル署名は、データの特定の一部分に署名する。いくつかの実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の一部または全部に署名する。署名された出力の特定の部分は、ＳＩＧＨＡＳＨフラグに依存する。ＳＩＧＨＡＳＨフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる４バイトコードである（したがって、署名時に固定される）。
【0062】
ロックスクリプトは、典型的には、それぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には、それが対応する署名を供給するという事実を指して「scriptSig」と呼ばれることがある。しかしながら、より一般的には、ＵＴＸＯが償還されるための条件が署名を認証することを含むことは、ブロックチェーン１５０のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、任意の１つまたは複数の条件を定義することができる。したがって、より一般的な用語「ロックスクリプト」および「ロック解除スクリプト」が好まれ得る。
【0063】
図１に示すように、アリスおよびボブのコンピュータ機器１０２ａ、１２０ｂの各々上のクライアントアプリケーションは、それぞれ、追加の通信機能を含み得る。この追加の機能により、（いずれかの当事者または第三者の扇動で）アリス１０３ａは、ボブ１０３ｂと別個のサイドチャネル１０７を確立することができる。サイドチャネル１０７は、ブロックチェーンネットワークとは別でのデータの交換を可能にする。そこのような通信は、「オフチェーン」通信と呼ばれることがある。例えば、これは、当事者の一方がトランザクションをネットワーク１０６にブロードキャストすることを選択するまで、トランザクションが（まだ）ブロックチェーンネットワーク１０６に登録されることなく、またはチェーン１５０上に進むことなく、アリスとボブとの間でトランザクション１５２を交換するために使用され得る。このようにトランザクションを共有することは、「トランザクションテンプレート」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる１つまたは複数の入力および／または出力を欠いていてもよい。代替的にまたは追加的に、サイドチャネル３０１は、鍵、交渉された額または条件、データコンテンツなどの任意の他のトランザクション関連データを交換するために使用され得る。
【0064】
サイドチャネル１０７は、ブロックチェーンネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立され得る。代替的にまたは追加的に、サイドチャネル１０７は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはアリスのデバイス１０２ａとボブのデバイス１０２ｂとの間の直接のワイヤードまたはワイヤレスリンクを介して確立され得る。一般に、本明細書のどこでも、参照されるサイドチャネル１０７は、「オフチェーン」すなわちブロックチェーンネットワーク１０６とは別でデータを交換するための１つまたは複数のネットワーキング技術または通信媒体を介した任意の１つまたは複数のリンクを含み得る。２つ以上のリンクが使用される場合、全体としてのオフチェーンリンクの束または集合は、サイドチャネル１０７と呼ばれ得る。したがって、アリスおよびボブがサイドチャネル１０７上で情報またはデータの特定の部分などを交換すると言われている場合、これは、これらのデータの部分のすべてが全く同じリンクまたは同じタイプのネットワーク上で送信されなければならないことを必ずしも意味するものではないことに留意されたい。
【0065】
オンチェーンの消費税メカニズム
消費税は、売上税だけでなく、税関、物品税などの税である。これらのタイプの税は、商品またはサービスの購入に直接結びついている。これらの消費税のうち、以下の例は、売上税およびＶＡＴ（付加価値税）の多段階消費税システムに焦点を当てている。しかしながら、これは、本明細書に開示されるメカニズムが適用可能である用途の範囲を必ずしも限定するものではない。
消費税は、売上税だけでなく、税関、物品税などの税である。これらのタイプの税は、商品またはサービスの購入に直接結びついている。これらの消費税のうち、以下の例は、売上税およびＶＡＴ（付加価値税）の多段階消費税システムに焦点を当てている。しかしながら、これは、本明細書に開示されるメカニズムが適用可能である用途の範囲を必ずしも限定するものではない。
【0066】
売上税は、最終エンドユーザへの商品の販売に課される消費税を指す。売上税が適用される管轄区域では、この税は、（小売店から顧客へのトランザクションが通常、最終エンドユーザへの販売を表すと仮定して）小売店で販売されるすべてのアイテムに対して支払われる。
【0067】
仲介業（例えば、卸売業者から小売業者）の場合、商品には課税されない。これらの仲介業が売上税を支払わないようにするためには、「中間事業者であることを証明する」必要がある。この証明は、通常、適切な税務当局によって与えられる「再販証明書（resale certificate）」の形態である。
【0068】
中間の買い手は、購入時に、売り手に証明書またはそのＩＤ番号などのそのような証明を、典型的にはアイテムが再販用であるというステートメントと共に提供することを求められる。それ以外の場合、購入者（最終消費者であると仮定される）と仮定して、そのような証明のない購入者に販売された各アイテムに対して課税される。
【0069】
図３は、農家の綿から顧客のドレスになるまでの購入の例示的なチェーンにおいて、売上税がどのように運用されるかの例を示す。表は、いくつかの例示的な購入額についての売上税計算を示す。
【0070】
一方、ＶＡＴの重要な特徴は、参加者が対象物に付加した価値に対してのみ税を支払うことである。例として、ＶＡＴ率が５％であり、アイテムを￡１００で購入して￡１５０で販売する場合、参加者が税務当局に支払う義務があるＶＡＴは￡５０の５％である。商品に付加される価値は、￡１５０－￡１００＝￡５０であることに留意されたい。
【0071】
これを容易にするために、買い手－売り手は、自身が支払うＶＡＴと、自身が受け取るＶＡＴとを追跡することが予想される。次いで、買い手－売り手は、定められた時期（毎年、四半期ごとなど）に提出する納税申告書にこの情報を記載し、税務当局は、それに応じて買い手－売り手に還付する。
【0072】
図４は、販売移行シーケンスシステムを通って綿が移動し、最終的に顧客によって購入されるドレスとなる例を用いて、どのように商品／サービスに価値が付加されるかを示す。表は、いくつかの例示的な購入額についてのＶＡＴ計算を示す。
【0073】
従来、農家、工場、または小売業者などの買い手－売り手は、支払われるべきＶＡＴなどの消費税が還付されるようになるまで、管轄区域に応じて、３ヶ月、６ヶ月、または１２ヶ月などの所定の期間待たなければならない。消費税のより迅速な還付を可能にする技術的解決策を見つけることが望ましいであろう。本開示は、最大で、ＶＡＴなどの消費税のリアルタイム還付を可能にするブロックチェーンベースのメカニズムを提供する。代替または追加の利点として、ブロックチェーンベースの解決策を使用して、売上税またはＶＡＴなどの消費税の徴収および／または還付におけるアカウンタビリティおよび／またはセキュリティの向上を提供することもできる。
【0074】
例として図３、図４および図６に示されるように、購入のチェーンは、１つまたは複数の商品および／またはサービスの買い手かつ売り手である１つまたは複数の買い手－売り手を含み得る。チェーン内の各買い手および／または売り手は、本明細書ではＢ＿Ｓiとラベル付けされ得、ｉ＝０…ｎである。例示として図３および図４では、ｎ＝３であり、図６では、ｉ＝４であるが、これらは単なる例であることは理解されよう。Ｂ＿Ｓ0は売り手のみであり、ｎは買い手の数であり、Ｂ＿Ｓnは買い手のみ（最終顧客）である。Ｂ＿Ｓ1からＢ＿Ｓn-1の各々は、買い手－売り手、すなわち買い手かつ売り手である。買い手－売り手Ｂ＿Ｓi+1は、チェーン内の先行する売り手Ｂ＿Ｓiから１つまたは複数の商品および／またはサービスを購入し、１つまたは複数の商品および／またはサービスを、その先の買い手Ｂ＿Ｓi+2へと販売する。そのため、買い手－売り手は、購入時に消費税を購入する必要がない（売上税の場合）か、または消費税の還付を受ける権利がある（ＶＡＴの場合）。どの種類の消費税が適用されるかは、管轄区域に依存する。
【0075】
本開示によれば、買い手Ｂ＿Ｓi+1は、（ＶＡＴであれ売上税であれ）消費税を売り手Ｂ＿Ｓiに支払い、売り手は、買い手が消費税を取り戻す権利があると仮定すれば買い手が消費税を取り戻すことを可能にするが、そうでなければ税務当局（ＴＡ）が税を請求することを可能にするトランザクションにおいて、チェーン上で消費税をエスクローする。ＶＡＴの場合、これは、いずれにせよＶＡＴの仕組みを反映するが、税務当局の所定の決算期の終了を待つ必要なく、買い手－売り手へのＶＡＴのより迅速な還付を可能にする。売上税の場合、税を支払い、その後直ちに還付されることで、ブロックチェーンを使用して、買い手が売上税を支払っていないという事実を不変に文書化することができ、したがって、不正な当事者が、権利がないときに売上税を免れることに対するセキュリティが向上する。
【0076】
図５は、上記を実装するためのブロックチェーンベースのメカニズムにおいて使用され得る例示的なブロックチェーントランザクション１５２Ｔを示す。単に便宜上のラベルとして、そのような役割のトランザクション１５２Ｔは、本明細書では「ターゲット」トランザクションまたは「第１の」トランザクションと呼ばれ得る。出力ベースのトランザクションモデルでは、ターゲットトランザクション１５２Ｔは、ファンディングトランザクション（または「第０の」トランザクション）１５２Ｆの出力を指し示す少なくとも１つの入力２０２を含む。
【0077】
ターゲットトランザクション１５２Ｔの入力は、ファンディングトランザクション１５２Ｆの、指し示された出力のロックスクリプトをロック解除するロック解除スクリプトを含み、したがって、ターゲットトランザクション１５２Ｔにおいてチェーン上で消費税をエスクローするために必要な資金を提供する。ターゲットトランザクション１５２Ｔは、エスクローされた資金をロック解除するための条件を指定するロックスクリプトを含む少なくとも１つの出力２０３0も含む。この出力２０３0のロックスクリプトは、ターゲットトランザクション１５２Ｔの出力２０３0を指し示す支出トランザクション１５２Ｓ（または「第２の」トランザクション）の入力内のロック解除スクリプトによってロック解除することができ、したがって、支出トランザクション１５２Ｓの受益者がエスクローされた資金を受け取ることを可能にする。開示されたメカニズムの出力ベースの実装によれば、ターゲットトランザクション１５２Ｔのロックスクリプトは、資金を請求するための少なくとも２つの代替条件、すなわち、少なくとも支出トランザクション１５２Ｓが買い手Ｂ＿Ｓi+1によって署名されることを要求する第１の条件と、少なくとも支出トランザクション１５２Ｓが税務当局ＴＡによって署名されることを要求する第２の代替条件とで構成される。したがって、買い手または税務当局のいずれかが、潜在的に資金を請求することができる。これにより、買い手Ｂ＿Ｓi+1は、還付を受ける権利がある消費税を回収することができるが、買い手Ｂ＿Ｓi+1がそれを回収しない場合、税務当局ＴＡが代わりに資金を請求することができる。
【0078】
出力ベースのモデルでは、支出トランザクション１５２Ｓは、関連当事者（この場合、買い手Ｂ＿Ｓi+1または税務当局ＴＡのいずれか）の暗号署名を、支出トランザクション１５２Ｓの入力内のロック解除スクリプトに含めることによって署名される。署名は、暗号署名機能を使用して当事者（買い手またはＴＡ）の秘密鍵を支出トランザクションの少なくとも一部に適用することによって生成され、この署名は、ロック解除スクリプトに含まれる。署名は、当該当事者の対応する公開鍵を使用して認証することができ、この原理により、署名に対するチャレンジをターゲットトランザクション１５２Ｔのロックスクリプトに含めることができる。公開鍵－秘密鍵ペアおよび暗号署名技法の詳細は、それ自体、当業者によく知られている。
【0079】
実施形態では、第１の条件は、買い手Ｂ＿Ｓi+1による資金の回収を可能にするために、１つまたは複数の追加の要件が満たされることを要求し得る。実施形態では、これは、支出トランザクション１５２Ｓのロック解除スクリプトがパズルの解を含むという要件を含み、この解は、買い手が還付を受ける権利があることを検証することに応答して税務当局ＴＡによって買い手Ｂ＿Ｓi+1に先に提供されたシークレット値を含む。例えば、これは、購入に関する情報を検証すること、および／または（例えば、買い手を、承認された買い手－売り手であると証明する買い手のデジタル証明書を認証することによって）買い手の身元を検証することを含み得る。実施形態では、パズルはハッシュパズルを含み得る。言い換えると、パズルは、プレイメージのハッシュを含み、プレイメージは、少なくともシークレット値（および場合によっては、シークレットと連結された１つまたは複数の追加の要素）から構成される。次いで、買い手Ｂ＿Ｓi+1は、ターゲットトランザクション１５２Ｔの出力２０３0をロック解除し、資金を請求するために、正しいプレイメージを提示しなければならない。この要件を実装するために、ターゲットトランザクション１５２Ｔのロックスクリプトは、ハッシュと、解（この例ではプレイメージ）を含むようにロック解除スクリプトにチャレンジするロックスクリプトの一部とを含む。しかしながら、すべての可能な実施形態において、パズルがハッシュパズルであることに限定されないことに留意されたい。他の可能な暗号パズル、例えば、ｒパズルも当技術分野で知られている。
【0080】
いくつかの実施形態では、（買い手Ｂ＿Ｓi+1が資金を回収することを可能にする）第１の条件は、例えば、購入ごとに（例えば、ランダムに、または発注書などの購入に関する情報に基づいて）新しいシークレットを生成することによって、個々の購入ごとに変化する要件を含む。これは、買い手が、個々の還付ごとに承認を得なければならないことを意味する。例えば、このようなシステムは、付加価値税（ＶＡＴ）の場合に適用することができる。しかしながら、代替的に、第１の条件は、個々の解が購入ごとに提供されることを要求しなくてもよく、複数の購入にわたって静的なままであってもよい。例えば、第１の条件は、暗号署名を用いて自身の身元を証明することのみを買い手Ｂ＿Ｓi+1に求めてもよいし、買い手が買い手－売り手として最初に登録するときに一度だけＴＡによって買い手に提供されるシークレットを含む解を提供することを買い手に求めてもよい。例えば、このようなシステムは、売上税の場合に適用することができる。
【0081】
実施形態では、第２の、代替条件は、税務当局ＴＡが買い手Ｂ＿Ｓi+1の代わりに資金を回収することを可能にするために、１つまたは複数の追加の要件が満たされることを要求し得る。実施形態では、これは、支出トランザクション１５２Ｓが買い手Ｂ＿Ｓi+1および税務当局ＴＡの署名で署名されるという要件を含み得る。この場合、ＴＡは、買い手からの承認を得て初めて資金を回収することができる。買い手がこれを行わず、ＴＡが買い手に税を支払う義務があると考えた場合、ＴＡは常に法的手段に戻ることができる。
【0082】
第２の条件によって要求される追加の要件の別の、代替のまたは追加の例として、ファンディングトランザクションのロックスクリプトは、税務当局ＴＡが資金を請求することができるようになる前にタイムアウト期間が経過していることを要求し得る。すなわち、現在の時間は、ロックスクリプトで指定されたタイムアウト時間よりも後でなければならない。ブロックチェーンの当業者にはよく知られているように、そのような目的のための時間は、人間の時間（秒、分、時間、日、週、月および／または年）で、またはブロックの高さ（ネットワーク１０６上でプルーフオブワークの解を成功裏に公開させ、したがってブロックチェーン１５０に含まれたブロックの数）の単位で測定することができる。したがって、税務当局ＴＡは、買い手Ｂ＿Ｓi+1が一定期間資金を回収しない場合にのみ資金を請求することができる。
【0083】
オプションで、ターゲットトランザクションは、購入のメタデータを記憶するために使用される追加の使用不可能な出力２０３1も含み得る。例えば、スクリプト言語を使用して、追加の出力２０３1は、ブロックチェーンネットワーク１０６によって適用されるプロトコルに応じて、ＯＰ＿ＲＥＴＵＲＮオペコードを含めるか、またはＯＰ＿ＲＥＴＵＲＮの後にＯＰ＿ＦＡＬＳＥを含めることによって、使用不可能にされ得る。メタデータは、例えば、発注書のコピーまたはハッシュ、インボイス、購入日、店舗ＩＤ、顧客ＩＤ、インボイスＩＤ、および／または購入または関与する当事者に関連する任意の他の情報を含み得る。ターゲットトランザクション１５２Ｔがブロック１５１に含まれると、このメタデータは、例えば、監査目的のために、不変の記録としてチェーン上に留まる。
【0084】
上記のいずれかと同様の機能性が、出力ベースのモデルではなくアカウントベースのモデルにおいてスマートコントラクトを使用して代替的に提供され得ることは理解されよう。
【0085】
どのタイプのトランザクションモデルが使用されても、方法は以下のように進行し得る。買い手Ｂ＿Ｓi+1と売り手Ｂ＿Ｓiと税務当局ＴＡとの間の通信は、任意の適切なオフチェーンサイドチャネル１０７を介して当事者のそれぞれのコンピュータ機器１０２間で行われ得る。
Ａ．買い手Ｂ＿Ｓi+1は、売り手Ｂ＿Ｓiに発注書を送信する。発注書は、注文されている１つまたは複数の商品および／またはサービスを指定する。買い手Ｂ＿Ｓi+1は、買い手Ｂ＿Ｓi+1の身元を証明するデジタル証明書（またはその参照）も売り手Ｂ＿Ｓiに送信し得る。
Ｂ．売り手Ｂ＿Ｓiは、インボイスを生成し、要求メッセージを税務当局ＴＡに送信する。要求メッセージは、販売されている１つまたは複数の商品および／またはサービスを指定するインボイスを含み得る。要求メッセージは、代替的にまたは追加的に、買い手Ｂ＿Ｓi+1の証明書、および／または売り手の身元を証明するための売り手Ｂ＿Ｓiのデジタル証明書を含んでもよい。実施形態では、売り手Ｂ＿Ｓiは、売り手Ｂ＿Ｓiが買い手の証明書を認証する場合にのみ、要求メッセージを送信し得る。
Ｃ．要求メッセージに応答して、ＴＡは、例えば、購入の詳細を検証すること、ならびに／または買い手および／もしくは売り手の証明書を認証することによって、売上税の還付が承認されるかどうかを検証する。このステップは、買い手Ｂ＿Ｓi+1が買い手－売り手であり、最終消費者ではないことを検証することを含み得る。検証にパスした場合、ＴＡは、確認メッセージを売り手Ｂ＿Ｓiに返信する。実施形態では、確認メッセージは、ターゲットトランザクション１５２Ｔに含まれるべきパズル（例えば、ハッシュパズル）を含み得る。また、場合によっては、確認メッセージは、ターゲットトランザクション１５２Ｔのテンプレートバージョンを含み得る。実施形態では、確認メッセージは、ＴＡの身元を証明するＴＡの証明書を含み得る。
Ｄ．売り手Ｂ＿Ｓiは、買い手Ｂ＿Ｓi+1に確認を返送する。これは、ＴＡからの確認メッセージからの情報の一部または全部、例えば、ＴＡの証明書を含み得る。
Ｅ．買い手Ｂ＿Ｓi+1は、売り手Ｂ＿Ｓiに消費税を支払う。これは、別のブロックチェーントランザクション１５２（図示せず）を介して、または不換通貨を使用して、チェーン上で行われ得る。
Ｆ．売り手Ｂ＿Ｓiは、ターゲットトランザクション１５２Ｔを取得する。これを行うために、ターゲットトランザクション１５２Ｔは、売り手Ｂ＿Ｓiが自ら生成し得る。代替的に、ターゲットトランザクション１５２Ｔのテンプレートが、ＴＡからの確認メッセージにおいて受信され、例えば、入力２０２に署名を追加することによって、売り手Ｂ＿Ｓiが完成させ得る。また、より一般的には、テンプレートは、買い手Ｂ＿Ｓi+1または第４の当事者などの任意の当事者から受信され得る。
Ｇ．売り手Ｂ＿Ｓiは、ブロックチェーン１５０上でブロック１５１において公開されるように、ターゲットトランザクション１５２Ｔをブロックチェーンネットワーク１０６に送信する。このステップは、売り手Ｂ＿Ｓiが自らターゲットトランザクション１５２Ｔをブロックチェーンネットワーク１０６のノード１０４に直接送信すること、またはその代わりに売り手Ｂ＿Ｓiとノード１０４との間の１つまたは複数の中間当事者を介してターゲットトランザクションを代理送信することを含み得る。いくつかの実施形態では、ステップＦは、売り手Ｂ＿Ｓiが税務当局の証明書を認証した場合にのみ実行され得る。
Ｈ．（パズルがターゲットトランザクション１５２Ｔに含まれていたことから）シークレットがＴＡから要求される場合、買い手Ｂ＿Ｓi+1は、要求メッセージをＴＡに送信し、それに応答して、要求されたシークレットを受信する。このステップは、買い手Ｂ＿Ｓi+1と売り手Ｂ＿Ｓiとの間の購入の完了に応答して、または買い手Ｂ＿Ｓi+1による別の買い手Ｂ＿Ｓi+2へのオンワード販売の時点で、または買い手Ｂ＿Ｓi+1が買い手－売り手としてＴＡに登録する最初の購入より早い時点に行うことができる。これは、新しいシークレットが購入ごとに要求されるか、１回限りの登録時に１回だけ要求されるか、または実際にシークレットが全く要求されないに依存する（他の実施形態では、買い手Ｂ＿Ｓi+1の署名は、ターゲットトランザクション１５２Ｔにおいてエスクローされた資金を回収する目的で買い手－売り手として買い手の身元を証明するのに十分であるとみなされ得る）。いくつかの実施形態では、ステップＧは、買い手Ｂ＿Ｓi+1がＴＡの証明書を認証した場合にのみ実行され得る。
Ｉ．買い手Ｂ＿Ｓi+1は、ターゲットトランザクションの出力２０３0を償還するための支出１５２Ｓを得る。このステップは、買い手Ｂ＿Ｓi+1が自らそれを生成すること、または買い手が、例えば、自身の署名（および必要であればシークレット）をロック解除スクリプトに追加することによって、買い手が完成させるべき支出トランザクション１５２Ｓのテンプレートを、別の当事者から受信することを含み得る。テンプレートが受信される場合、テンプレートは、買い手Ｂ＿Ｓi、税務当局ＴＡ、または第４の当事者から受信され得る。
Ｊ．買い手Ｂ＿Ｓi+1は、ブロックチェーン１５０上でブロック１５１において公開されるために、支出トランザクション１５２Ｔをブロックチェーンネットワーク１０６に送信する。このステップは、買い手Ｂ＿Ｓi+1が自ら支出トランザクション１５２Ｓをブロックチェーンネットワーク１０６のノード１０４に直接送信すること、または買い手Ｂ＿Ｓi+1とノード１０４との間の１つまたは複数の中間当事者を介して支出トランザクションを代理送信することを含み得る。いくつかの実施形態では、ステップＩは、買い手Ｂ＿Ｓi+1が税務当局の証明書を認証した場合にのみ実行され得る。
Ａ．買い手Ｂ＿Ｓi+1は、売り手Ｂ＿Ｓiに発注書を送信する。発注書は、注文されている１つまたは複数の商品および／またはサービスを指定する。買い手Ｂ＿Ｓi+1は、買い手Ｂ＿Ｓi+1の身元を証明するデジタル証明書（またはその参照）も売り手Ｂ＿Ｓiに送信し得る。
Ｂ．売り手Ｂ＿Ｓiは、インボイスを生成し、要求メッセージを税務当局ＴＡに送信する。要求メッセージは、販売されている１つまたは複数の商品および／またはサービスを指定するインボイスを含み得る。要求メッセージは、代替的にまたは追加的に、買い手Ｂ＿Ｓi+1の証明書、および／または売り手の身元を証明するための売り手Ｂ＿Ｓiのデジタル証明書を含んでもよい。実施形態では、売り手Ｂ＿Ｓiは、売り手Ｂ＿Ｓiが買い手の証明書を認証する場合にのみ、要求メッセージを送信し得る。
Ｃ．要求メッセージに応答して、ＴＡは、例えば、購入の詳細を検証すること、ならびに／または買い手および／もしくは売り手の証明書を認証することによって、売上税の還付が承認されるかどうかを検証する。このステップは、買い手Ｂ＿Ｓi+1が買い手－売り手であり、最終消費者ではないことを検証することを含み得る。検証にパスした場合、ＴＡは、確認メッセージを売り手Ｂ＿Ｓiに返信する。実施形態では、確認メッセージは、ターゲットトランザクション１５２Ｔに含まれるべきパズル（例えば、ハッシュパズル）を含み得る。また、場合によっては、確認メッセージは、ターゲットトランザクション１５２Ｔのテンプレートバージョンを含み得る。実施形態では、確認メッセージは、ＴＡの身元を証明するＴＡの証明書を含み得る。
Ｄ．売り手Ｂ＿Ｓiは、買い手Ｂ＿Ｓi+1に確認を返送する。これは、ＴＡからの確認メッセージからの情報の一部または全部、例えば、ＴＡの証明書を含み得る。
Ｅ．買い手Ｂ＿Ｓi+1は、売り手Ｂ＿Ｓiに消費税を支払う。これは、別のブロックチェーントランザクション１５２（図示せず）を介して、または不換通貨を使用して、チェーン上で行われ得る。
Ｆ．売り手Ｂ＿Ｓiは、ターゲットトランザクション１５２Ｔを取得する。これを行うために、ターゲットトランザクション１５２Ｔは、売り手Ｂ＿Ｓiが自ら生成し得る。代替的に、ターゲットトランザクション１５２Ｔのテンプレートが、ＴＡからの確認メッセージにおいて受信され、例えば、入力２０２に署名を追加することによって、売り手Ｂ＿Ｓiが完成させ得る。また、より一般的には、テンプレートは、買い手Ｂ＿Ｓi+1または第４の当事者などの任意の当事者から受信され得る。
Ｇ．売り手Ｂ＿Ｓiは、ブロックチェーン１５０上でブロック１５１において公開されるように、ターゲットトランザクション１５２Ｔをブロックチェーンネットワーク１０６に送信する。このステップは、売り手Ｂ＿Ｓiが自らターゲットトランザクション１５２Ｔをブロックチェーンネットワーク１０６のノード１０４に直接送信すること、またはその代わりに売り手Ｂ＿Ｓiとノード１０４との間の１つまたは複数の中間当事者を介してターゲットトランザクションを代理送信することを含み得る。いくつかの実施形態では、ステップＦは、売り手Ｂ＿Ｓiが税務当局の証明書を認証した場合にのみ実行され得る。
Ｈ．（パズルがターゲットトランザクション１５２Ｔに含まれていたことから）シークレットがＴＡから要求される場合、買い手Ｂ＿Ｓi+1は、要求メッセージをＴＡに送信し、それに応答して、要求されたシークレットを受信する。このステップは、買い手Ｂ＿Ｓi+1と売り手Ｂ＿Ｓiとの間の購入の完了に応答して、または買い手Ｂ＿Ｓi+1による別の買い手Ｂ＿Ｓi+2へのオンワード販売の時点で、または買い手Ｂ＿Ｓi+1が買い手－売り手としてＴＡに登録する最初の購入より早い時点に行うことができる。これは、新しいシークレットが購入ごとに要求されるか、１回限りの登録時に１回だけ要求されるか、または実際にシークレットが全く要求されないに依存する（他の実施形態では、買い手Ｂ＿Ｓi+1の署名は、ターゲットトランザクション１５２Ｔにおいてエスクローされた資金を回収する目的で買い手－売り手として買い手の身元を証明するのに十分であるとみなされ得る）。いくつかの実施形態では、ステップＧは、買い手Ｂ＿Ｓi+1がＴＡの証明書を認証した場合にのみ実行され得る。
Ｉ．買い手Ｂ＿Ｓi+1は、ターゲットトランザクションの出力２０３0を償還するための支出１５２Ｓを得る。このステップは、買い手Ｂ＿Ｓi+1が自らそれを生成すること、または買い手が、例えば、自身の署名（および必要であればシークレット）をロック解除スクリプトに追加することによって、買い手が完成させるべき支出トランザクション１５２Ｓのテンプレートを、別の当事者から受信することを含み得る。テンプレートが受信される場合、テンプレートは、買い手Ｂ＿Ｓi、税務当局ＴＡ、または第４の当事者から受信され得る。
Ｊ．買い手Ｂ＿Ｓi+1は、ブロックチェーン１５０上でブロック１５１において公開されるために、支出トランザクション１５２Ｔをブロックチェーンネットワーク１０６に送信する。このステップは、買い手Ｂ＿Ｓi+1が自ら支出トランザクション１５２Ｓをブロックチェーンネットワーク１０６のノード１０４に直接送信すること、または買い手Ｂ＿Ｓi+1とノード１０４との間の１つまたは複数の中間当事者を介して支出トランザクションを代理送信することを含み得る。いくつかの実施形態では、ステップＩは、買い手Ｂ＿Ｓi+1が税務当局の証明書を認証した場合にのみ実行され得る。
【0086】
ステップＡ～ＤおよびＨはオプションであるが、当事者間の通信を改善するため、および／またはプロセスのセキュリティを向上させるために採用され得る。例えば、ステップＡ～Ｃにおける証明書の提示および認証は、不正なまたは悪意のある当事者によるシステムの破壊に対するセキュリティを向上させる。また、論理的な依存関係がある場合を除いて、上記のステップのすべてが提示された順序で実行される必要はないことにも留意されたい。例えば、ステップＥおよびＦは、互いに対していずの順序でも実行することができる。
【0087】
例示として、ここで、いくつかの例示的なシステムの実装を、付加価値税（ＶＡＴ）および売上税に照らして、より詳細に述べる。例示的なシステムは、本明細書では、ＴＡＸＲＴ（Tax In Real Time）システムと呼ばれ得る。
【0088】
ＴＡＸＲＴは、その名が示すように、税のリアルタイム処理に基づいて構築された課税システムである。より具体的には、売上税や付加価値税（ＶＡＴ）など、多段階の消費税システムをめぐるプロセスを管理するためのブロックチェーンベースのシステムである。
【0089】
以下に、リアルタイムシステムの売上税（ＳＴＡＸＲＴ）およびＶＡＴ（ＶＴＡＸＲＴ）バージョンを概説する。それぞれ、カスタマイズされたブロックチェーントランザクションのシステムと、システム内の利害関係者（および／または他の参加者）間の相互作用のためのプロトコルとを中心に構築される。
【0090】
付加価値税システムＶＴＡＸＲＴ
ＶＴＡＸＲＴは、付加価値税システムの独特の特性を容易にするように設計されたシステムのバージョンである。ＶＡＴの重要な要素は、「アイテムの売買のシーケンスの参加者」が、そのアイテムに付加された価値に対してのみ税を支払うことが予想されること、そのため、参加者は、アイテムを販売する際に、アイテムの以前の購入で支払った税が還付されることが予想されることであることを想起されたい。このシステムの参加者は、以下のように説明することができる。
ＶＴＡＸＲＴは、付加価値税システムの独特の特性を容易にするように設計されたシステムのバージョンである。ＶＡＴの重要な要素は、「アイテムの売買のシーケンスの参加者」が、そのアイテムに付加された価値に対してのみ税を支払うことが予想されること、そのため、参加者は、アイテムを販売する際に、アイテムの以前の購入で支払った税が還付されることが予想されることであることを想起されたい。このシステムの参加者は、以下のように説明することができる。
【表1】
【0091】
支払い
図６の例によってキャプチャされているように、参加者間の支払いに関してシステムの設計を最初に説明する。このシステムは、ＶＡＴを徴収し、税務当局ＴＡにＶＡＴを支払うことを担うのは売り手であるという前提で設計されていることに留意されたい。
図６の例によってキャプチャされているように、参加者間の支払いに関してシステムの設計を最初に説明する。このシステムは、ＶＡＴを徴収し、税務当局ＴＡにＶＡＴを支払うことを担うのは売り手であるという前提で設計されていることに留意されたい。
【0092】
最も左の当事者は売り手（Ｂ＿Ｓ0）である。前述したように、この参加者は商品の販売のみ行うと仮定する。買い手Ｂ＿Ｓ1は、Ｂ＿Ｓ0からアイテム（Ｉｔｅｍ１）を購入する。当然ながら、２つ以上のアイテムを購入することも可能であるが、説明の目的で、１つの「アイテム」のみが売買されることに触れる。図示の例では、ＶＡＴ率は２０％に設定されている。そのため、販売価格が￡１００である場合、Ｂ＿Ｓ1は、ＶＡＴで￡２０をＢ＿Ｓ0に支払う必要がある。この支払いは、オンブロック（暗号通貨）またはオフブロック（例えば、ＦＩＡＴ）であり得る。このタイプおよび同様のタイプの支払い（販売価格＋ＶＡＴ）は、図の下部に矢印で示されている。
【0093】
Ｂ＿Ｓ1からＶＡＴを受け取ると、売り手Ｂ＿Ｓ0は、ＶＡＴが税務当局またはＢ＿Ｓ1のいずれかによってのみ請求され得る（２つの代替条件としてＴＡまたはＢ＿Ｓ1にロックされたＵＴＸＯ）ようにＶＡＴをエスクローするブロックチェーントランザクション（例えば、ビットコイントランザクション）を作成する。上記トランザクションの各潜在的な受信者は、それぞれＶＡＴを請求することができる条件を有する。税務当局の場合、指定された時間ｔ1の後にのみ資金を請求することができる。この時間は、売り手Ｂ＿Ｓ0と税務当局との間の共同契約で設定される。これは、管轄区域の税法に規定された標準時間に基づいている可能性が高い。
【0094】
Ｂ＿Ｓ1によるエスクローされた資金の請求は、Ｂ＿Ｓ1に対するＶＡＴ還付を表す。Ｂ＿Ｓ1が買い手Ｂ＿Ｓ2にアイテムを販売するときに、Ｂ＿Ｓ1に還付が行われることが予想される。Ｂ＿Ｓ1がアイテムを販売するか、または少なくともアイテムをＢ＿Ｓ2に販売することに同意する場合、売り手Ｂ＿Ｓ1は、これを税務当局に通信するであろう。当局の承認を前提として、当局は、シークレット値ｓｖ1をＢ＿Ｓ1にセキュアに通信するであろう。このシークレット値の知識は、Ｂ＿Ｓ1が、エスクローからＶＡＴ還付を請求することを可能にするものである。資金をシークレットにロックするトランザクションを作成することができるようにするために、このシークレットのハッシュも売り手Ｂ＿Ｓ0に通信される。税務当局が（ある時点ｔ1の後であっても）これらの資金に等しくアクセスすることができると仮定すると、Ｂ＿Ｓ1は、シークレット値を受信した後、税務当局が使用することができる前に、資金を請求することが賢明である。ＴＡが資金を請求することを可能にするのは、Ｂ＿Ｓ1が実際には買い手－売り手であることが判明しない（またはそれを証明することができない）という不測の事態を想定したものである。
【0095】
この一連のステップは、シーケンスにおいて後続する参加者の各々の間で繰り返される。買い手－売り手Ｂ＿ＳiおよびＢ＿Ｓi+1の一般的なペアを考慮する。Ｉｔｅｍi+1はＩｔｅｍiの次の反復（例えば、生地からドレス）であることに留意されたい。Ｂ＿Ｓi、Ｂ＿Ｓi+1、および税務当局間の支払いのリストは以下のとおりである。
【0096】
買い手Ｂ＿Ｓi+1がＢ＿Ｓiからアイテム（Ｉｔｅｍi+1）を購入する。ＶＡＴ率はｒに設定され、ｒは比率である。そのため、販売価格が￡Ｘi+1である場合、買い手Ｂ＿Ｓi+1は、ＶＡＴで￡ｒＸi+1をＢ＿Ｓｉに支払う必要がある。この支払いは、オンブロック（暗号通貨）またはオフブロック（例えば、ＦＩＡＴ）であり得る。
【0097】
Ｂ＿Ｓi+1からＶＡＴを受け取ると、売り手Ｂ＿Ｓiは、ＶＡＴが税務当局またはＢ＿Ｓi+1のいずれかによってのみ請求され得るようにＶＡＴをエスクローするビットコイントランザクションを作成する。上記トランザクションの各潜在的な受信者は、それぞれＶＡＴを請求することができる条件を有する。税務当局の場合、指定された時間ｔ1+1の後にのみ資金を請求することができる。この時間は、売り手Ｂ＿Ｓｉと税務当局との間の共同契約で設定される。これは、管轄区域の税法に規定された標準時間に基づいている可能性が高い。
【0098】
Ｂ＿Ｓi+1によるエスクローされた資金の請求は、Ｂ＿Ｓi+1へのＶＡＴ還付を表す。Ｂ＿Ｓi+1が買い手Ｂ＿Ｓi+2（または売り手ＳＬ）にアイテムを販売するときに、Ｂ＿Ｓi+1に還付が行われることが予想される。Ｂ＿Ｓi+1がアイテムを販売するか、または少なくともアイテムをＢ＿Ｓi+2に販売することに同意する場合、買い手－売り手Ｂ＿Ｓi+1は、これを税務当局に通信するであろう。当局の承認を前提として、当局は、シークレット値ｓｖi+1をＢ＿Ｓi+1にセキュアに通信するであろう。このシークレット値の知識は、Ｂ＿Ｓi+1が、エスクローからＶＡＴ還付を請求することを可能にするものである。税務当局が（ある時点ｔi+1の後であっても）これらの資金に等しくアクセスすることができると仮定すると、Ｂ＿Ｓi+1は、シークレット値を受信した後、税務当局が使用することができる前に、資金を請求することが賢明である。シークレットは、例えば、税務当局によってランダムに生成されることによって、または発注書などの購入ごとの値の予測不可能な関数である（例えば、発注書を税務当局に知られている何らかの他の値と連結してからハッシュする）ことによって、買い手にとって予測不可能であるべきである。
【0099】
プロトコル
参加者間のこの支払いのセットを容易にするために、参加者は、いくつかのアクションを実行し得る。これらのアクションは、図７に概説されるプロトコルにキャプチャされている。
参加者間のこの支払いのセットを容易にするために、参加者は、いくつかのアクションを実行し得る。これらのアクションは、図７に概説されるプロトコルにキャプチャされている。
【0100】
図に示すプロトコルでは、まず、各買い手および／または売り手（Ｂ＿Ｓi）が、ＶＡＴトランザクションに署名するため、およびディフィーヘルマンセキュア通信のために利用する少なくとも１つの公開鍵を有すると仮定される（ディフィーヘルマンは、公開チャネルを経由して暗号鍵をセキュアに交換する方法である）。これらの鍵はすべて（トランザクションごとまたは他の形で）異なることができるが、簡略化のために、その買い手－売り手のすべてのこれらの公開鍵にラベルＰiが与えられる。絶対に必須である必要はないが、公開鍵Ｐiは、何らかの中央機関、おそらくは税務当局自体によって証明されると仮定される。
【0101】
図７のとおり、最初に起こることは、買い手Ｂ＿Ｓi+1が、購入されるアイテムＩｔｅｍi+1を含む発注書をＢ＿Ｓiに与えることである。発注書と共に、Ｂ＿Ｓi+1は、自身の公開鍵Ｐi+1も提供する。この情報を使用して、売り手Ｂ＿Ｓiは、インボイスを作成し、インボイスを、買い手および売り手の公開鍵ならびにそれらの対応するデジタル証明書と共に税務当局に送信する。
【0102】
税務当局は、情報に対してデューデリジェンスを行い、それには、証明書の信用性を評価すること、および、アイテムＩｔｅｍi+1が前のアイテムの反復であるかを判定することが含まれる。その承認を前提として、当局は、乱数ｓｖi+1を作成し、Ｈ（ｓｖi+1）を計算する。ここで、Ｈ（）は、決定性ハッシュ関数である。この販売トランザクション（ＳＴi+1）は、（ブロックチェーントランザクションではなく）販売の全体的な記述である。それは、当局によって販売ＩＤを与えられ、これは、Ｈ（ｓｖi+1）、インボイスの署名済みコピー、ならびに適用可能な証明書情報および公開鍵ＰTAと共に売り手Ｂ＿Ｓiに返信される。アイテムＩｔｅｍi+1が前のアイテム（例えば、Ｉｔｅｍi）の反復である場合、当局は、買い手－売り手Ｂ＿Ｓiに値ｓｖiをセキュアに通信するために、ディフィーヘルマンなどのシークレット共有スキームを開始する（これは、Ｂ＿ＳiがＩｔｅｍiの以前の販売に対する税還付を徴収するためである）。
【0103】
シークレット値ｓｖiを除外して、情報目的のために、売り手Ｂ＿Ｓiは、インボイスの署名済みコピー、値Ｈ（ｓｖi+1）、およびデジタル証明書を買い手Ｂ＿Ｓi+1に送付する。次いで、買い手Ｂ＿Ｓi+1は、望む場合、税務当局と証明書を妥当性確認し得る。買い手Ｂ＿Ｓi+1は、妥当性確認を受信すると、商品に必要とされるＶＡＴ（および商品／サービスのコスト）の売り手Ｂ＿Ｓiへの支払いに進み得る。
【0104】
ＶＡＴをＢ＿Ｓiに（暗号でまたは他の方法で）支払うと、売り手Ｂ＿Ｓiは、ブロックチェーンにサブミットされるＶＡＴビットコイントランザクション（ＶＡＴi+1）を構築する。このビットコイントランザクションのコア属性は、それがＶＡＴのエスクローとして機能する必要があることである。トランザクションは、想起する限り、以下のルールを実施することである：
【0105】
税務当局は、指定された時点の後にＶＡＴi+1の出力にアクセスすることができる。
【0106】
買い手－売り手Ｂ＿Ｓi+1は、Ｂ＿Ｓi+1がシークレット値ｓｖi+1を作り出すことができる場合、（ＶＡＴ還付として）ＶＡＴi+1の出力にアクセスすることができる。
【0107】
これは、ＶＡＴi+1内のカスタマイズされた出力スクリプトおよび支出トランザクションの署名を管理するプロトコルを通して実施される（以下を参照）。
【0108】
ＶＡＴi+1がブロックチェーンにサブミットされた後、新たな買い手－売り手Ｂ＿Ｓi+2がＢ＿Ｓi+1からＩｔｅｍi+2を購入したいと望むシナリオを考慮する。これは、Ｉｔｅｍi+2がＩｔｅｍi+1の次の反復（例えば、生地からドレス）である場合である。
【0109】
現在の買い手Ｂ＿Ｓi+2が自身の発注書を売り手Ｂ＿Ｓi+1にサブミットすると、販売トランザクションの詳細を税務当局にサブミットする際に、現在の売り手Ｂ＿Ｓi+2もまた、このデータセットにＶＡＴ還付要求を含める。この還付要求は、販売トランザクション（ＳＴi+1）およびＶＡＴトランザクション（ＶＡＴi+1）への参照を含む、Ｉｔｅｍi+1のＢ＿Ｓi+1の以前の購入の様々な既存の文書を含むであろう。
【0110】
ＶＡＴ還付要求を受信して妥当性確認すると、（販売トランザクションの処理と同時に）税務当局は、Ｂ＿Ｓi+1とディフィーヘルマンプロセスを開始し、それを通して、シークレット値ｓｖi+1がＢ＿Ｓi+1に渡される。ディフィーヘルマンプロセスは、税務当局および買い手－売り手Ｂ＿Ｓi+1の証明された公開鍵を使用して実行されることに留意されたい。
【0111】
次いで、買い手－売り手Ｂ＿Ｓi+1は、値ｓｖi+1（および、自身の署名ｓｉｇ（Ｐi+1））を使用して、ＶＡＴトランザクション（ＶＡＴi+1）の出力を使用することができる。
【0112】
Ｂ＿Ｓi+1が、時間ｔi+1までにＶＡＴi+1の出力を請求しない場合、税務当局は、出力を使用することができる（本質的に、政府はこの時点で資金を請求する）。
【0113】
ＶＡＴトランザクション
ＶＡＴトランザクションＶＡＴi+1は、前述したように、販売トランザクションＳＴi+1に関連して支払われるＶＡＴをエスクローするトランザクションである。ＶＡＴトランザクションの視覚的表現が図８に示されている。ここでは、入力および出力が、関連する寄与者および（潜在的な）受信者と共に示されている。売り手Ｂ＿Ｓiは、入力のための資金を提供する。税務当局は、自身の署名を承認として提供する（名目的な手数料／最小手数料で入力に与えることを介して）。一方、ＶＡＴ出力は、税務当局または買い手Ｂ＿Ｓi+1のいずれかによって受信されることができる。
ＶＡＴトランザクションＶＡＴi+1は、前述したように、販売トランザクションＳＴi+1に関連して支払われるＶＡＴをエスクローするトランザクションである。ＶＡＴトランザクションの視覚的表現が図８に示されている。ここでは、入力および出力が、関連する寄与者および（潜在的な）受信者と共に示されている。売り手Ｂ＿Ｓiは、入力のための資金を提供する。税務当局は、自身の署名を承認として提供する（名目的な手数料／最小手数料で入力に与えることを介して）。一方、ＶＡＴ出力は、税務当局または買い手Ｂ＿Ｓi+1のいずれかによって受信されることができる。
【0114】
（ＶＡＴ出力に加えて）別の出力の存在に気付く。これは、ＯＰ＿ＲＥＴＵＲＮ出力であり、販売トランザクションに関連するメタデータ（例えば、インボイスのコピーまたはハッシュ、トランザクションの日付、店舗ＩＤ、顧客ＩＤ、インボイスＩＤ、または購入に関連する任意の情報）を記憶するための二次出力として含まれる。このメタデータは、必要に応じて、プライバシーの目的で暗号化され得る。ビットコイントランザクション内のＯＰ＿ＲＥＴＵＲＮ出力は、使用不可能な出力である。別段の指定がない限り、ＶＡＴトランザクションの「出力」への言及は、ＯＰ＿ＲＥＴＵＲＮ出力ではなく、トランザクションのＶＡＴ出力を指す。
【0115】
ＶＡＴトランザクションの必要なエスクロー特性の成否は、ＶＡＴおよびその支出トランザクションのスクリプトおよび署名プロトコルの組合せに依存する。支出トランザクションは、ＶＡＴトランザクションの出力を使用するトランザクションである。
【0116】
これは、図９に示されるようなコミットメントチャネルの使用により達成される。
【0117】
コミットメントチャネルは３つのトランザクションから構成される。
－ ＶＡＴi+1：これは、ＶＡＴをエスクローにコミットするトランザクションである。
－ ＶＡＴPay：これは、ＶＡＴを政府に支払う支出トランザクションである。
－ ＶＡＴRef：これは、ＶＡＴを買い手－売り手Ｂ＿Ｓi+1に還付する支出トランザクションである。
－ ＶＡＴi+1：これは、ＶＡＴをエスクローにコミットするトランザクションである。
－ ＶＡＴPay：これは、ＶＡＴを政府に支払う支出トランザクションである。
－ ＶＡＴRef：これは、ＶＡＴを買い手－売り手Ｂ＿Ｓi+1に還付する支出トランザクションである。
【0118】
各トランザクションの詳細は、チャネルの構築のための図１０のフローチャートと共に以下で説明される。
【0119】
Ｓ１０：初期のコミットメントトランザクションＶＡＴi+1（表２）は、その<scriptPubKey>にしたがって、以下のいずれかによってのみ使用することができる利用可能なｒＸi+1を（その暗号通貨同等物において）作る：
【数1】
【0120】
Ｓ２０：コミットメントチャネルの支払いトランザクションＶＡＴPay（表３）は、税務当局がＶＡＴを徴収することができるようになる前に、法律で定められた期間または他の期間が発生することを可能にするように選択されたｎＬｏｃｋＴｉｍｅ値を含む。この期間内に、買い手－売り手Ｂ＿Ｓi+1がアイテム反復Ｉｔｅｍi+1→Ｉｔｅｍi+2を実行し、Ｉｔｅｍi+2を販売するのに十分な時間があったであろうことが予想される。ｎＬｏｃｋＴｉｍｅは、指定された時間が経過した後にのみビットコイントランザクションが実行可能であることを可能にするビットコイントランザクションパラメータである。
【0121】
Ｓ３０：支払いトランザクションＶＡＴPayは、買い手－売り手Ｂ＿Ｓi+1および税務当局ＴＡの両方によって署名されなければならない。これは、ＴＡが時間ｔi+1の後にのみＶＡＴを徴収するとの「約束」を破ることができないことを確実にするために行われる。プロセスの一部としてＢ＿Ｓi+1を含めることで、Ｂ＿Ｓi+1は、ｎＬｏｃｋＴｉｍｅ値がＴＡによって正しい値に設定されることを保証する能力を有する。逆もまた同様である。
【0122】
Ｓ４０：還付トランザクションＶＡＴRefの<scriptSig>は、その中にシークレット値ｓｖi+1を含むことが予想される。そのようなＴRefトランザクションの例を表４に示す。
【0123】
各トランザクションタイプの例は、以下の表２、表３、および表４に示される。
【表2】
【表3】
【表4】
【0124】
コミットメントチャネルの作成に関与するプロセスが与えられると、図６のシーケンス図は、これらのプロセスおよび通信を含むように修正され得る（図１１参照）。ＴＡによるＶＡＴトランザクション（ＶＡＴi+1およびＶＡＴPay）の作成が、Ｂ＿Ｓiを介したＢ＿Ｓi+1への通信と共に含まれることに留意されたい。
【0125】
売上税システムＳＴＡＸＲＴ
ＳＴＡＸＲＴは、売上税の徴収および支払いの管理を容易にするように設計されたブロックチェーンベースのシステムのバージョンである。いくつかの定義では、ＶＡＴは売上税のサブセットであると定義されることが多いが、本発明の目的上、この２つは区別され、売上税については、最終購入を行う個人によってのみ税が支払われるという両者間の重要な区別要因が定義される。税の支払いを免れるために、各仲介買い手－売り手｛Ｂ＿Ｓｉ：ｉ∈［１，ｎ－１］｝は、自身が税の支払いから免除されるべきであるという何らかの妥当性確認を提示しなければならない。この免除は、何らかの認められた当局（税務当局、例えばＩＲＳ、ＨＭＲＣ）によって買い手－売り手に与えられた証明である。重要なことに、ＳＴＡＸＲＴの場合、買い手－売り手の証明（certification）の証明は、ブロックチェーン上で行われる。より具体的には、提案された設計では、買い手は、売り手に売上税を支払わなければならない。次いで、売り手は、買い手が小売証明書（retail certificate）を有する場合、買い手によって取り出し可能なブロックチェーン上に売上税を直ちにエスクローする。
ＳＴＡＸＲＴは、売上税の徴収および支払いの管理を容易にするように設計されたブロックチェーンベースのシステムのバージョンである。いくつかの定義では、ＶＡＴは売上税のサブセットであると定義されることが多いが、本発明の目的上、この２つは区別され、売上税については、最終購入を行う個人によってのみ税が支払われるという両者間の重要な区別要因が定義される。税の支払いを免れるために、各仲介買い手－売り手｛Ｂ＿Ｓｉ：ｉ∈［１，ｎ－１］｝は、自身が税の支払いから免除されるべきであるという何らかの妥当性確認を提示しなければならない。この免除は、何らかの認められた当局（税務当局、例えばＩＲＳ、ＨＭＲＣ）によって買い手－売り手に与えられた証明である。重要なことに、ＳＴＡＸＲＴの場合、買い手－売り手の証明（certification）の証明は、ブロックチェーン上で行われる。より具体的には、提案された設計では、買い手は、売り手に売上税を支払わなければならない。次いで、売り手は、買い手が小売証明書（retail certificate）を有する場合、買い手によって取り出し可能なブロックチェーン上に売上税を直ちにエスクローする。
【0126】
支払い
ＳＴＡＸＲＴの場合、システムの設計は、図１２に例として示されるように、参加者間の支払いに関して同様に最初に説明される。
ＳＴＡＸＲＴの場合、システムの設計は、図１２に例として示されるように、参加者間の支払いに関して同様に最初に説明される。
【0127】
最も左の図は売り手（Ｂ＿Ｓ0）である。前述したように、この参加者は、商品の販売のみを行うと仮定する。買い手Ｂ＿Ｓiは、Ｂ＿Ｓ0からアイテム（Ｉｔｅｍ１）を購入し（この場合も、購入されるアイテムは２つ以上であってもよいが、説明の目的ので、１つの「アイテム」のみが売買されるものとする）。売上税率は２０％に設定されている。そのため、販売価格が￡１００である場合、Ｂ＿Ｓiは、ＶＡＴで￡２０をＳに支払う必要がある。この支払いは、オンブロック（暗号通貨）またはオフブロック（例えば、ＦＩＡＴ）であり得る。これらの販売価格＋売上税支払いは、図の下部に矢印で示されている。
【0128】
ＶＡＴと同様に、アイテムの購入に関して、買い手－売り手は、とにかく、売上税を売り手に支払うように求められることに留意されたい。買い手が必要な証明を有する限り、買い手が依然として自身の支払った売上税を「直ちに」回収することができることが望ましい。従来、買い手－売り手は売上税を全く支払わないが、支払う代わりに直ちに還付を受けることで、ブロックチェーン１５０を使用して、買い手－売り手の証明の有効性を記録することができる。
【0129】
Ｂ＿Ｓi+1が買い手－売り手Ｂ＿ＳiからのアイテムＩｔｅｍi+1に対して￡Ｙ支払う最初の販売トランザクションを考慮する。Ｂ＿Ｓi+1によって何らかの形態の個人識別が与えられると、買い手－売り手Ｂ＿Ｓiは、税務当局またはＢ＿Ｓi+1のいずれかによってのみ請求され得るように売上税をエスクローするビットコイントランザクションを作成する。上記トランザクションの潜在的な受信者のペアの各々は、それぞれＶＡＴを請求することができる条件を有する。税務当局の場合、指定された時間ｔ1の後にのみ資金を請求することができる。この時間値は、小売証明書の所有を証明するために買い手Ｂ＿Ｓi+1に与えられた期限を表す。
【0130】
以前のある時点で、買い手－売り手Ｂ＿Ｓi+1は、税務当局に「小売証明書」を付与するよう申請していたであろうことが予想される。この証明書は、税務当局の既知の信頼された公開鍵によって署名されたメッセージの形態であってもよい。このメッセージは公開鍵Ｐi+1と、買い手－売り手Ｂ＿Ｓi+1の他の識別情報（例えば、ＫＹＣ（know your client）情報）とを含む。買い手－売り手は、公開鍵に対応する秘密鍵を排他的に知っている。
【0131】
この秘密鍵は、Ｂ＿Ｓi+1が、支払った売上税を直ちに請求することを許可するものである。エスクローされた売上税を使わなかった場合（すなわち、時間ｔ1が来るまでに小売証明書免除の所有権を証明することができなかった場合）、税務当局は、単に、自力で売上税を徴収する。
【0132】
この一連のステップは、シーケンスにおいて後続する参加者の各々の間で繰り返される。
【0133】
プロトコル
参加者間のこの支払いのセットを容易にするために、参加者は、いくつかのアクションを実行することが予想される。これらのアクションは、図１３に概説されるプロトコルにキャプチャされている。
参加者間のこの支払いのセットを容易にするために、参加者は、いくつかのアクションを実行することが予想される。これらのアクションは、図１３に概説されるプロトコルにキャプチャされている。
【0134】
図１３に示すプロトコルでは、各買い手および／または売り手Ｂ＿Ｓiは、販売する意図がない場合、税務当局に小売証明書（ＲＣｅｒｔ）を申請する。証明要求は、Ｂ＿Ｓi+1からアイテムＩｔｅｍi+1を購入することを予想している買い手－売り手Ｂ＿Ｓi+1によって申請される。この証明を得るために、Ｂ＿Ｓi+1は、税務当局に、企業登録番号（Business Registration No.）などの適用可能なＫＹＣ情報を送信する。加えて、Ｂ＿Ｓi+1は、自身の公開鍵Ｐi+1も当局に通信する。
【0135】
この情報を受信すると、税務当局は必要なチェックを行い、満足した場合、公開鍵のデジタル証明書を作成することとなる。この小売証明書は、上記情報の署名されたハッシュと共に、生のＫＹＣおよび公開鍵情報を含むであろう。次いで、この証明書はＢ＿Ｓi+1にセキュアに通信される。
【0136】
Ｂ＿ＳiからアイテムＩｔｅｍi+1を購入しているとき、売り手Ｂ＿Ｓiに発注書を提供することに加えて、買い手Ｂ＿Ｓi+1は、自身の小売証明書も含む。この情報を使用して、売り手Ｂ＿Ｓiは、インボイスを作成し、インボイスを買い手の小売証明書と共に税務当局に送信する。
【0137】
税務当局は、証明書の信頼性を評価することを含めて、情報に対してデューデリジェンスを行う。その承認を前提として、当局は、売上税トランザクションＳＴｘi+1（表５）、ＳＴｘPay（表６）、およびＳＴｘRef（表７）を作成する。彼／彼女は、ＳＴｘi+1およびＳＴｘPayに署名する。
【0138】
売り手Ｂ＿Ｓiは、署名済みのＳＴおよびＳｔｘトランザクションならびに適用可能なすべてのデジタル証明書を買い手Ｂ＿Ｓi+1に送付する。「売上税トランザクション（ＳＴｘ）」は、売上税を管理するプロセスで利用されるブロックチェーントランザクションを指し、「販売トランザクション（ＳＴ）」という用語は、商品の購入の詳細、例えば、インボイスの詳細などを指す（販売トランザクションＳＴはブロックチェーントランザクションではないが、売上税トランザクションはブロックチェーントランザクションである）ことに留意されたい。次いで、買い手Ｂ＿Ｓi+1は、望む場合、税務当局と証明書を妥当性確認し得る。妥当性確認を受信すると、買い手Ｂ＿Ｓi+1は、ＳＴｘi+1、ＳＴｘPayトランザクションに署名し、アイテムに必要とされる売上税の売り手Ｂ＿Ｓiへの支払いに進む。
【0139】
売上税をＢ＿Ｓiに（暗号または他の方法で）支払うと、売り手Ｂ＿Ｓiは、ビットコイントランザクションＳＴｘi+1をブロックチェーンにサブミットする。ＶＡＴｘi+1として、ビットコイントランザクションＳＴｘi+1は、売上税のエスクローとして機能する。トランザクションは以下の基準を実施する。
－ 税務当局は、指定された時点の後にＳＴｘi+1の出力にアクセスすることができる。
－ 買い手－売り手Ｂ＿Ｓi+1は、小売証明書の公開鍵
に対する秘密鍵の知識を有する場合、ＳＴｘi+1の出力にアクセスすることができる。
－ 税務当局は、指定された時点の後にＳＴｘi+1の出力にアクセスすることができる。
－ 買い手－売り手Ｂ＿Ｓi+1は、小売証明書の公開鍵
【数2】
【0140】
これは、ＳＴｘi+1内のカスタマイズされた出力スクリプトおよび支出トランザクションの署名を管理するプロトコルを通して実施される（以下を参照）。
【0141】
ＳＴｘi+1がブロックチェーンにサブミットされた後、買い手－売り手Ｂ＿Ｓi+1は、公開鍵Ｐi+1に対応する秘密鍵を使用して生成される署名を使用して、売上税トランザクション（ＳＴｘi+1）の出力を使用することができる。
【0142】
買い手－売り手Ｂ＿Ｓi+1が、時間ｔi+1までにＳＴｘi+1の出力を請求しない場合、税務当局は、出力を使用することができる（本質的に、買い手－売り手が、証明された再販業者であることを証明することができなかったので、政府はこの時点で売上税を請求する）。
【0143】
売上税トランザクション
前述したように、売上税トランザクションＳＴｘi+1は、買い手－売り手が公開鍵Ｐi+1に対する秘密鍵を所有していることを証明することができる（小売証明書の所有権を示す）まで、売上税を一時的にエスクローするトランザクションである。ＳＴｘi+1の視覚的表現を表５に示す。繰り返しになるが、入力および出力は、関連する寄与者および（潜在的な）受信者と共に示される。売り手Ｂ＿Ｓiは、入力のための資金を提供する。税務当局は、自身の署名を承認として提供する（名目的な手数料／最小手数料で入力に与えることを介して）。一方、売上税出力は、税務当局または買い手Ｂ＿Ｓi+1のいずれかによって受信されることができる。
前述したように、売上税トランザクションＳＴｘi+1は、買い手－売り手が公開鍵Ｐi+1に対する秘密鍵を所有していることを証明することができる（小売証明書の所有権を示す）まで、売上税を一時的にエスクローするトランザクションである。ＳＴｘi+1の視覚的表現を表５に示す。繰り返しになるが、入力および出力は、関連する寄与者および（潜在的な）受信者と共に示される。売り手Ｂ＿Ｓiは、入力のための資金を提供する。税務当局は、自身の署名を承認として提供する（名目的な手数料／最小手数料で入力に与えることを介して）。一方、売上税出力は、税務当局または買い手Ｂ＿Ｓi+1のいずれかによって受信されることができる。
【0144】
図１４は、入力および出力を示す売上税トランザクションを示す。ＯＰ＿ＲＥＴＵＲＮ出力は、販売トランザクションに関連するメタデータを記憶するための二次出力として含まれる。このメタデータは、必要に応じて、プライバシーの目的で暗号化されてもよい。別段の指定がない限り、売上税トランザクションの「出力」への言及は、ＯＰ＿ＲＥＴＵＲＮ出力ではなく、トランザクションの売上税出力を指す。
【0145】
売上税トランザクションの必要なエスクロー特性の成否は、以下で説明され、図１５に示されるようなコミットメントチャネルの使用を通して達成され得る。
【0146】
コミットメントチャネルは、３つのトランザクションから構成される。
－ ＳＴｘi+1：これは、売上税をエスクローにコミットするトランザクションである。
－ ＳＴｘPay：これは、売上税を税務当局に支払う支出トランザクションである。
－ ＳＴｘRef：これは、売上税を買い手－売り手Ｂ＿Ｓi+1に還付する支出トランザクションである。
－ ＳＴｘi+1：これは、売上税をエスクローにコミットするトランザクションである。
－ ＳＴｘPay：これは、売上税を税務当局に支払う支出トランザクションである。
－ ＳＴｘRef：これは、売上税を買い手－売り手Ｂ＿Ｓi+1に還付する支出トランザクションである。
【0147】
チャネルの生成は、ＶＡＴエスクローのためのコミットメントチャネルと同じように動作するが、顕著な違いは、売上税トランザクションＳＴｘi+1の「ロックスクリプトの還付オプション」がシークレット値ｓｖ（これは、税務当局によってＢ＿Ｓi+1に通信されたシークレット値）の知識を要求しないことである。出力の買い手－売り手使用者Ｂ＿Ｓi+1は、証明された公開鍵Ｐi+1に対する署名を作成することのみが要求される。３つのトランザクションの詳細を、以下の表５、表６、および表７に示す。
【表5】
【表6】
【表7】
【0148】
参加者間の通信
ＳＴＡＸＲＴとＶＴＡＸＲＴの両方について、参加者は、必要な情報を交換するために互いに通信する。図１６は、参加者間の通信チャネルの例を示し、参加者は、それぞれのコンピューティングデバイスによって表される。
ＳＴＡＸＲＴとＶＴＡＸＲＴの両方について、参加者は、必要な情報を交換するために互いに通信する。図１６は、参加者間の通信チャネルの例を示し、参加者は、それぞれのコンピューティングデバイスによって表される。
【0149】
結論
開示された技法の他の変形または使用事例は、本明細書の開示が与えられると、当業者には明らかになり得る。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
開示された技法の他の変形または使用事例は、本明細書の開示が与えられると、当業者には明らかになり得る。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
【0150】
例えば、上記のいくつかの実施形態は、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０、およびビットコインノード１０４に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン１５０の１つの特定の例であり、上記の説明は概して任意のブロックチェーンに適用され得ることが理解されよう。すなわち、本発明は、ビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０、およびビットコインノード１０４への上記のいかなる言及も、それぞれブロックチェーンネットワーク１０６、ブロックチェーン１５０、およびブロックチェーンノード１０４への言及に置き換えることができる。ブロックチェーン、ブロックチェーンネットワーク、および／またはブロックチェーンノードは、上記で説明したように、ビットコインブロックチェーン１５０、ビットコインネットワーク１０６、およびビットコインノード１０４の説明されたプロパティのうちのいくつかまたはすべてを共有し得る。
【0151】
本発明の好ましい実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークであり、ビットコインノード１０４は、ブロックチェーン１５０のブロック１５１を作成し、公開し、伝搬し、記憶するという説明された機能の少なくともすべてを実行する。これらの機能のすべてではないが１つまたはいくつかのみを実行する他のネットワークエンティティ（またはネットワーク要素）が存在し得ることは除外されない。すなわち、ネットワークエンティティは、ブロックを作成および公開することはしないが、ブロックを伝搬および／または記憶する機能を実行し得る（これらのエンティティは、好ましいビットコインネットワーク１０６のノードとはみなされないことを想起されたい）。
【0152】
本発明の非優先実施形態では、ブロックチェーンネットワーク１０６は、ビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を作成し、公開し、伝搬し、記憶する機能のすべてではないが、少なくとも１つまたはいくつかを実行し得ることは除外されない。例えば、それらの他のブロックチェーンネットワーク上で、「ノード」は、ブロック１５１を作成および公開するが、それらのブロック１５１を記憶および／または他のノードに伝搬しないように構成される、ネットワークエンティティを指すために使用され得る。
【0153】
さらにより一般的には、上記の「ビットコインノード」１０４という用語へのいかなる言及も、「ネットワークエンティティ」または「ネットワーク要素」という用語に置き換えることができ、そのようなエンティティ／要素は、ブロックを作成し、公開し、伝搬し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ／要素の機能は、ブロックチェーンノード１０４を参照して上記で説明した方法と同じ方法でハードウェアに実装され得る。
【0154】
上記の実施形態は、例としてのみ説明されていることが理解されるであろう。より一般的には、下記ステートメントのうちのいずれか１つまたは複数による方法、装置、またはプログラムが提供され得る。
【0155】
ステートメント１：買い手による売り手からの１つまたは複数の商品および／またはサービスの購入に対する消費税を容易にするコンピュータ実装方法であって、少なくとも買い手は、上記商品および／またはサービスに基づいてオンワード販売を行う買い手－売り手であり、方法は、上記購入の売り手によって、少なくとも第２のブロックチェーントランザクションが買い手の暗号署名で署名されることを要求する第１の条件と、少なくとも第２のブロックチェーントランザクションが税務当局の少なくとも暗号署名で署名されることを要求する第２の条件という２つの代替条件のいずれかを第２のブロックチェーントランザクションが満たすによって償還することができる第１のブロックチェーントランザクションを取得することと、買い手から消費税の支払いを受けたことに応答して、ブロックチェーン上に記録されるべき第１のブロックチェーントランザクションを送信することとを含む方法。
【0156】
ステートメント２：税務当局からパズルを受信することを含み、パズルの解は、税務当局から買い手に共有されるシークレットを含み、第１の条件は、第２のブロックチェーントランザクションがパズルの解を含むことも要求する、ステートメント１の方法。
【0157】
ステートメント３：パズルは、プレイメージのハッシュに基づいて生成されたハッシュ値を含むハッシュパズルを含み、プレイメージは、パズルの解であり、上記シークレットを含む、ステートメント２の方法。
【0158】
ステートメント４：シークレットはランダム要素を含む、ステートメント２または３の方法。
【0159】
ステートメント５：シークレットは購入ごとに変化し、上記購入に対して一意である、ステートメント２、３または４の方法。
【0160】
ステートメント６：シークレットは購入の情報に基づく、ステートメント２から５のいずれかの方法。
【0161】
ステートメント７：第１の条件は、上記購入を含む買い手による複数の購入にわたって一定のままである、ステートメント１から３のいずれかの方法。
【0162】
ステートメント８：第２の条件は、第２のトランザクションが買い手の暗号署名を含むことも要求する、先行ステートメントのいずれかの方法。
【0163】
ステートメント９：第２の条件は、タイムアウトが経過していることをさらに要求する、先行ステートメントのいずれかの方法。
【0164】
ステートメント１０：タイムアウトは、秒、分、時間、日、週、月および／または年の単位で指定される、ステートメント９の方法。
【0165】
ステートメント１１：タイムアウトは、ブロック高さの単位で指定される、ステートメント９の方法。
【0166】
ステートメント１２：上記取得することは、売り手が第１のブロックチェーントランザクションを少なくとも部分的に生成することを含む、先行ステートメントのいずれかの方法。
【0167】
ステートメント１３：生成することは、売り手が税の支払いを受けたことに応答して、売り手によって実行される、ステートメント１２の方法。
【0168】
ステートメント１４：上記取得することは、売り手が税務当局から第１のブロックチェーントランザクションを受信することを含む、ステートメント１から１１のいずれかの方法。
【0169】
ステートメント１５：トランザクションを取得する前に、売り手が、購入に関する情報を税務当局に送信し、この情報の少なくとも一部に基づいて税務当局から確認メッセージを受信することを含む、先行ステートメントのいずれかの方法。
【0170】
ステートメント１６：購入に関する情報は、購入される商品および／もしくはサービスの表示、ならびに／または売り手が購入のために支払う額を含む、ステートメント１５の方法。
【0171】
ステートメント１７：購入に関する情報は、買い手から受け取った発注書に基づく、ステートメント１５または１６の方法。
【0172】
ステートメント１８：購入に関する情報は、買い手のデジタル証明書および／または売り手のデジタル証明書を含み、税務当局が、買い手および／または売り手の証明書を認証してから上記確認を返すことを可能にする、ステートメント１５、１６または１７の方法。
【0173】
ステートメント１９：確認メッセージは、税務当局のデジタル証明書および／または購入の販売ＩＤを含む、ステートメント１５から１８のいずれかの方法。
【0174】
ステートメント２０：確認メッセージは販売ＩＤを含み、販売ＩＤは第１のブロックチェーントランザクションに含まれる、ステートメント１９の方法。
【0175】
ステートメント２１：確認メッセージは税務当局の証明書を含み、方法は、売り手が税務当局の証明書を認証することを含み、第１のブロックチェーントランザクションを送信することは、税務当局の証明書の認証を条件とする、ステートメント１９または２０の方法。
【0176】
ステートメント２２：確認メッセージは、売り手が第１のブロックチェーントランザクションを生成する、第１のブロックチェーントランザクションのテンプレートバージョンまたはパズルを含む、少なくともステートメント２および１２に従属するステートメント１５から２１のいずれかの方法。
【0177】
ステートメント２３：確認メッセージは、第１のブロックチェーントランザクションを含む、少なくともステートメント１４に従属するステートメント１５から２１のいずれかの方法。
【0178】
ステートメント２４：方法は、税務当局からの確認に応答して、売り手が買い手に確認を返信することを含む、ステートメント１５から２３のいずれかの方法。
【0179】
ステートメント２５：買い手への確認は、税務当局からの確認メッセージの少なくとも一部を含む、ステートメント２４の方法。
【0180】
ステートメント２６：第１のブロックチェーントランザクションは、購入のメタデータをさらに含む、先行ステートメントのいずれかの方法。
【0181】
ステートメント２７：消費税は付加価値税（ＶＡＴ）を含む、先行請求項のいずれかの方。
【0182】
ステートメント２８：消費税は売上税を含む、ステートメント１から２６のいずれかの方法。
【0183】
ステートメント２９：ブロックチェーンは、各ブロックチェーントランザクションが、ロックスクリプトを含む少なくとも１つの出力と、別のトランザクションの出力を指し示し、指し示されたトランザクションの出力をロック解除するためのロック解除スクリプトを含む少なくとも１つの入力とを含む出力ベースのモデルにしたがって動作し、上記第１のブロックチェーントランザクションの代替条件は、第１のブロックチェーントランザクションの出力のロックスクリプトに含まれ、上記第２のブロックチェーントランザクションの入力は、第１のブロックチェーントランザクションの上記出力を指し示す、先行ステートメントのいずれかの方法。
【0184】
ステートメント３０：ブロックチェーンは、各ブロックチェーントランザクションがスマートコントラクトを含むアカウントベースのモデルにしたがって動作し、上記第１のブロックチェーントランザクションの代替条件は、第１のブロックチェーントランザクションのスマートコントラクトで定義される、ステートメント１から２８のいずれかの方法。
【0185】
ステートメント３１：１つまたは複数のメモリユニットを備えるメモリと、１つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ機器であって、メモリは、処理装置上で実行されるように構成されたコードを記憶し、コードは、処理装置上にあるときに、ステートメント１から３０のいずれかの方法を実行するように構成される、コンピュータ機器。
【0186】
ステートメント３２：コンピュータ可読ストレージ上に具現化され、コンピュータ機器上で実行されると、ステートメント１から３０のいずれかの方法を実行するように構成されたコンピュータプログラム。
【0187】
ステートメント３３：買い手による売り手からの１つまたは複数の商品および／またはサービスの購入に対する消費税を容易にするコンピュータ実装方法であって、少なくとも買い手は、上記商品および／またはサービスに基づいてオンワード販売を行う買い手－売り手であり、方法は、上記購入の買い手によって、消費税を売り手に支払うことを含む、売り手からの購入を行うことと、購入を行うことに続いて、ブロックチェーン上の第１のブロックチェーントランザクションを識別することであって、第１のブロックチェーントランザクションは、少なくとも第２のブロックチェーントランザクションが買い手の暗号署名で署名されることを要求する第１の条件と、少なくとも第２のブロックチェーントランザクションが税務当局の少なくとも暗号署名で署名されることを要求する第２の条件という２つの代替条件のいずれかを第２のブロックチェーントランザクションが満たすによって償還されるように構成される、識別することと、ブロックチェーン上に記録されるべき第２のブロックチェーントランザクションを送信することであって、第２のブロックトランザクションは、少なくとも買い手の暗号署名を含む上記代替条件のうちの第１の条件を満たすように構成され、それによって買い手の消費税を回収することとを含む方法。
【0188】
ステートメント３４：第２のブロックチェーントランザクションは、送信前に買い手によって少なくとも部分的に生成される、ステートメント３３の方法。
【0189】
ステートメント３５：第１の条件は、第２のブロックチェーントランザクションが第１のブロックチェーントランザクションに含まれるパズルの解を含むことも要求し、解はシークレットを含み、方法はさらに、購入を行うことと第２のブロックチェーントランザクションを生成することとの間に、買い手が、上記購入への参照およびオンワード販売に関する情報を含む還付要求を税務当局にサブミットすることと、買い手が、セキュアなチャネルを介して税務当局からシークレットを受信することとを含み、買い手による第２のブロックチェーントランザクションの生成は、税務当局から受信されたシークレットを上記第２のトランザクションに含めることを含む、ステートメント３４の方法。
【0190】
ステートメント３６：１つまたは複数のメモリユニットを備えるメモリと、１つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ機器であって、メモリは、処理装置上で実行されるように構成されたコードを記憶し、コードは、処理装置上にあるときに、ステートメント３３から３５のいずれかの方法を実行するように構成される、コンピュータ機器。
【0191】
ステートメント３７：コンピュータ可読ストレージ上に具現化され、コンピュータ機器上で実行されると、ステートメント３３から３５のいずれかの方法を実行するように構成されたコンピュータプログラム。
【0192】
ステートメント３８：買い手による売り手からの１つまたは複数の商品および／またはサービスの購入に対する消費税を容易にするコンピュータ実装方法であって、少なくとも買い手は、上記商品および／またはサービスに基づいてオンワード販売を行う買い手－売り手であり、方法は、税務当局によって、売り手から購入に関する情報を受信することと、購入に関する受信された情報に基づいて購入を検証することと、検証に応答して、売り手が、少なくとも第２のブロックチェーントランザクションが買い手の暗号署名で署名されることを要求する第１の条件と、少なくとも第２のブロックチェーントランザクションが税務当局の少なくとも暗号署名で署名されることを要求する第２の条件という２つの代替条件のいずれかを第２のブロックチェーントランザクションが満たすによって償還されるように構成された第１のブロックチェーントランザクションを取得し、ブロックチェーン上への記録のために送信することを可能にする確認メッセージを売り手に返信することとを含む方法。
【0193】
ステートメント３９：１つまたは複数のメモリユニットを備えるメモリと、１つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ機器であって、メモリは、処理装置上で実行されるように構成されたコードを記憶し、コードは、処理装置上にあるときに、ステートメント３８の方法を実行するように構成される、コンピュータ機器。
【0194】
ステートメント４０：コンピュータ可読ストレージ上に具現化され、コンピュータ機器上で実行されると、ステートメント３８の方法を実行するように構成されたコンピュータプログラム。
【0195】
本明細書で開示される別の態様によれば、売り手、買い手、および税務当局のアクションを含む方法が提供され得る。
【0196】
本明細書に開示される別の態様によれば、売り手、買い手、および税務当局のコンピュータ機器を備えるシステムが提供され得る。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図】
【図】
【図】
【図】
【国際調査報告】