Corda Token-SDK（その２）

公開日

June 27, 2019

カテゴリ

Corda技術を知る

タグ

🍀Corda4 🧑‍💻CorDapp開発 🗳️Token-SDK

筆者

生永

この記事で学べること

40文字程度で記事に内容と得られる点を執筆する。GPTに任せるのもアリ。

はじめに
4.Token SDKの概要
Token-SDKとは
リリーススケジュール
ソースコード
5.Token-SDKが前提とするトークンの分類
6.トークンライフサイクル（FungibleToken<EvolvableTokenType>)
募集要項の生成（トークン募集前）
トークン発行(IPO/STO)
トークンの売買、2次流通
トークンイベントの発生
トークン償還
7.取引のプライバシー確保
8.まとめ
Cash Issuerに関して
Corda Sttlerに関して
Token SDKに関して
Cordaに関して

はじめに

この記事は、Token-SDKを紹介する2回続きの記事である。一回目についてはこちらをご覧いただきたい。

⬅️

前回の記事はこちら Corda Token-SDK（その１）

1.想定ユースケース
2.トークンエコノミー実現に向けたCordaの各種実装
3.TokenSDKで実現できること

それではToken-SDKについて紹介していこう。

4.Token SDKの概要

Token-SDKとは

R3が主体となってコミットしているトークン発行用CorDapp開発キットである。

リリーススケジュール

V1:6月末、V2以降：未定

現在はCorda本体とは別リリースだが、Cordaの次期バージョン（Corda5）よりCorda本体に取り込まれる予定。

ソースコード

本体ソースコード https://www.github.com/corda/token-sdk
開発用ひな型（@token-templateブランチ）http://github.com/corda/cordapp-template-kotlin

（現在も活発に開発が行われている為、たった今cloneしたとしてもそのままでは動かない可能性がある。）

5.Token-SDKが前提とするトークンの分類

トークン分類マトリックス

上記は、Token-SDKが前提とするトークン分類である。2×2のマトリックスになっている。

縦軸はFungibleかNonFungibleかを示す。横軸はトークンの状態変化を許すかどうかによる分類である。

トークン状態に関して
ライフサイクル中にトークンの状態が変わりうるのEvolvableTokenType、一度発行されたら償還されるまで状態が変化しないのがFixedTokenTypeになる。EvolvableTokenTypeの場合、個別のトークンを示すFungibleToken/NonFungibleTokenの属性としてTokenTypeを持ち、そのTokenTypeを変更する事で、その状態変化が実現する。（実際にはTokenTypeを示すポインターを属性として持ち、ポインターの示す最新のTokenTypeが、現在の状態を指すという風に実装されている）

これでは何のことやら、というビジネスサイドの方のために、具体例を2×２のマトリックスに入れたのが次の表である。

トークン分類（具体例）

仮想通貨、ポイントといったものはFixedTokenTypeである一方、通常の金融商品は基本的にEvolvableTokenTypeになる。そして、上場される金融商品はFungibleToken<EvolvableTokenType>に、非上場で分割不要ならNonFungibleToken<EvolvableTokenType>に分類されることになる。

6.トークンライフサイクル（FungibleToken<EvolvableTokenType>)

ここからさらに詳細に踏み込んでいくが、話を一般的な上場証券に適するFungibleToken<EvolvableTokenType>に絞って展開する。他の実装もFungibleToken<EvolvableTokenType>から類推できると思う。

トークンライフサイクル

トークンのライフサイクルは上の図に示した通り2種5段階に分けることができる。それぞれを簡単に説明する。

募集要項の生成（トークン募集前）

最初に、発行するトークンの要項を作る必要がある。これはEvolvableTokenTypeを実装したオブジェクトを用意し、トランザクションとして発行すればよい。

EvolvableTokenTypeに特徴的な属性として以下の3つを持つ。
linearID：発行したTokenTypeに紐づくID,状態が変化させてもこのIDは変化しない。
maintainers：TokenTypeを変化させる権限を持ったネットワーク参加者のリスト。
DistributionList：TokenTypeが変化したときに、その通知（＝トランザクション）を受け取るべきネットワーク参加者の一覧（要はそのTokenの保有者一覧）

トークン発行(IPO/STO)

トークンを発行する。募集要項で作成したトークンタイプ（EvolvableTokenTypeを参照したオブジェクト）を参照したトランザクションを発行する。この際、トークンの所有者一覧（DistributionList）が設定される。

