处于风口浪尖的区块链技术正蓬勃发展，很多企业将目光投向了这一颠覆性的技术。然而区块链这一全新的领域和野蛮生长的生态圈，令很多雄心勃勃的采纳者无所适从。本话题将会从企业应用的视角出发，分享在企业应用中尝试区块链的实践，我们会考虑哪些因素，如何选择合适的区块链技术、进行去中心化应用的架构设计、优化区块链节点的部署，为充满雄心的区块链采纳者助力。

我想在座的各位多少应该都听说过区块链。正如之前的演讲嘉宾所言，区块链这几年非常火，2016 年被大家称为区块链元年。区块链的概念已经讲了太多，今天我们不再讲了。我们聊一聊，如果你想要在你的组织里引入区块链技术，你应该注意哪些事情。

在最近的一年多的时间以来，我们跟一些客户在区块链的项目上做了一些共同的探索，跟社区也有一些交流。我们觉得在一个企业里面，你做区块链的时候必须考虑下面这几个因素。

第一点，现在在市场上有这么多区块链技术可以选择，我可能只是想做一个区块链应用，什么样的技术适合我。比如我是把比特币代码 fork 出来改一套自己的实现，还是采用某些供应商提供的解决方案呢？

第二点，现在围绕区块链开发的是所谓的去中心化应用(Decentrilized Application)，很多人发现这跟我们做一个传统的企业级应用或者互联网应用的思路是不太一样的。因为它所带来的去中心化的思路，会对我的整个架构设计思路产生影响，在这种情况下应该如何设计我的软件？

第三点，区块链在部署层面，也跟我们传统的基于私有机房里或者公有云私有云部署的应用不太一样，因为我们需要去中心化地部署区块链的节点，我们会遇到哪些挑战，应该怎么优化我们的部署方式。

今天我将从以上三点跟大家分享一下我自己的认识。

区块链的技术选择
不知道大家听说过哪些跟区块链有关的技术名词？有人提到了以太坊，这可能是目前最成熟的区块链开发平台。还有人提到了超级账本，这也出现在我们这一期的技术雷达上面。还有人提到了像布萌这样的区块链解决方案，现在中国有非常多这样区块链领域的创业公司。

我们看一下这页 slide，这个图上面密密麻麻的图标，这是 Willam Mougagyar 总结的 2016 年的区块链在 Fintech 领域的 landscape，非常多的技术。当然大家知道区块链其实不只是在金融领域，在供应链、医疗等很多其他领域都有应用。在这张全景图里的区块链技术有基于比特币等加密货币的基础设施，有开发智能合约的平台，有中间件，有上层更有针对性的行业解决方案。当你想要做一个区块链的应用，你会发现有很多选择。

不是所有的企业都是直接做区块链业务的创业公司，我们企业很多时候希望是能够看到这个技术能给公司带来什么样的改变和价值。当然也是因为这个技术有非常大的潜力，很有可能颠覆掉现在很多像支付、中介这样的业务形态，我们可能想要提前看一下，防止被一些崛起的区块链创新者颠覆掉。

我这里假设，我们不会自己从零研发一套区块链的技术栈。我的确看到很多创业公司基于比特币、瑞波币等开源的加密货币，fork 出来在上面做开发。我们建议基于一些相对成熟的，开源的或者商业的解决方案，在上面构建我们的应用。

在去选择区块链技术的时候，首先它跟我们以往做技术决策没有任何的区别。我们以前做技术决策会看这个方案提供什么类型的编程语言的接口，要考虑程序员是不是熟悉，它的文档支持什么样，它的背后是不是有一些大公司，是不是有开源组织背书，够不够稳定，行业里面有没有应用案例。

在这之外，当我们选择 Blockchain 技术的时候，一定要建立在自己需要解决的业务问题上。 Gartner 今年初的时候发布的了篇文章叫“Top 10 Mistakes in Enterprise Blockchain Projects”，其中提到了一大家对区块链应用的误区是“Confusing a limited, foundation-level protocol with a complete business solution” 。

区块链这个概念最早由中本聪在 08 年底比特币白皮书里的一个章节提出，只是作为比特币的一个底层的实现技术出现的。在 09 年开始以比特币为代表的加密货币火了很久后，从这一两年开始，大家才发现区块链技术本身也有它的价值。我们在看待区块链技术的时候，一定要把它当成一个冷冰冰的技术。我们不是在做“区块链” ，不是拿着锤子找钉子。区块链技术本身，跟我们的商业解决方案是有区别的，它是我们要构建的业务解决方案的一部分。很多时候我们需要更加关注在我们的区块链解决方案上。

