特表2022-511084 | 知財ポータル「IP Force」

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

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ ゼットイーユー・テクノロジーズ・インコーポレイテッドの特許一覧

特表2022-511084ブロックチェーン技術を用いてデータベースアプリケーションを増強するためのシステムおよび方法

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7

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

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

(11)【公表番号】

(43)【公表日】2022-01-28

(54)【発明の名称】ブロックチェーン技術を用いてデータベースアプリケーションを増強するためのシステムおよび方法

(51)【国際特許分類】

G06F 16/27 20190101AFI20220121BHJP

【ＦＩ】

G06F16/27

【審査請求】未請求

【予備審査請求】有

(21)【出願番号】P 2021532074

(86)(22)【出願日】2019-11-28

(85)【翻訳文提出日】2021-07-20

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

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

(87)【国際公開日】2020-06-11

(31)【優先権主張番号】62/775,201

(32)【優先日】2018-12-04

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．ＪＡＶＡ

(71)【出願人】

【識別番号】521155900

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

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

(72)【発明者】

【氏名】ユミン・キアン

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175CA12

(57)【要約】

ブロックチェーン技術を用いてデータベースアプリケーションを増強するための方法が開示される。方法は、データベースアプリケーションによって行われたデータ修正を、対応するデータベース内に記録するとともに、グローバルコンセンサスの確認のためにブロックチェーン上に記録することを含む。これは、既存のアプリケーションアーキテクチャを変更することなく、また既存のアプリケーションに対するコード変更を最小限に抑えて、行われる。データベース内の、ブロックチェーンとの同期を必要とするレコードは、コンセンサス投票にかけられ、認可されないデータベース変更はロールバックされ、それにより、従来のデータベースアプリケーションに不変性および否認不可の特徴が与えられる。かくして、データベース内のレコードは、グローバルに一貫性のあるものになる。既存のデータベースアプリケーションを、コードを大幅に修正することなく、ブロックチェーン上にデプロイすることができる。複数のアプリケーションが、共通のブロックチェーンを通じてデータを同期させることができ、それにより、ブロックチェーンアプリケーションの構築が大いに簡単になる。

【特許請求の範囲】

【請求項1】

【請求項2】

前記第1のテーブルを前記修正するステップが、ステータスカラムを1組の所定の値のうちの1つに設定することを含む、請求項1に記載の方法。

【請求項3】

前記1組の所定の値が、「confirmed」、「insert pending」、「update pending」、および「delete pending」を含む、請求項2に記載の方法。

【請求項4】

前記第1のテーブルを前記修正するステップが、前記第1のテーブルにおいて第1のレコードを挿入するステップ、更新するステップ、または削除するステップのうちの1つを含み、前記第2のテーブルを前記修正することが、前記第2のテーブルにおいて第2のレコードを挿入すること、更新すること、または削除することのうちの1つを含む、請求項2に記載の方法。

【請求項5】

前記第1のレコードのフィールドが、前記第2のレコードの全てのフィールドを備え、前記第1のレコードがさらに、前記ステータスカラムに対応するステータスフィールドを含む、請求項4に記載の方法。

【請求項6】

前記修正するステップの後で、前記データベースのログから前記データベースにおける変更を特定するステップをさらに含み、前記変更が、前記ブロックチェーンによるコンセンサス投票を必要とする、請求項1に記載の方法。

【請求項7】

前記第1のテーブルを前記修正するステップが、前記データベースとデータを交換するアプリケーションによって開始される、請求項1に記載の方法。

【請求項8】

前記トランザクションをコミットした後で、前記アプリケーションにトランザクションの成功を通知するステップと、
そうでない場合は、前記トランザクションをロールバックした後で、前記アプリケーションにトランザクションの失敗を通知するステップと
をさらに含む、請求項7に記載の方法。

【請求項9】

【請求項10】

前記書込みコマンドを前記受領するステップの前に、前記データベース内の、前記ブロックチェーンとの同期を必要とする第1のテーブルを選択し、前記第1のテーブルに対応する前記一時ワーキングテーブルを作成するステップをさらに含む、請求項9に記載の方法。

【請求項11】

前記書込みコマンドを前記受領するステップの前に、前記第1のテーブルから前記クエリテーブル内に履歴データをインポートするステップをさらに含む、請求項10に記載の方法。

【請求項12】

【請求項13】

前記ワーキングテーブルに前記データを書き込むステップが、前記ワーキングテーブル内のステータスフィールドを1組の所定の値のうちの1つに設定することを含む、請求項12に記載のシステム。

【請求項14】

前記1組の所定の値が、「confirmed」、「insert pending」、「update pending」、および「delete pending」を含む、請求項13に記載のシステム。

【請求項15】

前記命令がデータベースプロキシをさらに含み、前記データベースプロキシが前記プロセッサに、
a)前記クエリテーブルを宛先とする前記アプリケーションからの前記書込み要求をインターセプトすること、
b)前記書込み要求をパースして、前記データオペレーションレコード、および前記データベースを修正するための対応するステートメントを構成すること、ならびに
c)前記ステートメントを使用して前記ワーキングテーブルを修正すること
を行わせる、請求項12に記載のシステム。

【請求項16】

前記データベースが、リレーショナルデータベース管理システム(RDBMS)であり、前記ステートメントが、構造化照会言語(SQL)である、請求項15に記載のシステム。

【請求項17】

前記命令がブロックチェーンリスナコンポーネントをさらに含み、前記ブロックチェーンリスナコンポーネントが前記プロセッサに、
a)前記ブロックチェーン内の新たなブロックに応答して、新たなデータを取り出すこと、
b)前記新たなデータに関連するデータセットを生成することであって、前記データセットがSQLステートメントを含む、生成すること、および
c)前記SQLステートメントを前記データベース内で実行して、前記新たなデータに従って前記クエリテーブルを修正すること
を行わせる、請求項16に記載のシステム。

【請求項18】

前記データセットが、テーブル名、主キー、修正前のオリジナルレコード値、修正後の新たなレコード値、データオペレーションタイプ、およびオペレーションのデータベースノード番号のうちの1つまたは複数を含む、請求項17に記載のシステム。

【請求項19】

読出しコマンドを受領すると、前記プロセッサが前記クエリテーブルからデータを読み出す、請求項12に記載のシステム。

【請求項20】

前記データベース内の前記ワーキングテーブルに前記データを前記書き込むステップにおいて、前記命令が前記プロセッサに、
テーブル名、主キー、修正前のオリジナルレコード値、修正後の新たなレコード値、データオペレーションタイプ、およびオペレーションのデータベースノード番号のうちの1つまたは複数を含むデータセットを生成すること
をさらに行わせる、請求項12に記載のシステム。

【請求項21】

ブロックチェーンにおけるコンセンサス投票を用いて、第1のデータベースを使用した第1のアプリケーションを増強するためのシステムであって、前記第1のアプリケーションが、前記ブロックチェーン上の第1のノード上で実行され、前記システムが、
a)前記第1のアプリケーションからアプリケーションコマンドを受領し、それらをデータベースコマンドに変換する、第1のデータベースプロキシと、
b)前記第1のデータベース内にあって、前記コンセンサス投票を前記ブロックチェーンが完了する前のローカルトランザクションを格納しておくための、第1組の一時テーブルと、
c)前記コンセンサス投票の結果を前記ブロックチェーンが戻した後のデータを記録するための、第1組のクエリテーブルと、
d)前記第1のデータベースにおける変更を追跡するための、第1のデータベースログ追跡モジュールと、
e)前記ブロックチェーンにデータを書き込むための、第1のブロックチェーンライタモジュールと、
f)前記ブロックチェーンにおけるイベントおよび変更を監視するための、第1のブロックチェーンリスナモジュールと
を備え、
前記第1のブロックチェーンリスナモジュールおよび前記第1のブロックチェーンライタモジュールが、前記ブロックチェーンと通信しており、前記第1のデータベースプロキシが、前記第1のアプリケーションおよび前記第1のデータベースと通信しており、前記第1のブロックチェーンリスナモジュールが、前記第1のデータベースと通信している、
システム。

