20分で復習するCorda Ledger

Corda Hands-on 前編

1. Network

https://gyazo.com/409ab49c3b66e5a9dd86923d82267336

(Corda Documentの図を編集して独自作成)

上図がCorda(Enterprise, Private Network)における全体像

登場componentは6種類

1. Node : Consortium Network の参加者が運営する通常の Node

2. Notary : Network Operator が運営する「二重支払い check」のための Node

3. Identity Manager : 新たな Node が Network に参加する場合に証明書等を付与する Doorman Node

4. Network Map : Network における他の Node や NotaryのIP等を教えるDNS Node

5. Signing Service : Identity Manager と Network Map の鍵と署名機能を担う Node

6. Trust Root : Network における Root 認証局

Node 同士は Network Map を介して相互に IP を知ることで p2p で通信する

また、 Network Map は Network parameters という Network 全体で共有なパラメータを全 Node に共有しており、各 Node はこの parameter から、Notary の接続先を特定し、通信することができる。

Trust Root は通常の Network と同様に Private な Network に隔離され、Root の秘密鍵を保守する

一方で Signing Service は、Identity Manager と Network Map の秘密鍵 を保管するため、Private な Network に置くが、アウトバウンドで Identity Manager と Network Map に対して polling をし、署名リクエスト Queue をチェックしてリクエスト があれば、署名をする。

各 Node は、Network 参加時に Doorman Node である Identity Manager に参加リクエストをし、参加が許可されれば Node の 証明書を付与され、Network Map に登録されることで、正当な Network 参加者となる。

https://gyazo.com/700dda64db3559615ac3ce4937c0b3f7

(Corda Documentの図を編集して独自作成)

開発モードでは　上記のようにNodeとNotaryしかない

2. Ledger

https://gyazo.com/a13b721c4711a513b3674fcfa0fb7d0a

(Corda Technical Paperより引用)

Corda はUTXO

Blockは存在しない、TXのみ

TXのGlobal broadcastはしない

遷移させるStateに関係のあるNodeにのみTXが送信される

各NodeがTXに署名をし、署名が集まったらNotaryに二重支払いチェックをしてもらい、その後、署名したNodeのvaultにのみ、そのStateが反映される

この「取引関係者にしかTXが送信されない」という特性によりプライバシー問題を解決している(ということになっている)

つまり、Ledgerとしては上図のように人それぞれ違うStateを持つことになる

3. State

https://gyazo.com/20a07f2d5d50b48b7447fbe86d01e316

(Corda Documentより引用)

上図のような構造を持ったオブジェクト

(Cordappに実装します)

上の例は IOUのState

「Alice から Bob に 10 ポンドの借用証書 (つまり、Bob は Alice から 10 ポンドを返済してもらう債権を保持しているということ)」「支払い期限、既 返済額、ペナルティ」などの情報が見て取れるように、State には自由にプロパティを設 定することができる

Participants として「この State の関係 Node」を指定することができる。

validation する Contract(後述) への Reference を付与する。ここで、この State を遷移するためには、ここで指定されている Contract で validation しなければならない という制限をすることができる。

4. Transaction

https://gyazo.com/741bc0ad51411e2b02fcce8fea849f14

(Corda Documentより引用)

TransactionでState遷移を起こす

TXは上図のような構造を持つ

InputState => OutputState × n個

command (=>の部分。Stateにどんな変化を起こすかのコマンド IssueとかUpdateとかTransfer とか)

time stamp

attachment

sig

Transactionを作成する部分のコードはFlow(後述)に記述する

Transactionは「Stateの関係者(participants)に対するState遷移の提案」と考えれば良い

上図の例は、「BobがAliceから10ポンド返済してもらう権利が表彰されたIOU」を5ポンド分返済済みにし、「Aliceの持っている5ポンド」を「Bobの物にする」というState遷移、つまり「AliceがBobに借金5ポンド返済します、いいですよね」という提案をAliceが作ってBobに送るというTransactionである

TimeStampには Time Windowを指定できる

Attachmentには、zip等のファイルを添付できる

https://gyazo.com/cc5f8c51f9884525bf3f613dce09f21e

(Corda Documentより引用)

UTXO baseであるため、上図のように あるTXのInput StateはUTXOが入る

https://gyazo.com/fa1ff4fe16531031ebe2e3ffdeaddbcd

(Corda Documentより引用)

