IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン ホールディングス リミテッドの特許一覧

特開2024-109955ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法
<>
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図1
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図2
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図3
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図4
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図5A
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図5B
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図6
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図7
  • 特開-ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024109955
(43)【公開日】2024-08-14
(54)【発明の名称】ブロックチェーンネットワークにおける階層型トークン分配のためのシステム及び方法
(51)【国際特許分類】
   H04L 9/32 20060101AFI20240806BHJP
【FI】
H04L9/32 200Z
【審査請求】有
【請求項の数】12
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2024088888
(22)【出願日】2024-05-31
(62)【分割の表示】P 2022205204の分割
【原出願日】2018-06-22
(31)【優先権主張番号】1710283.1
(32)【優先日】2017-06-28
(33)【優先権主張国・地域又は機関】GB
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジョセフ,ダニエル
(57)【要約】      (修正有)
【課題】トークンミキシングシステムにおける暗号化によるセキュリティを提供して、複数のインプットノードが複数のアウトプットノードにトークンを共同して分配する方法及び装置を提供する。
【解決手段】方法は、ミキサノード(Uij)において実施される方法は、上流ノード(Ui)及びミキサノードに関連付けられた複数の下流ノード(Uijk)を識別するステップと、上流ノードと協力して、上流ノードとミキサノードとの間の第1トランザクションのための第1コミットメントチャネル(Ui→Uij)を生成し、複数の下流ノードの各々について、下流ノードと協力して、ミキサノードと下流ノードとの間の第2トランザクションのための第2コミットメントチャネル(Ui j→Uij k)を生成するステップと、を含み、第1トランザクションのアンロックスクリプトは第2トランザクションのうちのいずれか1つのアンロックスクリプトから導出される。
【選択図】図7
【特許請求の範囲】
【請求項1】
第1ノードから第2ノードへの一方向コミットメントチャネルを生成する、コンピュータ実装方法であって、前記方法は処理リソースにより実施され、前記方法は、
指定トークンセットが前記第1ノードから前記第2ノードへの転送のために送信又はコミットされるコミットメントコンポーネントを表す第1コミットメントトランザクションを生成するステップと、
前記第2ノードから前記第1ノードへ全てのトークンを返す返却トランザクションを生成するステップと、
前記返却トランザクションに署名し、前記返却トランザクションに署名することに基づき、前記第1コミットメントトランザクションに署名するステップと、
ブロックチェーン外で行われるトークンの転送を反映するために、1つ以上の更なる返却トランザクションを生成するステップと、
を含む方法。
【請求項2】
前記第1コミットメントトランザクションは、pay-to-script-hashトランザクションである、請求項1に記載の方法。
【請求項3】
前記返却トランザクションは、指定時点の後にのみ実行可能である、請求項1に記載の方法。
【請求項4】
前記1つ以上の更なる返却トランザクションは、前記第1ノードが前記第2ノードに対して行うよう要求された全てのトークンの転送を反映する、請求項1に記載の方法。
【請求項5】
前記方法は、前記第1ノード及び前記第2ノードの両方により実施される、請求項1に記載の方法。
【請求項6】
前記第1ノードは譲渡側ノードであり、前記第2ノードは譲受側ノードである、請求項1に記載の方法。
【請求項7】
前記一方向コミットメントチャネルは、時間期間に渡り複数の転送により、前記第1ノードに関連付けられたパーティAが前記第2ノードに関連付けられたパーティBに支払うことを望む使用に適する、請求項1に記載の方法。
【請求項8】
前記返却トランザクションは、前記第2ノードが前記第1コミットメントトランザクションについて提示された基準を満たすことができない場合に、コミットされたトークンを前記第1ノードに返却することを可能にする、請求項1に記載の方法。
【請求項9】
前記第1ノードが前記第2ノードにシークレット値を提供し又は前記第2ノードが前記第1ノードに前記シークレット値を提供し、前記シークレット値は前記一方向コミットメントチャネルをロックする、請求項1に記載の方法。
【請求項10】
前記シークレット値は、以下:
乱数が前記第1ノードと前記第2ノードとの間で転送されるステップと、
シークレット値の暗号化バージョンが前記第1ノードと前記第2ノードとの間で転送されるステップと、
を含む方法に従い生成される、請求項9に記載の方法。
【請求項11】
コンピューティング装置であって、
プロセッサと、
メモリと、
ネットワークインタフェースと、
前記プロセッサにより実行されると前記プロセッサに請求項1に記載の方法を実行させるコンピュータ実行可能命令を含むブロックチェーンアプリケーションと、
を含むコンピューティング装置。
【請求項12】
プロセッサ実行可能命令を格納している非一時的プロセッサ可読媒体であって、前記プロセッサ実行可能命令は、ノードのうちの1つのプロセッサにより実行されると、前記プロセッサに請求項1に記載の方法を実行させる、非一時的プロセッサ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、ブロックチェーンを介して行われる転送及びトランザクションに関し、より詳細には、トークンミキシングシステムにおける暗号化によるセキュリティを提供して、複数のインプットノードが複数のアウトプットノードにトークンを共同して分配することを可能にする方法及び装置に関する。
【背景技術】
【0002】
本願明細書で、用語「ブロックチェーン」は、あらゆる形式の電子的な、コンピュータに基づく、分散台帳を含むよう使用される。これらは、限定ではないが、ブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、及びそれらの変形を含む。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装及びプロトコルが本発明の範囲に含まれることに留意すべきである。
【0003】
ブロックチェーンは、ブロックにより構成される、コンピュータに基づく非集中型の分散型システムとして実装される総意に基づく電子台帳である。また、ブロックはトランザクションにより構成される。各トランザクションは、ブロックチェーンシステム内で参加者間のデジタルアセットの制御の転送を符号化するデータ構造であり、少なくとも1つのインプット及び少なくとも1つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能なレコードを生成する。トランザクションは、そのインプット及びアウトプットに組み込まれたスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。ビットコインプラットフォーム上で、これらのスクリプトは、スタックに基づくスクリプト言語を用いて記述される。
【0004】
トランザクションがブロックチェーンに書き込まれるために、「検証され」なければならない。ネットワークノード(マイナー)は、各トランザクションが有効であることを保証するために作業を実行し、無効なトランザクションはネットワークから拒否される。ノードにインストールされたソフトウェアクライアントは、自身のロック及びアンロックスクリプトを実行することにより、この検証作業を未使用トランザクション(UTXO)に対して実行する。ロック及びアンロックスクリプトの実行が真と評価した場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、トランザクションは、i)トランザクションを受信した第1ノードにより検証され、トランザクションが検証された場合に、ノードは該トランザクションをネットワーク内の他のノードに中継し、ii)マイナーにより構築された新しいブロックに追加し、iii)マイニングされ、つまり過去のトランザクションの公開台帳に追加されなければならない。
【0005】
ブロックチェーンに関連する関心の他の分野は、ブロックチェーンを介する現実世界のエンティティの表現及び転送のための「トークン」(又は「カラードコイン」)の使用である。潜在的に機密な又は秘密のアイテムは、識別可能な意味又は価値を有しないトークンにより表現できる。したがって、トークンは、現実世界のアイテムをブロックチェーンから参照できるようにする識別子として機能する。トークンは、例えば、ネットワークリソース及び/又はデジタルアセットの将来の制御を表してよい。幾つかの場合には、トークンは、アセット又は価値を表してよい。本願は、暗号通貨の環境における実施に限定されず、トークンの分散転送のためのブロックチェーンネットワークに関連するとして更に広く理解される。
【0006】
ビットコインのようなブロックチェーン技術の認識される利点のうちの1つは、トランザクションの匿名性である。ビットコインユーザの個人的詳細は、ビットコインアドレスに正式且つ明示的にアタッチされず、ブロックチェーンのビットコイン台帳だけが、公用アドレス情報を含む。しかしながら、二次的データ(例えば、トランザクションを完了するために必要な出荷アドレス)及び分析を用いると、関心のある第三者が公に入手可能な情報を組み合わせて、ビットコイン台帳上のトランザクションの詳細事項を現実のアイデンティティに関連付けることが可能な場合がある。特定のシステム、例えば投票システム、医療アプリケーション、等では、ネットワーク内での又はネットワークからのユーザの追跡可能性は、セキュリティ及び/又は信頼性のような多数の理由により望ましくない。
【0007】
ユーザがブロックチェーンデータを通じて識別され得る1つの方法は、特定のビットコインアドレスにより制御されるブロックチェーントークンの量である。ビットコインネットワークを介してブロードキャストされるトランザクション内のトークンのフローを追跡することにより、特定量のトークンをアドレスに帰属させることが可能な場合がある。このトークン量は、また、アドレスに関連付けられたユーザのアイデンティティを推定するために(例えば、外部の第三者により)使用され得る。例えば、あるアドレスから転送された合計トークン量が目立って大量であると決定された場合、該アドレスに関連付けられたユーザのアイデンティティの可能な集合は、そのような大量のトークンを保持していること又はそうすることが可能であると知られている者だけを含むよう絞られる。
【0008】
ユーザのアイデンティティを保護する際の困難は、トークンの実際の転送があるアドレスから行われる前に複数のサブ量/数量(sub-amounts/quantithies)に分割される場合よりも、あるアドレスにあるトークンが「そのまま(intact)」保たれる(つまり、単位量として維持される)場合に、特に一層顕著である。アドレスからのトークンの転送を偽装しようとするために様々な匿名技術が利用されるときでも、該アドレスから生じるトランザクションは、トランザクションにより転送されるべきトークンがそのまま保たれるならば、非常に容易に追跡されるだろう。アドレスにあるトークン量を分割することは、しかしながら、直接的な作業ではなく、技術的課題を提示する。特に、アドレスにある初期トークン量を小さなサブ量に分割する作業は、所有権、つまりトークンの制御を維持したまま、ユーザを初期量から分離させてしまうという技術的課題を呈する。
【0009】
したがって、ブロックチェーントランザクションにおいてインプットからアウトプットへの非追跡可能性及び非リンク可能性の向上を実現するために、ブロックチェーンアドレスにおけるトークン量を分割及び分配する方法及び装置を提供することが望ましい。
【0010】
しかしながら、ブロックチェーンネットワーク内でトークンをセキュアにミックスし分配しようとするとき、多数の技術的問題が存在する。例えば、参加ノード(又は該参加ノードに関連付けられた別のノード)が他のトークンを他のノードに公開させるプロトコルを実行する前に、該参加ノードがトークンを請求できる場合に、セキュリティが侵害され得る。さらに、例えばオフライン参加者による意図的又は不慮の誤ったトークン配分を防ぐことが重要である。
【0011】
このようなソリューションがここで考案される。
【0012】
したがって、本発明により、添付の請求の範囲に定められるような方法及び装置が提供される。
【発明の概要】
【0013】
本発明は、コンピュータにより実装される方法及び対応するシステムを提供し得る。方法/システムは、ブロックチェーンにより実施される方法/システムとして記載され得る。本発明は、セキュリティ方法又は暗号化方法/システムとして記載され得る。本発明は、暗号通貨の一部又は額のようなデジタルリソース/アセット(例えばトークン)のセキュアな転送を提供し得る。追加又は代替として、本発明は、暗号通貨の一部又は額のようなデジタルリソース/アセットの転送を制御する制御メカニズムを提供し得る。参照を容易にするために、アセット又はリソースは、本願明細書で「トークン」と呼ばれてよい。
【0014】
「コミットメントチャネル(Commitment channels)」は、順序付きで構成されてよく、複数のノードが階層的に配置されてよい。ルートノードは、階層構造内のトークン転送又は交換(例えば、特定ノードへのトークンの分配)の実行を制御してよい。本願明細書に記載の方法及びシステムは、分配に関連する任意のトークンのいかなるアンロック/アクセスも、コミットメントチャネルが適切に生成されたこと及び制御ノードが次にトークン転送処理を開始したことを制御ノードが決定するまで且つそうしない限り、任意の参加ノードにより行われないことを保証することにより、トークン分配のセキュリティを向上し得る。制御ノードは、階層的に配置されたコミットメントチャネルと結合されたとき、参加ノードがトークンの規定される分配を受け取ることを保証し得るシークレット値の順次的開示を開始してよい。例えば、階層構造の各パスに沿ったシークレット値の順次的開示は、参加ノードがトークンを転送するパスに沿ってそれぞれのノードから該トークンを受け取ることを可能にし得る。順次的なシークレットの開示は、参加ノードが、全てのトークントランザクションが参加ノードにより署名され、制御ノードにより決定されたようにコミットメントチャネルが適切に生成され及び完了したときにのみ、彼らのそれぞれのトークンを受け取ることを可能にし得る。
【0015】
追加又は代替として、本願は、リソース(又は「アセット」若しくは「トークン」)分配処理に参加するためのコンピュータにより実施される方法を記載し得る。リソース分配処理は、インプットノードに関連付けられたインプットアドレスにあるリソース/アセット/トークン数量を、複数のサブ数量に分割し、該サブ数量をそれぞれのアウトプットノードに関連付けられた複数のアウトプットアドレスにブロックチェーンを用いて分配する。以後、私達は、便宜上、「リソース」又は「アセット」の代わりに、用語「トークン」を使用する。
【0016】
トークン分配処理は、インプットノード、アウトプットノード、及び複数のミキサノードにより共同で実施されてよい。方法は、ミキサノードで実施されてよい。方法は、
上流ノード(Ui)及びミキサノードに関連付けられた複数の下流ノード(Uijk)を識別するステップと、上流ノードと協力して、上流ノードとミキサノードとの間の第1(ブロックチェーン)トランザクションのための第1コミットメントチャネルを生成し、
複数の下流ノードの各々について、下流ノードと協力して、ミキサノードと下流ノードとの間の第2トランザクションのための第2コミットメントチャネルを生成する、ステップと、を含む。その結果、第1(ブロックチェーン)トランザクションのアンロックスクリプトは第2(ブロックチェーン)トランザクションのうちのいずれか1つのアンロックスクリプトから導出される。
【0017】
用語「譲渡側(transferor)ノード」は、本願明細書では、用語「上流ノード」と同義的に使用されることがある。譲渡側ノードは、リソースを別のノードへ転送するノードであってよい。用語「下流(downstream)ノード」は、本願明細書では、用語「譲受側(transferee)ノード」と同義的に使用されることがある。譲受側ノードは、リソースを別のノード、例えば譲渡側ノードから受け取るノードであってよい。
【0018】
幾つかの実装では、前記第2コミットメントチャネルを生成するステップは、前記下流ノードと協力して、前記下流ノードへ転送すべきトークン数量をコミットするための第1ブロックチェーントランザクションを生成し、前記コミットされたトークン数量を前記ミキサノードに返す第2ブロックチェーントランザクションを生成し、前記コミットされたトークン数量の前記下流ノードへの転送を実行する第3ブロックチェーントランザクションを生成する、ステップを含んでよい。
【0019】
幾つかの実装では、前記トークン数量は、前記複数の下流ノードの各々へ転送すべきそれぞれの数量を識別する前記ミキサノードの値割り当て方式に基づき決定されてよい。
【0020】
幾つかの実装では、前記第3ブロックチェーントランザクションは、前記第2コミットメントチャネルに関連付けられた第2シークレット値を含むアンロックスクリプトを含んでよい。
【0021】
幾つかの実装では、前記方法は、前記第2コミットメントチャネルに関連付けられた前記第2シークレット値を取得するステップ、を更に含んでよい。
【0022】
幾つかの実装では、前記方法は、前記第1コミットメントチャネルに関連付けられた前記第1シークレット値を前記第2シ―クレット値を用いて導出するステップ、を更に含んでよい。
【0023】
幾つかの実装では、前記第1シークレット値は、前記インプットノードに関連付けられたシークレット鍵値に基づき、前記シークレット鍵値は全てのミキサノードに知られていない。
【0024】
幾つかの実装では、前記方法は、前記上流ノードへ及び前記インプットノードへ、ミキサ鍵値を送信するステップ、を更に含んでよい。
【0025】
幾つかの実装では、前記ミキサノードは、前記ミキサノードが前記上流ノードからの第1トークン数量の転送を検出した第1アドレスと、前記ミキサノードが前記下流ノードへ前記第1数量のサブ数量を転送する複数の第2アドレスと、を含んでよい。
【0026】
幾つかの実装では、前記複数の第2アドレスにおける合計トークン数量は、少なくとも前記第1数量に等しくてよい。
【0027】
幾つかの実装では、前記第2ブロックチェーントランザクションは、前記第2ブロックチェーントランザクションが前記ブロックチェーンに提出する資格があるようになる時点を指定するトランザクションパラメータを含んでよい。
【0028】
幾つかの実装では、前記第1ブロックチェーントランザクションは、前記第2ブロックチェーントランザクションが前記下流ノードにより署名された後に、前記ブロックチェーンに提出されてよい。
【0029】
幾つかの実装では、前記第1コミットメントチャネルは、任意の第2コミットメントチャネルが生成された後に、生成されてよい。
【0030】
本願は、記載の方法を実行するためのコンピューティング装置を更に記載する。前記コンピューティング装置は、少なくとも1つのプロセッサと、メモリと、ネットワーク接続を提供するネットワークインタフェースと、実行されると、前記プロセッサに本願明細書に記載の方法のうちの1つ以上の動作を実行させるプロセッサ実行可能命令を含むブロックチェーンアプリケーションと、を含んでよい。
【0031】
本願は、トークン分配処理に参加するためのプロセッサ実行可能命令を記憶し得る非一時的プロセッサ可読媒体を更に記載する。前記トークン分配処理は、インプットノードと、複数のアウトプットノードと、複数のミキサノードとを含み、前記プロセッサ実行可能命令は、前記ノードのうちの1つのプロセッサにより実行されると、前記プロセッサに本願明細書に記載の方法のうちの1つ以上の動作を実行させる。プロセッサは、ミキサノード内に設けられてよい。
【0032】
本発明のある態様又は実施形態に関連して記載される任意の特徴は、1つ以上の他の態様/実施形態に関して使用されてもよい。本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
【図面の簡単な説明】
【0033】
図1】例示的なノードのブロックチェーンネットワークを示す。
図2】コミットメントチャネルを構成する例示的な処理をフローチャート形式で示す。
図3】階層型トークン分配プロトコルで利用される例示的なノードの階層構造を示す。
図4】階層型トークン分配プロトコルのインスタンスを開始する例示的な処理をフローチャート形式で示す。
図5A】階層型トークン分配プロトコルで利用されるコミットメントチャネルの概略図を示す。
図5B】階層型トークン分配プロトコルにおけるノードと下流ノードとの間のコミットメントチャネルを構成する例示的な処理をフローチャート形式で示す。
図6】階層型トークン分配プロトコルにおける階層構造内のパスに沿ってトークン転送を提出する例示的な処理をフローチャート形式で示す。
図7】階層型トークン分配プロトコルにおいて、それぞれトークン転送を受信する及びトークンを転送する異なるブロックチェーンアドレスの、ミキサノードによる使用を示す概略図を示す。
図8】簡略化した参加ノードのブロック図を示す。
【発明を実施するための形態】
【0034】
先ず、図1を参照する。図1は、ブロック図の形式で、ブロックチェーンに関連付けられた例示的なブロックチェーンネットワーク100を示す。ブロックチェーンネットワークは、他の会員からの招待無しに又は承認無しに誰でも参加し得るピアツーピア開放型会員制ネットワークである。ブロックチェーンプロトコルの下でブロックチェーンネットワーク100が動作し、該ブロックチェーンプロトコルのインスタンスを実行する分散型電子装置は、ブロックチェーンネットワーク100に参加してよい。このような分散型電子装置は、ノード102と呼ばれてよい。ブロックチェーンプロトコルは、例えばビットコインプロトコル、又は他の暗号通貨であってよい。
【0035】
ブロックチェーンプロトコルを実行し、ブロックチェーンネットワーク100のノード102を形成する電子装置は、例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバのようなコンピュータ、スマートフォンのようなモバイル装置、スマートウォッチのようなウェアラブルコンピュータ、又は他の電子装置を含む様々な種類であってよい。
【0036】
ブロックチェーンネットワーク100のノード102は、有線及び無線通信技術を含み得る適切な通信技術を用いて互いに結合される。多くの場合、ブロックチェーンネットワーク100は、少なくとも部分的にインターネット上で実施され、個々のノード102の幾つかは、地理的に離散した位置に置かれてよい。
【0037】
ノード102は、ブロックチェーン上の全てのトランザクションのグローバル台帳を維持する。グローバル台帳は、分散台帳であり、各ノード102はグローバル台帳の完全コピー又は部分コピーを格納してよい。グローバル台帳に影響を与えるノード102によるトランザクションは、他のノード102により検証される。その結果、グローバル台帳の有効性が維持される。ビットコインプロトコルを使用することのような、ブロックチェーンネットワークの実装及び動作の詳細は、当業者に理解される。
【0038】
各トランザクションは、標準的に、1つ以上のインプット及び1つ以上のアウトプットを有する。インプット及びアウトプットに埋め込まれるスクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。トランザクションのアウトプットは、トランザクションの結果としてトークンが転送されるアドレスであってよい。該トークンは、次に、利用可能なトランザクションアウトプットとして該アウトプットアドレスに関連付けられる。ビットコインのような暗号通貨の環境では、利用可能なトランザクションアウトプットは、未使用トランザクションアウトプット(UTXO)と呼ばれてよい。後続のトランザクションは、次に、該トークンを1つ以上の他のアドレスへ転送するために、該アドレスをインプットとして参照してよい。
【0039】
トランザクションは、個人情報がブロックチェーン台帳上のトランザクションに含まれないという点で疑似匿名性であるが、トランザクションのチェーンの中でのトークンの転送を追跡すること、及び幾つかの場合には、外部データを用いてトークンを個人にリンクすることが可能である。匿名性を向上する目的で、様々なソースからのインプットをプールし、及びプールしたトークンをアウトプットに割り当てるために、ミキシングトランザクションが使用され得る。全てのインプット及びアウトプットが同じサイズである場合、特定のインプットを特定のアウトプットに関連付けることは困難である。しかしながら、このようなトランザクションでは、少なくとも1つの参加ノードは、インプットアドレスと別の参加ノードにより指定されたアウトプットアドレスとの間のつながりに気付く。ビットコインプロトコルにおけるCoinJoin動作のような、このようなミキシングトランザクションでは、複数のインプット及び複数のアウトプットを有する単一のトランザクションが使用され、トークンをミックスする。
【0040】
幾つかの他の匿名化技術は、インプットとアウトプットとの間のリンクを開示するのを回避しようとするために使用される。例えば、多様な有効性を有する、リング署名又はステルスアドレスである。ステルスアドレスは、トークンが送信されるべきアウトプットアドレスを特定ユーザから分離しようとする。リング署名は、可能な署名者のグループのうちの1人が特定トランザクションに署名した/承認した1人である等しい可能性を生成することにより、ソース非追跡可能性を生成しようとする。残念ながら、リング署名は、幾つかのブロックチェーンプロトコルでは実装に問題があることが分かっている。
【0041】
本開示は、ブロックチェーンアドレスにあるトークンを複数の異なるアドレスに分配する技術を提供する。より具体的には、あるアドレスにある初期トークン量を小さなサブ量に分割し、該サブ量をアウトプットアドレスのセットの間で分配する技術が記載される。トークンの分割は、初期トークン量の制御/所有権をそれらの最終アドレスにおけるサブ量の制御/所有権から分離するという観点で達成される。特に、初期トークンのサブ量は、外部観察者が最終アウトプットアドレスを初期トークン量を保管していたアドレスと関連付けることを困難にするよう、分配される。
【0042】
本発明の実施形態によると、ブロックチェーン上のあるアドレスにある初期トークンは、参加ノードのセットの間でトークンの転送の階層構造を通じて分配される。特に、初期トークン量及びそのサブ量は、「階層構造」の複数の層を通じて順次分割される。用語「階層構造」は、本開示で使用されるとき、アドレスにある初期トークン量のサブ量を分配するために生成される転送のセットを概念化するための構造を表す。本願の文脈では、「階層構造」は、リンクされたノードのセットとして表される、ルートノードと親ノードを有する子のサブ木とを含む木構造として理解されてよい。本開示で提案される階層構造トークン分配方式は、参加ノード(木構造の中のノードとして表される)の間のトークンの転送を用いて、分配の開始者に対応する「ルート」ノードから、開始者により制御されるアウトプットアドレスでもある複数の「リーフ」ノードへ、トークンを分配する。
【0043】
本願明細書に記載の技術は、分配の参加ノードが彼らのトークンを盗まれる危険に晒されないことを保証するために、参加ノードの間でトークンを転送するための「コミットメントチャネル」の使用を通じて実装されるセキュリティメカニズムも提供する。プロトコルの開始者は、コミットメントチャネルに関連付けられたシークレット値の伝搬される開示を用いて、コミットメントチャネルの後の「アンロック」を制御して、プロトコルのトークントランザクションが該トランザクションのための全てのコミットメントチャネルが確立されるまで実行されるのを防ぐ。生成されたコミットメントチャネルを用いてトークントランザクションの全部の完了に成功すると、アドレスの初期トークン量は、複数の宛先(アウトプット)アドレスに分配される。
【0044】
本願明細書の説明では、用語「インプットノード」、「アウトプットノード」、「参加ノード」、「インプットアドレス」、及び「アウトプットアドレス」が使用され得る。ノードの「アドレス」への言及は、物理ノードのネットワークアドレスへの言及を意味しない。むしろ、「アドレス」は、物理ノードがトランザクションにおいて署名に対応する鍵を有することにより所有権を請求可能なトークンの割り当てを有するブロックチェーン上のトランザクションの中で指定されるアドレスである。この意味で、「アウトプットアドレス」は、参加ノードのアドレスではなく、参加アウトプットノードにより所有される又はそれに関連付けられたブロックチェーントランザクションアウトプットアドレスである。同様に、「インプットアドレス」は、参加インプットノードにより所有される又はそれに関連付けられた利用可能なトランザクションアウトプット(暗号通貨の用語ではUXTO)のアドレスである。
【0045】
<コミットメントチャネル>
ビットコインのような種々のブロックチェーン技術は、時折、参加ノード間のペアによるトランザクションの構成において、「コミットメントチャネル」を使用し得る。コミットメントチャネルは、全てのトランザクションをブロックチェーンにコミットさせることなく、ノードが複数のトランザクションを生成できるよう設計される。コミットメントチャネルが参加ノードのペアの間で確立されると、ノードは、所与の時間期間内に望む限り多数の転送に従事でき、トランザクションのうちの2つだけが最終的にブロックチェーンに追加される。結果として、コミットメントチャネルの使用は、ブロックチェーンに追加される必要のあるトランザクションの数を低減でき、関連するトランザクションコストを低減できる。コミットメントチャネルは、また、譲受側ノードにより特定基準が満たされない場合に、又は譲渡側若しくは譲受側ノードのいずれかが特定転送セットの後に処理を終了することを決定した場合に、トークンを返却させる柔軟性を譲渡側ノードに提供する。
【0046】
図2は、譲渡ノードUAから譲受ノードUBへの一方向コミットメントチャネルUA→UBを生成する例示的な処理200をフローチャート形式で示す。処理200は、参加ノードUA及びUBのペアにより実施される。例えば、一方向コミットメントチャネルは、パーティAがパーティBに時間期間に渡り複数の転送により(例えば、サービスのために)支払うことを望むシナリオでの使用に適してよい。より一般的には、コミットメントチャネルUA→UBは、参加ノードUA及びUBの間のトークンの交換の可能なセットを実現し得る。
【0047】
ステップ202で、譲渡側UAは、コミットメントトランザクションTcを生成する。コミットメントトランザクションは、指定トークンセットxがUBへの転送のために送信され/コミットされるコミットメントチャネルのコミットメントコンポーネントを表す。幾つかの実施では、コミットメントトランザクションは、2-of-2マルチシグネチャのP2SH(pay-to-script-hash)トランザクションであってよい。このとき、トランザクションはブロックチェーンネットワークへ提出されない。
【0048】
ステップ204で、マルチシグネチャ制御されたトークンからの全てのトークンをUAに返却する別個の返却トランザクションTr,0がUAにより生成される。このトランザクションは、ブロックチェーントランザクションを指定時点の後にのみ実行可能にするパラメータnLockTimeを含む。返却トランザクションは、譲受ノードUBが持ち時間内に(つまりnLockTimeまでに)コミットメントトランザクションについての提示された基準を完了できない場合に、コミットされたトークンをノードUAに返却させる。
【0049】
ステップ206で、譲渡側UAは返却トランザクションに署名する。ステップ208で、UBが返却トランザクションに署名したと決定された場合、ステップ210で、UAは元のコミットメントトランザクションTCに署名し、それをブロックチェーンへ提出する。このとき、ノードUA及びUBは、ステップ212~226に示すようにブロックチェーン外で生成されているトークン転送を反映するために、1つ以上の新しい返却トランザクション(Tr,1,Tr,2,...,Tr,i,...)の生成に進んでよい。特に、これらの返却トランザクションは、UAが該時点でUBに生成するよう要求した全てのトークン転送を反映し得る。参加ノードが任意の返却トランザクションTr,iに署名することを拒否した場合、ノードは、nLockTimeの後に、「前の」返却トランザクションTr,i-1をブロックチェーンに提出できる。例えば、最悪のシナリオでは、UAは、Tr,0に署名しそれをブロックチェーンネットワークに提出することにより、Tcの中でUAによりコミットされた全部のトークンを返還要求できる。
【0050】
図2に示すように、UAとUBとの間の(オフブロック)返却トランザクションの反復は、UAからUBへの全部のトークン転送を表す最終返却トランザクションが構成されネットワークに提出されるまで、生成されてよい。より具体的には、初期返却トランザクションTr,0のnLockTime値がSstopにより表され、nがUAとUBとの間で生成された実行中のオフブロック転送の中で生成された返却トランザクションの数であり、sが、ノードが前の返却トランザクションを提出する他のノードを危険にさらす前に、返却トランザクションに合意するための両方のパーティの持ち時間である場合、ノードは、新しい転送を交渉し続けることができる(ステップ216)。ここで、ステップ240で、t≦Sstop-i*sの間、(つまり、初期返却トランザクションのnLockTimeが経過していない間)、次の返却トランザクション毎に、最終返却トランザクションがブロックチェーンに提出されるまで、nLockTimeの値は減少されている。
【0051】
<階層構造トークン分配>
本開示は、ブロックチェーン内の特定アドレスにあるトークンを複数のアウトプットアドレスに分配する技術を記載する。初期アドレスにあるトークン量は、複数のサブ量に分割される。複数のサブ量は、次に、アウトプットアドレスのセットの間に分配される。本開示で提案されるトークン分配方式(階層型ト―クン分配方式、又はHierarchical Token Distribution scheme:HTD)は、(概念的「階層構造」の中のノードとして表される)参加ノード間の転送の「階層」構造を利用する。特に、HTDは、トークンを初期アドレスから、ノードの複数レベルの階層構造を通じて転送する。幾つかの場合には、HTDは、ブロックチェーンネットワーク内のトランザクションを匿名化するソリューションの一部として又はそれに加えて使用されてよい。HTDの一例は、図3~8を参照して以下に記載される。
【0052】
トークン分配の初期化
図4を参照すると、図4はHTDプロトコルのインスタンスを開始する例示的な処理400を示す。ノードは、HTDインスタンスに参加して、該ノードに関連付けられたアドレスにあるトークンを分割し分配できる。上述のように、HTDは、複数のノードを複数レベルの階層構造に概念的に構成することにより進行する。HTDの開始者は、ルートノードUとして表され、トークン分配のアウトプットアドレスは、階層構造の中のリーフノードとして表される。HTDインスタンスは、開始者自身により、又は異なるノード及び/又は制御システムにより管理されてよい。後者の場合、開始者は、ノード/制御システムにより提供されるHTDサービスを使用することを要求し得る。
【0053】
ステップ402で、HTDサービスの種々のパラメータを含む初期化データは、管理者及び/又は開始者により集められ又は選択されてよく、以下を含む:
・階層構造の中のノード当たりの固定ブランチ数(nb)。階層構造の中でリーフの無い各ノードが有する子/譲受側の数を示す。
【0054】
・アウトプット又は「リーフ」の数。少なくとも幾つかの実施形態では、アウトプットの数は、以下の関数の範囲無いの値の集合から選択されてよい。Leaves=f(nb,nl)=nb nl-1
【0055】
ここで、nl>2は階層構造の中のレベルの数であり、ルートノードはレベル1であり、最終レベルはリーフを含むレベルである。例えば、nb=2ならば、リーフの範囲は、Leaves={2,2,2,...,2nl-1}={4,8,16,...}である。
【0056】
ステップ404で、HTDは、階層構造の中の「ミキサノード」として動作する参加ノードのセットを募集する(recruit)。募集は、HTDの管理者及び/又は開始者により実行されてよく、又は募集は分散されてよい(例えば、参加ノードは、HTDに「選択されて(opt in)」、ミキサノードとして機能し、例えば自身の「ミキシング」サービスを提供するために支払を受け取ってよい)。ミキサノードは、ルートではない、階層構造の木構造の中の内部ノードである。各ミキサノードは、自身の「親」(又は上流)ノードから第1トークン数量を受け取り、該第1数量のサブ量を自身の「子」(又は下流)ノードへ転送するよう構成される。パラメータnb及びnlが与えられると、HTDインスタンスの階層構造の中のミキサノードの数nmixは、次式により計算されてよい。
【0057】
【数1】
幾つかの実施形態では、ミキサノードは、HTD内で「ミキシング」機能を提供してよい。ミキシングを促進するために、各募集された参加ノードは、少なくとも最小数(minx)のトークンを所有することを期待されてよい。ここで、minx=f(nl)である。この最小値は、ミキサノードが位置する、階層構造内のレベルに依存してよい。
【0058】
HTDプロトコルの主要な要素は、部分的完了のリスク及びその結果として所望のトークンの最終分配の実現に失敗すること無しに、プロトコルが完全に実施されることを保証する、セキュリティメカニズムの実装である。HTDのために必要なセキュリティを達成するために、ソリューションは、楕円曲線暗号の公開-秘密鍵関係の準同形特性を利用する。ここで、E(m)+E(n)=E(m+n)である。
【0059】
E(x)=xG及びGは、楕円曲線の基点である。プロトコルのセキュリティは、HTDの階層構造の中の親-子ノードペアの間の全てのトークントランザクションに対して「コミットメントチャネル」を使用すること、及びプロトコルの参加ノード間に確立されたコミットメントチャネルを介して開始者Urtにより制御が行われることに依存する。
【0060】
このセキュリティメカニズムを設定する際に、開始者は、先ず、ステップ406で、ランダム値(又は鍵)ksを選択し、ksGを計算する。ここで、Gは楕円曲線上の基点を表す。ksの値は、HTDを通じて開始者により秘密に保たれる。ステップ408で、全ての他の参加ノードUiは、それぞれのランダム値/鍵kiを選択し、この値を開始者へセキュアに送信する。ステップ410で、開始者は、次に、乱数値の集合{krt,i}を選択する。ここで、これらの乱数の各々は、階層構造のリーフ(アウトプット)ノードに対応する。つまり、開始者は、ランダム値kleafを各リーフノードに割り当てる。
【0061】
十分な数のミキシングノードがHTDサービスにより募集されると、開始者により選択されたアウトプット値又はリーフの数に基づき、ノードの階層構造が「構築される」。図3に、ノードの例示的な階層構造300が示され、ここで、nb=2であり、リーフの数nlは4に等しい。階層構造はルートノード302、8個のリーフノード304、及びルートノード302とリーフノード304との間の8個の異なるパスに沿った固有の位置に置かれた複数のミキサノード306を含む。ルートノード302に関連付けられたアドレスにある初期量のトークンは、階層構造300に基づき分配方式を用いてアウトプットリーフノード304に分配可能である。(一般性を失うことなく、以下の注釈は、本開示を通じてノードをラベル付けするために使用される。ノードがUijとラベル付けされた場合、Uijの親ノードはUiであり、Uijの子ノードはUijkであり、ここでk∈[1,nb]である。)。
【0062】
HTDの「階層構造」は、特定ブロックチェーンアドレスにある初期量のトークンの、複数の異なるアウトプットアドレスへの分配を生じる、参加ノード間のトークントランザクションのセットの表現である。特に、階層構造内のノードの相対位置は、初期アドレスのトークンを分配する際のHTDプロトコルにより使用されるトランザクションを定める。ルートノード以外の階層構造内の各ノードは、自身の親ノードからトークンの転送を受け取り、階層構造内の全ての非リーフノードは、自身の子ノードの各々へ、それぞれの量のトークンを転送する。より具体的には、階層構造内の各ミキサノードは、2種類のトランザクションに参加する。つまり(1)自身の親ノードから特定量xのトークンの転送を受け取り、(2)自身の子ノードへxのそれぞれのサブ量を転送する。したがって、階層構造内のノードの位置は、対応する参加ノードが関連するトランザクションのセットを完全に定める。
【0063】
HTDの匿名化能力における支援のために、様々なランダム化処理が、階層構造を構成する間に行われて、個々のミキシングノードの位置を決定してよい。ランダム化は、レベル毎に基づき行われてよい(つまり、参加ノードは、階層構造のあるレベルに指定されるが、該レベル内の位置はランダムに決定される)、或いは、ノードは階層構造内の任意のランダムなミキシングノード位置に置かれてよい。
【0064】
HTD内のミキサノードの階層的配置により、ランダム化の選択は、ミキサノードにおいて既に利用可能なトークン数量minxについての示唆を有する。ミキサノードがHTD中にトークンの転送をミキシングできるために、ミキサノードは、分配のためのトークンを受け取る前に、少なくとも最少量のトークンを処理すべきである。例えば、ミキサノードの募集中に制限が課されてよく、ミキサノードのうちの少なくとも1つが、nb個の別個のアドレスにおいて既に利用可能な該ミキサノードの子ノードに分配するよう依頼される数量と等価な数量のトークンを有することを要求する。これは、トークンが子ノードの間で分割されるべき比に依存して、ミキサノードが階層構造内で上位にいるほど、HTDに参加するために、より多くのトークンを処理しなければならないことを意味する(なぜなら、階層構造内でより上位にいるノードは分配のためにより多くのトークン数量を受け取るからである)。したがって、ミキサノードが階層構造の特定レベルのために募集された場合、ランダム化は、階層構造の該レベルに渡り「水平方向に」ノードを移動することに制限され、レベルはそれ自身のminx値を有する。他方で、ミキサノードがレベルに関して制限無く募集された場合、ミキサノードは、階層構造のミキシングレベルのうちの任意のレベルの任意の位置にランダムに位置付けることができ、全てのミキシングノードについてminx値は共通であり得る。
【0065】
ステップ412で階層構造内のミキサノードの位置を決定すると、開始者は、ステップ414で、ルートノード及びリーフノードを含む階層構造を(概念的に)構成し、ステップ416で、各参加ノードUiに、ミキシングノードがトークンを受け取ることを期待するノード、及びミキシングノードがそれぞれトークンを転送する予定であるノードを通信する。
【0066】
<HTDにおけるコミットメントチャネル>
階層構造の設計が確立され、各参加ノードが彼らそれぞれの譲渡側(上流ノード)及び譲受側(下流ノード)を認識すると、一方向コミットメントチャネルのセットが全ての参加ノードとそれらの譲受側との間に設定される。HTDにおける親-子ノードペアの間の全てのトークントランザクションは、「コミットメントチャネル」の使用を通じて達成される。HTDでは、コミットメントチャネルは、3つの別個のトランザクション、つまりコミットメントトランザクションTc、返却トランザクションTr,0、及び転送トランザクションTt、により定められる。図5Aは、3つのトランザクションの間の関係を示す概略図を示す。したがって、一般性を失わずに、HTDにける譲渡側ノードUiから譲受側ノードUijへのトークンの各転送では、以下の3つのブロックチェーントランザクションが生成される。
・コミットメントトランザクションTcは、UiがUijへの転送のためにトークンのセットxをコミットするために利用する2-of-2マルチシグネチャP2SHトランザクションである。該転送は以下のいずれかにより制御される:
2-of-2マルチシグネチャ(Ui,Uij)、又は、
シークレット値svijの知識、及びUijの署名。
・返却トランザクションTr,0は、前にコミットされたトークンxをUiに返す。このトランザクションは、特定時点の後に、ブロックチェーンに提出する資格を有するようになる。返却トランザクションの実行に成功するために、ユーザUi及びUijの署名が必要である。
・転送トランザクションTtは、コミットされたトークンxをUijへ実際に送信する。このトランザクションの実行に成功するために、シークレット値svijの知識及びユーザUijの署名が必要である。
【0067】
HTDの部分として生成された各コミットメントチャネルは、トークンの任意の転送を受け取るために譲受側が提供しなければならないシークレット値により「ロック」される。図5Bに、譲渡側ノードUiと譲受側ノードUijとの間のコミットメントチャネルUi→Uijを構成する例示的な処理500が示される。
1.工程502:譲受側Uijは、ランダム値kijを選択する。各コミットメントチャネルは、外部ノードがトランザクションのセットをHTDの同じインスタンスの要素であると関連付けできることを一層困難にするために、異なる乱数を利用してよい。特に、ブロックチェーン内に見える異なるトランザクションをHTDの共通インスタンスにリンクできることは、トランザクションが必ずしも全て同じシークレットでタグ付けされないので、一層複雑にできる。
2.工程502:譲受側Uijは、kijの値をUiに通信する。
3.工程504:譲渡側Uiは、関係Qij=Qi+kijG=svijGを用いて、シークレット値svijの暗号化バージョンQijを計算する。
4.工程506:譲渡側Uiは、暗号化された値Qijを利用し、コミットメントトランザクションTcを生成する。コミットメントトランザクションTcは、(1)Ui及びUijの両者の署名、又は(2)svij及びUijの署名、のいずれかによってのみ転送可能なトークン数量xをコミットする。
5.工程508:譲渡側Uiは、返却トランザクションTr,0を生成する。返却トランザクションTr,0はコミットされた価値xをUiに戻す。返却トランザクションは、パラメータnLockTimeを含む。nLockTimeは、時点であって、その時点で又はその時点より後に、返却トランザクションがブロックチェーンに提出する資格を有するようになる時点を指定する。提案されたnLockTime値は次式のように計算されてよい。
【0068】
【数2】
ここで、nlは階層構造内のレベルの数であり、level(Ui)は階層構造内のUiのレベルであり、Sはブロックチェーンネットワークに提出されたノードへの第1転送の開始時間であり、sは、各Uiがコミットメントチャネルを構成するために及びトークンをUiに転送し及び転送トランザクションTtをブロックチェーンネットワークに提出するコミットメントチャネルのための必要なシークレット値を検索するために与えられた時間量を表す、HTDサービスにより選択された時間値である。
6.工程510:譲受側Uijは返却トランザクションに署名する。
7.工程512:譲渡側Uiは、コミットメントトランザクションTcに署名し、それをブロックチェーンに提出する。
8.工程514:転送トランザクションTtが生成される。転送トランザクションTtは、コミットメントトランザクションのコミットされたトークンxをUijへ転送する。転送トランザクションのためのアンロックスクリプト又は<scriptSig>は、転送トランザクションがブロックチェーンへの提出に成功するならば、値svijを含む必要がある。
【0069】
HTDでは、第1コミットメントチャネルUi→Uijを介して受信されたトークンは、幾つかのサブ量に分けられる。該幾つかのサブ量は、一方で、nb個の第2コミットメントチャネルUij→Uijkを介して転送される。子ノードへの転送のために、各非リーフノードにおいてトークン数量を分割することは、それぞれのノードの値割り当て方式により制御されてよい。例えば、あるノードの値割り当て方式は、該ノードにおいて受信されたトークン数量が該ノードの子ノードの間で分割され得る比(例えば、50:50、40:35:25、等)を示してよい。値割り当て方式は、階層構造内の非リーフノード毎に独立に決定されてよい。又は同じ値割り当て方式が全ての非リーフノードに適用されてよい。幾つかの実施形態では、所望のサブ量がHTD階層構造内のそれらそれぞれの宛先(アウトプット)アドレスに到着することを保証するために、値割り当て方式が利用されてよい。
【0070】
HTD内でミキサノードとしてサービスを提供する参加ノードは、自身が、分配処理の中で該ノードが自身の子へ転送したサブ量の和に少なくとも等しいトークン数量の転送を、自身の上流(親)ノードから受け取ることを保証したいと望み得る。これは、トランザクションのいずれかをノードが途中で中止する又は取り消すことを可能にしないで、プロトコルのトランザクションが完了することを保証することを助けることにより、コミットメントチャネルの使用が、HTD参加ノードにセキュリティ手段を提供できる場合である。Urtからリーフノードへの経路を追跡する階層構造内の全てのパスについて、親-子ノードペアの間のコミットメントチャネルは、特定の順序で生成される。特に、コミットメントチャネルUi→Uijは、任意のコミットメントチャネルUij→Uijkの前に生成される。つまり、トークンをユーザUijへ転送するトランザクションのためのコミットメントチャネルは、UijからUijkへ転送するトランザクションのいずれのコミットメントチャネルより前に確立される。この順序付きシーケンスは、Uijが自身の譲受側Uijkのうちの少なくとも1つへの転送を行う場合に、ノードUijが、転送を危険にさらす/生成する前に、Uijが実行に成功できるUijへのTtトランザクションが存在することを保証することを可能にする。
【0071】
少なくとも幾つかの実施形態では、HTDにおける転送トランザクションのうちの1つ以上に関連付けられたトランザクション「コスト」が存在する。さらに、プロトコルに参加するミキサノードは、彼らのミキシングサービスを提供する前に、トークンの受け取りを要求する可能性がある。例えば、ミキサノードのうちの少なくとも1つの各々について、ミキサノードのサービスを起動するために(例えば、トークンのミキシングのためにノードのリソースを結集する及び/又は制御するために)、特定量のトークンがミキサノードへ転送される必要がある。これらの「コスト」は、リーフノードにおける所望の/期待されるトークンアウトプットの観点で、HTDに導入されるべきトークンの量について決定するとき、開始者により考慮され得る。
【0072】
一例として、ミキサノードUijへのトークンの転送が、ノードの受け取ったトークンの割合として見え、UijがUijの譲受側へ転送しなければならないトランザクションコストを含むと仮定すると、HTDにおけるトランザクションセットのための合計ミキサノードコストCmixは次式により表せる。
【0073】
【数3】
ここで、sはミキサノードから取り込まれた転送されたトークンの率/割合であり、xはU0において「デポジットされた」量であり、nlは階層構造内のレベルの数である。ミキサノードは、レベル2で開始し、リーフの前のレベルで終了する。したがって、含まれるレベルの数は、nm=nl-2である。関数Cmix(s,x)は、トークン転送が分割される比とは独立である。
【0074】
<コミットメントチャネルのシークレット値>
各コミットメントチャネルUi→Uijは、譲受側が、コミットメントチャネルを介してトークンを受け取るために、シークレット値svijを提供することを要求する。HTDプロトコルでは、開始者は、トークン分配処理の部分として実施される(親-子ノードペアの間の)全ての転送処理に対して制御を行う。シークレット値svijは、コミットメントチャネルを「ロック」するよう機能し、開始者がリーフノードへトークンを転送するためのコミットメントチャネルが生成されたことを確信するまで、参加ノードのいずれかによるトークンの引き出しを防ぐ。HTDの階層構造に沿った任意の場所に位置するコミットメントチャネルUi→Uijのシークレット値は、以下の処理に従い取得されてよい。
1.Uijは、自身の乱数kij(HTDの初期化中にUijにより選択され、図4の処理400の工程408に示される)をUiに通信し、Uiは自身のシークレット鍵の暗号化バージョンQiをUijに通信する。ここで、Qi=sviGである。
2.コミットメントチャネルUi→Uijのシークレット値は、svij=svi+kijになる。
ここで、これの暗号化された値は、Qij=Qi+kijGである。シークレット値svijは、反復的に定められ、sv=ksで開始する。
3.このシークレット値svij=ks+ka+kb+…+kij、ここでks,ka,kb,…,kiは、同じパスの中のコミットメントチャネルUi→Uijの前のコミットメントチャネルの参加ノードにより選択された乱数である。これは、以下の計算から分かる。Qij=Qi+kijG=(ksG+kaG+kbG+...+kiG)+kijG=(ks+ka+kb+...+kij)G
このとき、開始者がksを秘密に保持しており、HTD内のいずれの他のノードに知られていないので、ノードUijはコミットメントチャネルのシークレット値を知らない。より一般的には、HTDの転送トランザクションのいずれも、開始者がシークレット値ksを開示せずにば開始できない。
【0075】
<HTDのトランザクションの実行>
図6を参照すると、図6は、HTDの参加ノードにより生成されたコミットメントチャネルの転送トランザクションを実行する例示的な処理600を示す。上述のように、分配の開始者Uは乱数値kiを階層構造の全てのノードから受信し、したがって全部のシークレット値を所有している。(HTD内で使用されるコミットメントチャネルのシークレット値はsvij=ks+ka+kb+...+kijにより定められることを思い出す)。時間Sで又はその前に全てのコミットメントチャネルが生成されたならば、開始者は、HTDのコミットメントチャネルの全部のシークレット値の順次的開示を開始する。特に、ステップ602で、開始者は、対応するリーフノードに至る階層構造内の(連続的なコミットメントチャネルの)ユニークなパスの各々について、svfinal=ks+ka+kb+...+kz+kleafにより与えられる「最終」シークレット値svfinalを開示する。開始者は、svfinal値を対応するUzノード(つまり、パスの中のUleafの親)へ直接通信することによりこれを行うことができる。或いは、開始者は、転送トランザクションTt:Uz→Uleaf(開始者もリーフノードを有するので)を提出でき、それにより、がシークレット値svfinalをブロックチェーンから取り出すことを可能にする。ステップ604で、トークンをリーフノードへ転送するためのコミットメントチャネルのnLockTimeが経過していないことをチェックすると、ステップ604で、開始者は、Tt:Uz→Uleafをブロックチェーンに提出する。
【0076】
ステップ606でUzがsvfinal値を取得すると、ステップ608で、Uzは、svfinalから(Uleafによりその親Uzへと前に通信された)kleafを単に抽出でき、Uzが自身の親ノードからトークンを受け取るために必要なシークレット値であるsvzを決定する。より一般的には、各ノードUijkは、値svijkを自身の譲渡側Uijに直接通信してよい。或いは、Uijkがそうすることに失敗した場合、ノードUijは、トークンをUijへ転送する転送トランザクションのnLockTime値が終了する前に、ブロックチェーン台帳の中の値svijkを取り出そうと試みる。
【0077】
このように、シークレット値svijは、(ステップ608~622を通じて)順次的に開示される。一方で、階層構造内のパスを上へと移動すること及び関係svij=svijk-kijkを使用することにより、現在時間は次式より小さい。
【0078】
【数4】
svij値は、ノードUijがTt:Ui→Uijによりトークンを受け取ることを可能にする。この順次的開示手順の重要な結果は、特定のコミットメントチャネルのシークレット値が、コミットメントチャネルがHTDの階層構造内で共有されるパスのうちのいずれかを用いて決定できることである。各コミットメントチャネルは、(転送トランザクションのアンロックスクリプト<scriptSig>に含まれる)1つのシークレット値のみを有する。HTDの階層構造を表す木構造の中の「エッジ」(つまり、親-子ノードペアの間のコミットメントチャネル)は、該「エッジ」を含む全てのパスにより共有されるので、該「エッジ」に対応するコミットメントチャネルに関連付けられたシークレット値の計算は、該コミットメントチャネルを共有するパスのうちのいずれかを用いて実行されてよい。これは、また、ノードUijが、自身のnb個の子ノードのうちの1つ以上が彼らのトークンをUijから受け取る前に、Uiから自身のトークンを受け取ることができることを示唆する。特に、Uijは、1人の譲受側がトークンをUijから引き出した場合でも、自身の満期の全部のトークンをUiから受け取ることができる。各ノードUijは、したがって、Uijが自身の子ノードUijkのうちの少なくとも1つへトークンの転送を行った場合、トークンを受け取る能力を保証される。HTDの転送トランザクションの全部が完了スト、トークンの元のセットは、リーフノードのインプットアドレスへ分配される。
【0079】
<トークンの返却>
返却トランザクションのブロックチェーンへの提出は、返却トランザクションがブロックチェーンにより受け付けられるべきではない時間期間であるnLockTime値により制限される。HTDでは、提案されるnLockTimeの値は次式により与えられる。
【0080】
【数5】
譲受側Uijkが返却トランザクションTr,0:Uij→UijkのnLockTimeの終了前にシークレット値svijkを開示することに失敗した場合、譲渡側Uijは、返却トランザクションをブロックチェーンに提出してよい。この返却トランザクションの提出に成功した場合、譲渡側Uijと譲受側Uijkとの間のコミットメントチャネルの転送トランザクションTt:Uij→Uijkは、決して実行できない。少なくとも1つの返却トランザクションがブロックチェーンに提出された場合、返却提出処理が、階層構造のレベルを通じて上へと開始者Uまで及びそれを含むまで、繰り返される。
【0081】
<匿名性の検討>
上述のように、ミキサノードは、HTDの複数レベルの階層構造を通じてトークンを分配する間、トークンをミキシングする機能を提供してよい。つまり、ミキサノードは、トークンのフローの追跡を一層困難にし得る。これを行うことのできる1つの方法は、(親ノードから)トークンの受け取られる及びミキサノードがそれらの子ノードへトークンを渡すことのできるアドレスと異なる予め存在するアドレスを、ミキサノードが有することを保証することによる。図7に、このシナリオの一例が示される。図7では、Uijは、UijがトークンをUiから受け取るアドレス(Addr_P1)、及び子ノードUijkへ渡されるべき十分な数量のトークンが既に利用可能である別個のアドレス(Addr_P2)を有する。ノードにおけるトークン量の受け取りとノードからのサブ量の転送とを分離するために、ミキサノードのこれらの別個のアドレスを用いることは、HTDにおける匿名性の利益を生じる可能性がある。少なくとも幾つかの実施形態では、HTDプロトコルは、異なる支払受け取りアドレスを有する最少数のミキサノードしか必要としないよう設計されてよい。例えば、HTDの開始者及び/又は管理者は、階層構造の各パスの中の少なくとも1つのミキサノードが異なる転送受け取りアドレス規定を順守することを強制してよい。
【0082】
ここで図8を参照する。図8は、ブロック図の形式で、参加ノード800の簡略化された例を示す。ノード800は、インプットノード又はアウトプットノードであってよい。ノード800は、1つ以上のマイクロプロセッサ、特定用途向け集積回路(ASIC)、マイクロコントローラ、又は同様のコンピュータ処理装置を含み得るプロセッサ802を含む。ノード800は、永久及び非永久メモリを含み得る、値、変数、及び幾つかの例ではプロセッサ実行可能プログラム命令を格納するメモリ804、並びに、有線又は無線ネットワークを介してネットワーク接続を提供するネットワークインタフェース806、を更に含む。
【0083】
ノード800は、実行されるとプロセッサ802に本願明細書に記載の機能又は動作のうちの1つ以上を実行させるプロセッサ実行可能命令を含むプロセッサ実行可能ブロックチェーンアプリケーション808を含む。
【0084】
本願明細書に記載の装置及び処理、並びに、参加ノードを構成する記載の方法/処理を実施するモジュール、ルーチン、プロセス、スレッド、アプリケーション、又は他のソフトウェアコンポーネントは、標準的なコンピュータプログラミング技術及び言語を用いて実現されてよい。本願は、特定のプロセッサ、コンピュータ言語、コンピュータプログラミング技法、データ構造、及び他のこのような実装の詳細に限定されない。
【0085】
留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する(comprising又はcomprises)」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する(comprises)」は「含む(includes)又は構成される(consists of)」を意味し、「有する(comprising)」は「含む(including)又は構成される(including of)」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、1つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組合せが有利に用いることができないことを示すものではない。
【符号の説明】
【0086】
100 ブロックチェーンネットワーク
102 ノード
図1
図2
図3
図4
図5A
図5B
図6
図7
図8
【外国語明細書】