【請求項22】

前記ブロックチェーンが、第2のデータベースを使用した第2のアプリケーションを実行する第2のノードを備え、前記システムが、
a)前記第2のアプリケーションからアプリケーションコマンドを受領し、それらをデータベースコマンドに変換する、第2のデータベースプロキシと、
b)前記第2のデータベース内にあって、前記コンセンサス投票を前記ブロックチェーンが完了する前のローカルトランザクションを格納しておくための、第2組の一時テーブルと、
c)前記コンセンサス投票の結果を前記ブロックチェーンが戻した後のデータを記録するための、第2組のクエリテーブルと、
d)前記第2のデータベースにおける変更を追跡するための、第2のデータベースログ追跡モジュールと、
e)前記ブロックチェーンにデータを書き込むための、第2のブロックチェーンライタモジュールと、
f)前記ブロックチェーンにおけるイベントおよび変更を監視するための、第2のブロックチェーンリスナモジュールと
をさらに備え、
前記第2のブロックチェーンリスナモジュールおよび前記第2のブロックチェーンライタモジュールが、第2のブロックチェーンと通信しており、前記第2のデータベースプロキシが、前記第2のアプリケーションおよび前記第2のデータベースと通信しており、前記第2のブロックチェーンリスナモジュールが、前記第2のデータベースと通信している、
請求項21に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は一般に、ブロックチェーンシステムに関し、詳細には、ブロックチェーン技術を用いてデータベースアプリケーションを増強することに関する。

【背景技術】

【0002】

エンタープライズアプリケーションは従来、典型的にはプレゼンテーション層、ビジネス層、およびデータ格納層またはデータ永続化層から構成される階層状または層状のアーキテクチャを使用している。プレゼンテーション層は、ユーザの対話を容易にするためのユーザインターフェースを提供するソフトウェアコンポーネントを含んでいる。ビジネスロジック層は、データに適用されるビジネスルールまたはビジネスロジックを実装したソフトウェアコンポーネントを収容している。格納層は、永続的データの格納および関連のデータアクセスサービスの提供に使用されるソフトウェアコンポーネントを収容している。

【0003】

これらの各層におけるコンポーネントとサービスの組合せにはかなりのばらつきがあるが、データ格納層は典型的には、データ格納サービスを実施するためのリレーショナルデータベース管理システム(RDBMS)またはNOSQLデータベースを含んでいる。

【0004】

エンタープライズクラスアプリケーションに適したリレーショナルデータベース管理システムは、典型的には、エラーの場合でさえ正当性を保証すべきトランザクションをサポートする。トランザクションは、同時発生することのある個々の不可分なオペレーションである。トランザクション処理システムは、トランザクションの同時処理を管理し、データの共有を可能にし、データの完全性を確実なものにし、トランザクション実行の優先順位付けを管理する。

【0005】

したがって、データベーストランザクションは、不可分性、一貫性、独立性、および耐久性(略してACID)と呼ばれる1組の特性によって特徴付けられる。不可分性とは、データに対する全ての変更が、あたかもそれらが単一のオペレーションであるかのように実施されることを意味する。一貫性とは、トランザクションの開始時とその終了時とでデータが一貫した状態にあることを要するものである。独立性とは、トランザクションの中間状態が、他のトランザクションにとって不可視であることを意味する。耐久性とは、トランザクションの完了が成功した後では、システム障害の場合でさえ、データに対する変更が永続し、取り消されないことを意味する。

【0006】

しばしば、データベースアプリケーションにおける基本的要件は、データベーストランザクションにおいて、1つのオペレーションに複数のデータベースオペレーションが関与し、これらのレコードが全て一緒に成功または失敗しなければならないことである。例えば、ある銀行口座から別の銀行口座への資金の移動は、ある口座からの引落としや別の口座への入金など、複数の変更が関与していても、単一のデータベーストランザクションである。

【0007】

一方、ブロックチェーントランザクションは、コンセンサスを介して機能する。ブロックチェーン技術は、集団参加および参加体間のコンセンサスによって、トランザクションの信頼できるレコードを維持する。ブロックチェーンはしばしば、ノードと呼ばれるネットワーク接続された複数のデバイスによって共同で維持される分散型台帳技術(DLT)と理解され、説明される。したがって、ブロックチェーンは、分散型データベースシステムと考えることができる。

【0008】

従来のエンタープライズアプリケーションがブロックチェーンに移行するとき、関連のデータベーストランザクションオペレーションの特徴が保持される必要がある。

【0009】

ブロックチェーン技術の使用を望んだ従来のエンタープライズアプリケーションは、格納層とインターフェースするビジネスロジック層内のコードを、使用されるブロックチェーンの特徴に適した関連する新たなビジネスロジックコードと置き換えていた。当然のことながら、これはコストのかかる、時間のかかる、かつ手間のかかる行為であった。この困難が、従来のデータベースアプリケーションをブロックチェーンドメインに移行させることに対する障壁を生み出していた。

【0010】

従来のデータベースアプリケーションがブロックチェーン技術を採用するのを妨げる別の課題が、ブロックチェーントランザクション完了性能である。ブロックチェーンでは、コンセンサスメカニズムが存在し、それにより、各ブロックチェーントランザクションは、トランザクションをチェーン内のブロックに書き込む前に、ノードの大多数がトランザクションを確認するのを待つ必要がある。したがって、ブロックチェーントランザクションはしばしば、それが最終的にコミットされ得る前に、数秒または数分間にもわたって続く。一方、データベースアプリケーションでは、データベーストランザクションをコミットするデータ書込みオペレーションはしばしば、瞬時に行われ、その結果として、一般的な取引データベースシステムは、数ミリ秒という長さの応答時間を有する。

【発明の概要】

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

【0011】

したがって、前述の課題のうちの少なくとも一部を緩和するための、改善されたシステムおよび方法が必要とされている。

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

【0012】

本発明の一態様によれば、データベース内とブロックチェーン内でトランザクションを同時に処理する方法が提供される。方法は、トランザクションに従って、データベース内の第1のテーブルを修正することと、トランザクションに対応するデータオペレーションレコードを構成し、コンセンサス投票のためにブロックチェーンに挿入することとを含む。方法は、コンセンサス投票の結果が成功であるときは、データベース内の第2のテーブルをトランザクションに応じて修正することによって、トランザクションをコミットし、そうでない場合は、トランザクションをロールバックし、それにより、第2のテーブルを変更されないままにすることをさらに含む。

【0013】

本発明の別の態様によれば、データベーストランザクション内のトランザクションをブロックチェーン内のトランザクションと同期させる方法が提供される。方法は、書込みコマンドを受領することと、書込みコマンドを受領したことに応答して、一時ワーキングテーブルに書き込むことと、コンセンサス投票のために対応する書込み要求をブロックチェーンにサブミットすることとを含む。方法は、コンセンサス投票の結果を受領したときは、書込みコマンドに従ってクエリテーブルを修正するが、そうでない場合は、クエリテーブルを変更されないままにすることをさらに含む。

【0014】

