この記事で学べること

ノード間で発生したデータ破損の回復をサポートするCollaborative Recoveryのうち、トランザクションの差異を検出するLedgerSyncについて理解できる。

目次

• Collaborative Recovery CorDapps概要
• Ledger Sync
• システム要求
• 構成パラメータ
• Flow仕様
• ScheduleReconciliationFlow
• パラメーター
• 戻り値
• コマンド例
• GetReconciliationStatusesFlow
• パラメーター
• 戻り値
• コマンド例
• パラメーター
• 戻り値
• コマンド例
• RefreshReconciliationStatusesFlow
• パラメーター
• 戻り値
• コマンド例
• StopReconciliationForPartyFlow
• パラメーター
• 戻り値
• コマンド例
• IsReconciliationScheduledForPartyFlow （ デバッグ用 ）
• パラメータ
• 戻り値
• コマンド例
• IsRespondingToReconciliationForPartyFlow （ デバッグ用 ）
• パラメータ
• 戻り値
• コマンド例
• 関連データベーステーブル

Collaborative Recovery CorDapps概要

Collaborative Recovery はノード間で発生したトランザクション差異の検出、及び回復をサポートするツール群の総称です。Collaborative Recovery は目的に応じた複数のアプリケーションで構成。指定したノード間でのトランザクションの差異を検出する LedgerSync や、台帳のデータの差異を修正し整合性を取る LedgerRecover があります。

Ledger Sync

LedgerSync は、同じビジネスネットワーク内の 2 つのノードが保持する共通台帳データの違いを安全且つプライバシーを守った形で見つけ出すCorDapp です。CorDapp を実行しているピアは、欠落したTransctionを見つけ出すことが可能です。この手順はReconciliation(リコンサイル)と呼ばれています。

LedgerSyncは、差分が少ない、または全く差分がない大規模なデータセットを効率的に調整するように設計されています（Efficient Set Reconciliation Algorithm Without Prior Contextに基づいています）。一般的に、転送が期待できるデータ量は、差分の大きさに比例しており、データセット内の項目の総数ではありません。この理由から、LedgerSyncは、大規模なデータセットであっても、最小限のネットワークオーバーヘッドで済みます。

LedgerSyncはプライバシーを考慮して設計されています。パーティは実際のデータを共有することはありません。その代わりに、難読化されたデータのみを含み、当事者が一方的にデコードできないInvertible Bloom Filtersを共有します。さらに、LedgerSync は、トランザクションに参加したパーティのみが、トランザクション作成者の台帳から欠落していることを報告できるようにすることで、プライバシーを確保します。

LedgerSync は、スケジュールを組んでで動作することができます。それは、同時に行われるインバウンド/アウトバウンドの調整の数を制限するために制限されたflowプールを利用し、また、機能が悪用されるのを防ぐために、異なるスロットリング技術をサポートしています。

ハイレベル、ピアツーピアのリコンサイルflowは、下の図に描かれています。LedgerSync は、ユーザーによって設定された制限まで、複数のリコンサイルを同時に実行することができます。

システム要求

LedgerSync のシステム要件は、主にVaultのサイズに依存します。LedgerSync は、すべてのTransaction情報がメモリに保持されているわけではありませんが、Vault内のすべての Transactionのインメモリグラフを使用します。

全体的なメモリ使用量は、Vault内のTransaction数、および各Transactionに関与する参加者（パーティ）の数に依存します。

このセクションで説明するシナリオに必要なメモリ量の目安は、以下の表を参照してください。これはあくまでもガイドラインです。Corda を使用しているネットワークでは、使用するヒープスペースの量に影響を与える変数がたくさんありますが、これで必要なメモリ量の一般的な感覚がつかめるはずです。

トランザクションあたりの参加者(Party)は、Output Stateあたりの参加者数です。A+B+Cで、AはOutput State 0の参加者数、Bは出力状態 1 の参加者数、Cは出力状態 2 の参加者数です。

構成パラメータ

構成パラメータを使ってledger Syncを定義することができます。

構成パラメーターの指定が無い場合、または構成ファイルが存在しない場合は、デフォルト値を使用します。

• maxNumberOfIbfFilterFlows

他のパーティとのリコンサイルを試みるとき、レッジャーの差異の数を正確に推定するために、多くの「Invertible Bloom Filters」を交換します。この設定パラメータは、応答するノードのflowの意図的/偶発的な乱用を防ぐために、これらの交換の数を制限するために使用されます。

デフォルト：5

指定可能値：1 ～ 15

• maxNumberOfParallelReconciliationRequests

リコンサイルの最大並列実行数

デフォルト：3

指定可能値：1 ～ 10

• maxReconciliationRetryAttemptTimeout

要求ノードが調整を再試行し続ける時間。ノードが短期間に過度に再試行する事で負荷の高騰を低減するために使用されます。

デフォルト：1（ 時間 ）

指定可能値：0 以上

• timeWindowForReconciliationRequestLimit

maxAllowedReconciliationRequestsPerTimeWindow と組み合わせて、ノードが特定の時間内に別のノードからのリコンサイル要求に応答する頻度を制御。例：1分当たり10件の応答

デフォルト：1h

指定可能値：0 以上

• maxAllowedReconciliationRequestsPerTimeWindow

timeWindowForReconciliationRequestLimit と組み合わせて、ノードが特定の時間内に別のノードからのリコンサイル要求に応答する頻度を制御

デフォルト：1000

