特許ウォッチ

公開番号2024179711
公報種別公開特許公報(A)
公開日2024-12-26
出願番号2023098763
出願日2023-06-15
発明の名称情報処理プログラム、情報処理装置および情報処理方法
出願人富士通株式会社
代理人弁理士法人酒井国際特許事務所
主分類G06F 9/48 20060101AFI20241219BHJP(計算;計数)
要約【課題】BCでのトランザクションの実行時にオーバーヘッドを回避する。
【解決手段】情報処理装置1は、ブロックチェーンを跨ぐ取引を、取引に含まれる処理群と処理毎に異なる実行パラメータとに分ける。そして、情報処理装置1は、ブロックチェーンを対象とする複数の処理を同一時間帯で実行するようにグループを生成する際に、実行パラメータの内容が同一である処理がグループに含まれないように処理群をスケジューリングする。これにより、情報処理装置1は、例えば、BCを跨ぐ資産の取引等の処理のスケジューリングを行うサービスに適用することができる。
【選択図】図11
特許請求の範囲【請求項１】
ブロックチェーンを対象とする処理群のうち同一時間帯に実行される複数の処理を含むグループを生成する際に、前記実行パラメータの内容が同一である処理が前記グループに含まれないように処理群をスケジューリングする
処理をコンピュータに実行させる情報処理プログラム。
続きを表示（約 1,200 文字）【請求項２】
前記スケジューリングする処理は、
同一のブロックチェーンを対象とする複数の処理を同一時間帯で実行するためのスケジューリングを実施してスケジューリングの結果を前記グループに生成し、
前記実行パラメータの内容が同一である複数の処理が前記グループに含まれる場合には、当該複数の処理のうち１つの処理を除く処理を前記グループから分離し、
分離した処理を再スケジューリングする
ことを特徴とする請求項１に記載の情報処理プログラム。
【請求項３】
前記スケジューリングする処理は、さらに、処理を分離した前記グループに上限数を超える数の複数の処理が含まれていないかを検証し、前記グループに前記上限数を超える数の複数の処理が含まれている場合には、超過分の処理を前記グループから分離し、
分離した処理を再スケジューリングする
ことを特徴とする請求項１または請求項２に記載の情報処理プログラム。
【請求項４】
前記スケジューリングする処理によってスケジューリングされた結果に基づいて、各グループに含まれる処理群をそれぞれ対象のブロックチェーンに送信し、
前記対象のブロックチェーンから、処理に対応する実行結果を含むブロックを受信し、
超過分の処理を前記グループから分離する処理は、
前記グループに含まれる実行結果の数を用いて、前記対象のブロックチェーンに対応する前記グループの前記上限数を推定し、
処理を分離した前記グループに推定した前記上限数を超える数の複数の処理が含まれていないかを検証する
ことを特徴とする請求項３に記載の情報処理プログラム。
【請求項５】
前記上限数を推定する処理は、
前記ブロックに含まれる実行結果の数および前記実行結果を蓄積する際の時刻を用いて、直近一定時間内の前記ブロックに含まれる実行結果の数の平均値を算出し、
該算出した平均値を、前記対象のブロックチェーンに対応するグループの上限数として推定する
ことを特徴とする請求項４に記載の情報処理プログラム。
【請求項６】
ブロックチェーンを対象とする処理群のうち同一時間帯に実行される複数の処理を含むグループを生成する際に、前記実行パラメータの内容が同一である処理が前記グループに含まれないように処理群をスケジューリングするスケジューリング部
を有することを特徴とする情報処理装置。
【請求項７】
ブロックチェーンを対象とする処理群のうち同一時間帯に実行される複数の処理を含むグループを生成する際に、前記実行パラメータの内容が同一である処理が前記グループに含まれないように処理群をスケジューリングする
処理をコンピュータが実行する情報処理方法。

