Corda为何广获金融业好评？全面解析R3的设计哲学-掘金网

Corda是一个为企业打造的分布式帐本（Distributed Ledger），由R3开发、维护并于2016年正式开源，是与企业以太坊和Hyperledger Fabric齐名的知名联盟链。Corda相当独特— —首先，它的设计思路与其他两者相当不同，例如它使用的是「未花费交易输出」（Unspent Transaction Output, UTXO）模型而非「帐户模型」（Account Model）；其次， Corda也有截然不同的目标：「易于监管、注重脉络、反映现实」是它的设计哲学。

究竟Corda 是怎么设计的？又为什么会这样设计？在本文中，笔者将会简述Corda 的运作流程，并探讨Corda 的设计思路与设计哲学，同时介绍Corda 独具的「可监管性」。

笔者所在的公司BSOS，为Corda官方技术伙伴，具开发Corda的实务经验。为了与下文所提及的技术做出区分，笔者暂且把起源于比特币／以太坊的区块链技术体系称为「中本区块链」（Nakamoto Blockchain）。

Corda的起源

Corda是针对金融业协作效率，进行升级改进的一种技术方案。相对于中本区块链「建立去中心化金融体系」这样横空出世又带有密码庞克（Cypherpunk）色彩的激进方案，它显得温和平稳地多。R3认为当今的金融业之间的协作模式不仅缺乏效率，而且成本高昂— —原因是每个银行都各自维护自己的帐本，为了追求严谨，彼此验证帐本是个耗资费时的工作；不仅如此，每个不同的协作场景都需要重复一遍验证流程，这也让协作变得没有效率。对此，R3提出的解决思路很直观：把帐本从银行「之内」，放到银行「之间」，让银行共同维护一份帐本，并降低建立信任的成本。

简单来说，Corda可以让两家甚至多家银行能够共享同一个帐本，形成对帐本的「共识」，并且能彼此验证帐本内容，降低信任成本。那么该如何降低成本呢？降低成本几乎可以等同于降低人为因素，让过程自动化。Corda能够让帐本依照双方事先缔结的「合约」与「流程」自动化地执行交易。

左一与左二：现有的协作范式；右一：Corda 提出的协作范式。出处：Corda 白皮书

在金融业协作的大背景之下，Corda的设计除了受到中本区块链很大的启发，亦注重「易于监管、注重脉络、反映现实」的设计哲学，这赋予Corda一个很鲜明的立场。以中本区块链为基底，Corda在帐本、共识与合约的设计上都发展出独具特色的架构。在本文中，笔者将针对这三者的设计思路进行更详细的说明。

在此之前，我们先来看一下Corda 的基本组件与运作流程。

Corda概观

Corda的网络组成。出处：Corda 官方文件

Corda是一个对等网络（Peer-to-peer Network），参与节点（Participant）——或简称Corda节点，是Corda网络的主要成员，它们可以依照场景自由组成不同的商业网络（Business Network ）。

除了Corda节点，还有一些必要的服务节点，例如负责检查交易双花（Double Spending）的公证服务；负责身份与权限控管的身份服务（Idneitity Service）；负责节点查询的网络映射服务（Network Map Service）；以及负责引入真实世界资讯的预言机（Oracle）。

Corda 节点

Corda 节点架构。出处：Corda 官方简报

Corda节点的架构如上图，其中包含：服务节点所需的模组，例如公证模组与身份模组；与交易执行与储存相关的模组，例如Java虚拟机（JVM）、交易资料库（Rows ）与金库（Vault）；以及一个或多个运行于Corda之上的分布式应用程式：CorDapp。

Corda 节点内的「金库」与开源专案Hashicorp Vault 是不同的东西

CorDapp 简介

CorDapp 是运行于Corda 之上的分布式应用程式，所有的Corda 节点皆需透过CorDapp 来发出交易、形成共识、以及更新帐本。

概念上来说，CorDapp是对业务逻辑的封装，这使复杂的金融业务能够比较容易地在不同机构之间重现或转移。Corda节点也可以同时运行多个CorDapp，同时参与不同协作场景。

具体来说，这些业务逻辑指的是「流程」、「状态」与「合约」：