怎么样找到能用区块链解决的业务问题，其实可以用一些精益创新的方法论。这些方法论说它新吧，很多创业公司、以及我们给我们的客户做咨询已经用了很多年；说传统，很多公司还没开始用这样的方法去梳理自己的创新业务。这些方法论包括分析你所面对的目标客户群体，建立他们的用户画像；通过对面向需求的场景进行分析，建立客户体验地图；以及为了支撑该体验，梳理各业务环节应该怎样流转，分析业务流程地图；此外通过商业触点分析跟你的业务模式之间的交互，通过体验心情地图和设计挑战改善你的产品设计和用户体验。

这些方法论在很多业务创新中都是适用的，那么在区块链应用中我们应该额外注意什么？首先我们要明确区块链解决的两个核心问题：第一个是分布式的信任(Distributed Trust)，第二是不可抵赖的账本(Indelible Ledgers)。

首先是分布式信任，它能够在所谓的去中心化的场景下，多个完全没有信任关系的参与方，在没有一个中间的权威背书情况下，建立起共识和信任。前面梳理业务流程和商业触点的时候，我们要去分析在企业整个业务流程里，有哪些触点是我需要跟第三方的组织、机构发生交互，需要去建立某种信任机制，我们的区块链技术可以应用在这些触点上。区块链的另一个使用场景是不可抵赖的账本。因为我们知道区块链通过将每一笔交易进行哈希、多个交易哈希通过 Merkle Tree 构建为区块、再讲不通区块通过 Hash Point 串成一个链条，这种结构能够非常容易和高效地校验到对底层账本的篡改。那些需要去审计，需要去合规的业务，一旦你使用了区块链类的技术，它能够给你带来的成本降低是非常明显的。

所以在我们说区块链的应用的时候，一定不是单纯看着这个技术去开脑洞。一定是基于真实的业务问题，我们对真实的业务问题进行分析，找这类需要构建多方信任的点，找到需要不可抵赖的数据的点，在这些点上再去构建区块链的解决方案。

找到了业务问题后，我们可能还需要关注两个核心的业务指标。第一是业务的吞吐量，第二是业务的交易确认时间。

首先我们要了解这项业务交易的吞吐量有多少。比如如果我做的是一个跨国结算的业务，每天的交易量是几十万笔，那我的区块链系统所支持的日吞吐必须要支撑这个数字，这是交易吞吐量。

另外一点是交易的确认时间，当我发生了一笔转帐或者一笔支付，交易多长时间能够确认。比特币的例子大家都比较熟悉。大家都知道比特币真正链上的交易吞吐量比较低，TPS 只有 7，也就是每秒 7 笔交易。如果直接基于比特币开发商业应用，那可能很多日交易量超过百万的业务场景是没有办法支撑的。另外，比特币是每十分钟生成一个区块，也就是一次转帐的确认时间要花十分钟。而一般连续生成 6 个区块，也就是大概 1 个小时的时间，我们才认为你的这次转账已经在链上比较稳定，不太容易被篡改了。十分钟的时间，如果你想做的是跨国支付，这相比于传统 T+2、 T+3 的到账时间已经大大缩短了。但是如果做一些面向消费者的应用，消费者不可能站在那里等你十分钟，才能知道我付款成功了。当然这里只是用比特币举例子，实际在比特币上有很多像微支付通道、闪电网络、隔离见证这样的技术去改善比特币的吞吐量和交易确认时间。

但这里是想提醒大家，你所面对业务的交易吞吐量和交易确认时间，会很大程度影响你选择什么样的区块链技术。跟具体的区块链技术相关，我认为有一些因素是不用考虑的：

比如你用了什么样的加密算法，单向加密是用的 SHA128 还是 SHA256，非对称加密是用的 RSA 还是椭圆曲线。我们认为作为企业中你其实不需要太关注具体的加密算法，这应当是你选择的区块链技术栈的一部分，加密算法实现封装在内部。自己去实现加密算法和做调优非常难写对，尽量不要自己写。

另外，还有一些基于开源区块链技术去扩展自己应用的公司，可能会去调优 P2P 网络的通信性能。这个我们也是同样的观点，作为企业来说没有必要自己去调这些底层的网络通信协议，它应该是你在选择某种区块链技术时就考察过的。