発明の詳細な説明【技術分野】
【０００１】
本発明は、情報処理プログラムなどに関する。
続きを表示（約 2,000 文字）【背景技術】
【０００２】
ブロックチェーン間連携ミドルウェア（以降、ＢＣ間連携ＭＷ）が知られている。ＢＣ間連携ＭＷとは、アプリケーションからの要求に応じて複数のブロックチェーン（以降、ＢＣ）を跨ぐ取引を実行する機能を持つソフトウェアのことをいう。
【０００３】
図１７は、ＢＣ間連携ＭＷの典型例を示す参考図である。図１７に示すように、ユーザアプリケーションから事前に定義された取引シナリオを指定した取引実行要求を受信したＢＣ間連携ＭＷでは、連携プロセスが、指定された取引シナリオを永続化ストレージから取得する（ａ１，ａ２）。そして、連携プロセスは、取得した取引シナリオに記述された連携先ＢＣへトランザクションを送信し（ａ３）、トランザクションの実行結果を永続化ストレージのシナリオ実行証跡に書き込む（ａ４）。ここでいう取引シナリオとは、例えば、あるＢＣの暗号資産を別の暗号資産と交換するシナリオのことをいう。ユーザアプリケーションは、事前に定義された取引シナリオを指定して取引の実行要求を行うだけで、ＢＣ固有の処理を実行することなく複数のＢＣを跨ぐ取引を実行できる。
【０００４】
ところが、図１７で示したＢＣ間連携ＭＷでは、連携プロセスが単一であるため、取引処理性能や可用性を向上させることができない。取引シナリオは複数のＢＣへのトランザクション送信処理を含むため、取引シナリオを処理する連携プロセスは、例えば、現在どの取引シナリオのどのトランザクション送信を実行しているのかを示す取引シナリオの処理状況（ステート）を持つので、多重化できない。連携プロセスを多重化するには、取引シナリオの処理状況（ステート）を連携プロセスの外に出して、処理状況（ステート）のない構成にする必要がある。
【０００５】
連携プロセスを処理状況（ステート）のない構成にする手法として、シーケンシャルなコンボイパターンの手法が利用できる（例えば、非特許文献１参照）。シーケンシャルなコンボイパターンとは、プロセスが順序性のあるメッセージ群を処理する際に、メッセージ群毎にメッセージキュー内の異なるカテゴリに格納し、メッセージキュー内のメッセージの処理を複数の後続のプロセスに分散させる技術である。しかしながら、取引実行要求をそのままメッセージ化するだけでは、大量のトランザクションを送信する多くのプロセスが必要となる。
【０００６】
そこで、必要なプロセス数を削減する改善策として、ジョブショップスケジューリングの手法が利用できる（例えば、非特許文献２参照）。ジョブショップスケジューリングとは、順序性のあるメッセージ群の集まりを複数のマシンで実行する際の実行スケジュールを最適化するアルゴリズムである。シーケンシャルなコンボイパターンをジョブショップスケジューリングと組み合わせて、トランザクションの送信を同時に並列実行するようスケジューリングしてからメッセージキューに格納する手法が考えられる。しかしながら、従来のジョブショップスケジューリングでは、ＢＣで行われるトランザクションの実行時にオーバーヘッドが発生し得る。ここでいうオーバーヘッドには、例えば、ＢＣで同時に実行する際に発生し得る、同一アドレスに対するトランザクションの衝突や、ＢＣで同時に実行可能なトランザクションの数の超過が挙げられる。
【０００７】
そこで、ＢＣで行われるトランザクションの実行時のオーバーヘッドを抑止可能なスケジューリング手法として、ＢＣ送信前のトランザクションを事前に解析し、トランザクション内の属性情報から実行順序を決定する手法が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００８】
米国特許出願公開第２０１８／０１５８０３４号明細書
【非特許文献】
【０００９】
Microsoft.2022. シーケンシャルなコンボイパターン，https://learn.microsoft.com/ja-jp/azure/architecture/patterns/sequential-convoy
Google.2023. The Job Shop Problem，https://developers.google.com/optimization/scheduling/job_shop
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来技術では、事前にトランザクションを解析できないＢＣの場合には、ＢＣでのトランザクションの実行時にオーバーヘッドを回避することができないという問題がある。
（【００１１】以降は省略されています）

関連特許