雷锋网AI金融评论报道，5 月 13 日，由 ThoughtWorks 主办的 2017 技术雷达峰会在北京召开。ThoughtWorks 中国区区块链能力负责人刘尚奇在大会上发表了题为《Blockchain in Enterprise》（企业区块链）的主题演讲，系统讲解了区块链技术在企业级应用中的实践问题。

刘尚奇表示，区块链的概念近两年逐渐深入人心，但真正进入企业级应用的时候，实际上还面对许多问题。从业者应该清醒认识到：进行区块链选择的决策时，从业者一定要从当前需要解决的实际业务问题出发，将决策建立在真正的业务需求上，而不是一个纯粹的技术。技术应该是应用解决方案的一部分。

但作为应用解决方案的一部分，企业开始部署区块链时发现区块链需要去中心化，这跟传统应用的部署思路几乎完全不同，并因此陷入困境。对此刘尚奇表示，在区块链技术中除了智能合约和分布式账本等底层组件需要去中心化之外，其实上层架构跟传统技术完全没有区别。同时他建议：

不论区块链的应用是去中心化的应用，企业都应该把它构建在一系列相互独立的服务基础上，将系统模块化，这样不同的部分就可以进行独立的演化和部署。

关于区块链理论和实践的更多内容，雷锋网 AI 慕课学院在“从零构建一个区块链应用”系列课程中将做一个全面讲解，刘尚奇也是导师之一，感兴趣的朋友千万不要错过！

以下为演讲全文（雷锋网做了不改变原意的编辑）：

如果你想要在你的组织里引入区块链技术，你应该注意哪些事情？我们觉得在一个企业里面，你做区块链的时候必须考虑下面这几个因素：

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

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

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

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

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

不是所有的企业都是直接做区块链业务的创业公司，企业更多地希望这项技术能给公司带来什么改变和价值。因为区块链所具有的巨大潜力——很有可能颠覆当前支付、中介等业务形态，大家都可能想提前准备，防止被崛起的区块链创新者颠覆掉。

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

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

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

区块链技术本身，跟我们的商业解决方案是有区别的，它是我们要构建的业务解决方案的一部分。很多时候我们需要更加

怎么样找到能用区块链解决的业务问题，这些方法论包括：分析所面对的目标客户群体，建立用户画像；通过对面向需求的场景进行分析，建立客户体验地图；以及为了支撑该体验，梳理各业务环节应该怎样流转，分析业务流程地图；此外通过商业触点分析跟你的业务模式之间的交互，通过体验心情地图和设计挑战改善你的产品设计和用户体验。

此外，在区块链应用中我们应该额外注意什么？首先我们要明确区块链解决的两个核心问题：第一个是分布式的信任(Distributed Trust)，第二是不可抵赖的账本(Indelible Ledgers)。

首先是分布式信任，它能够在所谓的去中心化的场景下，多个完全没有信任关系的参与方，在没有一个中间的权威背书情况下，建立起共识和信任。

前面梳理业务流程和商业触点的时候，需要：分析在企业整个业务流程里，有哪些触点是我需要跟第三方的组织、机构发生交互，需要去建立某种信任机制，我们的区块链技术可以应用在这些触点上。

区块链的另一个使用场景是不可抵赖的账本。区块链通过将每一笔交易进行哈希、多个交易哈希通过 Merkle Tree（梅克尔树）构建为区块、再通过 Hash Point 串成一个链条，这种结构能够非常容易和高效地校验到对底层账本的篡改。那些需要审计，需要合规的业务，一旦使用了区块链类的技术，能够给你带来的成本降低是非常明显的。

所以在我们说区块链的应用的时候，一定不是单纯看着这个技术去开脑洞，一定是基于真实的业务问题。

我们对真实的业务问题进行分析，找这类需要构建多方信任的点，找到需要不可抵赖的数据的点，在这些点上再去构建区块链的解决方案。

找到了业务问题后，我们可能还需要

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

另外一点是交易的确认时间，当我发生了一笔转帐或者一笔支付，交易多长时间能够确认。比特币真正链上的交易吞吐量比较低，每秒 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。最上面是应用，监控端，跑一些真正的解决方案，这是区块链相关的技术，这是底层的账本，旁边可以结合其他的区块链的定制工具，结合市场做一些架构。

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

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

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

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

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

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

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

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

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

