Stateの再発行機能や、Transacitionのチェーン検証の遡及について理解できる。
- はじめに
- 本稿について
- 前提知識
- CordaのTransactionチェーンが長くなったときの課題
- Stateの再発行機能
- 自力で再発行する
- Re-issuanceによるState再発行
- 1.保有しているStateの発行者に対して、State再発行を要求。
- 2.発行者は、要求に関して承認または拒否を選択する。
- 3.発行者は、再発行を要求されたStateのコピーおよび、再発行ロック用のStateを発行する。
- 4.コピー元のStateを完全に消費する。
- 5.UnlockReIssuedStatesを実行して、コピーされたStateのロックを解除する。
- 特記事項
- 1.川下に伝わる情報について
- 2.再発行するための署名数について
- おわりに
はじめに
本稿について
本稿は、Corda Enterprise4.7、Corda Open Source4.7から実装された機能「Stateの再発行」に関してご紹介したものです。英語のドキュメントはこちらからご覧ください。また、本稿は例示としてこちらのソースコードを使用しています。
前提知識
CordaのTransactionチェーンが長くなったときの課題
上記の図は、CordaのTransactionがつながっていっている様子を表したものです。括弧の中は保有者を表しています。例えば最初の取引はAに80円、Bに50円発行されています。そのAが保有していた80円がX、Yに移転していきます。
この時、以下のような疑問を抱く人もいるのではないでしょうか？
「Aさんが80円持っていた事Bさんが50円持っていた事を、Yさんが知る必要があるのか？」
Transactionチェーンが長くなると主に2つの課題が発生します。
- 川下の保有者に川上の保有者や参加者が開示されてしまう。
- パフォーマンスの低下(Transactionを遡及して検証するため)
Stateの再発行機能
自力で再発行する
上記の課題はTransactionのチェーンがつながっていくことにより発生します。
よって、解消するにはTransactionを切断するような処理が必要です。
- 保有しているStateをコピーしたStateを生成する。
- コピー元のStateを業務ロジック上、何にも使用せず消費済にする。
この時1で生成したStateは、コピー元のStateとCorda上は関係のないものになるため、
川上の情報は川下に伝播することがなくなりますが、以下のような課題が残ります。
- 両方のStateを消費する不正が発生する。
- コピー元のStateを消費したが、Stateが(なんらかの理由で)再発行されない。
「1」に関しては、保有者は一時的に2つのStateを保有することになります。そのため、使用してはいけないコピー元のStateも消費される恐れがあります。一方、コピー元のStateを消費して再発行するような仕組みにしても、何らかの理由で再発行が失敗してしまったら保有者はStateを消費しただけになってしまいます。
Re-issuanceによるState再発行
前述のとおり、自力での再発行はユーザー依存になるだけではなく、ロジックが複雑になるという課題がありました。よって、Cordaは4.7から標準として「re-issuance 」の機能を実装しました。
Re-issuanceの基本原理も上記に基づいていますが、不整合防止のための仕組みが施されています。
- 保有しているStateの発行者に対して、State再発行を要求。
- 発行者は、要求に関して承認または拒否を選択する。
- 発行者は、再発行を要求されたStateのコピーおよび、再発行ロック用のStateを発行する。
- コピー元のStateを完全に消費する。
- UnlockReIssuedStatesを実行して、コピーされたStateのロックを解除する。
1.保有しているStateの発行者に対して、State再発行を要求。
Stateを再発行するには、保有者で「RequestReissuance 」もしくは「RequestReissuanceAndShareRequiredTransactions」を実行します。再発行したいStateおよびStateの正当性を検証するために、Transactionの情報を渡します。正常終了すると発行者に「ReissuanceRequest」が発行されます。
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つのコマンドの内訳は以下の通りです。
- ロックされたStateを消費してアンロックされたStateを生成(Stateに紐づく任意のMoveやTransferのようなコマンドを指定してください)
- アクティブなReissuanceLockを消費して非アクティブなReissuanceLockを生成
「2」のReissuanceLockのコントラクトコード中では主に以下のような検証を行います。
- Attachmentに付与された「元のStateを消費した際のTransactionのInput State」と「任意のState」のInput Stateがデータレベルで等しいこと。
- Attachmentに付与された「元のStateを消費した際のTransaction」にOutput Stateが含まれていないこと。
- Attachmentに付与された「元のStateを消費した際のTransaction」に再発行要求者の署名が付与されていること。
※再発行を要求した後でも、オリジナルのStateを使い続けることもできます。しかし、その際は「UnlockReIssuedStates」によるロック解除ができなくなります。再発行されたStateは不要になるため「DeleteReIssuedStatesAndLock」を実行して、再発行されたStateを削除できます。
上記の一連の処理が完了するとStateが再発行され、Transactionの切断が完了します。
特記事項
1.川下に伝わる情報について
Stateを再発行した場合、「Stateを再発行したこと」および「State再発行のロックを解除したこと」は川下に伝播されます。
2.再発行するための署名数について
State再発行には、最低以下の署名が必要になります。
- RequestReissuance + 1(保有者)
- ReissueStates + 2(発行者, 保有者)
- コピー元Stateの償還 + n(償還Flowの実装に依存)
- UnlockReIssuedStates + 1(保有者)
おわりに
Transaction長さを制御することは、Cordaの運用に大きくかかわってきます。
Cordaはブロックチェーンのため、もちろん、Transactionが遡及できた方が良いユースケースもたくさんあると思います。サービスやシステムの要件に併せて是非ご活用ください。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japan エンジニアリング部所属
ソリューションアーキテクト/PoC支援
This is the way. みんなでキャズムを超えていきましょう！