特表 2022-544321 非中央集権型トランザクション通信プロトコルのための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-10-17

(54)【発明の名称】非中央集権型トランザクション通信プロトコルのための方法およびシステム

(51)【国際特許分類】

   G06F 9/46 20060101AFI20221007BHJP

   H04L 9/32 20060101ALI20221007BHJP

【ＦＩ】

G06F9/46 430

H04L9/32 200Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022509682

(86)(22)【出願日】2020-08-17

(85)【翻訳文提出日】2022-04-14

(86)【国際出願番号】 CA2020051124

(87)【国際公開番号】W WO2021030906

(87)【国際公開日】2021-02-25

(31)【優先権主張番号】62/888,091

(32)【優先日】2019-08-16

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】PCT/CA2020/050056

(32)【優先日】2020-01-20

(33)【優先権主張国・地域又は機関】CA

(31)【優先権主張番号】PCT/CA2020/051065

(32)【優先日】2020-08-05

(33)【優先権主張国・地域又は機関】CA

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

(71)【出願人】

【識別番号】521155900

【氏名又は名称】ゼットイーユー・テクノロジーズ・インコーポレイテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ジャン－フィリップ・ボーデ

(72)【発明者】

【氏名】パトリシア・ポパール－フォルティア

(72)【発明者】

【氏名】ユミン・キアン

(57)【要約】

スマートコントラクトなしの複数の参加者の間でのトランザクションの分散型決済のためのシステムおよび方法が開示される。方法は、複数のノードを各々が有する複数のブロックチェーンと、トランザクションのすべての動作がコミットまたはロールバックされるように、ノード間でメッセージを転送し、ステータス値を維持するためのコーディネータとを含むシステムを利用する。方法は、参加者のうちの1人から生成されたトランザクションに関する要求を受信するステップと、ビルボード上にトランザクション要求を投稿するステップと、ビルボードからノードによるトランザクション要求を読み取るステップと、参加者間を同期するステップと、要求をコミットするかまたはロールバックするために、参加者からのトランザクション投票を受信するステップと、トランザクションをコミットするか、または要求をロールバックすることによって、トランザクション投票に基づいてトランザクションを実行するステップとを含む。

【特許請求の範囲】

【請求項1】

スマートコントラクトのないシステムにおける複数の参加者の間でのトランザクションの分散型決済のための方法であって、前記システムが、複数のノードを各々が有する複数のブロックチェーンと、前記トランザクションのすべての動作がコミットまたはロールバックされるように、前記トランザクションを調整するために前記ノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータとを備え、前記方法が、
a)前記複数の参加者のうちの1人から生成された前記トランザクションに関する要求を受信するステップと、
b)前記トランザクション要求をビルボード上に公に投稿するステップと、
c)前記ビルボードから前記複数のノードによる前記トランザクション要求を読み取るステップと、
d)準備フェーズにおいて、前記参加者間で同期し、前記準備フェーズの検証を確認するために投票するステップと、
e)コミットフェーズにおいて、前記要求をコミットするかまたはロールバックするために前記参加者からトランザクション投票を受信するステップと、
f)トランザクションをコミットするかまたは前記要求をロールバックすることによって、前記トランザクション投票に基づいて前記トランザクションを実行するステップと
を含む、方法。

【請求項2】

前記複数のノードの各々においてローカル仮想マシンを実行するステップをさらに含む、請求項1に記載の方法。

【請求項3】

前記同期するステップが、少なくとも一意のハッシュを交換するステップを含む、請求項1に記載の方法。

【請求項4】

前記システムにおいてビザンチンフォールトトレラントプロトコルが使用される、請求項1に記載の方法。

【請求項5】

前記ノードによって計算されたタイムアウト遅延が前記トランザクションのロールバックを引き起こす、請求項4に記載の方法。

【請求項6】

複数の参加者が、第1のプロトコルと第2のプロトコルとを同時に使用して、資産およびデータのうちの1つまたは複数を交換することを可能にするシステムであって、前記システムが、
複数のブロックチェーンであって、各ブロックチェーンが複数のノードを有する、複数のブロックチェーンと、
トランザクションのすべての動作がコミットまたはロールバックされるように、前記トランザクションを調整するために前記ノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータと
を備え、前記システムが、
a)前記複数の参加者のうちの1人から生成された前記トランザクションに関する要求を受信するステップと、
b)前記トランザクション要求をビルボード上に公に投稿するステップと、
c)前記ビルボードから前記複数のノードによる前記トランザクション要求を読み取るステップと、
d)準備フェーズにおいて、前記参加者間で同期し、前記準備フェーズの検証を確認するために投票するステップと、
e)コミットフェーズにおいて、前記要求をコミットするかまたはロールバックするために前記参加者からトランザクション投票を受信するステップと、
f)トランザクションをコミットするかまたは前記要求をロールバックすることによって、前記トランザクション投票に基づいて前記トランザクションを実行するステップと
を実行するように適合された、システム。

【請求項7】

前記同期すると、各参加者は、他の各参加者の公開鍵とWebSocketとを有する、請求項6に記載のシステム。

【請求項8】

前記同期すると、各参加者は、前記トランザクションに関連するトランザクション要求オブジェクトのハッシュを有する、請求項7に記載のシステム。

【請求項9】

並列化、マルチスレッド、およびチェーントランザクションのうちの少なくとも1つを使用して、オフチェーントランザクションのためのスケーラビリティをさらに可能にする、請求項6に記載のシステム。

【請求項10】

前記複数のノードの各々が、双方向通信チャネルを介して前記ビルボード上の投稿をリッスンする、請求項6に記載のシステム。

【請求項11】

前記双方向通信チャネルがWebSocketである、請求項10に記載のシステム。

【請求項12】

前記システムが、プロトコルに依存せず、現在存在する、または将来存在するスマートコントラクトを伴う、または伴わない、任意の許可ベースの公開台帳を扱うことができる、請求項6に記載のシステム。

【請求項13】

トランザクション通信プロトコルと分散型合意メカニズムとをさらに備える、請求項6に記載のシステム。

【請求項14】

ビザンチンフォールトトレラント(BFT)プロトコルを備える、請求項6に記載のシステム。

【請求項15】

未使用トランザクションアウトプット(UTXO)証明が使用される、請求項14に記載のシステム。

【請求項16】

前記トランザクションの遅延がフォールトトレランスしきい値を超えた場合、ロールバックコミットメントが実行される、請求項15に記載のシステム。

【請求項17】

前記システムが、非中央集権化され、コミッションが前記チェーンのサイズとともに増加するインセンティブモデルを前記ノードに提供する、請求項6に記載のシステム。

【請求項18】

前記システムがアルゴリズムに依存しない、請求項6に記載のシステム。

【請求項19】

