はじめに

こんにちは。ブロックチェーン推進室の鈴木です。

私の所属するブロックチェーン推進室では、企業間取引に特化したエンタープライズブロックチェーンプラットフォーム:Cordaに関して機能調査を行っております。
Cordaは世界で350社を超える金融機関、規制当局、中央銀行、業界団体、システム・インテグレーターやソフトウェアベンダーにより構成されるR3エコシステムから、エンドユーザー目線で設計・開発されています。
また、4半期に1度のバージョンアップにより機能追加がされていますが、その機能がお客様に活用できるものなのか、ドキュメントだけではわからないことも多く、ブロックチェーン推進室独自で調査を進めています。

このブログでは、そういったCordaの機能調査をした結果を機能の使い方含めて紹介していきます。

Cordaの導入方法についてはこちらのドキュメントをご参照ください。

今後以下の内容で紹介しようと思います。

  1. Corda JMeterの使い方(9/1公開済み)
  2. Corda Enterprise Performance検証 ノードスペックを変化することによる性能変化(9/15公開済み)
  3. Corda Tokens SDK and Accounts(9/29公開済み)
  4. Corda Enterprise Collaborative Recovery(10/15公開済み)
  5. Corda Enterprise Archive Service(10/27公開済み)
  6. Corda Firewallの設定方法(11/9公開済み)
  7. Corda re-issuance Tokens SDK and Accountsを利用した一括「re-issuance」(11/24公開済み)
  8. Corda Time-windows(←今回はこちらの記事)
  9. Corda Oracle
  10. Corda attachment

(以降、バージョンアップの都度、新機能を紹介予定)

第8回目は「Corda Time-windows」について紹介します。

概要

今回の記事は「Time-windows」についてです。Time-windows(以下、「タイムウィンドウ」と表記)はTransactionのコミット可能な時間帯を指定できる機能です。
KeyConceptの1つでありながら、概要は知っているが実装方法や使い方はよく知らないという方も多いのではないかと思います。
したがって本記事では実装方法などを紹介していきます。
タイムウィンドウはアタッチメントと同様にTransactionに含めることで利用でき、タイムウィンドウが含まれている場合、タイムウィンドウに設定した時間枠でのみコミットできます。
Notaryはタイムスタンプ機関であり、タイムウィンドウ外でのTransactionをコミットすることを拒否します。
Notaryは二重支払い防止以外にも現在の時間が 、設定されたタイムウィンドウ内かどうかを確認します。
タイムウィンドウを用いることで、例えば取引を9時~15時までとして、15時以降は拒否するなどが可能です。

タイムウィンドウの時間指定方法

タイムウィンドウでの時間指定には設定ファイルなどに記述する必要はなく、コード上で設定します。
具体的にはTransactionBuilderのsetTimeWindowで設定します。
このパラメータにタイムウィンドウの情報を渡します。パラメータの渡し方として以下2種類の方法があります。

(1) 直接設定する。
(2) タイムウィンドウオブジェクトを生成し、設定する。

(1)は時刻と時間を渡し、その時刻の±時間がタイムウィンドウとして設定されます。
様々なパターンのタイムウィンドウを設定するには、(2)のタイムウィンドウオブジェクトを作成する必要があります。

▼タイムウィンドウオブジェクト生成方法

TimeWindowクラスから対象のメソッドを呼び出して、戻り値としてタイムウィンドウオブジェクトを受け取ります。
対象メソッドは以下の通りです。
※大文字アルファベットは時刻、小文字アルファベットは時間を表します。

  • TimeWindow.between(A, B)

これは時刻AからBまでの間にコミットが可能ということ表すタイムウィンドウオブジェクトを返します。

図1:時刻Aから時刻Bまでコミット可能

  • TimeWindow.fromOnly(A)

これは時刻Aからであればコミット可能ということを表すタイムウィンドウオブジェクトを返します。

図2:時刻Aからコミット可能

  • TimeWindow.untilOnly(B)

これは時刻Bまでであればコミット可能ということを表すタイムウィンドウオブジェクトを返します。

図3:時刻Bまでコミット可能

  • TimeWindow.fromStartAndDuration(A,a)

これは時刻Aから時刻A+a時間までであればコミット可能ということを表すタイムウィンドウオブジェクトを返します。

図4:時刻Aから時刻A₊a時間までコミット可能

  • TimeWindow.withTolerance(A,a)

これは時刻A-a時間から時刻A+a時間までであればコミット可能ということを表すタイムウィンドウオブジェクトを返します。

図5:時刻A-a時間から時刻A₊a時間までコミット可能

(1)の直接設定するパターンでは、内部的にTimeWindow.withToleranceを呼び出しています。

以上がタイムウィンドウオブジェクトの生成方法です。

記録されるTable

Stateを発行する(inputなし、outputあり)場合、Notaryの署名は必要ありませんでしたがタイムウィンドウが含まれている場合、Notaryの署名が必要になります。
Stateを発行時にタイムウィンドウが含まれている場合はコミット時にNODE_NOTARY_COMMITTED_TXSとNODE_NOTARY_REQUEST_LOGにレコードが追加されます。
Stateの更新や削除する(inputあり)場合では二重支払いの公証が入るためNODE_NOTARY_COMMITTED_STATESのテーブルにもレコードが記録されます。

タイムウィンドウを利用する要件

タイムウィンドウは全てのTransactionに一括で適用されるものではなく、Transactionごとに設定できるため柔軟に対応できます。
ある契約に有効期限を設ける場合やある時間以降(以内)に決済を可能にする要件や時間外取引を禁止にする要件などで利用できます。

考察とまとめ

気をつけるべきことはタイムウィンドウの時間内にTransactionが生成されないといけないということではなく、この時間内にNotaryが署名しなければならないということです。
まず、Transactionにタイムウィンドウが含まれている場合、そのTransactionにNotaryの署名が求められます。
Notaryの認識する現在時刻がタイムウィンドウの時間枠内である場合、Notaryは署名を行います。
時間枠外の場合、署名をせずにこれを拒否します。

図6:Transaction生成とタイムウィンドウ

ノードがTransactionを生成してNotaryが公証するまでに複数のStepがある場合やノード間の通信が混雑してしまっている場合には、想定している時刻と大幅にずれる可能性があります。
また、各ノードとNotaryは自動では時刻同期をとっておらず、時刻がずれている可能性があることにも注意が必要です。
実装においては、Stateに日付や時刻のプロパティを持たせてContractでTransactionに含まれているタイムウィンドウと検証を行い、有効期限の制限をより強固にすることも可能です。
例えば、図6のようなタイムウィンドウ外でTransactionが生成されることを認めないならば、これをContractで検証を行うことも可能です。

おわりに

タイムウィンドウについて紹介しましたがとても簡単に実装できます。
実装よりも要件として、どれくらいの時間枠を設けるかの方が難しいかもしれません。

今回は以上になります。


本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。