JP2022532464A - ブロックチェーン・トランザクション・マネージャー - Google Patents

ブロックチェーン・トランザクション・マネージャー Download PDF

Info

Publication number
JP2022532464A
JP2022532464A JP2021547344A JP2021547344A JP2022532464A JP 2022532464 A JP2022532464 A JP 2022532464A JP 2021547344 A JP2021547344 A JP 2021547344A JP 2021547344 A JP2021547344 A JP 2021547344A JP 2022532464 A JP2022532464 A JP 2022532464A
Authority
JP
Japan
Prior art keywords
transaction
blockchain
blockchain transaction
nonce
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021547344A
Other languages
English (en)
Other versions
JP7457031B2 (ja
Inventor
スリバスタバ、ニーラジ
Original Assignee
ディーエルティー グローバル インク.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ディーエルティー グローバル インク. filed Critical ディーエルティー グローバル インク.
Publication of JP2022532464A publication Critical patent/JP2022532464A/ja
Application granted granted Critical
Publication of JP7457031B2 publication Critical patent/JP7457031B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1474Saving, restoring, recovering or retrying in transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/1675Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1687Temporal synchronisation or re-synchronisation of redundant processing components at event level, e.g. by interrupt or result of polling

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【要約】ブロックチェーン・トランザクション・マネージャーは、受信されたブロックチェーン・トランザクションを検証し、その検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れ、前記受信されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性を準備し、前記受信されたブロックチェーン・トランザクションを永続的キューに入れ、前記受信されたブロックチェーン・トランザクションにデジタル署名し、またはこれを認証し、前記デジタル署名または認証されたブロックチェーン・トランザクションを前記ノードに送信するよう試行し、前記送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングすることにより、ブロックチェーン・ネットワーク内のノードへのブロックチェーン・トランザクション送信を管理する方法を実施する。前記ブロックチェーン・トランザクション属性内でブロックチェーン・トランザクション処理手数料を自動的に再計算する工程が提供される。前記ブロックチェーン・トランザクションが拒否された場合にトランザクション属性を修復し、前記修復されたブロックチェーン・トランザクションを前記ノードに送信する工程も提供される。また、ナンスは、受信されたブロックチェーン・トランザクションに自動的に割り当てられ、前記関連付けられたブロックチェーン・トランザクションが拒否されると再割り当てされる。【選択図】 図3

Description

本願は、Neeraj Srivastavaにより2019年12月13日付で出願された米国仮特許出願第62/948,060号「Blockchain Transaction Manager」(ブロックチェーン・トランザクション・マネージャー)に基づく利益を主張するものであり、この参照によりその全体が本明細書に組み込まれる。
本願は、実行中のコンピュータ・アプリケーションとブロックチェーン・ネットワーク間に介在して前記実行中のアプリケーションのブロックチェーン・トランザクションの送信と監視と受け取りとを支援する仲介システムを対象としたものである。
ブロックチェーン・トランザクション・パイプラインは、多くの課題に直面している。一部の課題は、ブロックチェーン・プラットフォーム全般に共通した、例えばトランザクションの送信と、それらの共有台帳での受け取り間の遅延である。他の課題は、著しくプラットフォーム特有で、例えばイーサリアム(Ethereum)におけるトランザクション「ナンス」の採番問題で起こる拒否などである。これらの問題にソリューションを提供し、前記共通した課題およびプラットフォーム特有の課題に対処する単一のインターフェースに、そのソリューションを実装することが望ましい。
本明細書で説明するシステムおよび方法は、人的介入を最小限に抑えながら、アプリケーションがブロックチェーン・ネットワーク、例えばイーサリアムにトランザクションを送信できる率を最大限に伸ばし、成功して確定されるトランザクションの比率を最大限に伸ばすことにより、当該技術分野のニーズに対処する。本明細書で説明するインターフェースは、ユーザーのアプリケーションとブロックチェーン・ネットワーク間に挿入でき、これにより堅牢なトランザクション・パイプライン、ステータス・レポーティング、およびエラー管理という利点が得られる。本明細書で説明するブロックチェーン・トランザクション・マネージャーは、キュー、ならびにブロックチェーン・ネットワークの状態に応答してトランザクションを準備し各々の属性を繰り返し調整し、トランザクション・ステータスを知るためネットワークをポーリングするアルゴリズムを組み合わせたものにより、上記の課題に対処する。これらの能力は、並列性と、エラー後の自動再送信とを可能にする。
第1の態様では、ブロックチェーン・トランザクション・マネージャーが提供され、このブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク内のノード用に意図されたブロックチェーン・トランザクションを受信し、前記ブロックチェーン・ネットワーク内のノードへの前記ブロックチェーン・トランザクションの送信を管理する。前記ブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・トランザクションを生成するユーザー・アプリケーションへのインターフェースを提供するトランザクション管理アプリケーションを含む。前記トランザクション管理アプリケーションは、前記ブロックチェーン・ネットワークおよびトランザクションを送信するアイデンティティについて必要な情報を受信し、受信されたブロックチェーン・トランザクションを検証し、前記受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる。トランザクション・ハンドラは、前記ブロックチェーン・ネットワークおよびアイデンティティの情報を格納し、受信されたブロックチェーン・ネットワークの少なくとも1つのトランザクション属性を準備し、前記ユーザー・アプリケーションにより事前に供給されたアイデンティティ・クレデンシャルを使って、前記受信されたブロックチェーン・トランザクションに対し、前記ブロックチェーン・ネットワークに適用可能であるとしてデジタル署名または認証し、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する。ブロックチェーン・ポーラーは、送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスを観察および報告する。
実施形態例において、前記トランザクション管理アプリケーションは、前記ブロックチェーン・トランザクションを受信すると追跡目的でこれに汎用一意識別子を割り当てる。前記トランザクション・ハンドラは、さらに、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する試行を追跡用に追跡キューに入れ、前記ブロックチェーン・ネットワーク内のノードへ正常に送信されたブロックチェーン・トランザクションのステータス情報を格納する。
他の実施形態において、管理アクティビティ・スケジューラは、前記ブロックチェーン・ネットワーク内のノードにより拒否されたトランザクションを受信し、前記拒否されたトランザクションを再試行する。また、前記ブロックチェーン・ポーラーにより送信されたブロックチェーン・トランザクションの初期ポーリングが、設定可能な最大試行回数を超えると、前記管理アクティビティ・スケジューラは、前記送信されたブロックチェーン・トランザクションのステータスを追跡し続けるために、前記ブロックチェーン・ステータスのさらなるポーリングをより低い頻度で前記ブロックチェーン・ポーラーによりスケジュールすることができる。
さらに別の実施形態では、トランザクション管理コンソールが、インタラクティブなインターフェースを介して、人間のユーザーによる前記トランザクション管理アプリケーションへのアクセスを提供する。前記トランザクション管理コンソールは、前記ユーザーのインタラクティブなインターフェースを介して、ブロックチェーン・トランザクションと各々のステータスのリストを前記ユーザーに提供する。前記トランザクション管理コンソールは、さらに、ブロックチェーン・トランザクションに使用するアイデンティティまたはトランザクション認証クレデンシャルを管理する。
前記ブロックチェーン・トランザクション・マネージャーは、さらに、データベースを含むことができ、このデータベースは、送信されたがまだ前記ブロックチェーン・ネットワーク内のノードに正常に書き込まれていないブロックチェーン・トランザクションを格納し、前記送信が成功しなかった理由と、前記送信されたブロックチェーン・トランザクションのステータスとを格納する。
第2の態様では、ブロックチェーン・ネットワーク内のノードへのブロックチェーン・トランザクションの送信を管理する方法が提供される。この方法の実施形態例は、受信されたブロックチェーン・トランザクションを検証し、その検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる工程と、前記受信されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性を準備し、前記受信されたブロックチェーン・トランザクションを永続的キューに入れる工程と、前記ブロックチェーン・ネットワークに適切であるとして、前記受信されたブロックチェーン・トランザクションにデジタル署名し、またはこれを認証する工程と、前記デジタル署名または認証されたブロックチェーン・トランザクションを、前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と、前記送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングする工程とを含む。実施形態例において、前記ブロックチェーン・ステータスをポーリングする工程は、送信されたブロックチェーン・トランザクションの前記ブロックチェーン・ネットワークでの受理に向けた進捗状況に関する情報について、前記ブロックチェーン・ネットワーク内のノードをポーリングする工程と、望ましい進捗状況情報が受信されるまで前記ポーリングを再試行する工程とを含む。実施形態例において、前記ポーリング工程は、期限が切れた後または最大ポーリング試行回数後、頻度が低下する。
実施形態例において、前記方法は、さらに、前記ブロックチェーン・ネットワーク内のノードに送信されたブロックチェーン・トランザクションの送信が、前記ブロックチェーン・ネットワークにより前記トランザクションが受理される結果になったかどうかを、前記ブロックチェーン・ネットワークに適した基準に基づいて示す応答を受信する工程と、前記送信されたブロックチェーン・トランザクションを、前記送信されたブロックチェーン・トランザクションのステータスとともにデータベースに書き込む工程とを含む。前記送信されたブロックチェーン・トランザクションの前記ステータスが、前記送信が成功しなかったことを示した場合、前記方法は、さらに、前記送信が成功しなかった理由を前記データベースに格納する工程を含む。
他の実施形態例では、前記送信されたブロックチェーン・トランザクションが、再試行可能なエラーにより前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記拒否されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性に、修復アルゴリズムが適用されて、修復されたブロックチェーン・トランザクションが作成される。前記修復されたブロックチェーン・トランザクションは、デジタル署名され、前記修復されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する試行が行われる。前記送信されたブロックチェーン・トランザクションが、再試行可能なエラーにより前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記送信されたブロックチェーン・トランザクションは、受理されるまで若しくは再試行の上限を超えるまで、前記ブロックチェーン・ネットワーク内のノードに再送信される。前記再試行の上限を超えた場合は、格納された利用可能なトランザクション・ナンスのプールにナンス値を追加することにより前記トランザクションのナンスの可用性が示され、前記送信されたブロックチェーン・トランザクションが、データベース内のエラー発生トランザクション・テーブルに書き込まれ、最初に送信された生ブロックチェーン・トランザクションが抽出されて、その生ブロックチェーン・トランザクションが再び準備され、新規受信されたトランザクションと同じ工程を使って送信される。
ブロックチェーン・ネットワークがイーサリアムと同様なトランザクション・ナンスを使用する、さらに別の実施形態例では、前記受信されたブロックチェーン・トランザクションにナンスが自動的に割り当てられる。前記受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、同じアカウントおよびブロックチェーン・ネットワーク用に複数のブロックチェーン・トランザクションが並列処理されている場合、ロック機構を使って、必ず一度に1つのトランザクションについてしかナンスが計算されないようにする工程を含むことができる。ブロックチェーン・トランザクションが複数の再試行後も前記ブロックチェーン・ネットワーク内のノードに受理されない場合、前記受理されないブロックチェーン・トランザクションのナンスを、当該受理されないブロックチェーン・トランザクションに関連付けられたアカウントが再使用に利用できるナンスのプールに割り当てることができる。前記方法は、さらに、ナンスを割り当てる際、前記利用できるナンスのプールが、前記受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを含むかどうか考慮する工程と、前記ナンスのプールが、前記受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを少なくとも1つ含む場合、最も低い値のナンスを選択し、その最も低い値のナンスを前記受信されたブロックチェーン・トランザクションに割り当てる工程とを含むことができる。
前記受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、さらに、前記ブロックチェーン・ネットワーク内のノードから前記アカウント用のナンスを取得する工程と(Nweb3)、前回自動的に前記アカウントに割り当てられたナンスを取得する工程と(Nred)、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス(Nweb3)を、前回自動的に前記アカウントに割り当てられた前記ナンス(Nred)から減算する工程と、事前定義されたナンス・ウィンドウよりNred - Nweb3が大きい場合、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス(Nweb3)を選択し、それ以外の場合は、より大きな値を有するナンスを選択する工程とを有することができる。前記方法は、さらに、前記受信されたブロックチェーン・トランザクションにデジタル署名する前に、前記アカウントに利用可能な最低のナンスを選択する工程と、前記選択された最低ナンスよりも低い値を有するナンスが前記プールに含まれる場合、前記選択されたナンスを、前記プールからのより低い値のナンスと取り替える工程と、前記プールからの前記より低い値のナンスを、前記受信されたブロックチェーン・トランザクション用に使う工程とを含むことができる。
他の実施形態例では、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、その拒否されたブロックチェーン・トランザクションのナンスはナンスのプールに書き込まれ、そのプール内の最低値のナンスが、前記ブロックチェーン・ネットワーク内のノードへの送信用に準備された、次に受信されるブロックチェーン・トランザクションにより使用されるものである方法。前記拒否されたブロックチェーン・トランザクションは、再びデジタル署名される前に、前記ブロックチェーン・ネットワーク内のノードへの再送信用に、新規ナンスが自動的に割り当てられる。
さらに別の実施形態例において、前記少なくとも1つのトランザクション属性は、プロキシの演算およびストレージ・コスト単位あたりのブロックチェーン・トランザクション手数料として前記ブロックチェーン・トランザクションの送信者が支払いを申し出ている額を有し、前記手数料は、前記ブロックチェーン・トランザクションの処理について、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担される。前記額は、前記ブロックチェーン・ネットワークで最近受理されたブロックチェーン・トランザクションに関連付けられた額に基づいて自動的に計算できる。前記方法は、最大量の演算およびストレージ・プロキシ単位(G)を自動的に計算する工程を含むこともでき、Gは、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークによる前記ブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示すものである。このような方法は、前回採掘されたブロックの制限値を前記ブロックチェーン・ネットワークから取得する工程を含むことができ(Gmb)、前記制限値は、前記ブロックチェーン・ネットワーク内のノードを含む前記ブロックチェーン・ネットワークによる単一ブロックへの採掘用に選択されたブロックチェーン・トランザクションの処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量のプロキシ演算およびストレージ単位の合計の最大値を含む。次に、Gdb ≧ Gmbの場合、G = Gmb * αを割り当て(ここでα <1)、Gmb > Gdbの場合、比R = Gmb/Gdbを計算して、以下のようにGを見出す。
(R ≧ 0およびR ≦ 設定可能な係数CR1 、ここでCR1>0)の場合、G = Gdb * β、
(R > CR1およびR ≦ 設定可能な係数CR2 、ここでCR2> CR1)の場合、G = Gdb * γ、および
(R > CR2)の場合、G = Gdb * δ, where δ > γ > β > 1
次いで、前記ブロックチェーン・トランザクションにデジタル署名し若しくはこれを認証する前に、当該ブロックチェーン・トランザクションに適切な場合、当該ブロックチェーン・トランザクションにGが加算され、前記デジタル署名され若しくは認証されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行される。
他の実施形態では、前記ブロックチェーン・トランザクションの処理について前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担される、プロキシ単位あたりに推定される演算およびストレージ・コストのブロックチェーン・トランザクション手数料について、前記ブロックチェーン・トランザクションの送信者が支払いを申し出ている額が低すぎる、または高すぎるという理由から、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークによる前記ブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量の演算およびストレージ・プロキシ単位が所定のパーセンテージだけ増減調整され、前記ブロックチェーン・トランザクションが、スケジュールされた遅延後に前記ブロックチェーン・ネットワーク内のノードに再送信される。
本明細書で説明する実施形態は、本開示全体にわたり説明する方法を実装する命令によりコードされたコンピュータ・システムおよびコンピュータ可読媒体も包含する。例えば、本明細書で説明する前記システムおよび方法は、本明細書で説明するように、クラウドのコンピューティング・プラットフォーム上で実装して、データにアクセスし、これをブロックチェーン・プラットフォームに格納する機能を提供することができる。
本開示については、添付の図面の例により非限定的に例示しており、これらの図面において、同様な参照番号は同様な要素を示す。
図1は、ブロックチェーン・トランザクション・マネージャーが一実施形態例でデプロイされた場合に、これを使用する文脈のブロック図を例示したものである。 図2は、図1の前記ブロックチェーン・トランザクション・マネージャーのサービス・コンポーネントおよびキューを通じたトランザクションの全体的な動きを、メッセージ・キューの観点から例示したものである。 図3は、一実施形態例における図1の前記ブロックチェーン・トランザクション・マネージャーのコンポーネントのブロック図を例示したものである。 図4は、一実施形態例における図1の前記ETMコンソールのブロック図を例示したものである。 図5は、一実施形態例における図1の前記ETMアプリケーションのブロック図を例示したものである。 図6は、図3のETM_TxHandler_Serviceの一実施形態例を例示したものである。 図7は、図3のETM_Polling_Serviceの一実施形態例を例示したものである。 図8は、図3のETM_Scheduling_Serviceの一実施形態例を例示したものである。 図9は、実施形態例のトランザクション処理に直接関係する5つのエンティティのためのキュー内にあるトランザクションを表すうえで使用されるスキーマを例示したものである。 図10は、トランザクションのライフサイクルにわたる経路を例示したものであり、一実施形態例においてトラブルのない準備および送信と、迅速な採掘と、正常な実行を伴う。 図11は、一実施形態例におけるトランザクションの即時修復および再送信の工程を例示したものである。 図12は、一実施形態例において「再試行可能」なトランザクション・エラーを処理する工程を例示したものである。 図13は、上述したアクティビティ経路をハイレベルでまとめたもので、前記システムが、エラー発生後にどこで工程を再試行し、および/またはどこで意図的に時間遅延を導入するかに主眼を置いている。 図14は、一実施形態例における前記ブロックチェーン・トランザクション・マネージャー工程を状態遷移モデルとして視覚化して例示したものである。 図15は、本明細書に開示した前記ブロックチェーン・トランザクション・マネージャーの1若しくはそれ以上の実施形態を実施するうえで適した特殊用途コンピュータへとプログラム可能な、一般的汎用コンピュータのブロック図である。
以下の説明は、図1~15を参照して、当業者が実施できるよう具体的な実施形態を十分に例示したものである。他の実施形態では、構造上、論理上、工程上、および他の変更を実装できる。一部の実施形態の部分および特徴は、他の実施形態の部分および特徴に含め、またはそれを置き換えることができる。請求項に記載した実施形態は、それら請求項の利用可能なすべての等価物を包含する。
用語
ブロックチェーン:ブロックと呼ばれるレコードの、絶えず成長し続けるリスト。前記レコードは暗号を使ってリンクされ、固定される。各ブロックは、通常、直前のブロックの暗号ハッシュ、タイムスタンプ、およびトランザクション・データを含む。ブロックチェーンは、トランザクション・データの改ざんに本質的に耐性があるよう設計される。分散台帳としての用途のため、ブロックチェーンは、通常、新規ブロック検証用のプロトコルに集合的に準拠するピアツーピア・ネットワークにより管理される。一度記録されると、いかなる所与のブロックのデータも、すべての後続ブロックを変更することなく遡及的に変更することはできず、全後続ブロック変更には、ネットワークの過半数による共謀が必要になる。
スマート・コントラクト:ブロックチェーンまたは分散台帳で行われる汎用演算を提供するコンピュータ・プロトコル。スマート・コントラクト・トランザクションは、単純であっても、洗練された論理を実装するものであってもよい。その結果得られるトランザクションは、通常、台帳参加者に透明で、追跡可能および不可逆的である。種々の分散台帳技術プラットフォーム、例えばイーサリアムは、実装タイプのスマート・コントラクトを有する。イーサリアムの場合、スマート・コントラクトはプログラミングを高度に抽象化したものであり、バイトコードにまでコンパイルされ、イーサリアム・ブロックチェーンにデプロイされ、実行される。
Node.js(登録商標):JavaScriptコードをブラウザ外で実行する無料オープンソース・サーバー環境。Node.js(登録商標)は、ChromeブラウザのJavaScriptランタイム上で構築された非同期プログラミング・プラットフォームである。Node.js(登録商標)に関する詳細は、「About Node.js(登録商標)」、Node.js、Node.js Foundation、https://nodejs.org/en/about/で参照できる。
イーサリアム用語:本明細書で説明する実施形態例については、一般に使用されイーサリアムとして知られているブロックチェーン・プラットフォームを参照して説明する。イーサリアムの論文、実装、および関連ライブラリでは、同じ概念に異なる名称を使用する場合があり、本明細書では、以下の意味に沿った方法で、以下の用語が使用される。
プラットフォームの属性
Ether(イーサ):イーサリアム・ブロックチェーン・プラットフォーム固有の仮想通貨。この通貨の用途の1つは、ネットワークを代表してマイナー(採掘者)の仕事に報酬を支払うことである。この点でイーサリアムと同様なブロックチェーン・プラットフォームについては、本明細書における「イーサ」は、考慮されるプラットフォームに固有の類似仮想通貨と同義的なものと見なすべきである。
Miner(マイナー):ブロックチェーン・トランザクションを評価し、ブロックチェーン・データの完全性を各々のネットワーク内で集合的に維持する演算を実行するエンティティ(実体)。
トランザクション・ライフサイクル用語
Submitter(送信者):トランザクションに関連付けられたブロックチェーン・ネットワーク・アイデンティティであり、トランザクション用アイデンティティのクレデンシャルは、当該トランザクションのデジタル署名用に、および手数料が課金される仮想通貨アカウントに対して使用される。
Sending/Sent(送信中/送信済み):ブロックチェーン・ネットワーク内の近傍ノード宛トランザクションの初回通信(または試行)。
Rejected(拒否):ブロックチェーン・ネットワーク内の近傍ノードへの初回通信中、エラーのためトランザクションが拒否された。
Pending(保留中):初回通信中にトランザクションが受理され、保留中トランザクション・リストに入れられ、他のブロックチェーン・ネットワーク・ノードにブロードキャストされているが、採掘されているかはまだ不明である。
Mined(採掘済み):トランザクションが評価され、ブロックに含められ、ブロックチェーンに追加された(少なくとも所与のノードから見て)。トランザクションが成功(Succeeded)または失敗(Failed)した。
Receipt(レシート):ブロックチェーン・ネットワーク内の近傍ノードから発信されるデータで、成功または失敗に関する情報を含めて、トランザクションが採掘されたことがわかった旨を示す。(「Receipt」(レシート)は、広く使用されているweb3ソフトウェア・ライブラリが使用している用語で、イーサリアム・ノードで使用される。)
Succeeded(成功):採掘済みトランザクションが、採掘時にエラーなく完全に実行された。
Failed(失敗):採掘済みトランザクションが採掘時にエラーを起こし、完全に実行されず、失敗に関する詳細のブロックへの記録と、送信者の仮想通貨アカウントに対する当該試行の手数料の課金とを除いて影響は生じなかった。失敗は、種々の理由で起こる可能性があり、そのいくつかは本明細書で説明している。
Finalized(確定):当該ブロックチェーン・ネットワークの別部分でトランザクション確認処理がより進んだことが発見されたためブロックチェーン内でブロックが置換されるという事態になる可能性が極めて低いトランザクション。これを決定する正式な仕様はないが、通常は、後続して追加されるブロックの数に基づく。
Simple Transaction(単純なトランザクション):新規スマート・コントラクトを含まないブロックチェーン・トランザクション。
Contract Transaction(コントラクト・トランザクション):新規スマート・コントラクトを含むブロックチェーン・トランザクション。
トランザクションの属性
Gas(ガス代、燃料代):総演算量およびストレージ・コストの推定用に標準化されたプロキシ単位額であり、所与のトランザクションが処理されるとイーサリアムと同様なブロックチェーン・ネットワークが負担し、これをもとにトランザクションの送信者に手数料が課金される。「Gas」は、プロキシ単位であり、このような見積り総額の用語でもある。
Startgas(ガス代の上限):提案されたトランザクションに対して支払う意思がある上限額としてトランザクション送信者が示すプロキシ演算およびストレージの最大単位数。(これはweb3ライブラリ用語である。イーサリアムのイエローペーパーでは、これを「gas limit」(ガスリミット)と呼ぶ。
Gasprice(ガス価格):トランザクション送信者が、そのトランザクションを採掘するアカウントに申し出ている支払い額であり、そのトランザクションの処理中に消費された単位ガス代あたりの仮想通貨手数料。
Intrinsic gas(トランザクションで使われるガス):任意のスマート・コントラクト・コード実行前に、トランザクションが使用するであろうガス代。ベースラインのトランザクション・ガス代に、トランザクションに伴うパラメータとして供給される任意データのガス代を加えたものを含む。(後者が計算されるのは、トランザクションが失敗しても、入力パラメータがブロックチェーンに記録されるためである。)
Nonce(ナンス):本明細書においてナンスに関するすべての説明は、イーサリアムおよび同様なブロックチェーン・プラットフォーム上における送信者のトランザクションに必要な連番の採番に関する。
ネットワークの属性
Block gas limit(ブロック・ガスリミット):これは、ネットワーク上のマイナーが、保留中のトランザクションを単一ブロックで採掘するために選択する場合、選択された全トランザクションに対して許容されるstartgasの最大合計値である。各イーサリアム・ネットワーク、またはマイナーに報酬を支払うための同様な構造を備えたプラットフォームに基づくネットワークには、独自の制限値があり、各新規ブロックが追加された後に少量増加または減少する。
ブロックチェーン・ノードの属性
Nonce window(ナンス・ウィンドウ):トランザクションが有することのできる、ノードに受理される最高のナンス値であり、所与の送信者アイデンティティ用に前記ノードがブロックチェーン・ネットワークに送信した前回のトランザクションのナンスよりもデルタだけ高いものとして表現される。ナンス・ウィンドウの効果は、ブロードキャスト保留中のノードで各アイデンティティについて存在できるトランザクションの数を制限することである。ナンス・ウィンドウは、ブロックチェーン・ネットワーク内のノードごとに構成できる。
Proximate node(近傍ノード):ブロックチェーン・ネットワーク内のノードであって、ユーザーまたはアプリケーションが、当該ブロックチェーン・ネットワーク全体とインタラクトするうえで最も直接的に通信するノード。
概要
ブロックチェーン・トランザクションの課題
本明細書で説明するブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク、例えばイーサリアムと直接連動する場合、または現在広く使用されているサポート・ライブラリを使用する場合、アプリケーションが直面する難題に対処する。上記のように、本明細書の説明は、一般に使用されるイーサリアム・ブロックチェーン・ネットワークについて行うが、当業者であれば、本明細書で説明する技術は、他のブロックチェーン・ネットワーク、例えばAION、ArcBlock、EOS、NEO、Hyperledger(登録商標) Fabric、Hyperledger(登録商標) Sawtooth、NxT、QTUM、Quorum、Smilo、Tezos、TRON、Wanchain、またはZilliqaにも使用できることが理解されるであろう。本明細書における用語は、イーサリアム・ブロックチェーン・ネットワークに関するものである。対応する用語は、他のブロックチェーン・ネットワーク、例えば言及したものの文脈で使用される。
1.採掘予定または確定済みトランザクションのための同期的なWait
ブロックに追加予定のトランザクション、または何らかの措置により「ファイナリティ」を達成するためのトランザクションの時間遅延は、大部分のブロックチェーン・プラットフォームに共通する課題である。ナイーブなアプリケーションでは「ファイア・アンド・フォーゲット」アプローチをとり、ブロックチェーン・ネットワーク内の近傍ノードにトランザクションを送信し、それが成功するものと想定して、その後のアクティビティがそれ以外の状況になるまで、手続きを進める。より確実性を求める者は、手続きを進める前に、トランザクションが採掘または確定されるのを一般的な時間長だけ待つことを選択する。しかしながら、これらのアプローチはどちらも理想的ではない。一方は後続工程の不確実性増大を招き、他方は数分間の同期的な待ち時間を生じる。
2.ナンス・ギャップにより生じるトランザクション停止
イーサリアムなどのブロックチェーン・プラットフォームで採用されているトランザクション「ナンス」の概念に関する難題の2つ目のカテゴリー。ナンスとは、所与のブロックチェーン・アイデンティティ用に送信されたトランザクションに順次割り当てられるとして、ネットワークが予測する数値である。ナンスは送信者により割り当てられるが、実際には、送信者は、これを当該ブロックチェーン・ネットワークに関連付けられたサポート・コード・ライブラリに委託することが多い。イーサリアムと同様なネットワークは、ナンス数値の順にトランザクションを処理しようとし、それが種々の理由でトランザクションの遅延または失敗につながる場合がある。すでに処理された値より低い、または著しく高い値を伴うトランザクションは、完全に失敗する。シーケンスにない値は、シーケンス中のギャップが埋まるまで、後続ナンスを伴うトランザクションが無視される原因となる。
3.トランザクション手数料の期待値変更について手動でリコンフィグレーションする必要性
イーサリアム同様に採掘者への支払い機構を備えたブロックチェーン・プラットフォームで受理されるようにするため、トランザクションは、上記で定義したgaspriceに部分的に基づき、ネットワークへの手数料としてトランザクターが支払う意思のある最大額を伴う。gaspriceを軽んじると、より気前のよいトランザクションがブロックチェーンに含められるべく選択されることになり、長時間または無期限の遅延を招きかねない。後者は、好まれる価格の経時的な変動により、課題として複雑化する。しかし、その変動性に合わせてgaspriceを十分高く設定するということは、ほとんどの場合に過払いすることを意味する。そのため、大部分のトランザクターは、定期的に、またトランザクションが通らないと気づいたときにも、各々のアプリケーションが提案する価格を手動で調整する(そのトランザクションは、次いで新規に送信されなければならない)。
4.ブロックチェーン・トランザクションの拒否と失敗の発見および扱いに関する難題
ナンスおよびトランザクション手数料は、トランザクションが拒否および失敗する原因のうちのほんの2つである。これらと、スマート・コントラクト自体に起因するエラーを含む他の原因は、ブロックチェーン処理の非同期的な性質上、またプラットフォームからのエラー・レポートが不親切なため、検出が難しい。検出された場合は、対処が困難である。以下では、本明細書で説明するブロックチェーン・トランザクション・マネージャーに関連する具体的なエラー条件についていくつか説明する。
低ナンス・エラー
トランザクションへのナンス割り当ては、シーケンシャル処理として設計されている。各トランザクションは、二重支出い問題を防ぐため、ナンス(整数)と結び付られる。提案された各トランザクションにつき、ナンスは、その前のトランザクションのナンスより1大きいことが要求される。nonce low error(低ナンス・エラー)は、トランザクションが送信者からネットワークに対し、その送信者が前回採掘した直近のトランザクションよりも低いナンスを用いて提案されたときに起こる。この状況は、トランザクションを送信するアプリケーションの水平スケーリング試行中、例えばナイーブなナンス割り当てアルゴリズム、例えば広く使用されているイーサリアム・サポート・ライブラリに見られるものが使用された場合に起こりうる。それらのライブラリは、前記送信者の最高ナンスに関する独自のローカルな観察に基づき、ナンスを自動割り当てする。複数のインスタンスがこれを並行して試行すると、重複したナンス割り当てが起こる可能性が高く、2番目に処理されたものが失敗する結果となる。
ガス代が低すぎる、ガス代が高すぎる、およびガス切れ
上述のように、イーサリアムなどのブロックチェーン・プラットフォームにおけるトランザクションには、ネットワークへの手数料として送信者が支払う意思のある最大額が伴う。その額は、部分的に、トランザクション属性startgas、送信者に許容されるプロキシ演算の上限、およびトランザクションのストレージ単位に基づく。startgasについて選択される額がトランザクションの問題を起こす状況は3つある。その2つは、ブロックチェーン・ネットワーク内のノードにより、トランザクションがそのネットワークに送信されるとき、決定される。これらのプラットフォーム内の各トランザクションは、演算およびストレージに最低量のプロキシ単位を消費し、これをトランザクションの「intrinsic gas」という。そのため、startgasがこれよりも低く設定されると、トランザクションはただちにgas low error(ガス代が少ないためのエラー)で拒否される。startgasを高すぎる値で割り当てても問題が生じる。startgasがブロック・ガスリミットよりも高い場合、トランザクションはgas exceeded error(ガス代が高すぎるためのエラー)で拒否されるが、これはネットワークの現状でそのトランザクションが明らかにブロックに収容できないことをノードが認識するためである。ガス関連の3つ目の問題は、トランザクションの採掘時にのみ発見されるが、これはトランザクションの厳密なストレージおよび演算ニーズが実際に実行されるときにしかわからないためである。startgasが実際に必要なガス代よりも低い場合、マイナーは、当該限度額に達し次第、トランザクションの処理を停止し、それをout-of-gas failure(ガス切れによる失敗)としてブロックチェーンに記録する。そのトランザクションの影響が記録されるものの、演算処理はネットワークにより実行済みであるため、送信者のイーサ・アカウントに対してstartgas全額に基づく手数料が課金される。
リモート・プロシージャ・コール(RPC)の応答がない
トランザクションを送信するアプリケーションは、通常、リモート・プロシージャ・コールによりブロックチェーン・ネットワーク内の近傍ノードとインタラクトする。これがアプリケーションにとり問題となるのは、ノードがそれらコールに対して一時的に反応しなくなる場合であり、その場合、結果的にトランザクションは受け取られない。
残高不足
トランザクションは、トランザクションの送信時にgaspriceとstartgasの積が送信者のアカウントにあるイーサ額より大きいと、insufficient funds error(残高不足によるエラー)で拒否される。
「既知のトランザクション」エラー
提案されたトランザクションについてすでに情報を得ているかどうかをノードが識別できるようにするため、各トランザクションの属性は識別用ハッシュに含められる。ハッシュとは、それらの属性に関しては一意だが後続のトランザクションに関しては、そのトランザクションが厳密に同じ属性を有するならば同一のものとなる値である。ノードは、その保留中トランザクションリストにすでにあるハッシュと同じハッシュを伴ったトランザクションを受け取ると、known transaction error(既知のトランザクション・エラー)により、そのトランザクションを拒否する。(同じハッシュを伴った先行トランザクションがすでに採掘済みである場合も後続トランザクションは失敗するが、その場合はnonce low error(低ナンス・エラー)となる。)
5.システム障害によるトランザクション損失
ブロックチェーン・トランザクションを送信する自動システムは複数の工程を伴い、これにはトランザクション属性の追加、デジタル署名、ブロックチェーンへの送信(可能性として、その過程でサードパーティのライブラリを経由する)、および永続的ステータスおよび他のデータが含まれる。この工程を単独で管理するアプリケーションは、エラー、例外、またはサービス障害の扱いが洗練されていないと、これらの工程のいずれかでトランザクションまたはデータを失いやすい。
そのため、本明細書で説明するブロックチェーン・トランザクション・マネージャーが実装されるまで、ブロックチェーン・ネットワーク、例えばイーサリアムを使用するアプリケーションは、ブロックチェーン・ネットワーク・トランザクションの受理(「採掘」)の停止とその待機に直面していた。トランザクションは、注意を要するトランザクション採番(「ナンス」)のほか、頻発する再プログラミング単位コスト見積り(「ガス代」)によるトランザクション手数料で、ブロックされてしまう場合もある。また、アプリケーションは、すべてのブロックチェーン・ネットワーク・トランザクション・エラーも扱わなければならなかった。
ブロックチェーン・トランザクションの課題に対するソリューション
本明細書で説明するブロックチェーン・トランザクション・マネージャーは、キューと、ブロックチェーン・ネットワークの状態に応答してトランザクションを準備し各々の属性を繰り返し調整し、トランザクション・ステータスを学習するためネットワークをポーリングするアルゴリズムとを組み合わせたものにより上記の課題に対処する。これらの能力は、並列性と、エラー後の自動再送信とを可能にする。
1.非同期的な並列トランザクション処理
実施形態例において、前記ブロックチェーン・トランザクション・マネージャーは、キューされたトランザクションのロバストなパイプラインを使ったのち、ネットワークをポーリングしてトランザクションの成否を追跡することにより、上記の主要な課題の2つに対処する。これにより、ユーザー・アプリケーションは、最終的な確定を待つことなくトランザクションを送信することができる。また、各工程の後続キューが当該工程の処理の成否確定までトランザクションを保留することによるトランザクションの損失も排除する。前記キュー・パイプラインは、初回送信と、gasprice、ナンス、およびgaslimitなどの属性の追加と、デジタル署名と、ネットワーク確定とを仲介する。キューは、再試行および失敗のレポーティングも管理する。
もう1つの利点として、キューは、論理的に並列な処理を各工程で可能にする。前記ブロックチェーン・トランザクション・マネージャーのサービス・コンポーネントは、そのような並列性のために設計されており、必要に応じて(例えば、利用可能なナンス値を決定する場合)共有状態用のキャッシュ支援を備えている。
手動で扱う場合、ブロックチェーン・トランザクション、例えばイーサリアム・トランザクションは、通常、トランザクションの追跡に使用されるトランザクションの全特徴の「トランザクション・ハッシュ」に基づいて追跡される。例えば、トランザクション・ハッシュは、トランザクションが、必要な属性全とともにデジタル署名されてブロックチェーン・ネットワーク内のノードへ正常に送信された場合、そのノードにより計算されて戻される。一方、本明細書で説明するブロックチェーン・トランザクション・マネージャーは、部分的な(「生」)トランザクションをユーザー・アプリケーションから受理する。非同期的な処理にとって特定の属性は実際の送信の直前に計算されることが理想的であるため、これは望ましいことである。その結果、工程全体にわたって追跡すべきトランザクションに、付加的な識別子が必要になる場合があり、これには、そのトランザクションがブロックチェーン・ネットワーク内のノードにより拒否される可能性が含まれる。
前記ブロックチェーン・トランザクション・マネージャーは、アプリケーション・プログラミング・インターフェース(Application Programming Interface:API)経由、例えばHTTPリクエストを使ってデータを取得、配置、ポスト、および削除するRepresentational State Transfer(REST)API経由でトランザクションが受信された場合、汎用一意識別子(universal unique identifier:UUID-ランダム)を各トランザクションに追跡目的で割り当てる。実施形態例において、前記ブロックチェーン・トランザクション・マネージャーは、ランダムに生成されたバージョン4のUUIDsを使用する。ほとんどの実施形態では、その後トランザクションがブロックチェーン・ネットワーク内のノードにより受理されるが、その場合もトランザクション・ハッシュは生成される。また、そのハッシュは、次いでトランザクションIDに関連付けられ、コールするアプリケーション用に利用可能になる。
この非同期的なトランザクション処理は種々のプログラミング・プラットフォームを使って実施できるが、実施形態例におけるブロックチェーン・トランザクション・マネージャーのアプローチは、非同期的な処理用に強力なサポートと、ブロックチェーン・ネットワークとのインタラクトについて十分にテストされたライブラリとを備えたもの、例えばイーサリアムのブロックチェーン・プラットフォームに既存のものを1つ選択する。
2. 自動ナンス割り当て
前記ブロックチェーン・トランザクション・マネージャーは、配慮の行き届いた着信トランザクションへのナンス自動割り当てにより、上述したナンス関連の課題を最小限に抑える。ナンスの計算は、同じアカウントからの複数のトランザクションが同時に処理される場合、特に重要になる。例えば、イーサリアム・ネットワークがトランザクションをブロードキャストするのは、そのナンスが整数値で、ネットワークに通信された直前のトランザクションのナンスより1だけ大きい場合に限られる。同じナンスが複数のトランザクションに割り当てられた場合、イーサリアム・ブロックチェーン・ネットワークは、どれでも最初に受信したものを受理し、残りを拒否する。
ブロックチェーン・トランザクション・マネージャーの実施形態例におけるナンス割り当てアルゴリズムは、以下の工程を実施することにより、これらの状況を防ぐ。
1)同じアカウントおよびネットワーク用の複数のトランザクションが、前記ブロックチェーン・トランザクション・マネージャーにより並列処理されている場合は、ロック機構を使い、それらトランザクションのうち、一度に1つしかナンスを計算しないようにする。
2)なお、複数の再試行後にトランザクションが失敗したら、それに割り当てられたナンスは必ずそのトランザクションに関連付けられたアカウント用の再使用可能なナンスのプールに追加される(後述)。このプールが処理中のトランザクションのアカウントに関するナンスを含まないか確認する。もしそうであれば、最低値のものを選択し、それを前記プールから除去して前記処理中のトランザクションに割り当てる。そうでない場合は、工程3へ進む。
3)所与の送信者のアカウント用のナンスをブロックチェーン・ネットワークから取得する:Nweb3
4)前記ブロックチェーン・トランザクション・マネージャーにより所与のアカウントに前回割り当てられたナンスを取得する:Nred
5)工程4のナンスから工程3のナンスを差し引く:Nred - Nweb3 。その差がナンス・ウィンドウより大きい場合(上記のノード属性定義を参照)、工程3のナンスを選ぶ。すなわち、Nred - Nweb3 > ナンス・ウィンドウの場合、N = Nweb3
6)それ以外の場合は、工程3と工程4のナンスを比較し、値の大きいほうを選択する。すなわち、Nred > Nweb3の場合、N=Nred 。それ以外の場合は、N=Nweb3
7)当該トランザクションのデジタル署名の直前に、工程2と同様な確認を繰り返して、確実に利用可能な最小ナンスが使用されるようにする。工程1~6で割り当てられたナンスより低い値を前記プールが含む場合、前記割り当てられたナンスを前記プール内のナンスと交換し、前記プールのナンスのほうを前記トランザクションに使用する。
3.自動実行コスト推定
トランザクション手数料を小さく若しくは大きく見積もりすぎることによる上記の難題を回避するため、前記ブロックチェーン・トランザクション・マネージャーでは、トランザクションごとに個別にコスト属性を推定する。
gaspriceは、最近ネットワークで受理されたトランザクションに関連付けられたガス価格に基づいて計算される。一実施形態例では、広く使用されているweb3ライブラリの、過去数ブロックのガス価格の中央値に基づく計算を使用できる。
一実施形態例のトランザクションに許容される最大のガス代(smartgas)の計算は、以下の工程を含む。
1)前回採掘されたブロックのブロック・ガスリミットをブロックチェーン・ネットワークから取得する:Gmb
2)トランザクションに要求される実際のガス代の推定値を取得する。(web3ライブラリは、渡されたデータ、および/またはスマート・コントラクト・コールのシミュレーション実行に基づいて、この推定を行う):Gdb
3)Gdb ≧ Gmbの場合、G = Gmb* CF0、ここで、CF0は設定可能な係数。
4)Gmb > Gdb の場合、Gの計算は、Gmb がどれだけGdb より大きいかに依存する。比R = Gmb/Gdb を計算したのち、Gを以下のように見出だす。
(R ≧ 0 AND R≦ CR1、ここでCR1 は、CR1>0の設定可能な比)である場合、G = Gdb * CF1、ここで、CF1 は設定可能な係数。
(R > CR1 AND R≦ CR2、ここでCR2 は、CR2>CR1の設定可能な比)である場合、G = Gdb * CF2、ここで、CF2 は設定可能な係数。
(R > CR2)の場合、G = Gdb * CF3、ここで、CF3は設定可能な係数。
5)トランザクションが、任意メッセージ・データを伴わないイーサ通貨送信である(すなわち、トランザクション属性に「value」(値)属性は存在するが、「data」(データ)は不在または空である)場合、startgasは設定可能なイーサ額、Gvalueである。
6)トランザクションが、任意メッセージ・データを伴うイーサ通貨送信である(すなわち、「data」(データ)も「value」(値)も存在する)場合、startgasは上記の工程4で算出されたガス代と、工程5の設定可能な値、Gvalueとの和である。すなわち、startgas = Gvalue + G 。
一度計算されると、これらの属性が生トランザクションに追加され、次いでデジタル署名および指定されたブロックチェーン・ネットワークへの送信へと進む。
4.トランザクションの準備および送信の再試行
前記ブロックチェーン・トランザクション・マネージャーは、ブロックチェーン・ネットワーク内のノードにトランザクションを送る工程を、2段階に分ける。その1つ目はトランザクションの準備で、これには、ナンスおよびコスト属性の追加が含まれる。2つ目は送信で、これには、前記トランザクションへのデジタル署名と、ブロックチェーン・ネットワーク内のノードへの引き渡しが含まれる。これらの工程のどちらかを行っているときに問題が生じた場合、前記ブロックチェーン・トランザクション・マネージャーの最初の対処戦略は、単なる再試行アプローチである。システムは、各工程に設定可能な回数に達するまで、単にトランザクションの準備または送信を再試行する。
どちらかの段階で最大再試行数を超えると、そのトランザクションはエラー・キューに入れられる。意図的な遅延後、そのトランザクションは、再度の準備および送信用に戻される。ブロックチェーン・ネットワーク内のノードによる拒否により成功しなかったものは、後述するようにカスタマイズされた付加的なハンドリングを受ける。
5.拒否されたトランザクションの扱い
ブロックチェーン・ネットワーク内のノードに繰り返し拒否されたトランザクションの扱いは、第1に、トランザクションのナンスが使用されていないことによる将来的な問題を回避することと、第2に、可能であれば拒否の原因に対処することを伴う。このセクションでは、これらの処理に関する前記ブロックチェーン・トランザクション・マネージャーのアプローチについて説明する。
自動ナンス再割り当て
ブロックチェーン・ネットワーク内のノードによりトランザクションが拒否されると、それに割り当てられたナンスは、送信者のブロックチェーン・アイデンティティ用に前記ノードが受け取ったナンスのリスト内のシーケンスには現れない。そのため、前記ノードが、その後、後続ナンスを伴う後続トランザクションだけを順次受信しても、このトランザクションのナンス数値を飛ばすことになってしまい、上述したナンス・ギャップが生じる。この問題を回避するため、拒否されたトランザクションのナンスは、ただちに前記ブロックチェーン・トランザクション・マネージャーのインメモリ・キャッシュリストに書き込まれる。そのような最低数値のナンスは、次いで上述のように、前記送信者のために準備される次のトランザクションに使用される。これにより、ナンス採番のいかなるギャップも早急に埋められる。
トランザクションが拒否された原因が対処された場合も、そのトランザクションが最初に割り当てられたナンスとともに再び送信されることはない。その代わり、再送信用にデジタル署名が再び行われる前に、自動ナンス割り当てが再度行われる。この工程は、後述する理由によるものを含め、再試行を繰り返した後にトランザクションが失敗したすべての場合に行われる。
自動startgas再計算
ブロックチェーン・ネットワーク内のノードに送信されたときにgas low(ガス代が少ない)またはgas exceeded(ガス代が高すぎる)ためのエラーで拒否されるトランザクションでは、スケジュールされた遅延後に再び準備および送信されるときstartgasを調整することで、拒否に対処される。調整で増減される額は、当該システム用に設定可能なパーセンテージ係数に基づき、例えば、ガス代が少ない場合は20%増、ガス代が高すぎる場合は10%増である。
遅延とレポーティングにより対処される拒否
「RPC not responding」(RPCの応答なし)または「insufficient funds」(残高不足)で拒否されるトランザクションの場合、前記ブロックチェーン・トランザクション・マネージャーは、根本的な原因は時とともに対処されると想定する。トランザクションは、エラー・キューへの書き込み以外、何のアクションも講じられないため、待ち時間後に再び準備および送信される。ただし、前記理由はトランザクションのステータスとともにデータベースに書き込まれ、これによりユーザーのアプリケーションによる監視が可能になる。
ナンス変更による「既知のトランザクション」拒否の扱い
上述のように、「known transaction」(既知のトランザクション)による拒否は、トランザクションがすでに送信されたものと同一のときに起こる。前記ブロックチェーン・トランザクション・マネージャーの実施形態例では、この原因を、偶然同一である2つのトランザクションに、同じナンスが割り当てられたものと想定する。(前記ブロックチェーン・トランザクション・マネージャーが所与の送信者に関する全トランザクションを扱っている場合、この状況は、非常にまれなはずであるが、より複雑な状況では生じる可能性がある。)これに対する解決策は、前記トランザクションから重複したナンスを除去し、適切なものを新たに割り当てることである。いずれにしても、これが起こるのは、トランザクションがエラー・キューに送信されたのち、再度準備され、再送信される場合であるため、すべての拒否に提供されるハンドリングを超える付加的なハンドリングは不要である。
6.トランザクション・ステータスのポーリング
ユーザー・アプリケーションがトランザクションを非同期的に送信できるようにした場合、完全に自動化したトランザクション・マネージャの2つ目の重要な要件は、前記トランザクションがブロックチェーン・ネットワークにより実行されたことと、その実行が成功したか失敗したかを確認することである(そのトランザクション自体の趣旨の観点から)。一般に、この追跡で観察されるのは、2つの状況のうち1つであり、その1つは、一般的なトランザクションが比較的短く予測可能な時間内に採掘される状況(例えば、数秒、主な公共イーサリアム・ネットワークの場合、現在1、2分、または他のプラットフォームの場合は可能性としてより長時間)、もう1つは、ネットワークまたはトランザクション自体の問題で採掘が著しく遅れる状況である。これを予測し、前記ブロックチェーン・トランザクション・マネージャーは、2つの別個のステータス・ポーリング・アプローチを実装している。その1つ目は、より集中的なものである。ノードへの送信後、トランザクションの記録は、はじめのうち、最近送信された他のトランザクションの記録とともにキューに保持される。その各々は順番に取得され、ブロックチェーン・ネットワーク内のノードは、前記トランザクションが採掘済みか確認するためのクエリーを実行する。そうである場合は、前記採掘の結果に基づいて適切なアクションが講じられる。そうでない場合、前記トランザクションは、設定可能な再試行の上限に達するまで、集中的なポーリング(例えば、1分に2回)を繰り返すため再試行キューに入る。その時点で、前記トランザクションは、ジョブ・スケジューラに基づき、第2のポーリング・アプローチへと送られる。前記スケジューラは、集中的なポーリングが再び試行される前に、時間遅延を導入する。2フェーズのスケジュールがサポートされており、例えばスケジューリングの再ポーリングを5分間ごとに5回まで行い、その後はポーリングにより前記トランザクションが採掘されたことが示されるまで1時間に1回無期限に行う。これにより、ネットワーク資源の使用と、トランザクション・ステータスのタイムリーなレポーティングとの間のバランスをとることができる。
7.データベース障害の扱い
データベース可用性の中断は、上記で言及された潜在的なシステム障害源の1つである。前記ブロックチェーン・トランザクション・マネージャーは、トランザクション・ライフサイクルのどこで中断が起こるかに応じて、この可能性を異なる態様で扱う。ほとんどの場合、この扱いは、それに後続するデータベースのアクティビティ、例えばエラー・テーブルへのトランザクションの書き込みを伴う。それらの書き込みが、広範囲のデータベース非可用性により不可能な場合、情報は、異なる場所(本実施形態例ではテキストファイル)に一時的に書き込まれ、その後エラー・ハンドリング・ルーチンがデータベースにてステータス更新を行うことができる。
APIレイヤーにおけるデータベース障害
ユーザー・アプリケーションにより生トランザクションが送信されたときにデータベースが応答しない場合、前記ブロックチェーン・トランザクション・マネージャーは、単にトランザクションの受理を拒否し、エラーのリターンコードをREST APIに提供する。
トランザクション準備中のデータベースまたはキャッシュ障害
トランザクションの準備および署名には、データベースからのブロックチェーン・ネットワーク情報の読み出しと、セキュアなストレージからのアイデンティティ・クレデンシャル取得が伴う。これら処理のいずれにおけるエラーも、設定可能な最大試行数まで、アクティビティの再試行を起こす。(キャッシュの読み出しは例外である。キャッシュを読み出せない場合は、代わりにセキュアなストレージが読み出される。)設定可能な最大反復数を越えてエラーが続くと、それに続く扱いは各問題に依存する。ネットワーク情報のルックアップ中にエラーが起こると、そのトランザクションはエラー・テーブルに書き込まれ、スケジュールされた遅延後に再試行される。他の全エラーについては、トランザクションがエラー・テーブルに書き込まれるものの、自動的には再試行されない。前記トランザクションは、後述するように、管理者からETMコンソールを介して手動で再試行できる。
ブロックチェーン・ノードへの送信後のデータベース障害
ブロックチェーン・ネットワーク内の近傍ノードがトランザクションを受理すると、前記ブロックチェーン・トランザクション・マネージャーは、その詳細を、その送信時のステータスとともにデータベースに記録する。何らかの理由でそれができない場合、そのトランザクションは、問題が生じた旨とともにエラー・テーブルに書き込まれる。その後は、ETMコンソールを介して手動で再試行できる。
ポーリング後のデータベース障害
データベース更新は、ポーリングの各ラウンド後に行われる―これは、トランザクションが採掘された旨を示す受信が得られたことを反映させるため、または最大再試行数を超過し、そのポーリングの再試行は遅延後に行うべきであることを記録するためのいずれかである。前記一実施形態例では、前記データベースが利用できない場合、これらの書き込みは、データベースが再び利用可能になるまでの保留措置としてローカル・テキストファイルに行われ、データベースが再び利用可能になった時点で、当初の意図どおりに情報が前記データベースに書き込まれる。
エラーが起こったトランザクションのスケジューリング中におけるデータベース障害
一実施形態例では、キューの代わりにデータベースを使って、エラー・ハンドリングを必要とするトランザクションを保持する。それらのトランザクションの定期的な検索中に生じるデータベース問題は、すべてログされる。前記トランザクションを検索するための定期的試行は継続的に行われるため、一時的な問題は、システム管理者が手動でログされた問題に対処したのち自己修復される。
8.トランザクションのバルク処理
トランザクションを非同期的に処理および監視する能力を考慮すると、クライアント・アプリケーションがトランザクションをバルク送信する能力は、適切な利便性であり、前記ブロックチェーン・トランザクション・マネージャーでサポートされている。
そのため、本明細書で説明するブロックチェーン・トランザクション・マネージャーでは、トランザクションが準備されるとき、ブロックチェーン・ネットワーク内の近傍ノードとの接続が受理可能になると、ブロックチェーン・ネットワークの送信用トランザクションをキューに入れることにより、従来のブロックチェーン・ネットワークの課題に対処する。ナンスは、自動的に割り当てられてブロッキングを防ぎ、前記ブロックチェーン・ネットワーク・トランザクション・ステータスは定期的にポーリングおよび取得される。また、ガス代は、最新の状態に基づいて自動的に割り当てられる。ブロックチェーン・ネットワーク・エラーの多くは、自動的に扱われ、自動的に扱えないエラーについてはレポーティングが提供される。
実施形態例
概要
前記ブロックチェーン・トランザクション・マネージャーの機能は、各トランザクションのライフサイクルの種々の段階でブロックチェーン・トランザクションにアクションをとることができる一連のサービス・コンポーネントの組み合わせによって達成され、これには、障害および拒否状況への対処が含まれる。また、これらのコンポーネントは、ブロックチェーン・ネットワーク(例えば、イーサリアム)とインタラクトして、トランザクションを送信し、その各々のステータスを追跡する。一連の永続的メッセージ・キューは、それらのサービス・コンポーネントによりトランザクションの保留アクションまたは確定を保持し、インメモリおよび永続的データベースは、前記サービス・コンポーネントの作業に必要とされる、関連性の高いブロックチェーン・アイデンティティの情報とそのトランザクションを保持する。システムは、主にブロックチェーン・トランザクションを生成または追跡する必要があるアプリケーションの要求に応えることを目的としている。この目的のため、プログラミング言語に依存せずサービス・コンポーネントにアクセス可能なREST APIが提供される。また、APIは、ブロックチェーン・トランザクション・マネージャー機能のサブセットへの人間ユーザーによる直接的なアクセスを提供するウェブ・サーバーで若しくはローカル・マシンのサービスとしてデプロイされるブラウザベースのフロントエンド「コンソール」ウェブ・アプリケーションに、サービスを提供する。
図1は、ブロックチェーン・トランザクション・マネージャー100が一実施形態例でデプロイされた場合に、これを使用する文脈のブロック図を例示したものである。例示した実施形態例において、このブロックチェーン・トランザクション・マネージャー100は、イーサリアム・トランザクション・マネージャー(Ethereum Transaction Manager:ETM(商標))として構成され、近傍ブロックチェーン・ノード110および複数のブロックチェーン・ノード155を含むイーサリアム・ブロックチェーン・ネットワークにインターフェース接続する。上記のように、他種のブロックチェーン・ネットワークと併用した場合、前記ブロックチェーン・トランザクション・マネージャー100は、前記他種のブロックチェーン・ネットワークの各前記ノードにインターフェース接続する。図示したように、当該ブロックチェーン・トランザクション・マネージャー100は、以下さらに詳しく説明するように、デプロイされたETM(商標)コンソール120と、デプロイされたETM(商標)アプリケーションおよびサービス130とを含む。当該ブロックチェーン・トランザクション・マネージャー100は、ユーザーのブラウザ140および/またはユーザーのコンピュータ上のブロックチェーン・トランザクション生成アプリケーション150により生成されるブロックチェーン・トランザクション用のノード110および155を含むイーサリアム・ブロックチェーン・ネットワークに対し、REST API駆動のインターフェースとして機能する。
キューおよびサービス・コンポーネント
上述のように、前記ブロックチェーン・トランザクション・マネージャー100の機能の大部分は、メッセージング・キュー経由でサービス・コンポーネントへ向かうトランザクションのライフサイクルに基づいており、前記サービス・コンポーネントは、ローカルであっても、選択されたイーサリアム・ネットワークにおいても、アクションを講じることができる。ハイレベルにおけるコンポーネント、キュー、各々の目的、およびトランザクション・フローを、以下の表1に記載する。
Figure 2022532464000002
表2で説明するキューは、これらのコンポーネントに、扱うべきトランザクションを供給する。キューの使用は、前記ブロックチェーン・トランザクション・マネージャー100がトランザクションを並列処理する能力に貢献し、別個のコンポーネントおよびインフラストラクチャを、トランザクション・ライフサイクルの異なる段階で使用できるようにする。
Figure 2022532464000003
図2は、前記ブロックチェーン・トランザクション・マネージャー100の前記サービス・コンポーネント(表1)およびキュー(表2)を通じたトランザクションの全体的な動きを、メッセージ・キューの観点から例示したものである。これらの動きに関わるアクティビティのほか、各フローに伴うデータ形態の詳細は、前記ブロックチェーン・トランザクション・マネージャー100の処理に関して以下でさらに詳しく説明していく。なお、トランザクションは、キューではなくデータベースを介してETM_Schedulingへ流れるため、図2では、このサービス・コンポーネントに向かう着信トランザクションの流れが示されていないことに注意すべきである。
持続性とキャッシング
上記で概略説明したトランザクションのライフサイクルは、種々のポイントにおけるサデータベースによりポートされる。それらのデータベースには、以下のものが含まれる。
永続的リレーショナル・ストレージ
用途:ユーザーから受信され、システムにより合成され、またはイーサリアム・ネットワークからポーリングされるトランザクション関連の情報は、すべて永続的リレーショナル・ストレージに保管される。これは、前記ブロックチェーン・トランザクション・マネージャー(イーサリアム・ブロックチェーン・ネットワークの場合、イーサリアム・トランザクション・マネージャー(ETM(商標))100)トランザクション・ライフサイクルにおける各トランザクションのステータスを含む。プライベート・ブロックチェーン・キーは、このストレージから除外される。
キーのためのセキュリティ強化ストレージ
目的:ブロックチェーン・トランザクション・マネージャーを使用するアプリケーションは、送信するトランザクションに関連付けられることになるイーサリアム・アイデンティティごとに、パブリック-プライベート・キーのペアをシステムに提供する。これは、前記ブロックチェーン・トランザクション・マネージャー100がトランザクション属性を追加または修正した後で、そのトランザクションにデジタル署名できるようにするうえで望ましいことである。それらのキーのストレージには、付加的なセキュリティと単離が必要である。ETM(商標)などのトランザクション・マネージャーの実施者は、望ましいレベルのセキュリティに基づいて、任意の暗号化されたオブジェクト・ストアを使用でき、または前記ブロックチェーン・トランザクション・マネージャーがハードウェアまたはソフトウェアベースの専用セキュア・キー・ストレージを使用するようにできる。
インメモリ・キャッシング
目的:ブロックチェーン・ネットワーク接続情報、送信者のアイデンティティ、および各アイデンティティのナンス割り当てを含む読み出されたデータ要素を、繰り返しキャッシングすることにより性能を向上させる。
ユーザーおよびアプリケーションのアクセス管理
セキュリティは、キー管理およびトランザクション署名を除き、トランザクション管理とは関連性の低い懸念事項である。各ユースケースのセキュリティ・ニーズを考慮し、通常の最適実施例が適用される。以下、実施形態例で使用されるアプローチを概説する。
アクセス管理には、2つの別個のアプローチが使われる。第1に、REST API経由でユーザー・アプリケーションが直接利用できる機能は、アイデンティティ管理システムを使って認証される。前記ブロックチェーン・トランザクション・マネージャー100自体が認識するためのアイデンティティとそれに伴うクレデンシャルは、アイデンティティ・システムで作成される。前記クレデンシャルは、前記ブロックチェーン・トランザクション・マネージャー外の工程でこのAPIを使用する権限がある任意のユーザー・アプリケーションと共有され、各APIコールにより前記ブロックチェーン・トランザクション・マネージャー100に供給されて戻される。第2に、前記ETMコンソール120によりアクセスされる機能は、別個のジェイソン・ウェブ・トークン(JSON Web Token:JWT)ベースの認証方法を使用する。これにより、デプロイメント中に設定される、前記ETMコンソールの唯一の管理者アイデンティティにより、追加利用者を作成できるようになる。どちらの方法でもアクセス可能な機能、例えばトランザクション・ステータスの取得は、どちらの方法でも認証でき、これを可能にするため、2つの別個のAPIエンドポイントによりサービスが提供される。
ETMコンソール
表3は、前記ETMコンソール120から利用できる機能を示したものである。トランザクションとそのステータスを読み出す場合を除き、これらの機能は、REST APIを介して接続しているユーザー・アプリケーションからは利用できない。
Figure 2022532464000004
ブロックチェーン・トランザクション・マネージャーの構成
以下では、前記システムの構成に関して、デプロイメント前に存在する設計と構成に焦点を置いた詳細(すなわち、静的アーキテクチャ、事前定義されたデータ・スキーマ、およびスタートアップ前の構成)を、図3~図9を参照して説明する。なお、ストレージおよびキューイングについて言及した技術はプレースホルダーであることに注意すべきである。当業者であれば、性能に関する他の考慮事項に基づき、各々に代替技術を選択できることが理解されるであろう。
図3は、一実施形態例における前記ブロックチェーン・トランザクション・マネージャー100のコンポーネントのブロック図を例示したものである。例示したように、前記ETMコンソール120は、REST API 300を介して前記デプロイされたETMアプリケーションおよびサービス130と通信し、これらは転じて、例示したアプリケーションおよびサービス・コンポーネントと通信する。そのようなコンポーネントとしては表1で説明したものがあり、これにはETM_App 130、ETM_TxHandler_Service 305、ETM_Polling_Service 310、およびETM_Scheduling_Service 315が含まれる。これらのコンポーネントはサブシステムも含み、これにはメッセージング・キュー・サブシステム320、永続的リレーショナルデータベース325、およびインメモリ・データベース330が含まれる。前記コンポーネントは、これら技術のためのサポート・ライブラリ、例えば前記実施形態例のもの、すなわちキュー・サポート・ライブラリ335、オブジェクト関係マッピング340、リレーショナルデータベース・サポート345、およびインメモリ・データベース・サポート350を含むこともできる。前記コンポーネントは、ブロックチェーン・ネットワーク・ピア・デバイス370とのインタラクションに、ブロックチェーン・サポート・ライブラリ360を使用することもできる。これらのコンポーネントについては、以下でさらに詳しく説明する。
コンソールの静的な構成
以上概説したように、前記ETMコンソール120は、ブロックチェーン・トランザクション・マネージャー機能のサブセットへのアクセスを人間のユーザーに提供するアプリケーションである。前記ETMコンソール120の構成に関するハイレベルの概要を図4に例示する。
図4は、一実施形態例における前記ETMコンソール120のブロック図を例示したものである。図示するように、前記ETMコンソール120は、一実施形態例において、パッケージ、例えばウェブ・ユーザーインターフェース・フレームワーク400、ウェブ・ユーザーインターフェース・スタイリング用のパッケージ410、およびユーザーインターフェースのイベントとAPIレスポンスを操作するパッケージ420を含む。図に略示したホーム画面(430)、サービス(440)、およびインターセプター(450)用の≪フォルダ≫定型パッケージは、実行時に解釈されて前記REST API 300と通信するコードファイルのセットを含む。解釈される言語によくあるように、これら個々のファイルは、サービス・コンポーネント自体のレベルに達するまで、適正にコンポーネントと見なせる、粒度の最も高いコード単位である。そのため、サブコンポーネントの代わりにフォルダ編成を示している。他の実施形態では、コンパイルされた、または他の任意の形態でコードを使用できる。
ETMアプリケーションの静的な構成
図5は、一実施形態例における前記ETMアプリケーション130のブロック図を例示したものである。前記ETMアプリケーション130は、前記システム100にRESTエンドポイントを提供し、第1のキューに向かうトランザクションのパイプである。ETMアプリケーション130の一実施形態例は、言語、例えば、ウェブ・アプリケーション・フレームワーク・パッケージのサポートを備えたウェブ・アプリケーション・サーバーの文脈での用途に適したNode.js(登録商標)でコードされる。図5は、その実装と依存性の重要な要素を示している。図4に示した依存性は、ここでは、または以下で説明するその他のサービス・コンポーネントでは、繰り返されない。キューへのパブリッシュおよびキューからの消費のため、ならびにデータベースとインタラクトするためのサポート・コードも存在するが、ここでは、または前記サービス・コンポーネントのいずれについても、説明を容易にするため示していない。
図5に例示するように、前記ETMアプリケーション130は、前記REST API 300とインタラクトし、ウェブ・アプリケーション・フレームワーク・パッケージ500と、アイデンティティ/アクセス管理ソフトウェア510と、アイデンティティ・クレデンシャルを暗号化する暗号化ライブラリ・パッケージ520と、アクセス・トークン・サポート・パッケージ530とを使用する。ここでも、ルート(REST APIs)540、サービス(コア機能)550、モデル(データ・エンティティ)560、およびキュー・イベントを扱うjobQueues/jobHandlers 570用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。
トランザクション・ハンドリング・サービスの静的な構成
図6は、ETM_TxHandler_Service 305の一実施形態例を例示したものである。このETM_TxHandler_Service 305は、種々のキューからトランザクションを消費し、各々のライフサイクル段階に適切な場合、それらを操作する。前記ポーリングおよびスケジューリング・サービス・コンポーネントと同様、前記ETM_TxHandler_Service 305は、露出したAPIを伴わないウェブ・アプリケーションとして実装されてきた。図示するように、当該ETM_TxHandler_Service 305は、ウェブ・アプリケーション・フレームワーク600と、ブロックチェーン・トランザクション署名サポート・ソフトウェア610と、インメモリ・データベース・レコード・ロック・サポート・ソフトウェア620と、を含むパッケージを使う。ここでも、モデル(データ・エンティティ)630、サービス(コア機能)640、およびキュー・イベントを扱うjobQueues/jobHandlers 650用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。「サービス」フォルダ640は、適切な場合にトランザクションを演算する論理を含むことが理解されるであろう。
これは、ブロックチェーン・ネットワークにトランザクションを送信する1つのコンポーネントであるため、デジタル署名用のライブラリ(ブロックチェーン・トランザクション署名サポート610)および一時的にキャッシュ・エントリをロックするライブラリ(インメモリ・データベース・レコード・ロック・サポート620)を使用する。後者は、ナンス割り当ての衝突を回避するうえで使用される。
ポーリング・サービスの静的な構成
図7は、ETM_Polling_Service 310の一実施形態例を例示したものである。ETM_Polling_Service 310は、ブロックチェーン・ネットワークに送信されたトランザクションのステータスを追跡する。また、ETM_Polling_Service 310の実施形態例は、ウェブ・アプリケーション・フレームワーク・パッケージ700を使って実装される。ここでも、モデル(データ・エンティティ)710、サービス(コア機能)720、およびキュー・イベントを扱うjobQueues/jobHandlers 730用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。トランザクションの属性がブロックチェーン台帳内の採掘済みブロックに最終的に見つかった場合、付加的なソフトウェア・パッケージ(図示せず)により前記属性の構文解析が容易になることが理解されるであろう。
スケジューリング・サービスの静的な構成
図8は、ETM_Scheduling_Service 315の一実施形態例を例示したものである。ETM_Scheduling_Service 315は、実行時間の長い定期的な工程を扱う。日時順ジョブ・スケジューリング・サポート・ソフトウェア・パッケージ800は、実施形態例における日時順のジョブ・スケジューリングを容易にする。また、ETM_Scheduling_Service 315の実施形態例は、ウェブ・アプリケーション・フレームワーク・パッケージ810を使って実装される。ここでも、モデル(データ・エンティティ)820、サービス(コア機能)830、およびjobQueues 840用の≪フォルダ≫定型パッケージは、一般に、実行時に解釈されるコード・ファイルのセットを含むが、異なる言語および実行モデルで実装することもできる。
データベースおよびキュー・エンティティ・スキーマ
前記ブロックチェーン・トランザクション・マネージャー100で永続的ストレージおよびキュー・ストレージ用に定義されるスキーマであって、トランザクション管理に関するものを、以下の表4に例示する。前記永続的データベースと併用されるこれらスキーマの目的としては、サービス・コンポーネント間で移動中の、特に先入れ先出しキューが不要なETM_Scheduling_Serviceに向かうトランザクション用のキューの代わりに、トランザクションと各々の進捗状況の永続的レコードを各々のライフサイクルにわたり提供し、呼び出しアプリケーションと、ユーザーと、ブロックチェーン・ネットワークおよびノードとの属性を保管することなどがある。
本質的に、キュー内のトランザクションを表現するうえでも、同じスキーマが使用される(一実施形態例ではJSONオブジェクトとして)。以下の表4と図9は、トランザクション処理に直接関係する5つのエンティティについて説明したものである。
Figure 2022532464000005
以下では、トランザクション管理に重要なフィールド値について説明する。
REST APIデータ・スキーマ
ETM_Appサービス・コンポーネント130は、前記REST API 300を介して、前記システムとの間で種々のデータ・オブジェクトを渡す。以下は、生トランザクションの受け取り時に予測されるJSONオブジェクトのフォーマット例である。
単純なトランザクション・リクエスト:
{
"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"
}
単純なバルク・トランザクション・リクエスト(リクエストごとに最高50トランザクションをサポート):
[
{
"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は、上述した一意のトランザクション識別子であることに注意すべきである。
重要なフィールド値:Status(ステータス)
前記ブロックチェーン・トランザクション・マネージャー100において、データ・フィールドstatusは、トランザクション・ライフサイクル全体の進捗状況において粒度の粗い点を定義する。このフィールドは、エンティティ(トランザクション、コントラクト、エラー)およびコードで表示される――いずれのサービス・コンポーネントでも、/config/configs/status.json を参照。許容されるフィールド値およびそれぞれの意味を、表5に記載する。
Figure 2022532464000006
実施形態例において、前記ブロックチェーン・トランザクション・マネージャー100は、以下を含むサービス・セットをユーザー・アプリケーションに提供するNode.js(登録商標)ウェブ・アプリケーションである。
トランザクションのリクエスト受理、検証、およびキューイング、
トランザクションの価格設定、署名、および送信、
トランザクション・ステータスのポーリングおよび追跡、
スケジューリングおよび定期的なアクティビティ、
ダッシュボードおよび管理機能、および
レポートの生成およびメール送信
前記ブロックチェーン・トランザクション・マネージャー100は、ナンス管理、反復コスト見積もり、およびトランザクション・ライフサイクル マネジメントも提供する。
前記ブロックチェーン・トランザクション・マネージャーにおけるトランザクションのライフサイクル
前記ブロックチェーン・トランザクション・マネージャー100の機能の大半は、個々のブロックチェーン(例えば、イーサリアム)トランザクションが確実に成功することを目指し、または失敗に対処する(希望的には、はるかに低い頻度で)ものである。その結果、前記システムの大部分の処理は、4つのブロックチェーン・トランザクション・マネージャー・サービスおよびブロックチェーン・ネットワークを通じたトランザクションの道筋をたどることにより理解される。以下の説明では、通常のトランザクション・ハンドリング、およびトランザクション自体またはそれに関するコンポーネント動作のどちらかに伴う問題が生じた場合の代替ハンドリングに伴うアクティビティについて吟味していく。
通常のトランザクション・ライフサイクル
トランザクションがそのライフサイクルを通して進むに伴い前記システムにより実行され、トラブルのない準備および送信と、迅速な採掘と、正常な実行に係わるアクティビティを、図10に例示している。
例示するように、前記ETMアプリケーション130は、1010で生トランザクションを検証し、etm_appキューに入れる。
次に、ETM_TxHandler_Service 305が、1020で、前記生トランザクションをデキューし、その属性を準備して、前記生トランザクションを永続的キューに入れる。前記準備済みトランザクションは、1030でデキューおよびデジタル署名され、その署名済みトランザクションは、1040でブロックチェーン・ネットワークのノード110に送信される。成功応答が受信されると、前記トランザクションは1050でTx-Submittedステータスとともにデータベースに書き込まれ、ポーリング・キューに送信される。
ETM_Polling_Service 310は、1060で前記ポーリング・キューから前記トランザクションをデキューし、1070でTx-Pendingステータスとともに前記データベースを更新して、polling_retryに加える。前記ブロックチェーン・ノードは、polling_retryキュー内にある間に、1080で送信「レシート」用にポーリングされる。そのポーリング結果は、1085で評価される。前記トランザクションが未採掘であるという結果が出ると、1080でポーリングが繰り返される。前記トランザクションが正常に採掘されると、1090で前記データベースがTx-Successステータスで更新され、前記ポーリング・キューからデキューされる。これでこの工程は完了する。
ただし、この工程中には、いくつかエラーが起こりうる。以下、これらエラーの処理について説明する。
遅延されるレシート・フロー
ポーリング第1ラウンド用の設定可能な時間枠の間にトランザクションが採掘された旨が示されない場合、前記システムは、そのトランザクションを一定時間保留にしたのち、ポーリングの第2ラウンドを開始する。これを実施するため、データベース内の前記トランザクションにフラグが設定される。ETM_Scheduling Service 315は、定期的に、前記フラグが設定されTx-Pendingステータスを伴うトランザクションについて、前記データベースにクエリーを行う。設定可能な待機時間後、前記フラグはクリアされ、前記トランザクションはポーリング入力キュー、etm_tx_polling、またはetm_contract_pollingの1つにパブリッシュされる。これにより、前記トランザクションに関するポーリングが再び開始される。再度のポーリングでもレシートが得られない場合は、このフローが繰り返され、設定可能な反復回数を過ぎると遅延時間がより長くなる。未採掘のトランザクションに対するこの反復は、レシートが受信されるまで無期限に続けられる。
ETM_AppのAPIエラー応答フロー
ETMアプリケーション130によりトランザクションが前記生トランザクション・キューに入れられる際は、事前に、一握りのトランザクション関連エラー条件を認識できる。この場合、エラー応答は、前記REST API 300により戻される。この経路をとるエラーとしては、生トランザクションの検証が失敗、データベースが利用不能、およびキューが利用不能などがある。
TxHandlerの修復および再送信フロー
startgasなどのネットワーク関連トランザクション属性によりトランザクションが拒否された場合は、属性を調整して再送信できる。例えば、図11は、ETM_TxHandler_Service 305によるトランザクションの即時修復および再送信の工程1100を例示したものである。この経路で扱える問題としては、gas low(ガス代が少ない)およびgas exceeded(ガス代が高すぎる)などがある。例示したように、準備済み未署名トランザクションのうちブロックチェーン・ノード110(例えば、イーサリアム・ノード)により拒否されたものは、1110で取得され、1120でそのトランザクションにアルゴリズム修復が適用されて、トランザクション属性が修復される(例えば、startgas修正)。前記修復されたトランザクションは、1130でデジタル署名され、署名されたそのトランザクションは、1140でブロックチェーン・ノードへの送信試行が繰り返される。その後問題が起こらない場合、後者の工程は、図10の1040における正常なアクティビティ・フローの再開に対応する。
スケジューラのエラー・フローを通じた再試行
一部のエラーは、即時再送信で対処されるのではなく、遅延後の再試行で成功する場合がある。前記ブロックチェーン・トランザクション・マネージャー100において、これらのトランザクションは、待ち時間中に条件を改善したのち生トランザクションとして再キューイングするよう、スケジューリング・サービス315に送られる。図12は、一実施形態例において「再試行可能」なトランザクション・エラーを処理する工程1200を例示している。この経路で扱われるエラーとしては、insufficient funds(残高不足)、RPC not responding(RPCの応答なし)、ERM_TxHandler_Service 305における特定のデータベース・エラー、およびknown transaction(既知のトランザクション)エラーなどがある。
図12に例示するように、再試行可能なエラーにより拒否されたトランザクションはETM_TxHandler_Service 305に提供され、1210で前記ブロックチェーン・ノードへの送信が再試行される。1215で前記トランザクションが受理されると、そのトランザクションは、図10を参照して上述した通常の経路に沿って進む。前記トランザクションが再び再試行可能なエラーにより拒否された場合、ETM_TxHandler_Service 305は、1210でそのトランザクションを前記ブロックチェーン・ノードに再送信するよう試みる。これは、設定可能な再試行の上限(最大の再試行回数)を超えるまで続く。そのような場合には、1220で前記トランザクションのナンスがキャッシュに維持されて、他のトランザクションに利用できるようにし、前記トランザクションは、1230でデータベースのエラー・トランザクション・テーブルに書き込まれる。前記トランザクションは、1240で前記データベースのアクティブ・トランザクション・テーブルから除去される。
前記ETM_Scheduling_Service 315により定期的なソフトウェア・イベントが生成されることに応答し、当該サービスは、1250で前記データベースの前記エラー・トランザクション・テーブルにクエリーを行う。1260では、エラーの発生が見られたトランザクションごとに、そのトランザクションから生トランザクションが抽出され、生トランザクション・キューに入れられる。1270では、前記ETM_TxHandler_Service 305が、図10を参照して上述した通常の経路に沿って、前記生トランザクションを処理する。
トランザクション失敗経路
ポーリング工程により、トランザクションが採掘されたがその実行が失敗したことが示された場合、そのトランザクションは、図10の「採掘され、成功した」経路のようにポーリング・キューからデキューされるが、そのトランザクションのステータスは、Tx-Failed(トランザクション失敗)と書き込まれる。
アクティビティのタイミングに関する要約
図13は、上述したアクティビティ経路をハイレベルでまとめたもので、前記システムがどこで意図的に時間遅延を導入するかに主眼を置いている。例示するように、ユーザー・アプリケーション150から受信されたトランザクションは、前記ETMアプリケーション130に提供され、その生トランザクションは、1300で検証される。前記検証された生トランザクションは前記ETM_TxHandler_Service 305に提供され、これが1310で前記トランザクションを準備する。前記REST API 300は、これらの処理用に時間遅延およびretry_countを提供する。前記遅延は、トランザクション準備の各再試行前に、前記ETM_TxHandler_Service 305により意図的に処理に導入されて、問題を誘発している状態がそれ自体により解消されるようにする。提供された再試行回数を超えた後も前記トランザクションが適切に準備されない場合、そのトランザクションは、1315でETM_Scheduling_Service 315に送信され、指定された時間後に、そのトランザクションの再処理が生トランザクションとしてスケジュールされる。前記トランザクションは、1310で正常に準備されると、1320でブロックチェーンに送信される。前記ETM_TxHandler_Service 305は、この処理にも、再試行ごとにretry_countおよび意図的な遅延時間を提供する。前記トランザクションが適切に準備されず、提供された再試行回数を超えると、そのトランザクションも同様に1315でETM_Scheduling_Service 315に送信され、指定された時間後に、そのトランザクションの再処理が生トランザクションとしてスケジュールされる。前記トランザクションが1320でブロックチェーンに送信されると、前記ETM_Polling_Service 310が1330でレシートについてポーリングし、1340でトランザクションの成否を記録する。また、ポーリング時間の制限も提供される(例えば、5000ms、または指定された最大再試行回数)。ポーリングが前記最大再試行回数を超えると、前記ETM_Scheduling_Service 315は、1350で再ポーリングをスケジュールする。例えば、例示したように、この再ポーリングは、最初の数分間に数回試行され、その後は、より長い間隔で再試行される。再度のポーリングでもレシートが得られない場合は、このフローが繰り返され、設定可能な反復回数を過ぎると遅延時間がより長くなる。未採掘のトランザクションに対するこの反復は、レシートが受信されるまで無期限に続けられる。そのため、特定の状況において、トランザクションは、正常に処理されるまで保持され、一定時間後に再試行される。
ETM内のキューに関する追加情報
以上、トランザクションのライフサイクルにおけるキューの役割について説明してきたが、それらキューの内容とその用途について図2よりも詳しく理解すると有用であろう。
各キューの内容は、何らかの形態のトランザクションである。それらにパブリッシュされるオブジェクトを記述するスキーマは、そのトランザクションが生か、準備済みか、エラー状態かに応じて、かつ、単純なトランザクションか、スマート・コントラクト・トランザクションかに応じて異なる。表6は、これらオブジェクトの1つがキューまたはデキューされる際のパブリッシュと消費の関係を一覧したものである。各キューに何が含まれているかを説明するにあたり、表6では、トランザクションのタイプとライフサイクル進捗状況を合わせた省略表現を使用している。
Figure 2022532464000007
表7では、表6で使用したトランザクションのタイプとライフサイクル進捗状況に関する前記省略用語をさらに詳しく説明している。各タイプおよび状態のトランザクションを表現するため使用したデータ・エンティティが含まれている。
Figure 2022532464000008
Figure 2022532464000009
表7に概説された省略表現での状態名は、状態遷移モデルにおいて、上述した工程のトランザクション指向の見方を例示するうえで使用できる。
図14は、前記ブロックチェーン・トランザクション・マネージャー工程におけるトランザクションのライフサイクルを、一実施形態例に送信された単一のブロックチェーン・トランザクションについて、統一モデリング言語(Unified Modeling Language:UML)状態遷移モデル1400として視覚化し、例示したものである。例示するように、前記ETM_Appコンポーネント130は、トランザクションを受信して検証し(すなわち、そのトランザクションが有効であり、その送信者およびブロックチェーン・ネットワークが既知である)、その時点で、前記トランザクションは、システム内で初期状態にあると見なすことができ、raw_tx 1405でラベル付けされる。状態1405の前記生トランザクションは、このトランザクションに属性を割り当て、デジタル署名するため、トランザクション・ハンドラ(ETM_TxHandler_Service 305)に提供される。成功すると、前記トランザクションは、準備済みトランザクションまたは準備済みコントラクトの状態1410に入ったものと見なすことができ、その区別は、そのトランザクションが単純なトランザクションかコントラクト・トランザクションかにそれぞれ依存する。この定義は後続状態に当てはまり、そのような区別については図で説明している。前記トランザクション・ハンドラが、この状態のトランザクションをその近傍ブロックチェーン・ノード110に送信すると、そのトランザクションが正常に送信されたか、前記近傍ブロックチェーン・ノード110により拒否されたかに応じて、決定の擬似状態1415により表される2つの状態のうち1つに入ると見なすことができる。拒否されると、前記トランザクションは、エラー発生トランザクションまたはエラー発生コントラクト・トランザクションの状態1420に入る。送信されると、前記トランザクションは、送信済みトランザクションまたは送信済みコントラクト・トランザクションの状態1430に入る。1420から引き続き、前記トランザクション・ハンドラは、前記送信を再試行し、可能性として反復し、その結果が新たな状態を擬似状態1425ごとに決定する。いずれかの再試行が成功すると、そのトランザクションは、前記送信済みトランザクションまたは送信済みコントラクトの状態1430に入る。ただし、前記設定可能なMaxRetries閾値を超える回数、トランザクションが拒否されると、そのトランザクションは、unresolved_errored状態1435に入ると見なせる。このunresolved_errored状態にあるトランザクションに対し、前記スケジューラ(ETM_Scheduling_Service 315)は、当該エラーがトランザクション・ハンドラにより解決できるタイプのエラーかどうかを決定する。この決定は、決定の擬似状態1440により表される。そうである場合、前記トランザクションは、前記生トランザクションの状態1405に戻され、ライフサイクルは、その状態から継続される。一方、前記スケジューラ315が決定の擬似状態1440において、エラー・タイプが手動で対処されるべき旨を決定すると、前記トランザクションは、終了状態の擬似状態1470への遷移で表されるように、永続的に前記unresolved_errored状態1435にとどまる。
トランザクションが前記送信済みトランザクションまたは送信済みコントラクトの状態1430に入ると、前記ブロックチェーン・ネットワークは、コンポーネントETM_Polling_Service 310により、そのトランザクションのステータスについて繰り返しポーリングされる。その工程の結果が次の遷移を決定し、これは決定の擬似状態1445により表される。前記ポーリングにより前記トランザクションが採掘され失敗したことが示されると、そのトランザクションは、その最終状態である失敗したトランザクションまたは失敗したコントラクトの状態1450に入り、これは終了の擬似状態1470への遷移により表される。
一方、前記ポーリング状態1445においてポーリング中に前記トランザクションが見つからない場合、そのトランザクションは、no_receipt_transactionまたはno_receipt_contractの状態1455に入る。コンポーネントETM_Scheduling_Service 315およびETM_Polling_Service 310が連携してブロックチェーン・ネットワークで前記トランザクションのステータスをポーリングしている間は、この状態が保たれる。前記ポーリングは無期限に続くが、結果が得られると、その結果により前記トランザクションの後続状態が決定され、これは決定の擬似状態1460により表される。前記ポーリングにより前記トランザクションが採掘され失敗したことが示されると、上記のとおり、そのトランザクションは、その最終状態である失敗したトランザクションまたは失敗したコントラクトの状態1450に入り、これは終了の擬似状態1470への遷移により表される。
最後に、決定の擬似状態1445または決定の擬似状態1460のどちらかで考慮される前記ポーリングにより、前記トランザクションが採掘され成功したことが示されると、そのトランザクションは、その最終状態である成功したトランザクションまたは成功したコントラクトの状態1465に入り、これは終了の擬似状態1470への遷移により表される。
このように、本明細書で説明する前記ブロックチェーン・トランザクション・マネージャー100は、ユーザーのコンピュータからブロックチェーンまで、ブロックチェーン・トランザクションを適切に誘導するよう動作する。
コンピュータ実施形態
図15は、本明細書に開示した前記ブロックチェーン・トランザクション・マネージャー100の1若しくはそれ以上の実施形態を実施するうえで適した特殊用途コンピュータへとプログラム可能な、一般的汎用コンピュータ1500のブロック図である。上述の前記ブロックチェーン・トランザクション・マネージャー100は、任意の汎用処理コンポーネント、例えば課された必要な作業負荷を扱ううえで十分な処理能力、メモリリソース、および通信処理能力を備えたコンピュータに実装できる。前記コンピュータ1500は、メモリ・デバイスと通信可能なプロセッサ1502(中央処理装置またはCPUと呼ぶことができる))を含み、前記メモリ・デバイスは、二次ストレージ1504と、読み出し専用メモリ(ROM)1506と、ランダムアクセスメモリ(RAM)1508と、入出力(I/O)装置1510と、ネットワーク接続装置1512とを含む。前記プロセッサ1502は、1若しくはそれ以上のCPUチップとして実装でき、または1若しくはそれ以上の特定用途向け集積回路(application specific integrated circuits:ASICs)の一部であってよい。
前記二次ストレージ1504は、通常、1若しくはそれ以上のディスクドライブまたはテープドライブから成り、不揮発性データ・ストレージに使用され、RAM 1508が全作業データを保持するうえで十分大きくない場合はオーバーフロー・データ・ストレージ・デバイスとして使用される。二次ストレージ1504を使うと、RAM 1508にロードされるプログラムが実行用に選択されたとき、そのようなプログラムを格納できる。前記ROM 1506は、プログラム実行中に読み出される命令および可能性としてデータを格納するため使用される。ROM 1506は不揮発性メモリ・デバイスであり、通常、二次ストレージ1504の大容量メモリと比べて、小容量のメモリを有する。前記RAM 1508は、揮発性データを格納し、可能性として命令を格納するため使用される。ROM 1506とRAM 1508双方へのアクセスは、通常、二次ストレージ1504へのアクセスよりも高速である。
本明細書で説明するデバイスは、コンピュータ可読命令を格納するコンピュータ可読非一時的媒体と、前記メモリと結合された1若しくはそれ以上のプロセッサとを含むよう構成でき、実行時、前記コンピュータ可読命令は、図1~図14を参照して上述した方法工程および処理を実行するよう前記コンピュータ1500を設定する。前記コンピュータ可読非一時的媒体は、全タイプのコンピュータ可読媒体を含み、これには、磁気ストレージ・メディア、光学ストレージ・メディア、フラッシュ・メディア、およびソリッドステート・メディアが含まれる。
さらに、本開示の工程のいずれか1つまたは全部に関して上述した処理と演算を容易にする1若しくはそれ以上のコンピュータで実行可能な命令を含むソフトウェアは、1若しくはそれ以上のサーバーおよび/または1若しくはそれ以上のルーターおよび/または1若しくはそれ以上のデバイスにインストールでき、かつ、これらとともに本開示と一貫した消費者および/または生産者ドメインで販売できることを理解すべきである。あるいは、前記ソフトウェアは、本開示と一貫した消費者および/または生産者ドメイン内で、取得して、1若しくはそれ以上のサーバーおよび/または1若しくはそれ以上のルーターおよび/または1若しくはそれ以上のデバイスにロードでき、これには物理媒体または配信システムを介した前記ソフトウェア取得が含まれ、これには例えば前記ソフトウェアの作成者が所有するサーバーからの取得、または前記ソフトウェアの作成者が所有しないが使用するサーバーからの取得が含まれる。前記ソフトウェアは、例えばインターネットを通じた配信用に、サーバーに格納できる。
また、当業者であれば、本開示は、その用途に関し、当該説明に記載し若しくは図面に示した構成要素(コンポーネント)の構造および構成の詳細に限定されないことが理解されるであろう。本明細書の実施形態は、他の実施形態も可能であり、種々の方法で実施または実行できる。また、本明細書で使用する表現おび用語は、説明を目的としたものであり、限定的なものと見なすべきではないことが理解されるであろう。本明細書で使用する「を含む(including)」、「を有する(comprising)」、または「を有する(having)」、およびこれらの派生表現は、付随して記載された項目とその均等物だけでなく、付加的な項目も包含するよう意図されている。特に限定されない限り、本明細書における用語「接続される(connected)」、「結合される(coupled)」、「取り付けられる(mounted)」、およびこれらの変形表現は広義に使用され、直接的および間接的な接続、結合、および取り付けを包含する。また、用語「接続される(connected)」および「結合される(coupled)」、およびこれらの変形表現は、物理的または機械的な接続または結合に制限されない。さらに、用語、例えば「上へ(up)」、「下へ(down)」、「底部(bottom)」、および「頂部(top)」は相対的なものであり、例示を補足するため使用されるが、限定を意図したものではない。
例示した実施形態に基づき使用される前記例示的なデバイス(装置)、システム、および方法の構成要素は、少なくとも部分的に、デジタル電子回路、アナログ電子回路、またはコンピュータ・ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装できる。これらの構成要素は、例えば、コンピュータ・プログラム製品、例えば情報担体または機械可読ストレージ・デバイスで有形に具現化されたコンピュータ・プログラム、プログラム・コード、またはコンピュータ命令として、データ処理装置、例えばプログラム可能なプロセッサ、コンピュータ、または複数のコンピュータにより実行し、またはその動作を制御するために実装できる。
コンピューター・プログラムは、コンパイルまたは解釈される言語を含む任意形態のプログラミング言語で書き込み可能であり、スタンドアロン・プログラムとして、またはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境での使用に適した他のユニットとしてのものを含む任意形態でデプロイできる。コンピュータプログラムは、コンピュータまたは複数のコンピュータにおける、1か所、または分散され通信ネットワークで相互接続された複数か所での実行用にデプロイできる。また、本明細書で説明した技術を実施する機能的なプログラム、コード、およびコード・セグメントは、当業者プログラマであれば、本開示の範囲内であるとして容易に解釈できるであろう。前記例示的な実施形態に伴う方法工程は、機能を実行するための(例えば、入力データを計算し、および/または出力を生成することにより)コンピュータ・プログラム、コード、または命令を実行する1若しくはそれ以上のプログラム可能なプロセッサにより実施できる。また、方法工程は、特殊用途論理回路、例えばFPGA(フィールド・プログラマブル・ゲート・アレイ)またはASIC(特定用途向け集積回路)などにより実施でき、装置は、これらとして実装することができる。
本明細書に開示した実施形態に関連付けて説明した種々の例示的な論理ブロック、モジュール、および回路は、本明細書で説明した機能を実行するよう設計された汎用プロセッサ、デジタル信号プロセッサ(digital signal processor:DSP)、ASIC、FPGA、または他のプログラム可能な論理デバイス、離散ゲート、またはトランジスタ論理、離散ハードウェア・コンポーネント、またはこれらの任意の組み合わせで実装または実行できる。汎用プロセッサは、マイクロプロセッサであってよいが、代替形態において、前記プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはオートマトンであってよい。また、プロセッサは、コンピュータ装置の組み合わせ、例えばDSPおよびマイクロプロセッサ、複数のマイクロプロセッサ、1若しくはそれ以上のマイクロプロセッサをDSPコアと連動させたもの、またはそのような他の任意の構成の組み合わせとして実装できる。
コンピューター・プログラムの実行に適したプロセッサには、例として、汎用および特殊用途マイクロプロセッサの双方、ならびに任意タイプのデジタル・コンピュータの任意の1若しくはそれ以上のプロセッサなどがある。一般に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリ、あるいはその双方から命令とデータを受け取る。コンピュータの本質的な要素は、命令を実行するプロセッサ、および命令とデータを格納する1若しくはそれ以上のメモリ・デバイスである。一般に、コンピュータは、データを格納する1若しくはそれ以上の大容量ストレージ・デバイス、例えば磁気、磁気・光ディスク、または光ディスクも含むことになり、またはそれらに動作可能に結合されてそこからデータを受信し若しくはこれにデータを転送し、またはその双方を行う。コンピュータ・プログラム命令およびデータを具現化するうえで適した情報担体としては、全形態の不揮発性メモリなどがあり、これには例えば、半導体メモリ・デバイス、例えば電気的にプログラム可能な読み出し専用メモリすなわちROM(electrically programmable ROM:EPROM)、電気的に消去可能でプログラム可能なROM(electrically erasable programmable ROM:EEPROM)、フラッシュ・メモリ・デバイス、およびデータ・ストレージ・ディスク(例えば、磁気ディスク、内蔵ハードディスク、またはリムーバブル・ディスク、磁気・光ディスク、ならびにCD-ROMおよびDVD-ROMディスク)が含まれる。前記プロセッサおよび前記メモリは、特殊用途論理回路により補完でき、またはこれに組み込むことができる。
当業者であれば、情報および信号は、多種多様な技術およびテクニックのいずれかを使って表されることが理解されるであろう。例えば、以上の説明全体にわたり参照可能なデータ、命令(instructions)、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光学場または光子、あるいはこれらの任意の組み合わせにより表すことができる。
当業者であれば、さらに、本明細書に開示した実施形態に関連付けて説明した前記種々の例示的な論理ブロック、モジュール、回路、およびアルゴリズム工程は、電子ハードウェア、コンピュータ・ソフトウェア、または双方の組み合わせとして実装できることが理解されるであろう。このハードウェアおよびソフトウェアの可換性を明確に例示するため、上記では、種々の例示的な構成要素(コンポーネント)、ブロック、モジュール、回路、および工程について、各々の機能性の点で全般的に説明してきた。このような機能性がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、システム全体に課される特定の用途および設計の制約に依存する。当業者であれば、説明した機能性を種々の方法で特定の用途ごとに実装できるであろうが、そのような実装に関する決定は、本開示の範囲からの逸脱を生じると解釈すべきではない。ソフトウェア・モジュールは、ランダムアクセスメモリ(RAM)、フラッシュ・メモリ、ROM、EPROM、EEPROM、レジスタ、ハードディスク、リムーバブル・ディスク、CD-ROM、または当該技術分野で知られた他の任意形態の記憶媒体に常駐できる。例示的な記憶媒体はプロセッサに結合され、そのプロセッサが前記記憶媒体から情報を読み出し、そこに情報を書き込めるようにされる。代替形態では、前記記憶媒体を前記プロセッサと一体化できる。すなわち、前記プロセッサおよび前記記憶媒体は、集積回路に常駐でき、または離散コンポーネントとして実装できる。
本明細書において、「機械可読媒体(machine-readable medium)」とは、一時的または永続的に命令とデータを格納できる装置(デバイス)をいい、これに限定されるものではないが、ランダムアクセスメモリ(RAM)、読み取り専用(ROM)、バッファ・メモリ、フラッシュ・メモリ、光媒体、磁気媒体、キャッシュ・メモリ、他種のストレージ(例えば、消去可能でプログラム可能な読み取り専用メモリ(EEPROM))、および/またはこれらの任意の適切な組み合わせを含む。用語「機械可読媒体」は、単一の媒体または複数のメディア(例えば、一元化または分散されたデータベース、または付随するキャッシュおよびサーバー)であって、プロセッサ命令を格納できるものを含むと解釈されるべきである。また、用語「機械可読媒体」は、任意の媒体、または複数の媒体の組み合わせであって、1若しくはそれ以上のプロセッサを実行するための命令を格納でき、その命令が1若しくはそれ以上のプロセッサにより実行される際、その1若しくはそれ以上のプロセッサが本明細書で説明した方法論のうち任意の1若しくはそれ以上を実行できるようにするものを含むと解釈されるべきである。このように、「機械可読媒体」とは、単一のストレージ装置(apparatus)またはデバイスのほか、複数のストレージ装置またはデバイスを含む「クラウドベース」のストレージ・システムまたはストレージ・ネットワークをいう。本明細書における用語「機械可読媒体」は、信号自体は含まない。
以上に示した説明および図は、単なる例示目的で示したものであり、請求項に特段の断りがない限り、前記例示的な実施形態を限定することを意図したものでは一切ない。なお、上述した種々の例示的実施形態の前記種々の要素の種々の技術的態様は、その他多くの方法で組み合わせが可能であり、これらすべてが、本開示の範囲内と見なされることに注意すべきである。
そのため、例示的な実施形態を例示的目的で開示してきたが、当業者であれば、種々の変更形態、追加形態、および置換形態が可能であることが理解されるであろう。したがって、本開示は上記の実施形態に限定されるものではなく、添付の請求請求の範囲内で、ならびに各々の均等物の全範囲内で修正が可能である。

100...ブロックチェーン・トランザクション・マネージャー
110...近傍ブロックチェーン・ノード
120...ETM(商標)コンソール
130...ETM(商標)アプリケーションおよびサービス
140...ユーザー・ブラウザ
150...ブロックチェーン・トランザクション生成アプリケーション
155...ブロックチェーン・ノード
300...REST API
305...ETM_TxHandler_Service
310...ETM_Polling_Service
315...スケジューリング・サービス、ETM_Scheduling_Service
320...キュー・サブシステム
325...永続的リレーショナルデータベース
330...インメモリ・データベース
335...キュー・サポート・ライブラリ
340...オブジェクト関係マッピング
345...リレーショナルデータベース・サポート
350...インメモリ・データベース・サポート
360...ブロックチェーン・サポート・ライブラリ
370...ブロックチェーン・ネットワーク・ピア・デバイス
400...ウェブ・ユーザーインターフェース・フレームワーク
410...ウェブ・ユーザーインターフェース・スタイリング用のパッケージ
420...ユーザーインターフェースのイベントとAPIレスポンスを操作するパッケージ
430...ホーム画面
440...サービス
450...インターセプター
500...ウェブ・アプリケーション・フレームワーク・パッケージ
510...アイデンティティ/アクセス管理ソフトウェア
520...暗号化ライブラリ・パッケージ
530...アクセス・トークン・サポート・パッケージ
540...ルート(REST APIs)
550...サービス(コア機能)
560...モデル(データ・エンティティ)
570...jobQueues/jobHandlers
600...ウェブ・アプリケーション・フレームワーク
610...ブロックチェーン・トランザクション署名サポート・ソフトウェア
620...インメモリ・データベース・レコード・ロック・サポート・ソフトウェア
630...モデル(データ・エンティティ)
640...サービス(コア機能)
650...jobQueues/jobHandlers
700...ウェブ・アプリケーション・フレームワーク・パッケージ
710...モデル(データ・エンティティ)
720...サービス(コア機能)
730...jobQueues/jobHandlers
800...日時順ジョブ・スケジューリング・サポート・ソフトウェア・パッケージ
810...ウェブ・アプリケーション・フレームワーク・パッケージ
820...モデル(データ・エンティティ)
830...サービス(コア機能)
840...jobQueues
1400...統一モデリング言語(Unified Modeling Language:UML)状態遷移モデル
1405...初期状態
1410...準備済みトランザクションまたは準備済みコントラクトの状態
1415...決定の擬似状態
1420...エラー発生トランザクションまたはエラー発生コントラクト・トランザクションの状態
1425...擬似状態
1430...送信済みトランザクションまたは送信済みコントラクト・トランザクションの状態
1435...unresolved_errored状態
1440...決定の擬似状態
1445...決定の擬似状態
1450...失敗したトランザクションまたは失敗したコントラクトの状態
1455...no_receipt_transactionまたはno_receipt_contractの状態
1460...決定の擬似状態
1465...成功したトランザクションまたは成功したコントラクトの状態
1470...終了の擬似状態
1500...一般的汎用コンピュータ
1502...プロセッサ
1504...二次ストレージ
1506...読み出し専用メモリ(ROM)
1508...ランダムアクセスメモリ(RAM)
1510...入出力(I/O)装置
1512...ネットワーク接続装置
ブロックチェーン・トランザクション・パイプラインは、多くの課題に直面している。一部の課題は、ブロックチェーン・プラットフォーム全般に共通した、例えばトランザクションの送信と、それらの共有台帳での受け取り間の遅延である。他の課題は、著しくプラットフォーム特有で、例えばイーサリアム(Ethereum)におけるトランザクション「ナンス」の採番問題で起こる拒否などである。これらの問題にソリューションを提供し、前記共通した課題およびプラットフォーム特有の課題に対処する単一のインターフェースに、そのソリューションを実装することが望ましい。
この出願の発明に関連する先行技術文献情報としては、以下のものがある(国際出願日以降国際段階で引用された文献及び他国に国内移行した際に引用された文献を含む)。
(先行技術文献)
(特許文献)
(特許文献1) カナダ国特許出願公開第110245006号明細書
(特許文献2) カナダ国特許出願公開第110060161号明細書
(特許文献3) カナダ国特許出願公開第111651525号明細書
(特許文献4) 米国特許出願公開第2020/0250174号明細書

Claims (30)

  1. ブロックチェーン・ネットワーク内のノード用に意図されたブロックチェーン・トランザクションを受信し、前記ブロックチェーン・ネットワーク内のノードへの前記ブロックチェーン・トランザクションの送信を管理するブロックチェーン・トランザクション・マネージャーであって、
    ブロックチェーン・トランザクションを生成するユーザー・アプリケーションへのインターフェースを提供するトランザクション管理アプリケーションであって、前記トランザクション管理アプリケーションは、前記ブロックチェーン・ネットワークおよびトランザクションを送信するアイデンティティについて必要な情報を受信し、受信されたブロックチェーン・トランザクションを検証し、前記受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる、トランザクション管理アプリケーションと、
    トランザクション・ハンドラであって、前記ブロックチェーン・ネットワークおよびアイデンティティの情報を格納し、受信されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性を準備し、前記ユーザー・アプリケーションにより供給されたアイデンティティ・クレデンシャルを使って、前記受信されたブロックチェーン・トランザクションに対し、前記ブロックチェーン・ネットワークに適用可能であるとしてデジタル署名または認証し、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する、トランザクション・ハンドラと、
    送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスを観察および報告するブロックチェーン・ポーラーと
    を有するブロックチェーン・トランザクション・マネージャー。
  2. 請求項1記載のブロックチェーン・トランザクション・マネージャーにおいて、前記トランザクション管理アプリケーションは、前記ブロックチェーン・トランザクションを受信すると追跡目的でこれに汎用一意識別子を割り当てるものであるブロックチェーン・トランザクション・マネージャー。
  3. 請求項1記載のブロックチェーン・トランザクション・マネージャーにおいて、前記トランザクション・ハンドラは、さらに、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する試行を追跡用に追跡キューに入れ、前記ブロックチェーン・ネットワーク内のノードへ正常に送信されたブロックチェーン・トランザクションのステータス情報を格納するものであるブロックチェーン・トランザクション・マネージャー。
  4. 請求項1記載のブロックチェーン・トランザクション・マネージャーにおいて、さらに、
    前記ブロックチェーン・ネットワーク内のノードにより拒否されたトランザクションを受信し、前記拒否されたトランザクションを再試行する管理アクティビティ・スケジューラを有するものであるブロックチェーン・トランザクション・マネージャー。
  5. 請求項4記載のブロックチェーン・トランザクション・マネージャーにおいて、前記ブロックチェーン・ポーラーにより送信されたブロックチェーン・トランザクションの初回ポーリングが、設定可能な最大試行回数を超えたとき、前記管理アクティビティ・スケジューラは、前記送信されたブロックチェーン・トランザクションのステータスを追跡し続けるために、前記ブロックチェーン・ステータスのさらなるポーリングをより低い頻度で前記ブロックチェーン・ポーラーによりスケジュールするものであるブロックチェーン・トランザクション・マネージャー。
  6. 請求項1記載のブロックチェーン・トランザクション・マネージャーにおいて、さらに、
    インタラクティブなインターフェースを介して人間のユーザーによる前記トランザクション管理アプリケーションへのアクセスを提供するトランザクション管理コンソールを有し、当該トランザクション管理コンソールは、前記ユーザーのインタラクティブなインターフェースを介して、ブロックチェーン・トランザクションと各々のステータスのリストを前記ユーザーに提供するものであるブロックチェーン・トランザクション・マネージャー。
  7. 請求項6記載のブロックチェーン・トランザクション・マネージャーにおいて、前記トランザクション管理コンソールは、さらに、ブロックチェーン・トランザクションに使用するアイデンティティまたはトランザクション認証クレデンシャルを管理するものであるブロックチェーン・トランザクション・マネージャー。
  8. 請求項1記載のブロックチェーン・トランザクション・マネージャーにおいて、さらに、
    データベースであって、送信されたがまだ前記ブロックチェーン・ネットワーク内のノードに正常に書き込まれていないブロックチェーン・トランザクションを格納し、前記送信が成功しなかった理由と、前記送信されたブロックチェーン・トランザクションのステータスとを格納するデータベースを有するものであるブロックチェーン・トランザクション・マネージャー。
  9. ブロックチェーン・ネットワーク内のノードへのブロックチェーン・トランザクションの送信を管理する方法であって、
    受信されたブロックチェーン・トランザクションを検証し、その検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる工程と、
    前記受信されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性を準備し、前記受信されたブロックチェーン・トランザクションを永続的キューに入れる工程と、
    前記ブロックチェーン・ネットワークに適切であるとして、前記受信されたブロックチェーン・トランザクションにデジタル署名し、またはこれを認証する工程と、
    前記デジタル署名または認証されたブロックチェーン・トランザクションを、前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と、
    前記送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングする工程と
    を有する方法。
  10. 請求項9記載の方法において、前記ブロックチェーン・ステータスをポーリングする工程は、送信されたブロックチェーン・トランザクションの前記ブロックチェーン・ネットワークでの受理に向けた進捗状況に関する情報について、前記ブロックチェーン・ネットワーク内のノードをポーリングする工程と、望ましい進捗状況情報が受信されるまで前記ポーリングを再試行する工程とを有するものである方法。
  11. 請求項10記載の方法において、前記ポーリング工程は、期限が切れた後または最大ポーリング試行回数後、頻度が低下するものである方法。
  12. 請求項9記載の方法において、さらに、
    前記ブロックチェーン・ネットワーク内のノードに送信されたブロックチェーン・トランザクションの送信が、前記ブロックチェーン・ネットワークにより前記トランザクションが受理される結果になったかどうかを、前記ブロックチェーン・ネットワークに適した基準に基づいて示す応答を受信する工程を有するものである方法。
  13. 請求項12記載の方法において、さらに、
    前記送信されたブロックチェーン・トランザクションを、前記送信されたブロックチェーン・トランザクションのステータスとともにデータベースに書き込む工程を有するものである方法。
  14. 請求項13記載の方法において、前記送信されたブロックチェーン・トランザクションの前記ステータスが、前記送信が成功しなかったことを示した場合、さらに、前記送信が成功しなかった理由を前記データベースに格納するものである方法。
  15. 請求項14記載の方法において、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記拒否されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性に修復アルゴリズムを適用して修復されたブロックチェーン・トランザクションを作成し、前記修復されたブロックチェーン・トランザクションにデジタル署名し、前記修復されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行するものである方法。
  16. 請求項14記載の方法において、前記送信されたブロックチェーン・トランザクションが、再試行可能なエラーにより前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、受理されるまで若しくは再試行の上限を超えるまで、前記送信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに再送信するものである方法。
  17. 請求項16記載の方法において、前記再試行の上限を超えた場合、格納された利用可能なトランザクション・ナンスのプールにナンス値を追加することにより前記トランザクションのナンスの可用性を示す工程と、データベース内のエラー発生トランザクション・テーブルに前記送信されたブロックチェーン・トランザクションを書き込む工程と、最初に送信された生ブロックチェーン・トランザクションを抽出して、その生ブロックチェーン・トランザクションが再び準備され、新規受信されたトランザクションと同じ工程を使って送信されるようにする工程とのうち少なくとも1つを実行するものである方法。
  18. 請求項9記載の方法において、さらに、
    前記ブロックチェーン・ネットワークがトランザクション・ナンス機構を含む場合、前記受信されたブロックチェーン・トランザクションにナンスを自動的に割り当てる工程を有するものである方法。
  19. 請求項18記載の方法において、前記受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、
    同じアカウントおよびブロックチェーン・ネットワーク用に複数のブロックチェーン・トランザクションが並列処理されている場合、ロック機構を使って、必ず一度に1つのトランザクションについてしかナンスが計算されないようにする工程と、
    ブロックチェーン・トランザクションが複数の再試行後も前記ブロックチェーン・ネットワーク内のノードに受理されない場合、前記受理されないブロックチェーン・トランザクションのナンスを、当該受理されないブロックチェーン・トランザクションに関連付けられたアカウントが再使用に利用できるナンスのプールに割り当てる工程と、
    ナンスを割り当てる際、前記利用できるナンスのプールが、前記受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを含むかどうか考慮する工程と、
    前記ナンスのプールが、前記受信されたブロックチェーン・トランザクションに関連付けられた前記アカウント用のナンスを少なくとも1つ含む場合、最も低い値のナンスを選択し、その最も低い値のナンスを前記受信されたブロックチェーン・トランザクションに割り当てる工程と
    を有するものである方法。
  20. 請求項19記載の方法において、前記受信されたブロックチェーン・トランザクションに前記ナンスを自動的に割り当てる工程は、さらに、
    前記ブロックチェーン・ネットワーク内のノードから前記アカウント用のナンスを取得する工程と(Nweb3)、
    前回自動的に前記アカウントに割り当てられたナンスを取得する工程と(Nred)、
    前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス(Nweb3)を、前回自動的に前記アカウントに割り当てられた前記ナンス(Nred)から減算する工程と、
    事前定義されたナンス・ウィンドウよりNred - Nweb3が大きい場合、前記ブロックチェーン・ネットワーク内のノードからの前記アカウント用の前記ナンス(Nweb3)を選択し、それ以外の場合は、より大きな値を有するナンスを選択する工程と
    を有するものである方法。
  21. 請求項20記載の方法において、さらに、
    前記受信されたブロックチェーン・トランザクションにデジタル署名する前に、前記アカウントに利用可能な最低のナンスを選択する工程と、前記選択された最低ナンスよりも低い値を有するナンスが前記プールに含まれる場合、前記選択されたナンスを、前記プールからのより低い値のナンスと取り替える工程と、前記プールからの前記より低い値のナンスを、前記受信されたブロックチェーン・トランザクション用に使う工程とを有するものである方法。
  22. 請求項9記載の方法において、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、その拒否されたブロックチェーン・トランザクションのナンスはナンスのプールに書き込まれ、そのプール内の最低値のナンスが、前記ブロックチェーン・ネットワーク内のノードへの送信用に準備された、次に受信されるブロックチェーン・トランザクションにより使用されるものである方法。
  23. 請求項22記載の方法において、前記拒否されたブロックチェーン・トランザクションは、再びデジタル署名される前に、前記ブロックチェーン・ネットワーク内のノードへの再送信用に、新規ナンスが自動的に割り当てられるものである方法。
  24. 請求項9記載の方法において、前記少なくとも1つのトランザクション属性は、プロキシの演算およびストレージ・コスト単位あたりのブロックチェーン・トランザクション手数料として前記ブロックチェーン・トランザクションの送信者が支払いを申し出ている額を有し、前記手数料は、前記ブロックチェーン・トランザクションの処理について、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担され、前記額は、前記ブロックチェーン・ネットワークで最近受理されたブロックチェーン・トランザクションに関連付けられた額に基づいて計算されるものである方法。
  25. 請求項9記載の方法において、さらに、
    最大量の演算およびストレージ・プロキシ単位(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を加算し、前記デジタル署名され若しくは認証されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と
    を有するものである方法。
  26. 請求項9記載の方法において、前記ブロックチェーン・トランザクションの処理について前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークにより負担される、プロキシ単位あたりに推定される演算およびストレージ・コストのブロックチェーン・トランザクション手数料について、前記ブロックチェーン・トランザクションの送信者が支払いを申し出ている額が低すぎる、または高すぎるという理由から、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記ブロックチェーン・ネットワーク内のノードを含むブロックチェーン・ネットワークによる前記ブロックチェーン・トランザクション処理に対し、トランザクションの送信者が支払う意思があるとして示す、最大量の演算およびストレージ・プロキシ単位を所定のパーセンテージだけ増減調整し、スケジュールされた遅延後に前記ブロックチェーン・ネットワーク内のノードに前記ブロックチェーン・トランザクションを再送信するものである方法。
  27. 命令を格納する非一時的コンピュータ可読媒体であって、前記命令は、1若しくはそれ以上のプロセッサにより実行されると、ブロックチェーン・ネットワーク内のノードへのブロックチェーン・トランザクション送信を管理する方法を、当該1若しくはそれ以上のプロセッサに実施させ、前記方法は、
    受信されたブロックチェーン・トランザクションを検証し、その検証済みの受信されたブロックチェーン・トランザクションをトランザクション・キューに入れる工程と、
    前記受信されたブロックチェーン・トランザクションの少なくとも1つのトランザクション属性を準備し、前記受信されたブロックチェーン・トランザクションを永続的キューに入れる工程と、
    前記ブロックチェーン・ネットワークに適切であるとして、前記受信されたブロックチェーン・トランザクションにデジタル署名し、またはこれを認証する工程と、
    前記デジタル署名または認証されたブロックチェーン・トランザクションを、前記ブロックチェーン・ネットワーク内のノードに送信するよう試行する工程と、
    前記送信されたブロックチェーン・トランザクションのブロックチェーン・ステータスをポーリングする工程と
    を有する、当該非一時的コンピュータ可読媒体。
  28. 請求項27記載の媒体において、さらに、
    命令であって、1若しくはそれ以上のプロセッサにより実行されると、前記ブロックチェーン・トランザクション受信時、前記1若しくはそれ以上のプロセッサに、追跡目的で前記ブロックチェーン・トランザクションに汎用一意識別子を割り当てさせる、命令を有するものである媒体。
  29. 請求項27記載の媒体において、さらに、
    命令であって、1若しくはそれ以上のプロセッサにより実行されると、当該1若しくはそれ以上のプロセッサに、前記受信されたブロックチェーン・トランザクションを前記ブロックチェーン・ネットワーク内のノードに送信する試行を追跡用に追跡キューに入れさせ、前記ブロックチェーン・ネットワーク内のノードへ正常に送信されたブロックチェーン・トランザクションのステータス情報を格納させる、命令を有するものである媒体。
  30. 請求項27記載の媒体において、さらに、
    命令であって、1若しくはそれ以上のプロセッサにより実行されると、当該1若しくはそれ以上のプロセッサに、前記送信されたブロックチェーン・トランザクションが前記ブロックチェーン・ネットワーク内のノードにより拒否された場合、前記ブロックチェーン・トランザクションを再送信させ、前記送信されたブロックチェーン・トランザクションの初回ポーリングがいつタイムアウトしたかを決定させたのち、前記送信されたブロックチェーン・トランザクションの初回ポーリングがタイムアウト後に前記送信されたブロックチェーン・トランザクションのステータスを追跡し続けるため前記ブロックチェーン・ステータスのさらなるポーリングをより低い頻度でスケジュールさせる、命令を有するものである媒体。
JP2021547344A 2019-12-13 2020-12-09 ブロックチェーン・トランザクション・マネージャー Active JP7457031B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962948060P 2019-12-13 2019-12-13
US62/948,060 2019-12-13
PCT/CA2020/051692 WO2021113967A1 (en) 2019-12-13 2020-12-09 Blockchain transaction manager

Publications (2)

Publication Number Publication Date
JP2022532464A true JP2022532464A (ja) 2022-07-15
JP7457031B2 JP7457031B2 (ja) 2024-03-27

Family

ID=76320633

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021547344A Active JP7457031B2 (ja) 2019-12-13 2020-12-09 ブロックチェーン・トランザクション・マネージャー

Country Status (9)

Country Link
US (2) US11095431B2 (ja)
EP (1) EP3884396A4 (ja)
JP (1) JP7457031B2 (ja)
KR (1) KR20220002248A (ja)
CN (1) CN113424171A (ja)
CA (1) CA3125575C (ja)
MX (1) MX2021009737A (ja)
SG (1) SG11202107654QA (ja)
WO (1) WO2021113967A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10621579B2 (en) * 2018-09-06 2020-04-14 Intercontinental Exchange Holdings, Inc. Multi-signature verification network
CN118196938A (zh) * 2018-12-06 2024-06-14 开利公司 由区块链支持的智能锁***
US11095431B2 (en) * 2019-12-13 2021-08-17 DLT Global, Inc. Blockchain transaction manager
CN111768184A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法及区块链节点
US11917088B2 (en) * 2020-09-21 2024-02-27 International Business Machines Corporation Integrating device identity into a permissioning framework of a blockchain
US11573931B2 (en) * 2021-01-21 2023-02-07 Microsoft Technology Licensing, Llc Smart near-real-time folder scan based on a breadth first search
WO2023277552A1 (ko) * 2021-06-30 2023-01-05 주식회사 아티프렌즈 스토리지 노드의 참여를 통한 데이터 분할 보관 방법
US11528197B1 (en) * 2021-08-04 2022-12-13 International Business Machines Corporation Request facilitation for approaching consensus for a service transaction
US20230088674A1 (en) * 2021-09-13 2023-03-23 Shopify Inc. Systems and methods for blockchain network congestion-adaptive digital asset event handling
US20230162178A1 (en) * 2021-11-24 2023-05-25 Circle Internet Financial, Inc. Blockchain transaction rebroadcast
CN115271746B (zh) * 2022-09-27 2023-01-31 江苏荣泽信息科技股份有限公司 一种带优先级的区块链交易排序方法
CN116703403B (zh) * 2023-07-31 2023-10-20 成都创一博通科技有限公司 基于区块链网络的离线交易方法和金融服务平台

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180191714A1 (en) * 2016-12-30 2018-07-05 Slock.it, Inc. Block-chain enabled service provider system
US20190096522A1 (en) * 2017-09-25 2019-03-28 Cable Television Laboratories, Inc Systems and methods for secure fulfillment tracking using a shared registry
US20190095585A1 (en) * 2017-09-27 2019-03-28 International Business Machines Corporation Blockchain based proactive chromosomal determination

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10046228B2 (en) * 2016-05-02 2018-08-14 Bao Tran Smart device
US10984081B2 (en) * 2016-09-30 2021-04-20 Cable Television Laboratories, Inc. Systems and methods for secure person to device association
US10762506B1 (en) * 2017-05-11 2020-09-01 United Services Automobile Association Token device for distributed ledger based interchange
WO2019204094A1 (en) * 2018-04-19 2019-10-24 Walmart Apollo, Llc Systems and methods for decentralized content distribution
US10243748B1 (en) * 2018-06-28 2019-03-26 Jonathan Sean Callan Blockchain based digital certificate provisioning of internet of things devices
US10608829B1 (en) * 2018-10-08 2020-03-31 International Business Machines Corporation Blockchain timestamp agreement
US11469878B2 (en) * 2019-01-28 2022-10-11 The Toronto-Dominion Bank Homomorphic computations on encrypted data within a distributed computing environment
US11971874B2 (en) * 2019-01-31 2024-04-30 Salesforce, Inc. Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (DLT)
CN110060161B (zh) * 2019-03-28 2021-05-28 众安信息技术服务有限公司 用于区块链交易防重的客户端服务实现方法及服务组件
US11176273B2 (en) * 2019-05-03 2021-11-16 International Business Machines Corporation Privacy-preserving anomalous behavior detection
CN110245006B (zh) * 2019-05-07 2023-05-02 深圳壹账通智能科技有限公司 区块链事务的处理方法、装置、设备及存储介质
US11249985B2 (en) * 2019-06-15 2022-02-15 Facebook, Inc. Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
US11057188B2 (en) * 2019-08-19 2021-07-06 International Business Machines Corporation Database service token
US20210091960A1 (en) * 2019-09-24 2021-03-25 International Business Machines Corporation Tracking and verification of physical assets
US11095431B2 (en) * 2019-12-13 2021-08-17 DLT Global, Inc. Blockchain transaction manager
CN111651525A (zh) * 2020-06-24 2020-09-11 北京米弘科技有限公司 区块链数据存储方法和装置
US11736456B2 (en) * 2020-09-29 2023-08-22 International Business Machines Corporation Consensus service for blockchain networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180191714A1 (en) * 2016-12-30 2018-07-05 Slock.it, Inc. Block-chain enabled service provider system
US20190096522A1 (en) * 2017-09-25 2019-03-28 Cable Television Laboratories, Inc Systems and methods for secure fulfillment tracking using a shared registry
US20190095585A1 (en) * 2017-09-27 2019-03-28 International Business Machines Corporation Blockchain based proactive chromosomal determination

Also Published As

Publication number Publication date
CA3125575C (en) 2023-03-07
SG11202107654QA (en) 2021-08-30
US20210184833A1 (en) 2021-06-17
CA3125575A1 (en) 2021-06-17
KR20220002248A (ko) 2022-01-06
US11621824B2 (en) 2023-04-04
EP3884396A4 (en) 2022-01-19
EP3884396A1 (en) 2021-09-29
WO2021113967A1 (en) 2021-06-17
MX2021009737A (es) 2021-09-08
US20210359838A1 (en) 2021-11-18
US11095431B2 (en) 2021-08-17
CN113424171A (zh) 2021-09-21
JP7457031B2 (ja) 2024-03-27

Similar Documents

Publication Publication Date Title
JP2022532464A (ja) ブロックチェーン・トランザクション・マネージャー
US10986177B2 (en) Systems and methods of self-forking blockchain protocol
US11544678B2 (en) Protocol flow for notarizing a transaction
JP5603780B2 (ja) 膨大な数の処理命令のリアルタイム処理に関する改良
US11392955B2 (en) Temporary consensus networks in a resource transfer system
US11138606B2 (en) Transfer costs and lock timeouts in a resource transfer system
US11367072B2 (en) Private networks and content requests in a resource transfer system
EP3791353A1 (en) Prioritization in a permissioned blockchain
CN111833034B (zh) 一种批量扣款方法、支付服务器、计算机设备及存储介质
US11481771B2 (en) One way functions in a resource transfer system
US20220351177A1 (en) Hold condition in a resource transfer system
US11392944B2 (en) Transfer costs in a resource transfer system
US20160342984A1 (en) Loop transfer in a resource transfer system
AU2022215275A1 (en) Temporary consensus networks in a resource transfer system
AU2016272701A1 (en) Systems and methods for publicly verifiable authorization
WO2017060816A1 (en) Private networks and content requests in a resource transfer system
US11568399B2 (en) Distributed ledger management system, distributed ledger management method, and node
Elgedawy CRESCENT: a reliable framework for durable composite web services management
US20240005330A1 (en) Transaction health monitoring and fault-tolerant routing

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210813

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210813

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221025

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230125

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230321

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20230627

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231027

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20231218

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240116

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20240215

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240314

R150 Certificate of patent or registration of utility model

Ref document number: 7457031

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150