システムに動作を実行させるように適合された内容を有する非一時的コンピュータ可読媒体であって、前記システムが、複数のブロックチェーンであって、各ブロックチェーンが複数のノードを有する、複数のブロックチェーンと、トランザクションのすべての動作がコミットまたはロールバックされるように、前記トランザクションを調整するために前記ノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータとを含み、前記動作が、
a)前記複数の参加者のうちの1人から生成された前記トランザクションに関する要求を受信する動作と、
b)前記トランザクション要求をビルボード上に公に投稿する動作と、
c)前記ビルボードから前記複数のノードによる前記トランザクション要求を読み取る動作と、
d)準備フェーズにおいて、前記参加者間で同期し、前記準備フェーズの検証を確認するために投票する動作と、
e)コミットフェーズにおいて、前記要求をコミットするかまたはロールバックするために前記参加者からトランザクション投票を受信する動作と、
f)トランザクションをコミットするかまたは前記要求をロールバックすることによって、前記トランザクション投票に基づいて前記トランザクションを実行する動作と
を含む、非一時的プロセッサ可読媒体。

【請求項20】

前記内容が、ビザンチンフォールトトレラント(BFT)プロトコルを実装するための動作をさらに含む、請求項19に記載の非一時的プロセッサ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、2019年8月16日に出願した「Method and System for a Decentralized Transactional Communication Protocol」と題する米国仮出願第62/888,091号、および2020年8月5日に出願した「Distributed Blockchain Transaction System」と題する国際出願番号PCT/CA2020/051065の利益を主張するものであり、これらの各々の内容は、参照により本明細書に組み込まれる。本出願はまた、2020年1月20日に出願した「A Method for Generating Random Numbers in Blockchain Smart Contracts」と題する国際出願番号PCT/CA2020/050056の利益を主張するものであり、その内容は、参照により本明細書に組み込まれる。

【0002】

本出願は、一般に、ブロックチェーンシステムに関し、特に、複数のブロックチェーンを用いる分散型ブロックチェーントランザクションに関する。

【背景技術】

【0003】

ブロックチェーンシステムは、参加者の間の集合的な参加および合意によって、トランザクションの信頼できる記録を維持する。ブロックチェーンは、ノードと呼ばれる複数のネットワークデバイスによって共同で維持される分散型台帳技術(DLT)として説明され得る。したがって、ブロックチェーンは、分散型耐タンパー性ストレージシステムと考えられ得る。

【0004】

ブロックチェーン上のトランザクションは、いくつかの異なる参加者の間の分散型合意通信を必要とする。これらの参加者は、互いを知り、信頼する必要はない。参加者は、複数のトランザクション要求とチェーントランザクション決済とを同時に実行することもできる。これは、参加者がトランザクション要求入札を生成するべきであり、第三者がトランザクションチェーン入札を生成するべきである非常に非同期的な環境を作成する。さらに、これらは、システムの信頼できない特性を損なうことなく行われるべきである。

【0005】

このような環境における、特に参加ノードからの分散サービス妨害(DDOS)攻撃、悪意のあるコード注入、または他の悪意のある動作などの悪意のある活動を防止するために、トランザクション要求とトランザクションチェーンとを扱う層は、依然として非同期で対話することができながら、異種でなければならない。

【0006】

それに加えて、分散型トランザクションシステムは、スケーラブルであるべきである。歴史的に、分散型台帳技術(DTL)の最も重要な問題の1つは、これらのネットワークのスケーラビリティである。スケーラビリティは、一般に、処理され得る時間単位あたりのトランザクション数、たとえば、1秒あたりのトランザクション(TPS)によって近似される。ライトニングネットワークおよびステートチャネルなどのいくつかの技術は、この問題を解決することを目的としているが、一般的に1つまたは多くても数個のプロトコルにしか関連付けられないこれらの技術が構築されるプロトコル中心の方法に起因する制限が存在する。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】米国特許出願第62/794,336号

【発明の概要】

【発明が解決しようとする課題】

【0008】

したがって、ブロックチェーンベースのシステムにおける前述の問題の少なくともいくつかを軽減する改善されたシステムおよび方法に対するニーズが存在する。

【課題を解決するための手段】

【0009】

本発明の一態様によれば、スマートコントラクトのないシステムにおける複数の参加者の間でのトランザクションの分散型決済のための方法が提供され、システムは、複数のノードを各々が有する複数のブロックチェーンと、トランザクションのすべての動作がコミットまたはロールバックされるように、トランザクションを調整するためにノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータとを含み、方法は、複数の参加者のうちの1人から生成されたトランザクションに関する要求を受信するステップと、トランザクション要求をビルボード上に公に投稿するステップと、ビルボードから複数のノードによるトランザクション要求を読み取るステップと、準備フェーズにおいて、参加者間で同期し、準備フェーズの検証を確認するために投票するステップと、コミットフェーズにおいて、要求をコミットするかまたはロールバックするために参加者からトランザクション投票を受信するステップと、トランザクションをコミットするかまたは要求をロールバックすることによって、トランザクション投票に基づいてトランザクションを実行するステップとを含む。

【0010】

本発明の別の態様によれば、複数の参加者が、第1のプロトコルと第2のプロトコルとを同時に使用して、資産およびデータのうちの1つまたは複数を交換することを可能にするシステムが提供され、システムは、複数のブロックチェーンであって、各ブロックチェーンが複数のノードを有する、複数のブロックチェーンと、トランザクションのすべての動作がコミットまたはロールバックされるように、トランザクションを調整するためにノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータとを備え、システムは、複数の参加者のうちの1人から生成されたトランザクションに関する要求を受信するステップと、トランザクション要求をビルボード上に公に投稿するステップと、前記ビルボードから前記複数のノードによるトランザクション要求を読み取るステップと、準備フェーズにおいて、前記参加者間で同期し、準備フェーズの検証を確認するために投票するステップと、コミットフェーズにおいて、要求をコミットするかまたはロールバックするために参加者からトランザクション投票を受信するステップと、トランザクションをコミットするかまたは要求をロールバックすることによって、トランザクション投票に基づいてトランザクションを実行するステップとを実行するように適合される。

【0011】

本発明の別の態様によれば、システムに動作を実行させるように適合された内容を有する非一時的コンピュータ可読媒体が提供され、システムは、複数のブロックチェーンであって、各ブロックチェーンが複数のノードを有する、複数のブロックチェーンと、トランザクションのすべての動作がコミットまたはロールバックされるように、トランザクションを調整するためにノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータとを含み、動作は、複数の参加者のうちの1人から生成されたトランザクションに関する要求を受信する動作と、トランザクション要求をビルボード上に公に投稿する動作と、ビルボードから複数のノードによるトランザクション要求を読み取る動作と、準備フェーズにおいて、参加者間で同期し、準備フェーズの検証を確認するために投票する動作と、コミットフェーズにおいて、要求をコミットするかまたはロールバックするために参加者からトランザクション投票を受信する動作と、トランザクションをコミットするかまたは要求をロールバックすることによって、トランザクション投票に基づいてトランザクションを実行する動作とを含む。

【0012】

本発明の一態様によれば、複数の参加者が、同じプロトコルから、他のプロトコルと同時に、かつオフチェーンで、資産/データを交換することを可能にし、したがって、ライトニングネットワークまたはステートチャネルの代替となるシステムが提供される。

