六大分布式账本技术体系评估报告（比特币、Ripple、比特股、以太坊、HyperLedger 和 Corda）

为满足区块链研究业务需求，我们对目前世界上有影响的六大分布式账本技术体系（比特币、Ripple、比特股、以太坊、HyperLedger 和 Corda）进行了深入的考察和评估。其中前四个技术体系是平台、货币、社区三位一体的，后两个技术平台是“纯平台的”。 考察评估的维度涉及领域适用性、场景适用性、计算能力完备性、架构分层合理性、共识达成机制与效率、计算与存储的效率、隐私与特权机制、原生货币的作用和必要性、技术与运营支持、未来发展潜力与动向十个方面。

领域适用性

比特币账本底层数据结构拥有的唯一一个价值字段用于描述比特币价值创造和转移的面额。换句话说，比特币技术体系如要移作他用，也只能提供单一标的资产的登记和转移。如要同时支持多种标的资产共处和交易，还需进行相应的改造。 以太坊、比特股、Ripple、HyperLedger 技术体系都能够同时提供多种标的资产（含数字货币）的登记和转移服务，天然支持数字货币和数字资产在一个区块链上共处，这对于构建具有资产交易业务逻辑的资产端应用来说是更加方便的。此外，除原生货币之外，由外部注入的数字货币（比如代币等）在技术处理上与普通的数字资产无异。外部注入的货币与原生货币之间的汇兑，其技术实现方式也与资产交易类同。 在非金融端，各技术体系一般都在底层数据结构中提供一个文本类型的信息字段，可供信息提供方签名分发，作为“经签发方确认的消息”，间接提供非金融领域的信用服务。在以太坊和 HyperLedger 技术体系中，经签发方确认的消息还可触发智能合约执行相应的动作。

场景适用性

根据分布式总账的技术特点，一个应用场景的参与方，既是业务的参与主体，同时又是其分布式总账本身的运营和见证主体。一般根据参与方加入应用场景是否需要获得许可，把场景分为“非许可的”和“许可的”两类。在区块链社区中也把“非许可的”场景称为“公有链”，把“许可的”场景细分为“私有链”和“联盟链”。私有链是单边治理的业务生态，联盟链是多边共同治理的业务生态，公有链是整个社区共同治理的业务生态。

比特币、以太坊、比特股、Ripple 都通过自身社区共治共享的公有链体现了其技术体系对公有链场景的适用性，鉴于公有链社区人员组成的复杂性和博弈的高度对抗性，能够在公有链环境下生存下来的分布式总账技术平台，在安全上是经得起考验的，不加改造或略加改造作为联盟链或私有链部署也具有可行性。

HyperLedger 目前的设计是以联盟链为出发点，但是其白皮书强调每个模块 （包括身份认证和共识算法以及数据库协议等模块）的可插拔性，兼顾了今后作为公有链的可能性。Corda 目前已公布的资料较少，但也可以从中清晰看到其非公有链的取向。

计算能力完备性

价值可编程是分布式总账技术的一个重要的本质属性，直接决定平台对业务逻辑的表达能力，具体体现在“智能合约”上面。比特币的内置脚本表达能力是 极为有限的。Ripple 目前不支持智能合约。Bitshares 的智能合约在运用上有很多限制，并不能自定义。以太坊和 HyperLedger 支持智能合约且达到“图灵完备”程度。

架构分层合理性

目前，业界对于分布式总账的基础协议栈结构并无统一共识，各技术体系做法不一。无论从快速构建应用角度来说，还是从与分布式账本之外的技术资源整合的角度，甚至从未来占领标准化制高点的角度来看，架构分层的合理性都是一个应该引起高度关注的议题，架构分层朝着更合理方向的每一次改进，既体现了业界对分布式账本技术架构理解的深化和运营理念的升华，也往往酝酿着新的商业机会。

我们期待的分布式账本技术体系的架构，应该体现三类不同性质的节点（记账端、验证端、客户端），五个不同的协议栈层次（网络通信、基础账本、共识、智能合约、应用），四个不同的管理要素（身份、策略、数据、过程）。 从长远来讲，有些共性技术（如 P2P 通信和执行智能合约的虚拟机环境）或许应该交给更合适的主体来做。

从现实情况看，六大体系中，Hyperledger 的架构分层显示出更多的包容性和更大的弹性，其各组成模块有灵活的可插拔性，便于支持各种法律和监管环境下分布式账本技术的落地，各模块间的相互关系也较为合理。该架构的优点值得我们吸取。

