Corda Network 構成
概念編
Corda Networkって何?
Corda を実際に運営する上では、どのようにネットワークを構成するのかも重要になってくる
具体的に、Networkを構成する要素としては以下の5つが存在する
1. Node
2. Notary
3. Trust Root
4. Identity Manager
5. Network Map Service
これら5つのコンポーネントをどのように運営するかのパターンとして以下の3つがある
1. The Corda Network
2. Segregated Network
3. Private Network
これらについて以下で説明していく
Corda Networkを構成する要素
https://gyazo.com/bf0ff11ba05e4eca74404e2b8ae965a9
1. Node
Corda コンソーシアムネットワーク参加者が運営するノード
独自でVaultを持ち、自身に関係のあるState(Transaction によるState Transition)を保存している
Flow で Transaction を生成し、取引相手のnodeに送る
コントラクトを使って、TXをvalidationする
2. Notary
二重支払い防止 (input stateの二重消費) を責務とする
Corda ネットワーク内のNode同士のTXの全てに署名する
Notaryの署名を持ってファイナリティを得られる = 唯一このtxのみでinputsが消費されたという証明
以下の2種類のNotaryが存在する
Non-validating Notary
UTXOのハッシュ値とそれが使用済みかどうかのmappingだけをvault内に持っていて二重支払いチェックのみを行う
Cordappは持たない
validating Notary
TXの中身まで見て、TXの構造が正当かどうかまで検証する
etaro.icon > ここでどこまで検証しているか。ContractでいうShape constraints (outputの数とinputの数, TXに入ってるCommandの数のvalidation)なのか、Contents constraints (実際のinputとoutputの中身のvalidation)なのか、Required Signer constraints(commandに入ってる署名が揃っているかのvalidation)なのか
etaro.icon > A. Validating Notaryは、CorDappを共有されているので、Nodeと同様に全てのconstraintsの検証をする
Notaryは "TXの中身を見て検証し、そのinputが使用されたというmappingは保存する" が、"TXの中身を保存したりはしない"らしい
つまり、Notaryが「Tokenの総発行量」などの全体Stateを持ち、各ノードがそれを問い合わせるといったことはしない
この場合は、Tokenの発行者(issuer)がTokenの全体Stateに関わる全てのTXに署名するといった形を取ることになる
下記のData visibilityの表を参考
Data visibility
https://gyazo.com/b4ee1f4bb3544fd6853a87dbce610e12
3. Trust Root (別名: Root CA)
参加者Nodeに対して付与される公開鍵/証明書を発行する認証局
Root証明書の保持等を行う
当然だが、高度なセキュリティ要件が求められる
証明書は以下のような構造
https://gyazo.com/7516410211af1bca38d22577c6934360
証明書の階層構造
以下の構造をベースに、自由な階層構造を構築できる。
https://gyazo.com/2614fcf5d5b49ba7b67a7b63bd336dfd
Cordaノード間の通信はTLSで暗号化されるが、そのときに利用する証明書は以下の階層構造で生成される。
https://gyazo.com/7666bd5ad24b322f784437ee97fc9006
証明書の階層構造の例
https://gyazo.com/a6e45955cc68280bac72457f1d1c65d8
Confidential Identityは以下のように派生する
https://docs.corda.net/_images/certificate_structure.png
4. Identity Manager (旧名: Doorman)
新たなNodeがネットワークに参加したいぜって時に Trust Root から発行されたIdentity Manager自身の鍵で作成したNodeの公開鍵/証明書を付与して、ネットワークへの参加を許可する主体
新規ノードに対しX.500識別名と公開鍵のペアから成る証明書を提供することで、Cordaネットワークへの参加を承認する
CRL(Certificate Revocation List)によって失効した公開鍵を管理している
新たなNodeが参加しようとする時にしか呼ばれない
5. Network Map Service
以下のようにネットワークに参加してる各Nodeの公開鍵、証明書、IP、「名前、地域、国」などのNodeInfoを持っている
https://gyazo.com/6da25643e0b05f22298227b7f155265d
ネットワーク参加者の "電話帳" と呼ばれている
shuntak.icon > DNSみたいな感じか
Nodeは初めての相手とTXのやり取りをする際にここに「このPartyとTXのやり取りしたいんだけどInfo教えてちょ」と聞いて、教えてもらうという処理をしている
etaro.icon > 初めての相手の時のみNetwork Map Serviceに聞きに行ってるのか、毎回聞きに行ってるのか
A. 各ノードはNetwork Mapのキャッシュを持っている
akinama.icon > 更新された時のキャッシュのデータ齟齬とかは発生しうらない?
https://gyazo.com/cc82378926534938d358892b46400c84
etaro.icon > Confidential Transaction系の機能で、新しくpubkeyを作成して、それを匿名Accountとして使用するが、あれはNodeが新しく生成したpubkeyとNodeのpubkeyで署名した証明書を作成し、それを取引相手にだけ共有することで、取引相手は「正当なNodeの鍵で署名された証明書付きなので正当なAccount keyである」ことを検証でき、その「他のNodeから見たら匿名」のpubkeyとTXのやり取りができる。Validating Notaryの場合はNotaryにAccount keyの証明書を共有しなくてはならない?
Corda Networkの構成パターン
1. The Corda Network
https://gyazo.com/d1a5334a2188e23417f7fba1612e016b
Notary
Trust Root
Identity Manager
Network Map Service
を全てThe Corda Network Foundationが運営するというパターン
メリット
インターオペラビリティ
そもそも上記の4つの管理者コンポーネントが共通なので異なる子ネットワーク同士でもStateの変更等は可能
Notaryも共通だし、Network Mapが共通なら、他の子networkのnodeのIPとかも知れるため
デメリット
Notaryすら Corda Network Foundation運営なので、TX単位で署名されないなども究極起こってしまう
ただし、non-validating Notaryならば、TXのinput stateのrefしか見えないので、不正のしようがない
どちらかというと可用性等の問題か
Notary が署名するごとに課金、nodeが参加するごとに課金など、Corda Foundationに対するTX課金が発生する可能性がある
ネットワークが全世界共通になるので、規制などでこれが引っかかる場合がある
The Corda Network Foundationは、このネットワークの子ネットワークの参加者たちが参加できる議会形式になっている
オフチェーンガバナンス
2. Segregated Network
https://gyazo.com/73ec5ed18a4f02f8de4a543cdb82dfe6
Notary
Network Map Service
のみ独自で運営するパターン
Trust Root
identity manager
Network Map Service
Network Mapはインターオペラビリティのために Corda Foundation運営のものも使える?
は、Corda Foundation運営のものを使用
メリット
Notaryは、自ネットワーク運営
デメリット
Notaryの運営コスト
現状はまだexperimental
もちろんIdentity manager、Trust RootがFoundation運営のため、コンソーシアムに新たに参加する際等はCorda Foundationに依存する形になる
3. Private Network
https://gyazo.com/81ca39d4b9863fc4ca574cf7ae9ac2cf
4つの管理者コンポーネント全てを自前で運営するパターン
ネットワークの中でビジネスオーナーを決めて、その主体が用意するのが通常
Notary Poolは、あくまで単なる冗長化の想定
RaftやBFTなどはexperimentalな機能
メリット
Corda Foundation への依存を最小限に
ネットワークが閉じているので規制などに対応しやすい
デメリット
インターオペラビリティがない
etaro.icon > 正確には「ない」というより、他のブロックチェーンとのクロスチェーンと同じようなことを考えなければならないというだけ。逆に個別にCorda以外のブロックチェーンと繋ごうと思った場合に、管理者系Nodeが自前でないために、private network以外では対応できない可能性あり
運営コストが高い
特にTrust Root はセキュアな証明書を発行する必要があるため、セキュリティ要件が高い
プライベートネットワークでも Corda Enterprize版の課金はある?
プライベートネットワークにおいては、ビジネス上のオーナー(Business Network Owner : BNO)が各管理ノードの運用をすることが想定されている
以下のような、BNO向けのツールも提供されている
https://gyazo.com/3c1da096847533e80ace0cbedef535d0
詳細編
Corda Enterprise Network Manager 全体像
https://docs.cenm.r3.com/_images/enm-high-level.png
Trust Root
PKI (HSM / Keystore)
Keystoreの場合、jks (java key store) ファイルを設置する
Utimaco SecurityServer Se Gen2
Gemalto Luna
Securosys PrimusX
Azure Key Vault
Databaseを持たない
Identity Manager
Databaseを持つ
Contains information relating to certificate signing requests of nodes wanting to join the network as well as information regarding revocation of nodes from the network.
Network Map Service
Databaseを持つ
Contains information relating to the current participants on the network, the current network parameters and any pending parameter updates
データベース
以下DBを利用可能
Microsoft SQL Server
PostgreSQL
Oracle DB
H2 (本番利用は非推奨)
Sub Zone
https://gyazo.com/7328f56935655aa5a440b1c330ab451f
Network Map
Nodeが他のNodeのNodeInfoを取得する方法は以下の2つ
1. Network Map ServerにHTTPリクエスト
2. 直接他のNodeからNodeInfoを共有してもらう
HTTP 経由
各Nodeは、networkServicesを使ってネットワーク参加する際に、configの中のnetworkMapUrlに指定されている先に、自分のNodeInfoファイルに署名して送りつける
この時、NodeはNetwork Mapをダウンロードしてきてcacheにする
NodeInfoの詳細は以下
code:NodeInfo.kt
@CordaSerializable
data class NodeInfo(val addresses: List<NetworkHostAndPort>,
val legalIdentitiesAndCerts: List<PartyAndCertificate>,
val platformVersion: Int,
val serial: Long
) {
init {
require(addresses.isNotEmpty()) { "Node must have at least one address" }
require(legalIdentitiesAndCerts.isNotEmpty()) { "Node must have at least one legal identity" }
require(platformVersion > 0) { "Platform version must be at least 1" }
}
@Transient
private var _legalIdentities: List<Party>? = null
val legalIdentities: List<Party>
get() {
return _legalIdentities ?: legalIdentitiesAndCerts.map { it.party }.also { _legalIdentities = it }
}
fun isLegalIdentity(party: Party): Boolean = party in legalIdentities
fun isLegalIdentity(name: CordaX500Name): Boolean = legalIdentities.any { it.name == name }
fun identityFromX500Name(name: CordaX500Name): Party = identityAndCertFromX500Name(name).party
fun identityAndCertFromX500Name(name: CordaX500Name): PartyAndCertificate {
return legalIdentitiesAndCerts.singleOrNull { it.name == name }
?: throw IllegalArgumentException("Node does not have the requested identity of \"$name\"")
}
}
Network Mapは、各Nodeから送りつけられてきたNodeInfoのHashのlistをDatabaseに保持する
各ノードは定期pollingでこのcacheを更新して最新に保つ
各ノードは、取引相手から送られてきたNodeInfoをhash化して、自身のDBに持つNetwork Mapと突合し、listに含まれていればNetwork Mapに含まれている正当なnodeだと判断する
Network Mapに生えているREST endpointは以下の通り
https://gyazo.com/e05a580dbe9b5d27516cc76fa1f416ee
zone operatorやnode operatorなどの管理者が主にdebug用に使用するためのendpointは以下の通り
https://gyazo.com/4a6de84846727d3bf6b584b7f65b2f3b
他のNodeから直接共有
他のNodeが--just-generate-node-infoコマンドで生成したnodeInfo-${hash}というファイル名のNodeInfoファイルを、主にrsyncで共有してもらい、additional-node-infosディレクトリに格納
そもそも他者ノードにrsyncできなくない?メールで事前やり取り?
shuntak.icon < あれ、これやりたくないからブロックチェーン使うんじゃないの??
こうすることでNodeはadditional-node-infosディレクトリの中のNodeInfoを参照するようになる
Network Parameters
Networkの参加nodeが全員合意した上で、同じ値を使っていないといけないParameters
Cordaの場合は、network operatorがこれらの値の変更に署名して、network map によって各Nodeに共有することによって、全てのノードに新しいparametersを使用させることができる
Network Map Serverを使用している場合
各NodeはNetwork Mapと同時にこのパラメータの値を取得し、network-parametersファイルにそれをcacheして使用する
Network Map Serverを使用していない場合
network-parameters をNodeInfoの生成・共有と同時に行う
network-parametersの中身
minimumPlatformVersion: cordaのversion
notaries: networkで使用しているnotariesのidentity情報とvalidation-type(non-valiかvalidatingか)
maxMessageSize: 各メッセージのMax Size (attachmentは例外)
maxTransactionSize: トランザクションのMax Size (attachmentを含む)
modifiedTime: network parametersが最後にmodifyされた日時
epoch: network parametersのversion number
whitelistedContractImplementations: Contract Codeのホワイトリスト
eventHorizon: Nodeが応答しないと見なされてNetwork map から削除されてしまう時間間隔
その他にも自由にparameterを追加できる
Network Parameters の Update方法
notaryを追加する時、秘匿化やクロスチェーン要件でnetwork parametersを追加する時などにupdateをする
update時には、もちろんnetwork内の全てのnodeに新しいnetwork parametersをsyncする必要がある
Network Map Serviceは、「Updateしたnetwork parametersのhashと変更差分の説明とUpdateの期限」を各ノードに送信する
受け取るNodeは CordaRPCOps.networkParametersFeedを使用して ParametersUpdateInfoを受け取る、Downloaded new network parametersというサーバログも表示される
network operatorは、各node operatorにemailで「network parameters更新したよ!〇〇までにupdateしてね!」という連絡もする
deadlineまでにupdateしなかったらnetwork mapから弾かれちゃう or Node operatorと交渉
Certificate Revocation List (CRL)
CRLとは、無効になったcertificateのシリアルナンバーのlist
certificateにはシリアルナンバーが振られている
CRLはIdentity Managerによって管理され、各NodeはIdentity ManagerのCRLを定期的に同期して保持しておく
各ノードは他のノードと通信する際に、相手のcertificateがこのCRLに存在しないかどうかを確認する
CRR(Certificate Revocation Request)によって、CRLに新たなシリアルナンバーを追加する
一度リストに追加したら消せない
CRL に CRRをする口、CRLを検索する口の2つのendpointが必要
Revocation Service のREST endpoint
https://gyazo.com/37146d79907c5d17985cc4712b90887c
CRR に必要なパラメータ
certificateSerialNumber: revokeするcertificate のシリアルナンバー
csrRequestId : revokeするcertificate を追加したCSR ID
legalName: revokeするcertificate の legal name
reason : revokeする理由
KEY_COMPROMISE: This reason indicates that it is known or suspected that the certificate subject’s private key has been compromised. It applies to end-entity certificates only.
CA_COMPROMISE: This reason indicates that it is known or suspected that the certificate subject’s private key has been compromised. It applies to certificate authority (CA) certificates only.
AFFILIATION_CHANGED:
This reason indicates that the subject’s name or other information has changed.
SUPERSEDED: This reason indicates that the certificate has been superseded.
CESSATION_OF_OPERATION:
This reason indicates that the certificate is no longer needed.
PRIVILEGE_WITHDRAWN:
This reason indicates that the privileges granted to the subject of the certificate have been withdrawn.
reporter : このCRRのissuer
用語メモ
Sub Zones
ENM : Each Network Map
CRR : Certificate Revocation Request
CSR : Certificate Signing Request
CENM
Identity Manager Service, Network Map Service, Notary Nodeを含んだSub Zone を作成できるキット
Reference