指定可能値： 0 ～ 2147483647

• transactionReaderPageSize

transactionをデータベースより読み取る際のバッチ/ページサイズ（ パフォーマンスに影響 ）。

デフォルト：100

指定可能値： 10 ～ 10000000

• transactionReaderPoolSize

トランザクションデータをデシリアライズする際に使用するスレッド数（ パフォーマンスに影響 ）

デフォルト：10

指定可能値： 5 ～ 1000

Flow仕様

LedgerSync で実行可能なフローには下記の種類があります。

ScheduleReconciliationFlow

このFlowを通して、指定した他のノードに対してリコンサイル要求を発行します。リコンサイルの処理は非同期であり、ジョブとして内部キューに追加します。リコンサイルの実施タイミングは、他のリコンサイルの実行状況等により変動します。リコンサイル対象のノードがビジー状態の場合、maxReconciliationRetryAttemptTimeout で設定した感覚でリコンサイル要求を繰り返す（ 負荷軽減 ）

ノード間のトランザクションの差異が多い場合、所属するネットワークの NetworkParameter の maxMessageSize 制限により、リコンサイルが失敗（ MaxMessageSizeExceededException を出力 ）する可能性があります。

なお、以下の条件ではリコンサイルを実行することはできません。

• リコンサイルの対象となるPartyが、リコンサイルを開始しているノードと同じアイデンティティを持っている場合（自分とリコンサイルできない）。
• 相手側のPartyとの間ですでに進行中のリコンサイルがスケジュールされている/進行中である場合。

パラメーター

parties：リコンサイルを実施するノード名のリスト

戻り値

無し

コマンド例

Node01 が Node02 及び Node03 とのリコンサイルを実施する

GetReconciliationStatusesFlow

条件に一致するリコンサイルステータスのリストを取得するFlow。自ノードが要求したリコンサイル対象を取得する際は IN_PROGRESS ステータスを指定する事で可能。

パラメーター

• party：リコンサイルステータスを取得する対象のノード名(任意)
• lastReconciliationStatus：検索するステータス （ 任意 ）
• isRequester：true ：自ノードが要求を開始したリコンサイル対象のリストを検索するfalse：他のノードが要求を開始したリコンサイル対象のリストを検索する

戻り値

ReconciliationStatusのリスト

コマンド例

GetReconciliationStatusForPartyFlow

指定したノードのリコンサイルステータスを取得するFlow。

パラメーター

• party：リコンサイルステータスを取得する対象のノード名
• isRequester：true ：自ノードが要求を開始したリコンサイル対象のリストを検索するfalse：他のノードが要求を開始したリコンサイル対象のリストを検索する

戻り値

ReconciliationStatusのリスト、またはnull。

コマンド例

RefreshReconciliationStatusesFlow

リコンサイルステータスをリフレッシュするFlow。

このFlowは、現在のノードのレッジャーからtransactionが見つからないことが判明したリコンサイルの照合の結果を "リフレッシュ "します。ノードのレッジャーをスキャンして、ID が欠落しているtransactionのリストにあるものと一致するtransactionを探します。transactionが見つかった場合、リコンサイルのステータスが更新され、transactionが消えている状態ではなくなったことが反映されます。

不足しているtransactionの一部またはすべてが回収された場合は、リコンサイルのステータスを更新する必要があります。

パラメーター

無し

戻り値

無し

コマンド例

StopReconciliationForPartyFlow

リコンサイル要求のステータスを STOPPED に設定し、リコンサイルに関するスレッドを強制終了するFlow。

リコンサイルを要求または応答するリクエストのステータスを STOPPED に設定し、リコンサイルに接続されているスレッドを kill します。これは Corda killFlow RPC コマンドと一緒に (または後に) 使用してください。そうしないと、スケジューラは関係者との新しいリコンサイルを開始できないので、これは状況によっては必要なステップです。

パラメーター

party：リコンサイルを止めたい対象のノード名

戻り値

無し

コマンド例

IsReconciliationScheduledForPartyFlow （ デバッグ用 ）

指定したノードのリコンサイルが 進行中・発信中・リコンサイル中のいずれかを確認するためのテストFlow。リコンサイルのステータスを取得する目的では使用不可。スケジューラが現在実行中かどうかではなく、スケジューラがそれを認識しているかどうかをチェックするためにのみ有用です。

パラメータ

party：リコンサイルステータスを取得する対象のノード名

戻り値

スケジューラ内にPartyの発信中リコンサイルが入っている場合、trueを返します。それ以外の場合はfalseを返します。

コマンド例

IsRespondingToReconciliationForPartyFlow （ デバッグ用 ）

指定したノードのリコンサイルが 進行中・受信中・リコンサイル中のいずれかを確認するためのテストFlow。リコンサイルのステータスを取得する目的では使用不可。スケジューラが現在実行中かどうかではなく、スケジューラがそれを認識しているかどうかをチェックするためにのみ有用です。

パラメータ

party：リコンサイルステータスを取得する対象のノード名

戻り値

スケジューラ内にPartyのリ受信中コンサイルが入っている場合、trueを返します。それ以外の場合はfalseを返します。

コマンド例

関連データベーステーブル

こちらから。

✍️

Written by 趙 昇 (Sheng Zhao)

SBI R3 Japan ビジネス推進部

デジタルアセットのプロジェクトをしています。

パブリックチェーン大好きでした(今も)が、Cordaの魅力に惹かれました！

→筆者の記事一覧