共识达成机制与效率

目前可供选择的共识达成机制有工作量证明机制、权益证明机制、委托授权的权益证明机制、Ripple 共识机制和实用拜占庭容错机制等。

工作量证明机制 (Proof of Work, POW)的优点是可以达到完全去中心化，节点自由进出。缺点是消耗大量的资源，共识达成的周期较长，不适合在资本市场的“主战场”应用。而且从统计角度上讲是需要 6 个或以上的确认才能认为是明确确认且不可逆。其网络容错的上限是 50%。典型应用是比特币和以太坊。

权益证明机制（Proof of Stake, POS）已有很多不同变种，但基本概念是产生区块的难度应该与对应节点在网络里所占的权益（所有权占比）成反比。POS 的优点是在很大程度上缩短了共识达成的时间。它的网络容错上限也是 50%。典型应用是点点币（Peercoin）和未来币（NXT）。以太坊计划在未来使用的 POS 算法叫 Casper，验证人数最多 250 人，并且区块一旦达到最终状态（final）就完全不可伪造。

委托授权的权益证明机制 (DPOS)。它其实是 POS 的变种，由全部节点记账变为选出代表节点记账。当使用去中心化自治公司 (Decentralized Autonomous Company, DAC) 这一说法时，每个股东按其持股比例拥有影响力。每个股东可以将其投票权授予一名代表。获票数最多的前 N 位代表成为验证者，并按既定时间表轮流产生区块。它的网络容错上限也同样为 50%。典型应用是比特股(Bitshares)。比特股需等待半数以上的验证者确认才认为区块不可逆。

瑞波共识机制(Ripple Consensus)。瑞波共识算法设定了一组特殊节点列表，只有在这个列表中的节点才是有效的验证者。这种机制达成共识的效率非常高，并且只有达成共识的区块才会写入账本。因此写入即有效，无需等待确认的时间。 为了达到高可靠性，只有 80%的验证者同意交易才算有效，即网络容错上限为20%。

实用拜占庭容错算法(Practical Byzantine Fault Tolerance)。这个算法可以在异步网络中不保证活跃度的情况下解决拜占庭将军问题. 虽然该方案不保证活跃度，但它进入无限循环的概率非常低, 在工程中是完全可用的。PBFT依靠法定多数(quorum)，每个节点一票，少数服从多数，实现了拜占庭容错。采用 PBFT 算法的网络容错上限为 33%。在私有链/联盟链的部署方式下，实用拜占庭容错算法（PBFT）具有较大潜力。

恒星共识协议(Stellar Consensus Protocol)与 PBFT 算法类似。它是基于联邦拜占庭协议(Federated Byzantine Agreement)改进而成，同样解决了拜占庭容错问题。 SCP 通过节点自行选择仲裁片区(quorum slice)来达成共识，增减节点非常灵活。 网络效率也很高，也采用只有达成共识才写账本的方法，因此也没有等待确认的时间。它的网络容错上限同样为 33%。其性能也可以作为 PBFT 的参考。

计算与存储效率

目前运行着平台+货币+社区三位一体的公有链上，我们所观察到的计算与存储效率受到很多因素的制约，而且计算与存储之间存在目标冲突，并非技术上完全不能实现更高的效率，所以参照意义并不是很大。 要实现分布式账本技术的大规模的应用，在计算与存储方面做进一步的性能优化是不可避免的。目前可选择的技术方案有：

一种方式是以定期保存的账本快照（snapshot）当做整个网络共同认可的状态。按照这种方式，全量历史记录有可能回退到云化甚至中心化存储，这在公有链上是相当于在安全性和去中心化上做出了一定的妥协。我们也可考虑以诸如 IPFS 等分布式文件存储方案来降低中心化存储的风险。

另一种方式是分片处理 (sharding). 这种方式主要出于解决计算性能问题的考虑，但是也兼顾了缓解存储问题的需要。总体思路是，每个节点只处理一部分（比如一部分账户发起的）交易，从而减轻节点的计算和存储负担。但是这种方式也会带来新的问题，如在复杂时序逻辑下数据的一致性、交易的原子性和交易的相互依赖对性能的影响等。