还有很多人在提区块链的交互操作性(Interoperability)。我们知道前面列了这么多区块链的技术实现，它们底层的协议，包括账本的数据结构，节点的验证和通信方式，在上面跑的只能合约都是互不兼容的。有点像我们在上世纪建立全球的 Internet 前，每个组织有很多自己的局域网。当然这些局域网都发挥了它们自己的作用，但彼此之间是信息孤岛没有打通。所以很多人说你选用区块链的时候要考虑交互操作性，考虑是不是和其他的区块链实现兼容，这样将来大一统的时候，你不用做太多迁移的工作。我承认交互操作性非常重要，但坦白来说，在这个时间点，我不建议大家在这上面花太多的时间。因为现在并没有哪一种实现成为所谓的事实标准(defacto standard)。未来比特币或是以太坊是否完成大一统，都不一定。这个时候没必要投入太多时间去试图预测不确定的未来。

跟具体区块链技术相关的因素，我建议可以考虑这三个点：第一点，你的共识算法。第二点是账户模型，第三点是智能合约。

共识算法，有人开玩笑说解决的是“今天中午吃什么”的问题？这是一个很贴切的描述。所谓的分布式共识算法，我有这么多分布式的节点，彼此之间需要网络通信对某个状态达成共识，但彼此之间又不信任。这跟我们在互联网应用做分布式系统有很大的区别。传统的分布式系统节点都部署在自己的机房里，不需要考虑拜占庭错误，你需要考虑的只有丢包、超时、机器 crash 这些问题，用 Paxos 和 Raft 一类的算法就可以了。

但是如果做区块链的应用，我一定要处理拜占庭错误，面对潜在的欺诈和篡改的情况。这里选择不同的共识算法，会对你的区块链应用有比较大的影响。不同的区块链技术，一般会选择不同的分布式共识的算法，这跟区块链技术本身的价值主张也有关系。有的区块链应用可能就是要做公有链，面向公开网络；有的区块链应用做的是联盟链，有限节点，追求高性能、高吞吐量，它们选用的共识算法一定是不同的。这里是主要算法的对比。

比较有名的共识算法有三大类。

一个类是在比特币验证了很多年的 PoW，工作量证明， PoW 已经被证明非常适合这种全开放网络的公有链，对于拜占廷错误的容忍率比较高，一般我们认为有 51%的节点联合起来进行欺诈，才能对整个区块链产生有效供给。但相应的，PoW 非常消耗算力，吞吐量和确认时间也都不太理想。

还有一大类是以太坊采用的 PoS，权益证明，以及 DPoS 等扩展。权益证明是基于不同节点的股权数，有点像真实的股东大会投票一样，在股东里面随机选举节点进行记账。这类算法也比较适合公有链，相比 PoW 在容量和计算资源上都是有优化的。

还有一类是拜占廷容错协议 BFT，比较有名的像 PBFT。这类算法是基于状态机同步的算法(state machine replication)，不需要代币。当客户端发送请求给一个节点，每一个节点互相广播其他所有节点发送消息，彼此之间进行交易的确认。一般来说它的延时比较低，吞吐量也更高，但是相对来说对网络压力也比较高，更加适合有限网络节点。另外 BFT 类算法对拜占庭错误的容忍度也相对较低，像 PBFT 有 f 个节点发生拜占庭错误时，整个网络要大于 3f+1 个节点才能保证正确性。

2016 年业界在共识算法上面也做了很多探索，现在大家基本达成的共识是：如果你的区块链应用场景是公有链，可以使用 PoW、 PoS 这类算法，如果你的区块链应用场景是许可链联盟链，可以采用 BFT 类算法。

另外一个，你所使用区块链技术的账户模型。有两个流派，第一个流派以比特币为代表的 UTSO 模型，第二个以以太坊为代表的简单账户模型。

先说一下简单账户模型，很简单，我转帐支付就是钱加减、付钱。 UTSO，在每一个构建交易的时候，有输入和输出。比特币我有一千块钱，给艾丽斯转一百块钱的时候，我不是扣掉一百块钱，我是构造这么一个交易，输入一百块钱，输出一百块钱。你的每一次交易数据会记录在这个账本里面，这样日后做一些数据分析更加容易。因为最早是比特币提出的，对于双发问题比较奏效。简单账户模型它比较有效，就是简单的转帐，可以支持一些比较高级的，如果你基于 UTSO 做可能会更麻烦一些。

第三个是对智能合约的支持，很多人做了一两年，发现我们原来只需要一个分布式账本，只需要一个记账的。如果你只做一个不可篡改的记账，但是很多公司，很多组织看中它的智能合约的能力。选择技术，在技术雷达里面出现了两个，这是我们做过一些共同试验的解决方案。

