Simplexity

R3 Corda概念理解

Posted on Edited on
Symbols count in article: 4k Reading time ≈ 13 mins.

Corda的设计理念

R3 Corda: A Distributed Ledger Designed for Financial Services : R3 CTO在2016年设计之初分享的设计理念及心路历程

  1. 专门针对金融场景开发，而非通用区块链。受区块链思想的影响，在很多设计理念上考虑了当前金融领域的特点和经典场景。
    • 交易不再全局广播，只在相关方可见；
    • 引入可信公证人机制；
    • 没有经典的区块&全局一条链的设计等等；
  2. 借鉴了区块链经典思想，回归到本质：共识，有效性，唯一性，不可篡改性，可验证性。
    • 使用公证人机制防止双花；
    • UTXO模型，从单纯的资产扩展到状态；
    • 签名放篡改抵赖；

无链之链，非链之链。更恰当应该叫分布式账本DLT。基于金融领域真实存在的一些假设和前提（例如存在可信公证人），更像是借鉴区块链思想去解决金融领域的实际问题，提升效率。

Concept & Model

1. P2P Network Component

• Nodes, communicating using AMQP/1.0 over TLS. Nodes use a relational database for data storage.
• A permissioning service that automates the process of provisioning TLS certificates.
• A network map service that publishes information about nodes on the network.
• One or more notary services. A notary may itself be distributed over multiple nodes.
• Zero or more oracle services. An oracle is a well known service that signs transactions if they state a fact and that fact is considered to be true. They may also optionally also provide the facts. This is how the ledger can be connected to the real world, despite being fully deterministic.

  1. Network Map Service网络地图服务，发布每个节点的IP地址，证书及提供服务接口等。节点可以订阅网络地图变更事件，启动时主动注册。节点可以本地缓存地图，收到其他节点连接时基于地图校验以及身份体系服务作校验。

2. Data Model

• State objects, representing an agreement between two or more parties, governed by machine-readable Contract Code. This code references, and is intended to implement, portions of human-readable Legal Prose.
• Transactions, which transition state objects through a lifecycle.
• A Flow Framework, which enables parties to coordinate actions without a central controller.

  1. 节点存储的State可以是任意格式，不限定于KV结构。丰富了其在金融领域的实际表达能力，可以是包含真实的合同文件等。Corda关注的是状态转移，所以除了最开始的发行外，所有的后续的状态转移都必然有输入输出。

3. Transaction Model

• Input references : These are (hash, output index) pairs that point to the states a transaction is consuming.
• Output states : Each state specifies the notary for the new state, the contract(s) that define its allowed transition functions and finally the data itself.
• Attachments : Transactions specify an ordered list of zip file hashes. Each zip file may contain code, data, certificates or supporting documentation for the transaction. Contract code has access to the contents of the attachments when checking the transaction for validity.
• Commands : There may be multiple allowed output states from any given input state. For instance an asset can be moved to a new owner on the ledger, or issued, or exited from the ledger if the asset has been redeemed by the owner and no longer needs to be tracked. A command is essentially a parameter to the contract that specifies more information than is obtainable from examination of the states by themselves (e.g. data from an oracle service). Each command has an associated list of public keys. Like states, commands are object graphs.
• Signatures : The set of required signatures is equal to the union of the commands’ public keys.
• Type : Transactions can either be normal or notary-changing. The validation rules for each are different.
• Timestamp : When present, a timestamp defines a time range in which the transaction is considered to have occurrred.
• Summaries : Textual summaries of what the transaction does, checked by the involved smart contracts. This field is useful for secure signing devices.

Corda流程

  1. 节点只需要存储跟自己相关的信息，而且也只能看到跟自己相关的，任何普通参与方都没有全局账本，只有跟自己相关的局部账本。相对于传统区块链的共享数据，更关注于保护隐私。节点B需要验证A的porposal，验证输入有效性，例如说转让资产的场景，A当前所持有资产是第三方C在之前的交易里转给A的。B需要一直回溯和验证状态转移链路，一直到最开始发行的起始。从这个意义上，这是状态转移链。Identity & Permission Service解决了交易链路上各个涉及方的身份认证问题。Corda规定了propasal的发起方需要存有这些历史记录供对手方查询，解决了数据来源的问题。在类似于零售交易的场景下，回溯链路可能会很长，可以通过State re-issuance剪枝等方式来解决。
  2. Notary Pool公证人池，共识算法可插拔式，可以是BFT，也可以是raft等。按照最基本的定义，公证人可仅作为消除交易并行冲突，防止双花，保证唯一性这个基本职能，不作为具体交易的验证节点，因此就不需要看到交易的具体内容。
  3. 交易签名的机制是定义在flow里，可以配置AND/OR等多种组合阈值规则（复合签名）。每个state都指向某个notary，单个交易里不允许消费由不同notary控制的多个state，因此单个交易就没有必要协调多个notary来达到原子性。

一些想法

  1. Corda设计的初衷就是针对银行场景，可信公证人身份很容易在现实中找到对应的角色，例如央行，监管机构等。同时，交易的合法/签名规则是最开始定义在flow里的，因此除了交易方，公证人之外很容易引入其他角色。例如规定一笔交易必须经过监管节点签名等等，现实中的合规检查和监管都容易实现。但同时这种星型拓扑给公证人和监管角色节点的性能及安全都提出了更高的要求，技术处理不好可能会成为整个网络的单点故障。
  2. 目前看Corda专注和适用的场景还是偏向低频的批发型B2B业务。如果将其作为零售性CBDC的技术方案，性能是否能满足有待验证。类似于之前分析的OpenCBDC方案，货币发行当局作为公证人验证交易的合法性，存在性，唯一性，与Corda的设计有相似之处。但正如在之前文章分析的，UTXO模型的固有局限性可能还是一个制约。
  3. Corda跟传统区块链的形态差别还是很大的，针对金融场景设计意味着同时放弃了对通用场景的支持。但是这种借鉴技术又不拘泥的做法还是值得学习的，毕竟技术最终也是为业务而服务的。正如R3的CTO所说，“Every successful project I’ve worked on started with the requirements, not some cool piece of technology, and I was determined to bring that discipline into our work at R3.”

Ref.

官方文档: corda-platform-whitepaper
官方文档: corda-technical-whitepaper