流程（Flow）：每个CorDapp皆会对应一个唯一的、由开发者依实际需求制定的「流程」，通常与业务流程相关，它是在交易的发起者（Initiator）与回应者（Responder）之间从发起交易到确认交易所需的步骤集合，类似于协定（Protocol）。特别的是，「公证服务」的身份也是在流程中被指定。
状态（State）：每个CorDapp都有「状态」，以表达比单纯的帐户余额更丰富的资讯。然而这里的状态仅定义了交易的状态「格式」，其本身并不实际保存数值，只有在发起交易时才会依照此格式将实际「数值」记录到交易上。
合约（Contract）：每个CorDapp的「状态」皆会对应一份「合约」，它是一组验证交易有效性的约束规则集合——也就是真实世界对「合约」的定义。值得一提的是，CorDapp 「合约」与中本区块链的「智能合约」是两个截然不同的概念。

实作上来说，CorDapp 是一个JAR 档，其内包装了Java 类别，并运行于JVM。上述的「流程」、「状态」与「合约」皆各有其相应的Java 类别，Corda 官方也提供了基本的模板让开发者能于其上开发CorDapp。

Corda交易的四大阶段

尽管CorDapp 可以设计「流程」以因应不同的业务逻辑，交易流程的大致上仍可以分为四大阶段：

发起交易：发起者根据CorDapp「状态」与「输入」求出新状态的值；接着产生带有新状态的交易并对其签章；
验证交易：回应者根据交易指向的「合约」进行验证，若交易有效则对交易签章，关于「合约」的功能将在下文详述；
公证交易：由指定的「公证服务」再次验证交易，若交易有效则「公证服务」会对交易签章；
更新帐本：发起者、回应者检验交易是否附有「公证服务」的签章，若有则更新帐本。

值得注意的是：Corda交易仅在交易双方验证、执行，交易内容也不会广播给所有节点，这样的交易流程更符合在真实世界发生的交易流程，这有别于中本区块链的「排序—执行」共识模型；另一方面，Corda对维护帐本共识采取的作法也与中本区块链截然不同— — Corda无需维护全局唯一的交易顺序、也不以去中心化的范式决定「记帐权」，它仅需维护所有节点对交易「独一性」（Uniqueness）的共识，而这个工作可以透过一个能观测全局的「公证服务」来完成。关于共识与「公证服务」的细节，笔者将于下文详述。

接下来，我们就来深入探讨Corda 的设计思路。

Corda 的设计思路

如前言所述，Corda 是受中本区块链启发的技术，究竟在帐本、共识与合约的设计上，它向中本区块链借镜了什么？又发明了什么？

1. 帐本：扩充UTXO，并将帐本局部化

UTXO 模型

「未花费交易输出」（Unspent Transaction Output, UTXO）是一个经典的发明，也是比特币使用的模型。相对于帐户模型（Account Model），UTXO的状态并不集中在一个单一的巨大树状资料结构——或称为「世界状态」（World State），而是分散地被记录在每一笔交易中。

在UTXO 模型中，每个交易都会有「输入」与「输出」：

企业以太坊（Enterprise Ethereum）解决了什么问题？

现今我们一般认知的区块链技术，也就是公有链（Public Chain），首先起源于骇客圈，其强调的是去中心化的治理与无需许可的参与，以太坊便是箇中代表。尽管这些技术是完全开源的，

输出即是新的状态；输入则是其他交易的输出。

例如上图中，右侧的交易「TRANSACTION Hash=1ba0ce7a71…」具有两个「输入」，分别对应左侧交易「TRANSACTION Hash=95fd065cb0…」的第二个「输出」与左侧交易「TRANSACTION Hash=0dbfcf6665…」的第一个「输出」。

输出具有两种状态：「已花费」（Spent）与「未花费」（Unspent）。若某「输出」已被其他交易当成「输入」，则该「输出」就是「已花费」的，同时不能再次作为其他交易的「输入」。UTXO模型中必须防止「双重花费」（Double Spending），以保证帐本的安全性。

UTXO 模型能够表现状态演变的完整历程，让每个过程都清清楚楚，这样的特性对注重原始单据的金融业来说更加适合。同时， UTXO 模型之下的交易顺序是自然确立的，这也有利于更轻量的共识机制设计。

Corda 交易的内容

Corda也在UTXO的基础之上进行诸多扩充，例如引入「指令」（Command）与「附件」（Attachment）的设计等等，以上再搭配CorDapp的「状态」，丰富了UTXO的表达能力，以实现更复杂的价值转移。值得一提的是，「附件」可以是具有效力的合约法律文本，即使出现非预期的交易结果，也能依循实际合约的文本采取后续行动。

Corda 的帐本是「局部化」的。出处：Corda 官方文件