【0013】

本発明の別の態様によれば、システムは、並列化、マルチスレッド化、およびチェーントランザクションを使用して、オフチェーントランザクションのためのスケーラビリティを可能にする。

【0014】

本発明の別の態様によれば、システムは、プロトコルに依存せず、現在存在する、または将来存在するスマートコントラクトをサポートする、またはしない、任意の許可ベースの公開台帳を扱うことができる。

【0015】

本発明の別の態様によれば、システムは、トランザクション通信プロトコルと分散型合意メカニズムとを使用する。

【0016】

本発明の別の態様によれば、システムは、任意のチェーントランザクションの遅延がフォールトトレランスしきい値を超えた場合、ロールバックコミットメントが実行されるので、未使用トランザクションアウトプット(UTXO(Unspent Transaction Output))証明とビザンチンフォールトトレランス(Byzantine Fault Tolerance)方法とを使用する。

【0017】

本発明の別の態様によれば、システムは、非中央集権化され、最適化されたチェーントランザクションのためのインセンティブ付与(incentivization)モデルを有するノードを使用する。チェーンが大きいほど、コミッションの割り当ては、よくなる。

【0018】

本発明の別の態様によれば、ノードのシステムは、アルゴリズムに依存せず、参加者が、システムの経済モデルよってサポートされる、より良い性能のモデルを自分で作成することを可能にする。

【0019】

本発明の実施形態を例としてのみ示す図において、

【図面の簡単な説明】

【0020】

【図1】アトミックスワップインフラストラクチャ層を示す概略ブロック図である。

【図2】参加者がビルボードオブジェクト(BBo(Billboard Object))にトランザクション要求を投稿することを示す概略ブロック図である。

【図3】ノードがtxRequest ABIを読み取ることを示す概略ブロック図である。

【図4】参加者がどのように一意のハッシュを交換するかを示す概略ブロック図である。

【図5】参加者が同期されていることをどのように承認するかを示す概略ブロック図である。

【図6】参加者が準備フェーズステータスを投票することを示す概略ブロック図である。

【図7】成功投票をプロンプトとして使用してエスクローマルチシグウォレットを初期化する方法を示す概略ブロック図である。

【図8】コミットフェーズが参加者によって実行されることを示す概略ブロック図である。

【図9】ノードまたは参加者の検証を示す概略ブロック図である。

【図10】検証投票を示す別の概略ブロック図である。

【図11】実行フェーズを示す概略ブロック図である。

【図12】TxChainクリーニングフェーズを示す概略ブロック図である。

【図13】ロールバックを示す概略ブロック図である。

【図14】ノード経済モデルを示す図である。

【図15】txRequests入札の細分化を示す図である。

【図16】トランザクションブリッジ(txBridge)-ブリッジ初期化を示す図である。

【図17】トランザクションブリッジ(txBridge)-レシート交換を示す図である。

【発明を実施するための形態】

【0021】

本開示は、分散型合意と、アトミックトランザクションフレームワークと、未使用トランザクションアウトプット(UTXO)と、ビザンチンフォールトトレランス標準とを使用して、TCP/IP(伝送制御プロトコル/インターネットプロトコル)によく似た高スケーラブルスマートコントラクトレス通信プロトコルを作成する方法について説明する。

【0022】

プロトコルは、ZeU Crypto Networks Inc.のアトミックスワップのクロスチェーン、マルチチェーンの特殊性を活用し、その内容が参照により本明細書に組み込まれる、2019年8月6日に出願した、「Distributed Blockchain Transaction System」と題する、上記の米国仮特許出願第62/883,531号において説明されているようなクロスチェーントランザクションを完了するための方法およびシステムに少なくとも部分的に依存する。

【0023】

スマートコントラクトは、刺激的で強力な技術であるが、歴史的に、スケーラビリティと相互運用性の制限を有していた。システムが特定のプロトコルと統合されると、システムを別のプロトコルに移植することは困難である。資産またはデータの高スループットの交換の文脈において、基礎となるプロトコルに関連するコストおよび遅延は、デジタル資産コストに関連するコストを資産の変動性によって変動させる可能性がある。

【0024】

ブロックチェーンにおける各トランザクションは、新しい所有者に関する支出可能な金額の合計として機能する1つまたは複数のトランザクションアウトプット(TXO)を有する。これらの未使用の合計は、未使用トランザクションアウトプット(UTXO)と呼ばれる。新しい所有者が他の誰かに支払うためにそれらを償還するまで、それらは、UTXOのままである。

【0025】

前述のように、トランザクション分散型合意通信は、互いを知らないまたは信用しないn人の参加者によって行われるが、複数のトランザクション要求とチェーントランザクション決済とを同時におよび/または連続して実行し得る。これは、参加者がトランザクション要求入札を生成するべきであり、第三者がトランザクションチェーン入力を生成するべきである非常に非同期の環境を作成するが、信頼性のないアーキテクチャまたはインフラストラクチャの約束に違反することはない。

【0026】

さらに、特に参加ノードからの分散サービス妨害(DDOS)攻撃、悪意のあるコード注入、または他の形態のサイバー攻撃を防止するために、トランザクション要求およびトランザクションチェーン層は、依然として非同期で対話することができながら、異種でなければならない。

【0027】

分散型台帳技術(DTL)の最も重要な問題の1つは、それらのネットワークのスケーラビリティである。性能スケーラビリティは、一般に、ネットワークが任意の所与の時間において処理することができる1秒あたりのトランザクション数(TPS)の点から測定され得る。ライトニングネットワークおよびステートチャネルなどの解決策は、この問題を解決するための試みである。制限は、一般的に単一のプロトコルまたは限られた数のプロトコルにのみ関連付けられる技術が構築されるプロトコル中心の方法に起因する。

【0028】

本発明の実施形態の例示的な少なくともいくつかの方法は、公開または許可ベースの台帳上に展開されるスマートコントラクトの必要性を除去する。ハッシュ交換合意メカニズムは、資産およびデータのうちの1つまたは複数の交換を仮想化する将来性のある方法を作成するために活用される。本明細書で説明される方法の例示的な実施形態は、改善されたスケーラビリティおよび適応性を提供し、インフラストラクチャを全体としてプロトコルに依存せず、いくつかの点で将来性があるようにする。

【0029】

説明されている実施形態において作成された通信チャネルは、各参加者の仮想マシン(VM)を使用して分散的に実行され、各トランザクションチェーンは、プロセスにおいて実行される。複数のプロセスが同時に生成され得、マルチスレッディングが協調的なプロセス実行を可能にする。

【0030】

1つの例示的な実施形態において、VMプロセスは、C#または同等物などの機械言語において実行されるが、並列化およびマルチスレッディングは、Javaなどのコンパイラ言語においてラップされる。参加者が実行する各々の同時トランザクションチェーンは、並列であり、生成されたユーザVMプロセスの合計が、プロセス実行の負荷を分担し、システムを高速かつ信頼性の高いものにする。

【0031】