消費されたUTXOはhistoricになっていく

https://gyazo.com/00e78d647e8dcf4f384e706ed0841ac2

(Corda Documentより引用)

vault (各Nodeのデータベース)には、各Stateのhistorical statesも一緒に入っている

5. Flow

https://gyazo.com/24fed2e00e574a70b84178d8d846d7f7

(Corda Documentより引用)

Flowは 「TXを作る」プログラムくん

Cordappで実装します

NodeはこのFlowというプログラムを実行することで「TXを作って、取引相手に送信して署名してもらって、Notaryに送って、vaultに保存する」

Flowには, Initiator FlowとResponder Flowの二種類がある

提案者が実行するのがInitiator Flow

受け取って確認して署名する方が実行するのがResponder Flow

上図のFlowは以下のような手順を表している

1. Alice Node が Initiator Flow を実行し、State 遷移の提案としての TX を作成、そ の TX を Contract で validation した後、署名し、State participants の Node に 順番に送信

2. participants である Bob Node が Responder Flow を実行、TX を Contract と ResponderFlow の中で validation を行なった後、署名し、Alice Node に送信

3. Alice Node は participants 全員の署名が集まった TX を Notary に送信

4. Notary は二重支払いチェック (Validating Notary の場合はcordappを保持し、 Contract による validation も行う) を行い、署名し、Alice Node に送信

5. Alice Node は、Notary の署名付きの TX を participants に送信

6. 各 Node は自身の vault に State 遷移を commit

6. Contract

https://gyazo.com/544dc3fb3e090e78a652c9b11e8759e8

(Corda Documentより引用)

Contractは TXをvalidationするためのコード

Cordappで実装します

Ethereum の Smart Contractとは全く違うので注意

上図のようにStateにContractのリファレンスが紐づいており、あるStateを遷移させるTXは、そのStateに紐づいてるContractでvalidationされる

https://gyazo.com/304014aa6693b7346f860d65f448d4c2

(Corda Documentより引用)

また、上図のように Historical Stateを遡及的に検証していく際にも、それぞれのStateに紐づいているContractのvalidationに違反していないかを検証する

例：ある証券100個を50万円で売買するとき、Contractでは数学的なバリデーション（移転前後で証券や資金の総量が変わらないことや署名検証等）を行い、Flowで売買の金額の間違いがないことを担保する。

7. Node Architecture

https://gyazo.com/0a490ff14dd3e190b58d4b28792f2829

(Corda Documentより引用)

Nodeは上図のような構造を持っている

State, Contract, Flowのコードが含まれるCordappを持つ

vaultというDBを持つ

clientから接続するためのRPCの口を持つ

他のNodeと通信するためのp2pの口を持つ

8. Notary

Notary is 「二重支払いチェックするマン」

TXが当事者同士でしかやり取りされないため、二重支払いを防ぐためのNodeが必要、それがNotary

Notaryには

1. Validting Notary

2. Non-validating Notary

の二種類が選択可能

1. Validting Notary

cordapp.jarを保持

Txを受け取ると、「Nodeと同様にcordappのContractやResponderFlowを動作させて、TXのState遷移の中身を検証した上で」TXに使用されているInputStateが未使用かをチェック。 InputStateのhash値を自身のvaultに保存し、それを持って消費済みとする

プライバシー×

セキュリティ○

2. Non-validating Notary

cordapp.jarを保持しない

Txを受け取ると、TXに使用されているInputStateが未使用かをチェック。 InputStateのhash値を自身のvaultに保存し、それを持って消費済みとする

プライバシー ○

denial of state 攻撃 があり、セキュリティ×

まとめ: 重要な点

CordaはUTXO base

TXのglobal broadcastはしない

TXは「関係者に対するState遷移の提案」

Contractは「Stateのvalidation code」

Flow は「TXを作成/実行するプログラム」

Notaryは「二重支払いチェックマン」

TXのフローは以下の通り

1. 提案者がInitiate Flow でTXを作成/実行する

2. 受領者がResponder FlowでTXを受領、Contractでstate遷移をvalidation、内容に合意したらsignして提案者に返却

3. 提案者はState遷移に必要な署名が集まったら Notaryへ送信

4. Notaryが二重支払いチェック

5. 晴れてfinality、関係者Nodeのvaultに保存する

Cordapp開発者は

の3つを実装する

後編へ続く

Reference