この記事で学べること

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つの課題が発生します。

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」が発行されます。

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がデータレベルで等しいこと。
2. Attachmentに付与された「元のStateを消費した際のTransaction」にOutput Stateが含まれていないこと。
3. 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が遡及できた方が良いユースケースもたくさんあると思います。サービスやシステムの要件に併せて是非ご活用ください。

✍️

Written by 立山 和人 (Kazuto Tateyama)

SBI R3 Japan エンジニアリング部所属

ソリューションアーキテクト/PoC支援

This is the way. みんなでキャズムを超えていきましょう！

→筆者の記事一覧