非中央集権型ビルボードとノードとを含むインフラストラクチャは、オフチェーントランザクション分散型合意通信プロトコルのスケーラビリティ、効率、および速度を最大化するのに役立つ。詳細に説明されるように、使用されるプロトコルは、準備フェーズとそれらの合意された条件とを決済するか、またはコミットフェーズにおいてそれらのコミットメントをロールバックするために、参加者およびノードからのローカル仮想マシンを活用する。

【0032】

インフラストラクチャは、以下の特徴のうちの1つまたは複数を有し、(a)参加者とノードとの間の非同期かつ異種の通信のためにメモリベースのキュー処理を使用し、(b)高速取引の効率を最大化するために、参加者が同時かつ共同のプロセスを実行することを可能にし、(c)参加者がノードを実行し、トランザクションチェーン入札市場に参加することを可能にし、したがって、完全に非中央集権化された環境における最適化およびスケーラビリティをインセンティブ化し、(d)単一の特定の台帳内の参加者が同じ台帳の他の参加者に、たとえば、BTCがBTCに参加することを可能にし、これが、高速オフチェーントランザクションチェーンを可能にし、したがって、クロスチェーンおよびマルチラテラルコンテキストにおけるライトニングネットワーク能力、すなわち、プロトコルに依存しないことと、任意のトランザクションチェーンにおけるn人の参加者とをシミュレートする。

【0033】

例示的な方法は、任意のローカル参加者のVMが、n-nb人の参加者(nPt)を含むn-nb個のプロセス(nPs)を実行することができるので、スケーラビリティの課題を解決する。1秒あたりのトランザクション(TPS)は、nPs*nPtにほぼ等しくなる。さらに、マルチスレッディングは、複数のローカルVMが1つのプロセス実行において協働し、したがって、プロセスをさらに高速にする。それに加えて、トランザクション分散型合意通信チャネルは、プルーフオブワーク(POW(Proof-of-Work))などの強力だが低速でコストのかかる合意技術が必要ないスマートコントラクトレス環境を作成する。代わりに、プルーフオブステーク(POS(Proof-of-Stake))が、ノードの経済モデル内で何らかの形で使用される。

【0034】

以下で説明される例示的な方法は、「Distributed Blockchain Transaction System」と題する前述の米国仮特許出願第62/883,531号において開示されているように、たとえば、1秒の所定の時間内で実行され得る(すなわち、要求が成功するかまたは失敗する)、したがって、大量の取引を可能にするUTXOおよびアトミック基準に従うコントラクトレスVM環境内で、本譲受人のクロスチェーン、マルチチェーンシステムを利用するためのステップについて詳述する。デジタル資産を使用するかどうかにかかわらず、任意の1つのトランザクションの結果は、成功または失敗のいずれかである。

【0035】

方法は、以下の参加するアクター、(a)トランザクション要求入札を生成する参加者、および(b)トランザクションチェーン入札を生成するノードの非中央集権型インフラストラクチャについて説明する。参加者は、トランザクション入札キューにトランザクション要求、すなわち、入札を投稿するユーザと呼ばれる。

【0036】

ノードは、ZeroMQなどのメモリベースのキューハンドラを使用して、連続的なトランザクション要求リストに接続される。ノードは、任意のトランザクションチェーンを最適化するために絶えず争っている。ノードの自律エージェントは、そのチェーンをトランザクションチェーン入札として提出する。

【0037】

1つの例示的な方法において、各参加者は、ハッシュ、アドレス、関数名前空間、関数パラメータ、パラメータデータ型などを送信するために、リモート処理呼び出し(RPC(Remote Processing Call))を使用して他の参加者のVMとWebSocketによって通信するオブジェクトの形態においてローカル仮想マシン(VM)を実行する。この通信は、ZeroMQなどの高性能のインメモリタスクキューを使用する。

【0038】

参加者がトランザクションを開始するとき、参加者は、トランザクション要求を公的に投稿するか、またはその取引要求に一致する公的に投稿されたものを検索する。取引要求は、各参加者の要求された取引を決済し、したがって、ループを閉じるために、トランザクションのチェーンのためのn人の参加者を含むことができる。

【0039】

非中央集権型インフラストラクチャがトランザクション要求を中継するとき、それは、トランザクションチェーンを作成し、それに対する分散型合意決済を開始し、すなわち、トランザクションチェーンにおける参加者のトランザクション要求を開始する。

【0040】

トランザクションチェーン(TxCh)は、ノードの最適化アルゴリズム自律エージェントによって作成されたオブジェクトである。それは、一緒にマッチングされるユーザトランザクション要求(資産、データ、またはその両方)のチェーンである。トランザクションチェーンが作成されると、VMトランザクションの開始が、参加者1から参加者nまで開始される。

【0041】

トランザクションのチェーンIDが提出されると、参加者は、それらの要求を同期させ、通信チャネル(たとえば、WebSocketアドレス)と、任意のさらなる通信を暗号化するための公開鍵とを共有する。

【0042】

この方法は、ローカルVM方法におけるクロスチェーンと分散型合意とを活用する。インフラストラクチャは、2つの主な構成要素、(a)トランザクション要求ビルボードおよび(b)最適化アルゴリズムに分離され得る。

【0043】

トランザクション要求ビルボードは、参加ノードが接続されている限り参加ノード間で分散されるトランザクション要求オブジェクトリストである。

【0044】

最適化アルゴリズムは、トランザクション要求マッチングのために訓練された自律エージェントであり、最大のトランザクションチェーンを作成するために最適化手法を使用する。アルゴリズムは、ノードによってホストおよび運用され、トランザクションチェーン入札を提出する。

【0045】

任意の所与のトランザクションチェーンを提出する第1のノードは、最大の所定の期間、たとえば、1秒の間、トランザクション要求キュー内にロックされたトランザクションチェーン参加者を見る。ロックされると、関連するトランザクション要求は、凍結され、他のノードによって提出することができなくなり、これは、アルゴリズムが第1の参加者のトランザクション要求を開始するまでの時間を与える。

【0046】

単一のトランザクションチェーンは、可能な限り多くの参加者を有することによって最適化され、これは、ノードネットワークからのスケーラビリティをさらにインセンティブ化するのに役立つ。ノードは、すべての参加者の間で手数料が徴収される支払いプロセスを介して、決済においてより大きいコミッションを獲得することによってインセンティブを与えられ、単一のチェーンにおける参加者が多いほど、手数料も多くなる。この経済モデルは、収益性の高いノードを実行することが、可能な限り多くのトランザクションチェーンを実行し、各チェーンを可能な限り長くすることを意味することを保証する。

【0047】

方法は、負荷分散が可能な並列化されたマルチスレッド環境にラッピングすることによってマシンレベル(バイト)で実行される処理を最適化し、多数の同時または共同プロセスを実行するために、参加者のローカルVM環境を活用する。

【0048】

方法は、3つのフェーズ、(a)準備フェーズ、(b)コミットフェーズ、および(c)実行フェーズに分離される。

【0049】

