この記事で学べること

Corda 4.11 enterpriseにて追加されたTwo Phase Finalityの詳細について把握でき、次回以降の記事で解説するLedger Recoveryを理解する上で重要な内容となります。

目次

• はじめに
• 既存ファイナリティ構成のご説明
• 新規手法Two Phase Finalityの登場
• Phase 1: Notarization前のトランザクションを共有
• Phase 2: トランザクションのNotarizaction, Recording, Sharing
• Two Phase Finalityの特徴
• Two Phase Finality導入による影響と最適化手法
• 1. ACKの無効化
• 2. Optimistic Finalisationプロトコルの実行
• 最後に

はじめに

Corda 4.11 enterpriseでは、リカバリー関連の処理が、これまでのversionから大きくアップデートされ、複数の新機能が追加されました。Corda 4.11 enterpriseで導入された新機能に関する記事は、全３部構成（Two Phase Finality, Finality Recovery Flow, Ledger Recovery Flow）を予定しており、本記事は第一弾として、Two Phase Finality (略称：2PF)をご紹介したいと思います。

2PFの導入により、以前のversionから採用されていたトランザクションのファイナライズの構成が細分化され、第二弾でご紹介する台帳のリカバリー機能を実現する上で、大きな役割を担っています。

既存ファイナリティ構成のご説明

2PFの特徴をご理解いただく上で、重要となるのが既存ファイナリティの理解になります。

そもそも、Cordaの文脈でファイナリティとは何を指すのでしょうか？

ファイナリティとは、NotaryによるNotarizing（二重消費チェック）、 Recording (トランザクションを利害関係者の台帳に保存する行為)やSharing (全ての参加者にトランザクションを配布する行為)をひっくるめて指した言葉になります。

さて、上記のファイナリティの処理を図に起こすと以下のようになります。

一見、よくできたファイナリティの構成のように思えますが、実は障害発生を想定すると、リカバリーの操作性に関する難点が存在します。 ※ここでの障害は、ネットワーク障害やノードが利用停止状況に陥る事を指します。：

flowの受信側（上図のBさん）は、ファイナリティが完了して、初めてトランザクションを受け取ります。したがって、Bさんはリカバリーに必要な材料を保持しない構成のため、ファイナリティ処理のリカバリーの起点は、常にflowの送信側（上図のAさん）に制限されるという制約が存在しました。

故に、Corda 4.10以前では、障害時のリカバリー処理に関して、柔軟性に欠けることが課題として挙げられていました。

新規手法Two Phase Finalityの登場

既存手法の問題点に対処するために、Corda 4.11 enterpriseからTwo Phase Finalityという機能が追加され、ファイナリティ処理を２段階（Two Phase）に分割する仕様へとなりました。

2PFの構成は、以下の図の通りです。

筆者が加えたオレンジの点線を境に、ファイナリティ処理がTwo Phaseになっていることが分かります。解説のため、点線の上側はPhase 1、点線の下側をPhase 2としたいと思います。（Cordaのドキュメント内ではPhase分けされていません。）

Phase 1: Notarization前のトランザクションを共有

まずPhase 1の解説になります。

flowの送信者（図中のAさん）が署名検証を行った後に、Recordという処理に入り、図中SendTxnFlow, ReceiveTxnFlow等を通して、Notarization前のトランザクションを利害関係者間で配布し、各DBに保存する処理がPhase 1になります。

Phase 1により、Notarization前の段階で、トランザクションの利害関係者が、トランザクション情報を保持するようになりました。

Phase 2: トランザクションのNotarizaction, Recording, Sharing

Phase 2に関しては、既存のファイナリティ手法と何ら変わりません。

Notarization, Recording, Sharingのプロセスを経ることで、最終的にトランザクションの利害関係者が、Notarize済みのトランザクションを手元に保持することになります。

Two Phase Finalityの特徴

既存のファイナリティ処理とは異なり、Phase 1の時点で、トランザクションの利害関係者が、トランザクションのメタデータを持ちます。故に、障害が発生した場合でも、flowの送信者と受信者の両方がリカバリー処理の始点となることができます。

Two Phase Finality導入による影響と最適化手法

さて、2PFの導入によって、リカバリー処理に柔軟性が追加されました。しかし、既存手法と比較した時、2PFがもたらすオーバーヘッドはどのくらいになるのでしょうか。

実際に、R3が計測を行ったところ、現金発行や支払いに関するCordappにおいて、2PFの導入により、最大15%の遅延増加と最大15%のスループット低下が観測されたそうです。

しかしながら、R3社の考えとしては、2PFがもたらす障害耐性やリカバリーの柔軟性は、導入障壁とのトレードオフとして得られる利点であり、実際にパフォーマンスを最適化する手法が２つほど提案されています。

1. ACKの無効化

先ほど、添付した2PFの図では、SendTxnFlowによるDistribution recordの共有を受けて、受信側がACK (受信確認)を送信しています。一般的に、ACKが返ってこないと、送信側で次の処理が開始できない仕様になっています。

取引やリカバリーに確実性が求められるユースケースでは、ACKの利活用は非常に有効です。一方で、テスト目的ならびに帯域の制限や速度を気にする場合は、ReceiverTransactionFlowのパラメータで、deferredAck = trueを設定することで、ACKを返答しないようにすることも可能です。ただし、defeeredAck = trueでは確実性は保証されないので、ご注意ください。

2. Optimistic Finalisationプロトコルの実行

Optimistic Finalizationプロトコルの説明は少しわかりにくいため、例を用いて解説したいと思います。

仮定：flowの送信者はファイナライズが完了したが、受信者側はファイナライズが滞留状態＝未完了である

1. 送信者は、ファイナライズ済みのトランザクションで生成したstateを消費するトランザクションXを作成
2. 送信者がトランザクションXのファイナライズ処理を開始し、受信側にトランザクションXを共有する
1. 受信側は滞留状態にあるため、トランザクションXで消費されるstateを作成したトランザクションは未ファイナライズ状態である。
3. 受信側は、トランザクションXをファイナライズすることで、滞留状態にあったファイナライズ処理を、自動的にファイナライズ済みとマークします

つまり、Optimistci Finalization プロトコルとは、あるトランザクションのファイナライズ処理が滞っている状況下において、その派生トランザクションを受信した場合、派生トランザクションのファイナライズ処理をもって、滞留していたファイナライズ処理を完了させる機能になります。

最後に

本記事では、Corda 4.11 enterpriseにて新たに追加されたTwo Phase Finalityの機能をご説明しました。

2PFの導入によって、ファイナリティ処理が２段階になり、Distribution Recordというメタデータの共有は、Cordaの障害耐性やリカバリー時の柔軟性を大幅に向上させる要素となりました

また、2PF自体は多少なりともオーバーヘッドの増加を招くものの、最適化によって導入の障壁を限りなく減らすが可能になります。

何よりも、2PFがもたらす障害耐性やリカバリーの柔軟性という利点は、導入による欠点を大きく勝る要素であると我々は考えております。

✍️

Written by 井本 翔太 (Shota Imoto)

SBI R3 Japanインターン エンジニアリング部所属

Cordaの技術調査・検証や記事執筆など多岐に渡ります

趣味：英語学習（まだまだですが…）・テニス・映画鑑賞

イギリス大学院進学 2025年9月～🇬🇧

→筆者の記事一覧