(57)【要約】      （修正有）【課題】ブロックチェーンの拡張を可能にする、トランザクション処理システムおよび方法を提供する。【解決手段】トランザクション処理システムは、ルートチェーンと、複数のリーフチェーンと、ルートチェーン及び複数のリーフチェーンを中継するための少なくとも１つのリレイヤとを含む。リレイヤは、複数のリーフチェーンのうち第１リーフチェーンから第２リーフチェーンへの送金要求を、第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトと、ルートチェーンが含む第１リーフチェーンの第１リーフチェーンコントラクトとの間の中継及びルートチェーンが含む第２リーフチェーンの第２リーフチェーンコントラクトと第２リーフチェーンが含む第１リーフチェーンマネージャコントラクトとの間の中継によって処理する。【選択図】図４
2020109617.tif 000002
【特許請求の範囲】
【請求項１】
ルートチェーンと、複数のリーフチェーンと、前記ルートチェーン及び前記複数のリーフチェーン間を中継するための少なくとも１つのリレイヤとを含むトランザクション処理システムであって、
前記ルートチェーンは、前記複数のリーフチェーンそれぞれのためのリーフチェーンコントラクトと、前記ルートチェーンのためのルートチェーンマネージャコントラクトとを含み、
前記複数のリーフチェーンは、それぞれ対応するリーフチェーンマネージャコントラクトを含み、
前記リレイヤは、
前記複数のリーフチェーンのうち第１リーフチェーンから第２リーフチェーンへの送金要求を、（１）前記第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトと前記ルートチェーンが含む前記第１リーフチェーンの第１リーフチェーンコントラクトとの間の中継、および（２）前記ルートチェーンが含む前記第２リーフチェーンの第２リーフチェーンコントラクトと前記第２リーフチェーンが含む第２リーフチェーンマネージャコントラクトとの間の中継によって処理する、
トランザクション処理システム。
【請求項２】
前記リレイヤは、
前記複数のリーフチェーンそれぞれまたは割り当てられたリーフチェーンで生成される取引、および前記ルートチェーンで生成される取引を収集するプロデューサ、および
前記第１リーフチェーンの第１リーフチェーンマネージャコントラクトからの送金要求を、（１）前記ルートチェーンが含む前記第１リーフチェーンの第１リーフチェーンコントラクトに伝達するか、または（２）前記ルートチェーンの第２リーフチェーンコントラクトからの送金要求を前記第２リーフチェーンの第２リーフチェーンマネージャコントラクトに伝達するインタチェーンコンシューマ
を含む、請求項１に記載のトランザクション処理システム。
【請求項３】
前記リレイヤは、
前記プロデューサが収集する取引をキューに記録して順に前記インタチェーンコンシューマに提供するキューサーバ、および
前記送金要求の伝達を保障するために障害を処理するインタチェーンフェイルオーバ
をさらに含む、請求項２に記載のトランザクション処理システム。
【請求項４】
前記ルートチェーンマネージャコントラクトは、
前記複数のリーフチェーンそれぞれで発給されたコインの総量を、送金要求された情報を利用して分析することによって、送金要求が正常であるか否かを決定し、
正常であると決定された送金要求をブロックに記録する、
請求項１に記載のトランザクション処理システム。
【請求項５】
前記ルートチェーンマネージャコントラクトは、
前記複数のリーフチェーンそれぞれからの前記リレイヤを経た送金完了要求を、前記送金要求の送金要求記録を利用して処理し、
前記送金要求記録を削除し、
対応するリーフチェーンに前記リレイヤを経て送金完了を要求する、
請求項４に記載のトランザクション処理システム。
【請求項６】
前記ルートチェーンマネージャコントラクトは、
新たなリーフチェーンが追加される場合、前記ルートチェーンに実現される前記新たなリーフチェーンのリーフチェーンコントラクトのアドレスを登録し、
前記ルートチェーンのリーフチェーンコントラクトにアクセス可能なリレイヤユーザを追加する、
請求項１に記載のトランザクション処理システム。
【請求項７】
前記第１リーフチェーンマネージャコントラクトは、
前記第１リーフチェーンに実現される新たなサービスのためのサービスコントラクトのアドレスを登録し、
前記ルートチェーンマネージャコントラクトは、
前記サービスコントラクトのアドレスをさらに登録する、
請求項６に記載のトランザクション処理システム。
【請求項８】
前記第１リーフチェーンマネージャコントラクトは、
前記第１リーフチェーンの第１サービスに対して実現された第１サービスコントラクトによる第１ユーザの送金要求を受信して前記第１リーフチェーンのブロックに記録した後、前記受信した送金要求は前記リレイヤを経て前記ルートチェーンに伝達させ、
前記ルートチェーンから前記リレイヤを経て伝達される送金完了要求にしたがって前記第１リーフチェーンの全体通貨量を調節する、
請求項１に記載のトランザクション処理システム。
【請求項９】
前記第１リーフチェーンマネージャコントラクトは、
前記送金要求による交換取引ハッシュを生成し、
前記交換取引ハッシュ、前記第１ユーザの識別子、前記第１サービスの識別子、前記送金要求の対象となる第２サービスの識別子、前記送金要求の対象となる第２ユーザの識別子、および固有値を含む送金要求記録を生成し、
前記固有値は、前記送金要求に対応する要求時刻、前記送金要求に対応するリーフチェーンである前記第１リーフチェーンの識別子、および前記ブロックの識別子の結合によって唯一の値として生成される、
請求項８に記載のトランザクション処理システム。
【請求項１０】
前記第１リーフチェーンマネージャコントラクトは、
前記第１ユーザの送金要求の受信に応答して前記第１ユーザの残高から送金要求された金額を差し引き、差し引いた金額が使用できないようにロックを設定する、
請求項８に記載のトランザクション処理システム。
【請求項１１】
前記第１リーフチェーンマネージャコントラクトは、
前記送金要求が失敗するとき、前記ロックされた金額を解除して前記第１ユーザに返還する、
請求項１０に記載のトランザクション処理システム。
【請求項１２】
前記少なくとも１つのリレイヤは、前記複数のリーフチェーンそれぞれに対応するリレイヤおよび前記ルートチェーンに対応するリレイヤを含む、
請求項１０に記載のトランザクション処理システム。
【請求項１３】
前記複数のリーフチェーンそれぞれに対応するリレイヤは、予め設定された時間周期ごとに対応するリーフチェーンが動的に変更される、
請求項１２に記載のトランザクション処理システム。
【請求項１４】
リレイヤのトランザクション処理方法であって、
少なくとも１つのプロセッサにより、第１リーフチェーンの第１サービスから第２リーフチェーンの第２サービスへの第１送金要求を、前記第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトから受信する段階、
前記少なくとも１つのプロセッサにより、前記受信した第１送金要求を、ルートチェーンが含む前記第１リーフチェーンの第１リーフチェーンコントラクトによって呼び出す（ｉｎｖｏｋｅ）段階、
前記少なくとも１つのプロセッサにより、前記ルートチェーンが含む前記第２リーフチェーンの第２リーフチェーンコントラクトから前記第１送金要求に対応する第２送金要求を受信する段階、および
前記少なくとも１つのプロセッサにより、前記受信した第２送金要求を、前記第２リーフチェーンが含む第２リーフチェーンマネージャコントラクトによって呼び出す（ｉｎｖｏｋｅ）段階
を含む、トランザクション処理方法。
【請求項１５】
前記少なくとも１つのプロセッサにより、前記第２リーフチェーンマネージャコントラクトから前記第２送金要求に対応する第１送金完了要求を受信する段階、
前記少なくとも１つのプロセッサにより、前記受信した第１送金完了要求を、ルートチェーンが含む前記第２リーフチェーンの前記第２リーフチェーンコントラクトによって呼び出す（ｉｎｖｏｋｅ）段階、
前記少なくとも１つのプロセッサにより、前記ルートチェーンが含む前記第１リーフチェーンの前記第１リーフチェーンコントラクトから前記第１送金完了要求に対応する第２送金完了要求を受信する段階、および
前記少なくとも１つのプロセッサにより、前記受信した第２送金完了要求を、前記第１リーフチェーンの前記第１リーフチェーンマネージャコントラクトによって呼び出す（ｉｎｖｏｋｅ）段階
をさらに含む、請求項１４に記載のトランザクション処理方法。
【請求項１６】
前記第１送金要求は、前記第１サービスの第１ユーザから前記第２サービスの第２ユーザへの送金要求を含み、
前記送金要求によるコインは、前記第１リーフチェーンが含む前記第１リーフチェーンマネージャコントラクトによって前記第１ユーザの残高から差し引かれ、使用できないようにロックされ、エスクロコントラクトに送金要求記録として記録される、
請求項１４に記載のトランザクション処理方法。
【請求項１７】
前記第１送金要求を受信する段階または前記第２送金要求を受信する段階は、
前記リレイヤが含むプロデューサの取引収集によって前記第１送金要求を受信するか前記第２送金要求を受信し、
前記第１送金要求を呼び出す（ｉｎｖｏｋｅ）段階または前記第２送金要求を呼び出す（ｉｎｖｏｋｅ）段階は、
前記リレイヤがさらに含むインタチェーンコンシューマによって前記第１送金要求を呼び出す（ｉｎｖｏｋｅ）か、または前記第２送金要求を呼び出す（ｉｎｖｏｋｅ）する、
請求項１４に記載のトランザクション処理方法。
【請求項１８】
前記ルートチェーンが含むルートチェーンマネージャコントラクトが、複数のリーフチェーンそれぞれで発給されたコインの総量を送金要求された情報を利用して分析することによって前記第１送金要求が正常であるか否かを決定し、正常であると決定された前記第１送金要求をブロックに記録し、前記第１送金要求に対応する前記第２送金要求を前記第２リーフチェーンコントラクトによって前記リレイヤに送信する、
請求項１４に記載のトランザクション処理方法。
【請求項１９】
請求項１４〜１８のうちのいずれか一項に記載のトランザクション処理方法をコンピュータ装置に実行させる、コンピュータプログラム。
【請求項２０】
請求項１４〜１８のうちのいずれか一項にトランザクション処理方法をコンピュータ装置に実行させるためのコンピュータプログラムが記録されている、コンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
以下の説明は、ブロックチェーンの拡張を可能にするトランザクション処理システムおよび方法に関する。
【背景技術】
【０００２】
ブロックチェーン（ｂｌｏｃｋ−ｃｈａｉｎ）とは、電子台帳（ｅｌｅｃｔｒｏｎｉｃ  ｌｅｄｇｅｒ）であって、トランザクションのためのブロックで構成されたコンピュータ基盤の分散型、Ｐ２Ｐ（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）のシステムで実現される。各トランザクション（Ｔｒａｎｓａｃｔｉｏｎ：Ｔｘ）は、ブロックチェーンシステム内の参加者同士にデジタル資産の制御送信をエンコードするデータ構造であり、少なくとも１つの入力と少なくとも１つの出力を含む。各ブロックには以前ブロックのハッシュが含まれ、該当のブロックはともに連結し、すべてのブロックチェーンに記録されたすべてのトランザクションの永久的かつ不変的な（ｕｎａｌｔｅｒａｂｌｅ）記録を生成する。例えば、特許文献１は、ブロックチェーン基盤のユーザ定義貨幣取引システムおよびその動作方法を開示している。このようなブロックチェーン自体は、スケールアウト（ｓｃａｌｅ  ｏｕｔ）できない。例えば、ブロックチェーンネットワークでブロックを生成するためのノードを追加しても、ブロック生成のための合意の費用が増加するだけで、トランザクションに対するブロック生成速度は増加しない。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】韓国公開特許第１０−２０１８−０１１３１４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ルートチェーンを基盤としてリーフチェーンを追加する方式により、スケールアウトが可能なトランザクション処理システムおよび方法を提供する。
【課題を解決するための手段】
【０００５】
トランザクション処理システムは、ルートチェーン（Ｒｏｏｔ  Ｃｈａｉｎ）と、複数のリーフチェーン（Ｌｅａｆ  Ｃｈａｉｎ）と、ルートチェーン及び複数のリーフチェーンを中継するための少なくとも１つのリレイヤ（Ｒｅｌａｙｅｒ）とを含み、ルートチェーンは、複数のリーフチェーンそれぞれのためのリーフチェーンコントラクトと、ルートチェーンのためのルートチェーンマネージャコントラクトとを含み、複数のリーフチェーンは、それぞれ対応するリーフチェーンマネージャコントラクトを含み、前記リレイヤは、前記複数のリーフチェーンのうち第１リーフチェーンから第２リーフチェーンへの送金要求を、（１）前記第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトと前記ルートチェーンが含む前記第１リーフチェーンの第１リーフチェーンコントラクトとの間の中継、および（２）前記ルートチェーンが含む前記第２リーフチェーンの第２リーフチェーンコントラクトと前記第２リーフチェーンが含む第１リーフチェーンマネージャコントラクトとの間の中継によって処理する、トランザクション処理システムを提供する。
【０００６】
一側によると、前記リレイヤは、前記複数のリーフチェーンそれぞれまたは割り当てられたリーフチェーンで生成される取引および前記ルートチェーンで生成される取引を収集するプロデューサ、および前記第１リーフチェーンの第１リーフチェーンマネージャコントラクトからの送金要求を、（１）前記ルートチェーンが含む前記第１リーフチェーンの第１リーフチェーンコントラクトに伝達するか、または（２）前記ルートチェーンの第２リーフチェーンコントラクトからの送金要求を前記第２リーフチェーンの第２リーフチェーンマネージャコントラクトに伝達するインタチェーンコンシューマを含んでよい。
【０００７】
他の側面によると、前記リレイヤは、前記プロデューサが収集する取引をキューに記録して前記インタチェーンコンシューマに順に提供するキューサーバ、および前記送金要求の伝達を保障するために障害を処理するインタチェーンフェイルオーバをさらに含んでよい。
【０００８】
また他の側面によると、前記ルートチェーンマネージャコントラクトは、前記複数のリーフチェーンそれぞれで発給されたコインの総量を、送金要求された情報を利用して分析することで、送金要求が正常であるか否かを決定し、正常であると決定された送金要求をブロックに記録してよい。
【０００９】
また他の側面によると、前記ルートチェーンマネージャコントラクトは、前記複数のリーフチェーンそれぞれからの前記リレイヤを経た送金完了要求を前記送金要求の送金要求記録を利用して処理し、前記送金要求記録を削除し、対応するリーフチェーンに前記リレイヤを経て送金完了を要求してよい。
【００１０】
また他の側面によると、前記ルートチェーンマネージャコントラクトは、新たなリーフチェーンが追加される場合、前記ルートチェーンに実現される前記新たなリーフチェーンのリーフチェーンコントラクトのアドレスを登録し、前記ルートチェーンのリーフチェーンコントラクトにアクセス可能なリレイヤユーザを追加してよい。
【００１１】
また他の側面によると、前記第１リーフチェーンマネージャコントラクトは、前記第１リーフチェーンに実現される新たなサービスのためのサービスコントラクトのアドレスを登録し、前記ルートチェーンマネージャコントラクトは、前記サービスコントラクトのアドレスをさらに登録してよい。
【００１２】
また他の側面によると、前記第１リーフチェーンマネージャコントラクトは、前記第１リーフチェーンの第１サービスに対して実現された第１サービスコントラクトにより第１ユーザの送金要求を受信して前記第１リーフチェーンのブロックに記録した後、前記受信した送金要求を前記リレイヤを経て前記ルートチェーンに伝達させ、前記ルートチェーンから前記リレイヤを経て伝達される送金完了要求にしたがって前記第１リーフチェーンの総コイン量を調節してよい。
【００１３】
また他の側面によると、前記第１リーフチェーンマネージャコントラクトは、前記送金要求による交換取引ハッシュを生成し、前記交換取引ハッシュ、前記第１ユーザの識別子、前記第１サービスの識別子、前記送金要求の対象となる第２サービスの識別子、前記送金要求の対象となる第２ユーザの識別子、送金金額、および要求時間のうちの少なくとも１つを含む送金要求記録を生成してよい。
【００１４】
また他の側面によると、前記第１リーフチェーンマネージャコントラクトは、前記第１ユーザの送金要求の受信に応答して前記第１ユーザの残高から送金要求された金額を差し引き、差し引いた金額が使用されないようにロックを設定してよい。
【００１５】
また他の側面によると、前記第１リーフチェーンマネージャコントラクトは、前記送金要求が失敗したとき、前記ロックされた金額を解除して前記第１ユーザに返還してよい。
【００１６】
また他の側面によると、前記少なくとも１つのリレイヤは、前記複数のリーフチェーンそれぞれに対応するリレイヤおよび前記ルートチェーンに対応するリレイヤを含んでよい。
【００１７】
さらに他の側面によると、前記複数のリーフチェーンそれぞれに対応するリレイヤは、対応するリーフチェーンが予め設定された時間周期ごとに動的に変更されてよい。
【００１８】
リレイヤのトランザクション処理方法であって、少なくとも１つのプロセッサにより、第１リーフチェーンの第１サービスから第２リーフチェーンの第２サービスへの第１送金要求を前記第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトから受信する段階、前記少なくとも１つのプロセッサにより、前記受信した第１送金要求をルートチェーンが含む前記第１リーフチェーンの第１リーフチェーンコントラクトに呼び出す（ｉｎｖｏｋｅ）段階、前記少なくとも１つのプロセッサにより、前記ルートチェーンが含む前記第２リーフチェーンの第２リーフチェーンコントラクトからの前記第１送金要求に対応する第２送金要求を受信する段階、および前記少なくとも１つのプロセッサにより、前記受信した第２送金要求を前記第２リーフチェーンが含む第２リーフチェーンマネージャコントラクトに呼び出す（ｉｎｖｏｋｅ）段階を含む、トランザクション処理方法を提供する。
【００１９】
コンピュータ装置と結合して前記トランザクション処理方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録された、コンピュータプログラムを提供する。
【００２０】
前記トランザクション処理方法をコンピュータ装置に実行させるためのコンピュータプログラムが記録されている、コンピュータ読み取り可能な記録媒体を提供する。
【発明の効果】
【００２１】
ルートチェーンを基盤としてリーフチェーンを追加する方式により、スケールアウトが可能なトランザクション処理システムおよび方法を提供することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施形態における、ネットワーク環境の例を示した図である。
【図２】本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。
【図３】本発明の一実施形態における、ブロックチェーンの拡張を可能にするトランザクション処理システムの概括的な構成の例を示した図である。
【図４】本発明の一実施形態における、トランザクション処理システムの細部構成の例を示した図である。
【図５】本発明の一実施形態における、新たなリーフチェーンを追加する過程の例を示したフローチャートである。
【図６】本発明の一実施形態における、新たなサービスを追加する過程の例を示したフローチャートである。
【図７】本発明の一実施形態における、サービスにコインを発行する過程の例を示したフローチャートである。
【図８】本発明の一実施形態における、コイン交換過程の例を示したフローチャートである。
【図９】本発明の一実施形態における、各チェーン間のスマートコントラクトによるコイン交換データの流れを示した図である。
【図１０】本発明の一実施形態における、リレイヤのトランザクション処理方法の例を示した図である。
【発明を実施するための形態】
【００２３】
以下、実施形態について、添付の図面を参照しながら詳しく説明する。
【００２４】
本発明の実施形態に係るトランザクション処理システムは、少なくとも１つのコンピュータ装置によって実現されてよい。コンピュータ装置においては、本発明の一実施形態に係るコンピュータプログラムがインストールおよび実行されてよく、コンピュータ装置は、実行するコンピュータプログラムの制御にしたがって本発明の一実施形態に係るトランザクション処理方法を実行してよい。上述したコンピュータプログラムは、コンピュータ装置と結合してトランザクション処理方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録されてよい。ここで、説明したコンピュータプログラムは、独立する１つのプログラムパッケージの形態であってもよいし、独立する１つのプログラムパッケージの形態がコンピュータ装置に予めインストールされてオペレーティングシステムや他のプログラムパッケージと連係する形態であってもよい。
【００２５】
図１は、本発明の一実施形態に係る、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。また、図１のネットワーク環境は、本実施形態に適用可能な環境のうちの１つの例を説明したものに過ぎず、本実施形態に適用可能な環境が図１のネットワーク環境に限定されることはない。
【００２６】
複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、ＰＣ（ｐｅｒｓｏｎａｌ  ｃｏｍｐｕｔｅｒ）、ノート型ＰＣ、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｐｌａｙｅｒ）、タブレットなどがある。一例として、図１では、電子機器１（１１０）の例としてスマートフォンを示しているが、本発明の実施形態において、電子機器１（１１０）は、実質的に無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信することのできる多様な物理的なコンピュータ装置のうちの１つを意味してよい。
【００２７】
通信方式が限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を利用する通信方式だけではなく、機器間の近距離無線通信が含まれてよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ  ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター・バスネットワーク、ツリーまたは階層的ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。
【００２８】
サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。例えば、サーバ１５０は、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０にサービス（一例として、映像通話サービス、金融サービス、決済サービス、ソーシャルネットワークサービス、メッセージングサービス、検索サービス、メールサービス、コンテンツ提供サービス、および／または質問および返答サービスなど）を提供するシステムであってよい。
【００２９】
図２は、本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。上述した複数の電子機器１１０、１２０、１３０、１４０それぞれやサーバ１５０、１６０それぞれは、図２に示されたコンピュータ装置２００によって実現されてよく、本発明の実施形態に係る方法は、このようなコンピュータ装置２００によって実行されてよい。
【００３０】
このとき、図２に示すように、コンピュータ装置２００は、メモリ２１０、プロセッサ２２０、通信インタフェース２３０、および入力／出力インタフェース２４０を含んでよい。メモリ２１０は、コンピュータ読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、ディスクドライブのような永続的大容量記録装置を含んでよい。ここで、ＲＯＭやディスクドライブのような永続的大容量記録装置は、メモリ２１０とは区分される別の永続的記録装置としてコンピュータ装置２００に含まれてもよい。また、メモリ２１０には、オペレーティングシステムと、少なくとも１つのプログラムコードが記録されてよい。このようなソフトウェア構成要素は、メモリ２１０とは別のコンピュータ読み取り可能な記録媒体からメモリ２１０にロードされてよい。このような別のコンピュータ読み取り可能な記録媒体は、フロッピードライブ、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭドライブ、メモリカードなどのコンピュータ読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータ読み取り可能な記録媒体ではない通信インタフェース２３０を通じてメモリ２１０にロードされてもよい。例えば、ソフトウェア構成要素は、ネットワーク１７０を介して受信されるファイルによってインストールされるコンピュータプログラムに基づいてコンピュータ装置２００のメモリ２１０にロードされてよい。
【００３１】
プロセッサ２２０は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１０または通信インタフェース２３０によって、プロセッサ２２０に提供されてよい。例えば、プロセッサ２２０は、メモリ２１０のような記録装置に記録されたプログラムコードにしたがって受信される命令を実行するように構成されてよい。
【００３２】
通信インタフェース２３０は、ネットワーク１７０を介してコンピュータ装置２００が他の装置（一例として、上述した記録装置）と互いに通信するための機能を提供してよい。一例として、コンピュータ装置２００のプロセッサ２２０がメモリ２１０のような記録装置に記録されたプログラムコードにしたがって生成した要求や命令、データファイルなどが、通信インタフェース２３０の制御にしたがってネットワーク１７０を介して他の装置に伝達されてよい。これとは逆に、他の装置からの信号や命令、データ、ファイルなどが、ネットワーク１７０を介してコンピュータ装置２００の通信インタフェース２３０を通じてコンピュータ装置２００に受信されてよい。通信インタフェース２３０を通じて受信された信号や命令、データなどは、プロセッサ２２０やメモリ２１０に伝達されてよく、ファイルなどは、コンピュータ装置２００がさらに含むことのできる記録媒体（上述した永続的記録装置）に記録されてよい。
【００３３】
入力／出力インタフェース２４０は、入力／出力装置２５０とのインタフェースのための手段であってよい。例えば、入力装置は、マイク、キーボード、カメラ、またはマウスなどの装置を、出力装置は、ディスプレイやスピーカのような装置を含んでよい。他の例として、入力／出力インタフェース２４０は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。入力／出力装置２５０は、コンピュータ装置２００と１つの装置で構成されてもよい。
【００３４】
また、他の実施形態において、コンピュータ装置２００は、図２の構成要素よりも少ないか多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、コンピュータ装置２００は、上述した入力／出力装置２５０のうちの少なくとも一部を含むように実現されてもよいし、トランシーバやデータベースなどのような他の構成要素をさらに含んでもよい。
【００３５】
図３は、本発明の一実施形態における、ブロックチェーンの拡張を可能にするトランザクション処理システムの概括的な構成の例を示した図である。図３は、ルートチェーン（Ｒｏｏｔ  Ｃｈａｉｎ）３１０、リーフチェーンＡ（Ｌｅａｆ  Ｃｈａｉｎ  Ａ）３２０、リーフチェーンＢ（Ｌｅａｆ  Ｃｈａｉｎ  Ｂ）３３０、およびリレイヤ（Ｒｅｌａｙｅｒ）３４０を含むトランザクション処理システム３００の例を示している。ルートチェーン３１０とリーフチェーン３２０および３３０は、複数のコンピュータ装置が連結するネットワークを形成してよく、リレイヤ３４０は、少なくとも１つのコンピュータ装置によって実現されてよい。
【００３６】
トランザクション処理システム３００において、ルートチェーン３１０は、絶対信頼システムであってよく、リーフチェーン３２０および３３０それぞれは、ルートチェーン３１０に自身が信頼システムであるということを証明しなければならない。このとき、リーフチェーン３２０および３３０それぞれは個別のサービスと連係してよく、新たなサービスが追加されるときには新たなリーフチェーンも追加されてよい。言い換えれば、図３の実施形態では、２つのリーフチェーン３２０および３３０を示しているが、３つ以上のリーフチェーンを含んでもよく、これはブロックチェーンの拡張が可能であることを意味してよい。ここで、「サービス」は、同一または互いに異なる主体がネットワークを介して自身のユーザに提供するオンラインサービスを含んでよい。一例として、互いに異なる銀行が提供するインターネットバンキングサービスそれぞれに対応するリーフチェーンが構成されてよい。また、互いに異なるソーシャルネットワークサービスそれぞれに対応するリーフチェーンが構成されてもよい。リーフチェーン３２０および３３０それぞれは、ルートチェーン３１０にブロックのハッシュを記録して信頼を認められなければならない。一例として、マークル・ツリー・ルート・ハッシュ（ｍｅｒｋｌｅ  ｔｒｅｅ  ｒｏｏｔ  ｈａｓｈ）が活用されてよい。
【００３７】
ルートチェーン３１０ではユーザ間のコイン交換は行わず、コイン交換は、リーフチェーン３２０および３３０それぞれの内部および／またはリーフチェーン３２０および３３０間でなされてよい。このとき、リーフチェーン３２０および３３０間のコイン交換は、リレイヤ３４０を経てルートチェーン３１０が仲裁および管理してよい。リーフチェーン３２０および３３０それぞれには、少なくとも１つの分散型アプリケーション（Ｄｅｃｅｎｔｒａｌｉｚｅｄ  Ａｐｐｌｉｃａｔｉｏｎ：ＤＡｐｐ）が含まれてよい。ここで、分散型アプリケーションとは、バックエンドコードが脱中央化されたＰ２Ｐネットワーク上で巡回（あるいは、データ呼出および登録をブロックチェーンデータベースに行う）され、これをフロントエンドからインタフェースに提供するアプリケーションを意味する。このとき、リーフチェーン３２０および３３０それぞれでは、分散型アプリケーションの必要にしたがい、チェーンまたはコイン交換とは関係のないスマートコントラクト（ｓｍａｒｔ  ｃｏｎｔｒａｃｔ）を実現してよく、これをルートチェーン３１０では関与しない。リーフチェーン３２０および３３０それぞれでチェーン間のコイン交換のためのプロトコルを有するスマートコントラクトを実現しようとする場合には、ルートチェーン３１０からスマートコントラクトの実現のための許可をもらわなければならない。ルートチェーン３１０の許可がないスマートコントラクトによるチェーン間ではコイン交換ができないように制限されてよい。
【００３８】
リーフチェーン３２０および３３０それぞれの内部でのコイン交換は、ルートチェーン３１０を経由する必要がないため、リーフチェーン３２０および３３０それぞれで処理されてよく、処理された内容が含まれたすべてのブロックの要約情報（一例として、上述したマークル・ツリー・ルート・ハッシュ）をルートチェーン３１０に記録してよい。この反面、リーフチェーン３２０および３３０間のコイン交換は、ルートチェーン３１０を経由しなければならず、リーフチェーン３２０および３３０それぞれのブロックとルートチェーン３１０のブロックには、コイン交換の処理に関する内容が記録されなければならない。このとき、リーフチェーン３２０および３３０間のコイン交換は、リレイヤ３４０を経て行われてよい。
【００３９】
図４は、本発明の一実施形態における、トランザクション処理システムの細部構成の例を示した図である。トランザクション処理システム３００は、図４に示すように、１つのルートチェーン３１０と複数のリーフチェーン３２０および３３０、さらにリレイヤ３４０で構成されてよい。
【００４０】
ルートチェーン３１０は、ルートチェーン３１０のためのスマートコントラクトであるルートチェーンマネージャコントラクト（Ｒｏｏｔ  Ｃｈａｉｎ  Ｍａｎａｇｅｒ  Ｃｏｎｔｒａｃｔ）４１１を含んでよく、トランザクション処理システム３００に含まれる複数のリーフチェーン３２０および３３０それぞれのためのスマートコントラクトを含んでよい。図４の実施形態では、ルートチェーン３１０に、リーフチェーンＡ（Ｌｅａｆ  Ｃｈａｉｎ  Ａ）３２０のためのスマートコントラクトであるリーフチェーンＡコントラクト（Ｌｅａｆ  Ｃｈａｉｎ  Ａ  Ｃｏｎｔｒａｃｔ）４１２とリーフチェーンＢ（Ｌｅａｆ  Ｃｈａｉｎ  Ｂ）３３０のためのスマートコントラクトであるリーフチェーンＢコントラクト（Ｌｅａｆ  Ｃｈａｉｎ  Ｂ  Ｃｏｎｔｒａｃｔ）４１３が含まれる例を示している。
【００４１】
また、リーフチェーン３２０および３３０それぞれは、分散型アプリケーションのためのスマートコントラクトを含んでよい。図４の実施形態では、リーフチェーンＡ３２０には分散型アプリケーションコントラクト（ｄＡｐｐ  Ｃｏｎｔｒａｃｔ）４２１が、リーフチェーンＢ３３０には分散型アプリケーションコントラクト４３１が含まれる例を示している。また、リーフチェーンＡ３２０にはリーフチェーンＡ３２０のためのスマートコントラクトであるリーフチェーンマネージャコントラクト（Ｌｅａｆ  Ｃｈａｉｎ  Ｍａｎａｇｅｒ  Ｃｏｎｔｒａｃｔ）４２２が、リーフチェーンＡ３３０にはリーフチェーンＢ３３０のためのスマートコントラクトであるリーフチェーンマネージャコントラクト４３２がさらに含まれてよい。
【００４２】
リレイヤ３４０は、ルートチェーン３１０とリーフチェーン３２０および３３０のブロック生成を観察しながら、ルートチェーン３１０とリーフチェーン３２０および３３０に記録および／または伝達が要求される情報を呼び出してよい（ｉｎｖｏｋｅ）。文脈上適切である場合には、「呼び出し」は「始動」と言及されてもよい。リレイヤ３４０は、プロデューサ（Ｐｒｏｄｕｃｅｒ）４４１、カフカ（Ｋａｆｋａ）４４２、インタチェーンコンシューマ（ＩｎｔｅｒＣｈａｉｎ  Ｃｏｎｓｕｍｅｒ）４４３、インタチェーンフェイルオーバ（ＩｎｔｅｒＣｈａｉｎ  Ｆａｉｌｏｖｅｒ）４４４、データベース（Ｄａｔａｂａｓｅ）４４５を含んでよい。
【００４３】
プロデューサ４４１は、ルートチェーン３１０を含むすべてのチェーンで新たに生成されたブロックの情報を収集してカフカ４４２に入力してよい。カフカ４４２は、一種のキューサーバであって、収集した情報をキューに記録して順に提供してよい。このとき、インタチェーンコンシューマ４４３は、各チェーン別に呼び出し（ｉｎｖｏｋｅ）が要求されるイベントをフィルタリングしてよい。イベントによっては、複数のフィルタリングが要求されてもよい。インタチェーンコンシューマ４４３は、各チェーンに呼び出し（ｉｎｖｏｋｅ）をするとき、シグニフィケーション（ｓｉｇｎｉｆｉｃａｔｉｏｎ）のためにチェーン別に個別のユーザを生成し、ユーザの権限をスマートコントラクトに記録してよい。
【００４４】
インタチェーンコンシューマ４４３は、以下の（１）〜（７）のようなイベントなどを感知してよい。
【００４５】
（１）リーフチェーンでの送金要求イベント
（１−１）インタチェーンコンシューマ４４３は、リーフチェーンでの送金要求イベントを感知し、ルートチェーンに送金要求内容を伝達してよい。
【００４６】
（２）ルートチェーンでの送金要求イベント
（２−１）インタチェーンコンシューマ４４３は、ルートチェーンでの送金要求イベントを感知し、送金要求を受信するリーフチェーンに送金要求内容を伝達してよい。
【００４７】
（２−２）インタチェーンコンシューマ４４３は、受信するリーフチェーンへの伝達が失敗したとき、送金要求を受信するリーフチェーンの識別情報を含む送金失敗情報をルートチェーンに伝達してよい。
【００４８】
（３）ルートチェーンでの送金要求失敗イベント
（３−１）インタチェーンコンシューマ４４３は、送金を要求したリーフチェーンに送金失敗内容を伝達してよい。
【００４９】
（４）リーフチェーンでの送金完了イベント
（４−１）インタチェーンコンシューマ４４３は、ルートチェーンに送金完了内容を伝達してよい。
【００５０】
（５）ルートチェーンでの送金完了イベント
（５−１）インタチェーンコンシューマ４４３は、送金を要求したリーフチェーンに送金完了内容を伝達してよい。
【００５１】
（６）ルートチェーンでのコイン発行イベント
（６−１）インタチェーンコンシューマ４４３は、コインが発行されるリーフチェーンに発行内容を伝達してよい。
【００５２】
（７）リーフチェーンでのブロック生成イベント
（７−１）インタチェーンコンシューマ４４３は、ルートチェーンにブロックのマークル・ツリー・ルート・ハッシュを伝達してよい。
【００５３】
インタチェーンフェイルオーバ４４４は、（３−１）、（４−１）、（５−１）、（６−１）、および（７−１）が正常に伝達されるように障害克服機能を提供してよく、データベース（Ｄａｔａｂａｓｅ）４４５は、インタチェーンコンシューマ４４３およびインタチェーンフェイルオーバ４４４において受信および／または送信（伝達）した情報を記録するために活用されてよい。
【００５４】
図５は、本発明の一実施形態における、新たなリーフチェーンを追加する過程の例を示したフローチャートである。
【００５５】
段階５１０で、トランザクション処理システム３００は、リーフチェーンを構築してよい。例えば、新たなリーフチェーンは、以下で説明される新たなサービスを追加するために構築されてよい。
【００５６】
段階５２０で、トランザクション処理システム３００は、チェーン間またはコントラクト間のコイン送金を担当するリーフチェーンマネージャコントラクトをリーフチェーンに実現してよい。
【００５７】
段階５３０で、トランザクション処理システム３００は、該当のリーフチェーンを処理することのできるコントラクト（以下、リーフチェーンコントラクト）をルートチェーンに実現してよい。
【００５８】
段階５４０で、トランザクション処理システム３００は、実現されたルートチェーンのリーフチェーンコントラクトアドレスをルートチェーンマネージャコントラクトに登録してよい。
【００５９】
段階５５０で、トランザクション処理システム３００は、ルートチェーンのリーフチェーンコントラクトにアクセス可能なリレイヤユーザを追加してよい。
【００６０】
段階５６０で、トランザクション処理システム３００は、リーフチェーンのリーフチェーンマネージャコントラクトにアクセス可能なリレイヤユーザを追加してよい。
【００６１】
このとき、段階５５０および段階５６０のリレイヤユーザは、同じユーザであってもよいし、互いに異なるユーザであってもよい。リーフチェーン別、さらにはルートチェーンでも互いに異なる個別のリレイヤユーザを設定して活用することが、保安上で有利となる。ここで、リレイヤユーザは、トランザクション処理システム３００が提供するサービスのアカウントに対応してよい。
【００６２】
図６は、本発明の一実施形態における、新たなサービスを追加する過程の例を示したフローチャートである。
【００６３】
段階６１０で、トランザクション処理システム３００は、該当となるサービスのコントラクトをリーフチェーンに実現してよい。実現されたコントラクトのアドレスは、該当となるサービスを区分するための値として使用されてよい。該当のサービスは、チェーン間のコイン交換プロトコルを備えたコントラクトであってよい。
【００６４】
段階６２０で、トランザクション処理システム３００は、リーフチェーンのリーフチェーンマネージャコントラクトに、該当となるサービスに対して実現されたコントラクトのアドレスを登録してよい。例えば、図５の段階５２０では、チェーン間またはコントラクト間のコイン送金を担当するリーフチェーンマネージャコントラクトをリーフチェーンに実現することについて説明した。このようなリーフチェーンマネージャコントラクトにサービスのためのコントラクトのアドレスが登録されてよい。
【００６５】
段階６３０で、トランザクション処理システム３００は、実現されたコントラクトのアドレスをルートチェーンのルートチェーンマネージャコントラクトに登録してよい。このとき、実現されたコントラクトのアドレスは、ルートチェーンマネージャコントラクトの管理者権限によって登録されてよい。ルートチェーンマネージャコントラクトに、リーフチェーンのサービスに対して実現されたコントラクトのアドレスをルートチェーンに実現された該当のリーフチェーンのリーフチェーンコントラクトとともに登録すれば、ルートチェーンのリーフチェーンコントラクトにもリーフチェーンのサービスに対して実現されたコントラクトのアドレスが該当のリーフチェーンのサービスとして登録されるようになる。
【００６６】
図７は、本発明の一実施形態における、サービスにコインを発行させる過程の例を示したフローチャートである。
【００６７】
段階７１０で、ルートチェーンのルートチェーンマネージャコントラクトは、ルートチェーンに実現された、リーフチェーンコントラクトに登録されたサービスのコントラクトのアドレスに対してコイン発行を要求してよい。例えば、ルートチェーンのルートチェーンマネージャコントラクトは、ルートチェーンに実現されたリーフチェーンコントラクトにより、コインを発行するためのサービスに対するコントラクトのアドレスによって該当のサービスを識別してよく、識別されたサービスに対してコイン発行イベントを発生させてよい。
【００６８】
段階７２０で、インタチェーンコンシューマは、該当のサービスに対するコイン発行イベントを感知し、該当のリーフチェーンのリーフチェーンマネージャコントラクトにサービスのコイン発行を要求してよい。
【００６９】
段階７３０で、リーフチェーンマネージャコントラクトは、該当のサービスを探してコインを発行してよい。このとき、コインは、該当のサービスのコントラクトを実現するときに入力したサービスオペレータ（一例として、図５の段階５６０で追加されたリレイヤユーザ）に発給されてよい。
【００７０】
図８は、本発明の一実施形態における、コイン交換過程の例を示したフローチャートである。同じチェーンの同じサービスでのコイン交換は、該当のリーフチェーンのコイン交換のためのスマートコントラクトで行われてよい。また、同じチェーンの異なるサービス間でのコイン交換は、該当のリーフチェーンのリーフチェーンマネージャコントラクトで行われてよい。例えば、同じチェーンでの第１サービスから第２サービスへの送金は、リーフチェーンマネージャコントラクトが第１サービスの送金要求にしたがって第２サービスのコントラクトのアドレスを呼び出すことによってなされてよい。この反面、異なるチェーン間でのコイン交換は、以下の段階８１０〜８９０によって行われてよい。図８の段階８１０〜８９０は、図４を参照しながら説明したリーフチェーンＡ３２０とリーフチェーンＢ３３０間のコイン交換の例について説明する。
【００７１】
段階８１０で、リーフチェーンＡ３２０は、ユーザａによるリーフチェーンＢ３３０のユーザｂへのコイン交換要求（送金要求）を受信してよい。このとき、リーフチェーンＡ３２０は、ユーザａの残高などを把握し、コイン交換要求が正常な要求である場合には、リーフチェーンＡ３２０のブロックに記録してよい。交換要求されたコイン（送金要求されたコイン）は、リーフチェーンＡ３２０に含まれるリーフチェーンマネージャコントラクトによってユーザａの残高から差し引かれてよく、使用できないようにロック（ｌｏｃｋ）されてよい。例えば、リーフチェーンＡ３２０のリーフチェーンマネージャコントラクトは、送金要求された金額だけユーザａの残高から差し引かれた金額が使用されないようにロックを設定してよい。差し引かれたユーザａの金額に関する情報は、エスクロコントラクトに記録されてよい。このような送金の成功に関する記録は、プロデューサ４４１によってカフカ４４２に記録されてよい。送金要求が正常でない場合、リーフチェーンＡ３２０は、送金要求の失敗内容をブロックに記録してよい。また、リーフチェーンＡ３２０は、送金要求が失敗したときにはイベントを記録しないようにすることにより、送金が発生しないようにしてよい。
【００７２】
段階８２０で、インタチェーンコンシューマ４４３は、リーフチェーンＡ３２０からリーフチェーンＢ３３０への送金要求イベントを感知し、ルートチェーン３１０に該当の送金要求を伝達してよい。送金要求イベントの感知は、プロデューサ４４１の取引収集によって感知されてよく、インタチェーンコンシューマ４４３は、感知された送金要求イベントの感知に応答してルートチェーン３１０に該当の送金要求を伝達してよい。
【００７３】
段階８３０で、ルートチェーン３１０は、リーフチェーンＡ３２０で発給したコインの総量を、送金要求情報に基づいて分析することで、該当の送金要求が正常な要求であるか否かを確認し、該当の送金要求が正常な要求である場合、リーフチェーンＡ３２０からリーフチェーンＢ３３０へのコイン交換要求をブロックに記録してよい。交換要求は、送金するコイン量が使用できないようにロック（ｌｏｃｋ）してよい。また、ルートチェーン３１０は、該当の送金要求が正常な要求でない場合、失敗内容をブロックに記録してよい。失敗と記録された送金要求は、インタチェーンコンシューマ４４３で送金失敗イベントとして感知されてリーフチェーンＡ３２０に伝達されてよく、送金失敗イベントを受信したリーフチェーンＡ３２０は、ロックされたコインを解除してユーザａに返還してよい。
【００７４】
段階８４０で、インタチェーンコンシューマ４４３は、ルートチェーン３１０からリーフチェーンＢ３３０への送金要求イベントを感知し、リーフチェーンＢ３３０に該当の送金要求を伝達してよい。リーフチェーンＢ３３０が正常に動作せずに呼び出し（ｉｎｖｏｋｅ）が失敗した場合には、ルートチェーン３１０にリーフチェーンＢ３３０のシステム異常による伝達失敗内容を送信してよい。失敗と記録された要求は、インタチェーンコンシューマ４４３で送金失敗イベントとして感知されてリーフチェーンＡ３２０に伝達されてよく、送金失敗イベントを受信したリーフチェーンＡ３２０は、ロックされたコインを解除してユーザａに返還してよい。
【００７５】
段階８５０で、リーフチェーンＢ３３０は、該当の送金要求が正常な要求である場合、ユーザｂにコインを送金し、リーフチェーンＢ３３０の総コイン量を送金されたコイン量だけ増加させてよい。送金要求が失敗した場合には、失敗内容をブロックに記録してよい。
【００７６】
段階８６０で、インタチェーンコンシューマ４４３は、リーフチェーンＢの送金完了結果をイベントとして感知し、ハッシュと成功の可否をルートチェーン３１０に伝達してよい。
【００７７】
段階８７０で、ルートチェーン３１０は、送金結果を受信して送金失敗と送金成功に応じて処理してよく、その結果をハッシュとともにブロックに記録してよい。送金が成功した場合、ルートチェーン３１０は、ロックされたコイン送金要求を解除し、リーフチェーンＡ３２０からリーフチェーンＢ３３０への送金を進めてそれぞれのコイン量を変更してよい。送金が失敗した場合、ルートチェーン３１０は、ロックされたコイン送金要求を解除してリーフチェーンＡ３２０に返還してよい。
【００７８】
段階８８０で、インタチェーンコンシューマ４４３は、ルートチェーン３１０で処理した送金結果イベントを感知し、リーフチェーンＡ３２０にその結果を伝達してよい。
【００７９】
段階８９０で、リーフチェーンＡ３２０は、送金結果を受信し、成功である場合には、ロックされたコインを解除してリーフチェーンＡ３２０の総コイン量を調節（総コイン量から送金コイン量を差し引く）してよい。送金が失敗した場合には、リーフチェーンＡ３２０は、ロックされたコインを解除してユーザａに返還してよい。リーフチェーンＡ３２０は、このような送金結果を、ルートチェーン３１０に記録されたハッシュとともにブロックに記録してよい。
【００８０】
図９は、本発明の一実施形態における、各チェーン間のスマートコントラクトによるコイン交換データの流れを示した図である。
【００８１】
（１）ユーザａのコイン交換要求をリーフチェーンＡ３２０の分散型アプリケーション１（ｄＡｐｐ  １）９２０が受信した場合、分散型アプリケーション１（９２０）は、リーフチェーンマネージャコントラクトＡ９１０に交換要求をしてよい。リーフチェーンマネージャコントラクトＡ９１０は、交換取引ハッシュ（ｅＴｘＨａｓｈ）を生成し、交換取引ハッシュ、送金しようとするユーザａ（の識別子）とサービスａ（の識別子）、送金を受けるサービスｂ（の識別子）とユーザｂ（の識別子）、金額情報（送金金額）、および／または要請時間を記録（送金要求記録（エスクロ（ｅｓｃｒｏｗ）情報）を生成）してよい。このとき、リーフチェーンマネージャコントラクトＡ９１０は、分散型アプリケーション１（９２０）のコントラクトの総コイン量とユーザａの保有コインを差し引いてよい。
【００８２】
（２）プロデューサ４４１は、（１）で生成された取引を収集してよく、インタチェーンコンシューマ４４３は、ルートチェーン３１０のリーフチェーンＡコントラクト４１２に送金を要求してよい。
【００８３】
（３）リーフチェーンＡコントラクト４１２は、ルートチェーンマネージャコントラクト４１１により、送金要求情報をルートチェーン３１０に対して個別に記録してよい。このとき、リーフチェーンマネージャＡコントラクト４１２が管理する分散型アプリケーション１（９２０）の総コイン量から送金コイン量を差し引いてよい。
【００８４】
（４）プロデューサ４４１は、（３）で生成された取引を収集してよく、インタチェーンコンシューマ４４３は、送金を受けるサービスがあるリーフチェーンＢ３３０のリーフチェーンマネージャコントラクトＢ９４０に送金を要求してよい。
【００８５】
（５）リーフチェーンＢ３３０のリーフチェーンマネージャコントラクトＢ９４０は、送金しようとするサービスである分散型アプリケーション３（９５０）を呼び出し、分散型アプリケーション３（９５０）のコントラクトでユーザｂに送金がなされるようにしてよい。このとき、分散型アプリケーション３（９５０）のコントラクトは、リーフチェーンＢ３３０の総コイン量も増加させてよい。
【００８６】
（６）プロデューサ４４１は、（５）で生成された取引を収集してよく、インタチェーンコンシューマ４４３は、ルートチェーン３１０のリーフチェーンＢコントラクト４１３に送金完了を要求してよい。
【００８７】
（７）ルートチェーン３１０のリーフチェーンＢコントラクト４１３は、ルートチェーンマネージャコントラクト４１１に該当の送金要求のエスクロ（ｅｓｃｒｏｗ、送金要求記録）情報を読み込んで送金完了を処理してよい。送金が成功した場合、リーフチェーンＢコントラクト４１３が管理する分散型アプリケーション３（９５０）では、送金金額だけのリーフチェーンＢ３３０の総コイン量が増加されてよく、ルートチェーン３１０のルートチェーンマネージャコントラクト４１１により該当の送金要求記録は削除されてよい。送金が失敗した場合、リーフチェーンＡコントラクト４１２に登録された、送金要求したサービスである分散型アプリケーション１（９２０）では、送金コイン量の分だけリーフチェーンＡ３２０の総コイン量に増加されてよく、その後、ルートチェーン３１０のルートチェーンマネージャコントラクト４１１により該当の送金要求記録は削除されてよい。
【００８８】
（８）プロデューサ４４１は、（７）で生成された取引を収集してよく、インタチェーンコンシューマ４４３は、送金したリーフチェーンＡ３２０のリーフチェーンマネージャコントラクトＡ９１０に送金完了を要求してよい。
【００８９】
（９）リーフチェーンＡ３２０のリーフチェーンマネージャコントラクトＡ９１０は、送金完了情報を受信して該当の交換取引ハッシュが完了することを記録し、送金要求記録（ｅｓｃｒｏｗ）にある該当の要求を削除してよい。送金が失敗した場合、リーフチェーンマネージャコントラクトＡ９１０は、送金要求記録（ｅｓｃｒｏｗ）にある金額をユーザａに返還してよく、分散型アプリケーション１（９２０）の総コイン量も送金コイン分だけ増加させた後、送金要求記録（ｅｓｃｒｏｗ）から該当の要求を削除してよい。
【００９０】
既存のサービスをトランザクション処理システム３００に移行（ｍｉｇｒａｔｉｏｎ）する方式の例は、以下のとおりとなる。
【００９１】
１．既に生成された取引を各サービスがあるリーフチェーンに分離し、再びブロックを生成する方式。
【００９２】
２．現在のリンクチェーンをそのままコピーし、それぞれのリーフチェーンとして生成する方式。
【００９３】
３．現在運営中のサービスを各リーフチェーンに分離せず、１つのリーフチェーンで継続して維持する方式。
【００９４】
４．移行しなければならないサービスのユーザ残高はそのまま維持し、新たに実現されるリーフチェーンに既存のすべてのユーザの残高をそのまま送金する方式（既存のサービスではこれ以上の送金が起こらないようにし、照会のみが可能となるようにする）。
【００９５】
実施形態によって、リレイヤは、チェーンごとに存在してもよい。例えば、図４を参照しながら説明したように、１つのルートチェーン３１０と２つのリーフチェーン３２０および３３０が存在する場合、合計３つのチェーンのための３つのリレイヤが構成されてよい。この場合、ルートチェーン３１０のリレイヤは、２つのリーフチェーン３２０および３３０との要求、データ、および／またはイベントの伝達を処理してよく、２つのリーフチェーン３２０および３３０それぞれのリレイヤは、ルートチェーン３１０との要求、データ、および／またはイベントの伝達を処理してよい。このとき、リーフチェーンのためのリレイヤの談合を防ぐために、リレイヤそれぞれと連結するチェーンは、予め設定された時間周期（一例として、ブロック時間周期）ごとに動的に変更されてよい。このような実施形態において、ハッシュは、ハッシュタイムロックコントラクト（Ｈａｓｈｅｄ  ｔｉｍｅｌｏｃｋ  ｃｏｎｔｒａｃｔ）により、チェーン間を移動するときにリレイヤによって交換取引の途中に強奪されたり変調されたりしないようにしてよい。このようなハッシュタイムロックは、ユーザが交換取引の結果を直接確認することができる時間を提供するために利用されてよい。また、リレイヤの意図としない支払いを防ぐためのユニークな識別子として、個別の交換取引識別子が活用されてよい。このような交換取引識別子は、リーフチェーン間の価値移動がある場合、交換取引を唯一に識別してトラッキングするために活用されてよい。
【００９６】
図１０は、本発明の一実施形態における、リレイヤのトランザクション処理方法の例を示したフローチャートである。本実施形態に係るトランザクション処理方法は、上述したリレイヤを実現するコンピュータ装置２００によって実行されてよい。実施形態によって、リレイヤは、複数のコンピュータ装置によって実現されてもよい。例えば、上述したプロデューサ、インタチェーンコンシューマ、カフカインタチェーンフェイルオーバなどがそれぞれ個別のコンピュータ装置で実現され、ネットワークを介して互いに通信するように実現されてもよい。図１０では、１つのリレイヤが１つのコンピュータ装置２００によって実現されてトランザクション処理方法を処理する実施形態について説明する。一例として、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと、少なくとも１つのプログラムのコードとによる制御命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令にしたがってコンピュータ装置２００が図１０の方法に含まれる段階１０１０〜１０８０を実行するようにコンピュータ装置２００を制御してよい。
【００９７】
段階１０１０で、コンピュータ装置２００は、第１リーフチェーンの第１サービスから第２リーフチェーンの第２サービスへの第１送金要求を、第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトから受信してよい。一例として、第１送金要求は、第１サービスの第１ユーザから第２サービスの第２ユーザへの送金要求を含んでよい。このとき、送金要求によるコインは、第１リーフチェーンが含む第１リーフチェーンマネージャコントラクトによって第１ユーザの残高から差し引かれ、使用できないようにロックされ、エスクロコントラクトに送金要求記録として記録されてよい。本実施形態において、要求を受信するということは、実際に要求によるデータを受信すること、および／または要求によって生成されるイベントを照会することを意味してよい。一例として、第１送金要求を受信するということは、コンピュータ装置２００が第１送金要求によるデータを第１リーフチェーンマネージャコントラクトから受信することを意味してもよく、第１送金要求によって生成されるイベントをコンピュータ装置２００が第１リーフチェーンマネージャコントラクトから照会することを意味してもよい。このような要求の受信がもつ意味は、以下で説明される受信過程にも同じように適用されてよい。
【００９８】
段階１０２０で、コンピュータ装置２００は、受信した第１送金要求を、ルートチェーンが含む第１リーフチェーンの第１リーフチェーンコントラクトによって呼び出してよい（ｉｎｖｏｋｅ）。例えば、リレイヤは、プロデューサの取引収集によって第１送金要求を受信してよく、インタチェーンコンシューマにより、ルートチェーンが含む第１リーフチェーンの第１リーフチェーンコントラクトに第１送金要求を伝達してよい。
【００９９】
段階１０３０で、コンピュータ装置２００は、ルートチェーンが含む第２リーフチェーンの第２リーフチェーンコントラクトから、第１送金要求に対応する第２送金要求を受信してよい。例えば、ルートチェーンが含むルートチェーンマネージャコントラクトが、複数のリーフチェーンそれぞれで発給されたコインの総量を送金要求された情報を利用して分析することによって第１送金要求が正常であるか否かを決定し、正常であると決定された第１送金要求をブロックに記録し、第１送金要求に対応する第２送金要求を第２リーフチェーンコントラクトによってリレイヤに送信することにより、コンピュータ装置２００が第２送金要求を受信してよい。
【０１００】
段階１０４０で、コンピュータ装置２００は、受信した第２送金要求を、第２リーフチェーンが含む第２リーフチェーンマネージャコントラクトによって呼び出してよい（ｉｎｖｏｋｅ）。例えば、リレイヤは、プロデューサの取引収集によって第２送金要求を受信してよく、インタチェーンコンシューマにより、ルートチェーンに含まれる第２リーフチェーンが含む第２リーフチェーンマネージャコントラクトに第２送金要求を伝達してよい。
【０１０１】
段階１０５０で、コンピュータ装置２００は、第２リーフチェーンマネージャコントラクトから第２送金要求に対応する第１送金完了要求を受信してよい。第１送金完了要求は、第２リーフチェーンマネージャコントラクトによって第２送金要求が正常なものであると決定されることによって生成されてよく、リレイヤは、プロデューサの取引収集によって第１送金完了要求を受信してよい。
【０１０２】
段階１０６０で、コンピュータ装置２００は、受信した第１送金完了要求を、ルートチェーンが含む第２リーフチェーンの第２リーフチェーンコントラクトによって呼び出してよい（ｉｎｖｏｋｅ）。一例として、リレイヤは、インタチェーンコンシューマにより、ルートチェーンに含まれる第２リーフチェーンの第２リーフチェーンコントラクトに第１送金完了要求を伝達してよい。
【０１０３】
段階１０７０で、コンピュータ装置２００は、ルートチェーンに含まれる第１リーフチェーンの第１リーフチェーンコントラクトから、第１送金完了要求に対応する第２送金完了要求を受信してよい。第２送金完了要求は、ルートチェーンに含まれるルートチェーンマネージャコントラクトが、第２送金完了要求を正常なものとして決定することによって生成されてよい。リレイヤは、プロデューサの取引収集によって第２送金完了要求を受信してよい。
【０１０４】
段階１０８０で、コンピュータ装置２００は、受信した第２送金完了要求を、第１リーフチェーンの第１リーフチェーンマネージャコントラクトによって呼び出してよい（ｉｎｖｏｋｅ）。一例として、リレイヤは、インタチェーンコンシューマにより、第１リーフチェーンの第１リーフチェーンマネージャコントラクトに第２送金完了要請を伝達してよい。第１リーフチェーンでは、第１リーフチェーンマネージャコントラクトが、リレイヤを経て伝達される第２送金完了要求にしたがって第１リーフチェーンの総コイン量を調節してよい。
【０１０５】
以上のように、本発明の実施形態によると、ルートチェーンを基盤としてリーフチェーンを追加する方式により、スケールアウトが可能なトランザクション処理システムおよび方法を提供することができる。
【０１０６】
上述したシステムまたは装置は、ハードウェア構成要素、ソフトウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ  ｌｏｇｉｃ  ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。
【０１０７】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。
【０１０８】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。前記コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよいし、コンピュータソフトウェア当業者に公知な使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピディスク、磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ  ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を記録して実行するように特別に構成されたハードウェア装置が含まれる。このような記録媒体は、単一または複数のハードウェアが結合された形態の多様な記録手段または格納手段であってよく、あるコンピュータシステムに直接接続される媒体に限定されることはなく、ネットワーク上に分散存在するものであってもよい。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。
【０１０９】
以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。
【０１１０】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【符号の説明】
【０１１１】
３００：トランザクション処理システム
３１０：ルートチェーン
３２０：リーフチェーンＡ
３３０：リーフチェーンＢ
３４０：リレイヤ
【図１】
2020109617.tif 000003
【図２】
2020109617.tif 000004
【図３】
2020109617.tif 000005
【図４】
2020109617.tif 000006
【図５】
2020109617.tif 000007
【図６】
2020109617.tif 000008
【図７】
2020109617.tif 000009
【図８】
2020109617.tif 000010
【図９】
2020109617.tif 000011
【図１０】
2020109617.tif 000012