去中心化
另外一点，在构建区块链的应用的时候，你应该怎么构建。很多人说区块链是完全去中心化的，跟传统的思路完全不一样，怎么构建我的应用，完全懵了。

在你的传统的应用里面，最上层是 UI 层，最下层是数据库。而在区块链部署中，最上层是你的 Cllent，它里面不会跑真正的节点，只是一个轻客户端，负责调用后层的区块链的合约，包括你做一个网站也好，你可以使用任何熟悉的技术。真正的核心部分是 SMART contract，最底层是分布式的账本。只有下面这几层才需要去中心化的部署，去构建的。上层跟我们传统的技术没有任何区别。

在去构建区块链应用的时候，我们看到一些公司做咨询，发现它们把很多东西做到一块了。因为是一个新的东西，做在一块非常方便。但是区块链有一些共识算法，这就导致往后演化非常不容易，因为这里面每一部分都可以独立的演化和独立发展。

这里是 hyperledger，我的身份管理，我的注册，一部分是所谓的负责底下的共识算法、分布式账本，这些都是特别像共识算法，一部分是在 hyperledger 里面的智能合约。即使我们没有使用 hyperledger，我们自己做公有云也是类似，这部分一定要跟业务的应用不能放在一个代码进行编译打包。

另外一部分，有可能不是由智能合约，我们希望把这部分单独拿出来，单独做一个服务的模块。一般来说在你的区块链里面一定会涉及身份的管理，无论你使用什么样的技术都会有这一块，我们也建立独立出来。它给推荐了一个架构，我们看到它也是把我们分布式账本，把身份跟密钥管理服务做成共同的服务，包括加密算法能够提炼出来，在上面承载了一些 ML、 BI 的 servlces。最上面是应用，监控端，跑一些真正的解决方案，这是区块链相关的技术，这是底层的账本，旁边可以结合其他的区块链的定制工具，结合市场做一些架构。

这是我们推荐的方式，因为区块链是很多技术的混杂，一定不要混在一块，要构成一个一个独立的服务。这样像身份管理，像区块链技术、共识算法、加密技术，都可以选择独立的技术的提供商，或者独立的开元实现，去构建自己独立的业务，这样不会绑死在某一个平台上，可以有更大的发挥空间。

部署和建议
说到部署，这里只提一点原计划的应用。一些同学问我，他们是自己做技术的创业者。说区块链这个技术，我一旦数据写进去就不可篡改了，很多时候我想要改这个数据怎么办？

我说分两种情况。第一种情况，真的是出于监管审计的要求做篡改，也是分两个流派，一派认为区块链的技术应该提供这样的能力，我是站在另外一派，我认为不应该提供这种能力。另外，你明明写错了，我看到个人开发者面临的问题，因为我自己的应用写错了，导致数据损坏和数据错误。你在正常的企业里面做开发，一定是经过严格的开发和测试，要提前测试才能上到生产环境的。我们一般开发可能本机布几个节点，然后一个网络，不可能开发完之后直接去了，你一定会有区块链不同的测试网络节点，你上生产环境之前一定要充分的测试，去保证这部分的逻辑没有错，不会因为逻辑的问题导致数据的错误，然后才能上升到生产环节。怎么在本地的生产环境、开发之间能够维护一套统一的环境，包括基础设施，区块链的网络配置，我们认为是用这个技术非常容易解决的。

另外一点，你真正面临一个问题，你现在部署的应用不是只是在你自己的机房里边，你有全部的权限部署。为了建立分布式的信任，你需要在不同的节点上，不同的参与方，可能在你的组织之外，你去分发你的应用，你没有一个苹果商店，你很难约束他们的环境，他们的技术环境，他们的条件。这时候，我们认为你只是分送给他们一个最新的软件包让他们升级，可能会有很多不可控的因素。包括他们使用的技术、软件版本、中间件会有一些冲突，可能有些难以预料的问题。在这种场景下，从你的软件和环境整个标准化，去分发，我认为是很好的策略。所以我们建议当你做应用的时候，还是用原计划管理环境，管理部署和发布。

最后，在企业想要尝试区块链技术的时候，会面临非常多不确定的因素，这里我总结了三点建议给大家：

● 当你选择区块链技术的时候，一定是在你的业务上，它不是一个纯粹的技术，一定是应用解决方案的一部分。

● 区块链的应用也好，还是去中心化应用，我们建议把它构建在一系列独立的服务上，这样不同的部分可以独立的演化和部署。

● 希望原计划来管理，提高你的部署，包括软件分发的效率。

今天的分享就是这些，谢谢大家。