如何利用区块链开发落地项目？实战达人一步步教你

区块链是目前比较流行的一个新概念，它包含了科技和金融两个概念。 本文以联盟链为例，简单介绍一下实践联盟链的基本流程。

作者|微友区块链CTO陈浩

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

公证区块链是指仅限于某些关键数据的自我证明、公开、防篡改等功能的区块链。 它通常是价值型区块链中的附加功能，也可以单独扩展用于宣传等。 基于价值的区块链是指可以转移资产所有权的记账簿。

如果确定是基于价值的区块链，我们需要确定目标区块链的整体定位：是通用价值传输区块链，还是特定场景下的区块链？ 如果是特定场景下的区块链，我们通常会推荐Hyperledger作为技术原型。 如果是更通用的价值区块链，我们推荐以太坊的思路 。

业务场景搭建及初步分析

首先要明确的是，区块链不是万能的。 很多场景其实不用区块链技术就可以解决。 像跨境支付领域，区块链之所以能发挥好，是因为有很多点对点的跨境机构，有大量的支付清算需求，不想中介机构参与。 区块链是一个不错的选择。 但在一些集团和大公司内部，区块链解决方案基本上远不如传统的企业资源解决方案。

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 也会收到反馈。

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

对于案例 1，敏感和隐私数据不会公开，即使加密也不允许上传到区块链。 因此，产生了一个数据输入输出到区块链的过程，这个过程是区块链不可控的。

那么是否可以用传统技术来控制它呢？ 它似乎也不起作用。 能够满足不暴露敏感数据的方案只有HASH计算和同态加密。 但是这两者都需要将数据传输到指定位置。

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

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

业务场景建模

对于第二节中的两种情况，我们接下来进行建模。 抛开核心痛点，我们一定还有记账的需求。 本质上，每个节点在任何情况下都是服务器和客户端。 那么你用多少来衡量你的贡献和需求呢？

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

发展历程

A. 区块链原型选择

根据本文开头的描述，如果是针对特定场景的区块链解决方案，推荐Hyperledger fabric。 当然，也可以建立私有的以太坊链。 以下是以太坊和 Fabric 之间的一些比较：

Ethereum 和 HyperLedger 的相同点：

它们都是提供区块链业务实现的平台，业务实现通过智能合约完成，实现最大的灵活性，底层无需修改。

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

HyperLedger是：Shim链码容器，使用GO编写合约。

正式版都是用GO语言实现的。

因为都提供了第三方可编程的能力以太坊有哪些落地应用，由于难度大，内部漏洞在所难免。 对外，存在恶意程序攻击的威胁。 尤其是公链的时候，威胁就更大了。 上个月，以太坊报告了一个合约 solidity 语言漏洞。

以太坊和 HyperLedger 的区别：

以太坊只提供智能合约功能。 也与其定位不谋而合：智能合约和去中心化应用平台。 没有对系统安全或访问机制的底层或核心支持。 HyperLedger在吸取以太坊智能合约特性的同时，提供了MemberShip、身份验证角色管理等模块，更贴近商业应用场景。

共识机制不同。 由于共识的不同，每秒可以处理的交易量也不同。 以太坊每秒可以处理数千笔交易，而 HyperLedger 可以达到 10 万笔交易。

采用的技术实现思路不同。 以太坊更多的是自己实现，自己造轮子，有点像开发者炫技，比如自己提供合约语言solidity，自己实现EVM（这可能是实际需要）。

表1是笔者一个私有链项目中两者的对比（私有链考虑了Hydrachain的可行性）。

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

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

事实上，智能合约在某些场景下并不是强制性的。 对于用户来说，可靠性、便捷性、实时性是第一要求。 对于具体的应用场景，将“合约”固化在区块链中也是一个可行的思路。

关于以上两条联盟链的实现，笔者还想强调的是，并不是所有的服务都必须基于区块链。 作者设想了一个通用的伞形结构，比如比特币的侧链技术。 主链提供基础账本服务。 侧链提供特定场景服务，侧链上的应用可以脱离区块链实现，只需要注册接口即可。

B.交互界面设计

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

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

C. 基本账本设计

基本账本设计包括以下两个问题：

首先是原型区块链是否已经满足需求？ 对于以太坊来说，基本不用改动基础账本，只需要构建智能合约即可。 如果是基于比特币系统，可能会有较大的变化。

不满足要求如何变更基础账本？ 这实际上取决于帐户模型。 如果使用UTXO模型，变化的关键点是如何嵌入模板交易主体。 如果你使用Balance模式，那么就没有这个问题。

D. 业务扩展层设计

业务扩展设计的内容比较复杂，篇幅问题这里只是提出两个问题：

1. 扩展层是接入区块链还是内置于区块链？

2. 如果包含数据录入，是否需要屏蔽？ 脱敏后如何上链？

先思考这两个问题，或许可以帮助大家更好的规划业务拓展层的内容。

发展转型与困难

一、发展思路的转变

与传统的网络服务不同，区块链的发展不再是面向服务的，而是面向账本和交易的。

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

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

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

B、发展困难

目前，区块链项目的开发存在三个难点：

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

目前比较成熟的技术体系有比特币及衍生技术体系、以太坊、HyperLedger fabric、Bitshares、Ripple和NXT。 其中，前三个是最具影响力的区块链项目。 比特币及其衍生技术大多采用C++语言开发； 以太坊支持大部分主流语言，官方是Go，还有其他分支项目比如Rust语言的Parity wallet； Hyperledger 目前基于 Go。

从目前上海的区块链从业人员来看，保守估计在400-500人左右。 按一半是开发人员算，只有200多人，在庞大的市场需求面前，人才极为稀缺。

由于目前C++在金融和游戏领域只有部分需求以太坊有哪些落地应用，所以C++工程师并不多，尤其是高水平的C++工程师就更少了。 Go作为一门新兴语言，发展势头强劲，但Go的生态没有Java大。

从Java的角度，如何利用它的生态，目前的区块链还没有到那个地步。

整体而言，区块链技术与其他技术的结合还有待探索。

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

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

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

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

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