本発明のさらに別の態様によれば、データベースとブロックチェーンを同期させるためのシステムが提供される。システムはプロセッサを含み、プロセッサは、メモリ内に格納された命令を実行し、それによって、データベースに書き込むべきデータを有する書込み要求をアプリケーションから受領すると、プロセッサは次の、データベース内のワーキングテーブルにデータを書き込むステップと、コンセンサス投票のためにデータオペレーションレコードをブロックチェーンにサブミットするステップと、コンセンサス投票の結果の成功を示す標識を受領したときは、データベース内のクエリテーブルにデータを書き込み、そうでない場合は、クエリテーブルを変更されないままにするステップとを実施する。

【0015】

本発明のさらに別の態様によれば、ブロックチェーンにおけるコンセンサス投票を用いて、データベースを使用したアプリケーションを増強するためのシステムが提供される。アプリケーションは、ブロックチェーン上のノード上で実行される。システムは、アプリケーションからアプリケーションコマンドを受領し、それらをデータベースコマンドに変換する、データベースプロキシと、データベース内にあって、コンセンサス投票をブロックチェーンが完了する前のローカルトランザクションを格納しておくための、1組の一時テーブルと、コンセンサス投票の結果をブロックチェーンが戻した後のデータを記録するための、1組のクエリテーブルと、データベースにおける変更を追跡するための、データベースログ追跡モジュールと、ブロックチェーンにデータを書き込むための、ブロックチェーンライタ(writer)モジュールと、ブロックチェーンにおけるイベントおよび変更を監視するための、ブロックチェーンリスナ(listener)モジュールとを含む。ブロックチェーンリスナモジュールおよびブロックチェーンライタモジュールは、ブロックチェーンと通信している。データベースプロキシは、アプリケーションおよびデータベースと通信している。ブロックチェーンリスナモジュールは、データベースと通信している。

【0016】

本発明の実施形態をほんの一例として示す図において。

【図面の簡単な説明】

【0017】

【図1】本発明の一実施形態の典型例であるシステムの簡易概略図である。

【図2】図1のデータベース内のワーキングテーブルの簡易概略図である。

【図3】図1のデータベース内のクエリテーブルの簡易概略図である。

【図4】図1のデバイス実行アプリケーションによって行われる動作のフローチャートである。

【図5】図1のデバイス実行アプリケーションを利用してトランザクションを実行するための例示的プロセスのフローチャートである。

【図6】図1のブロックチェーンに新たなブロックが追加された後でデータベースデータを回復し、同期させるための例示的プロセスのフローチャートである。

【図7】データベース既存アプリケーションを、そのデータベースとブロックチェーンの両方と対話するアプリケーションに移行させるためのステップを要約した、フローチャートである。

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

【0018】

本発明の実施形態は、データベースアプリケーションをブロックチェーンアプリケーションに移行させることに関連する問題に対処する。これらの問題には、同期取引オペレーションを非同期取引オペレーションに移行させることが含まれる。主要な理由のなかでもこのミスマッチが、ビジネス層のコードの書き換えを余儀なくしている。

【0019】

ブロックチェーン技術の主要な利点は、タンパー明示性を備えた(tamper-evident)トランザクションを確実なものにすることであるが、ブロックチェーンのアーキテクチャおよび設計は予め決まっている。ブロックチェーンアプリケーションでは、インクリメンタルなオペレーションのみが実施され得る。ブロックチェーンは、ランダムな照会またはランダムな状況修正に適していない。実際、ランダムな修正を、不可能とまではいかなくても困難にすることは、信頼できる仲介機関なしで不変の監査証跡を確実なものにしようとするブロックチェーンの望ましい特性である。残念なことに、この特性は、アプリケーション開発の自由度および範囲を制限するものでもある。

【0020】

ブロックチェーンアプリケーションは、ブロックチェーン内に全てのデータを保存する必要はない。そうではなく、格納されるデータのうちの一部の否認不可物だけがブロックチェーン内に保存される必要がある。したがって、大多数のブロックチェーンアプリケーションは、多様なローカル情報を格納するために、依然としてリレーショナルデータベースに頼っている。例えば、ユーザログイン認証は、依然として従来のリレーショナルデータベース管理システムまたはNOSQLデータベース上で行われている可能性があり、このリレーショナルデータベース管理システムまたはNOSQLデータベースが、データベースとブロックチェーンの同期をとる。

【0021】

本発明のさまざまな実施形態についての説明を下で行う。本開示では、「1つの(a)」または「1つの(an)」という語の使用は、本明細書において「備える」という用語とともに使用されるとき、「1つの(one)」を意味することができるが、それは「1つまたは複数の」、「少なくとも1つの」、および「1つまたは1つよりも多くの」の意味とも一致する。単数形で表現される任意の要素は、その複数形も包含する。複数形で表現される任意の要素は、その単数形も包含する。「複数」という用語は、本明細書では、1つよりも多くの、例えば2つ以上、3つ以上、4つ以上などを意味する。「上部」、「下部」、「上方に」、「下方に」、「縦に」、および「横に」など、方向を示す用語は、相対的参照を行う目的で使用されているにすぎず、任意の物品を使用時にどのように位置付けるべきか、または任意の物品をどのように組立体内にもしくは環境に対して取り付けるべきかに対するどんな制限も示唆するものではない。

【0022】

「備える」、「有する」、「含む」、および「収容する」という用語、ならびにそれらの文法的変形は、包含的またはオープンエンドであり、記載されていない追加の要素および/または方法ステップを除外しない。「本質的に～からなる」という用語は、本明細書において構成、使用、または方法に関連して使用されるとき、追加の要素、方法ステップ、または追加の要素と方法ステップの両方が存在する可能性があるが、これらが追加されても、記載された構成、方法、または使用が機能する様式に実質的に影響が及ばない、ということを意味する。「～からなる」という用語は、本明細書において構成、使用、または方法に関連して使用されるとき、追加の要素および/または方法ステップの存在を除外する。

【0023】

「ブロックチェーン」とは、タンパー明示性を備えた共有のデジタル台帳であり、これは、コンピューティングデバイスのパブリックまたはプライベートのピアツーピアネットワーク内でトランザクションを記録するものである。台帳は、暗号学的ハッシュによりリンクされたブロック(cryptographic hash-linked block)からなる、増え続ける連続したチェーンとして維持される。

【0024】

「ノード」とは、ブロックチェーンネットワーク上のデバイスである。デバイスは、典型的には、プロセッサ可読命令をその上に有するメモリを含むプロセッサ可読媒体に相互接続されたプロセッサを有する、コンピュータである。

【0025】

加えて、「第1の」、「第2の」、「第3の」などという用語は、説明を目的として使用されているにすぎず、相対的重要性を示すまたは意味すると解釈することはできない。

【0026】

本発明の説明においては、「取り付けられた」、「リンクされた」、および「接続された」という用語は、別段の明示的な定めおよび制限のない限り、広義に解釈すべきであることにも留意されたい。例えば、それは固定の接続であってもよく、組立て式の接続であってもよく、一体的に接続されてもよく、それはハードワイヤードであってもよく、ソフトワイヤードであってもよく、それは直接的に接続されていてもよく、仲介物を通じて間接的に接続されていてもよい。技術専門家にとって、上記の用語の本発明における具体的意味は、文脈の中で理解することができる。

【0027】

本発明の実施形態を示す図面においては、同じまたは類似の参照ラベルが、同じまたは類似の部分に対応する。本発明の説明においては、「複数の」の意味が、別段の指定のない限り、2つ以上の、を意味することに留意されたい。「上」、「下」、「左」、「右」、「内側」、「外側」、「前端」、「後端」、「頭部」、「尾部」という用語の方向または位置、すなわち図面中に示される配向または位置関係は、単に、本発明の説明の便宜を図り、説明を簡単にするためのものであって、示されたデバイスまたは要素が特定の配向を有し、特定の配向で構築され、動作しなければならない、ということを示すまたは意味するためのものではなく、したがって、本発明を限定するものとして使用することはできない。

