Hyperledger Fabric と戯れる part.5
けっこう日が空いてしまったが、その間に Blockchain Engineer Night 2019 #2 に参加するなどしてた。
IBM の人らが話してるイベントなだけあって、なかなか実りある話が聞けた。参加者の平均年齢が妙に高いのが気になったんだけど、Fabric 興味あるひとってオッサンばっかなん? 若い人らはやっぱ Ethereum とかなのかな?
Commercial Paper Tutorial
予定通り Commercial Paper チュートリアルをやる。
hyperledger-fabric.readthedocs.io
が、このチュートリアルはより実践的なものとなっており、ビジネス上の課題を解決していく目的から見て、要件の分析、設計、開発、構築までカバーされてるとかいないとかって事なので、Developing Applications ドキュメントをまず読んでから進める。
hyperledger-fabric.readthedocs.io
シナリオ
hyperledger-fabric.readthedocs.io
コマーシャルペーパー(以下CP。短期・無担保の約束手形) の発行・売買・償還を行うネットワークを構築する。
本文では各社の背景の設定まで作り込んでてなかなか面白いが、正直あんまり意味ない設定なので読み飛ばしても良い。
まとめると、本ネットワークの参加団体は 6 団体で、それぞれ以下のような感じ。 MagnetoCorp(発行) と RateM(評価) とそれ以外(売買)、で覚えておけばよい。
- MagnetoCorp
- CP の発行をする
- 発行した CP の償還をする
- RateM
- CP の売買を観察する
- CP の価値を評価する
- DigiBank
- CP の売買をする
- 購入した CP の償還をする
- BigFund
- (同上)
- BrokerHouse
- (同上)
- HedgeMatic
- (同上)
分析
hyperledger-fabric.readthedocs.io
CP を 状態 としてこんな感じで定義してる。
- CommercialPaper
- Issuer (発行者)
- Paper (CP番号)
- Issuer + Paper で pkey となるらしい
- Owner (所有者)
- CurrentState != Trading のときは Owner == Issuer となる
- IssueDate (発行日)
- Maturity (償還日)
- FaceValue (額面)
- 購入額ではなく、償還時に返却される金額
- CurrentState (現在のステータス)
- Issued (発行済) | Trading (取引中) | Redeemed (償還済)
また、「発行」「購入」「償還」の取引を トランザクション として以下のように定義している。
Issue (発行)
- Issuer (発行者)
- Paper (CP番号)
- IssueTime (発行日時)
- MaturityDate (償還日)
- FaceValue (額面)
Buy (購入)
- Issuer (発行者)
- Paper (CP番号)
- CurrentOwner (元の所有者 = 売る人)
- NewOwner (新しい所有者 = 買う人)
- PurchaseTime (購入日時)
- Price (購入額)
Redeem (償還)
- Issuer (発行者 = 償還する人)
- Paper (CP番号)
- CurrentOwner (元の所有者 = 償還される人)
- RedeemTime (償還日時)
CP は償還済なら消しちゃえばいいんじゃないの？と思ったが、償還された CP の記録は保存しないとダメって事らしい。
また、CP に償還額だけあって購入額がないのはおかしいんじゃ？とも思ったが、「購入額」は CP という 状態 に紐付く物ではなく、「購入」という トランザクションに紐付くものだという理解らしい。
さらに、なんで Buy や Redeem で Issuer や CurrentOwner を指定する必要があるのか謎に思ったが、Issuer は Paper とセットで pkey になるのでそのため。 CurrentOwner は CP の Owner と照合して合致しなければエラーとするためだけに使われている。
プロセスとデータの設計
hyperledger-fabric.readthedocs.io
上で太字にしていたように、 状態 と トランザクション は重要な概念らしい。
説明読めばなんとなくわかるんだけど、うまくまとめにくい。基本的に台帳に保存されるのはなにがしかの 状態 で、それが トランザクション に応じて変化・遷移していく、というモデルがこの技術に向いたデータ形式やその手続きということなのだろうか。
あるいはイミュータブルな トランザクション の積み重ねがミュータブルな 状態 を作る、と捉えることもできそうな気がする。
スマートコントラクト処理
hyperledger-fabric.readthedocs.io
スマートコントラクト、つまり ChainCode のコード読みとなる。
該当ディレクトリは commercial-paper/organization/magnetocorp/contract あるいは commercial-paper/organization/digibank/contract となる。 diff -r すればわかるが、これら2つは全く同じ。
lib/papercontract.js の CommercialPaperContract を見ると、issue、buy、redeem が定義されている。これらが上述した トランザクション 3種に相当する。
また、 createContext がオーバーライドされていて、このなかで Context を継承した CommercialPaperContext を生成するようにされている。
CommercialPaperContext は PaperList をフィールドに持ち、その PaperList は StateDB に対する CommercialPaper の add update および get を提供する。
CommercialPaper は Key と CurrentState をもつ State の子として定義され、issuer paperNumber issueDateTime maturityDateTime faceValue owner を持つ。(State.Key は [issuer, paperNumer] で定義する。) つまりこれが上述した 状態 のそれに相当する。
今回はここまで
また中途半端なところで止まっちゃったけど、GW はガッツリ遊ぶ気なのであまり更新間隔あけないほうがいいかなって思ったのでここで中断。
次回はこの続き。
