知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-18
(45)【発行日】2024-03-27
(54)【発明の名称】ブロックチェーン・トランザクション・マネージャー
(51)【国際特許分類】
G06Q 20/38 20120101AFI20240319BHJP
【ＦＩ】
G06Q20/38 310
【請求項の数】
15
(21)【出願番号】P 2021547344
(86)(22)【出願日】2020-12-09
(65)【公表番号】
(43)【公表日】2022-07-15
(86)【国際出願番号】 CA2020051692
(87)【国際公開番号】W WO2021113967
(87)【国際公開日】2021-06-17
【審査請求日】2021-08-13
(31)【優先権主張番号】62/948,060
(32)【優先日】2019-12-13
(33)【優先権主張国・地域又は機関】US
【前置審査】
(73)【特許権者】
【識別番号】321005788
【氏名又は名称】ケーエヌエヌエックス コーポレーション
(74)【代理人】
【識別番号】100104411
【弁理士】
【氏名又は名称】矢口 太郎
(72)【発明者】
【氏名】スリバスタバ、ニーラジ
【審査官】加舎 理紅子
(56)【参考文献】
【文献】米国特許出願公開第２０１９／００９６５２２（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１８／０１９１７１４（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１９／００９５５８５（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
(57)【特許請求の範囲】
【請求項1】
ブロックチェーン・ネットワーク内のノード用に意図されたブロックチェーン・トランザクションを受信し、前記ブロックチェーン・ネットワーク内のノードへの前記ブロックチェーン・トランザクションの送信を管理するブロックチェーン・トランザクション・マネージャーであって、ブロックチェーン・トランザクションを生成するユーザー・アプリケーションへのインターフェースを提供するトランザクション管理アプリケーションであって、前記トランザクション管理アプリケーションは、前記ブロックチェーン・ネットワークおよびトランザクションを送信するアイデンティティについて必要な情報を受信し、受信されたブロックチェーン・トランザクションを検証して、検証済みの受信されたブロックチェーン・トランザクションを生成し、この検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる、トランザクション管理アプリケーションと、
トランザクション・ハンドラであって、前記ブロックチェーン・ネットワークおよびアイデンティティの情報を格納し、前記検証済みの受信されたブロックチェーン・トランザクションの少なくとも１つのトランザクション属性であって、前記検証済みの受信されたブロックチェーン・トランザクションのためのナンス属性及びコスト属性のうちの少なくとも１つを含む、少なくとも１つのトランザクション属性を生成し、前記少なくとも１つのトランザクション属性を前記検証済みの受信されたブロックチェーン・トランザクションに追加し、前記検証済みの受信されたブロックチェーン・トランザクションを前記少なくとも１つのトランザクション属性と一緒に永続的キューに入れ、前記ユーザー・アプリケーションにより供給されたアイデンティティ・クレデンシャルを使って、前記永続的キューに入れられた前記検証済みの受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワークに適用可能であるとしてデジタル署名または認証し、前記デジタル署名または認証した検証済みの受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する、トランザクション・ハンドラと、
前記送信されたデジタル署名または認証した検証済みの受信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングするブロックチェーン・ポーラーと
を有するブロックチェーン・トランザクション・マネージャー。
【請求項2】
請求項１記載のブロックチェーン・トランザクション・マネージャーにおいて、前記トランザクション管理アプリケーションは、前記受信されたブロックチェーン・トランザクションの受信時に追跡目的でこれに汎用一意識別子を割り当てるものであるブロックチェーン・トランザクション・マネージャー。
【請求項3】
請求項１記載のブロックチェーン・トランザクション・マネージャーにおいて、前記トランザクション・ハンドラは、さらに、前記検証済みの受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する前記試行を追跡用に追跡キューに入れ、前記ブロックチェーン・ネットワーク内のノードへ正常に送信されたブロックチェーン・トランザクションのステータス情報を格納するものであるブロックチェーン・トランザクション・マネージャー。
【請求項4】
請求項１記載のブロックチェーン・トランザクション・マネージャーにおいて、さらに、前記ブロックチェーン・ネットワーク内のノードにより拒否されたブロックチェーン・トランザクションを受信し、前記拒否されたブロックチェーン・トランザクションを再試行する管理アクティビティ・スケジューラを有し、
前記ブロックチェーン・ポーラーによる送信されたデジタル署名または認証した検証済みの受信されたブロックチェーン・トランザクションの初回ポーリングが、設定可能な最大試行回数を超えたとき、前記管理アクティビティ・スケジューラは、前記送信されたデジタル署名または認証した検証済みの受信されたブロックチェーン・トランザクションのステータスを追跡し続けるために、前記ブロックチェーン・ステータスのさらなるポーリングをより低い頻度で前記ブロックチェーン・ポーラーによりスケジュールするものであるブロックチェーン・トランザクション・マネージャー。
【請求項5】
請求項１記載のブロックチェーン・トランザクション・マネージャーにおいて、さらに、インタラクティブなインターフェースを介して人間のユーザーによる前記トランザクション管理アプリケーションへのアクセスを提供するトランザクション管理コンソールを有し、当該トランザクション管理コンソールは、前記ユーザーのインタラクティブなインターフェースを介して、ブロックチェーン・トランザクションと各々のステータスのリストを前記ユーザーに提供し、
前記トランザクション管理コンソールは、さらに、ブロックチェーン・トランザクションに使用するアイデンティティまたはトランザクション認証クレデンシャルを管理するものであるブロックチェーン・トランザクション・マネージャー。
【請求項6】
請求項１記載のブロックチェーン・トランザクション・マネージャーにおいて、さらに、データベースであって、まだ前記ブロックチェーン・ネットワーク内のノードに正常に書き込まれていない送信されたデジタル署名または認証した検証済みの受信されたブロックチェーン・トランザクションを格納し、前記送信が成功しなかった理由と、前記送信されたデジタル署名または認証した検証済みの受信されたブロックチェーン・トランザクションのステータスとを格納するデータベースを有するものであるブロックチェーン・トランザクション・マネージャー。
【請求項7】
ブロックチェーン・ネットワーク内のノードへのブロックチェーン・トランザクションの送信を管理する方法であって、プロセッサが、受信されたブロックチェーン・トランザクションを検証して検証済みの受信されたブロックチェーン・トランザクションを生成し、その検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる工程と、
前記プロセッサが、前記検証済みの受信されたブロックチェーン・トランザクションの少なくとも１つのトランザクション属性であって、前記検証済みの受信されたブロックチェーン・トランザクションのためのナンス属性及びコスト属性のうちの少なくとも１を含む、少なくとも１つのトランザクション属性を生成し、前記少なくとも１つのトランザクション属性を前記検証済みの受信されたブロックチェーン・トランザクションに追加し、前記検証済みの受信されたブロックチェーン・トランザクションを前記少なくとも１つのトランザクション属性と一緒に永続的キューに入れる工程と、
前記プロセッサが、前記ブロックチェーン・ネットワークに対し、前記永続的キューに入れられた前記検証済みの受信されたブロックチェーン・トランザクションをデジタル署名または認証する工程と、
前記プロセッサが、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションを、前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と、
前記プロセッサが、前記送信されたデジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングする工程と
を有する方法。
【請求項8】
請求項７記載の方法において、前記ブロックチェーン・ステータスをポーリングする工程は、送信されたデジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの前記ブロックチェーン・ネットワークでの受理に向けた進捗状況に関する情報について、前記プロセッサが、前記ブロックチェーン・ネットワーク内のノードをポーリングする工程と、前記プロセッサが、望ましい進捗状況情報が受信されるまで前記ポーリングを再試行する工程と、前記プロセッサが、期限が切れた後または最大ポーリング試行回数後、前記ポーリングする工程の頻度を低下させる工程と、を有するものである方法。
【請求項9】
請求項７記載の方法において、さらに、前記ブロックチェーン・ネットワーク内のノードに送信された前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの送信が、前記ブロックチェーン・ネットワークにより前記デジタル署名または認証された検証済みの受信されたトランザクションが受理される結果になったかどうかを、前記プロセッサが、前記ブロックチェーン・ネットワークに適した基準に基づいて示す応答を受信する工程と、
前記送信されたデジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションを、前記プロセッサが、そのステータスとともにデータベースに書き込む工程と、
前記送信されたデジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの前記ステータスが、前記送信が成功しなかったことを示した場合、さらに、前記送信が成功しなかった理由を前記プロセッサが、前記データベースに格納する工程と、を有するものである方法。
【請求項10】
請求項７記載の方法において、さらに、前記ブロックチェーン・ネットワークがトランザクション・ナンス機構を含む場合、前記プロセッサが、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションにナンスを自動的に割り当てる工程を有し、
前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、
同じアカウントおよびブロックチェーン・ネットワーク用に複数のブロックチェーン・トランザクションが並列処理されている場合、前記プロセッサが、ロック機構を使って、必ず一度に１つのトランザクションについてしかナンスが計算されないようにする工程と、
ブロックチェーン・トランザクションが複数の再試行後も前記ブロックチェーン・ネットワーク内のノードに受理されない場合、前記受理されないブロックチェーン・トランザクションのナンスを、前記プロセッサが、当該受理されないブロックチェーン・トランザクションに関連付けられたアカウントが再使用に利用できるナンスのプールに割り当てる工程と、
ナンスを割り当てる際、前記利用できるナンスのプールが、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを含むかどうか前記プロセッサが、考慮する工程と、
前記ナンスのプールが、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを少なくとも１つ含む場合、前記プロセッサが、最も低い値のナンスを選択し、その最も低い値のナンスを前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションに割り当てる工程と
を有するものである方法。
【請求項11】
請求項１０記載の方法において、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、さらに、前記プロセッサが、前記ブロックチェーン・ネットワーク内のノードから前記アカウント用のナンスを取得する工程と（Nweb3）、
前記プロセッサが、前回自動的に前記アカウントに割り当てられたナンスを取得する工程と（Nred）、
前記プロセッサが、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス（Nweb3）を、前回自動的に前記アカウントに割り当てられた前記ナンス（Nred）から減算する工程と、
事前定義されたナンス・ウィンドウよりNred - Nweb3が大きい場合、前記プロセッサが、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス（Nweb3）を選択し、それ以外の場合は、より大きな値を有するナンスを選択する工程と
を有するものである方法。
【請求項12】
請求項７記載の方法において、前記送信されたデジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、その拒否されたブロックチェーン・トランザクションのナンスはナンスのプールに書き込まれ、そのプール内の最低値のナンスが、前記ブロックチェーン・ネットワーク内のノードへの送信用に生成された、次に受信されたブロックチェーン・トランザクションにより使用され、前記拒否されたブロックチェーン・トランザクションは、再びデジタル署名または認証される前に、前記ブロックチェーン・ネットワーク内のノードへの再送信用に、新規ナンスが自動的に割り当てられるものである方法。
【請求項13】
請求項７記載の方法において、前記少なくとも１つのトランザクション属性は、プロキシの演算およびストレージ・コスト単位あたりのブロックチェーン・トランザクション手数料として前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの送信者が支払いを申し出ている額を有し、前記手数料は、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの処理について、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担され、前記額は、前記ブロックチェーン・ネットワークで最近受理されたブロックチェーン・トランザクションに関連付けられた額に基づいて計算されるものである方法。
【請求項14】
請求項７記載の方法において、さらに、最大量の演算およびストレージ・プロキシ単位（G）を自動的に計算する工程を有し、Gは、前記ノードを含む前記ブロックチェーン・ネットワークによる前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示すものであり、この自動計算工程は、
前記プロセッサが、前回採掘されたブロックの制限値を前記ブロックチェーン・ネットワークから取得する工程であって（Gmb）、前記制限値は、前記ノードを含む前記ブロックチェーン・ネットワークによる単一ブロックへの採掘用に選択されたブロックチェーン・トランザクションの処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量のプロキシ演算およびストレージ単位の合計の最大値を含む、工程と、
前記プロセッサが、前記トランザクションの処理に必要なプロキシ演算およびストレージ単位の実際量の推定値を取得する工程であって（Gdb）、
Gdb ≧ Gmbの場合、G = Gmb * αを割り当て（ここでα ＜1）、
Gmb ＞ Gdbの場合、比R = Gmb/Gdbを計算し、
（R ≧ 0およびR ≦ 設定可能な係数CR1 、ここでCR1＞0）の場合、G = Gdb * β、
（R ＞ CR1およびR ≦ 設定可能な係数CR2 、ここでCR2＞ CR1）の場合、G = Gdb * γ、
（R ＞ CR2）の場合、G = Gdb * δ, where δ ＞ γ ＞ β ＞ 1
のようにGを見出す、工程と、
前記ブロックチェーン・トランザクションを前記ブロックチェーンネットワーク用にデジタル署名または認証する前に、前記プロセッサが、当該ブロックチェーン・トランザクションにGを加算し、前記デジタル署名または認証されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と
を有するものである方法。
【請求項15】
請求項７記載の方法において、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの処理について前記ノードを含む前記ブロックチェーン・ネットワークにより負担される、プロキシ単位あたりに推定される演算およびストレージ・コストのブロックチェーン・トランザクション手数料について、前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションの送信者が支払いを申し出ている額が低すぎる、または高すぎるという理由から、前記送信されたデジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記ノードを含む前記ブロックチェーン・ネットワークによる前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量の演算およびストレージ・プロキシ単位を所定のパーセンテージだけ増減調整し、スケジュールされた遅延後に前記ノードに前記デジタル署名または認証された検証済みの受信されたブロックチェーン・トランザクションを再送信するものである方法。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、Ｎｅｅｒａｊ Ｓｒｉｖａｓｔａｖａにより２０１９年１２月１３日付で出願された米国仮特許出願第６２／９４８，０６０号「Ｂｌｏｃｋｃｈａｉｎ Ｔｒａｎｓａｃｔｉｏｎ Ｍａｎａｇｅｒ」（ブロックチェーン・トランザクション・マネージャー）に基づく利益を主張するものであり、この参照によりその全体が本明細書に組み込まれる。
【0002】
本願は、実行中のコンピュータ・アプリケーションとブロックチェーン・ネットワーク間に介在して前記実行中のアプリケーションのブロックチェーン・トランザクションの送信と監視と受け取りとを支援する仲介システムを対象としたものである。
【背景技術】
【0003】
ブロックチェーン・トランザクション・パイプラインは、多くの課題に直面している。一部の課題は、ブロックチェーン・プラットフォーム全般に共通した、例えばトランザクションの送信と、それらの共有台帳での受け取り間の遅延である。他の課題は、著しくプラットフォーム特有で、例えばイーサリアム（Ｅｔｈｅｒｅｕｍ）におけるトランザクション「ナンス」の採番問題で起こる拒否などである。これらの問題にソリューションを提供し、前記共通した課題およびプラットフォーム特有の課題に対処する単一のインターフェースに、そのソリューションを実装することが望ましい。
この出願の発明に関連する先行技術文献情報としては、以下のものがある（国際出願日以降国際段階で引用された文献及び他国に国内移行した際に引用された文献を含む）。
（先行技術文献）
（特許文献）
（特許文献１） カナダ国特許出願公開第１１０２４５００６号明細書
（特許文献２） カナダ国特許出願公開第１１００６０１６１号明細書
（特許文献３） カナダ国特許出願公開第１１１６５１５２５号明細書
（特許文献４） 米国特許出願公開第２０２０／０２５０１７４号明細書
この出願の発明に関連する先行技術文献情報としては、以下のものがある（国際出願日以降国際段階で引用された文献及び他国に国内移行した際に引用された文献を含む）。
（先行技術文献）
（特許文献）
（特許文献１） カナダ国特許出願公開第１１０２４５００６号明細書
（特許文献２） カナダ国特許出願公開第１１００６０１６１号明細書
（特許文献３） カナダ国特許出願公開第１１１６５１５２５号明細書
（特許文献４） 米国特許出願公開第２０２０／０２５０１７４号明細書
【発明の概要】
【課題を解決するための手段】
【0004】
本明細書で説明するシステムおよび方法は、人的介入を最小限に抑えながら、アプリケーションがブロックチェーン・ネットワーク、例えばイーサリアムにトランザクションを送信できる率を最大限に伸ばし、成功して確定されるトランザクションの比率を最大限に伸ばすことにより、当該技術分野のニーズに対処する。本明細書で説明するインターフェースは、ユーザーのアプリケーションとブロックチェーン・ネットワーク間に挿入でき、これにより堅牢なトランザクション・パイプライン、ステータス・レポーティング、およびエラー管理という利点が得られる。本明細書で説明するブロックチェーン・トランザクション・マネージャーは、キュー、ならびにブロックチェーン・ネットワークの状態に応答してトランザクションを準備し各々の属性を繰り返し調整し、トランザクション・ステータスを知るためネットワークをポーリングするアルゴリズムを組み合わせたものにより、上記の課題に対処する。これらの能力は、並列性と、エラー後の自動再送信とを可能にする。
【0005】
第１の態様では、ブロックチェーン・トランザクション・マネージャーが提供され、このブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク内のノード用に意図されたブロックチェーン・トランザクションを受信し、前記ブロックチェーン・ネットワーク内のノードへの前記ブロックチェーン・トランザクションの送信を管理する。前記ブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・トランザクションを生成するユーザー・アプリケーションへのインターフェースを提供するトランザクション管理アプリケーションを含む。前記トランザクション管理アプリケーションは、前記ブロックチェーン・ネットワークおよびトランザクションを送信するアイデンティティについて必要な情報を受信し、受信されたブロックチェーン・トランザクションを検証し、前記受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる。トランザクション・ハンドラは、前記ブロックチェーン・ネットワークおよびアイデンティティの情報を格納し、受信されたブロックチェーン・ネットワークの少なくとも１つのトランザクション属性を準備し、前記ユーザー・アプリケーションにより事前に供給されたアイデンティティ・クレデンシャルを使って、前記受信されたブロックチェーン・トランザクションに対し、前記ブロックチェーン・ネットワークに適用可能であるとしてデジタル署名または認証し、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する。ブロックチェーン・ポーラーは、送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスを観察および報告する。
【0006】
実施形態例において、前記トランザクション管理アプリケーションは、前記ブロックチェーン・トランザクションを受信すると追跡目的でこれに汎用一意識別子を割り当てる。前記トランザクション・ハンドラは、さらに、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する試行を追跡用に追跡キューに入れ、前記ブロックチェーン・ネットワーク内のノードへ正常に送信されたブロックチェーン・トランザクションのステータス情報を格納する。
【0007】
他の実施形態において、管理アクティビティ・スケジューラは、前記ブロックチェーン・ネットワーク内のノードにより拒否されたトランザクションを受信し、前記拒否されたトランザクションを再試行する。また、前記ブロックチェーン・ポーラーにより送信されたブロックチェーン・トランザクションの初期ポーリングが、設定可能な最大試行回数を超えると、前記管理アクティビティ・スケジューラは、前記送信されたブロックチェーン・トランザクションのステータスを追跡し続けるために、前記ブロックチェーン・ステータスのさらなるポーリングをより低い頻度で前記ブロックチェーン・ポーラーによりスケジュールすることができる。
【0008】
さらに別の実施形態では、トランザクション管理コンソールが、インタラクティブなインターフェースを介して、人間のユーザーによる前記トランザクション管理アプリケーションへのアクセスを提供する。前記トランザクション管理コンソールは、前記ユーザーのインタラクティブなインターフェースを介して、ブロックチェーン・トランザクションと各々のステータスのリストを前記ユーザーに提供する。前記トランザクション管理コンソールは、さらに、ブロックチェーン・トランザクションに使用するアイデンティティまたはトランザクション認証クレデンシャルを管理する。
【0009】
前記ブロックチェーン・トランザクション・マネージャーは、さらに、データベースを含むことができ、このデータベースは、送信されたがまだ前記ブロックチェーン・ネットワーク内のノードに正常に書き込まれていないブロックチェーン・トランザクションを格納し、前記送信が成功しなかった理由と、前記送信されたブロックチェーン・トランザクションのステータスとを格納する。
【0010】
第２の態様では、ブロックチェーン・ネットワーク内のノードへのブロックチェーン・トランザクションの送信を管理する方法が提供される。この方法の実施形態例は、受信されたブロックチェーン・トランザクションを検証し、その検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる工程と、前記受信されたブロックチェーン・トランザクションの少なくとも１つのトランザクション属性を準備し、前記受信されたブロックチェーン・トランザクションを永続的キューに入れる工程と、前記ブロックチェーン・ネットワークに適切であるとして、前記受信されたブロックチェーン・トランザクションにデジタル署名し、またはこれを認証する工程と、前記デジタル署名または認証されたブロックチェーン・トランザクションを、前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と、前記送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングする工程とを含む。実施形態例において、前記ブロックチェーン・ステータスをポーリングする工程は、送信されたブロックチェーン・トランザクションの前記ブロックチェーン・ネットワークでの受理に向けた進捗状況に関する情報について、前記ブロックチェーン・ネットワーク内のノードをポーリングする工程と、望ましい進捗状況情報が受信されるまで前記ポーリングを再試行する工程とを含む。実施形態例において、前記ポーリング工程は、期限が切れた後または最大ポーリング試行回数後、頻度が低下する。
【0011】
実施形態例において、前記方法は、さらに、前記ブロックチェーン・ネットワーク内のノードに送信されたブロックチェーン・トランザクションの送信が、前記ブロックチェーン・ネットワークにより前記トランザクションが受理される結果になったかどうかを、前記ブロックチェーン・ネットワークに適した基準に基づいて示す応答を受信する工程と、前記送信されたブロックチェーン・トランザクションを、前記送信されたブロックチェーン・トランザクションのステータスとともにデータベースに書き込む工程とを含む。前記送信されたブロックチェーン・トランザクションの前記ステータスが、前記送信が成功しなかったことを示した場合、前記方法は、さらに、前記送信が成功しなかった理由を前記データベースに格納する工程を含む。
【0012】
他の実施形態例では、前記送信されたブロックチェーン・トランザクションが、再試行可能なエラーにより前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記拒否されたブロックチェーン・トランザクションの少なくとも１つのトランザクション属性に、修復アルゴリズムが適用されて、修復されたブロックチェーン・トランザクションが作成される。前記修復されたブロックチェーン・トランザクションは、デジタル署名され、前記修復されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する試行が行われる。前記送信されたブロックチェーン・トランザクションが、再試行可能なエラーにより前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記送信されたブロックチェーン・トランザクションは、受理されるまで若しくは再試行の上限を超えるまで、前記ブロックチェーン・ネットワーク内のノードに再送信される。前記再試行の上限を超えた場合は、格納された利用可能なトランザクション・ナンスのプールにナンス値を追加することにより前記トランザクションのナンスの可用性が示され、前記送信されたブロックチェーン・トランザクションが、データベース内のエラー発生トランザクション・テーブルに書き込まれ、最初に送信された生ブロックチェーン・トランザクションが抽出されて、その生ブロックチェーン・トランザクションが再び準備され、新規受信されたトランザクションと同じ工程を使って送信される。
【0013】
ブロックチェーン・ネットワークがイーサリアムと同様なトランザクション・ナンスを使用する、さらに別の実施形態例では、前記受信されたブロックチェーン・トランザクションにナンスが自動的に割り当てられる。前記受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、同じアカウントおよびブロックチェーン・ネットワーク用に複数のブロックチェーン・トランザクションが並列処理されている場合、ロック機構を使って、必ず一度に１つのトランザクションについてしかナンスが計算されないようにする工程を含むことができる。ブロックチェーン・トランザクションが複数の再試行後も前記ブロックチェーン・ネットワーク内のノードに受理されない場合、前記受理されないブロックチェーン・トランザクションのナンスを、当該受理されないブロックチェーン・トランザクションに関連付けられたアカウントが再使用に利用できるナンスのプールに割り当てることができる。前記方法は、さらに、ナンスを割り当てる際、前記利用できるナンスのプールが、前記受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを含むかどうか考慮する工程と、前記ナンスのプールが、前記受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを少なくとも１つ含む場合、最も低い値のナンスを選択し、その最も低い値のナンスを前記受信されたブロックチェーン・トランザクションに割り当てる工程とを含むことができる。
【0014】
前記受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、さらに、前記ブロックチェーン・ネットワーク内のノードから前記アカウント用のナンスを取得する工程と（Nweb3）、前回自動的に前記アカウントに割り当てられたナンスを取得する工程と（Nred）、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス（Nweb3）を、前回自動的に前記アカウントに割り当てられた前記ナンス（Nred）から減算する工程と、事前定義されたナンス・ウィンドウよりNred - Nweb3が大きい場合、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス（Nweb3）を選択し、それ以外の場合は、より大きな値を有するナンスを選択する工程とを有することができる。前記方法は、さらに、前記受信されたブロックチェーン・トランザクションにデジタル署名する前に、前記アカウントに利用可能な最低のナンスを選択する工程と、前記選択された最低ナンスよりも低い値を有するナンスが前記プールに含まれる場合、前記選択されたナンスを、前記プールからのより低い値のナンスと取り替える工程と、前記プールからの前記より低い値のナンスを、前記受信されたブロックチェーン・トランザクション用に使う工程とを含むことができる。
【0015】
他の実施形態例では、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、その拒否されたブロックチェーン・トランザクションのナンスはナンスのプールに書き込まれ、そのプール内の最低値のナンスが、前記ブロックチェーン・ネットワーク内のノードへの送信用に準備された、次に受信されるブロックチェーン・トランザクションにより使用されるものである方法。前記拒否されたブロックチェーン・トランザクションは、再びデジタル署名される前に、前記ブロックチェーン・ネットワーク内のノードへの再送信用に、新規ナンスが自動的に割り当てられる。
【0016】
さらに別の実施形態例において、前記少なくとも１つのトランザクション属性は、プロキシの演算およびストレージ・コスト単位あたりのブロックチェーン・トランザクション手数料として前記ブロックチェーン・トランザクションの送信者が支払いを申し出ている額を有し、前記手数料は、前記ブロックチェーン・トランザクションの処理について、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担される。前記額は、前記ブロックチェーン・ネットワークで最近受理されたブロックチェーン・トランザクションに関連付けられた額に基づいて自動的に計算できる。前記方法は、最大量の演算およびストレージ・プロキシ単位（G）を自動的に計算する工程を含むこともでき、Gは、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークによる前記ブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示すものである。このような方法は、前回採掘されたブロックの制限値を前記ブロックチェーン・ネットワークから取得する工程を含むことができ（Gmb）、前記制限値は、前記ブロックチェーン・ネットワーク内のノードを含む前記ブロックチェーン・ネットワークによる単一ブロックへの採掘用に選択されたブロックチェーン・トランザクションの処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量のプロキシ演算およびストレージ単位の合計の最大値を含む。次に、Gdb ≧ Gmbの場合、G = Gmb * αを割り当て（ここでα ＜1）、Gmb ＞ Gdbの場合、比R = Gmb/Gdbを計算して、以下のようにGを見出す。
【0017】
（R ≧ 0およびR ≦ 設定可能な係数CR1 、ここでCR1＞0）の場合、G = Gdb * β、
（R ＞ CR1およびR ≦ 設定可能な係数CR2 、ここでCR2＞ CR1）の場合、G = Gdb * γ、および
（R ＞ CR2）の場合、G = Gdb * δ, where δ ＞ γ ＞ β ＞ 1
次いで、前記ブロックチェーン・トランザクションにデジタル署名し若しくはこれを認証する前に、当該ブロックチェーン・トランザクションに適切な場合、当該ブロックチェーン・トランザクションにGが加算され、前記デジタル署名され若しくは認証されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行される。
（R ＞ CR1およびR ≦ 設定可能な係数CR2 、ここでCR2＞ CR1）の場合、G = Gdb * γ、および
（R ＞ CR2）の場合、G = Gdb * δ, where δ ＞ γ ＞ β ＞ 1
次いで、前記ブロックチェーン・トランザクションにデジタル署名し若しくはこれを認証する前に、当該ブロックチェーン・トランザクションに適切な場合、当該ブロックチェーン・トランザクションにGが加算され、前記デジタル署名され若しくは認証されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行される。
【0018】
他の実施形態では、前記ブロックチェーン・トランザクションの処理について前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担される、プロキシ単位あたりに推定される演算およびストレージ・コストのブロックチェーン・トランザクション手数料について、前記ブロックチェーン・トランザクションの送信者が支払いを申し出ている額が低すぎる、または高すぎるという理由から、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークによる前記ブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量の演算およびストレージ・プロキシ単位が所定のパーセンテージだけ増減調整され、前記ブロックチェーン・トランザクションが、スケジュールされた遅延後に前記ブロックチェーン・ネットワーク内のノードに再送信される。
【0019】
本明細書で説明する実施形態は、本開示全体にわたり説明する方法を実装する命令によりコードされたコンピュータ・システムおよびコンピュータ可読媒体も包含する。例えば、本明細書で説明する前記システムおよび方法は、本明細書で説明するように、クラウドのコンピューティング・プラットフォーム上で実装して、データにアクセスし、これをブロックチェーン・プラットフォームに格納する機能を提供することができる。
【図面の簡単な説明】
【0020】
本開示については、添付の図面の例により非限定的に例示しており、これらの図面において、同様な参照番号は同様な要素を示す。
【発明を実施するための形態】
【0021】
以下の説明は、図１～１５を参照して、当業者が実施できるよう具体的な実施形態を十分に例示したものである。他の実施形態では、構造上、論理上、工程上、および他の変更を実装できる。一部の実施形態の部分および特徴は、他の実施形態の部分および特徴に含め、またはそれを置き換えることができる。請求項に記載した実施形態は、それら請求項の利用可能なすべての等価物を包含する。
【0022】
用語
ブロックチェーン：ブロックと呼ばれるレコードの、絶えず成長し続けるリスト。前記レコードは暗号を使ってリンクされ、固定される。各ブロックは、通常、直前のブロックの暗号ハッシュ、タイムスタンプ、およびトランザクション・データを含む。ブロックチェーンは、トランザクション・データの改ざんに本質的に耐性があるよう設計される。分散台帳としての用途のため、ブロックチェーンは、通常、新規ブロック検証用のプロトコルに集合的に準拠するピアツーピア・ネットワークにより管理される。一度記録されると、いかなる所与のブロックのデータも、すべての後続ブロックを変更することなく遡及的に変更することはできず、全後続ブロック変更には、ネットワークの過半数による共謀が必要になる。
ブロックチェーン：ブロックと呼ばれるレコードの、絶えず成長し続けるリスト。前記レコードは暗号を使ってリンクされ、固定される。各ブロックは、通常、直前のブロックの暗号ハッシュ、タイムスタンプ、およびトランザクション・データを含む。ブロックチェーンは、トランザクション・データの改ざんに本質的に耐性があるよう設計される。分散台帳としての用途のため、ブロックチェーンは、通常、新規ブロック検証用のプロトコルに集合的に準拠するピアツーピア・ネットワークにより管理される。一度記録されると、いかなる所与のブロックのデータも、すべての後続ブロックを変更することなく遡及的に変更することはできず、全後続ブロック変更には、ネットワークの過半数による共謀が必要になる。
【0023】
スマート・コントラクト：ブロックチェーンまたは分散台帳で行われる汎用演算を提供するコンピュータ・プロトコル。スマート・コントラクト・トランザクションは、単純であっても、洗練された論理を実装するものであってもよい。その結果得られるトランザクションは、通常、台帳参加者に透明で、追跡可能および不可逆的である。種々の分散台帳技術プラットフォーム、例えばイーサリアムは、実装タイプのスマート・コントラクトを有する。イーサリアムの場合、スマート・コントラクトはプログラミングを高度に抽象化したものであり、バイトコードにまでコンパイルされ、イーサリアム・ブロックチェーンにデプロイされ、実行される。
【0024】
Ｎｏｄｅ．ｊｓ（登録商標）：ＪａｖａＳｃｒｉｐｔコードをブラウザ外で実行する無料オープンソース・サーバー環境。Ｎｏｄｅ．ｊｓ（登録商標）は、ＣｈｒｏｍｅブラウザのＪａｖａＳｃｒｉｐｔランタイム上で構築された非同期プログラミング・プラットフォームである。Ｎｏｄｅ．ｊｓ（登録商標）に関する詳細は、「Ａｂｏｕｔ Ｎｏｄｅ．ｊｓ（登録商標）」、Ｎｏｄｅ．ｊｓ、Ｎｏｄｅ．ｊｓ Ｆｏｕｎｄａｔｉｏｎ、ｈｔｔｐｓ：／／ｎｏｄｅｊｓ．ｏｒｇ／ｅｎ／ａｂｏｕｔ／で参照できる。
【0025】
イーサリアム用語：本明細書で説明する実施形態例については、一般に使用されイーサリアムとして知られているブロックチェーン・プラットフォームを参照して説明する。イーサリアムの論文、実装、および関連ライブラリでは、同じ概念に異なる名称を使用する場合があり、本明細書では、以下の意味に沿った方法で、以下の用語が使用される。
【0026】
プラットフォームの属性
Ether（イーサ）：イーサリアム・ブロックチェーン・プラットフォーム固有の仮想通貨。この通貨の用途の１つは、ネットワークを代表してマイナー（採掘者）の仕事に報酬を支払うことである。この点でイーサリアムと同様なブロックチェーン・プラットフォームについては、本明細書における「イーサ」は、考慮されるプラットフォームに固有の類似仮想通貨と同義的なものと見なすべきである。
Ether（イーサ）：イーサリアム・ブロックチェーン・プラットフォーム固有の仮想通貨。この通貨の用途の１つは、ネットワークを代表してマイナー（採掘者）の仕事に報酬を支払うことである。この点でイーサリアムと同様なブロックチェーン・プラットフォームについては、本明細書における「イーサ」は、考慮されるプラットフォームに固有の類似仮想通貨と同義的なものと見なすべきである。
【0027】
Miner（マイナー）：ブロックチェーン・トランザクションを評価し、ブロックチェーン・データの完全性を各々のネットワーク内で集合的に維持する演算を実行するエンティティ（実体）。
【0028】
トランザクション・ライフサイクル用語
Submitter（送信者）：トランザクションに関連付けられたブロックチェーン・ネットワーク・アイデンティティであり、トランザクション用アイデンティティのクレデンシャルは、当該トランザクションのデジタル署名用に、および手数料が課金される仮想通貨アカウントに対して使用される。
Submitter（送信者）：トランザクションに関連付けられたブロックチェーン・ネットワーク・アイデンティティであり、トランザクション用アイデンティティのクレデンシャルは、当該トランザクションのデジタル署名用に、および手数料が課金される仮想通貨アカウントに対して使用される。
【0029】
Sending/Sent（送信中／送信済み）：ブロックチェーン・ネットワーク内の近傍ノード宛トランザクションの初回通信（または試行）。
【0030】
Rejected（拒否）：ブロックチェーン・ネットワーク内の近傍ノードへの初回通信中、エラーのためトランザクションが拒否された。
【0031】
Pending（保留中）：初回通信中にトランザクションが受理され、保留中トランザクション・リストに入れられ、他のブロックチェーン・ネットワーク・ノードにブロードキャストされているが、採掘されているかはまだ不明である。
【0032】
Mined（採掘済み）：トランザクションが評価され、ブロックに含められ、ブロックチェーンに追加された（少なくとも所与のノードから見て）。トランザクションが成功（Succeeded）または失敗（Failed）した。
【0033】
Receipt（レシート）：ブロックチェーン・ネットワーク内の近傍ノードから発信されるデータで、成功または失敗に関する情報を含めて、トランザクションが採掘されたことがわかった旨を示す。（「Receipt」（レシート）は、広く使用されているweb3ソフトウェア・ライブラリが使用している用語で、イーサリアム・ノードで使用される。）
Succeeded（成功）：採掘済みトランザクションが、採掘時にエラーなく完全に実行された。
Succeeded（成功）：採掘済みトランザクションが、採掘時にエラーなく完全に実行された。
【0034】
Failed（失敗）：採掘済みトランザクションが採掘時にエラーを起こし、完全に実行されず、失敗に関する詳細のブロックへの記録と、送信者の仮想通貨アカウントに対する当該試行の手数料の課金とを除いて影響は生じなかった。失敗は、種々の理由で起こる可能性があり、そのいくつかは本明細書で説明している。
【0035】
Finalized（確定）：当該ブロックチェーン・ネットワークの別部分でトランザクション確認処理がより進んだことが発見されたためブロックチェーン内でブロックが置換されるという事態になる可能性が極めて低いトランザクション。これを決定する正式な仕様はないが、通常は、後続して追加されるブロックの数に基づく。
【0036】
Simple Transaction（単純なトランザクション）：新規スマート・コントラクトを含まないブロックチェーン・トランザクション。
【0037】
Contract Transaction（コントラクト・トランザクション）：新規スマート・コントラクトを含むブロックチェーン・トランザクション。
【0038】
トランザクションの属性
Gas（ガス代、燃料代）：総演算量およびストレージ・コストの推定用に標準化されたプロキシ単位額であり、所与のトランザクションが処理されるとイーサリアムと同様なブロックチェーン・ネットワークが負担し、これをもとにトランザクションの送信者に手数料が課金される。「Gas」は、プロキシ単位であり、このような見積り総額の用語でもある。
Gas（ガス代、燃料代）：総演算量およびストレージ・コストの推定用に標準化されたプロキシ単位額であり、所与のトランザクションが処理されるとイーサリアムと同様なブロックチェーン・ネットワークが負担し、これをもとにトランザクションの送信者に手数料が課金される。「Gas」は、プロキシ単位であり、このような見積り総額の用語でもある。
【0039】
Startgas（ガス代の上限）：提案されたトランザクションに対して支払う意思がある上限額としてトランザクション送信者が示すプロキシ演算およびストレージの最大単位数。（これはweb3ライブラリ用語である。イーサリアムのイエローペーパーでは、これを「gas limit」（ガスリミット）と呼ぶ。
【0040】
Gasprice（ガス価格）：トランザクション送信者が、そのトランザクションを採掘するアカウントに申し出ている支払い額であり、そのトランザクションの処理中に消費された単位ガス代あたりの仮想通貨手数料。
【0041】
Intrinsic gas（トランザクションで使われるガス）：任意のスマート・コントラクト・コード実行前に、トランザクションが使用するであろうガス代。ベースラインのトランザクション・ガス代に、トランザクションに伴うパラメータとして供給される任意データのガス代を加えたものを含む。（後者が計算されるのは、トランザクションが失敗しても、入力パラメータがブロックチェーンに記録されるためである。）
Nonce（ナンス）：本明細書においてナンスに関するすべての説明は、イーサリアムおよび同様なブロックチェーン・プラットフォーム上における送信者のトランザクションに必要な連番の採番に関する。
Nonce（ナンス）：本明細書においてナンスに関するすべての説明は、イーサリアムおよび同様なブロックチェーン・プラットフォーム上における送信者のトランザクションに必要な連番の採番に関する。
【0042】
ネットワークの属性
Block gas limit（ブロック・ガスリミット）：これは、ネットワーク上のマイナーが、保留中のトランザクションを単一ブロックで採掘するために選択する場合、選択された全トランザクションに対して許容されるstartgasの最大合計値である。各イーサリアム・ネットワーク、またはマイナーに報酬を支払うための同様な構造を備えたプラットフォームに基づくネットワークには、独自の制限値があり、各新規ブロックが追加された後に少量増加または減少する。
Block gas limit（ブロック・ガスリミット）：これは、ネットワーク上のマイナーが、保留中のトランザクションを単一ブロックで採掘するために選択する場合、選択された全トランザクションに対して許容されるstartgasの最大合計値である。各イーサリアム・ネットワーク、またはマイナーに報酬を支払うための同様な構造を備えたプラットフォームに基づくネットワークには、独自の制限値があり、各新規ブロックが追加された後に少量増加または減少する。
【0043】
ブロックチェーン・ノードの属性
Nonce window（ナンス・ウィンドウ）：トランザクションが有することのできる、ノードに受理される最高のナンス値であり、所与の送信者アイデンティティ用に前記ノードがブロックチェーン・ネットワークに送信した前回のトランザクションのナンスよりもデルタだけ高いものとして表現される。ナンス・ウィンドウの効果は、ブロードキャスト保留中のノードで各アイデンティティについて存在できるトランザクションの数を制限することである。ナンス・ウィンドウは、ブロックチェーン・ネットワーク内のノードごとに構成できる。
Nonce window（ナンス・ウィンドウ）：トランザクションが有することのできる、ノードに受理される最高のナンス値であり、所与の送信者アイデンティティ用に前記ノードがブロックチェーン・ネットワークに送信した前回のトランザクションのナンスよりもデルタだけ高いものとして表現される。ナンス・ウィンドウの効果は、ブロードキャスト保留中のノードで各アイデンティティについて存在できるトランザクションの数を制限することである。ナンス・ウィンドウは、ブロックチェーン・ネットワーク内のノードごとに構成できる。
【0044】
Proximate node（近傍ノード）：ブロックチェーン・ネットワーク内のノードであって、ユーザーまたはアプリケーションが、当該ブロックチェーン・ネットワーク全体とインタラクトするうえで最も直接的に通信するノード。
【0045】
概要
ブロックチェーン・トランザクションの課題
本明細書で説明するブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク、例えばイーサリアムと直接連動する場合、または現在広く使用されているサポート・ライブラリを使用する場合、アプリケーションが直面する難題に対処する。上記のように、本明細書の説明は、一般に使用されるイーサリアム・ブロックチェーン・ネットワークについて行うが、当業者であれば、本明細書で説明する技術は、他のブロックチェーン・ネットワーク、例えばAION、ArcBlock、EOS、NEO、Hyperledger（登録商標） Fabric、Hyperledger（登録商標） Sawtooth、NxT、QTUM、Quorum、Smilo、Tezos、TRON、Wanchain、またはZilliqaにも使用できることが理解されるであろう。本明細書における用語は、イーサリアム・ブロックチェーン・ネットワークに関するものである。対応する用語は、他のブロックチェーン・ネットワーク、例えば言及したものの文脈で使用される。
ブロックチェーン・トランザクションの課題
本明細書で説明するブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク、例えばイーサリアムと直接連動する場合、または現在広く使用されているサポート・ライブラリを使用する場合、アプリケーションが直面する難題に対処する。上記のように、本明細書の説明は、一般に使用されるイーサリアム・ブロックチェーン・ネットワークについて行うが、当業者であれば、本明細書で説明する技術は、他のブロックチェーン・ネットワーク、例えばAION、ArcBlock、EOS、NEO、Hyperledger（登録商標） Fabric、Hyperledger（登録商標） Sawtooth、NxT、QTUM、Quorum、Smilo、Tezos、TRON、Wanchain、またはZilliqaにも使用できることが理解されるであろう。本明細書における用語は、イーサリアム・ブロックチェーン・ネットワークに関するものである。対応する用語は、他のブロックチェーン・ネットワーク、例えば言及したものの文脈で使用される。
【0046】
１．採掘予定または確定済みトランザクションのための同期的なWait
ブロックに追加予定のトランザクション、または何らかの措置により「ファイナリティ」を達成するためのトランザクションの時間遅延は、大部分のブロックチェーン・プラットフォームに共通する課題である。ナイーブなアプリケーションでは「ファイア・アンド・フォーゲット」アプローチをとり、ブロックチェーン・ネットワーク内の近傍ノードにトランザクションを送信し、それが成功するものと想定して、その後のアクティビティがそれ以外の状況になるまで、手続きを進める。より確実性を求める者は、手続きを進める前に、トランザクションが採掘または確定されるのを一般的な時間長だけ待つことを選択する。しかしながら、これらのアプローチはどちらも理想的ではない。一方は後続工程の不確実性増大を招き、他方は数分間の同期的な待ち時間を生じる。
ブロックに追加予定のトランザクション、または何らかの措置により「ファイナリティ」を達成するためのトランザクションの時間遅延は、大部分のブロックチェーン・プラットフォームに共通する課題である。ナイーブなアプリケーションでは「ファイア・アンド・フォーゲット」アプローチをとり、ブロックチェーン・ネットワーク内の近傍ノードにトランザクションを送信し、それが成功するものと想定して、その後のアクティビティがそれ以外の状況になるまで、手続きを進める。より確実性を求める者は、手続きを進める前に、トランザクションが採掘または確定されるのを一般的な時間長だけ待つことを選択する。しかしながら、これらのアプローチはどちらも理想的ではない。一方は後続工程の不確実性増大を招き、他方は数分間の同期的な待ち時間を生じる。
【0047】
２．ナンス・ギャップにより生じるトランザクション停止
イーサリアムなどのブロックチェーン・プラットフォームで採用されているトランザクション「ナンス」の概念に関する難題の２つ目のカテゴリー。ナンスとは、所与のブロックチェーン・アイデンティティ用に送信されたトランザクションに順次割り当てられるとして、ネットワークが予測する数値である。ナンスは送信者により割り当てられるが、実際には、送信者は、これを当該ブロックチェーン・ネットワークに関連付けられたサポート・コード・ライブラリに委託することが多い。イーサリアムと同様なネットワークは、ナンス数値の順にトランザクションを処理しようとし、それが種々の理由でトランザクションの遅延または失敗につながる場合がある。すでに処理された値より低い、または著しく高い値を伴うトランザクションは、完全に失敗する。シーケンスにない値は、シーケンス中のギャップが埋まるまで、後続ナンスを伴うトランザクションが無視される原因となる。
イーサリアムなどのブロックチェーン・プラットフォームで採用されているトランザクション「ナンス」の概念に関する難題の２つ目のカテゴリー。ナンスとは、所与のブロックチェーン・アイデンティティ用に送信されたトランザクションに順次割り当てられるとして、ネットワークが予測する数値である。ナンスは送信者により割り当てられるが、実際には、送信者は、これを当該ブロックチェーン・ネットワークに関連付けられたサポート・コード・ライブラリに委託することが多い。イーサリアムと同様なネットワークは、ナンス数値の順にトランザクションを処理しようとし、それが種々の理由でトランザクションの遅延または失敗につながる場合がある。すでに処理された値より低い、または著しく高い値を伴うトランザクションは、完全に失敗する。シーケンスにない値は、シーケンス中のギャップが埋まるまで、後続ナンスを伴うトランザクションが無視される原因となる。
【0048】
３．トランザクション手数料の期待値変更について手動でリコンフィグレーションする必要性
イーサリアム同様に採掘者への支払い機構を備えたブロックチェーン・プラットフォームで受理されるようにするため、トランザクションは、上記で定義したgaspriceに部分的に基づき、ネットワークへの手数料としてトランザクターが支払う意思のある最大額を伴う。gaspriceを軽んじると、より気前のよいトランザクションがブロックチェーンに含められるべく選択されることになり、長時間または無期限の遅延を招きかねない。後者は、好まれる価格の経時的な変動により、課題として複雑化する。しかし、その変動性に合わせてgaspriceを十分高く設定するということは、ほとんどの場合に過払いすることを意味する。そのため、大部分のトランザクターは、定期的に、またトランザクションが通らないと気づいたときにも、各々のアプリケーションが提案する価格を手動で調整する（そのトランザクションは、次いで新規に送信されなければならない）。
イーサリアム同様に採掘者への支払い機構を備えたブロックチェーン・プラットフォームで受理されるようにするため、トランザクションは、上記で定義したgaspriceに部分的に基づき、ネットワークへの手数料としてトランザクターが支払う意思のある最大額を伴う。gaspriceを軽んじると、より気前のよいトランザクションがブロックチェーンに含められるべく選択されることになり、長時間または無期限の遅延を招きかねない。後者は、好まれる価格の経時的な変動により、課題として複雑化する。しかし、その変動性に合わせてgaspriceを十分高く設定するということは、ほとんどの場合に過払いすることを意味する。そのため、大部分のトランザクターは、定期的に、またトランザクションが通らないと気づいたときにも、各々のアプリケーションが提案する価格を手動で調整する（そのトランザクションは、次いで新規に送信されなければならない）。
【0049】
４．ブロックチェーン・トランザクションの拒否と失敗の発見および扱いに関する難題
ナンスおよびトランザクション手数料は、トランザクションが拒否および失敗する原因のうちのほんの２つである。これらと、スマート・コントラクト自体に起因するエラーを含む他の原因は、ブロックチェーン処理の非同期的な性質上、またプラットフォームからのエラー・レポートが不親切なため、検出が難しい。検出された場合は、対処が困難である。以下では、本明細書で説明するブロックチェーン・トランザクション・マネージャーに関連する具体的なエラー条件についていくつか説明する。
ナンスおよびトランザクション手数料は、トランザクションが拒否および失敗する原因のうちのほんの２つである。これらと、スマート・コントラクト自体に起因するエラーを含む他の原因は、ブロックチェーン処理の非同期的な性質上、またプラットフォームからのエラー・レポートが不親切なため、検出が難しい。検出された場合は、対処が困難である。以下では、本明細書で説明するブロックチェーン・トランザクション・マネージャーに関連する具体的なエラー条件についていくつか説明する。
【0050】
低ナンス・エラー
トランザクションへのナンス割り当ては、シーケンシャル処理として設計されている。各トランザクションは、二重支出い問題を防ぐため、ナンス（整数）と結び付られる。提案された各トランザクションにつき、ナンスは、その前のトランザクションのナンスより１大きいことが要求される。nonce low error（低ナンス・エラー）は、トランザクションが送信者からネットワークに対し、その送信者が前回採掘した直近のトランザクションよりも低いナンスを用いて提案されたときに起こる。この状況は、トランザクションを送信するアプリケーションの水平スケーリング試行中、例えばナイーブなナンス割り当てアルゴリズム、例えば広く使用されているイーサリアム・サポート・ライブラリに見られるものが使用された場合に起こりうる。それらのライブラリは、前記送信者の最高ナンスに関する独自のローカルな観察に基づき、ナンスを自動割り当てする。複数のインスタンスがこれを並行して試行すると、重複したナンス割り当てが起こる可能性が高く、２番目に処理されたものが失敗する結果となる。
トランザクションへのナンス割り当ては、シーケンシャル処理として設計されている。各トランザクションは、二重支出い問題を防ぐため、ナンス（整数）と結び付られる。提案された各トランザクションにつき、ナンスは、その前のトランザクションのナンスより１大きいことが要求される。nonce low error（低ナンス・エラー）は、トランザクションが送信者からネットワークに対し、その送信者が前回採掘した直近のトランザクションよりも低いナンスを用いて提案されたときに起こる。この状況は、トランザクションを送信するアプリケーションの水平スケーリング試行中、例えばナイーブなナンス割り当てアルゴリズム、例えば広く使用されているイーサリアム・サポート・ライブラリに見られるものが使用された場合に起こりうる。それらのライブラリは、前記送信者の最高ナンスに関する独自のローカルな観察に基づき、ナンスを自動割り当てする。複数のインスタンスがこれを並行して試行すると、重複したナンス割り当てが起こる可能性が高く、２番目に処理されたものが失敗する結果となる。
【0051】
ガス代が低すぎる、ガス代が高すぎる、およびガス切れ
上述のように、イーサリアムなどのブロックチェーン・プラットフォームにおけるトランザクションには、ネットワークへの手数料として送信者が支払う意思のある最大額が伴う。その額は、部分的に、トランザクション属性startgas、送信者に許容されるプロキシ演算の上限、およびトランザクションのストレージ単位に基づく。startgasについて選択される額がトランザクションの問題を起こす状況は３つある。その２つは、ブロックチェーン・ネットワーク内のノードにより、トランザクションがそのネットワークに送信されるとき、決定される。これらのプラットフォーム内の各トランザクションは、演算およびストレージに最低量のプロキシ単位を消費し、これをトランザクションの「intrinsic gas」という。そのため、startgasがこれよりも低く設定されると、トランザクションはただちにgas low error（ガス代が少ないためのエラー）で拒否される。startgasを高すぎる値で割り当てても問題が生じる。startgasがブロック・ガスリミットよりも高い場合、トランザクションはgas exceeded error（ガス代が高すぎるためのエラー）で拒否されるが、これはネットワークの現状でそのトランザクションが明らかにブロックに収容できないことをノードが認識するためである。ガス関連の３つ目の問題は、トランザクションの採掘時にのみ発見されるが、これはトランザクションの厳密なストレージおよび演算ニーズが実際に実行されるときにしかわからないためである。startgasが実際に必要なガス代よりも低い場合、マイナーは、当該限度額に達し次第、トランザクションの処理を停止し、それをout-of-gas failure（ガス切れによる失敗）としてブロックチェーンに記録する。そのトランザクションの影響が記録されるものの、演算処理はネットワークにより実行済みであるため、送信者のイーサ・アカウントに対してstartgas全額に基づく手数料が課金される。
上述のように、イーサリアムなどのブロックチェーン・プラットフォームにおけるトランザクションには、ネットワークへの手数料として送信者が支払う意思のある最大額が伴う。その額は、部分的に、トランザクション属性startgas、送信者に許容されるプロキシ演算の上限、およびトランザクションのストレージ単位に基づく。startgasについて選択される額がトランザクションの問題を起こす状況は３つある。その２つは、ブロックチェーン・ネットワーク内のノードにより、トランザクションがそのネットワークに送信されるとき、決定される。これらのプラットフォーム内の各トランザクションは、演算およびストレージに最低量のプロキシ単位を消費し、これをトランザクションの「intrinsic gas」という。そのため、startgasがこれよりも低く設定されると、トランザクションはただちにgas low error（ガス代が少ないためのエラー）で拒否される。startgasを高すぎる値で割り当てても問題が生じる。startgasがブロック・ガスリミットよりも高い場合、トランザクションはgas exceeded error（ガス代が高すぎるためのエラー）で拒否されるが、これはネットワークの現状でそのトランザクションが明らかにブロックに収容できないことをノードが認識するためである。ガス関連の３つ目の問題は、トランザクションの採掘時にのみ発見されるが、これはトランザクションの厳密なストレージおよび演算ニーズが実際に実行されるときにしかわからないためである。startgasが実際に必要なガス代よりも低い場合、マイナーは、当該限度額に達し次第、トランザクションの処理を停止し、それをout-of-gas failure（ガス切れによる失敗）としてブロックチェーンに記録する。そのトランザクションの影響が記録されるものの、演算処理はネットワークにより実行済みであるため、送信者のイーサ・アカウントに対してstartgas全額に基づく手数料が課金される。
【0052】
リモート・プロシージャ・コール（ＲＰＣ）の応答がない
トランザクションを送信するアプリケーションは、通常、リモート・プロシージャ・コールによりブロックチェーン・ネットワーク内の近傍ノードとインタラクトする。これがアプリケーションにとり問題となるのは、ノードがそれらコールに対して一時的に反応しなくなる場合であり、その場合、結果的にトランザクションは受け取られない。
トランザクションを送信するアプリケーションは、通常、リモート・プロシージャ・コールによりブロックチェーン・ネットワーク内の近傍ノードとインタラクトする。これがアプリケーションにとり問題となるのは、ノードがそれらコールに対して一時的に反応しなくなる場合であり、その場合、結果的にトランザクションは受け取られない。
【0053】
残高不足
トランザクションは、トランザクションの送信時にgaspriceとstartgasの積が送信者のアカウントにあるイーサ額より大きいと、insufficient funds error（残高不足によるエラー）で拒否される。
トランザクションは、トランザクションの送信時にgaspriceとstartgasの積が送信者のアカウントにあるイーサ額より大きいと、insufficient funds error（残高不足によるエラー）で拒否される。
【0054】
「既知のトランザクション」エラー
提案されたトランザクションについてすでに情報を得ているかどうかをノードが識別できるようにするため、各トランザクションの属性は識別用ハッシュに含められる。ハッシュとは、それらの属性に関しては一意だが後続のトランザクションに関しては、そのトランザクションが厳密に同じ属性を有するならば同一のものとなる値である。ノードは、その保留中トランザクションリストにすでにあるハッシュと同じハッシュを伴ったトランザクションを受け取ると、known transaction error（既知のトランザクション・エラー）により、そのトランザクションを拒否する。（同じハッシュを伴った先行トランザクションがすでに採掘済みである場合も後続トランザクションは失敗するが、その場合はnonce low error（低ナンス・エラー）となる。）
５．システム障害によるトランザクション損失
ブロックチェーン・トランザクションを送信する自動システムは複数の工程を伴い、これにはトランザクション属性の追加、デジタル署名、ブロックチェーンへの送信（可能性として、その過程でサードパーティのライブラリを経由する）、および永続的ステータスおよび他のデータが含まれる。この工程を単独で管理するアプリケーションは、エラー、例外、またはサービス障害の扱いが洗練されていないと、これらの工程のいずれかでトランザクションまたはデータを失いやすい。
提案されたトランザクションについてすでに情報を得ているかどうかをノードが識別できるようにするため、各トランザクションの属性は識別用ハッシュに含められる。ハッシュとは、それらの属性に関しては一意だが後続のトランザクションに関しては、そのトランザクションが厳密に同じ属性を有するならば同一のものとなる値である。ノードは、その保留中トランザクションリストにすでにあるハッシュと同じハッシュを伴ったトランザクションを受け取ると、known transaction error（既知のトランザクション・エラー）により、そのトランザクションを拒否する。（同じハッシュを伴った先行トランザクションがすでに採掘済みである場合も後続トランザクションは失敗するが、その場合はnonce low error（低ナンス・エラー）となる。）
５．システム障害によるトランザクション損失
ブロックチェーン・トランザクションを送信する自動システムは複数の工程を伴い、これにはトランザクション属性の追加、デジタル署名、ブロックチェーンへの送信（可能性として、その過程でサードパーティのライブラリを経由する）、および永続的ステータスおよび他のデータが含まれる。この工程を単独で管理するアプリケーションは、エラー、例外、またはサービス障害の扱いが洗練されていないと、これらの工程のいずれかでトランザクションまたはデータを失いやすい。
【0055】
そのため、本明細書で説明するブロックチェーン・トランザクション・マネージャーが実装されるまで、ブロックチェーン・ネットワーク、例えばイーサリアムを使用するアプリケーションは、ブロックチェーン・ネットワーク・トランザクションの受理（「採掘」）の停止とその待機に直面していた。トランザクションは、注意を要するトランザクション採番（「ナンス」）のほか、頻発する再プログラミング単位コスト見積り（「ガス代」）によるトランザクション手数料で、ブロックされてしまう場合もある。また、アプリケーションは、すべてのブロックチェーン・ネットワーク・トランザクション・エラーも扱わなければならなかった。
【0056】
ブロックチェーン・トランザクションの課題に対するソリューション
本明細書で説明するブロックチェーン・トランザクション・マネージャーは、キューと、ブロックチェーン・ネットワークの状態に応答してトランザクションを準備し各々の属性を繰り返し調整し、トランザクション・ステータスを学習するためネットワークをポーリングするアルゴリズムとを組み合わせたものにより上記の課題に対処する。これらの能力は、並列性と、エラー後の自動再送信とを可能にする。
本明細書で説明するブロックチェーン・トランザクション・マネージャーは、キューと、ブロックチェーン・ネットワークの状態に応答してトランザクションを準備し各々の属性を繰り返し調整し、トランザクション・ステータスを学習するためネットワークをポーリングするアルゴリズムとを組み合わせたものにより上記の課題に対処する。これらの能力は、並列性と、エラー後の自動再送信とを可能にする。
【0057】
１．非同期的な並列トランザクション処理
実施形態例において、前記ブロックチェーン・トランザクション・マネージャーは、キューされたトランザクションのロバストなパイプラインを使ったのち、ネットワークをポーリングしてトランザクションの成否を追跡することにより、上記の主要な課題の２つに対処する。これにより、ユーザー・アプリケーションは、最終的な確定を待つことなくトランザクションを送信することができる。また、各工程の後続キューが当該工程の処理の成否確定までトランザクションを保留することによるトランザクションの損失も排除する。前記キュー・パイプラインは、初回送信と、gasprice、ナンス、およびgaslimitなどの属性の追加と、デジタル署名と、ネットワーク確定とを仲介する。キューは、再試行および失敗のレポーティングも管理する。
実施形態例において、前記ブロックチェーン・トランザクション・マネージャーは、キューされたトランザクションのロバストなパイプラインを使ったのち、ネットワークをポーリングしてトランザクションの成否を追跡することにより、上記の主要な課題の２つに対処する。これにより、ユーザー・アプリケーションは、最終的な確定を待つことなくトランザクションを送信することができる。また、各工程の後続キューが当該工程の処理の成否確定までトランザクションを保留することによるトランザクションの損失も排除する。前記キュー・パイプラインは、初回送信と、gasprice、ナンス、およびgaslimitなどの属性の追加と、デジタル署名と、ネットワーク確定とを仲介する。キューは、再試行および失敗のレポーティングも管理する。
【0058】
もう１つの利点として、キューは、論理的に並列な処理を各工程で可能にする。前記ブロックチェーン・トランザクション・マネージャーのサービス・コンポーネントは、そのような並列性のために設計されており、必要に応じて（例えば、利用可能なナンス値を決定する場合）共有状態用のキャッシュ支援を備えている。
【0059】
手動で扱う場合、ブロックチェーン・トランザクション、例えばイーサリアム・トランザクションは、通常、トランザクションの追跡に使用されるトランザクションの全特徴の「トランザクション・ハッシュ」に基づいて追跡される。例えば、トランザクション・ハッシュは、トランザクションが、必要な属性全とともにデジタル署名されてブロックチェーン・ネットワーク内のノードへ正常に送信された場合、そのノードにより計算されて戻される。一方、本明細書で説明するブロックチェーン・トランザクション・マネージャーは、部分的な（「生」）トランザクションをユーザー・アプリケーションから受理する。非同期的な処理にとって特定の属性は実際の送信の直前に計算されることが理想的であるため、これは望ましいことである。その結果、工程全体にわたって追跡すべきトランザクションに、付加的な識別子が必要になる場合があり、これには、そのトランザクションがブロックチェーン・ネットワーク内のノードにより拒否される可能性が含まれる。
【0060】
前記ブロックチェーン・トランザクション・マネージャーは、アプリケーション・プログラミング・インターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ：ＡＰＩ）経由、例えばＨＴＴＰリクエストを使ってデータを取得、配置、ポスト、および削除するＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ＡＰＩ経由でトランザクションが受信された場合、汎用一意識別子（ｕｎｉｖｅｒｓａｌ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ：ＵＵＩＤ－ランダム）を各トランザクションに追跡目的で割り当てる。実施形態例において、前記ブロックチェーン・トランザクション・マネージャーは、ランダムに生成されたバージョン４のＵＵＩＤｓを使用する。ほとんどの実施形態では、その後トランザクションがブロックチェーン・ネットワーク内のノードにより受理されるが、その場合もトランザクション・ハッシュは生成される。また、そのハッシュは、次いでトランザクションＩＤに関連付けられ、コールするアプリケーション用に利用可能になる。
【0061】
この非同期的なトランザクション処理は種々のプログラミング・プラットフォームを使って実施できるが、実施形態例におけるブロックチェーン・トランザクション・マネージャーのアプローチは、非同期的な処理用に強力なサポートと、ブロックチェーン・ネットワークとのインタラクトについて十分にテストされたライブラリとを備えたもの、例えばイーサリアムのブロックチェーン・プラットフォームに既存のものを１つ選択する。
【0062】
２． 自動ナンス割り当て
前記ブロックチェーン・トランザクション・マネージャーは、配慮の行き届いた着信トランザクションへのナンス自動割り当てにより、上述したナンス関連の課題を最小限に抑える。ナンスの計算は、同じアカウントからの複数のトランザクションが同時に処理される場合、特に重要になる。例えば、イーサリアム・ネットワークがトランザクションをブロードキャストするのは、そのナンスが整数値で、ネットワークに通信された直前のトランザクションのナンスより１だけ大きい場合に限られる。同じナンスが複数のトランザクションに割り当てられた場合、イーサリアム・ブロックチェーン・ネットワークは、どれでも最初に受信したものを受理し、残りを拒否する。
前記ブロックチェーン・トランザクション・マネージャーは、配慮の行き届いた着信トランザクションへのナンス自動割り当てにより、上述したナンス関連の課題を最小限に抑える。ナンスの計算は、同じアカウントからの複数のトランザクションが同時に処理される場合、特に重要になる。例えば、イーサリアム・ネットワークがトランザクションをブロードキャストするのは、そのナンスが整数値で、ネットワークに通信された直前のトランザクションのナンスより１だけ大きい場合に限られる。同じナンスが複数のトランザクションに割り当てられた場合、イーサリアム・ブロックチェーン・ネットワークは、どれでも最初に受信したものを受理し、残りを拒否する。
【0063】
ブロックチェーン・トランザクション・マネージャーの実施形態例におけるナンス割り当てアルゴリズムは、以下の工程を実施することにより、これらの状況を防ぐ。
【0064】
１）同じアカウントおよびネットワーク用の複数のトランザクションが、前記ブロックチェーン・トランザクション・マネージャーにより並列処理されている場合は、ロック機構を使い、それらトランザクションのうち、一度に１つしかナンスを計算しないようにする。
【0065】
２）なお、複数の再試行後にトランザクションが失敗したら、それに割り当てられたナンスは必ずそのトランザクションに関連付けられたアカウント用の再使用可能なナンスのプールに追加される（後述）。このプールが処理中のトランザクションのアカウントに関するナンスを含まないか確認する。もしそうであれば、最低値のものを選択し、それを前記プールから除去して前記処理中のトランザクションに割り当てる。そうでない場合は、工程３へ進む。
【0066】
３）所与の送信者のアカウント用のナンスをブロックチェーン・ネットワークから取得する：Nweb3
４）前記ブロックチェーン・トランザクション・マネージャーにより所与のアカウントに前回割り当てられたナンスを取得する：Nred
５）工程４のナンスから工程３のナンスを差し引く：Nred - Nweb3 。その差がナンス・ウィンドウより大きい場合（上記のノード属性定義を参照）、工程３のナンスを選ぶ。すなわち、Nred - Nweb3 ＞ ナンス・ウィンドウの場合、N = Nweb3 。
４）前記ブロックチェーン・トランザクション・マネージャーにより所与のアカウントに前回割り当てられたナンスを取得する：Nred
５）工程４のナンスから工程３のナンスを差し引く：Nred - Nweb3 。その差がナンス・ウィンドウより大きい場合（上記のノード属性定義を参照）、工程３のナンスを選ぶ。すなわち、Nred - Nweb3 ＞ ナンス・ウィンドウの場合、N = Nweb3 。
【0067】
６）それ以外の場合は、工程３と工程４のナンスを比較し、値の大きいほうを選択する。すなわち、Nred ＞ Nweb3の場合、N=Nred 。それ以外の場合は、N=Nweb3 。
【0068】
７）当該トランザクションのデジタル署名の直前に、工程２と同様な確認を繰り返して、確実に利用可能な最小ナンスが使用されるようにする。工程１～６で割り当てられたナンスより低い値を前記プールが含む場合、前記割り当てられたナンスを前記プール内のナンスと交換し、前記プールのナンスのほうを前記トランザクションに使用する。
【0069】
３．自動実行コスト推定
トランザクション手数料を小さく若しくは大きく見積もりすぎることによる上記の難題を回避するため、前記ブロックチェーン・トランザクション・マネージャーでは、トランザクションごとに個別にコスト属性を推定する。
トランザクション手数料を小さく若しくは大きく見積もりすぎることによる上記の難題を回避するため、前記ブロックチェーン・トランザクション・マネージャーでは、トランザクションごとに個別にコスト属性を推定する。
【0070】
gaspriceは、最近ネットワークで受理されたトランザクションに関連付けられたガス価格に基づいて計算される。一実施形態例では、広く使用されているweb3ライブラリの、過去数ブロックのガス価格の中央値に基づく計算を使用できる。
【0071】
一実施形態例のトランザクションに許容される最大のガス代（smartgas）の計算は、以下の工程を含む。
【0072】
１）前回採掘されたブロックのブロック・ガスリミットをブロックチェーン・ネットワークから取得する：Gmb
２）トランザクションに要求される実際のガス代の推定値を取得する。（web3ライブラリは、渡されたデータ、および／またはスマート・コントラクト・コールのシミュレーション実行に基づいて、この推定を行う）：Gdb
３）Gdb ≧ Gmbの場合、G = Gmb* CF0、ここで、CF0は設定可能な係数。
２）トランザクションに要求される実際のガス代の推定値を取得する。（web3ライブラリは、渡されたデータ、および／またはスマート・コントラクト・コールのシミュレーション実行に基づいて、この推定を行う）：Gdb
３）Gdb ≧ Gmbの場合、G = Gmb* CF0、ここで、CF0は設定可能な係数。
【0073】
４）Gmb ＞ Gdb の場合、Gの計算は、Gmb がどれだけGdb より大きいかに依存する。比R = Gmb/Gdb を計算したのち、Gを以下のように見出だす。
【0074】
（R ≧ 0 AND R≦ CR1、ここでCR1 は、CR1＞0の設定可能な比）である場合、G = Gdb * CF1、ここで、CF1 は設定可能な係数。
【0075】
（R ＞ CR1 AND R≦ CR2、ここでCR2 は、CR2＞CR1の設定可能な比）である場合、G = Gdb * CF2、ここで、CF2 は設定可能な係数。
【0076】
（R ＞ CR2）の場合、G = Gdb * CF3、ここで、CF3は設定可能な係数。
【0077】
５）トランザクションが、任意メッセージ・データを伴わないイーサ通貨送信である（すなわち、トランザクション属性に「value」（値）属性は存在するが、「data」（データ）は不在または空である）場合、startgasは設定可能なイーサ額、Gvalueである。
【0078】
６）トランザクションが、任意メッセージ・データを伴うイーサ通貨送信である（すなわち、「data」（データ）も「value」（値）も存在する）場合、startgasは上記の工程４で算出されたガス代と、工程５の設定可能な値、Gvalueとの和である。すなわち、startgas = Gvalue + G 。
【0079】
一度計算されると、これらの属性が生トランザクションに追加され、次いでデジタル署名および指定されたブロックチェーン・ネットワークへの送信へと進む。
【0080】
４．トランザクションの準備および送信の再試行
前記ブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク内のノードにトランザクションを送る工程を、２段階に分ける。その１つ目はトランザクションの準備で、これには、ナンスおよびコスト属性の追加が含まれる。２つ目は送信で、これには、前記トランザクションへのデジタル署名と、ブロックチェーン・ネットワーク内のノードへの引き渡しが含まれる。これらの工程のどちらかを行っているときに問題が生じた場合、前記ブロックチェーン・トランザクション・マネージャーの最初の対処戦略は、単なる再試行アプローチである。システムは、各工程に設定可能な回数に達するまで、単にトランザクションの準備または送信を再試行する。
前記ブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク内のノードにトランザクションを送る工程を、２段階に分ける。その１つ目はトランザクションの準備で、これには、ナンスおよびコスト属性の追加が含まれる。２つ目は送信で、これには、前記トランザクションへのデジタル署名と、ブロックチェーン・ネットワーク内のノードへの引き渡しが含まれる。これらの工程のどちらかを行っているときに問題が生じた場合、前記ブロックチェーン・トランザクション・マネージャーの最初の対処戦略は、単なる再試行アプローチである。システムは、各工程に設定可能な回数に達するまで、単にトランザクションの準備または送信を再試行する。
【0081】
どちらかの段階で最大再試行数を超えると、そのトランザクションはエラー・キューに入れられる。意図的な遅延後、そのトランザクションは、再度の準備および送信用に戻される。ブロックチェーン・ネットワーク内のノードによる拒否により成功しなかったものは、後述するようにカスタマイズされた付加的なハンドリングを受ける。
【0082】
５．拒否されたトランザクションの扱い
ブロックチェーン・ネットワーク内のノードに繰り返し拒否されたトランザクションの扱いは、第１に、トランザクションのナンスが使用されていないことによる将来的な問題を回避することと、第２に、可能であれば拒否の原因に対処することを伴う。このセクションでは、これらの処理に関する前記ブロックチェーン・トランザクション・マネージャーのアプローチについて説明する。
ブロックチェーン・ネットワーク内のノードに繰り返し拒否されたトランザクションの扱いは、第１に、トランザクションのナンスが使用されていないことによる将来的な問題を回避することと、第２に、可能であれば拒否の原因に対処することを伴う。このセクションでは、これらの処理に関する前記ブロックチェーン・トランザクション・マネージャーのアプローチについて説明する。
【0083】
自動ナンス再割り当て
ブロックチェーン・ネットワーク内のノードによりトランザクションが拒否されると、それに割り当てられたナンスは、送信者のブロックチェーン・アイデンティティ用に前記ノードが受け取ったナンスのリスト内のシーケンスには現れない。そのため、前記ノードが、その後、後続ナンスを伴う後続トランザクションだけを順次受信しても、このトランザクションのナンス数値を飛ばすことになってしまい、上述したナンス・ギャップが生じる。この問題を回避するため、拒否されたトランザクションのナンスは、ただちに前記ブロックチェーン・トランザクション・マネージャーのインメモリ・キャッシュリストに書き込まれる。そのような最低数値のナンスは、次いで上述のように、前記送信者のために準備される次のトランザクションに使用される。これにより、ナンス採番のいかなるギャップも早急に埋められる。
ブロックチェーン・ネットワーク内のノードによりトランザクションが拒否されると、それに割り当てられたナンスは、送信者のブロックチェーン・アイデンティティ用に前記ノードが受け取ったナンスのリスト内のシーケンスには現れない。そのため、前記ノードが、その後、後続ナンスを伴う後続トランザクションだけを順次受信しても、このトランザクションのナンス数値を飛ばすことになってしまい、上述したナンス・ギャップが生じる。この問題を回避するため、拒否されたトランザクションのナンスは、ただちに前記ブロックチェーン・トランザクション・マネージャーのインメモリ・キャッシュリストに書き込まれる。そのような最低数値のナンスは、次いで上述のように、前記送信者のために準備される次のトランザクションに使用される。これにより、ナンス採番のいかなるギャップも早急に埋められる。
【0084】
トランザクションが拒否された原因が対処された場合も、そのトランザクションが最初に割り当てられたナンスとともに再び送信されることはない。その代わり、再送信用にデジタル署名が再び行われる前に、自動ナンス割り当てが再度行われる。この工程は、後述する理由によるものを含め、再試行を繰り返した後にトランザクションが失敗したすべての場合に行われる。
【0085】
自動startgas再計算
ブロックチェーン・ネットワーク内のノードに送信されたときにgas low（ガス代が少ない）またはgas exceeded（ガス代が高すぎる）ためのエラーで拒否されるトランザクションでは、スケジュールされた遅延後に再び準備および送信されるときstartgasを調整することで、拒否に対処される。調整で増減される額は、当該システム用に設定可能なパーセンテージ係数に基づき、例えば、ガス代が少ない場合は２０％増、ガス代が高すぎる場合は１０％増である。
ブロックチェーン・ネットワーク内のノードに送信されたときにgas low（ガス代が少ない）またはgas exceeded（ガス代が高すぎる）ためのエラーで拒否されるトランザクションでは、スケジュールされた遅延後に再び準備および送信されるときstartgasを調整することで、拒否に対処される。調整で増減される額は、当該システム用に設定可能なパーセンテージ係数に基づき、例えば、ガス代が少ない場合は２０％増、ガス代が高すぎる場合は１０％増である。
【0086】
遅延とレポーティングにより対処される拒否
「RPC not responding」（ＲＰＣの応答なし）または「insufficient funds」（残高不足）で拒否されるトランザクションの場合、前記ブロックチェーン・トランザクション・マネージャーは、根本的な原因は時とともに対処されると想定する。トランザクションは、エラー・キューへの書き込み以外、何のアクションも講じられないため、待ち時間後に再び準備および送信される。ただし、前記理由はトランザクションのステータスとともにデータベースに書き込まれ、これによりユーザーのアプリケーションによる監視が可能になる。
「RPC not responding」（ＲＰＣの応答なし）または「insufficient funds」（残高不足）で拒否されるトランザクションの場合、前記ブロックチェーン・トランザクション・マネージャーは、根本的な原因は時とともに対処されると想定する。トランザクションは、エラー・キューへの書き込み以外、何のアクションも講じられないため、待ち時間後に再び準備および送信される。ただし、前記理由はトランザクションのステータスとともにデータベースに書き込まれ、これによりユーザーのアプリケーションによる監視が可能になる。
【0087】
ナンス変更による「既知のトランザクション」拒否の扱い
上述のように、「known transaction」（既知のトランザクション）による拒否は、トランザクションがすでに送信されたものと同一のときに起こる。前記ブロックチェーン・トランザクション・マネージャーの実施形態例では、この原因を、偶然同一である２つのトランザクションに、同じナンスが割り当てられたものと想定する。（前記ブロックチェーン・トランザクション・マネージャーが所与の送信者に関する全トランザクションを扱っている場合、この状況は、非常にまれなはずであるが、より複雑な状況では生じる可能性がある。）これに対する解決策は、前記トランザクションから重複したナンスを除去し、適切なものを新たに割り当てることである。いずれにしても、これが起こるのは、トランザクションがエラー・キューに送信されたのち、再度準備され、再送信される場合であるため、すべての拒否に提供されるハンドリングを超える付加的なハンドリングは不要である。
上述のように、「known transaction」（既知のトランザクション）による拒否は、トランザクションがすでに送信されたものと同一のときに起こる。前記ブロックチェーン・トランザクション・マネージャーの実施形態例では、この原因を、偶然同一である２つのトランザクションに、同じナンスが割り当てられたものと想定する。（前記ブロックチェーン・トランザクション・マネージャーが所与の送信者に関する全トランザクションを扱っている場合、この状況は、非常にまれなはずであるが、より複雑な状況では生じる可能性がある。）これに対する解決策は、前記トランザクションから重複したナンスを除去し、適切なものを新たに割り当てることである。いずれにしても、これが起こるのは、トランザクションがエラー・キューに送信されたのち、再度準備され、再送信される場合であるため、すべての拒否に提供されるハンドリングを超える付加的なハンドリングは不要である。
【0088】
６．トランザクション・ステータスのポーリング
ユーザー・アプリケーションがトランザクションを非同期的に送信できるようにした場合、完全に自動化したトランザクション・マネージャの２つ目の重要な要件は、前記トランザクションがブロックチェーン・ネットワークにより実行されたことと、その実行が成功したか失敗したかを確認することである（そのトランザクション自体の趣旨の観点から）。一般に、この追跡で観察されるのは、２つの状況のうち１つであり、その１つは、一般的なトランザクションが比較的短く予測可能な時間内に採掘される状況（例えば、数秒、主な公共イーサリアム・ネットワークの場合、現在１、２分、または他のプラットフォームの場合は可能性としてより長時間）、もう１つは、ネットワークまたはトランザクション自体の問題で採掘が著しく遅れる状況である。これを予測し、前記ブロックチェーン・トランザクション・マネージャーは、２つの別個のステータス・ポーリング・アプローチを実装している。その１つ目は、より集中的なものである。ノードへの送信後、トランザクションの記録は、はじめのうち、最近送信された他のトランザクションの記録とともにキューに保持される。その各々は順番に取得され、ブロックチェーン・ネットワーク内のノードは、前記トランザクションが採掘済みか確認するためのクエリーを実行する。そうである場合は、前記採掘の結果に基づいて適切なアクションが講じられる。そうでない場合、前記トランザクションは、設定可能な再試行の上限に達するまで、集中的なポーリング（例えば、１分に２回）を繰り返すため再試行キューに入る。その時点で、前記トランザクションは、ジョブ・スケジューラに基づき、第２のポーリング・アプローチへと送られる。前記スケジューラは、集中的なポーリングが再び試行される前に、時間遅延を導入する。２フェーズのスケジュールがサポートされており、例えばスケジューリングの再ポーリングを５分間ごとに５回まで行い、その後はポーリングにより前記トランザクションが採掘されたことが示されるまで１時間に１回無期限に行う。これにより、ネットワーク資源の使用と、トランザクション・ステータスのタイムリーなレポーティングとの間のバランスをとることができる。
ユーザー・アプリケーションがトランザクションを非同期的に送信できるようにした場合、完全に自動化したトランザクション・マネージャの２つ目の重要な要件は、前記トランザクションがブロックチェーン・ネットワークにより実行されたことと、その実行が成功したか失敗したかを確認することである（そのトランザクション自体の趣旨の観点から）。一般に、この追跡で観察されるのは、２つの状況のうち１つであり、その１つは、一般的なトランザクションが比較的短く予測可能な時間内に採掘される状況（例えば、数秒、主な公共イーサリアム・ネットワークの場合、現在１、２分、または他のプラットフォームの場合は可能性としてより長時間）、もう１つは、ネットワークまたはトランザクション自体の問題で採掘が著しく遅れる状況である。これを予測し、前記ブロックチェーン・トランザクション・マネージャーは、２つの別個のステータス・ポーリング・アプローチを実装している。その１つ目は、より集中的なものである。ノードへの送信後、トランザクションの記録は、はじめのうち、最近送信された他のトランザクションの記録とともにキューに保持される。その各々は順番に取得され、ブロックチェーン・ネットワーク内のノードは、前記トランザクションが採掘済みか確認するためのクエリーを実行する。そうである場合は、前記採掘の結果に基づいて適切なアクションが講じられる。そうでない場合、前記トランザクションは、設定可能な再試行の上限に達するまで、集中的なポーリング（例えば、１分に２回）を繰り返すため再試行キューに入る。その時点で、前記トランザクションは、ジョブ・スケジューラに基づき、第２のポーリング・アプローチへと送られる。前記スケジューラは、集中的なポーリングが再び試行される前に、時間遅延を導入する。２フェーズのスケジュールがサポートされており、例えばスケジューリングの再ポーリングを５分間ごとに５回まで行い、その後はポーリングにより前記トランザクションが採掘されたことが示されるまで１時間に１回無期限に行う。これにより、ネットワーク資源の使用と、トランザクション・ステータスのタイムリーなレポーティングとの間のバランスをとることができる。
【0089】
７．データベース障害の扱い
データベース可用性の中断は、上記で言及された潜在的なシステム障害源の１つである。前記ブロックチェーン・トランザクション・マネージャーは、トランザクション・ライフサイクルのどこで中断が起こるかに応じて、この可能性を異なる態様で扱う。ほとんどの場合、この扱いは、それに後続するデータベースのアクティビティ、例えばエラー・テーブルへのトランザクションの書き込みを伴う。それらの書き込みが、広範囲のデータベース非可用性により不可能な場合、情報は、異なる場所（本実施形態例ではテキストファイル）に一時的に書き込まれ、その後エラー・ハンドリング・ルーチンがデータベースにてステータス更新を行うことができる。
データベース可用性の中断は、上記で言及された潜在的なシステム障害源の１つである。前記ブロックチェーン・トランザクション・マネージャーは、トランザクション・ライフサイクルのどこで中断が起こるかに応じて、この可能性を異なる態様で扱う。ほとんどの場合、この扱いは、それに後続するデータベースのアクティビティ、例えばエラー・テーブルへのトランザクションの書き込みを伴う。それらの書き込みが、広範囲のデータベース非可用性により不可能な場合、情報は、異なる場所（本実施形態例ではテキストファイル）に一時的に書き込まれ、その後エラー・ハンドリング・ルーチンがデータベースにてステータス更新を行うことができる。
【0090】
ＡＰＩレイヤーにおけるデータベース障害
ユーザー・アプリケーションにより生トランザクションが送信されたときにデータベースが応答しない場合、前記ブロックチェーン・トランザクション・マネージャーは、単にトランザクションの受理を拒否し、エラーのリターンコードをＲＥＳＴ ＡＰＩに提供する。
ユーザー・アプリケーションにより生トランザクションが送信されたときにデータベースが応答しない場合、前記ブロックチェーン・トランザクション・マネージャーは、単にトランザクションの受理を拒否し、エラーのリターンコードをＲＥＳＴ ＡＰＩに提供する。
【0091】
トランザクション準備中のデータベースまたはキャッシュ障害
トランザクションの準備および署名には、データベースからのブロックチェーン・ネットワーク情報の読み出しと、セキュアなストレージからのアイデンティティ・クレデンシャル取得が伴う。これら処理のいずれにおけるエラーも、設定可能な最大試行数まで、アクティビティの再試行を起こす。（キャッシュの読み出しは例外である。キャッシュを読み出せない場合は、代わりにセキュアなストレージが読み出される。）設定可能な最大反復数を越えてエラーが続くと、それに続く扱いは各問題に依存する。ネットワーク情報のルックアップ中にエラーが起こると、そのトランザクションはエラー・テーブルに書き込まれ、スケジュールされた遅延後に再試行される。他の全エラーについては、トランザクションがエラー・テーブルに書き込まれるものの、自動的には再試行されない。前記トランザクションは、後述するように、管理者からＥＴＭコンソールを介して手動で再試行できる。
トランザクションの準備および署名には、データベースからのブロックチェーン・ネットワーク情報の読み出しと、セキュアなストレージからのアイデンティティ・クレデンシャル取得が伴う。これら処理のいずれにおけるエラーも、設定可能な最大試行数まで、アクティビティの再試行を起こす。（キャッシュの読み出しは例外である。キャッシュを読み出せない場合は、代わりにセキュアなストレージが読み出される。）設定可能な最大反復数を越えてエラーが続くと、それに続く扱いは各問題に依存する。ネットワーク情報のルックアップ中にエラーが起こると、そのトランザクションはエラー・テーブルに書き込まれ、スケジュールされた遅延後に再試行される。他の全エラーについては、トランザクションがエラー・テーブルに書き込まれるものの、自動的には再試行されない。前記トランザクションは、後述するように、管理者からＥＴＭコンソールを介して手動で再試行できる。
【0092】
ブロックチェーン・ノードへの送信後のデータベース障害
ブロックチェーン・ネットワーク内の近傍ノードがトランザクションを受理すると、前記ブロックチェーン・トランザクション・マネージャーは、その詳細を、その送信時のステータスとともにデータベースに記録する。何らかの理由でそれができない場合、そのトランザクションは、問題が生じた旨とともにエラー・テーブルに書き込まれる。その後は、ＥＴＭコンソールを介して手動で再試行できる。
ブロックチェーン・ネットワーク内の近傍ノードがトランザクションを受理すると、前記ブロックチェーン・トランザクション・マネージャーは、その詳細を、その送信時のステータスとともにデータベースに記録する。何らかの理由でそれができない場合、そのトランザクションは、問題が生じた旨とともにエラー・テーブルに書き込まれる。その後は、ＥＴＭコンソールを介して手動で再試行できる。
【0093】
ポーリング後のデータベース障害
データベース更新は、ポーリングの各ラウンド後に行われる―これは、トランザクションが採掘された旨を示す受信が得られたことを反映させるため、または最大再試行数を超過し、そのポーリングの再試行は遅延後に行うべきであることを記録するためのいずれかである。前記一実施形態例では、前記データベースが利用できない場合、これらの書き込みは、データベースが再び利用可能になるまでの保留措置としてローカル・テキストファイルに行われ、データベースが再び利用可能になった時点で、当初の意図どおりに情報が前記データベースに書き込まれる。
データベース更新は、ポーリングの各ラウンド後に行われる―これは、トランザクションが採掘された旨を示す受信が得られたことを反映させるため、または最大再試行数を超過し、そのポーリングの再試行は遅延後に行うべきであることを記録するためのいずれかである。前記一実施形態例では、前記データベースが利用できない場合、これらの書き込みは、データベースが再び利用可能になるまでの保留措置としてローカル・テキストファイルに行われ、データベースが再び利用可能になった時点で、当初の意図どおりに情報が前記データベースに書き込まれる。
【0094】
エラーが起こったトランザクションのスケジューリング中におけるデータベース障害
一実施形態例では、キューの代わりにデータベースを使って、エラー・ハンドリングを必要とするトランザクションを保持する。それらのトランザクションの定期的な検索中に生じるデータベース問題は、すべてログされる。前記トランザクションを検索するための定期的試行は継続的に行われるため、一時的な問題は、システム管理者が手動でログされた問題に対処したのち自己修復される。
一実施形態例では、キューの代わりにデータベースを使って、エラー・ハンドリングを必要とするトランザクションを保持する。それらのトランザクションの定期的な検索中に生じるデータベース問題は、すべてログされる。前記トランザクションを検索するための定期的試行は継続的に行われるため、一時的な問題は、システム管理者が手動でログされた問題に対処したのち自己修復される。
【0095】
８．トランザクションのバルク処理
トランザクションを非同期的に処理および監視する能力を考慮すると、クライアント・アプリケーションがトランザクションをバルク送信する能力は、適切な利便性であり、前記ブロックチェーン・トランザクション・マネージャーでサポートされている。
トランザクションを非同期的に処理および監視する能力を考慮すると、クライアント・アプリケーションがトランザクションをバルク送信する能力は、適切な利便性であり、前記ブロックチェーン・トランザクション・マネージャーでサポートされている。
【0096】
そのため、本明細書で説明するブロックチェーン・トランザクション・マネージャーでは、トランザクションが準備されるとき、ブロックチェーン・ネットワーク内の近傍ノードとの接続が受理可能になると、ブロックチェーン・ネットワークの送信用トランザクションをキューに入れることにより、従来のブロックチェーン・ネットワークの課題に対処する。ナンスは、自動的に割り当てられてブロッキングを防ぎ、前記ブロックチェーン・ネットワーク・トランザクション・ステータスは定期的にポーリングおよび取得される。また、ガス代は、最新の状態に基づいて自動的に割り当てられる。ブロックチェーン・ネットワーク・エラーの多くは、自動的に扱われ、自動的に扱えないエラーについてはレポーティングが提供される。
【0097】
実施形態例
【0098】
概要
前記ブロックチェーン・トランザクション・マネージャーの機能は、各トランザクションのライフサイクルの種々の段階でブロックチェーン・トランザクションにアクションをとることができる一連のサービス・コンポーネントの組み合わせによって達成され、これには、障害および拒否状況への対処が含まれる。また、これらのコンポーネントは、ブロックチェーン・ネットワーク（例えば、イーサリアム）とインタラクトして、トランザクションを送信し、その各々のステータスを追跡する。一連の永続的メッセージ・キューは、それらのサービス・コンポーネントによりトランザクションの保留アクションまたは確定を保持し、インメモリおよび永続的データベースは、前記サービス・コンポーネントの作業に必要とされる、関連性の高いブロックチェーン・アイデンティティの情報とそのトランザクションを保持する。システムは、主にブロックチェーン・トランザクションを生成または追跡する必要があるアプリケーションの要求に応えることを目的としている。この目的のため、プログラミング言語に依存せずサービス・コンポーネントにアクセス可能なＲＥＳＴ ＡＰＩが提供される。また、ＡＰＩは、ブロックチェーン・トランザクション・マネージャー機能のサブセットへの人間ユーザーによる直接的なアクセスを提供するウェブ・サーバーで若しくはローカル・マシンのサービスとしてデプロイされるブラウザベースのフロントエンド「コンソール」ウェブ・アプリケーションに、サービスを提供する。
前記ブロックチェーン・トランザクション・マネージャーの機能は、各トランザクションのライフサイクルの種々の段階でブロックチェーン・トランザクションにアクションをとることができる一連のサービス・コンポーネントの組み合わせによって達成され、これには、障害および拒否状況への対処が含まれる。また、これらのコンポーネントは、ブロックチェーン・ネットワーク（例えば、イーサリアム）とインタラクトして、トランザクションを送信し、その各々のステータスを追跡する。一連の永続的メッセージ・キューは、それらのサービス・コンポーネントによりトランザクションの保留アクションまたは確定を保持し、インメモリおよび永続的データベースは、前記サービス・コンポーネントの作業に必要とされる、関連性の高いブロックチェーン・アイデンティティの情報とそのトランザクションを保持する。システムは、主にブロックチェーン・トランザクションを生成または追跡する必要があるアプリケーションの要求に応えることを目的としている。この目的のため、プログラミング言語に依存せずサービス・コンポーネントにアクセス可能なＲＥＳＴ ＡＰＩが提供される。また、ＡＰＩは、ブロックチェーン・トランザクション・マネージャー機能のサブセットへの人間ユーザーによる直接的なアクセスを提供するウェブ・サーバーで若しくはローカル・マシンのサービスとしてデプロイされるブラウザベースのフロントエンド「コンソール」ウェブ・アプリケーションに、サービスを提供する。
【0099】
図１は、ブロックチェーン・トランザクション・マネージャー１００が一実施形態例でデプロイされた場合に、これを使用する文脈のブロック図を例示したものである。例示した実施形態例において、このブロックチェーン・トランザクション・マネージャー１００は、イーサリアム・トランザクション・マネージャー（Ｅｔｈｅｒｅｕｍ Ｔｒａｎｓａｃｔｉｏｎ Ｍａｎａｇｅｒ：ＥＴＭ（商標））として構成され、近傍ブロックチェーン・ノード１１０および複数のブロックチェーン・ノード１５５を含むイーサリアム・ブロックチェーン・ネットワークにインターフェース接続する。上記のように、他種のブロックチェーン・ネットワークと併用した場合、前記ブロックチェーン・トランザクション・マネージャー１００は、前記他種のブロックチェーン・ネットワークの各前記ノードにインターフェース接続する。図示したように、当該ブロックチェーン・トランザクション・マネージャー１００は、以下さらに詳しく説明するように、デプロイされたＥＴＭ（商標）コンソール１２０と、デプロイされたＥＴＭ（商標）アプリケーションおよびサービス１３０とを含む。当該ブロックチェーン・トランザクション・マネージャー１００は、ユーザーのブラウザ１４０および／またはユーザーのコンピュータ上のブロックチェーン・トランザクション生成アプリケーション１５０により生成されるブロックチェーン・トランザクション用のノード１１０および１５５を含むイーサリアム・ブロックチェーン・ネットワークに対し、ＲＥＳＴ ＡＰＩ駆動のインターフェースとして機能する。
【0100】
キューおよびサービス・コンポーネント
上述のように、前記ブロックチェーン・トランザクション・マネージャー１００の機能の大部分は、メッセージング・キュー経由でサービス・コンポーネントへ向かうトランザクションのライフサイクルに基づいており、前記サービス・コンポーネントは、ローカルであっても、選択されたイーサリアム・ネットワークにおいても、アクションを講じることができる。ハイレベルにおけるコンポーネント、キュー、各々の目的、およびトランザクション・フローを、以下の表１に記載する。
上述のように、前記ブロックチェーン・トランザクション・マネージャー１００の機能の大部分は、メッセージング・キュー経由でサービス・コンポーネントへ向かうトランザクションのライフサイクルに基づいており、前記サービス・コンポーネントは、ローカルであっても、選択されたイーサリアム・ネットワークにおいても、アクションを講じることができる。ハイレベルにおけるコンポーネント、キュー、各々の目的、およびトランザクション・フローを、以下の表１に記載する。
【表1】
【0101】
表２で説明するキューは、これらのコンポーネントに、扱うべきトランザクションを供給する。キューの使用は、前記ブロックチェーン・トランザクション・マネージャー１００がトランザクションを並列処理する能力に貢献し、別個のコンポーネントおよびインフラストラクチャを、トランザクション・ライフサイクルの異なる段階で使用できるようにする。
【表2】
【0102】
図２は、前記ブロックチェーン・トランザクション・マネージャー１００の前記サービス・コンポーネント（表１）およびキュー（表２）を通じたトランザクションの全体的な動きを、メッセージ・キューの観点から例示したものである。これらの動きに関わるアクティビティのほか、各フローに伴うデータ形態の詳細は、前記ブロックチェーン・トランザクション・マネージャー１００の処理に関して以下でさらに詳しく説明していく。なお、トランザクションは、キューではなくデータベースを介してETM_Schedulingへ流れるため、図２では、このサービス・コンポーネントに向かう着信トランザクションの流れが示されていないことに注意すべきである。
【0103】
持続性とキャッシング
上記で概略説明したトランザクションのライフサイクルは、種々のポイントにおけるサデータベースによりポートされる。それらのデータベースには、以下のものが含まれる。
上記で概略説明したトランザクションのライフサイクルは、種々のポイントにおけるサデータベースによりポートされる。それらのデータベースには、以下のものが含まれる。
【0104】
永続的リレーショナル・ストレージ
用途：ユーザーから受信され、システムにより合成され、またはイーサリアム・ネットワークからポーリングされるトランザクション関連の情報は、すべて永続的リレーショナル・ストレージに保管される。これは、前記ブロックチェーン・トランザクション・マネージャー（イーサリアム・ブロックチェーン・ネットワークの場合、イーサリアム・トランザクション・マネージャー（ＥＴＭ（商標））１００）トランザクション・ライフサイクルにおける各トランザクションのステータスを含む。プライベート・ブロックチェーン・キーは、このストレージから除外される。
用途：ユーザーから受信され、システムにより合成され、またはイーサリアム・ネットワークからポーリングされるトランザクション関連の情報は、すべて永続的リレーショナル・ストレージに保管される。これは、前記ブロックチェーン・トランザクション・マネージャー（イーサリアム・ブロックチェーン・ネットワークの場合、イーサリアム・トランザクション・マネージャー（ＥＴＭ（商標））１００）トランザクション・ライフサイクルにおける各トランザクションのステータスを含む。プライベート・ブロックチェーン・キーは、このストレージから除外される。
【0105】
キーのためのセキュリティ強化ストレージ
目的：ブロックチェーン・トランザクション・マネージャーを使用するアプリケーションは、送信するトランザクションに関連付けられることになるイーサリアム・アイデンティティごとに、パブリック－プライベート・キーのペアをシステムに提供する。これは、前記ブロックチェーン・トランザクション・マネージャー１００がトランザクション属性を追加または修正した後で、そのトランザクションにデジタル署名できるようにするうえで望ましいことである。それらのキーのストレージには、付加的なセキュリティと単離が必要である。ＥＴＭ（商標）などのトランザクション・マネージャーの実施者は、望ましいレベルのセキュリティに基づいて、任意の暗号化されたオブジェクト・ストアを使用でき、または前記ブロックチェーン・トランザクション・マネージャーがハードウェアまたはソフトウェアベースの専用セキュア・キー・ストレージを使用するようにできる。
目的：ブロックチェーン・トランザクション・マネージャーを使用するアプリケーションは、送信するトランザクションに関連付けられることになるイーサリアム・アイデンティティごとに、パブリック－プライベート・キーのペアをシステムに提供する。これは、前記ブロックチェーン・トランザクション・マネージャー１００がトランザクション属性を追加または修正した後で、そのトランザクションにデジタル署名できるようにするうえで望ましいことである。それらのキーのストレージには、付加的なセキュリティと単離が必要である。ＥＴＭ（商標）などのトランザクション・マネージャーの実施者は、望ましいレベルのセキュリティに基づいて、任意の暗号化されたオブジェクト・ストアを使用でき、または前記ブロックチェーン・トランザクション・マネージャーがハードウェアまたはソフトウェアベースの専用セキュア・キー・ストレージを使用するようにできる。
【0106】
インメモリ・キャッシング
目的：ブロックチェーン・ネットワーク接続情報、送信者のアイデンティティ、および各アイデンティティのナンス割り当てを含む読み出されたデータ要素を、繰り返しキャッシングすることにより性能を向上させる。
目的：ブロックチェーン・ネットワーク接続情報、送信者のアイデンティティ、および各アイデンティティのナンス割り当てを含む読み出されたデータ要素を、繰り返しキャッシングすることにより性能を向上させる。
【0107】
ユーザーおよびアプリケーションのアクセス管理
セキュリティは、キー管理およびトランザクション署名を除き、トランザクション管理とは関連性の低い懸念事項である。各ユースケースのセキュリティ・ニーズを考慮し、通常の最適実施例が適用される。以下、実施形態例で使用されるアプローチを概説する。
セキュリティは、キー管理およびトランザクション署名を除き、トランザクション管理とは関連性の低い懸念事項である。各ユースケースのセキュリティ・ニーズを考慮し、通常の最適実施例が適用される。以下、実施形態例で使用されるアプローチを概説する。
【0108】
アクセス管理には、２つの別個のアプローチが使われる。第１に、ＲＥＳＴ ＡＰＩ経由でユーザー・アプリケーションが直接利用できる機能は、アイデンティティ管理システムを使って認証される。前記ブロックチェーン・トランザクション・マネージャー１００自体が認識するためのアイデンティティとそれに伴うクレデンシャルは、アイデンティティ・システムで作成される。前記クレデンシャルは、前記ブロックチェーン・トランザクション・マネージャー外の工程でこのＡＰＩを使用する権限がある任意のユーザー・アプリケーションと共有され、各ＡＰＩコールにより前記ブロックチェーン・トランザクション・マネージャー１００に供給されて戻される。第２に、前記ＥＴＭコンソール１２０によりアクセスされる機能は、別個のジェイソン・ウェブ・トークン（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ：ＪＷＴ）ベースの認証方法を使用する。これにより、デプロイメント中に設定される、前記ＥＴＭコンソールの唯一の管理者アイデンティティにより、追加利用者を作成できるようになる。どちらの方法でもアクセス可能な機能、例えばトランザクション・ステータスの取得は、どちらの方法でも認証でき、これを可能にするため、２つの別個のＡＰＩエンドポイントによりサービスが提供される。
【0109】
ＥＴＭコンソール
表３は、前記ＥＴＭコンソール１２０から利用できる機能を示したものである。トランザクションとそのステータスを読み出す場合を除き、これらの機能は、ＲＥＳＴ ＡＰＩを介して接続しているユーザー・アプリケーションからは利用できない。
表３は、前記ＥＴＭコンソール１２０から利用できる機能を示したものである。トランザクションとそのステータスを読み出す場合を除き、これらの機能は、ＲＥＳＴ ＡＰＩを介して接続しているユーザー・アプリケーションからは利用できない。
【表3】
【0110】
ブロックチェーン・トランザクション・マネージャーの構成
以下では、前記システムの構成に関して、デプロイメント前に存在する設計と構成に焦点を置いた詳細（すなわち、静的アーキテクチャ、事前定義されたデータ・スキーマ、およびスタートアップ前の構成）を、図３～図９を参照して説明する。なお、ストレージおよびキューイングについて言及した技術はプレースホルダーであることに注意すべきである。当業者であれば、性能に関する他の考慮事項に基づき、各々に代替技術を選択できることが理解されるであろう。
以下では、前記システムの構成に関して、デプロイメント前に存在する設計と構成に焦点を置いた詳細（すなわち、静的アーキテクチャ、事前定義されたデータ・スキーマ、およびスタートアップ前の構成）を、図３～図９を参照して説明する。なお、ストレージおよびキューイングについて言及した技術はプレースホルダーであることに注意すべきである。当業者であれば、性能に関する他の考慮事項に基づき、各々に代替技術を選択できることが理解されるであろう。
【0111】
図３は、一実施形態例における前記ブロックチェーン・トランザクション・マネージャー１００のコンポーネントのブロック図を例示したものである。例示したように、前記ＥＴＭコンソール１２０は、ＲＥＳＴ ＡＰＩ ３００を介して前記デプロイされたＥＴＭアプリケーションおよびサービス１３０と通信し、これらは転じて、例示したアプリケーションおよびサービス・コンポーネントと通信する。そのようなコンポーネントとしては表１で説明したものがあり、これにはETM_App １３０、ETM_TxHandler_Service ３０５、ETM_Polling_Service ３１０、およびETM_Scheduling_Service ３１５が含まれる。これらのコンポーネントはサブシステムも含み、これにはメッセージング・キュー・サブシステム３２０、永続的リレーショナルデータベース３２５、およびインメモリ・データベース３３０が含まれる。前記コンポーネントは、これら技術のためのサポート・ライブラリ、例えば前記実施形態例のもの、すなわちキュー・サポート・ライブラリ３３５、オブジェクト関係マッピング３４０、リレーショナルデータベース・サポート３４５、およびインメモリ・データベース・サポート３５０を含むこともできる。前記コンポーネントは、ブロックチェーン・ネットワーク・ピア・デバイス３７０とのインタラクションに、ブロックチェーン・サポート・ライブラリ３６０を使用することもできる。これらのコンポーネントについては、以下でさらに詳しく説明する。
【0112】
コンソールの静的な構成
以上概説したように、前記ＥＴＭコンソール１２０は、ブロックチェーン・トランザクション・マネージャー機能のサブセットへのアクセスを人間のユーザーに提供するアプリケーションである。前記ＥＴＭコンソール１２０の構成に関するハイレベルの概要を図４に例示する。
以上概説したように、前記ＥＴＭコンソール１２０は、ブロックチェーン・トランザクション・マネージャー機能のサブセットへのアクセスを人間のユーザーに提供するアプリケーションである。前記ＥＴＭコンソール１２０の構成に関するハイレベルの概要を図４に例示する。
【0113】
図４は、一実施形態例における前記ＥＴＭコンソール１２０のブロック図を例示したものである。図示するように、前記ＥＴＭコンソール１２０は、一実施形態例において、パッケージ、例えばウェブ・ユーザーインターフェース・フレームワーク４００、ウェブ・ユーザーインターフェース・スタイリング用のパッケージ４１０、およびユーザーインターフェースのイベントとＡＰＩレスポンスを操作するパッケージ４２０を含む。図に略示したホーム画面（４３０）、サービス（４４０）、およびインターセプター（４５０）用の≪フォルダ≫定型パッケージは、実行時に解釈されて前記ＲＥＳＴ ＡＰＩ ３００と通信するコードファイルのセットを含む。解釈される言語によくあるように、これら個々のファイルは、サービス・コンポーネント自体のレベルに達するまで、適正にコンポーネントと見なせる、粒度の最も高いコード単位である。そのため、サブコンポーネントの代わりにフォルダ編成を示している。他の実施形態では、コンパイルされた、または他の任意の形態でコードを使用できる。
【0114】
ＥＴＭアプリケーションの静的な構成
図５は、一実施形態例における前記ＥＴＭアプリケーション１３０のブロック図を例示したものである。前記ＥＴＭアプリケーション１３０は、前記システム１００にＲＥＳＴエンドポイントを提供し、第１のキューに向かうトランザクションのパイプである。ＥＴＭアプリケーション１３０の一実施形態例は、言語、例えば、ウェブ・アプリケーション・フレームワーク・パッケージのサポートを備えたウェブ・アプリケーション・サーバーの文脈での用途に適したＮｏｄｅ．ｊｓ（登録商標）でコードされる。図５は、その実装と依存性の重要な要素を示している。図４に示した依存性は、ここでは、または以下で説明するその他のサービス・コンポーネントでは、繰り返されない。キューへのパブリッシュおよびキューからの消費のため、ならびにデータベースとインタラクトするためのサポート・コードも存在するが、ここでは、または前記サービス・コンポーネントのいずれについても、説明を容易にするため示していない。
図５は、一実施形態例における前記ＥＴＭアプリケーション１３０のブロック図を例示したものである。前記ＥＴＭアプリケーション１３０は、前記システム１００にＲＥＳＴエンドポイントを提供し、第１のキューに向かうトランザクションのパイプである。ＥＴＭアプリケーション１３０の一実施形態例は、言語、例えば、ウェブ・アプリケーション・フレームワーク・パッケージのサポートを備えたウェブ・アプリケーション・サーバーの文脈での用途に適したＮｏｄｅ．ｊｓ（登録商標）でコードされる。図５は、その実装と依存性の重要な要素を示している。図４に示した依存性は、ここでは、または以下で説明するその他のサービス・コンポーネントでは、繰り返されない。キューへのパブリッシュおよびキューからの消費のため、ならびにデータベースとインタラクトするためのサポート・コードも存在するが、ここでは、または前記サービス・コンポーネントのいずれについても、説明を容易にするため示していない。
【0115】
図５に例示するように、前記ＥＴＭアプリケーション１３０は、前記ＲＥＳＴ ＡＰＩ ３００とインタラクトし、ウェブ・アプリケーション・フレームワーク・パッケージ５００と、アイデンティティ／アクセス管理ソフトウェア５１０と、アイデンティティ・クレデンシャルを暗号化する暗号化ライブラリ・パッケージ５２０と、アクセス・トークン・サポート・パッケージ５３０とを使用する。ここでも、ルート（ＲＥＳＴ ＡＰＩｓ）５４０、サービス（コア機能）５５０、モデル（データ・エンティティ）５６０、およびキュー・イベントを扱うjobQueues/jobHandlers ５７０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。
【0116】
トランザクション・ハンドリング・サービスの静的な構成
図６は、ETM_TxHandler_Service ３０５の一実施形態例を例示したものである。このETM_TxHandler_Service ３０５は、種々のキューからトランザクションを消費し、各々のライフサイクル段階に適切な場合、それらを操作する。前記ポーリングおよびスケジューリング・サービス・コンポーネントと同様、前記ETM_TxHandler_Service ３０５は、露出したＡＰＩを伴わないウェブ・アプリケーションとして実装されてきた。図示するように、当該ETM_TxHandler_Service ３０５は、ウェブ・アプリケーション・フレームワーク６００と、ブロックチェーン・トランザクション署名サポート・ソフトウェア６１０と、インメモリ・データベース・レコード・ロック・サポート・ソフトウェア６２０と、を含むパッケージを使う。ここでも、モデル（データ・エンティティ）６３０、サービス（コア機能）６４０、およびキュー・イベントを扱うjobQueues/jobHandlers ６５０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。「サービス」フォルダ６４０は、適切な場合にトランザクションを演算する論理を含むことが理解されるであろう。
図６は、ETM_TxHandler_Service ３０５の一実施形態例を例示したものである。このETM_TxHandler_Service ３０５は、種々のキューからトランザクションを消費し、各々のライフサイクル段階に適切な場合、それらを操作する。前記ポーリングおよびスケジューリング・サービス・コンポーネントと同様、前記ETM_TxHandler_Service ３０５は、露出したＡＰＩを伴わないウェブ・アプリケーションとして実装されてきた。図示するように、当該ETM_TxHandler_Service ３０５は、ウェブ・アプリケーション・フレームワーク６００と、ブロックチェーン・トランザクション署名サポート・ソフトウェア６１０と、インメモリ・データベース・レコード・ロック・サポート・ソフトウェア６２０と、を含むパッケージを使う。ここでも、モデル（データ・エンティティ）６３０、サービス（コア機能）６４０、およびキュー・イベントを扱うjobQueues/jobHandlers ６５０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。「サービス」フォルダ６４０は、適切な場合にトランザクションを演算する論理を含むことが理解されるであろう。
【0117】
これは、ブロックチェーン・ネットワークにトランザクションを送信する１つのコンポーネントであるため、デジタル署名用のライブラリ（ブロックチェーン・トランザクション署名サポート６１０）および一時的にキャッシュ・エントリをロックするライブラリ（インメモリ・データベース・レコード・ロック・サポート６２０）を使用する。後者は、ナンス割り当ての衝突を回避するうえで使用される。
【0118】
ポーリング・サービスの静的な構成
図７は、ETM_Polling_Service ３１０の一実施形態例を例示したものである。ETM_Polling_Service ３１０は、ブロックチェーン・ネットワークに送信されたトランザクションのステータスを追跡する。また、ETM_Polling_Service ３１０の実施形態例は、ウェブ・アプリケーション・フレームワーク・パッケージ７００を使って実装される。ここでも、モデル（データ・エンティティ）７１０、サービス（コア機能）７２０、およびキュー・イベントを扱うjobQueues/jobHandlers ７３０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。トランザクションの属性がブロックチェーン台帳内の採掘済みブロックに最終的に見つかった場合、付加的なソフトウェア・パッケージ（図示せず）により前記属性の構文解析が容易になることが理解されるであろう。
図７は、ETM_Polling_Service ３１０の一実施形態例を例示したものである。ETM_Polling_Service ３１０は、ブロックチェーン・ネットワークに送信されたトランザクションのステータスを追跡する。また、ETM_Polling_Service ３１０の実施形態例は、ウェブ・アプリケーション・フレームワーク・パッケージ７００を使って実装される。ここでも、モデル（データ・エンティティ）７１０、サービス（コア機能）７２０、およびキュー・イベントを扱うjobQueues/jobHandlers ７３０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。トランザクションの属性がブロックチェーン台帳内の採掘済みブロックに最終的に見つかった場合、付加的なソフトウェア・パッケージ（図示せず）により前記属性の構文解析が容易になることが理解されるであろう。
【0119】
スケジューリング・サービスの静的な構成
図８は、ETM_Scheduling_Service ３１５の一実施形態例を例示したものである。ETM_Scheduling_Service ３１５は、実行時間の長い定期的な工程を扱う。日時順ジョブ・スケジューリング・サポート・ソフトウェア・パッケージ８００は、実施形態例における日時順のジョブ・スケジューリングを容易にする。また、ETM_Scheduling_Service ３１５の実施形態例は、ウェブ・アプリケーション・フレームワーク・パッケージ８１０を使って実装される。ここでも、モデル（データ・エンティティ）８２０、サービス（コア機能）８３０、およびjobQueues ８４０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。
図８は、ETM_Scheduling_Service ３１５の一実施形態例を例示したものである。ETM_Scheduling_Service ３１５は、実行時間の長い定期的な工程を扱う。日時順ジョブ・スケジューリング・サポート・ソフトウェア・パッケージ８００は、実施形態例における日時順のジョブ・スケジューリングを容易にする。また、ETM_Scheduling_Service ３１５の実施形態例は、ウェブ・アプリケーション・フレームワーク・パッケージ８１０を使って実装される。ここでも、モデル（データ・エンティティ）８２０、サービス（コア機能）８３０、およびjobQueues ８４０用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。
【0120】
データベースおよびキュー・エンティティ・スキーマ
前記ブロックチェーン・トランザクション・マネージャー１００で永続的ストレージおよびキュー・ストレージ用に定義されるスキーマであって、トランザクション管理に関するものを、以下の表４に例示する。前記永続的データベースと併用されるこれらスキーマの目的としては、サービス・コンポーネント間で移動中の、特に先入れ先出しキューが不要なETM_Scheduling_Serviceに向かうトランザクション用のキューの代わりに、トランザクションと各々の進捗状況の永続的レコードを各々のライフサイクルにわたり提供し、呼び出しアプリケーションと、ユーザーと、ブロックチェーン・ネットワークおよびノードとの属性を保管することなどがある。
前記ブロックチェーン・トランザクション・マネージャー１００で永続的ストレージおよびキュー・ストレージ用に定義されるスキーマであって、トランザクション管理に関するものを、以下の表４に例示する。前記永続的データベースと併用されるこれらスキーマの目的としては、サービス・コンポーネント間で移動中の、特に先入れ先出しキューが不要なETM_Scheduling_Serviceに向かうトランザクション用のキューの代わりに、トランザクションと各々の進捗状況の永続的レコードを各々のライフサイクルにわたり提供し、呼び出しアプリケーションと、ユーザーと、ブロックチェーン・ネットワークおよびノードとの属性を保管することなどがある。
【0121】
本質的に、キュー内のトランザクションを表現するうえでも、同じスキーマが使用される（一実施形態例ではＪＳＯＮオブジェクトとして）。以下の表４と図９は、トランザクション処理に直接関係する５つのエンティティについて説明したものである。
【表4】
【0122】
以下では、トランザクション管理に重要なフィールド値について説明する。
【0123】
ＲＥＳＴ ＡＰＩデータ・スキーマ
ETM_Appサービス・コンポーネント１３０は、前記ＲＥＳＴ ＡＰＩ ３００を介して、前記システムとの間で種々のデータ・オブジェクトを渡す。以下は、生トランザクションの受け取り時に予測されるＪＳＯＮオブジェクトのフォーマット例である。
ETM_Appサービス・コンポーネント１３０は、前記ＲＥＳＴ ＡＰＩ ３００を介して、前記システムとの間で種々のデータ・オブジェクトを渡す。以下は、生トランザクションの受け取り時に予測されるＪＳＯＮオブジェクトのフォーマット例である。
【0124】
単純なトランザクション・リクエスト：
{
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞",
"to": "0x0123456789abcdef0123456789abcdef01234567",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
}
コントラクト・トランザクション・リクエスト：
{
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞rinkeby",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
}
単純なバルク・トランザクション・リクエスト（リクエストごとに最高５０トランザクションをサポート）：
[
{
"id": 200,
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞rinkeby",
"to": "0x0123456789abcdef0123456789abcdef01234567",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
},
{
"id": 201,
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞rinkeby",
"to": "0x0123456789abcdef0123456789abcdef01234567",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
},
etc...
]
単純なトランザクションまたはコントラクト・トランザクションのリクエストが受理された場合の、前記ブロックチェーン・トランザクション・マネージャーの応答：
{
"result": "Transaction successfully received",
"tx_id": "12345678-90ab-cdef-1234-567890abcdef"
}
単純なバルク・トランザクション・リクエストが受理された場合の、前記ブロックチェーン・トランザクション・マネージャーの応答：
[
{
"id": 200,
"result": "Transaction successfully received",
"tx_id": "12345678-90ab-cdef-1234-567890abcdef"
},
{
"id":201,
"result": "Transaction successfully received",
"tx_id": "12345678-90ab-cdef-1234-567890abcdef"
},
etc...
]
なお、tx_idは、上述した一意のトランザクション識別子であることに注意すべきである。
{
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞",
"to": "0x0123456789abcdef0123456789abcdef01234567",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
}
コントラクト・トランザクション・リクエスト：
{
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞rinkeby",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
}
単純なバルク・トランザクション・リクエスト（リクエストごとに最高５０トランザクションをサポート）：
[
{
"id": 200,
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞rinkeby",
"to": "0x0123456789abcdef0123456789abcdef01234567",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
},
{
"id": 201,
"application": "＜Application Name Goes Here＞",
"network": "＜Network Name Goes Here＞rinkeby",
"to": "0x0123456789abcdef0123456789abcdef01234567",
"from": "0x9876543210fedcba0x9876543210fedcba987654",
"data":"0xabcd123000000000000000000000000000001a",
"provider_type" : "http",
"retry_count": "2"
},
etc...
]
単純なトランザクションまたはコントラクト・トランザクションのリクエストが受理された場合の、前記ブロックチェーン・トランザクション・マネージャーの応答：
{
"result": "Transaction successfully received",
"tx_id": "12345678-90ab-cdef-1234-567890abcdef"
}
単純なバルク・トランザクション・リクエストが受理された場合の、前記ブロックチェーン・トランザクション・マネージャーの応答：
[
{
"id": 200,
"result": "Transaction successfully received",
"tx_id": "12345678-90ab-cdef-1234-567890abcdef"
},
{
"id":201,
"result": "Transaction successfully received",
"tx_id": "12345678-90ab-cdef-1234-567890abcdef"
},
etc...
]
なお、tx_idは、上述した一意のトランザクション識別子であることに注意すべきである。
【0125】
重要なフィールド値：Status（ステータス）
前記ブロックチェーン・トランザクション・マネージャー１００において、データ・フィールドstatusは、トランザクション・ライフサイクル全体の進捗状況において粒度の粗い点を定義する。このフィールドは、エンティティ（トランザクション、コントラクト、エラー）およびコードで表示される――いずれのサービス・コンポーネントでも、/config/configs/status.json を参照。許容されるフィールド値およびそれぞれの意味を、表５に記載する。
前記ブロックチェーン・トランザクション・マネージャー１００において、データ・フィールドstatusは、トランザクション・ライフサイクル全体の進捗状況において粒度の粗い点を定義する。このフィールドは、エンティティ（トランザクション、コントラクト、エラー）およびコードで表示される――いずれのサービス・コンポーネントでも、/config/configs/status.json を参照。許容されるフィールド値およびそれぞれの意味を、表５に記載する。
【表5】
【0126】
実施形態例において、前記ブロックチェーン・トランザクション・マネージャー１００は、以下を含むサービス・セットをユーザー・アプリケーションに提供するＮｏｄｅ．ｊｓ（登録商標）ウェブ・アプリケーションである。
【0127】
トランザクションのリクエスト受理、検証、およびキューイング、
トランザクションの価格設定、署名、および送信、
トランザクション・ステータスのポーリングおよび追跡、
スケジューリングおよび定期的なアクティビティ、
ダッシュボードおよび管理機能、および
レポートの生成およびメール送信
前記ブロックチェーン・トランザクション・マネージャー１００は、ナンス管理、反復コスト見積もり、およびトランザクション・ライフサイクル マネジメントも提供する。
トランザクションの価格設定、署名、および送信、
トランザクション・ステータスのポーリングおよび追跡、
スケジューリングおよび定期的なアクティビティ、
ダッシュボードおよび管理機能、および
レポートの生成およびメール送信
前記ブロックチェーン・トランザクション・マネージャー１００は、ナンス管理、反復コスト見積もり、およびトランザクション・ライフサイクル マネジメントも提供する。
【0128】
前記ブロックチェーン・トランザクション・マネージャーにおけるトランザクションのライフサイクル
前記ブロックチェーン・トランザクション・マネージャー１００の機能の大半は、個々のブロックチェーン（例えば、イーサリアム）トランザクションが確実に成功することを目指し、または失敗に対処する（希望的には、はるかに低い頻度で）ものである。その結果、前記システムの大部分の処理は、４つのブロックチェーン・トランザクション・マネージャー・サービスおよびブロックチェーン・ネットワークを通じたトランザクションの道筋をたどることにより理解される。以下の説明では、通常のトランザクション・ハンドリング、およびトランザクション自体またはそれに関するコンポーネント動作のどちらかに伴う問題が生じた場合の代替ハンドリングに伴うアクティビティについて吟味していく。
前記ブロックチェーン・トランザクション・マネージャー１００の機能の大半は、個々のブロックチェーン（例えば、イーサリアム）トランザクションが確実に成功することを目指し、または失敗に対処する（希望的には、はるかに低い頻度で）ものである。その結果、前記システムの大部分の処理は、４つのブロックチェーン・トランザクション・マネージャー・サービスおよびブロックチェーン・ネットワークを通じたトランザクションの道筋をたどることにより理解される。以下の説明では、通常のトランザクション・ハンドリング、およびトランザクション自体またはそれに関するコンポーネント動作のどちらかに伴う問題が生じた場合の代替ハンドリングに伴うアクティビティについて吟味していく。
【0129】
通常のトランザクション・ライフサイクル
トランザクションがそのライフサイクルを通して進むに伴い前記システムにより実行され、トラブルのない準備および送信と、迅速な採掘と、正常な実行に係わるアクティビティを、図１０に例示している。
トランザクションがそのライフサイクルを通して進むに伴い前記システムにより実行され、トラブルのない準備および送信と、迅速な採掘と、正常な実行に係わるアクティビティを、図１０に例示している。
【0130】
例示するように、前記ＥＴＭアプリケーション１３０は、１０１０で生トランザクションを検証し、etm_appキューに入れる。
【0131】
次に、ETM_TxHandler_Service ３０５が、１０２０で、前記生トランザクションをデキューし、その属性を準備して、前記生トランザクションを永続的キューに入れる。前記準備済みトランザクションは、１０３０でデキューおよびデジタル署名され、その署名済みトランザクションは、１０４０でブロックチェーン・ネットワークのノード１１０に送信される。成功応答が受信されると、前記トランザクションは１０５０でTx-Submittedステータスとともにデータベースに書き込まれ、ポーリング・キューに送信される。
【0132】
ETM_Polling_Service ３１０は、１０６０で前記ポーリング・キューから前記トランザクションをデキューし、１０７０でTx-Pendingステータスとともに前記データベースを更新して、polling_retryに加える。前記ブロックチェーン・ノードは、polling_retryキュー内にある間に、１０８０で送信「レシート」用にポーリングされる。そのポーリング結果は、１０８５で評価される。前記トランザクションが未採掘であるという結果が出ると、１０８０でポーリングが繰り返される。前記トランザクションが正常に採掘されると、１０９０で前記データベースがTx-Successステータスで更新され、前記ポーリング・キューからデキューされる。これでこの工程は完了する。
【0133】
ただし、この工程中には、いくつかエラーが起こりうる。以下、これらエラーの処理について説明する。
【0134】
遅延されるレシート・フロー
ポーリング第１ラウンド用の設定可能な時間枠の間にトランザクションが採掘された旨が示されない場合、前記システムは、そのトランザクションを一定時間保留にしたのち、ポーリングの第２ラウンドを開始する。これを実施するため、データベース内の前記トランザクションにフラグが設定される。ETM_Scheduling Service ３１５は、定期的に、前記フラグが設定されTx-Pendingステータスを伴うトランザクションについて、前記データベースにクエリーを行う。設定可能な待機時間後、前記フラグはクリアされ、前記トランザクションはポーリング入力キュー、etm_tx_polling、またはetm_contract_pollingの１つにパブリッシュされる。これにより、前記トランザクションに関するポーリングが再び開始される。再度のポーリングでもレシートが得られない場合は、このフローが繰り返され、設定可能な反復回数を過ぎると遅延時間がより長くなる。未採掘のトランザクションに対するこの反復は、レシートが受信されるまで無期限に続けられる。
ポーリング第１ラウンド用の設定可能な時間枠の間にトランザクションが採掘された旨が示されない場合、前記システムは、そのトランザクションを一定時間保留にしたのち、ポーリングの第２ラウンドを開始する。これを実施するため、データベース内の前記トランザクションにフラグが設定される。ETM_Scheduling Service ３１５は、定期的に、前記フラグが設定されTx-Pendingステータスを伴うトランザクションについて、前記データベースにクエリーを行う。設定可能な待機時間後、前記フラグはクリアされ、前記トランザクションはポーリング入力キュー、etm_tx_polling、またはetm_contract_pollingの１つにパブリッシュされる。これにより、前記トランザクションに関するポーリングが再び開始される。再度のポーリングでもレシートが得られない場合は、このフローが繰り返され、設定可能な反復回数を過ぎると遅延時間がより長くなる。未採掘のトランザクションに対するこの反復は、レシートが受信されるまで無期限に続けられる。
【0135】
ETM_AppのＡＰＩエラー応答フロー
ＥＴＭアプリケーション１３０によりトランザクションが前記生トランザクション・キューに入れられる際は、事前に、一握りのトランザクション関連エラー条件を認識できる。この場合、エラー応答は、前記ＲＥＳＴ ＡＰＩ ３００により戻される。この経路をとるエラーとしては、生トランザクションの検証が失敗、データベースが利用不能、およびキューが利用不能などがある。
ＥＴＭアプリケーション１３０によりトランザクションが前記生トランザクション・キューに入れられる際は、事前に、一握りのトランザクション関連エラー条件を認識できる。この場合、エラー応答は、前記ＲＥＳＴ ＡＰＩ ３００により戻される。この経路をとるエラーとしては、生トランザクションの検証が失敗、データベースが利用不能、およびキューが利用不能などがある。
【0136】
TxHandlerの修復および再送信フロー
startgasなどのネットワーク関連トランザクション属性によりトランザクションが拒否された場合は、属性を調整して再送信できる。例えば、図１１は、ETM_TxHandler_Service ３０５によるトランザクションの即時修復および再送信の工程１１００を例示したものである。この経路で扱える問題としては、gas low（ガス代が少ない）およびgas exceeded（ガス代が高すぎる）などがある。例示したように、準備済み未署名トランザクションのうちブロックチェーン・ノード１１０（例えば、イーサリアム・ノード）により拒否されたものは、１１１０で取得され、１１２０でそのトランザクションにアルゴリズム修復が適用されて、トランザクション属性が修復される（例えば、startgas修正）。前記修復されたトランザクションは、１１３０でデジタル署名され、署名されたそのトランザクションは、１１４０でブロックチェーン・ノードへの送信試行が繰り返される。その後問題が起こらない場合、後者の工程は、図１０の１０４０における正常なアクティビティ・フローの再開に対応する。
startgasなどのネットワーク関連トランザクション属性によりトランザクションが拒否された場合は、属性を調整して再送信できる。例えば、図１１は、ETM_TxHandler_Service ３０５によるトランザクションの即時修復および再送信の工程１１００を例示したものである。この経路で扱える問題としては、gas low（ガス代が少ない）およびgas exceeded（ガス代が高すぎる）などがある。例示したように、準備済み未署名トランザクションのうちブロックチェーン・ノード１１０（例えば、イーサリアム・ノード）により拒否されたものは、１１１０で取得され、１１２０でそのトランザクションにアルゴリズム修復が適用されて、トランザクション属性が修復される（例えば、startgas修正）。前記修復されたトランザクションは、１１３０でデジタル署名され、署名されたそのトランザクションは、１１４０でブロックチェーン・ノードへの送信試行が繰り返される。その後問題が起こらない場合、後者の工程は、図１０の１０４０における正常なアクティビティ・フローの再開に対応する。
【0137】
スケジューラのエラー・フローを通じた再試行
一部のエラーは、即時再送信で対処されるのではなく、遅延後の再試行で成功する場合がある。前記ブロックチェーン・トランザクション・マネージャー１００において、これらのトランザクションは、待ち時間中に条件を改善したのち生トランザクションとして再キューイングするよう、スケジューリング・サービス３１５に送られる。図１２は、一実施形態例において「再試行可能」なトランザクション・エラーを処理する工程１２００を例示している。この経路で扱われるエラーとしては、insufficient funds（残高不足）、RPC not responding（ＲＰＣの応答なし）、ERM_TxHandler_Service ３０５における特定のデータベース・エラー、およびknown transaction（既知のトランザクション）エラーなどがある。
一部のエラーは、即時再送信で対処されるのではなく、遅延後の再試行で成功する場合がある。前記ブロックチェーン・トランザクション・マネージャー１００において、これらのトランザクションは、待ち時間中に条件を改善したのち生トランザクションとして再キューイングするよう、スケジューリング・サービス３１５に送られる。図１２は、一実施形態例において「再試行可能」なトランザクション・エラーを処理する工程１２００を例示している。この経路で扱われるエラーとしては、insufficient funds（残高不足）、RPC not responding（ＲＰＣの応答なし）、ERM_TxHandler_Service ３０５における特定のデータベース・エラー、およびknown transaction（既知のトランザクション）エラーなどがある。
【0138】
図１２に例示するように、再試行可能なエラーにより拒否されたトランザクションはETM_TxHandler_Service ３０５に提供され、１２１０で前記ブロックチェーン・ノードへの送信が再試行される。１２１５で前記トランザクションが受理されると、そのトランザクションは、図１０を参照して上述した通常の経路に沿って進む。前記トランザクションが再び再試行可能なエラーにより拒否された場合、ETM_TxHandler_Service ３０５は、１２１０でそのトランザクションを前記ブロックチェーン・ノードに再送信するよう試みる。これは、設定可能な再試行の上限（最大の再試行回数）を超えるまで続く。そのような場合には、１２２０で前記トランザクションのナンスがキャッシュに維持されて、他のトランザクションに利用できるようにし、前記トランザクションは、１２３０でデータベースのエラー・トランザクション・テーブルに書き込まれる。前記トランザクションは、１２４０で前記データベースのアクティブ・トランザクション・テーブルから除去される。
【0139】
前記ETM_Scheduling_Service ３１５により定期的なソフトウェア・イベントが生成されることに応答し、当該サービスは、１２５０で前記データベースの前記エラー・トランザクション・テーブルにクエリーを行う。１２６０では、エラーの発生が見られたトランザクションごとに、そのトランザクションから生トランザクションが抽出され、生トランザクション・キューに入れられる。１２７０では、前記ETM_TxHandler_Service ３０５が、図１０を参照して上述した通常の経路に沿って、前記生トランザクションを処理する。
【0140】
トランザクション失敗経路
ポーリング工程により、トランザクションが採掘されたがその実行が失敗したことが示された場合、そのトランザクションは、図１０の「採掘され、成功した」経路のようにポーリング・キューからデキューされるが、そのトランザクションのステータスは、Tx-Failed（トランザクション失敗）と書き込まれる。
ポーリング工程により、トランザクションが採掘されたがその実行が失敗したことが示された場合、そのトランザクションは、図１０の「採掘され、成功した」経路のようにポーリング・キューからデキューされるが、そのトランザクションのステータスは、Tx-Failed（トランザクション失敗）と書き込まれる。
【0141】
アクティビティのタイミングに関する要約
図１３は、上述したアクティビティ経路をハイレベルでまとめたもので、前記システムがどこで意図的に時間遅延を導入するかに主眼を置いている。例示するように、ユーザー・アプリケーション１５０から受信されたトランザクションは、前記ＥＴＭアプリケーション１３０に提供され、その生トランザクションは、１３００で検証される。前記検証された生トランザクションは前記ETM_TxHandler_Service ３０５に提供され、これが１３１０で前記トランザクションを準備する。前記ＲＥＳＴ ＡＰＩ ３００は、これらの処理用に時間遅延およびretry_countを提供する。前記遅延は、トランザクション準備の各再試行前に、前記ETM_TxHandler_Service ３０５により意図的に処理に導入されて、問題を誘発している状態がそれ自体により解消されるようにする。提供された再試行回数を超えた後も前記トランザクションが適切に準備されない場合、そのトランザクションは、１３１５でETM_Scheduling_Service ３１５に送信され、指定された時間後に、そのトランザクションの再処理が生トランザクションとしてスケジュールされる。前記トランザクションは、１３１０で正常に準備されると、１３２０でブロックチェーンに送信される。前記ETM_TxHandler_Service ３０５は、この処理にも、再試行ごとにretry_countおよび意図的な遅延時間を提供する。前記トランザクションが適切に準備されず、提供された再試行回数を超えると、そのトランザクションも同様に１３１５でETM_Scheduling_Service ３１５に送信され、指定された時間後に、そのトランザクションの再処理が生トランザクションとしてスケジュールされる。前記トランザクションが１３２０でブロックチェーンに送信されると、前記ETM_Polling_Service ３１０が１３３０でレシートについてポーリングし、１３４０でトランザクションの成否を記録する。また、ポーリング時間の制限も提供される（例えば、５０００ｍｓ、または指定された最大再試行回数）。ポーリングが前記最大再試行回数を超えると、前記ETM_Scheduling_Service ３１５は、１３５０で再ポーリングをスケジュールする。例えば、例示したように、この再ポーリングは、最初の数分間に数回試行され、その後は、より長い間隔で再試行される。再度のポーリングでもレシートが得られない場合は、このフローが繰り返され、設定可能な反復回数を過ぎると遅延時間がより長くなる。未採掘のトランザクションに対するこの反復は、レシートが受信されるまで無期限に続けられる。そのため、特定の状況において、トランザクションは、正常に処理されるまで保持され、一定時間後に再試行される。
図１３は、上述したアクティビティ経路をハイレベルでまとめたもので、前記システムがどこで意図的に時間遅延を導入するかに主眼を置いている。例示するように、ユーザー・アプリケーション１５０から受信されたトランザクションは、前記ＥＴＭアプリケーション１３０に提供され、その生トランザクションは、１３００で検証される。前記検証された生トランザクションは前記ETM_TxHandler_Service ３０５に提供され、これが１３１０で前記トランザクションを準備する。前記ＲＥＳＴ ＡＰＩ ３００は、これらの処理用に時間遅延およびretry_countを提供する。前記遅延は、トランザクション準備の各再試行前に、前記ETM_TxHandler_Service ３０５により意図的に処理に導入されて、問題を誘発している状態がそれ自体により解消されるようにする。提供された再試行回数を超えた後も前記トランザクションが適切に準備されない場合、そのトランザクションは、１３１５でETM_Scheduling_Service ３１５に送信され、指定された時間後に、そのトランザクションの再処理が生トランザクションとしてスケジュールされる。前記トランザクションは、１３１０で正常に準備されると、１３２０でブロックチェーンに送信される。前記ETM_TxHandler_Service ３０５は、この処理にも、再試行ごとにretry_countおよび意図的な遅延時間を提供する。前記トランザクションが適切に準備されず、提供された再試行回数を超えると、そのトランザクションも同様に１３１５でETM_Scheduling_Service ３１５に送信され、指定された時間後に、そのトランザクションの再処理が生トランザクションとしてスケジュールされる。前記トランザクションが１３２０でブロックチェーンに送信されると、前記ETM_Polling_Service ３１０が１３３０でレシートについてポーリングし、１３４０でトランザクションの成否を記録する。また、ポーリング時間の制限も提供される（例えば、５０００ｍｓ、または指定された最大再試行回数）。ポーリングが前記最大再試行回数を超えると、前記ETM_Scheduling_Service ３１５は、１３５０で再ポーリングをスケジュールする。例えば、例示したように、この再ポーリングは、最初の数分間に数回試行され、その後は、より長い間隔で再試行される。再度のポーリングでもレシートが得られない場合は、このフローが繰り返され、設定可能な反復回数を過ぎると遅延時間がより長くなる。未採掘のトランザクションに対するこの反復は、レシートが受信されるまで無期限に続けられる。そのため、特定の状況において、トランザクションは、正常に処理されるまで保持され、一定時間後に再試行される。
【0142】
ＥＴＭ内のキューに関する追加情報
以上、トランザクションのライフサイクルにおけるキューの役割について説明してきたが、それらキューの内容とその用途について図２よりも詳しく理解すると有用であろう。
以上、トランザクションのライフサイクルにおけるキューの役割について説明してきたが、それらキューの内容とその用途について図２よりも詳しく理解すると有用であろう。
【0143】
各キューの内容は、何らかの形態のトランザクションである。それらにパブリッシュされるオブジェクトを記述するスキーマは、そのトランザクションが生か、準備済みか、エラー状態かに応じて、かつ、単純なトランザクションか、スマート・コントラクト・トランザクションかに応じて異なる。表６は、これらオブジェクトの１つがキューまたはデキューされる際のパブリッシュと消費の関係を一覧したものである。各キューに何が含まれているかを説明するにあたり、表６では、トランザクションのタイプとライフサイクル進捗状況を合わせた省略表現を使用している。
【表6】
【0144】
表７では、表６で使用したトランザクションのタイプとライフサイクル進捗状況に関する前記省略用語をさらに詳しく説明している。各タイプおよび状態のトランザクションを表現するため使用したデータ・エンティティが含まれている。
【表7】
【0145】
表７に概説された省略表現での状態名は、状態遷移モデルにおいて、上述した工程のトランザクション指向の見方を例示するうえで使用できる。
【0146】
図１４は、前記ブロックチェーン・トランザクション・マネージャー工程におけるトランザクションのライフサイクルを、一実施形態例に送信された単一のブロックチェーン・トランザクションについて、統一モデリング言語（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ：ＵＭＬ）状態遷移モデル１４００として視覚化し、例示したものである。例示するように、前記ETM_Appコンポーネント１３０は、トランザクションを受信して検証し（すなわち、そのトランザクションが有効であり、その送信者およびブロックチェーン・ネットワークが既知である）、その時点で、前記トランザクションは、システム内で初期状態にあると見なすことができ、raw_tx １４０５でラベル付けされる。状態１４０５の前記生トランザクションは、このトランザクションに属性を割り当て、デジタル署名するため、トランザクション・ハンドラ（ETM_TxHandler_Service ３０５）に提供される。成功すると、前記トランザクションは、準備済みトランザクションまたは準備済みコントラクトの状態１４１０に入ったものと見なすことができ、その区別は、そのトランザクションが単純なトランザクションかコントラクト・トランザクションかにそれぞれ依存する。この定義は後続状態に当てはまり、そのような区別については図で説明している。前記トランザクション・ハンドラが、この状態のトランザクションをその近傍ブロックチェーン・ノード１１０に送信すると、そのトランザクションが正常に送信されたか、前記近傍ブロックチェーン・ノード１１０により拒否されたかに応じて、決定の擬似状態１４１５により表される２つの状態のうち１つに入ると見なすことができる。拒否されると、前記トランザクションは、エラー発生トランザクションまたはエラー発生コントラクト・トランザクションの状態１４２０に入る。送信されると、前記トランザクションは、送信済みトランザクションまたは送信済みコントラクト・トランザクションの状態１４３０に入る。１４２０から引き続き、前記トランザクション・ハンドラは、前記送信を再試行し、可能性として反復し、その結果が新たな状態を擬似状態１４２５ごとに決定する。いずれかの再試行が成功すると、そのトランザクションは、前記送信済みトランザクションまたは送信済みコントラクトの状態１４３０に入る。ただし、前記設定可能なMaxRetries閾値を超える回数、トランザクションが拒否されると、そのトランザクションは、unresolved_errored状態１４３５に入ると見なせる。このunresolved_errored状態にあるトランザクションに対し、前記スケジューラ（ETM_Scheduling_Service ３１５）は、当該エラーがトランザクション・ハンドラにより解決できるタイプのエラーかどうかを決定する。この決定は、決定の擬似状態１４４０により表される。そうである場合、前記トランザクションは、前記生トランザクションの状態１４０５に戻され、ライフサイクルは、その状態から継続される。一方、前記スケジューラ３１５が決定の擬似状態１４４０において、エラー・タイプが手動で対処されるべき旨を決定すると、前記トランザクションは、終了状態の擬似状態１４７０への遷移で表されるように、永続的に前記unresolved_errored状態１４３５にとどまる。
【0147】
トランザクションが前記送信済みトランザクションまたは送信済みコントラクトの状態１４３０に入ると、前記ブロックチェーン・ネットワークは、コンポーネントETM_Polling_Service ３１０により、そのトランザクションのステータスについて繰り返しポーリングされる。その工程の結果が次の遷移を決定し、これは決定の擬似状態１４４５により表される。前記ポーリングにより前記トランザクションが採掘され失敗したことが示されると、そのトランザクションは、その最終状態である失敗したトランザクションまたは失敗したコントラクトの状態１４５０に入り、これは終了の擬似状態１４７０への遷移により表される。
【0148】
一方、前記ポーリング状態１４４５においてポーリング中に前記トランザクションが見つからない場合、そのトランザクションは、no_receipt_transactionまたはno_receipt_contractの状態１４５５に入る。コンポーネントETM_Scheduling_Service ３１５およびETM_Polling_Service ３１０が連携してブロックチェーン・ネットワークで前記トランザクションのステータスをポーリングしている間は、この状態が保たれる。前記ポーリングは無期限に続くが、結果が得られると、その結果により前記トランザクションの後続状態が決定され、これは決定の擬似状態１４６０により表される。前記ポーリングにより前記トランザクションが採掘され失敗したことが示されると、上記のとおり、そのトランザクションは、その最終状態である失敗したトランザクションまたは失敗したコントラクトの状態１４５０に入り、これは終了の擬似状態１４７０への遷移により表される。
【0149】
最後に、決定の擬似状態１４４５または決定の擬似状態１４６０のどちらかで考慮される前記ポーリングにより、前記トランザクションが採掘され成功したことが示されると、そのトランザクションは、その最終状態である成功したトランザクションまたは成功したコントラクトの状態１４６５に入り、これは終了の擬似状態１４７０への遷移により表される。
【0150】
このように、本明細書で説明する前記ブロックチェーン・トランザクション・マネージャー１００は、ユーザーのコンピュータからブロックチェーンまで、ブロックチェーン・トランザクションを適切に誘導するよう動作する。
【0151】
コンピュータ実施形態
図１５は、本明細書に開示した前記ブロックチェーン・トランザクション・マネージャー１００の１若しくはそれ以上の実施形態を実施するうえで適した特殊用途コンピュータへとプログラム可能な、一般的汎用コンピュータ１５００のブロック図である。上述の前記ブロックチェーン・トランザクション・マネージャー１００は、任意の汎用処理コンポーネント、例えば課された必要な作業負荷を扱ううえで十分な処理能力、メモリリソース、および通信処理能力を備えたコンピュータに実装できる。前記コンピュータ１５００は、メモリ・デバイスと通信可能なプロセッサ１５０２（中央処理装置またはＣＰＵと呼ぶことができる））を含み、前記メモリ・デバイスは、二次ストレージ１５０４と、読み出し専用メモリ（ＲＯＭ）１５０６と、ランダムアクセスメモリ（ＲＡＭ）１５０８と、入出力（Ｉ／Ｏ）装置１５１０と、ネットワーク接続装置１５１２とを含む。前記プロセッサ１５０２は、１若しくはそれ以上のＣＰＵチップとして実装でき、または１若しくはそれ以上の特定用途向け集積回路（application specific integrated circuits：ＡＳＩＣｓ）の一部であってよい。
図１５は、本明細書に開示した前記ブロックチェーン・トランザクション・マネージャー１００の１若しくはそれ以上の実施形態を実施するうえで適した特殊用途コンピュータへとプログラム可能な、一般的汎用コンピュータ１５００のブロック図である。上述の前記ブロックチェーン・トランザクション・マネージャー１００は、任意の汎用処理コンポーネント、例えば課された必要な作業負荷を扱ううえで十分な処理能力、メモリリソース、および通信処理能力を備えたコンピュータに実装できる。前記コンピュータ１５００は、メモリ・デバイスと通信可能なプロセッサ１５０２（中央処理装置またはＣＰＵと呼ぶことができる））を含み、前記メモリ・デバイスは、二次ストレージ１５０４と、読み出し専用メモリ（ＲＯＭ）１５０６と、ランダムアクセスメモリ（ＲＡＭ）１５０８と、入出力（Ｉ／Ｏ）装置１５１０と、ネットワーク接続装置１５１２とを含む。前記プロセッサ１５０２は、１若しくはそれ以上のＣＰＵチップとして実装でき、または１若しくはそれ以上の特定用途向け集積回路（application specific integrated circuits：ＡＳＩＣｓ）の一部であってよい。
【0152】
前記二次ストレージ１５０４は、通常、１若しくはそれ以上のディスクドライブまたはテープドライブから成り、不揮発性データ・ストレージに使用され、ＲＡＭ １５０８が全作業データを保持するうえで十分大きくない場合はオーバーフロー・データ・ストレージ・デバイスとして使用される。二次ストレージ１５０４を使うと、ＲＡＭ １５０８にロードされるプログラムが実行用に選択されたとき、そのようなプログラムを格納できる。前記ＲＯＭ １５０６は、プログラム実行中に読み出される命令および可能性としてデータを格納するため使用される。ＲＯＭ １５０６は不揮発性メモリ・デバイスであり、通常、二次ストレージ１５０４の大容量メモリと比べて、小容量のメモリを有する。前記ＲＡＭ １５０８は、揮発性データを格納し、可能性として命令を格納するため使用される。ＲＯＭ １５０６とＲＡＭ １５０８双方へのアクセスは、通常、二次ストレージ１５０４へのアクセスよりも高速である。
【0153】
本明細書で説明するデバイスは、コンピュータ可読命令を格納するコンピュータ可読非一時的媒体と、前記メモリと結合された１若しくはそれ以上のプロセッサとを含むよう構成でき、実行時、前記コンピュータ可読命令は、図１～図１４を参照して上述した方法工程および処理を実行するよう前記コンピュータ１５００を設定する。前記コンピュータ可読非一時的媒体は、全タイプのコンピュータ可読媒体を含み、これには、磁気ストレージ・メディア、光学ストレージ・メディア、フラッシュ・メディア、およびソリッドステート・メディアが含まれる。
【0154】
さらに、本開示の工程のいずれか１つまたは全部に関して上述した処理と演算を容易にする１若しくはそれ以上のコンピュータで実行可能な命令を含むソフトウェアは、１若しくはそれ以上のサーバーおよび／または１若しくはそれ以上のルーターおよび／または１若しくはそれ以上のデバイスにインストールでき、かつ、これらとともに本開示と一貫した消費者および／または生産者ドメインで販売できることを理解すべきである。あるいは、前記ソフトウェアは、本開示と一貫した消費者および／または生産者ドメイン内で、取得して、１若しくはそれ以上のサーバーおよび／または１若しくはそれ以上のルーターおよび／または１若しくはそれ以上のデバイスにロードでき、これには物理媒体または配信システムを介した前記ソフトウェア取得が含まれ、これには例えば前記ソフトウェアの作成者が所有するサーバーからの取得、または前記ソフトウェアの作成者が所有しないが使用するサーバーからの取得が含まれる。前記ソフトウェアは、例えばインターネットを通じた配信用に、サーバーに格納できる。
【0155】
また、当業者であれば、本開示は、その用途に関し、当該説明に記載し若しくは図面に示した構成要素（コンポーネント）の構造および構成の詳細に限定されないことが理解されるであろう。本明細書の実施形態は、他の実施形態も可能であり、種々の方法で実施または実行できる。また、本明細書で使用する表現おび用語は、説明を目的としたものであり、限定的なものと見なすべきではないことが理解されるであろう。本明細書で使用する「を含む（ｉｎｃｌｕｄｉｎｇ）」、「を有する（ｃｏｍｐｒｉｓｉｎｇ）」、または「を有する（ｈａｖｉｎｇ）」、およびこれらの派生表現は、付随して記載された項目とその均等物だけでなく、付加的な項目も包含するよう意図されている。特に限定されない限り、本明細書における用語「接続される（ｃｏｎｎｅｃｔｅｄ）」、「結合される（ｃｏｕｐｌｅｄ）」、「取り付けられる（ｍｏｕｎｔｅｄ）」、およびこれらの変形表現は広義に使用され、直接的および間接的な接続、結合、および取り付けを包含する。また、用語「接続される（ｃｏｎｎｅｃｔｅｄ）」および「結合される（ｃｏｕｐｌｅｄ）」、およびこれらの変形表現は、物理的または機械的な接続または結合に制限されない。さらに、用語、例えば「上へ（ｕｐ）」、「下へ（ｄｏｗｎ）」、「底部（ｂｏｔｔｏｍ）」、および「頂部（ｔｏｐ）」は相対的なものであり、例示を補足するため使用されるが、限定を意図したものではない。
【0156】
例示した実施形態に基づき使用される前記例示的なデバイス（装置）、システム、および方法の構成要素は、少なくとも部分的に、デジタル電子回路、アナログ電子回路、またはコンピュータ・ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装できる。これらの構成要素は、例えば、コンピュータ・プログラム製品、例えば情報担体または機械可読ストレージ・デバイスで有形に具現化されたコンピュータ・プログラム、プログラム・コード、またはコンピュータ命令として、データ処理装置、例えばプログラム可能なプロセッサ、コンピュータ、または複数のコンピュータにより実行し、またはその動作を制御するために実装できる。
【0157】
コンピューター・プログラムは、コンパイルまたは解釈される言語を含む任意形態のプログラミング言語で書き込み可能であり、スタンドアロン・プログラムとして、またはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境での使用に適した他のユニットとしてのものを含む任意形態でデプロイできる。コンピュータプログラムは、コンピュータまたは複数のコンピュータにおける、1か所、または分散され通信ネットワークで相互接続された複数か所での実行用にデプロイできる。また、本明細書で説明した技術を実施する機能的なプログラム、コード、およびコード・セグメントは、当業者プログラマであれば、本開示の範囲内であるとして容易に解釈できるであろう。前記例示的な実施形態に伴う方法工程は、機能を実行するための（例えば、入力データを計算し、および／または出力を生成することにより）コンピュータ・プログラム、コード、または命令を実行する１若しくはそれ以上のプログラム可能なプロセッサにより実施できる。また、方法工程は、特殊用途論理回路、例えばＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）またはＡＳＩＣ（特定用途向け集積回路）などにより実施でき、装置は、これらとして実装することができる。
【0158】
本明細書に開示した実施形態に関連付けて説明した種々の例示的な論理ブロック、モジュール、および回路は、本明細書で説明した機能を実行するよう設計された汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、ＡＳＩＣ、ＦＰＧＡ、または他のプログラム可能な論理デバイス、離散ゲート、またはトランジスタ論理、離散ハードウェア・コンポーネント、またはこれらの任意の組み合わせで実装または実行できる。汎用プロセッサは、マイクロプロセッサであってよいが、代替形態において、前記プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはオートマトンであってよい。また、プロセッサは、コンピュータ装置の組み合わせ、例えばＤＳＰおよびマイクロプロセッサ、複数のマイクロプロセッサ、１若しくはそれ以上のマイクロプロセッサをＤＳＰコアと連動させたもの、またはそのような他の任意の構成の組み合わせとして実装できる。
【0159】
コンピューター・プログラムの実行に適したプロセッサには、例として、汎用および特殊用途マイクロプロセッサの双方、ならびに任意タイプのデジタル・コンピュータの任意の１若しくはそれ以上のプロセッサなどがある。一般に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリ、あるいはその双方から命令とデータを受け取る。コンピュータの本質的な要素は、命令を実行するプロセッサ、および命令とデータを格納する１若しくはそれ以上のメモリ・デバイスである。一般に、コンピュータは、データを格納する１若しくはそれ以上の大容量ストレージ・デバイス、例えば磁気、磁気・光ディスク、または光ディスクも含むことになり、またはそれらに動作可能に結合されてそこからデータを受信し若しくはこれにデータを転送し、またはその双方を行う。コンピュータ・プログラム命令およびデータを具現化するうえで適した情報担体としては、全形態の不揮発性メモリなどがあり、これには例えば、半導体メモリ・デバイス、例えば電気的にプログラム可能な読み出し専用メモリすなわちＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ：ＥＰＲＯＭ）、電気的に消去可能でプログラム可能なＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ：ＥＥＰＲＯＭ）、フラッシュ・メモリ・デバイス、およびデータ・ストレージ・ディスク（例えば、磁気ディスク、内蔵ハードディスク、またはリムーバブル・ディスク、磁気・光ディスク、ならびにＣＤ－ＲＯＭおよびＤＶＤ－ＲＯＭディスク）が含まれる。前記プロセッサおよび前記メモリは、特殊用途論理回路により補完でき、またはこれに組み込むことができる。
【0160】
当業者であれば、情報および信号は、多種多様な技術およびテクニックのいずれかを使って表されることが理解されるであろう。例えば、以上の説明全体にわたり参照可能なデータ、命令（ｉｎｓｔｒｕｃｔｉｏｎｓ）、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光学場または光子、あるいはこれらの任意の組み合わせにより表すことができる。
【0161】
当業者であれば、さらに、本明細書に開示した実施形態に関連付けて説明した前記種々の例示的な論理ブロック、モジュール、回路、およびアルゴリズム工程は、電子ハードウェア、コンピュータ・ソフトウェア、または双方の組み合わせとして実装できることが理解されるであろう。このハードウェアおよびソフトウェアの可換性を明確に例示するため、上記では、種々の例示的な構成要素（コンポーネント）、ブロック、モジュール、回路、および工程について、各々の機能性の点で全般的に説明してきた。このような機能性がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、システム全体に課される特定の用途および設計の制約に依存する。当業者であれば、説明した機能性を種々の方法で特定の用途ごとに実装できるであろうが、そのような実装に関する決定は、本開示の範囲からの逸脱を生じると解釈すべきではない。ソフトウェア・モジュールは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュ・メモリ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク、リムーバブル・ディスク、ＣＤ－ＲＯＭ、または当該技術分野で知られた他の任意形態の記憶媒体に常駐できる。例示的な記憶媒体はプロセッサに結合され、そのプロセッサが前記記憶媒体から情報を読み出し、そこに情報を書き込めるようにされる。代替形態では、前記記憶媒体を前記プロセッサと一体化できる。すなわち、前記プロセッサおよび前記記憶媒体は、集積回路に常駐でき、または離散コンポーネントとして実装できる。
【0162】
本明細書において、「機械可読媒体（ｍａｃｈｉｎｅ－ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）」とは、一時的または永続的に命令とデータを格納できる装置（デバイス）をいい、これに限定されるものではないが、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用（ＲＯＭ）、バッファ・メモリ、フラッシュ・メモリ、光媒体、磁気媒体、キャッシュ・メモリ、他種のストレージ（例えば、消去可能でプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ））、および／またはこれらの任意の適切な組み合わせを含む。用語「機械可読媒体」は、単一の媒体または複数のメディア（例えば、一元化または分散されたデータベース、または付随するキャッシュおよびサーバー）であって、プロセッサ命令を格納できるものを含むと解釈されるべきである。また、用語「機械可読媒体」は、任意の媒体、または複数の媒体の組み合わせであって、１若しくはそれ以上のプロセッサを実行するための命令を格納でき、その命令が１若しくはそれ以上のプロセッサにより実行される際、その１若しくはそれ以上のプロセッサが本明細書で説明した方法論のうち任意の１若しくはそれ以上を実行できるようにするものを含むと解釈されるべきである。このように、「機械可読媒体」とは、単一のストレージ装置（ａｐｐａｒａｔｕｓ）またはデバイスのほか、複数のストレージ装置またはデバイスを含む「クラウドベース」のストレージ・システムまたはストレージ・ネットワークをいう。本明細書における用語「機械可読媒体」は、信号自体は含まない。
【0163】
以上に示した説明および図は、単なる例示目的で示したものであり、請求項に特段の断りがない限り、前記例示的な実施形態を限定することを意図したものでは一切ない。なお、上述した種々の例示的実施形態の前記種々の要素の種々の技術的態様は、その他多くの方法で組み合わせが可能であり、これらすべてが、本開示の範囲内と見なされることに注意すべきである。
【0164】
そのため、例示的な実施形態を例示的目的で開示してきたが、当業者であれば、種々の変更形態、追加形態、および置換形態が可能であることが理解されるであろう。したがって、本開示は上記の実施形態に限定されるものではなく、添付の請求請求の範囲内で、ならびに各々の均等物の全範囲内で修正が可能である。
【符号の説明】
【0165】
１００...ブロックチェーン・トランザクション・マネージャー
１１０...近傍ブロックチェーン・ノード
１２０...ＥＴＭ（商標）コンソール
１３０...ＥＴＭ（商標）アプリケーションおよびサービス
１４０...ユーザー・ブラウザ
１５０...ブロックチェーン・トランザクション生成アプリケーション
１５５...ブロックチェーン・ノード
３００...ＲＥＳＴ ＡＰＩ
３０５...ETM_TxHandler_Service
３１０...ETM_Polling_Service
３１５...スケジューリング・サービス、ETM_Scheduling_Service
３２０...キュー・サブシステム
３２５...永続的リレーショナルデータベース
３３０...インメモリ・データベース
３３５...キュー・サポート・ライブラリ
３４０...オブジェクト関係マッピング
３４５...リレーショナルデータベース・サポート
３５０...インメモリ・データベース・サポート
３６０...ブロックチェーン・サポート・ライブラリ
３７０...ブロックチェーン・ネットワーク・ピア・デバイス
４００...ウェブ・ユーザーインターフェース・フレームワーク
４１０...ウェブ・ユーザーインターフェース・スタイリング用のパッケージ
４２０...ユーザーインターフェースのイベントとＡＰＩレスポンスを操作するパッケージ
４３０...ホーム画面
４４０...サービス
４５０...インターセプター
５００...ウェブ・アプリケーション・フレームワーク・パッケージ
５１０...アイデンティティ／アクセス管理ソフトウェア
５２０...暗号化ライブラリ・パッケージ
５３０...アクセス・トークン・サポート・パッケージ
５４０...ルート（ＲＥＳＴ ＡＰＩｓ）
５５０...サービス（コア機能）
５６０...モデル（データ・エンティティ）
５７０...jobQueues/jobHandlers
６００...ウェブ・アプリケーション・フレームワーク
６１０...ブロックチェーン・トランザクション署名サポート・ソフトウェア
６２０...インメモリ・データベース・レコード・ロック・サポート・ソフトウェア
６３０...モデル（データ・エンティティ）
６４０...サービス（コア機能）
６５０...jobQueues/jobHandlers
７００...ウェブ・アプリケーション・フレームワーク・パッケージ
７１０...モデル（データ・エンティティ）
７２０...サービス（コア機能）
７３０...jobQueues/jobHandlers
８００...日時順ジョブ・スケジューリング・サポート・ソフトウェア・パッケージ
８１０...ウェブ・アプリケーション・フレームワーク・パッケージ
８２０...モデル（データ・エンティティ）
８３０...サービス（コア機能）
８４０...jobQueues
１４００...統一モデリング言語（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ：ＵＭＬ）状態遷移モデル
１４０５...初期状態
１４１０...準備済みトランザクションまたは準備済みコントラクトの状態
１４１５...決定の擬似状態
１４２０...エラー発生トランザクションまたはエラー発生コントラクト・トランザクションの状態
１４２５...擬似状態
１４３０...送信済みトランザクションまたは送信済みコントラクト・トランザクションの状態
１４３５...unresolved_errored状態
１４４０...決定の擬似状態
１４４５...決定の擬似状態
１４５０...失敗したトランザクションまたは失敗したコントラクトの状態
１４５５...no_receipt_transactionまたはno_receipt_contractの状態
１４６０...決定の擬似状態
１４６５...成功したトランザクションまたは成功したコントラクトの状態
１４７０...終了の擬似状態
１５００...一般的汎用コンピュータ
１５０２...プロセッサ
１５０４...二次ストレージ
１５０６...読み出し専用メモリ（ＲＯＭ）
１５０８...ランダムアクセスメモリ（ＲＡＭ）
１５１０...入出力（Ｉ／Ｏ）装置
１５１２...ネットワーク接続装置
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】