【0028】

ソフトウェアシステムアーキテクチャ
図1は、本発明の一実施形態の典型例であるソフトウェアシステム100の概略図を示す。ソフトウェアアプリケーションであるクライアントアプリケーション101が、データベース111とデータを交換する。

【0029】

データベース111は、リレーショナルデータベース管理システムであり、ワーキングテーブル103、プライベートテーブル104、およびクエリテーブル105を含む、複数のテーブルを含んでおり、これらのテーブルには、データベースプロキシサービス102を通じてアクセス可能である。

【0030】

ブロックチェーンリスナサービス108が、テーブル104、テーブル105、およびリボークコールバックサービス(revoke callback service)109とデータ通信している。データネットワークによって互いに相互接続された複数のノード110aから110eから構成されたブロックチェーン110が、ブロックチェーントランザクションを処理するためのコンセンサス投票を実施し、このブロックチェーントランザクションはアプリケーション101と同期される。

【0031】

プライベートテーブル104とデータ通信しているトランザクショントラッカコンポーネント106が、トランザクションを追跡する。ブロックチェーン110と通信しているブロックチェーンライタコンポーネント107が、投票に付すべき、かつコンセンサス後にブロックチェーン内のブロックに書き込むべきトランザクションをサブミットする。

【0032】

クライアントアプリケーション101は、データベースアプリケーション、すなわちデータベース主導型のソフトウェアアプリケーションである。システム100などのブロックチェーンシステムでは、さまざまな組織がさまざまな責務を実施し、したがって、ノード110aから110eのそれぞれが、複数のアプリケーションを実行することがある。しかし、これらのさまざまなアプリケーションは、共通の情報ストアから読み出し、そこに書き込む。

【0033】

プライベートテーブル104は、データをローカルに維持するローカルプライベートテーブルである。テーブル104内のデータは、コンセンサスを得るためにブロックチェーンに同期される必要はない。

【0034】

クエリテーブル105は、データベース111内に格納される永続的データを収容し、アプリケーション101などのアプリケーションによる使用に適したデータを収容することができる。

【0035】

ワーキングテーブル103は、クエリテーブルに似た、対応するオリジナルテーブルのコピーに、起こり得るトランザクションの競合の管理を助け、データベース111内へのデータの永続化をブロックチェーン110におけるコンセンサス投票と協調させるための追加のステータスまたはステートのフィールドまたはカラムが付加されたものとして作成される、一時テーブルである。

【0036】

データベースプロキシサービス102は、図示の実施形態では、データベース111へのアクセスを容易にするためのプロキシサービスである。データベースプロキシサービス102は、アプリケーション101から要求を受領する。データベースプロキシサービス102は、アプリケーション101から要求を受領した後、要求が読出し要求であるかそれとも書込み要求であるかを判定し、要求を、データベース111などのRDBMSに適した適切な構造化照会言語(SQL)ステートメントに変換する。代替実施形態では、読出し要求または書込み要求は、特定のデータベース111に対する下位レベルデータアクセス用に事前に定義されたインターフェースを使用して、適切なストアドプロシージャまたはアプリケーションプログラミングインターフェース(API)呼出しに変換されてもよい。

【0037】

ブロックチェーンデータに関連する読出し要求は、クエリテーブル105に転送され、一方、書込み要求は、ワーキングテーブル103に転送される。ローカルデータの読出し要求および書込み要求は、プライベートテーブル104に転送される。

【0038】

アプリケーション101が、ブロックチェーン110との同期を必要とするデータオペレーションを実施するとき、関連のオペレーションは最初に、プロキシサービス102によってワーキングテーブル103に向けられ、ワーキングテーブル103がトランザクションオペレーションを実施した後で、トランザクションログが生成され、このログは、トランザクショントラッカコンポーネント106によって監視される。

【0039】

本実施形態では、ワーキングテーブル103内の全てのテーブルは、図2に示すように、現在のレコードステータスを記録するための「ステータス」カラムを有する。ブロックチェーン110によってまだ確認されていないトランザクションに関する、トランザクションステート値またはトランザクションステータス値は、ペンディングステートまたはペンディングステータスにあると言われ、これには、「Pending insert」、「Pending update」、および「Pending delete」というステータス値が含まれる。このステータスは、ブロックチェーンにおいてコンセンサスに達するのに成功した後で、「Committed」に変更される。ブロックチェーンコンセンサスオペレーションが失敗した場合、ワーキングテーブル103内および関連のローカルテーブル内の関連するレコードがロールバックされ、ステータスカラムには「Committed」のマークが付される。

【0040】

クエリテーブル105は、ブロックチェーンシステム110におけるコンセンサス投票の結果として生じたデータを収容する。図3は、クエリテーブル105の一例を概略的に示す。

【0041】

ブロックチェーン書込みサービスコンポーネント107は、抽出されたデータ変更レコードを、コンセンサスオペレーションを開始するためにブロックチェーン110に書き込む。一実施形態では、書込みサービスコンポーネント107は、クエリテーブル105によってフィルタリングされたデータ変更レコードを読み出し、次いで、ブロックチェーンスマートコントラクトを呼び出し、ブロックチェーン110への書込み要求を開始し、変更された1つまたは複数のデータレコードをブロックチェーン110に書き込む。別のブロックチェーンを利用する他の実施形態では、コンポーネント107は、別のブロックチェーンアプリケーションプログラミングインターフェース(API)を使用してデータを書き込んでもよい。

【0042】

クエリテーブル105の内容は、ブロックチェーンライタモジュール107によって、ブロックチェーンシステム110内に記録されたトランザクションログから回復される。

【0043】

トランザクショントラッカコンポーネント106は、データベースによって生成されたログをリアルタイムで監視し、プライベートテーブル104のデータ変更レコードをフィルタリングするための、ログ追跡コンポーネントである。

【0044】

ブロックチェーン110において新たなブロックが生成され、同期されると、ブロックチェーンリスナサービスコンポーネント108は、ブロック内容を取り出し、データ変更ログをリストアし、データ変更SQLステートメントに変換し、次いで、対応する変更オペレーションをクエリテーブル105内で再生または実行する。すでに開始されている他のオペレーションと、あるオペレーションが競合する場合、あるオペレーションのほうが破棄される。現在のノード識別子(ノードID)が、変更レコードが生成されるのと同じノードIDである場合、以前のトランザクション情報はログから得られる必要があり、そのオリジナルデータがワークシートまたはワーキングテーブル103内にリストアされる。一方、データの一貫性を確実なものにするために、ロールバック情報がブロックチェーン110に書き戻される。

【0045】

コールバックサービス109は、ブロックチェーン110におけるコンセンサス投票が完了するたびに、アプリケーション101へのコールバックを生成する。トランザクションが現在のノードを通じて生成された場合、ブロックチェーンリスナモジュール108は、アプリケーション101へのコールバックを生成し、コンセンサス結果を、それが成功を示しているときにもそれが失敗を示しているときにも通知する。

【0046】

当業者には理解されるように、アプリケーション101にイベントについて通知するいくつかの方途がある。1つの一般的な方法は、コンフィギュレーションファイル内に定義されている事前定義されたコールバックAPIを通じたものである。事前定義されたAPIは、ブロックチェーン110内のローカルノードがコンセンサス投票の結果を取得すると、呼び出される。あるいは、メッセージキュー(MQ)または共有データベースイベントテーブルが使用されてもよい。結果はMQまたは共有イベントテーブルに送出され、アプリケーション101がMQまたはイベントテーブルをチェックして通知を得る。