第三种方式名为状态旁路 (State Channels)。这种策略是保持底层的区块链协议不变，通过改变协议用法的方式来解决扩展性问题。在这种策略下，分布式账本上可见的只是粗粒度的“批发”，可以类比出入备付金操作，而真正细粒度的双边或有限多边交易明细，则不作为“交易”记录在分布式账本上，而仅仅作为有争议事件发生时备查的“信息”单据，通过状态旁路的方式“曲线”执行。比特币体系下的“闪电网络”是在比特币脚本逻辑表达能力受到限制的情况下不得不借助“精巧”的设计实现的事实上的状态旁路。在以太坊体系下，借助智能合约的丰富表达能力，状态旁路的实现大大简化了。 三种优化思路并不是彼此排斥的，可以组合使用。

隐私及特权机制

目前分布式账本上的交易数据（包括交易内容和发送方，接受方的地址）都是公开可见的，对于中国资本市场业务来说，这种数据的暴露往往不符合业务规则和监管要求。在分布式账本基础协议的框架内，寻找既能对交易内容背书、又不让非授权人员（哪怕是背书者）获取交易内容的技术方案是非常重要的。

目前从公开资料中能够查阅到的较为彻底的、既适合公有链又适合私有链和联盟链的密码学解决方案有零知识证明、环签名和同态加密三种技术可供选择，相应的技术实现虽已接近可用水平但与实际需要尚有差距。

作为临时性的解决方案，有人建议使用“状态旁路”。用状态旁路提供隐私服务，其前提是所有用户均按同样的脚本使用智能合约。如果有用户故意使用恶意的智能合约，就有可能把在正确的智能合约内存中解密的明文交易信息泄露出去。因此，状态旁路只适合于双边或有限多边的场景，不适合大量用户同时使用。 特权机制是一个全新的问题。以太坊公有链受到 The DAO 被攻击事件的影响至今仍在持续，类似事件如果出现在资本市场“主战场”上是不堪设想的。但评估过程中，我们没有发现所考察的技术体系在这一问题上有可供选择的解决思路。

原生数字货币的意义与必要性

目前几乎所有部署在公有链上的分布式账本技术体系里都有原生的加密货币。这些加密货币具有的共同特点都是没有中心化的发行方，可以在其对应部署的公有链上自由流转。这些原生货币的用途包括：支付手段、汇兑手段、抵押手段、激励手段、权益证明和资源控制等。

随着一套分布式总账技术体系从公有链平移到私有链/联盟链场景，前面所说的关于原生虚拟货币的很多用途会被消解，一部分功能会被锚定法币的代币所取代，因此在私有链/联盟链的建设过程中，“去币化”已成为一道标配的工序。但是，“权益证明”和“资源控制”这两个职能，即使到了私有链/联盟链场景，仍然有存在的必要性。原生数字货币或许仍不失为在私有链/联盟链场景下履行这两个职能的一种单纯的计量和调节工具。

开发与技术支持

据不完全统计，比特币的核心代码库、以太坊的 Go 语言核心代码库、Ripple 的核心代码库、比特股 2.0 的核心代码库等均已进行了多次升级，超级账本的项 Fabric 与 Sawtooth Lake 都各自进行过升级。应该说这些平台的核心代码都积累了大量的在线升级经验。

相比之下，智能合约是契约但更是程序，是程序就难免会有升级问题。如何处理智能合约的升级，如何保证智能合约的状态和逻辑在升级前后有序衔接，如何保证智能合约的升级和平台的升级相得益彰而不是互相掣肘，也是全世界面对的艰难挑战。 比特币、Ripple、比特股的核心代码主要由 C++编写。HyperLedger 的 Fabric 项目核心代码主要由 Go 编写。HyperLedger 的 Sawtooth Lake 项目核心代码主要 Python 编写。

以太坊的黄皮书是对以太坊的形式规范描述（formal specification），即用计算机科学的形式语言来描述的以太坊系统的规范。参照黄皮书的规范可以用各种 编程语言实现客户端。目前以太坊有经过大量安全审计的 Go 语言, C++语言和 Python 语言实现的 3 个客户端，另有 Java 和 Ruby 的客户端也在开发中。

除 Corda 之外，其他平台都是开源项目，项目文档比较丰富。但最近 Corda 发布了非技术白皮书，使业界对其理念和技术路线有了较多的了解。

未来发展潜力和动向