提问一：刚才说到一个问题，假如我的业务真是有问题影响了数据，假如在生产环境中改我的区块链的数据是合理的吗？

刘尚奇：因为我们知道这个区块链技术它的特点就是所谓的数据不可篡改性。其实很多人问这个问题，我在生产环境改这个数据真的合理吗？我刚才也说两个流派，第一个流派，认为我作为现实中一定会发生错误的，一定是有包括监管的需要，特别像中国的场景会更明显一些，如果技术不提供监管和改数据的能力，可能政府都不会放行。这个由区块链的技术平台实现，可能会建立一个单独仲裁的节点和实现，像 Oracle，它来做我们的数据的最终审计，它是一个更权威的，去做一些修改的操作。但是我个人，包括很多做区块链技术的社区同仁也是认为，这个是不合理的，因为这个会抹杀区块链技术带来的价值，会抹杀你对区块链的信任。如果真的出现这样的情况怎么办？现实生活中人类一定会犯错，业务一定会犯错，现实生活中怎么处理的？通过线下的方式，你打个电话，你打错了钱，我们打钱回来，通过线下的契约弥补技术本身，技术保持它的价值，我靠其他的业务运转活动做补偿。谢谢。

提问二：我有一个问题，您说的可能更多是金融行业。我想它对于其他的行业有什么影响？比如传统的行业。

刘尚奇：这里可以开一个脑洞，如果大家熟悉 DEO 是什么概念。除了金融行业，因为你的区块链可以在一个一个不同的参与方之间建立起来分布式的共识，所以现在很多所谓的 O2O，一些中介化的应用也不需要了，包括 P2P。我不知道在座有没有滴滴打车或者大众点评这样的。如果你基于区块链的平台，大家开发出来这么一套打车软件或者租房软件，或者大众点评，我为什么还需要专门的公司去运营呢？我是租房的，有一个租房的租户，我有一个出租房源的房主，只需要这两方参与，我的信任和程序，不需要一个真正的公司和实体去建立这种信任。所以如果从这个角度去看的话，你发现我们现在很多做互联网 O2O，或者线上到线下，一些互联网化的应用，一些崛起的巨头公司，它们的业务场景都可以用区块链的智能合约去取代的。不知道有没有尝试解答这个问题。

提问三：我想问一下，公有链、私有链，现在还有一个联盟链。我简单理解联盟链就是几个私有链加在一起？

刘尚奇：私有链，我是一个组织，在组织内部，组织内部即使不用区块链，你也是有足够的信任度的。 联盟链是多家组织之间，比如说银行之间的信用卡的结算，我以前可能需要 visa 这样的机构，因为我银行 A 是建行，给招商银行转帐，我是在数据库里面扣一百块钱，给你的数据库里面加一百块钱，但是我们的数据库是分开的，没有办法确认你加的是一百块钱，不是两百块钱，我们需要像 vasa 这样的中介。如果出来了联盟链，我们在不同的参与方之间建立节点，我们达成一个共识，我们底下是共享账本，我知道扣了一百块钱，就是给你增加了一百块钱。联盟链更加适合于银行之间的结算，我们本身在业务上有一定往来和联系的实体，可能以前需要一个中介，一个背书方，一个权威的认证者做权威的授权，现在可以抛开它自己玩儿了。

编者注：按照官方介绍，"ThoughtWorks技术雷达"并不是一个客观的行业分析或者报告，也无意成为一份权威的官方文档，他所展现的就是当下技术领域上的一个“快照”，并进行了粗粒度的分类和趋势分析。ThoughtWorks 全球技术委员会（TAB）定期讨论技术发展现状，并以雷达形式对各类技术的成熟度进行评估并给出建议，为从程序员到 CIO/CTO 的利益相关者提供参考。这也是大会名称中“雷达”一词的意义。

——————————————————————————————

“从零构建一个区块链应用”开课啦！

ThoughtWorks 顶级专家手把手教你实现区块链应用！

课程详情：http://www.mooc.ai/course/78