【0047】

オペレーショナルログデータは、ブロックチェーンシステム110上に記録される。ブロックチェーン110は、さまざまな位置にある全てのノード110aから110eを接続し、コンセンサス投票を実施する、ブリッジである。

【0048】

理解され得るように、複数のノード110aから110eが同じトランザクションを記録しようと試みるとき、各ノードにおけるシステム時間は同期されていない可能性があるので、異なるノードにおいて発生したトランザクションの順序を確かめる方途はない可能性がある。

【0049】

一実施形態では、簡単にするために、ブロックチェーン110がコンセンサスを開始する順序が、ブロックチェーントランザクション競合を解決するための判断基準として使用される。ブロックチェーン内の各ブロックは、全てのノードにわたってすでに同期されている。データ修正は、ブロックチェーン110内のトランザクションログとして提示される。

【0050】

本実施形態では、所与のブロック内で、1つのレコードを修正できるノードは1つ、という制限がある。同じブロック内で1つのレコードが複数のノードによって修正されたことを示す複数のトランザクションログがある場合、唯一受け入れられるトランザクションログは最初のノードからのものであり、他のノードからの残りのトランザクションは棄却される。他のノードに対する変更は、ブロック内でトランザクションが再生されるまでは見られない。データベース再生により、同じレコードに関する他のノードの残りのトランザクションログは無視され、それらのトランザクションには失敗のマークが付される。ブロックチェーントランザクションが成功した後、同じレコードに影響を及ぼすかまたは同じレコードを修正する後続のペンディングブロックチェーントランザクションは棄却され、後続のトランザクションを開始したノードにおいて、対応するデータベーストランザクションがロールバックされる。他のノードも、後続のコペンディングトランザクションを棄却する。

【0051】

ビジネスオペレーションを記録するためには、アプリケーション101がビジネスオペレーションを、データベーストランザクションの一部をなす1つまたは複数のデータベースオペレーションに変換する。本実施形態では、アプリケーション101は、データベースインターフェースまたはデータベースプロキシ102を使用して、データベーストランザクションを得る。

【0052】

図4は、デバイス実行アプリケーション101によって行われる動作のフローチャートを示す。ステップ402において、データベーストランザクションが開始される。基礎をなすビジネスオペレーションには、ローカルデータベースオペレーション、およびブロックチェーン110上でのコンセンサスを必要とするブロックチェーンオペレーションが関与し得る。

【0053】

ステップ406において、アプリケーション101がワーキングテーブル103を修正する。データベース111内でトランザクションをコミットする前に、ブロックチェーン110におけるコンセンサスオペレーションが必要である。

【0054】

ステップ408において、データトラッキングモジュール106が、データベースワーキングテーブル103における変更を追跡し、オペレーションレコードを構成する。ステップ410において、コンセンサスを実施するために書込みデータオペレーションレコードがブロックチェーンライタモジュール107を通じてブロックチェーン110に挿入される。

【0055】

ステップ411において、一定期間後に、ブロックチェーン110がコンセンサスを完了し、新たなブロックが生成されて現在のノード110aに同期される。アプリケーション101は、コンセンサス結果を受領し、各レコードがコンセンサスの完了に成功したかどうかを判定する。コンセンサスの完了に成功した場合(ステップ412)、クエリテーブル105内のオペレーションレコード(ステップ414)を使用して、SQLステートメントが復元され、データベースオペレーションが実施され、レコードが復帰する。

【0056】

ステップ416において、現在のノード110aがデータオペレーション開始ノードと一致している場合、アプリケーション101は、ワーキングテーブル103内のレコードステータスを変更し、トランザクションをコミットする。ステップ418において、アプリケーション101は、コールバックサービス109によって、トランザクションがブロックチェーンコンセンサスの完了に成功したことを通知される。そうでない場合、アプリケーション101は、クエリテーブル105内のデータを対応するワーキングテーブル103にコピーする。

【0057】

ブロックチェーンコンセンサスが失敗した場合(ステップ412)、アプリケーション101は、データベーストランザクションをロールバックし、データベース111内の関連のレコードが、トランザクションが開始された前のステートに復元され(ステップ420)、コールバックサービス109から、トランザクションブロックチェーンコンセンサスが失敗したとの通知が送出される(ステップ422)。

【0058】

ブロックチェーンデータをデータベースデータと同期させるための技法
アプリケーション101は最初に、ローカルデータベース111にアクセスする。ブロックチェーン110の更新の性能または速度は、データベース111の更新速度よりもずっと遅いので、一実施形態では、確実にブロックチェーン内容がデータベース内容と一致するようにするために、非同期更新が使用される。

【0059】

当業者には理解され得るように、データベース111内の2組のテーブルは、ブロックチェーン110と同期される必要のあるデータを取り扱うように設計される。第1組のテーブルは、データベースによって一時的に更新されたデータを保存するために使用されるローカルの一時ワーキングテーブル103を含む。第2組は、ブロックチェーン110からデータベースにデータレコードをリストアするために使用されるクエリテーブル105を含む。アプリケーションの複雑さを回避するために、読出し要求をクエリテーブルにマッピングし書込みオペレーションを一時テーブルにマッピングする読出し-書込み間分離のための、データベースプロキシサービス102の形態をとる単純なプロキシが、アプリケーション101とデータベース111との間に設けられる。

【0060】

ワーキングテーブル103は、オリジナルテーブルのコピーに、もう1つのステータス/ステートカラムが追加または付加されたものである。追加のステータスカラムのうちの1つは、それぞれのレコードまたはロウのトランザクションステートを表す。一実施形態では、このステータスカラム、例えば図2に示すワーキングテーブル103の最終カラムが、4つのステータス値を有していてよい。他の実施形態では、より多数のまたはより少数のステータス値またはステート値が用いられてよい。

【0061】

一実施形態では、「Committed」というステータス値は、データがコンセンサスを終了したことを意味し、一方、「Insert pending」というステータス値は、insert SQLコマンドによってレコードが生成され、コンセンサス投票結果を待っていることを意味する。「Update pending」というステータス値は、update SQLによってロウまたはレコードが修正され、コンセンサス投票の結果を待っていることを意味する。「Delete pending」というステータス値は、delete SQLによってロウが修正されたが、実際のところはまだ削除されておらず、したがって削除のマークが付されただけであり、それと同時にコンセンサス投票結果を待っていることを意味する。

【0062】

ローカルトランザクションログの一般的なフォーマットは、次の通りである。

【0063】

【表1】

【0064】

アプリケーション101のユーザが一時テーブルの内容を修正した後、ログモニタがデータ修正ログ情報を同期させ、ログ情報をブロックチェーン110に書き込む。

【0065】

ブロックチェーン110に書き込むためのデータ構造およびルールは、次の通りである。

【0066】

【表2】

【0067】

ローカルデータベーストランザクションに、ブロックチェーン110上に載せる必要のある複数のレコードが関与する場合、レコード内には複数のデータセグメントがある。

【0068】

ローカルトランザクションが成功すると、ローカルトランザクションオペレーションを完了したノードが、スマートコントラクトを有するブロックチェーンアダプタを通じて、関連するデータをブロックチェーン110に書き込む。通常、ブロックチェーン110は、クライアントがスマートコントラクトにアクセスするためのAPIを公開している。アダプタ層は、APIを介して起動してブロックチェーンデータを内部的に修正することのできるスマートコントラクトを備えており、ブロックチェーンの一部をなす。ブロックチェーン110内の各ノードがスマートコントラクトモジュール(図示せず)を含んでいてよい。多様な理由のうちのいずれか1つにより、ローカルデータがブロックチェーン110との同期に失敗した場合、ローカルノードが復旧された後で、ブロックチェーンアダプタが自動的に、最後に中断された位置からコンセンサスを得るために、関連するログをブロックチェーン110に再び送出し始める。