比特币技术体系正在新的升级计划引领下寻求新的突破。尽管其典型公有链、 单一标的资产以及 POW 共识机制等特质决定了在金融领域获得广泛应用有很大难度，但我们还是希望看到新的升级计划给比特币技术体系带来新的跨越。

Ethereum（以太坊）制订了清晰的进一步开发的路线图，具体涉及浏览器、共识机制、虚拟机和可扩展性方面的重大改进。此外，以太坊还在积极探索满足金融行业需求的各种技术路径，这些探索涉及隐私保护、吞吐量以及功能更强且更加可靠的智能合约等方面。

Ripple（瑞波）现阶段主要致力于与银行合作，解决汇兑类问题，而对更全面的应用于金融领域所必须考虑的隐私保护、可扩展性、合规性等问题尚未有明确的解决思路和研究计划。

Bitshares（比特股）没有形成长期、稳定的核心开发团队，其创始人 BM（Daniel Larimer）亦于 2016 年 4 月表示，他将逐步淡出比特股的开发。因此，比特股未 来的发展前景并不明朗。

Corda 和 HyperLedger 分别由两家联盟组织发起建设，联盟的成员机构主要来自金融领域和 IT 领域。它们将聚焦于分布式总账技术在金融行业的运用，重点放在私有链、联盟链上。从已披露的信息来看，两个联盟均提出了一些有创意的设想，后续能否以及如何实现这些设想是 Corda 和 HyperLedger 发展的关键。

HyperLedger 是一个支持智能合约的、底层可插拔的通用协议框架，其上项目多有很强的金融背景，包容性相对较强，又有很多金融领域传统服务商参与加盟，组件模块的不断丰富是毋庸置疑的。

Corda 对数据的隐私性、合规性和监管需求的考虑明显更接近金融业务主战场的视角，不排除会走一条与众不同、直达金融业务本质的道路。

---

区块链技术路线

针对中国资本市场的现实环境，我们优先考虑提供联盟链解决方案，在联盟链上忠实体现和反映中国资本市场职能机构的业务范围和职能边界。在运营模式的设计上，支持技术层面的专业化运营服务和业务层面的自主化运营服务既互相剥离，又有机结合。

.1 借鉴

分布式账本技术的核心就是对算法的充分信任，而在算法代码开源条件下，通过在广泛应用和反复博弈中取得公众信任，是对一个分布式账本技术体系强安 全性的最好诠释。因此从近期看，我们的分布式账本基础平台不可能凭空产生、从头做起，而必须首先选择合适的开源分布式账本技术体系作为主要借鉴，在其基础上搭建符合中国国情、适合中国法律与监管需要的基础平台。

从前面的业务需求分析中不难看出，高安全性、强表达力、多资产类别、良好的未来发展潜力和性能优化前景，去除原生数字货币副作用小，是中国资本市场对基础账本选择的基本要求。而在我们所考察的六大技术体系里，最有借鉴价值的，是以太坊和超级账本两个平台。

.2 改造

从前面的业务需求分析中不难看出，我们为适应中国资本市场要求而拟在后续对分布式账本基础平台的主要修改工作，核心是在中心化的“特权”机制的引入、“隐私”机制的实现、原生数字货币的去除和业务处理性能的优化。它们都几乎不约而同地集中在智能合约层面。我们判断，合约语言的未来趋势一定是跨平台，即使在同一平台下，合约模板也完全有可能对基础账本层的细微版本变化无感。因此，我们的目标是：在智能合约层提出一套“合约模板”，尽量把所有改动封装在“合约模板”中，这样就可以在某种抽象意义下同时既支持近期以借鉴为主的基础账本，又支持远期以自主开发为主的基础账本。

.3 自主研发

从长远战略考虑看，我们应在充分掌握底层账本核心技术的前提下，自主开发出一套基于BaaS的区块链技术体系。 架构的充分模块化和架构组件的充分可插拔是我们未来自主研发的分布式总账技术体系的设计所应遵循的基本架构准则。 

共识机制选择

根据选型分析的结论，PBFT所能达到的性能指标在各类共识机制中名列前茅。据我们了解，目前，在以太坊平台和超级账本平台上都有引入 PBFT 共识机制的尝试。我们内部也进行了在以太坊平台上引入 PBFT 共识机制的测试。应该说，引入 PBFT 已经不存在本质上的技术障碍。 但是也要看到，PBFT 不适于节点可动态加入的场景。针对这种情况，我们还将深入研究 PBFT 的替代方案。