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 を実行します。再発行したいStateおよびStateの正当性を検証するために、Transactionの情報を渡します。

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

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

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

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

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のリスト」が付与されます。

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

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

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

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

mceclip0.png

※再発行を要求した後でも、コピー元Stateを使い続けることもできます。しかし、その時は「UnlockReIssuedStates」の実行ができなくなります。再発行されたStateは不要になるため「DeleteReIssuedStatesAndLock」を実行して、コピーされたStateを削除できます。

 

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

 

その他特記事項

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

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

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

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

 

おわりに

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

もちろん、Transactionが遡及できた方が良いユースケースもたくさんあると思います。

ご自身のサービスやシステムの要件に併せて是非ご活用ください。

 

Created by: Kazuto Tateyama

Last edited by: Kazuto Tateyama

Updated: 2021/02/19

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