【0069】

ブロックチェーン110上でコンセンサスが完了した後、ブロックチェーン適応プログラムが、ブロックチェーンの変更を監視し、データ回復ルールに従ってブロックチェーン内のログデータをクエリテーブルに同期させる。ブロックチェーン110からのデータを同期させるとき、データが要件を満たしている、すなわちオリジナルの値がクエリテーブル105内の対応する値と合致している場合、レコードがクエリテーブル内にリストアされ得る。ローカルノードについては、コンセンサス前はペンディングトランザクションデータがワーキングテーブル103に書き込まれるが、ペンディングステータスに維持される。コンセンサスに達した後、ワーキングテーブル103内のステータスまたはステートが、confirmedステータスに変更される。コンセンサスに達しなかった場合、ワーキングテーブル103からトランザクションがロールバックされる。

【0070】

その他の場合は、現在のノード110aがトランザクション開始ノードであるかどうかが判定され、そのトランザクション発生元ノードが、新たなロールバックレコードを生成し、それをブロックチェーンに書き込む。トランザクション開始ノードは引き続き、ワーキングテーブル内のロールバックされる必要のあるデータが、ペンディングステートにあるかどうかを判定する。レコードに対応するステータスがペンディングステートにある場合、現在のレコードにはその以前の値が上書きされ、ステータスが「Committed」に設定される。

【0071】

レコードがワーキングテーブル103内で修正されたもののブロックチェーン110上でのコンセンサス投票によって確認されていない場合、レコードは、レコードに関連するコンセンサス投票の結果がブロックチェーン110によって確認されるかまたは棄却されるまでは再度修正されない。したがって、ペンディングステータスにあるレコードを修正しようと試みるトランザクションは失敗することになる。換言すれば、ペンディングステータスを有するレコードは、新たなトランザクションに参加することができない。

【0072】

図5は、トランザクションを実行するための例示的プロセスのフローチャートである。ステップ501において、アプリケーション101が、データベーストランザクションを開始するためのデータ修正オペレーションを開始し、このトランザクションは、データベース内のデータを修正する。ステップ502において、アプリケーション101が、トランザクション内の次実行ステートメントを取得する。

【0073】

ステップ503a、503b、および503cにおいて、データオペレーションがレコードを挿入するものであるか、それとも更新するものであるか、それとも削除するものであるかが判定される。データベースプロキシサービス102が、アプリケーション要求をインターセプトし、パースし、適用可能なデータオペレーションおよび対応するSQLステートメントを決定する。

【0074】

ステップ504において、要求が新たなデータを挿入することである場合、挿入オペレーションが行われ、対応するテーブル名が、ワーキングテーブルの名前に修正される。

【0075】

ステップ505において、現在のレコードの内容にステートフィールドまたはステータスフィールドを追加することによって、新たなinsertステートメントが準備される。「pending insert」、「pending modify」、「pending delete」、および「committed」という4つのステートがある。「pending insert」、「pending modify」、「pending delete」というステートは、「ペンディング」ステート値またはステータス値である。新たなデータが挿入される場合のステータスフィールドは、「pending insert」であり、データが修正された後の「pending modify」としてのステータスフィールド、および「pending delete」としてのレコードが削除される場合のステータスフィールド。

【0076】

ステップ506において、対応するワーキングテーブルにレコードが挿入される。

【0077】

ステップ507において、SQLステートメントを使用して、ワーキングテーブル内でレコードが更新される。エージェントがSQLをインターセプトし、次いで、対応するワーキングテーブルを修正する。

【0078】

ステップ508において、アプリケーション101は、このトランザクションの実行中に他のトランザクションが関連のレコードを修正できないようにこれらのレコードをロックするため、またステータスフィールドを取得するために、ワークテーブル103に対して「select for update」を実行する。

【0079】

ステップ509において、現在のレコードがペンディングステートにあるまたはペンディングステータスを有するかどうかが判定される。ペンディングステートにあるレコードは、それにより競合が生じるので、別のトランザクションに参加することができない。現在のトランザクションと、ブロックチェーンコンセンサスを用いない他のトランザクションとの間に競合がある場合、現在のトランザクションは実行することができず、トランザクションは失敗する(ステップ519)。

【0080】

ステップ510において、update SQLが実行される。ワーキングテーブル103に対してデータが更新され、レコードのステートが「pending update」に修正される。ステップ511において、要求ステートメントがdeleteステートメントであり、プロキシがSQLをインターセプトし、修正後の対応するテーブル名が、ワーキングテーブル名である。

【0081】

ステップ512において、関連のレコードをロックするため、またステートまたはステータスを取得するために、ワークテーブル103に対する更新のための選択(selection for update)が行われる。したがって、本トランザクションの実行中に他のトランザクションは現在のレコードを修正することができない。ステップ513において、結果セットのステータスフィールドがペンディングステータスを有するかどうかが判定される。現在のトランザクションと、ブロックチェーンコンセンサスを用いない他のトランザクションとの間に競合がある場合、現在のトランザクションは実行することができず、失敗する(ステップ519)。

【0082】

ステップ514において、競合レコードがない場合、アプリケーション101は、更新命令を実行し、ワーキングテーブル103内のステータスフィールドを更新し、トランザクションに関与する全てのレコードの現在のステートを「pending delete」に修正する。ステップ515において、アプリケーションは、現在のSQLの実行が成功したかどうかをチェックし、成功していない場合、トランザクションは失敗する。ステップ516において、アプリケーション101は、トランザクションをコミットするかどうかを判定する。トランザクション内に他のトランザクションコマンドがある場合、アプリケーション101はステップ502に戻って、引き続き残りのトランザクションコマンドを実行する。

【0083】

ステップ517において、トランザクションがコミットされ、ステップ518において、トランザクション実行ログがデータベースノードまたは他のデータベースログ同期ノードにおいて生成され、ノード識別子が記録される。ステップ519において、トランザクションの失敗が宣言され、相当するメッセージがアプリケーション101に送出される。ステップ520において、トランザクション実行ログが、適切なフォーマットにフォーマット化される。一実施形態では、フォーマットは、Java Script Object Notation(JSON)レコードとすることができる。次いで、コンセンサスを開始するために、レコードがブロックチェーンインターフェースを通じてブロックチェーンに書き込まれる。

【0084】

ブロックチェーン内に新たなブロックが生成され、ノードに同期された後、図6に要約されるように、データベースデータを回復し、同期させるためのプロセスを使用して、ブロックチェーンデータが同期される。

【0085】

ステップ601において、ブロックチェーン内に新たなブロックが生成され、現在のノードに同期される。ステップ602において、現在の新たなブロックからのトランザクションログリストがデコードされる。ステップ603において、トランザクションログリストの再生未完了のレコードがあるかどうかに関してチェックが行われる。トランザクションログリストは、複数のトランザクションを含み、それぞれに1つまたは複数のレコードが関与する。他のノードと同期される必要があるのは、コンセンサスレコードを必要とするレコードのみであり、ローカルデータはチェーン上に載せられない。トランザクションは、完了されていないレコードを有するとき、引き続き、データベース内で再生できるようにそのレコードをSQLに変換する。トランザクションが実行を完了した場合、データベース内でコミットアクションが実施される。実行すべき他のトランザクションがある場合、引き続き次トランザクションを取得し、実行する。

【0086】

