Re-issuanceをもちいたStateの再発行機能

はじめに

本稿について

本稿は、Corda Enterprise4.7、Corda Open Source4.7から実装された機能「Stateの再発行」に関してご紹介したものです。英語のドキュメントはこちらからご覧ください。また、本稿は例示としてこちらのソースコードを使用しています。

 

前提知識

CordaのTransactionチェーンが長くなったときの課題

mceclip0.png

上記の図は、CordaのTransactionがつながっていっている様子を表したものです。括弧の中は保有者を表しています。例えば最初の取引はAに80円、Bに50円発行されています。そのAが保有していた80円がX、Yに移転していきます。

この時、以下のような疑問を抱く人もいるのではないでしょうか?

「Aさんが80円持っていた事Bさんが50円持っていた事を、Yさんが知る必要があるのか?」

Transactionチェーンが長くなると主に2つの課題が発生します。

  1. 川下の保有者に川上の保有者や参加者が開示されてしまう。
  2. パフォーマンスの低下(Transactionを遡及して検証するため)

 

Stateの再発行機能

自力で再発行する

上記の課題はTransactionのチェーンがつながっていくことにより発生します。
よって、解消するにはTransactionを切断するような処理が必要です。

  1. 保有しているStateをコピーしたStateを生成する。
  2. コピー元のStateを業務ロジック上、何にも使用せず消費済にする。

この時1で生成したStateは、コピー元のStateとCorda上は関係のないものになるため、
川上の情報は川下に伝播することがなくなりますが、以下のような課題が残ります。

  1. 両方のStateを消費する不正が発生する。
  2. コピー元のStateを消費したが、Stateが(なんらかの理由で)再発行されない。

「1」に関しては、保有者は一時的に2つのStateを保有することになります。そのため、使用してはいけないコピー元のStateも消費される恐れがあります。一方、コピー元のStateを消費して再発行するような仕組みにしても、何らかの理由で再発行が失敗してしまったら保有者はStateを消費しただけになってしまいます。

 

Re-issuanceによるState再発行

前述のとおり、自力での再発行はユーザー依存になるだけではなく、ロジックが複雑になるという課題がありました。よって、Cordaは4.7から標準として「re-issuance 」の機能を実装しました。

Re-issuanceの基本原理も上記に基づいていますが、不整合防止のための仕組みが施されています。

  1. 保有しているStateの発行者に対して、State再発行を要求。
  2. 発行者は、要求に関して承認または拒否を選択する。
  3. 発行者は、再発行を要求されたStateのコピーおよび、再発行ロック用のStateを発行する。
  4. コピー元のStateを完全に消費する。
  5. UnlockReIssuedStatesを実行して、コピーされたStateのロックを解除する。

1.保有しているStateの発行者に対して、State再発行を要求。

Stateを再発行するには、保有者で「RequestReissuance 」もしくは「RequestReissuanceAndShareRequiredTransactionsを実行します。再発行したいStateおよびStateの正当性を検証するために、Transactionの情報を渡します。正常終了すると発行者に「ReissuanceRequest」が発行されます。
mceclip0.png

2.発行者は、要求に関して承認または拒否を選択する。

発行者は承認もしくは拒否を選択できます。承認のFlowは以降の説明に譲るとして、拒否する場合は「RejectReissuanceRequest」に実行して拒否します。
mceclip2.png

3.発行者は、再発行を要求されたStateのコピーおよび、再発行ロック用のStateを発行する。

承認する場合は「ReissueStates」を実行します。「ReissueStates」を実行することで、コピーStateと再発行ロックStateを生成して保有者に返却します。コピーStateはencumberanceフラグが設定されていて、解除処理を行わない限り消費できません。(二重使用の防止)
mceclip3.png

4.コピー元のStateを完全に消費する。

コピー元のStateを「完全に消費」します。ここでいう「完全に消費」はOutput Stateがないような消費をさします。こちらに関しては、reissuanceのlibraryに含まれているわけではないため独自Flowを使用します。

5.UnlockReIssuedStatesを実行して、コピーされたStateのロックを解除する。

「コピーされたStateのロックを解除する。」とありますがCordaがUTXOモデルである以上、実体としてはロックされたStateを消費してアンロックされたStateを生成するという形になります。「UnlockReIssuedStates」内で生成するTransactionには2つのコントラクトと1つ以上のAttachmentが含まれています。Attachmentは「元のStateを消費した時のTransaction IDのリスト」が付与されます。
mceclip4.png

Transaction内の2つのコマンドの内訳は以下の通りです。

  1. ロックされたStateを消費してアンロックされたStateを生成(Stateに紐づく任意のMoveやTransferのようなコマンドを指定してください)
  2. アクティブなReissuanceLockを消費して非アクティブなReissuanceLockを生成

「2」のReissuanceLockのコントラクトコード中では主に以下のような検証を行います。

  1. Attachmentに付与された「元のStateを消費した際のTransactionのInput State」と「任意のState」のInput Stateがデータレベルで等しいこと。
  2. Attachmentに付与された「元のStateを消費した際のTransaction」にOutput Stateが含まれていないこと。
  3. Attachmentに付与された「元のStateを消費した際のTransaction」に再発行要求者の署名が付与されていること。

mceclip0.png

※再発行を要求した後でも、オリジナルのStateを使い続けることもできます。しかし、その際は「UnlockReIssuedStates」によるロック解除ができなくなります。再発行されたStateは不要になるため「DeleteReIssuedStatesAndLock」を実行して、再発行されたStateを削除できます。
mceclip5.png

 

上記の一連の処理が完了するとStateが再発行され、Transactionの切断が完了します。

 

特記事項

1.川下に伝わる情報について

Stateを再発行した場合、「Stateを再発行したこと」および「State再発行のロックを解除したこと」は川下に伝播されます。

2.再発行するための署名数について

State再発行には、最低以下の署名が必要になります。

 

おわりに

Transaction長さを制御することは、Cordaの運用に大きくかかわってきます。

Cordaはブロックチェーンのため、もちろん、Transactionが遡及できた方が良いユースケースもたくさんあると思います。サービスやシステムの要件に併せて是非ご活用ください。

 

Created by: Kazuto Tateyama

Last edited by: Kazuto Tateyama

Updated: 2021/08/24

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています