区块链是目前比较热的新概念，包含技术和金融两个概念。本文以联盟链为例，简述了实践联盟链的基本过程。

作者|陈豪，魏攸区块链CTO

首先要确定这个区块链的类型，是公证的区块链还是价值的？

公证区块链是指仅限于一些关键数据自认证、公开、防篡改等功能的区块链。它通常是一个附属于值区块链的函数，也可以独立扩展用于宣传和披露。价值区块链是指可以转移资产所有权的账簿。

如果是价值区块链，我们需要确定目标区块链的整体定位：是普世价值传递区块链还是特定场景下的区块链？如果是特定场景下的区块链，我们通常推荐超级账本作为技术原型。如果这是一个更普遍的价值区块链，我们建议以太坊的想法。

业务场景的构建和初步分析

首先，应该明确的是，区块链不是万能的。许多场景实际上可以在没有区块链技术的情况下解决。像跨境支付领域，区块链能玩好，是因为有很多点对点的跨境机构有大量的支付结算需求，他们不希望中介机构参与进来。区块链是个不错的选择。然而，在一些集团和大公司内部，区块链解决方案基本上远远不如传统的企业资源解决方案。

A.需求痛点分析

一般需求难点当满足以下条件时，您可以考虑使用区块链：

有互不信任的P2P网络环境；

节点是平等的，没有绝对的仲裁者。

节点之间存在博弈行为。

P2P网络可能包含输入和输出，当它包含输入和输出时，区块链不再是封闭的。

通常，节点有以下行为(包括但不限于):

不信任其他节点；

保证自己的收益最大化；

变得自私但不贡献资源。

对于上述场景的业务建模，需要根据具体的业务逻辑和博弈论推导出符合自己需求的方案。

B.非区块链技术可以解决吗？

案例1:

通常我们有不同的机构A、B、C，存在不对称的信息交换需求，即A、B、C分别拥有部分数据，但它们的组合拥有全部的市场数据。但作为A，我想知道B和C在自己的数据集中是否有一些点的数据，并根据这个结果调整购买策略。

案例二：

有不同的机构X，Y，Z，需要信息反馈。Z在接受Y的服务时，会给Y一个信息反馈，可能是信用评价，也可能只是回复反馈。简而言之，这种反馈是需要记录的，X会根据Z的信息反馈结果来调整自己的购买策略，当X购买服务时，也会给Y一个反馈，Z也会收到反馈。

以上两种情况首先考虑使用非区块链是否可以解决：

对于第一种情况，敏感数据和私有数据不会公开，即使加密，也不允许上传到区块链。因此，产生了数据输入和输出区块链的过程，这是区块链无法控制的。

那么用传统技术能控制吗？好像也不行。能够满足不暴露敏感数据的要求的唯一解决方案是散列计算和同态加密。但是两者都需要将数据传输到指定的位置。

我们通常考虑使用零知识证明作为解决方案，然而，具体的算法可能需要根据具体的业务逻辑构建，结合简单的智能契约，根据查询结果产生不同的输出。

对于情况2，反馈信息容易被篡改，刷单问题最大。如何保证这个信息反馈是客观的、中立的、不可更改的？你可以结合区块链代币的币龄，使交易具有方向性，防止作弊。

业务场景建模

对于第二部分中的两种情况，我们接下来将对它们进行建模。除了核心痛点，肯定还是有记账的需求。本质上，任何情况下的每个节点既是服务提供商，也是客户。那么如何衡量自己的贡献和索取有多少呢？

所以，在任何一个区块链平台上，都要有代币系统，否则记账会非常困难。在业务场景建模的过程中，我们主要关注如何实现节点之间的帕累托改进，而不是因为每个节点都是自私的，就让区块链服务名存实亡。

发展道路

一、区块链原型的选择

根据本文开头的叙述，如果Hyperledger fabric是针对特定场景的区块链解决方案，则推荐使用它。当然也可以建以太坊私链。以下是以太坊和布料的一些对比：

以太坊和HyperLedger一样：

它们都是提供区块链业务实现的平台，业务实现通过智能合约来完成，以实现最大的灵活性，并且不对底层进行修改。

以太坊是：EVM虚拟机，Solidity契约语言；

HyperLedger是一个： Shim链代码容器，契约用GO编写。

官方版本都是用GO语言实现的。

因为都提供第三方可编程性，因为难度大，所以内部难免有漏洞。存在恶意程序攻击的威胁。尤其是作为公链，威胁会更大。上个月，以太坊报告了合约可靠性语言漏洞。

以太坊和超账本的区别：