ユーザは、準備フェーズを開始し、各参加者が本物のトランザクションチェーンアプリケーションバイナリインターフェース(txChain ABI)、一意のハッシュの交換を共有し、ノードの暗号署名が本物であることを検証する。

【0050】

各参加者は、準備フェーズの有効性について投票する。これが行われると、ユーザは、各ユーザ関連機能、すなわち、12EOSに関する10Etherなどのユーザトランザクション要求に関して同期されたと見なされ、ロールバック機能は、コミットメントと見なされる。

【0051】

これらのコミットメントは、コミットフェーズにおいて実行される。参加者がコミットフェーズにおいてトランザクション投票を投稿すると、それは、成功または失敗のいずれかである。

【0052】

失敗は、各参加者のロールバックコミットメントを自動的に呼び出す。特定の時間期間内にコミットメントフェーズの通信またはシグナルの失敗を返さないことも、ロールバックコミットメントをアクティブにする。

【0053】

コミットフェーズの投票が成功した場合、実行フェーズが開始される。コミットメントが実行される。

【0054】

トランザクション決済(コミットメント)が成功である場合、トランザクションチェーン関連ノードは、ネットワークからのそのコミッションを請求するために、この実行フェーズステータスレポートをレシートとして使用し、関連するトランザクション要求は、解決される。

【0055】

トランザクション決済が失敗である場合、関連するトランザクション要求は、解決されず、他のノードがそれらのトランザクションチェーン入札内でそれを請求するために、ロック解除される。

【0056】

これらのフェーズは、ローカルマルチシグデジタルウォレットおよびロールバック機能のセットを使用することによって、資産の二重支出を防止する。

【0057】

システムは、実行ノードによって計算されたタイムアウト遅延に基づくビザンチンフォールトトレランスを有する。フォールトトレランスは、3人の参加者に対して1秒を基準として使用する任意のtxChainの長さにも比例する。この計算は、ノードによって実行される。

【0058】

成功すると、システムは、トランザクションに参加しているすべての台帳において一意のトランザクションを決済する。

【0059】

失敗すると、システムは、ロールバック機能をアクティブにし、すべての資産/データは、失敗ステータスとともに送信者に返される。2つのタイプの失敗イベント、資産およびデータがコミットされず、したがって、トランザクションが進行しない準備フェーズにおけるソフト失敗と、ロールバックコミットメントからロールバックをトリガするコミットフェーズにおけるハード失敗とが存在する。最後に、2つの方法、すなわち、txRequestの細分化およびトランザクションブリッジは、さらにより高いスケーラビリティを可能にし、大量の取引、マイクロペイメント、ビッグデータなどのユースケースに取り組むことができる。

【0060】

そのようなシステムの予見される弱点は、標準的なクラウド仮想マシンの中央集権化の観点に基づく。

【0061】

1.システム層
通信システムプロトコルは、トラストレスのままであることを保証するために、非中央集権化される。一実施形態において、プロトコルは、3つの層、すなわち、ネットワーク層と、ノード層と、インフラストラクチャ層とを有する。

【0062】

1.1.ネットワーク層
ネットワーク層は、トランザクション要求をビルボードに提出するすべての参加者の合計である。参加者は、取引要求を作成して投稿し、数秒以内にそのアクションの有無を確認することによって開始する。

【0063】

参加者側において、特定のトランザクションに対する要求が送信された。検証フェーズの投票後に接続遅延がない限り、ソフト失敗およびロールバックは、参加者によって決して見られたり経験されたりしない。これは、取り消し不能であり、参加者がレシートとして検証投票を使用して資産および/またはデータを請求することができることを意味する。検証投票は、参加者によって暗号で署名され、偽造するのは非常に困難である。

【0064】

参加するために、インターフェースは、WebSocketアドレスに接続し、プロトコルのフレームおよび方法内で通信する必要がある。WebSocketは、単一の伝送制御プロトコル(TCP)ソケット上で双方向の全二重通信チャネルを提供するウェブ技術である。

【0065】

1.2.ノード層
ノード層は、ネットワークに接続されたすべての参加ノードの合計である。ノードは、トランザクション要求(txRequest)によって構成されたトランザクションチェーン(txChain)を生成、提出、および解決するか、またはトランザクションブリッジを持続させることによってネットワークをマイニングする非中央集権型アクターである。

【0066】

ノードは、txChain内で解決するtxRequestからコミッション手数料を獲得することによって、参加するようにインセンティブを与えられる。txChainが長いほど、より多くの手数料入札が収集される。ノードは、資産/データを決して保持しないが、参加者間の契約期間の合意においてメディエータの役割を果たす。ノードは、手数料入札の90%を受け取る。ノードは、所定の間隔(たとえば、60分ごと)においてコミッションの10%を送信する責任がある。これは、手数料コストを最適化し、ノード側においてある程度の柔軟性を可能にすることを意味する。したがって、リスクは、所定の間隔(たとえば、60分)のコミッションボリュームの持続時間に限定される。そうしないことは、ブラックリストに登録される理由になる。

【0067】

ノードは、txChain入札を生成することができる前に、責任者に正式名称を付けるKYC/AML(ノウユアクライアント/アンチマネーロンダリング(Know Your Client/Anti-Money Laundering))方法をネットワークに使用することによって、ホワイトリストに登録する必要がある。そうするために、ノードは、任意のtxChainに関するトランザクション制限を表す資産の量をステークする(すなわち、制御されたエスクローウォレットに預ける)必要がある。

【0068】

ノードが嘘をついているのが見つかるか、またはオフラインになり、したがって資金を保留する場合、txChainは、失敗し、ロールバックは、失敗し、ステークは、参加者に補償するために使用される。次いで、ノードは、ブラックリストに登録される。

【0069】

1.3.インフラストラクチャ層
インフラストラクチャ層は、インフラストラクチャまたはシステムの唯一の中央集権化された部分である。インフラストラクチャ層は、ビルボードおよびLOCKオブジェクトを管理する。インフラストラクチャまたはシステムはまた、所定の間隔サイクル(たとえば、24時間サイクル)において、公開鍵(「pub_key」)が公的に開示され、提出された各ビルボードtxRequestに署名するために使用される新しい暗号署名を生成し、これは、なりすましを阻止することを意図している。

【0070】

説明されている実施形態において、インフラストラクチャまたはシステムは、プロトコル通信の待ち時間を最適化するために、高性能なメモリベースのキューシステムを使用する。

【0071】

2.トランザクションチェーン入札-ステップ1
図2は、ビルボードオブジェクト(BBo)にトランザクション要求を投稿する参加者の概略図を示す。

【0072】

2.1.トランザクション要求(txRequest)を生成する
最初に、各参加者は、自分のプロトコル関連送信者アドレス、すなわち、任意のデジタルウォレットアドレスを使用して、自分のローカル環境において自分のVM契約を開始する。

【0073】

第1の参加者は、トランザクション要求オブジェクトをそのVMに渡すことによってトランザクション要求を開始する。

【0074】

トランザクション要求オブジェクトは、以下を含む。

【0075】

