#目的
Corda V3.2のドキュメントを参照しながら、Cordaのコンセプトを理解する。
ドキュメントの内容を日本語で簡単にまとめたもの。
whitepaperはこちら。
The detailed thinking and rationale behind these concepts are presented in two white papers:
Corda: An Introduction
Corda: A Distributed Ledger (A.K.A. the Technical White Paper)
こちらのコンセプト説明動画は日本語字幕がついているので、英語が苦手な方にもおすすめ。
#内容
Cordaのドキュメントに沿ってみていく。
そもそもCordaって何?という方はCordaとはを参照してください。
##The network
- ネットワークはCordaのノードで構成されている
- ノードはCordaサービスとCorDapp(スマートコントラクト)を実行する
- 通信をpeer-to-peer(broadcastではない)にすることで、当事者間以外にデータは共有されない
- 相手側のpeerがダウンしていた場合はキューに保存される
- network map serviceがIPを発行しノード間で通信する
- ネットワークはpermissionedである。つまりBitcoinなどとは違い参加には許可が必要である
- doorman serviceがKYCプロセスを実行して証明書を発行することでネットワークに参加できる
- ノードが提供できるサービス
- Notary - 台帳の更新を検証し、uniqueness(2重取引でない)を保証する。ネットワークで1以上存在する
- Oracle - 外部のデータをもとにトランザクションを検証する。ネットワークで0以上存在する
##The ledger
- 台帳は主観的なもので、メンバーごとに持っている記録は異なる(=全ての記録を持つ台帳は存在しない)
##Identity
-
CordaでいうIDは2つ
- 法的ID(銀行Aや企業Bなど)
- サービスID(NotaryやOracleなど)
-
IDは以下のどちらかに該当する
- well known
- 一般に識別可能な公開鍵
- 参加者の機密性が要求される取引には適さない
- network map serviceが発行
- confidential
- トランザクションに関わるIDにのみ発行される公開鍵
- Notraryサービスなど一部には公開される可能性はあるが、名前とX.509証明書の配布には制限がある
- well known
-
証明書
- ノードがはじめて起動すると、鍵ペアが生成され、証明書署名要求がDoormanに送信される。
- DoormanはIDチェック後、認証局(CA)として使用されるノードに証明書を発行する。
- そのCA証明書を使って、ノードは自動で2つの証明書を作成して署名する。
- TLS証明書
- well knownIDのための署名者証明書
- 最後にノードはアドレスとwell knownIDを含むノード情報を作成し、network map serviceに登録する。
##States
- stateとは、台帳上の共有されているある時点でのfact(事実)のことである
- stateはBitcoinのような通貨ではなく、あらゆる静的モデル(cash,bond,,,)を表現することができる。
- CordaはUTXO (Unspent Transaction Output)モデルを採用しており、statesはImmutableである。
- その一方現実世界ではstateは時間と共に遷移するため(借金を返済するなど)、Cordaも現実世界に合わせる必要がある。
- 古いstateを過去のものとしてマークすることで、新しいstateに置きかえる。(新しいstateがHEADとなる)
- 過去としてマークされたものは、監査のために使用するため消去されずに台帳に残る。
- Vaultはstate(過去または現在)を格納しているデータベース。
- Vaultは各stateシーケンスのHEAD(最新のstate)を追跡し続ける。
##Contracts
###コントラクト
- 潜在的に信頼しない当事者を合意に至らせるために、トランザクションがルール・規則に沿ったものであるかを検証するコントラクトコードが必要。
- stateにコントラクトコードへの参照が含まれている(stateの図のContract Ref)。
- 参照先のコントラクトコードがステートを含むトランザクションを検証するために使用される。
###コントラクトコード
- コントラクトコード内にverify functionを定義して、制約に従っているかを検証する。
- 制約に違反している場合はverify functionは例外をスローする。制約に従っている場合はトランザクションは有効とされる。
- ノード間の台帳の整合性を保つために、コントラクトは特定のトランザクションを許可するか、拒否するか常に同じ結果を出力しなければならない。例えば、乱数や外部のデータを利用することは禁止されている。
- 禁止されているライブラリの利用を防ぐため、JVMを修正したsandbox内でコードを実行する。
- sandbox内では使用が許可されているライブラリのみが実行できる。
- コントラクトコード例
- コントラクトコードは外部のデータを参照できず、あくまで内部的な規則の検証であり、内容までは検証することができない。(例えば相手先から提案されたローンの借入額には応じることができない、などの判断は当事者がする必要がある)
###Oracle
- 外部データを参照するためには、Oracleを使用する。
- Oracleの章参照。
###Legal prose(法的文書)
- コントラクトコードでは、実世界のすべての事象を処理することは出来ない。
- 法的な衝突の解決には、既存の法律制度ないし司法制度を参照する必要がある。
- コントラクトコードは、法的文書を参照することができる。
- 法的文書の機能は未だ実装途中であり、現時点ではまだ不十分のためサポートしていない。
##Transactions
- トランザクションはstateを時間の経過と共に変化させる仕組みのこと。
- トランザクションは複数のstateを一度に変化させるために必要である。
- トランザクションに含めることができるのは、インプットステート、アウトプットステート、コマンド、Time-windows、アタッチメントの5つ。署名はトランザクションの中には入らない。
###トランザクションの遷移
-
トランザクションの3つのタイプ。
-
トランザクションはアトミックである。トランザクション内の全てのstateの更新が通れば、トランザクションは有効であり、1つでもstateの更新が失敗したら、トランザクションは無効となる。
###トランザクションのコミット
- コミットされていないトランザクションは台帳を更新する提案に過ぎない。アクションを要求する命令ではない。
- 提案のためのコードやロジックは他の当事者に共有する必要はない。ただし検証のためのコードは共有する。
- コミットするために、トランザクションに関わる全ての当事者による署名を得る。
- 署名された時点で、stateは過去のものとしてマークされ新しいstateが追加される。
###トランザクションの検証
- 次の2つの条件が満たされている必要がある。
- Transaction validity
- スマートコントラクトコードによる検証によりトランザクションが有効である
- 当事者によって署名がされている
- Transaction uniqueness
- 2重取引がされていない(参照先トランザクションがすでに使用されていない)
- Transaction validity
###その他コンポーネント
- インプット、アウトプットstate以外のコンポーネント
####Commands
- Commandはトランザクションの意図を示すものである。(トランザクションの動詞のようなもの)
- 公開鍵とコマンドと関連付けることにより、特定のステートの遷移について必要な署名者を特定する。
- トランザクション全体に対し必要な署名者は、全部の公開鍵を合体したものとなる。
- 例えば、下の図だとSETTLEコマンドはALICEとBOBの署名を必要とする。
- その他、外部のデータを取得する一つの方法として、オラクルサービスはコマンド内のデータに外部データを組み込むことが出来る。
####Attachments
- アタッチメントはトランザクションに添付出来る任意のデータファイルのこと。
- 通常 Zipファイルでありハッシュによって識別される。
- 必ずしもトランザクション内に含まれている必要はなく、アタッチメントのバイト列のハッシュが含まれていれば良い。
- アタッチメントは、カレンダーやコントラクトコードなど何度も再利用するようなデータを想定している。
- アタッチメントに含めることができるもの
- コントラクトコードとstateの定義(将来的に)
- データファイル(カレンダーなど)
####Time-windows
Time-windowsは、トランザクションをコミットできる時間枠を指定する。
TIme-windowsの章を参照。
##Flows
- フローは複数ステップの通信を制御する軽量なプロセス。
- 例えば、Aがトランザクションを作成して署名して、Bに送信して、Bが検証して署名して、Notaryが検証して、、、などという当事者間での一連のやり取りをコントロールする。
##Consensus
- コンセンサスは2つのタイプに分けられる
-
Verification Consensus(検証コンセンサス)
- レジャーの更新が有効かどうか、つまりコントラクトコードの制約に従って、トランザクションの当事者が全て署名をしたかどうかを検証する。
- それに加えて、トランザクションへのインプットが正しいかどうかを確認するために、インプットの作成に至ったチェーン内のすべてのトランザクションを検証する必要がある。
- 例えば、下の図でAliceがBobにIOU(借金)を返済する提案をしたとする(一番右のトランザクション)。
- BobはインプットであるCashが正しいかどうか検証するために、前のトランザクションを検証する(真ん中のトランザクション)
- 真ん中のトランザクションはAliceとDanのものだが、BobはこのトランザクションをAliceから提供してもらい検証する。
- さらにBobは前のトランザクションを検証する(一番左のトランザクション)
- このようにして全トランザクションを検証できた(=トランザクションのチェーンが壊れていないことを証明した)場合のみ、Bobは新しいトランザクションに署名する。
- BobはAliceから全トランザクションを提供してもらう。Aliceは前のトランザクションを既に検証しているため持っている。
- 残念ながら、分散台帳技術ではこれを避けることは出来きない。
-
Uniqueness Consensus(ユニークネスコンセンサス)
- レジャーの更新が一意かどうか。つまり2重支払いかどうかを検証する。
- インプットstateが他のトランザクションに参照されていないかを検証する。
- Notaryサービスによって、ユニークネスコンセンサスが検証される。
- 一度stateが参照されると、過去のものとしてマークされる。その結果、同じstateを二度使うことは不可能となる。
-
##Notaries
-
Notaryは2重取引を防ぐためのサービスである。(ユニークネスコンセンサス)
- トランザクションがコミットされFinalize(確定)するためには、当事者間の署名に加え、Notaryからの署名も必要となる
- ただし、トランザクション内にインプットステートを持たない場合やTime-windowがない場合は、Notaryからの署名は必要ない
- Notaryは、インプットstateの参照が過去に使われたかどうかについて、消費されたstateの参照マップをみて判断する。もしstateの参照が他で使用されていなければ、Notaryからの署名が受けられる。
-
オプションでトランザクションを検証する。(検証コンセンサス)
- Notaryがトランザクションを検証する場合は、Notaryもトランザクションの中身を見ることになる
-
複数のNotaryがCordaネットワーク上に存在できる
- 異なるニーズに合わせて、異なるコンセンサス・アルゴリズムが運営出来る
##Time-windows
- トランザクションにTime-windowが含まれた場合は、トランザクションはその期間内でのみコミットできる
- Time-window外のトランザクションはNotaryによってコミットされない
- ポイントの代わりにウィンドウを使用するのは、ノードやNotary間で時刻同期されておらず絶対時間がないため。
##Oracles
- factはトランザクションのコマンドの一部として組み込むことができる
- Oracleサービスはfactが正しいかどうかを検証し署名する
- 例えば FX レート、金利、株価などのレジャー外のfactを利用できるように、Oracleが窓口となる。
- トランザクション内で再利用するデータ(例えばExcelファイルなど)をアタッチメントとして提供も可能
##Nodes
- CordaノードはJVM内で実行されるプロセス
- ノード内ではRPCで、ネットワーク上の他ノードとはメッセージングサービスでやりとりをする
- ノードのカスタム機能を CorDapps(コーダップス)と呼ぶ。開発者はCorDappsを開発する。
- 開発者の視点からみたら以下のようなイメージになる
#まとめ
全体概要やwhitepaperから一方踏み込んだところでした。
#参考文献
Key Concepts
https://docs.corda.net/key-concepts.html