以太坊只提供智能合约能力。也与其定位不谋而合：智能合约，去中心化应用平台。没有对系统安全或访问机制的无内核支持。HyperLedger在吸收以太坊智能合约特点的同时，还提供了会员、认证角色管理等模块，更贴近商业应用场景。

共识机制不同。由于共识不同，每秒的交易量也不同。以太坊是每秒千级交易量，而HyperLedger可以达到十万级交易量。

采用的技术，实现思路不同。以太坊更多的是自己实现，自己做轮子，有点开发者炫技的感觉。比如他们提供solidity，一种契约语言，自己实现EVM(这可能是实际需要)。

表1是作者的一个private chain项目中两者的对比(private chain考虑了Hydrachain的可行性)。

读者可以根据自己实际的TPS需求做出一致的选择。表2是一些不同共识的参考数据。

当然，如果考虑自研，建议搭建基础比特币网络，添加、更改共识算法、网络传输协议和附加合同(可选)。

实际上，智能合约在某些场景中并不是必要选项。对于用户来说，可靠、方便、实时是第一需求。对于特定的应用场景，在区块链中固化“契约”也是一种可行的思路。

鉴于以上两个联盟链的实现，作者还想强调一点，并不是所有的服务都必须是区块链。作者构思了一个通用的伞形结构，比如比特币的侧链技术。主链提供基础账本服务，侧链提供具体场景服务。侧链上的应用程序可以由非区块链实现，只需要注册接口。

交互界面设计

在交互界面的设计上，推荐目前业界普遍使用的Json-RPC接口，兼具扩展性和友好性。

一般我们把接口分为两类：开放接口和账户接口。开放接口是指区块链本身的描述信息，不需要认证，账户接口需要账户认证。

c、基础账簿设计

基本分类帐设计包括以下两个问题：

首先，原型区块链满足需求了吗？对于以太坊来说，基本不需要改变基础账本，只需要建立一个智能合约就可以了。如果是基于比特币系统，可能会有重大改变。

需求未满足时，如何更改基本账簿？其实这个要看账户模式。如果使用UTXO模式，变化的关键点是如何嵌入模板事务体。如果使用平衡模式，那么就不存在这个问题。

d、业务扩展层设计

业务内容

1.扩展层是在区块链的外部还是内置于其中？

2.如果包括数据输入，是否需要脱敏？脱敏后如何收场？

先思考这两个问题，可能有助于你更好地规划业务扩展层的内容。

发展变化和困难

一、发展思路的转变

与传统的网络服务不同，区块链的发展不再侧重于服务，而是侧重于书籍和交易。

开发者面对的不再是以高可用性和高并发性为主要指标的应用，而是转向了面向用户、用户友好、开发可扩展的终端程序开发。

因此，高并发、高性能不再是区块链终端的核心指标，安全性、可扩展性、友好性成为主要指标。

图2是适用于联盟链/私有链项目的工作流程。

b、发展困难

目前，区块链项目发展面临三大困难：

1.人力资源储备开发不足

目前比较成熟的技术系统有比特币及衍生技术系统、以太坊、HyperLedger fabric、Bitshares、Ripple、NXT等。前三个是最有影响力的区块链项目。而比特币衍生品大多是用C语言开发的；以太坊支持大部分主流语言，官方的是Go，还有Rust语言的平价钱包等其他分支项目；目前超级账本以围棋为主。

目前，从在沪的区块链从业者来看，保守估计在400~500人左右。一半是开发者，只有200多。面对巨大的市场需求，人才极度匮乏。

目前因为C只在金融和游戏领域有部分需求，所以C工程师特别是高水平的C工程师并不多。作为一门新兴语言，Go发展很快，但生态没有Java大。

从爪哇的角度来看，如何对它进行生态利用，区块链目前还没有达到那个地步。

总的来说，区块链技术与其他技术的结合还有待探索。

2.区块链是一门交叉学科，需要工程实践各方面的经验。

在实践中，我们希望区块链的从业者既懂技术又懂金融。这就要求人员素质更高，相应的符合标准的人就更少。

3.关于区块链各技术体系的理解偏差。区块链技术和理念日新月异，闭门开发可能会走进死胡同。如何在保证开发进度的同时，保留一部分精力来更新知识体系，对开发者来说是一个极大的挑战。

区块链作为新兴技术，涵盖去中心化、去信任、共享经济、分布式计算、分布式存储等多个方面，考验技术人员的学习和思维能力。未来，区块链和人工智能一起，将影响普通人生活的方方面面。

作者：陈豪，魏攸区块链CTO，曾任埃森哲高级软件工程师，擅长C /Python语言，有多年清算支付系统开发经验。万向区块链实验室曾获得2016年上海区块链黑客马拉松大赛第三名，是开源项目Libbitcoin开发团队成员。