トークンの売買、2次流通

トークンの売買については、所有者を変更できればよい。ここには二つの注意点がある。

トランザクション発行者はだれか？
それは、所有者変更のトランザクション発行は誰でも発行できるという点である。もちろん、ファイナリティを持つためには、旧所有者の承認（＝署名）が無いといけないが、基本的に誰でも発行可能である。想定されるユースケースとしては、取引所でマッチングした取引をベースに所有者変更のトランザクションが自動で生成され、それに対して新旧の所有者が署名するような形が想定される。
トークンの情報をだれが持っているのか？
取引所がトランザクションを生成するという設計をとる場合、取引トランザクション発行に必要なトークン情報（CordaはUTXOモデルをとるので、必要なUnspend Transaction）を取引所が知っていなければならない。Cordaは他のブロックチェーン基盤と異なり、参加者全員がすべてのトランザクションの存在を知っているわけではない。必要なトークン総量の試算も含め間違いなく取引所でトランザクションを発行できるかどうかについては事前の十分な検討が必要である。

トークンイベントの発生

トークン発行後の状態変化の例として、想定しやすい例は、株式であれば株式分割や配当、債券であれば格付け変更、デフォルトや利金分配であろう。こうしたイベントの通知は当該トークン保有者に対して一斉に行われる必要があり、そのための仕組みがEvolvabletTokenTypeに含まれている。そのための肝になるのが、トークン状態を変化させる権限を持っている参加者の一覧（maintainers）である。権限を持つの（maintainers）は当該tokenの発行者だけではない。事務処理を信託銀行にゆだねているのであれば信託銀行も権限を持つだろう。デフォルト通知や格付けをS&Pやmoody’sに任せているのであれば、こうした格付け業者が権限を持つ可能性もあるだろう。

トークン償還

最後にトークンの償還である。償還トランザクションは基本的には所有者移転とほとんど変わらない。

ここまで、Token-SDKの想定するトークンライフサイクルと、そのそれぞれの実装のポイントと思われる部分の説明を行ってきた。基本的な概要説明はこれで終了である。興味があればぜひ、githubへいって、さらに中身を読んでいただくことを推奨する。用意されたドキュメントも含め、トークン発行において注意すべき事が網羅されており、非常に勉強になることは間違いない。

7.取引のプライバシー確保

最後に、取引のプライバシーについてToken-SDKが今持っている機能を簡単に紹介する。

AnonymisePartiesFlow

この図は、Token-SDKの持つ取引プライバシー確保の方法を図式化した絵である。あらゆるトランザクションについて、この図にある方法をとることでプライバシーを確保することが可能である。具体的には、トークンに設定される属性から、個人を特定する情報を取り除くだけである。

図にある通り、トークンは「保有者の（署名付き）フルネーム」と「保有者の公開鍵」という属性を持っている。ここから「署名付きフルネーム」を取り除いたうえで、保有者に「新しい公開鍵」を生成してもらい、公開鍵自体を交換してしまう。

その結果作られた新しいトランザクションには、新しい保有者の情報は「公開鍵」のみが含まれることになる。公開鍵が誰のものか知っているのは、

・公開鍵を作成した新しい保有者

・現在のトランザクションを作成している参加者

・公開鍵の認証をする認証局

だけになる。トランザクションの存在を認証局は知らないので、結果として保有者が誰かわかるのはトランザクションに参加した参加者だけという事が実現される。

勿論、トランザクションチェーンを追っていく事で「偶然」誰が参加しているのか特定できる可能性はあるが、基本的な匿名性はこれによって確保されることになる。

8.まとめ

ここまで、全2回にわたってToken-SDKの全体像を説明してきた。Cordaにとって、STO/IEOについてはまだまだこれから始めるユースケースというのが実情だ。トレードファイナンスやサプライチェーンマネジメントの方がユースケースとして先に進んでいる。しかし、この分野はBlockchainの活用分野としては一番最初に考えられてきた分野だけに、多くのユースケースが急速に積みあがることが想定される。

また、Token-SDKについても、１ノードでの複数アカウントの管理、ウォレット、株や債券の標準APIの提供、In-memoryトークン検索など、まだまだ追加予定の機能がたくさんある。引き続き情報があればアップデートしたいと思っている。

最後に、参考となるリンクを貼っておく。