(a)関数が命令詳細パラメータにあり、型がABIにおいて利用可能である場合の関数名前空間タプル。この場所は、プロミス(Promise)を作成するためにパラメータの名前空間および型を開示することを意図していることに留意されたい。プロミスは、ユーザのVMが関数を解釈、検証、および実行することをより容易にする。

【0076】

(i)機能的パラメータ

【0077】

(ii)パラメータデータ型

【0078】

(b)UnHIDタプル

【0079】

(c)pub_key

【0080】

(d)トランザクション要求オブジェクト(要求、ロールバック)タプル

【0081】

(i)要求オブジェクトは、関数名前空間とそのパラメータとを含み、たとえば、solidity(Ethereumコンパイル型言語)スマートコントラクトにおいて、古典的な伝達関数、転送(非整数送信者(コーディネータアドレス)、非整数ターゲット(ターゲットアドレス))を含む。名前空間(*param)構造は、データを使用して参加者の意思において資産とデータの両方が取り扱われることを可能にするために使用されることに留意されたい。スマートコントラクトは、エラーを返さないように、特定のパラメータと送信者のアドレスまたはターゲットアドレスとが含まれることを必要とする。

【0082】

(ii)資産がトランザクション要求にコミットされる場合、トランザクション要求命令がそこ(たとえば、送信者アドレス、1ETH、ターゲットアドレス、10EOS)に配置される。

【0083】

(e)ロールバック命令は、エスクローマルチシグデジタルウォレット初期化においてノードによって自動的に生成され、逆の命令を含む。

【0084】

オブジェクトは、リスト順序の不変性とこのリストの処理の最適化とのために、タプルまたは同等のものを使用する。

【0085】

ローカルVMは、各関数からABIをバイト単位で生成する。

【0086】

例:3関数コントラクトについて

【0087】

【表1】

【0088】

ABIがパラメータとして入力されると、それは、トランザクション要求と見なされる。
2.2.ビルボードへの投稿

【0089】

参加者は、トランザクション要求入札をビルボードに投稿する。トランザクション要求(txRequest)ABIは、それを生成する参加者によって暗号で署名される。24時間サイクルのビルボード署名もそれに署名し、これは、txRequest ABiが本物であることを保証する。

【0090】

例:ビルボードオブジェクトステータス

【0091】

【表2】

【0092】

107 参加者は、トランザクション要求オブジェクトABIを提出する。

【0093】

【表3】

【0094】

108 ここで、BBoは、次のようになる。

【0095】

【表4】

【0096】

一実施形態において、BBoは、そのまま10ミリ秒ごとに非同期でネットワークに投稿される。

【0097】

3.トランザクションチェーン入札-ステップ2
図3は、ノードがtxRequest ABIを読み取る方法を概略的に示す。

【0098】

3.1.マッチングアルゴリズムフィード
ノード1およびノード2が、ネットワークWebSocket上のBBo投稿をリッスンする。

【0099】

両方のノードは、それらの側において、入力パラメータとしてBBo txRequestリスト/アレイをとり、トランザクションチェーン入札を出力するマッチングアルゴリズムを実行する。

【0100】

ノード2もチェーンをマッチングする。LastUpdatedBBo(Each(10mms)BBo)→Algo(Nodes2)→TXC2=TX1→TX2→TX3→TX4→TX1

【0101】

ノード2は、txChain入札を提出する。これは、txの将来のチェーンにおける任意の最初の参加者にping信号を送信する。

【0102】

ノード2は、LOCKオブジェクトに進むときにtxChain ABIに署名し、txChainロックされたtxRequestが属するノードを識別する。

【0103】

3.2.第1の参加者にトランザクションチェーン入札をpingする
ノード2は、ユーザ1にpingし、チェーントランザクションtxRequest ABIに、ユーザ1、ユーザ2、ユーザ3、ユーザ4の値をポピュレートする。

【0104】

参加者は、予め技術的に同期される。参加者は、同期がすべてに対して有効であることを検証するために、それらの提出された一意のハッシュID(UnHID)を使用して、準備フェーズ契約を投票する必要がある。

【0105】

ユーザ1に送信されるtxChain関連ABIは、おおよそ次のようになる。

【0106】

【表5】

【0107】

4.一意のハッシュ(UnHID)のシードおよび交換を計算する。

【0108】

図4は、参加者が一意のハッシュを交換するブロック図を示す。

【0109】

参加者がtxChain Bid ABIを受信すると、トランザクションチェーンが開始される。ABIは、ユーザが安全に通信し、他の参加者、txChainを処理するノード、およびビルボードからの暗号署名を要求するために必要な情報を含む。

【0110】

第1の参加者は、乱数を生成し、そのハッシュ値を計算し、一意のハッシュID(UnHID)を生成する。このUnHIDは、通信のために使用されるキーペアを作成するためのシードとして使用される。

【0111】

乱数生成のための任意の数の方法が使用され得る。一実施形態において、乱数生成方法は、その内容が参照により本明細書に組み込まれる、「A Method for Generating Random Numbers in Blockchain Smart Contracts」と題する、本出願の譲受人に譲渡された、米国特許出願第62/794,336号において開示されている方法を使用した。

【0112】

5.トランザクション条件に合意する
図5は、参加者がHnを共有することによって同期されていることをどのように認識するかを示す図である。

【0113】

ユーザは、すべての他のハッシュされたHn=hashOf(h1+h2+h3+h4)の合計のハッシュを追加することによって、txChain ABIを交換する。ユーザは、txChain ABIを検証する。

【0114】

各参加者は、トランザクション要求ABIを次の参加者に送信する。例。

【0115】

【表6】

【0116】

すべての参加者は、最終要求ABI=FcHashのcHashを計算し、ユーザ1は、FcHashをユーザ2に投稿し、ユーザ2は、FcHashをユーザ3に投稿し、ユーザ3は、FcHashをユーザ1に投稿する。

【0117】

6.準備フェーズを実行する
図6は、参加者が準備フェーズステータス(Hnが対応する場合)を投票することを概略的に示す。

【0118】

FcHashが一致する場合、契約条件は、合意されたとみなされ、契約の準備フェーズが開始される。

【0119】

ここで、各参加者は、最終トランザクション要求オブジェクトのcHashと同様に、各々の他の参加者の公開鍵およびWebSocketを有する。参加者は、同期されていると見なされる。

【0120】

各々のユーザ関連関数およびロールバック命令は、各参加者のコミットメントと見なされる。それらは、資産がエスクローにコミットされた場合、txChainを解決するノードによってロールバックコミットメントとして解釈される。各参加者は、合意の条件の有効性、すなわち同期についての判断を投票する。

【0121】

各参加者は、ハッシュ、すなわちすべての参加者の準備フェーズステートメントの結果が一致するかどうかを評価し、成功ステータスを返し、それに応じて投票する。ステートメントは、成功または失敗のいずれかである。

【0122】

成功は、ノードのプロンプトへの暗号署名を使用して行われる。プロンプトは、ユーザが、任意の資産を預けるか、または任意のデータストリームの暗号署名を準備することによって、合意の条件をコミットすることに合意することを示す。言い換えれば、参加者は、エスクローウォレットがコミットフェーズを実行するための承認としてその署名を送信することによって、コミットフェーズに合意する。