ステップ604において、命令によりトランザクションログから次トランザクションレコードが取得される。ステップ605において、トランザクション内で次レコードが取得される。レコードは、そのデータ内容に従ってSQLオペレーションに復元される。データ内容には、オリジナル値、変更後の新たな値、オペレーションのタイプ、およびオペレーションノード情報が含まれる。ステップ606において、データレコードのオペレーションタイプがチェックされる。このタイプは、insert、update、またはdeleteのうちの1つであり、これらには、データ回復のための対応する方法が必要である。

【0087】

ステップ607において、insertステートメントが構築される。ステップ608において、このinsertステートメントに対応する主キーがすでに存在するかどうかを確かめるためにクエリテーブル105が検査される。キーがすでに存在する場合、それは、このトランザクションが同じブロック内の他のトランザクションと競合する可能性があることを示す。換言すれば、ある特定のブロックチェーンノード上の他のアプリケーションが、同じキーを使用した挿入オペレーションをすでに開始しており、そちらのほうが最初に実施されることになり、同じレコードに関する第2の挿入オペレーションは失敗することになる。主キーは、RDBMSにおいてテーブル内のレコードを一意に識別することを思い出されたい。

【0088】

ステップ609において、クエリテーブルへの挿入オペレーション。この段階では、(ステップ608において)クエリテーブル内に同じキーを有するレコードが存在しないことがすでに分かっている。ステップ610において、ログの生成されたノードが現在のノードであるかどうかが判定される。そのノードが現在のノードである場合、それは、対応するオペレーションレコードがワーキングテーブル内にあることを示し、対応するオペレーションレコードにはさらなる処理が必要である。ステップ611において、レコードがワーキングテーブルに直接挿入される。ログ生成ノードが現在のノードではないことは、(ステップ610において)すでに判定されている。ワーキングテーブルがこの主キーと同じデータを有する場合、現在のノードは、他のノードが記録オペレーションを実施した後で、競合オペレーションを実施し、それを直接破棄する。ワーキングテーブル内に記録し、クエリテーブルのレコードを使用して上書きし、ステータスを「committed」に変更する。

【0089】

ステップ612において、ワーキングテーブル内の対応するレコードが位置特定され、ステータスが「committed」に変更される。ワーキングテーブル内の記録された内容が、現在のレコードと一致していることを確認することが必要であり、これらのレコードが一致していない場合、現在のレコードが勝利し、正しい値として選ばれる。

【0090】

ステップ613において、updateステートメント(例えばSQL)が準備され、ステップ614において、クエリテーブル内に同じ主キーをもつレコードがあるかどうかが比べられる。主キーが見出されない場合、現在のオペレーションと競合する、このレコードに影響を及ぼす別の削除トランザクションがある可能性があり、現在のレコードが実行される前に対応するレコードが削除され、更新レコードは実行を継続することができず、現在のトランザクションが失敗することになり、そのため、関連する全てのステップがロールバックされる。

【0091】

ステップ615において、クエリテーブル内のこの主キーを有するレコードが更新され、新たな値と置き換えられる。ステップ616において、トランザクションが破棄され、ワーキングテーブル内のオリジナルの値が、クエリテーブル内にリストアされる。

【0092】

ステップ618において、現在のノードとレコード更新ノードが同じノードであるかどうかがチェックされる。同じノードではない場合、ステップ619において、クエリテーブルデータがワーキングテーブルにコピーされる。そうでない場合は、ステップ620において、ブロックチェーンにサブミットされたペンディングトランザクションを示す異なる値として、ワーキングテーブルが単純に上書きされる。アプリケーションによるワーキングテーブル内の新たな修正は、破棄されるものとして通知される。ワーキングテーブル103のステートは、Committedに設定される。

【0093】

ステップ621において、削除プロセスが実行される。ステップ622において、クエリテーブル内に削除すべき同じ主キーを有するレコードがあるかどうかがチェックされ、ない場合、ステップ623において、そのレコードがクエリテーブル内の対応するレコードから削除される。

【0094】

ステップ624において、現在のノードがデータサブミッションノードと同じであるか。ワーキングテーブルの同じ記述が同じレコードを有する場合、ワーキングテーブル103内のペンディングトランザクションが現在のトランザクションと競合するかどうかを、追加で判定する必要がある。そのオリジナルの値が異なる場合、競合が確認され、ワーキングテーブル103内のペンディングトランザクションが破棄され、アプリケーションに通知される。

【0095】

ステップ625において、主キーに対応するレコードがワーキングテーブル103から削除される。ステップ626において、トランザクションがロールバックされる。ワーキングテーブル103関連のトランザクションオペレーションに他のローカルデータオペレーションが関与している場合、ワーキングテーブル103のローカルトランザクションログが照会される必要がある。ステップ627において、トランザクションログに従って、同じトランザクションにおける他のデータテーブル内の他のオペレーションをロールバックするための逆方向オペレーションが構築される。

【0096】

ステップ628において、現在のトランザクションが終了しているかどうかがチェックされ、終了している場合、ステップ629において、トランザクションがコミットされ、そうでない場合は、プロセスが引き続き、ブロックチェーン内の次トランザクションを、ブロック内の全てのオペレーションが処理されるまで取得する。

【0097】

データ修正オペレーションがinsertステートメントである場合、ワーキングテーブル103に対して挿入オペレーションが実施される。

【0098】

ブロックチェーンへの同期イベントを生成するためのデータフォーマットは、次の通りである。

【0099】

【表3】

【0100】

コンセンサスが成功した後、レコードに従って、順方向データ挿入SQLステートメントが生成され得る。

【0101】

Insert into [テーブル名] values (値のリスト)

【0102】

コンセンサスが失敗した場合、トランザクションログに基づいて、ワーク関連のオペレーションをロールバックするための逆方向ロールバックステートメントを生成することができ、これには、トランザクションを開始する前の全ての値が収容される。

【0103】

Delete from [テーブル名] where key=[主キー]

【0104】

データ修正オペレーションがupdateステートメントである場合、ワークシートまたはワーキングテーブルがデータ更新オペレーションを実施する。ブロックチェーンへの同期を生成するためのデータフォーマットは、次の通りである。

【0105】

【表4】

【0106】

コンセンサスが成功した後、レコードに従って、順方向データ更新SQLステートメントが生成され得る。

【0107】

Update [テーブル名] set key1=val1,key2=val2 ....

【0108】

同時に、ワークシートに対しても更新オペレーションが実施される。

【0109】

Update [テーブル名] set status = ‘committed' where key1=val1

【0110】

コンセンサスが失敗した場合、ワーク関連のオペレーションをロールバックするための逆方向ロールバックステートメントを生成することができる。

【0111】

Update [テーブル名] set key1=val1_0,key2=val2_0 ....

【0112】

データ修正オペレーションがdeleteステートメントである場合、ワークテーブルがデータ更新オペレーションを実施し、オリジナルデータステートが「committed」から「pending delete」に変更される。

【0113】

ブロックチェーンへの同期を生成するためのデータフォーマットは、次の通りである。

【0114】

【表5】

【0115】

コンセンサスが成功した後、レコードに従って、順方向データ削除SQLステートメントが生成され得る。

【0116】

Delete from [テーブル名] where primarykey=val1_0

【0117】

ワークシートに対しても削除オペレーションを実施する。

【0118】

【0119】

Update [テーブル名] set status = committed where primarykey = val1_0

【0120】

アプリケーション移行
図7は、データベース既存アプリケーションを、そのデータベースとブロックチェーンの両方と対話するアプリケーションに移行させるためのステップを要約した、フローチャートを示す。

【0121】