UTXO模型之下的帐本即为由所有交易组成的有向无环图（DAG）之边缘（Edge）的状态集合。如概观所述，Corda的交易只会由相关各方保存，并不会被广播至全网，因此Corda节点维护的是一个仅与自身相关的「局部」帐本，而非带有所有交易的「全局」帐本，如上图所示：Alice的帐本有交易2、6、5、4、1；而Bob的帐本仅有交易2、6。这样的结果是所有：交易都不再被所有节点验证，因此任何节点只能自行获取及验证与该交易与该交易上游的所有交易，一路追朔到源头。事实上，这种「惰性验证」（Lazy Validation）的范式对整个网络的算力来说是比较轻量的。

2. 共识：无需区块链，使用更轻量的共识机制

Corda「公证服务」，出处：Corda 官方文件

Corda是一个分布式帐本，它同样需要维护「共识」以确保帐本运作，它把共识的两种属性：有效性与独一性，分别交由不同的机制来维护。

交易的有效性由交易相关各方确保；交易的独一性由「公证服务」验证，而这两者其实都未必要使用区块链，为什么呢？首先，「公证服务」是相对中心化的设计，无需藉由区块辅助记帐权的决定过程；其次，由于UTXO模型的交易顺序是自然确立的，因此共识的形成无需考虑交易的全局排序，也就无需利用区块来确立顺序。

「公证服务」藉由保存多个来自不同节点的交易来检查交易是否有被「双花」（Double Spending）以确认交易的「独一性」。公证服务皆具有实名制的身份，只有具足够公信力的公证服务会被指定。每个交易即将被送往的公证服务都是被直接指定的，这里没有如「工作证明」这般的赛局。

事实上，虽然这种公证的作法与现今的商业运作逻辑相去不远，然而与现有的作法相比，公证服务还具有以下两点特性：

所有操作皆为自动化执行，并且公开透明；
公证服务可以是由不同组织组成的丛集，每个公证节点先各别验证再透过拜占庭容错（BFT）或故障容错（CFT）的共识演算法形成共识，彼此监督制衡。

3. 合约：需与流程搭配以实现可程式化的价值

Corda 合约。出处：Corda 官方文件

Corda合约正如同我们在真实世界已然习惯的各种合约— —它们提供的是板上钉钉的、用来检验「状态」的规范，而违背合约的交易将会是无效的。

举例来说，租屋时的「租赁契约」具有房屋状态的规范，例如墙壁不能打洞、家具保持完整等等。若是违反契约，则租屋的交易就会无效化，轻则直接终止租赁交易，重则必须承担违约罚金。

Corda 合约与真实世界合约的映射关系紧扣「反映现实」的设计哲学，非常便于将原本在金融业已运行多年的各种合约照搬到Corda 上面。

如果拿「Corda 合约」跟「以太坊智能合约」做概念上的比较，我们会得到下面的结果：

也就是说，Corda 的「合约」与中本区块链的「智能合约」并非同等的概念，它们具有不同的目的与功能：

智能合约：是可执行的程式码，其中含有多个可呼叫的函式，且具有价值转移的能力，实现「可程式化的价值」（Programmable Value），把中本区块链变成一个通用计算平台；
Corda合约：是映射于帐本的真实世界规范，更贴近合约的原始定义。它虽然同是可执行的程式码，但是仅有一个事先制定好的介面，除了验证交易之外，没有其他功能。

尽管Corda 合约本身的表达力有限，Corda 仍可以透过「流程」与「交易」的设计来实现「可程式化的价值」，例如把多个交易串成「流程」。关于实作细节，官方文件有提供详细的范例，笔者就暂不赘述。

让Corda 更易监管的设计：观察节点与紧急通道

与其他两大联盟链相比，为金融业而生的Corda 可以说是最了解监管、也最易于监管的分布式帐本。从整合公钥基础设施（PKI）以便于控管与追踪的节点实名制，到能显示完整状态历程与交易脉络的UTXO 模型，都相当适合利用在监管的执行。

除此之外，Corda 有一些特别的设计，能让监管更积极介入：

观察节点（Observer）：「观察节点」是可以观察交易过程的特殊节点。虽然Corda只允许交易相关各方保存交易资料，但是不实际参与交易的「观察节点」却可以获取其观察对象的交易内容。
紧急通道（Emergency Access）：Corda还具有「紧急通道」这样的机制作为特殊情况的逃生门，让某些「特殊节点」可以进行如：暂停交易、修正错误交易等等的操作。虽然它看起来有点违反分布式帐本本身的定义，但对于Corda所要处理的金融业场景来说，大概有其必要性。