【0123】

参加者は、ノードに投票を投稿し、投票は、(1)成功(暗号署名)または(2)Nullのいずれかであり得る。

【0124】

7.コミットエスクローフェーズを実行する(資産が含まれる場合)
図7は、ノードが成功投票をプロンプトとして使用してエスクローマルチシグウォレットを初期化する方法を概略的に示す。

【0125】

資産がtxChain内に含まれる場合、このステップが適用される。ノードがすべての投票を受信すると、2つの署名を使用してエスクローウォレット初期化の実行を開始する。ノードは、txChain pub_key(Kn)を提供し、参加者は、pub_key(たとえば、K1)を提供した。初期化のいずれかが失敗した場合、HardFailイベントがトリガされ、ロールバックフェーズが呼び出される。すべての要求ウォレットが正常に初期化された場合、ノードは、実行フェーズを開始する。

【0126】

8.コミットフェーズを実行する
図8は、参加者によって実行されるコミットフェーズを示す。ノードは、すべてのユーザコミットメントの実行を開始する。コミットされた資産を有する参加者は、これらの資産をこのtxChain内の参加者のために作成されたエスクローマルチシグウォレットに送信する。コミットされたデータを有する参加者は、ターゲットpub_keyを用いてデータを暗号化し、それらの鍵を用いてデータに署名する。エスクローコミットメントトランザクションのいずれかが失敗した場合、すべてのtxChain参加者に対してハード失敗イベントがトリガされ、ロールバックフェーズが呼び出される。コミットされた資産を持たない参加者は、レシートなしでそれらのロールバックが失敗することを見る。これは、ソフト失敗である。コミットメントが失敗しない場合、ノードは、検証フェーズを開始するように参加者に通知する。

【0127】

9.検証フェーズ-参加者がエスクローを検証する
図9は、ノードおよび/または参加者の検証を示す図を示す。各参加者は、他の参加者のコミットされた資産または署名されたデータを評価する。エスクローウォレットがtxChainのすべての参加者に開示されているので、参加者は、資産の預け入れを検証することができる。参加者は、データが合意の条件(txChain ABI)における約束されたデータと一致し、正しい参加者によって署名されていることを検証することによって、データの有効性を検証することができる。

【0128】

10.検証フェーズ-参加者投票
図10は、投票の検証のプロセスまたは「検証投票」フェーズを示す。各参加者は、資産/データの有効性の判断について投票する。資産は、エスクローウォレット内にあり、データは、合意の条件と一致し、正しい参加者によって署名される。資産を検証するために、参加者は、エスクローアドレスを使用して対応する台帳を調べる。txidによる台帳ブロックが、合意された条件およびノードによって送信された(署名された)txidに対応する場合、トランザクションは、関連する台帳上になかった場合でも、有効であると見なされる。それは、依然として(ブロックエクスプローラを使用する台帳上に)保留中のトランザクションとして現れ、両方の実行者からの条件は、同じであることが証明される。

【0129】

ユーザ1は、投票(検証フェーズステータス)=すべてのユーザに対して真(署名)またはnullのいずれか、を投稿する。

【0130】

ユーザ2は、投票(検証フェーズステータス)=すべてのユーザに対して真または偽のいずれか、を投稿する。

【0131】

ユーザ3は、投票(検証フェーズステータス)=すべてのユーザに対して真または偽のいずれか、を投稿する。

【0132】

全会一致の投票が肯定的である場合、検証フェーズは、成功したと見なされ、実行フェーズが開始される。

【0133】

txChainの実行前フェーズは、1秒を基準とするタイムアウト遅延において実行され、これは、txChainの長さに比例して変更される。これは、動的なビザンチンフォールトトレランスポリシーを説明している。この段階において、任意の参加者が嘘をついた場合、それは、すべての他の参加者およびノードによって見られる。ノードが嘘をついた場合、それも、コミットメントがエスクローにおいて遂行されないので、見つかる。

【0134】

11.実行フェーズ
図11は、実行フェーズを概略的に示す。

【0135】

実行フェーズが実行されると、ノードは、各参加者のコミットメントを実行するための承認として検証フェーズ投票署名を使用する。コミットメントが実行されるたびに、ノードは、署名されたレシートを対応するターゲット参加者に送信する。実行時に、ノードは、手数料入札をそのノードのターゲットウォレットに送信する第2のトランザクションも実行することに留意されたい。参加者は、レシートが自分の要求したターゲットアドレス、すなわち自分が取引された資産を送信するように要求したアドレスに対応するかどうか、およびトランザクションが有効であるかどうかを検証することができる。参加者は、(a)署名されたtxidのレシートまたは(b)Nullのいずれかによって、txChainの有効性に関する自分の判断を送信する。

【0136】

12.トランザクションチェーン決済
図12は、TxChainクリーニングフェーズを示す。

【0137】

12.1.トランザクションチェーン決済(解決)
txChainを決済するために、ノードは、すべての参加者の署名されたtxidを提供し、それを削除するために、LOCKオブジェクト内のtxChainロックされたリソースに署名する必要がある。不正行為をして、資産を偽のエスクローに送るように参加者を騙しているのが見つかったノード、またはコミットメントを正常に実行しないノード、またはトランザクションタイムアウト遅延内に間違ったレシートを提供するノードは、そのステークを失い、ブラックリストに登録される。参加者は、自分の投票レシートをビルボードに提示することによって、報酬を請求する。

【0138】

ビルボードは、次の60分サイクルにおいてインフラストラクチャ手数料をノードに請求するために、ハッシュHb=hash(各参加者のtxid)、署名(Hb)を保持する。ここで、BBoオブジェクトは、次のようになる。

【0139】

【表7】

【0140】

13.ロールバックフェーズ

【0141】

図13は、ロールバックステップを概略的に示す。

【0142】

ロールバックが呼び出された場合、すべてのロールバックコミットメントは、参加者によって実行され、ノードによって副署される。ノードが副署しない場合、コミットメントは、失敗し、トランザクションは、実行されない。参加者が(悪い振る舞いまたはオフラインになることにより)ロールバックに署名しない場合、その資産は、失われ、支出不能なアドレスに残る。

【0143】

ロールバックイベントは、参加者からのアクションを必要とする。参加者の観点からは、トランザクションの失敗を示す第2の確認がある。該当する場合、ノードの障害、すなわち、txidが一致しないこと、およびノードステークからの補償資産が示される。悪い振る舞いまたはオフラインになることのいずれかによって任意のロールバックコミットメントが失敗した場合、ノードは、ブラックリストに登録され、そのステークは、失われ、参加者は、補償される。

【0144】

14.ノード経済モデル
図14は、例示的なノード経済モデルを概略的に示す。

【0145】

ネットワークへノードの参加の基礎となる例示的なノード経済モデルについて以下に説明する。

【0146】