ステップ701において、オリジナルのデータベース構造およびデータがエクスポートされる。

【0122】

ステップ702において、ブロックチェーンとの同期またはコンセンサス投票を必要とするテーブルが選択される。

【0123】

ステップ703において、コンセンサス投票またはブロックチェーンとの同期を必要とするオリジナルテーブルごとに、2つのテーブルが作成される。1つのテーブルはワークテーブルであり、ワークテーブルに対しては、オリジナルテーブルのエクスポートされたデータ構造に加えて、ステータスまたはステートのためのフィールドまたはカラムが追加される。もう1つのテーブルはクエリテーブルであり、これは、オリジナルテーブルのデータ構造と構造的に完全に一致している。

【0124】

ステップ704において、エクスポートされた履歴データがワークシート内にインポートされ、ステータスフィールドまたはステートフィールドの内容が「Committed」に設定される。

【0125】

ステップ705において、エクスポートされた履歴データがクエリテーブル内にインポートされる。

【0126】

ステップ706において、トランザクション追跡モジュールが、ワークシートのトランザクション変更情報を追跡するように構成される。

【0127】

ステップ707において、トランザクションコンセンサスイベント処理コードがアプリケーション層に記述される。ブロックチェーンがトランザクションオペレーションに成功すると、アプリケーション層コンセンサス結果がメッセージモードによって通知され、アプリケーション層は、ビジネスロジックに従って後続の処理モードを決定する。

【0128】

ステップ708において、別の新たなブロックチェーンについて、ブロックチェーン適応コードが記述される。適応コードは主として、新たなブロックチェーンにイベントを書き込むためのコード、および新たなブロックチェーンのデータ変更オペレーションをリスンし、変更を処理するためのコードを含む。

【0129】

データベースアプリケーションにブロックチェーン技術を利用することにとって最大の技術的課題の1つは、アーキテクチャの非互換性である。データベースアプリケーションと、場合によってはビジネスプロセスでさえも、ブロックチェーンの特徴に適応させる必要がある。

【0130】

本発明の実施形態により、データコンセンサスを得るためにブロックチェーン上に載せるべきある特定の重要なデータをアプリケーションがシームレスに選択するとともにデータの他の部分をアプリケーションがプライベートに維持することができるように、アプリケーションが開発または修正されることになる。有利には、この能力を用いて既存のアプリケーションを増強することに、コードの大幅な修正は必要ない。同時に、データの一貫性が確実なものになり得る。上で説明した実施形態の少なくとも一部は、ブロックチェーン技術を活用すると同時にブロックチェーンの複雑さを回避して、アプリケーションがシングルデータセンタアプリケーションからグローバル分散型アプリケーションに直接拡張されることを可能にする。本発明の実施形態は、ある特定のクラスのアプリケーションのアプリケーション開発およびデプロイメントを簡単にし、市場投入までの時間をさらにスピードアップすることが可能である。

【0131】

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

【符号の説明】

【0132】

100 ソフトウェアシステム
101 クライアントアプリケーション、デバイス実行アプリケーション
102 データベースプロキシサービス、データベースインターフェースまたはデータベースプロキシ
103 データベースワーキングテーブル、一時ワーキングテーブル、ワークテーブル
104 プライベートテーブル
105 クエリテーブル
106 トランザクショントラッカコンポーネント、データトラッキングモジュール
107 ブロックチェーンライタコンポーネント、ブロックチェーン書込みサービスコンポーネント、ブロックチェーンライタモジュール
108 ブロックチェーンリスナサービスコンポーネント、ブロックチェーンリスナモジュール
109 リボークコールバックサービス
110 ブロックチェーン、ブロックチェーンシステム
110aから110e ノード
111 ローカルデータベース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【手続補正書】

【提出日】2020-10-02

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

データベース内とブロックチェーン内でトランザクションを同時に処理する方法であって、
a)前記トランザクションに従って、前記データベース内の第1のテーブルを修正するステップと、
b)前記トランザクションに対応するデータオペレーションレコードを構成し、コンセンサス投票のために前記ブロックチェーンに挿入するステップと、
c)前記コンセンサス投票の結果が成功であるときは、前記データベース内の第2のテーブルを前記トランザクションに応じて修正することによって、前記トランザクションをコミットし、そうでない場合は、前記トランザクションをロールバックし、それにより、前記第2のテーブルを変更されないままにするステップと、
新たなブロックが前記ブロックチェーンに同期された後で、
ブロックチェーンリスナサービスコンポーネントを使用して、前記新たなブロックの内容からデータ変更ログを取り出すステップと、
前記データ変更ログを対応するデータベース変更コマンドに変換するステップと、
前記データベース変更コマンドを前記データベース内で実行するステップと
を含む、方法。

【請求項2】

前記第1のテーブルを前記修正するステップが、ステータスカラムを1組の所定の値のうちの1つに設定することを含む、請求項1に記載の方法。

【請求項3】

前記1組の所定の値が、「confirmed」、「insert pending」、「update pending」、および「delete pending」を含む、請求項2に記載の方法。

【請求項4】

【請求項5】

【請求項6】

【請求項7】

前記第1のテーブルを前記修正するステップが、前記データベースとデータを交換するアプリケーションによって開始される、請求項1に記載の方法。

【請求項8】

【請求項9】

データベーストランザクション内のトランザクションをブロックチェーン内のトランザクションと同期させる方法であって、
a)書込みコマンドを受領するステップと、
b)前記書込みコマンドを受領したことに応答して、
i)一時ワーキングテーブルに書き込むステップと、
ii)コンセンサス投票のために対応する書込み要求を前記ブロックチェーンにサブミットするステップと、
c)前記コンセンサス投票の結果を受領したときは、前記書込みコマンドに従ってクエリテーブルを修正し、そうでない場合は、前記クエリテーブルを変更されないままにするステップと、
d)新たなブロックが前記ブロックチェーンに同期された後で、
ブロックチェーンリスナサービスコンポーネントを使用して、前記新たなブロックの内容からデータ変更ログを取り出すステップと、
前記データ変更ログを対応するデータベース変更コマンドに変換するステップと、
前記データベース変更コマンドを前記データベース内で実行するステップと
を含む、方法。

【請求項10】

【請求項11】

【請求項12】

データベースとブロックチェーンを同期させるためのシステムであって、プロセッサを備え、前記プロセッサが、メモリ内に格納された命令を実行し、それによって、前記データベースに書き込むべきデータを含む書込み要求をアプリケーションから受領すると、前記プロセッサが、
a)前記データベース内のワーキングテーブルに前記データを書き込むステップと、
b)コンセンサス投票のためにデータオペレーションレコードを前記ブロックチェーンにサブミットするステップと、
c)前記コンセンサス投票の結果の成功を示す標識を受領したときは、前記データベース内のクエリテーブルに前記データを書き込み、そうでない場合は、前記クエリテーブルを変更されないままにするステップと、
d)新たなブロックが前記ブロックチェーンに同期された後で、
ブロックチェーンリスナサービスコンポーネントを使用して、前記新たなブロックの内容からデータ変更ログを取り出すステップと、
前記データ変更ログを対応するデータベース変更コマンドに変換するステップと、
前記データベース変更コマンドを前記データベース内で実行するステップと
を実施する、システム。

【請求項13】

【請求項14】

前記1組の所定の値が、「confirmed」、「insert pending」、「update pending」、および「delete pending」を含む、請求項13に記載のシステム。

【請求項15】

【請求項16】

【請求項17】

【請求項18】

【請求項19】

読出しコマンドを受領すると、前記プロセッサが前記クエリテーブルからデータを読み出す、請求項12に記載のシステム。

【請求項20】

【請求項21】