著名的金融领域分布式账本R3项目由于有众多金融机构的参与和支持，并且获得了数千万美元的融资，自宣布之日起就受到整个区块链生态环境的瞩目。从公布的一些新闻稿、白皮书中，人们已经了解到：R3的最大特点之一，就是一个没有区块链的“类区块链”系统，但是具体实现方案是什么，与区块链相关的系统对比又有什么特色，还是一个未知数。
随着R3的基础设施Corda项目在2016年11月30日宣布开源，笔者在第一时间对其技术白皮书、在线文档和源代码做了初步的阅读和分析。我们看到Corda的交易验证、共识机制等特性，采用了基于Notary（公证员）的模式。同时，为了服务于现实世界中的企业，Corda还具有很多与外部世界通讯的能力，例如：汇率、股票价格等信息的接收，可以通过一个叫做Oracle（先知）的角色来实现。总之，与此类似的设计还有不少，这一系列选择都是R3根据自身定位有意为之。R3 Corda是一个基于半信任环境的、服务于现实世界金融活动的分布式账本，同时满足信息适度可见和高性能两个核心特性。
Corda区别于其他“类区块链”系统的另一个重要特点，就是系统本身基于一个小众语言Kotlin来开发，运行在JVM之上。从实现层面来看，Corda有着鲜明的Java生态环境特点，例如：其节点使用的通讯、存储技术都是Java领域普遍采用的开源框架组合模型，相信这一点使得Corda非常适合企业使用，同时其自身开发成本也很低。此外，Corda中的合约（contract）以及Dapp应用，原则上是可以基于JVM上的任何语言来开发的，在应用开发者层面，一定程度上减小了kotlin小众化问题的影响。
除此之外，Corda作为较新的类区块链平台，还有很多令人关注的特性，本文将对其与区块链概念相关的各方面特性做一个概览，以便读者较为快速地了解这一著名的金融领域分布式账本。
基本概念与模型
去中心化数据库（Decentralized Database）
在技术层面上，Corda的定位是一个“去中心化数据库”，这一点对于理解Corda的设计和实现理念是非常重要的。
首先，在概念层面，去中心化数据库与分布式数据库有着重要的区别：分布式数据库仍然是一个中心化的系统，其服务目标是接收客户端的消息来存储数据，重点关注的是解决系统内部各个节点之间数据同步的问题。去中心化数据库，则是相互独立的参与方各自的私有数据库，在一定前提条件下同步某一方面的数据，如果参与方之间不完全的互相信任，则无法使用分布式系统中标准的数据同步算法。因此，两类系统的关注点、设计和实现模式大相径庭。
其次，在实现层面，去中心化数据库并不限于一种特定的技术：区块链这一随着比特币诞生的基础设施，可以认为是去中心化数据库的一种实现方式，也是现阶段获得最多认可的一种方式，但不是唯一的方式。从这个角度讲，Corda通过一系列的设计，给我们带来了去中心化数据库的另一种实现方案，这就是Corda系统的核心价值，一旦为人们所接受，必然会在“类区块链”生态系统中占有一席之地。
因此，Corda系统中最基本的概念、数据结构、算法和实现方式，在技术层面都是围绕“去中心化数据库”这一概念来完成的。
状态（State）与UTXO
状态是Corda网络中最基本的概念，我们可以理解状态就是“系统中的事实”，例如：“Alice拥有5000美元”，这就是一个状态。Corda系统的状态设计是基于交易的，也就是说只有一个有效交易的输出才是系统认可的有效状态，这实际上就是人们已经比较了解的UTXO模型。系统中还可以有另一个状态，就是“Alice拥有3000美元”，这是Alice参与的另一个交易产生的输出。假定系统中不再有任何Alice拥有某种资产的事实存在的话，那么从现实世界的角度看，可以认为Alice拥有8000美元。但是，Corda系统中并不存在“Alice拥有8000美元”这一事实，只有前述两个事实。熟悉“类区块链”系统的人都知道，在一个UTXO模型的系统中，Alice只有跟自己做一次交易，以前述两个状态作为输入，才能产生一个新的“Alice拥有8000”美元的状态。与此同时，前两个状态在系统中也就失效了。
与基于交易的状态模型对应的，是所谓基于账户的状态设计。也就是说，每一个交易会形成对账户状态的改变，就像银行存款账户的“余额”会随着该账户的每一次交易而变化。以太坊等区块链系统，采用的就是基于账户的模型（可能有人知道，Serenity声明也支持建立一个UTXO模型的代币系统，只在这里顺便提一句，就不展开了）。这两种模型的优劣，有相关的文章进行讨论，不是本文的重点。笔者的观点是，它们之间的差异与面向对象（O-O）的模式和函数式（functional）的模式之间的差异可以类比。
值得指出的是：采用了UTXO模型的系统，其交易之间实际上就有一个“链式结构”：一个交易的输出，成为另一个交易的输入，交易与交易之间就通过这个方式被串起来了。这样的链式结构，实际上是一个有向无环图（DAG），读者可以自行验证。同时，由于Corda系统的数据不是全局的，所以这样的“链”在系统中会存在多个，相互之间没有连接。因此，Corda系统中虽然没有“区块链”，但是仍然有“交易链”，这也就是笔者称Corda为“无链之链”的原因。
交易（Transaction）
交易就是状态转换的过程，简单地说是{输入状态、交易指令、输出状态}组成的元组，其中输入、输出都可以是一个状态列表。此外，交易还包括其他一些要素，如：附件、时间戳、各种签名以及为采用硬件加密的目的而使用的文字摘要（summeries），比较重要的部分都会在本文中讨论到。这一定义与其他“类区块链”系统中的交易定义区别不大，最主要的差异在于“交易指令”（command）这一概念，它描述的是这个交易具体是做什么的。
Corda的设计目标是对现实世界中各种交易类型进行支撑，因此要具有描述交易实际执行动作的能力，例如：转账、存入/提现、开票/兑付，诸如此类，所以要引入command这一概念。当然，这些交易动作只需要交易参与方事先约定就可以了，他们可以约定什么值表示什么含义，因此指令本身的具体值并不重要。Corda交易指令设计的关键要点是，指令必须包括有权作出这个指令的全部参与方的公钥用于后续的签名验证，并且允许交易的合约代码对此进行检查。比如说，资金转账的指令必须是某个银行才能执行，而开具一张承兑汇票的指令则可能需要开票方、承兑方都签署才能生效，这样一来接收这张汇票的一方，就可以通过事先编写的合约代码来实现这一检查。
有了指令机制，交易的合法性验证过程也更加清晰了：一个交易的全部指令所列出的所有参与方，就是一个交易需要签名的所有参与方。这是个充分必要条件，很好地解决了一个问题：交易到底需要验证哪些签名才被认为是有效的。同时值得提出的是，Corda的合约验证流程实现了合约与哈希算法之间的解耦——合约代码只需要判断事先约定的参与方的公钥是否都包含在此次交易的command当中，而对交易的全部签名的有效性（是否与这些公钥匹配）进行验证的工作留给Corda系统来做。这是Corda设计的一个特色，可以简化合约代码的开发和部署/升级工作，例如：一个合约对应的多次交易过程中系统的加密算法进行了升级，智能合约的代码是不需要改变的，这一点相对于比特币而言有一定优势。
除了command这一关键概念之外，Corda系统中交易还有很多特性，这里列出几个与Corda设计目标相匹配特点：
为了适应多方复杂交易的机制，Corda引入了联合公钥（Composite keys）的概念，系统中所说的需要keys的地方，都是指一个Composite key的结构。联合公钥是一个树状结构，叶节点表示来自一个参与方的一个公钥，而上层节点代表联合权重，用于表示必须有满足权重值条件的参与方签名才能认为该节点有效。例如：一个上层节点的权重为3，则意味着其下面节点必须有3个有效签名，这个节点才算有效。反过来说，一个权重为3的节点下面有5个参与方的公钥，也只需要3个签名有效，这个节点就有效。通过层层判断，到根节点形成一个组合条件，最终判断全部签名的总体有效性。联合公钥的概念如图1所示。
Corda的交易具有“半匿名”的能力，每一个状态都有他所属的参与方信息（party），这个信息包含两个“字段”：公钥和标识。只有公钥字段是任何时刻都必须有值的，一个新交易创建或者从磁盘上反序列化到内存中的时候，可以根据交易的参与方当前提供的身份来填充标识字段，这样就实现了交易参与者根据自身需要（和可接受的程度）来决定每一笔交易是实名的还是匿名的。另外，交易发送给Notary等节点进行签名时，也不需要传输标识字段，这样一来，即使一个交易本身是实名的，从全网的角度看仍然可以做到半匿名。
另外需要提及的一点，Corda中交易的类型有两种：普通交易和Notary变更交易。由于Notary概念还没有介绍，这里就不详细展开了，只要说明一件事：这两种交易类型的区别主要在验证流程，输入输出类型都是一样的，因而Corda的交易概念定义是唯一的。
合约（Contract）
合约就是交易双方事先达成的契约。从合约的角度看，交易其实就是它的一次执行过程，因此合约对交易有约束性，并且一个合约可以多次执行，也就是多个交易可以对应一个合约。
Corda的合约也就是我们常说的“智能合约”，本质上是一段代码，在JVM的体系中，就是一个类。合约都需要实现Contract这个Interface，这个接口有一个函数和一个属性：方法是verify，用于验证交易的合法性。这个函数接收TransactionForContract类型的参数，其中的关键点在于这个类型的构造函数的参数都是不可变参数类型，因此保证了Corda的合约都是“纯函数”——只能对交易起到验证作用，无法对被验证的交易产生任何副作用。
Contract的唯一属性：legalContractReference，是一个SecureHash类型的数据，用来存储现实世界中真实合约的标识。我们很容易想到：可以用这个值来存储合约文件实际内容的哈希值，用来保证对应合约内容的唯一性，很明显这是Corda系统与真实世界建立关系的一个连接点。
通过这样的结构，contract实现了它应该具有的两个能力：描述现实世界的合约，并且对根据这个合约进行的任何交易进行验证。从技术实现上来看，Corda的合约就是一个Java的class文件，可以被JVM执行，从而开发者可以使用JVM上的各种语言进行开发，合约代码中原则上也可以调用很多JVM上已有的类库、代码，这也是Corda的一大优势。在交易执行过程中，这个class文件必须作为交易的附件，是交易的输入条件之一，被系统加载并执行其verify函数。
这里需要再次强调的一点是：Corda的智能合约是“纯函数”，这一点和比特币类似，总体上就是说智能合约无法改变系统/交易的状态，即使无数次执行智能合约的代码，最终产生的结果都是一样的，系统状态也没有任何改变。
Oracle
Corda的设计理念之一就是要和现实世界发生联系，这种联系的能力前面已经看到了很多，Oracle则是这个理念的另一重要体现，这也是为什么笔者认为应该将其放在基本概念的范围来讲。股票价格、外汇牌价、银行利率，甚至一些非标准的信息（比如某家企业倒闭），都是“外部世界”发生的事实，而交易的过程和结果的验证，往往需要依赖这些信息。
Oracle（先知）就是这样一个角色——一个受信任的公共服务，用来将现实世界中的事实“注入”到Corda网络中，使之可以成为交易的一个输入项。具体实现方面，Corda将Oracle的行为模式设计成为对每一个交易进行事实的注入，而不是对整个系统进行注入。这样的设计有两方面的合理性，一方面是作为去中心化的数据库，恐怕也没有一个地方来登记所谓全局的信息了；另一方面从经济的角度讲，如果信息是全局的，一旦某个参与方获得了，就可以和其他人共享，Oracle就只有在发布信息的那个时刻才能获得报酬，经济利益方面没有保障将使得没有人愿意去承担这样的角色。因此，Oracle在每个交易中签署相应的内容，也成为Corda系统考虑现实世界经济活动特点的另一体现。
Oracle对整个交易进行签名的实现还带来了Corda当中另一个有普遍意义的概念：transaction tear-off，意思是说要把交易发给一个角色时，可以把不需要他知道的具体数据从发送的内容中删除，却仍然不影响他对整个交易签名。有了这个机制，就可以实现交易的隐私保护。那么，没有交易的全部数据，怎么实现对整个交易进行签名呢？为此，Corda将交易的签名结构做成一棵Merkle Tree，从而可以实现将一个保留了必要签名的分支发送给Oracle，使他仍然能按照签名结构完成对整个交易的签名。很显然，这基本上借鉴了比特币交易的签名实现机制，唯一不同的是，比特币用这种机制来节约磁盘空间的占用，而Corda用他来实现交易的隐私保护。
交易流程
交易流（Flow）
交易流（flow）是Corda系统的重要概念也是特色之一，简单说flow就是复杂交易的具体实现协议：如同比特币核心系统本身支持的动作只有“花钱”一样，Corda最基本的交易能力也只是{输入、指令、输出}。这样一来，现实世界中所出现的涉及多方的、多环节的、有条件的交易等复杂处理流程，只需要通过简单交易的组合、包装来完成。
由于Corda的交易通讯都是点对点的，而非全网广播的，因此交易流程实现起来相对简单、直接：就像一个流程图，我们只要描述节点之间的连接、数据传输的方向，以及从一个节点向下一个节点流转的条件等等，就可以设计出交易流程了。把这个流程通过代码实现，并且交由Corda系统去运行，就成了一个个在系统中的flow，支撑着Corda系统的日常运转交易处理，这实际上就是Corda系统的Dapp，又称CorDapp。
Corda有大量的内置flow，基本覆盖了日常交易流程中所用到的功能和典型交易的过程，例如：获取交易数据、变更Notary、交易组中确认，还包括典型的两个参与方的交易（模板）等等，都在net.corda.flows中定义。由于支持子流程调用，因此新开发一个flow需要的实际代码量应该也很少。
一个有意思的事情特别强调一下，Corda的flow实现，使用到了一个“黑科技”——quasar。这是一个JVM系统上实现fiber/co-routine形态的纤程/轻线程的类库，同时也是一套实现了actor模型的类库，可以说是目前actor领域内除Akka之外唯一一个比较有影响力的实现。Corda系统中主要是使用到了quasar的纤程能力，通过quasar字节码级别的注入，实现了一个flow的执行流程可以随时被挂起和恢复，并且挂起是可以在持久化层面实现的，从而大幅度提高了系统的可伸缩性和可靠性。由于quasar目前只对Java和Kotlin提供完整支持，对Clojure提供部分支持，对Scala等其他JVM语言的支持还相当不完善（Scala由于有Akka，对于quasar是不是感兴趣也是问题）。因此笔者相信，quasar应该是Corda采用Kotlin开发的最主要原因。不过，这里要回到开头提出过的一个话题：quasar的选用，显然是Corda作为一个系统在高并发和高可靠性方面的解决方案，与“类区块链”这个领域并没有本质的关系，因此这应该是本文唯一一个脱离区块链概念讨论的议题，主要是因为这个黑科技的吸引力还是蛮大的。
Notary与共识机制
Notary是Corda网络交易验证和确认的核心机制，这个机制的采用本质上想要解决两方面问题：一是避免因为分布式共识机制而导致交易信息在全网广播，这主要是为了支撑交易信息“适度可见”的能力。另一个目的是将共识机制与交易流程分开，变成一种标准服务，从而可以采用不同形态的共识实现方式，而非绑定到某种特定算法上。
Notary
Notary是公证人的意思，从字面上就能看出来其作用：就是有一个独立的、交易双方（多方）都信任的角色，来最终确认这笔交易的有效性。根据前面描述的基本概念可以知道，交易的输入、执行动作以及输出三者关系的有效性是通过智能合约来判断和保证的，因此本质上需要Notary进行判断和保证的就只有交易输入的有效性——某项输入数据没有曾经或正在成为其他交易的输入，也就是保证没有发生“双花”。从这个角度讲，Notary就是比特币的共识机制——区块链——的替代物。本质上讲，能采用Notary机制来替代区块链模式的共识机制，还是Corda的定位所决定的：一个半信任的网络，参与方和节点的加入都是可以事先经过审核的，即使存在恶意攻击，其种类和形态也和比特币面临的情况完全不同。
事实上，基于Notary进行交易确认的方式，最早是InterLedger提出的——由于InterLedger的目标是跨账本的交易，一个“类区块链”账本系统内部的节点共识算法是无法应用在不同账本之间的，为此必须有账本间认可的（半）信任中介来承担交易确认的职责，Corda的技术白皮书中也确认其Notary的概念来自InterLedger。
Notary的具体实现机制比较简单，交易参与方将交易发送给Notary，发送过程也采用flow的机制实现。Notary接收到交易后，根据自己以往记录的所有交易的输入，查询这个交易的输入是否曾经出现在另一个交易的输入项当中。如果确认这个交易的输入项都没发生过“双花”，则可以签署交易，此时交易就达到了最终生效（finality）的状态，也就完成了。如果Notary判断交易无效（其实就是发生了“双花”），就会返回异常，交易也就终止了。从这里也可以看出，使用Notary来做交易确认，本质上是要把交易的所有输入项发给他——由于系统的状态都是不可变的，所以只发输入项就够了。这也就解释了前面所提到的，Corda网络中的状态具有一个Notary属性，这个Notary是当初产生这个状态的交易验证时所使用的Notary。同时，为了实现上述验证过程，Corda网络也要求一个交易的输入项必须指向同一个Notary，也就是这个交易要提交验证的Notary。如果有些状态不是指向这个Notary，则首先要对这些状态执行Notary变更交易来实现转移。
此外，所谓单一的Notary服务，完全可以是一个网络，其中有多个Notary节点，但是他们依赖同一个数据库来存储信息，或者依赖一个能保证一致性的分布式数据。换句话说，只有各自独立运作，并不依赖一套数据存储的Notary，才能被认为是不同的Notary服务。上面提到的状态在Notary之间转移，指的是真正各自独立Notary之间的关系。
共识机制
提到Corda网络的共识机制可能会有些奇怪，前面刚刚提到Notary从某种意义上说就是“信任中介”，是比特币的区块链模式共识机制的替代物，防止双花由它来保证，Corda网络怎么还会有共识机制呢？
我们首先看看InterLedgr提出的Notary相关的共识机制：由于多个账本的一连串交易应该会有多个中介，因此中介间也要达成共识，并且由于网络复杂性和没有统一的信任机制，这种共识算法也要能够防止拜占庭失效/攻击。
笔者通过对InterLedger描述的共识机制和Corda当中的相关描述，发现一个问题：基于Notary的网络，其“共识概念”存在着歧义：
- 某个Notary服务本身作为一个分布式系统，节点之间受到网络的影响，可能存在拜占庭失效，这是一个技术问题。各个节点之间需要达到状态同步或者数据一致，需要一个BFT的算法，有时候也称为共识机制。
- 多个真正相互独立的Notary，如果要共同参与某个交易，由于各自的信息掌握并不完整，如何来达成共识即这个交易没有发生“双花”？本质上这又回到了信息的全局可见性问题。
原则上来说，比特币层面的共识机制指的是后者，通过“信息全局可见+PoW+区块链”的方式实现了共识。目前无论是InterLedger还是Corda，所讨论的共识机制都是前者，这是一个很明显的歧义。网上有个精彩评论从另一个角度谈到了这一点：Corda网络的Notary可以有很多实现，其中比特币就可以作为Notary的实现——一个全球唯一的、相对低速的Notary；反过来也可以说，区块链就是比特币网络的全局唯一Notary。
由此可见，在Corda网络中，Notary机制的有效性是严格限定在其覆盖范围内的，更大范围的交易验证，必须依赖于一个更广范围的Notary的建立，或者多个原本无关的Notary的协同作业。而这一点，目前在Corda网络中没有给出参考实现或者实现方面的指导意见，因此Corda网络中Notary的使用、迁移和共识机制在实现层面仍有未解决/论述的问题。
网络结构简述
正如开头提到过的，Corda的实现与运行体系带有鲜明的Java生态环境的特点——最典型的就是一些（相对成熟的）开源框架与组件的组合。具体体现为：Corda网络通讯基于activemq的一个子项目artemis；节点的存储则直接支持通过JPA将交易等数据结构存储到数据库中；节点的管理直接自带了一个Web应用。这些特性使得Corda在企业中的运用变得相对简单，是Corda的主要优势之一。
网络通讯
P2P网络的节点功能当中，通讯机制是很重要的组成部分，准确地说主要包括两部分，一个是通讯本身的功能，如通讯协议、消息结构、序列化等；另一部分可以称为P2P协议，涉及节点发现、加入与退出，离线时的机制等。
首先说网络通讯本身，Corda的通讯协议基于AMQP/1.0，采用TLS作为加密协议。Corda目前的（参考）实现简单而清晰——内嵌了Artemis，这是Apache ActiveMQ的一个子项目，是一个支持AMQP/1.0（也支持JMS）的全功能的消息中间件，并且适合于嵌入式应用。通过这个手段，通讯本身的功能都得到了覆盖，既包括基本的网络通讯协议的支持（Artemis的通讯功能基于Netty）、消息格式解析，又包括消息持久化（提升可靠性）、队列管理（简化内部消息处理流程）等高级特性。从这个实现就可以看出基于Java生态环境的解决方案带来的好处：能够在短时间内解决重要的基础设施需求。
说到P2P协议部分，Corda采用了很简单的NetworkMapCache服务的概念，字面上理解起来比较容易，就是每个节点包含一个整个网络Map的缓存。这个缓存自然是分布式维护的，网络变动会通知到各个节点，更新Map，每个节点也都对外提供发现、注册等服务，并且要求一定的身份验证。具体到实现模式，文档中并没有详细说明，从代码当中也看不到对于某一种P2P网络库的引用和自动发现功能的实现。同时，代码注释中提到，未来希望采用Raft/Paxos模式的选举方式实现网络初始Map的产生，因此目前的Corda应该在启动阶段采用简单的初始/种子节点的方式，这也是正常的模式。
总体而言，Corda的网络通讯层面的功能，还是直接利用了现有Java生态环境中的成熟组件，实现了较为快速的开发，同时拥有了完备的基本能力。
数据存储
Corda数据存储方面的架构可真是Java程序员的福音——支持通过ORM的方式，将交易数据存储到标准（关系型）数据库中，并且是通过标准JPA接口。具体实现方面，Corda节点内置一个H2数据库，同时允许通过配置JDBC连接到任何标准数据库上。
从底层架构的角度看，Corda基本就是为了方便企业应用，完全开放了底层数据结构。一个金融机构完全可以通过把Corda的数据和自身业务数据放在一个数据库里的方式，实现数据层面的直接打通——通过SQL JOIN的方式对两部分数据进行统一查询。Corda的技术白皮书中对这种数据整合方式也是完全支持和鼓励的，明显是作为系统设计的一个目标，这与Corda的总体目标确实是一致的，也说明Corda的设计者们对于企业在采纳一个新的系统时所关注的应用整合场景非常了解。
例如：Corda当中的“钱包”称为Vault（保险箱），就是存储了所有交易的实际资产信息的地方。如上所述，保险箱作为节点的一部分，也是完全基于这个JPA机制实现数据存储的。这样做的好处就是上面所说的，企业完全可以在数据层面将内部信息系统与Corda的保险箱打通，通过各种成熟的SQL查询模式，来实现应用整合，提升整个业务流程的开发效率，降低数据转移、核对等成本。当然，笔者建议这样做的时候一定要注意安全性、可靠性，否则一旦出现破坏Corda节点的数据库，恢复难度肯定比一般数据库要大得多。
节点管理
Corda的节点自带一个Node Explorer，这是一个Web应用，主要完成两类功能：
节点管理，包括查看当前节点状态的dashboard，能够查看与配置节点的基本参数，以及可以浏览全局网络的基本状况等。
应用管理，包括查看当前交易的记录，尤其是包含了现金这种内置交易的部分功能，能够查看所有现金交易的情况，以及真正发起一个最基本的现金交易，如图所示。
由此可见，Corda的节点内置了很多应用层面的功能，既方便使用者开箱即用，又可以作为应用开发的例子，供使用者进行学习和在此基础上扩充。笔者认为这也是Java生态环境的优势之一，毕竟底层系统也运行在JVM上，使得上层应用的开发和部署成本都有所降低。
网络节点小结
综合上面三个主要特性，基本上可以认为一个Corda节点就是一个标准的Java企业应用，存储、通讯、管理三个核心维度都是满足企业对于一个典型的Java应用的期待。对于金融机构、企业而言，采用Corda实现业务目标的阻力相对而言要小得多，使用过程中与自身的业务整合可以说毫无压力，从这个角度讲Corda的节点设计是完全能够支撑其市场目标的。
应用开发 —— CorDapp
去中心化应用（decentralized app，缩写为Dapp）的概念，应该是以太坊最早提出的。Corda特意将系统的应用写成“CorDapp”，可见是在呼应这个概念。很显然，CorDapp作为运行在去中心化数据库上的应用，当然可以称得上去中心化应用。
CorDapp是一个plugin形态的应用，通过实现CordaPluginRegistry抽象类，给出自己调用的flow（显然这是安全机制的考虑）、对外提供的API（rest形态）、标准Web接口等，最终形成一个jar，运行在corda的节点上。前面在讲flow的时候已经提到过，本质上corda的应用才对应着以太坊和HyperLedger的“智能合约”，从运行机制上看，大家本质上也都是plugin形态，并没有太大差别。
Corda为应用开发提供了一个模板：cordapp-template，这是一个独立的工程，可以用来作为开发一个新App的样板。如果要了解更多的App功能，还是应该自己去运行并学习corda工程中的samples里面所带的例子。尤其是用IDEA去开发corda时，各个例子可以直接在IDE中快速启动，便于开发者快速了解一下corda应用的运行结果。
由于Corda的文档也一再强调应用开发层面的机制还在快速变化当中，因此本文仅就其基本的插件模型作出上述介绍，其他详细内容读者可以在开发过程中跟踪最新的代码和手册。
总结
应有一席之地
结合上述对比、背景介绍和本文所述的内容，笔者认为可以得出一些结论。首先，Corda的根本目标是一个“去中心化数据库”，这既是他与其他区块链/类区块链系统最直接的关系，又是与所有“真正的”区块链系统最大的区别。其次，Corda的设计与实现，是在参考了成熟的区块链系统的一些标准概念和做法的同时，结合自身的目标定位做出了相应的取舍、改进和创新。第三，Corda所实现的新型的去中心化数据库，基本达到了其所宣称的三个主要目标：
- 信息适度可见
- 较高的系统性能
- 与现实世界的连接
除此之外，Corda对于在企业内的开发、部署和管理考虑的比较周全，因此我们相信其足以成为类区块链系统在企业应用领域占有一席之地的基础平台。
理想很丰满，现实很骨感
客观地说，Corda也存在一些问题，主要有两个方面：
第一是过度考虑现实世界需求的倾向——Corda当中模拟现实世界多重角色、体系结构中各种与现实世界的接口，有时候甚至让人产生一种“根据很多客户提出需求进行设计”的感觉。这种设计理念往往是“成也萧何，败也萧何”，可能会因为外部环境的变化而失去生命力，开发过程中也容易纠结于无法统一各种复杂情况而陷入停滞，优劣参半。
另一方面的问题是：相对于其宏伟的蓝图，Corda很多具体实现的细节层面还略显初级——“理想很丰满，现实很骨感”。当然，我们了解，除了以太坊之外，其他的类区块链系统的实现也都还处于非常初级的阶段，并不一定比Corda更完善。但是，由于Corda在去中心化数据库的核心理念——共识机制方面的“创新”，使得其这方面的实现必然更加为人们所关注。遗憾的是，笔者认为这方面的设计和实现，Corda还都有未解决的问题，不得不说在创新之路上任重而道远。
最后，笔者认为，一个好的类区块链/去中心化数据库系统，应该适度设计，具有一定的简单性：最主要的是将P2P网络、交易签名验证、拜占庭容错与补偿等核心机制进行整合，形成一个边界清晰的系统。在此基础上，如果特别关心性能、信息适度可见等特性，则可以引入Corda或者其他系统在这方面的设计理念进行扩充。重要的是，将上述特性在系统内部给出完善的实现（如果允许可插拔的实现机制，要有精确的接口和操作流程定义），并对外提供简单清晰的API。通过这样的方式，将可以构建出新一代面向价值转移的互联网基础设施，将分布式计算的能力发挥到一个新的层次。
原文发布时间为：2017年09月01日
本文作者：区块链大本营
本文来源：CSDN区块链大本营，如需转载请联系原作者。