ノードは、トランザクションチェーン(txChain)提案、すなわち入札を生成することによって、トランザクション要求(txRequest)をマイニングする。参加者は、それらの要求に手数料提案(入札)を追加する。ノードは、txRequest ABIと手数料入札とを見ることができる。ノードは、可能な限り最長の取引チェーン(txChain)をマッチングさせることによって、チェーンを最適化するようにインセンティブを与えられる。txChainがノードによって正常に実行されるたびに(実行フェーズ)、ノードは、手数料をそのノードターゲットウォレットに送信する。

【0147】

15.txRequest入札の細分化
図15は、txRequest入札の細分化を示す。トランザクション要求(txRequest)の細分化は、任意のtxRequestのオファーおよびアスク部分が同じtxChain内のより多くの参加者にマッチするように細分化され得ることを意味する原則である。コミットメントが実行フェーズにおいて実行される場合、コミットメントは、強制的に循環されない。コミットメントは、送信者、ターゲットアドレス、およびそれに関連付けられた金額である。参加者は、同じ参加者が2人以上の参加者、たとえば、ユーザ1、ユーザ2、およびユーザ3に資産を送信する多層契約に合意することができる。これは、より流動的で柔軟なtxChain入札生成を可能にする。

【0148】

16.トランザクションブリッジ(txBridges)
図16は、トランザクションブリッジ(txBridge)-ブリッジ初期化を示し、図17は、トランザクションブリッジ(txBridge)-レシート交換を示す。

【0149】

トランザクションブリッジ(txBridge)は、大量取引、マイクロトランザクション、およびビッグデータなどのユースケースを可能にする新しい多国間オフチェーン決済システムである。トランザクションブリッジは、すべての参加者が資産/データをコミットし、疑似トランザクション、すなわち暗号署名されたレシートを高速に交換することを可能にする決済システムとして説明され得る。

【0150】

コミットされた資産/データの合計を表す取引の合計金額またはタイムサイクルが経過すると、口座残高が決済される。口座残高決済は、合計の交換レシートを集計することによって計算される。

【0151】

集計されたレシートのハッシュは、残高の有効性の効率的な一度のチェックを可能にする。任意のレシートは、その信頼性を保証するために、ノードと関連する参加者の両方によって署名される必要があることに留意されたい。

【0152】

txBridgeは、通常のtxChainの場合と同じ方法でノードによって実行されるが、手数料コミッションのサイクルは、合意された決済サイクル(ASC(Agreed Settlement Cycle))に基づく。txBridgeは、txChainの変形である。txBridgeは、txChainのロジックの多くに従うが、いくつかの違いを有する。txBridgeは、n人の参加者間のtxChainの連続的な双方向プロセスである。各参加者は、資産を送受信するための有効なブリッジを有する。

【0153】

すべての参加者によって合意されたASCサイクルに従う場合。サイクルは、時間に基づき、口座残高決済によって終了する。各サイクルは、txChain決済と同様のロジックに従うtxBridgeサイクル決済によって終了する。

【0154】

口座残高決済は、2つの条件、(1)ASCタイムアウト、および(2)任意の2人の参加者のブリッジコンテキスト内のこれらの参加者の合計レシート値のうちの1つによってトリガされる(たとえば、レシート値>新しいリフレッシュされた米ドル(AliceのBTC+BobのETH)の90%である場合、Aliceは、10000米ドル相当のBTCをコミットし、Bobは、10000米ドル相当のETHをコミットする)。txBridgeは、相互に合意された条件ABIに基づくので、サイクルの合計の予測トランザクション値は、予測可能である。

【0155】

txBridgeをクリーニングすることは、Xステップに従う。

【0156】

【表8】

【0157】

16.1タイムアウトイベント

【0158】

ノードの観点においてASCサイクルが経過すると、タイムアウトイベントが呼び出される。ノードがこれを制御する。タイムアウトイベントが呼び出されると、レシートで証明された現在の口座残高が交換される。参加者は、一意の集計されたレシートハッシュを交換して、互いのレシートの有効性についての自分の判断を投票する。投票が成功した場合、口座残高トランザクションが実行される。txタイムアウトにより投票が失敗した場合、トランザクションは、発生せず、コミットされた資産/データは、触れられない。失敗が参加者によるものである場合、参加者のコミットされた資金が補償として使用される。失敗がノードによるものである場合、ノードのステークが補償として使用される。

【0159】

16.2.口座残高イベント
口座残高イベントがトリガされると、レシート値が計算され、新しい口座残高提案がユーザに送信される。ユーザは、レシート残高の有効性について自分の判断を投票し、ユーザは、ユーザがハッシュするために使用した自分の同期されたレシートからそれを計算することもできる。投票の結果が成功である場合、トランザクションが実行される。しかしながら、投票の結果が失敗またはタイムアウトである場合、トランザクションは、発生せず、コミットされた資産/データは、触れられない。

【0160】

失敗が参加者によるものである場合、参加者のコミットされた資金が補償として使用される。失敗がノードによるものである場合、ノードのステークが補償として使用される。

【0161】

16.3.スケーラビリティ
トランザクションの量およびnbは、参加者が投資するコミットされた資金と、ASCサイクルの長さとに依存する。

【0162】

疑似トランザクションの利点は、それらが超高速で手数料がかからないことであり、唯一の手数料は、口座残高決済イベントに関連し、これは、コストの爆発を引き起こすことなく、資産のごく一部が取引されることを可能にする。

【0163】

TxBridgeは、参加者とノードとの間の光ファイバ接続を介して実行され得、したがって、ナノ秒の取引/交換を可能にする。

【0164】

他の実施形態
当業者によって理解されるように、本発明の多くの代替実施形態が可能である。例示的な代替実施形態において、システム(たとえば、ブロックチェーンシステム)に以下の動作を実行させるように適合された内容を有する非一時的なプロセッサ可読媒体が提供される。

【0165】

システムは、複数のブロックチェーンであって、各ブロックチェーンが複数のノードを有する、複数のブロックチェーンと、トランザクションのすべての動作がコミットまたはロールバックされるように、トランザクションを調整するためにノード間でセキュリティメッセージを転送し、ステータス値を維持するためのコーディネータとを備える。動作は、複数の参加者のうちの1人から生成されたトランザクションに関する要求を受信する動作と、トランザクション要求をビルボード上に公に投稿する動作と、前記ビルボードからノードによるトランザクション要求を読み取る動作と、準備フェーズにおいて、参加者間で同期し、準備フェーズの検証を確認するために投票する動作と、コミットフェーズにおいて、要求をコミットするかまたはロールバックするために参加者からトランザクション投票を受信する動作と、トランザクションをコミットするかまたは要求をロールバックすることによって、トランザクション投票に基づいてトランザクションを実行する動作とを含む。

【0166】

このように、例としてのみ本発明の実施形態について説明してきたが、添付の特許請求の範囲によって定義される本発明は、特許請求の範囲から逸脱することなく多くの変形および並べ替えが可能であるので、例示的な実施形態の上記の説明に記載の特定の詳細によって限定されるべきではないことが理解されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【国際調査報告】