CordaにおけるReference Stateの活用方法(デモンストレーション編)

今回、Reference State(以下Ref.State)に関する細かな動作確認を行うため調査を行いました。

調査にあたりましてサンプルプログラムを作成しました。コード解説編とデモンストレーション編の２部編成でお届けしたいと思います。

本記事はRef.Stateについて詳しく知りたいCordaに精通していらっしゃるエンジニアの方やセールスの方を対象としております。

Cordaについて詳しく知りたい方はR3公式ドキュメントや株式会社digglueさんの記事をご覧ください。また、Cordaの概念であるUTXOモデルについて知りたい方は、こちらの解説記事をご覧ください。

SBI R3 Japan株式会社にインターンでお邪魔している井本翔太と申します。現在、都内の大学に通いながらエンジニアとして働かせていただいています。2021年頃からブロックチェーンに興味を持ち始め、その仕組みや活用方法を学ぶ過程でCordaと出会いました。私にとってCordaは社会にブロックチェーンという存在を浸透させる上で大きな役割を果たすと考えております。

改めて調査内容の確認です。

調査１：Ref.Stateをトランザクションに含め、コントラクトで検証可能か

調査２：あるノードで発行したRef.Stateのバックチェーンを別のノードで確認できるか

調査３：消費済みのRef.Stateをトランザクションに含められるか

調査１,２については要望を満たすことができましたが、

調査３はエラーが出力されました。

調査３で出力されたエラーについては後ほど説明したいと思います。

※調査１,２と調査３では実装が異なるため、サンプルプログラムは2つ作成しました。

サンプルプログラムはSBI R3 Japan株式会社が提供しております Corda trainingのコードにAddressState(住所録)をRef.Stateとして加えました。Corda trainingで扱うプログラムはIOU(借用証書)の発行(Issue)、譲渡(Transfer)、返済(Settle)に関するプログラムになります。今回は必要最低限の機能を実装するためにRef.Stateの実装対象をIssueのみに絞りました。

1. PublishFlow.javaを実行して、AddressStateを発行する。

2. MoveFlowを実行して、AddressStateを更新する。

3. IOUIssueFlowを実行して、IOUを発行。この時、SignedTransactionIDを記録

4. トランザクションの詳細を調べるため、run internalFindVerifiedTransaction txnId: Transaction-ID or Hashというコマンドを実行。引数に手順3で記録したSignedTransactionIDを指定する。

5. referencesという項目に記載されているtxhashがMoveFlow実行後に表示されるハッシュ値と一致するか確認

1. IOUTransferFlow.javaでIOUのトランザクションをParticipantBからParticipantCに渡す。

2. ParticipantCのNode Terminal Windowsにてrun internalFindVerifiedTransaction txnId: ~を実行し、付随されているAddressStateのハッシュ値を確認する。

3. 再びrun internalFindVerifiedTransaction txnId: ~を実行し、手順2で確認したハッシュ値を引数に指定する。InputStateに関する項目でハッシュ値を確認する。

4. 再びrun internalFindVerifiedTransaction txnId: ~を実行し、手順3で確認したハッシュ値を引数に指定する。InputStateに関する項目が空白になっていれば、別ノードでAddressStateのバックチェーンが確認できた事になります。

1.PulishFlowを実行し、AddressStateを発行

2.MoveFlowを実行し、AddressStateを更新

3.IOUIssueFlowを実行。この時、SignedTransactionIDを記録。

4.run internalFindVerifiedTransaction txnId: ~を実行。引数には手順3で記録したSignedTransactionIDを指定

5.referencesという項目に記載されているtxhashがPublishしたAddressStateと一致するか確認

「referencese:」という項目からAddressState(addressはroppongi)のハッシュ値を確認します。そして、run　internalFindVerifiedTransaction txnId: を実行します。以下に結果を示します。※添付図は一部カットしています。

赤枠からaddressがroppongiのAddressStateはtxhash=8C7EF4～というAddressState(addressはshinjuku)をinputStateとして使用している事が分かります。再び同様に、run internalFindVerifiedTransaction txnId: ~を実行します。※添付図は一部カットしています。

赤枠からinputの項目が空であることが分かります。したがって、PublishしたAddressStateまでトレースできたことを意味します。

基本的な手順は調査1と同様です。

先ほどエラーメッセージを直訳すると「一つもしくは複数のStateまたはReference Stateは他のトランザクションの中で既にインプットとして使われた」という意味です。このエラーの原因として、Moveする段階で最初にPublishしたAddressState(=1つ前のRef.State)がInputStateとして使われた事をNotaryが記録する事 が考えられます。詳しい説明のためにCDLを再掲します。

上記のCDLからMoveFlowを実行する際には、PublishしたAddressStateがInputStateとして使われていることが分かります。調査3ならsuginamiのAddressStateを消費して、nakanoのAddressStateを作成しています。

suginamiのAddressStateが消費済みという事実はNotaryに記録されます。したがって、IOUIssueのトランザクションにsuginamiのAddressState(1つ前のAddressState)を含めようとするとNotaryはNGを出します。

調査3が実現不可能な理由についてご理解いただけましたでしょうか?

調査1,2のサンプルプログラムです。

https://github.com/ShotaIMO/investigation-of-ReferenceState

調査3のサンプルプログラムです。

https://github.com/ShotaIMO/investigation-of-Previous-ReferenceState

サンプルプログラム作成にあたって、ご協力いただいたSBI R3 Japan株式会社のエンジニアチームの皆様ありがとうございました。

以上が調査結果の報告になります。皆様のRef.Stateに対する理解が深まれば幸いです。Cordaにご興味のある方はSBI R3 Japan株式会社へ直接ご連絡いただければ幸いです。Ref.StateRに関する新たな調査も始動しておりますので、また記事にしたいと思います。ご一読ありがとうございました。