与比特币关系最密切的技术：区块链原来是这样玩的

雷锋网消息。 2017年5月13日，由ThoughtWorks主办，在北京举行。 ThoughtWorks中国区区块链能力负责人刘尚奇在大会上发表了题为“企业区块链”（Enterprise Blockchain）的主题演讲，系统分享了区块链技术在企业级应用的实践问题。

刘尚奇表示，区块链的概念这两年逐渐深入人心，但真正进入企业级应用时，其实还面临很多问题。 从业者应该清楚地认识到，选择区块链技术与我们过去所做的所有其他技术决策没有什么不同。 从业者一定要从当前需要解决的实际业务问题出发，根据真正的业务需求而不是单纯的技术来做决策。 技术应该是应用程序解决方案的一部分。

然而，作为应用解决方案的一部分，当企业真正开始部署区块链时，却发现区块链需要去中心化，这与传统的应用部署思路几乎完全不同，从而陷入了两难境地。 对此，刘尚奇表示，在区块链技术中，除了SMART合约、分布式账本等底层组件去中心化之外，上层架构其实与传统技术完全没有区别。 同时，他建议：无论是区块链应用还是去中心化应用，企业都应该建立在一系列独立服务的基础上，将系统模块化，让不同部分可以独立演进和部署。

更多区块链理论与实践，雷锋网（公众号：雷锋网）AI MOOC学院将在“”系列课程中进行全面讲解。 刘尚奇也是教官之一。 如果您有兴趣，请这样做。 不要错过！

以下为演讲全文（AI研究院做了不改初衷的修改）：

我想在座的各位应该都对区块链有所耳闻。 正如前面几位讲者所说，区块链近几年非常火，2016年被称为区块链元年。 区块链这个概念前面讲的太多了，今天就不讲了。 如果您想在您的组织中引入区块链技术，让我们谈谈您应该注意的事项。

在过去一年多的时间里，我们和一些客户在区块链项目上做了一些共同探索，也和社区进行了一些交流。 我们认为在一个企业中，做区块链一定要考虑以下几个因素。

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

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

第三点，区块链的部署层次和我们传统的基于私有机房或者公有云、私有云部署的应用是不一样的，因为我们需要去中心化地部署区块链节点，我们会遇到什么是挑战以及我们应该如何优化我们的部署方法。

今天我将从以上三点与大家分享一下自己的理解。

区块链技术选择

不知大家听说过哪些与区块链相关的专业名词？ 有人提到以太坊，它可能是目前最成熟的区块链开发平台。 也有人提到了 Hyperledger，它也出现在了我们这一期的技术雷达上。 也有人提到了布盟这样的区块链解决方案。 现在国内区块链领域有很多创业公司。

大家看一下这一页的幻灯片，这张图上密密麻麻的图标，这是William Mougagyar总结的2016年区块链在金融科技领域的风景，很多技术。 当然，大家都知道区块链不仅仅是在金融领域，在供应链、医疗等很多其他领域也有应用。 全景图中的区块链技术具有基于比特币等加密货币的基础设施、开发智能合约的平台、中间件以及更上层针对性的行业解决方案。 当你想做一个区块链应用时，你会发现有很多选择。

并非所有公司都是直接从事区块链业务的初创公司。 我们公司往往希望看到这个技术能给公司带来什么样的改变和价值。 当然，也是因为这项技术潜力巨大，极有可能颠覆目前支付、中介等诸多业务形态。 我们可能要提前看一下，以免被一些正在崛起的区块链创新者颠覆。

我在这里假设我们不会从头开始开发区块链技术堆栈。 我确实看到很多初创公司基于比特币和瑞波币等开源加密货币进行分叉和开发。 我们建议在一些相对成熟的开源或商业解决方案之上构建我们的应用程序。

在选择区块链技术时，首先，它和我们之前的技术决策没有区别。 我们以前做技术决策的依据是解决方案提供什么类型的编程语言接口，程序员是否熟悉，支持什么样的文档，背后有没有一些大公司，有没有开源背书组织。 够稳定吗？ 有行业应用案例吗？

另外，当我们选择区块链技术时，我们必须建立在我们需要解决的业务问题之上。 Gartner 在今年早些时候发表了一篇名为《企业区块链项目中的十大错误》的文章，其中提到了对区块链应用的一种误解，即“将有限的、基础级的协议与完整的业务解决方案混为一谈”。

区块链的概念最早由中本聪在2008年底的比特币白皮书一章中提出，只是作为比特币的底层实现技术出现。 自2009年以比特币为代表的加密货币开始流行以来，时隔许久，直到近两年，大家才发现区块链技术本身也有它的价值。 当我们看待区块链技术时，我们必须将其视为一项冰冷的技术。 我们不是在做“区块链”，不是用锤子找钉子。 区块链技术本身不同于我们的业务解决方案。 它是我们想要构建的业务解决方案的一部分。 很多时候我们需要更加关注我们的区块链解决方案。

如何找到区块链可以解决的业务问题，其实可以用一些精益创新的方法论。 这些方法是新的。 许多初创公司，我们多年来一直在使用它们来咨询我们的客户。 说到传统，很多企业还没有开始用这种方式来梳理自己的创新业务。 这些方法论包括分析你所面对的目标客户群体，建立他们的用户画像； 通过面向需求的场景分析，构建客户体验地图； 梳理每个业务环节应该如何流动，分析业务流程，以支撑体验地图； 此外，通过业务接触点分析与您的业务模型的交互，并通过体验情绪图和设计挑战来改善您的产品设计和用户体验。

这些方法论适用于很多业务创新，那么在区块链应用中需要注意什么？ 首先，我们需要明确区块链解决的两个核心问题：第一个是分布式信任，第二个是Indelible Ledgers。

第一个是分布式信任，在所谓的去中心化场景下，完全没有信任关系的多方可以建立共识和信任，不需要中间的权威背书，就可以建立共识和信任。 在梳理业务流程和业务触点时，我们需要分析企业整个业务流程中有哪些触点。 我需要与第三方组织和机构进行交互，我们需要建立某种信任机制。 我们的地区区块链技术可以应用于这些接触点。 区块链的另一个用例是不可否认的分类账。 因为我们知道区块链对每笔交易进行哈希处理，多个交易哈希通过Merkle Tree构造成块，通过Hash Point将不合理的块串成一条链。 这种结构可以非常简单高效，可以准确验证底层账本的篡改情况。 对于那些需要审计合规的业务，一旦你使用了区块链技术，它能给你带来的成本降低是非常明显的。

所以我们在谈区块链的应用时，千万不能只看这个技术来开阔眼界。 它必须基于真实的业务问题。 我们分析真实的业务问题，找到需要建立多方信任的点，找到需要不可否认数据的点，然后在这些点上构建区块链解决方案。

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

首先，我们需要了解这个业务事务的吞吐量。 比如我做的是跨境结算业务，每天的交易量是几十万，那么我的区块链系统每天支持的吞吐量必须支持这个数字，就是交易吞吐量。

还有一点就是交易的确认时间。 当我进行转账或付款时，交易确认需要多长时间。 每个人都熟悉比特币的例子。 大家都知道真正的比特币链上的交易吞吐量是比较低的，只有7TPS，也就是每秒7笔交易。 如果直接基于比特币开发商业应用，可能无法支撑很多日交易量超过百万的业务场景。 此外，比特币每十分钟产生一个区块，即确认一笔转账需要十分钟。 一般连续产生6个区块，也就是1个小时左右，才认为你的转账在链上已经比较稳定，不容易被篡改。 十分钟，如果你要做的是跨境支付，这比传统的T+2、T+3大大缩短了到账时间。 但是如果你做一些面向消费者的应用，消费者不可能站在那儿等你十分钟就知道我支付成功了。 当然，这只是比特币的一个例子。 事实上，比特币上有很多技术，比如小额支付通道、闪电网络和隔离见证，来提高比特币的吞吐量和交易确认时间。

但是在这里要提醒大家的是在比特币中区块链的作用是，你的业务的交易吞吐量和交易确认时间会极大地影响你选择的区块链技术。 与具体的区块链技术相关，我认为有一些因素是不需要考虑的：

比如你用的是什么加密算法，单向加密是用SHA128还是SHA256，非对称加密是用RSA还是椭圆曲线。 我们认为，作为企业，不需要过多关注具体的加密算法。 这个应该是你选择的区块链技术栈的一部分，里面封装了加密算法实现。 自己实现加密算法和调优难度很大，尽量不要自己写。

此外，一些基于开源区块链技术扩展自身应用的公司可能会调整 P2P 网络的通信性能。 我们也持有相同的观点。 作为企业，没有必要自己去调整这些底层的网络通信协议。 应该是你在选择某项区块链技术时考察过的东西。

很多人也在提到区块链的互操作性（Interoperability）。 我们知道，上面列举了这么多的区块链技术实现，它们的底层协议，包括账本的数据结构、节点的验证和通信方式，以及运行在其上的智能合约，都是互不兼容的。 这有点像上个世纪我们建立全球互联网之前，每个组织都有很多自己的局域网。 当然，这些局域网发挥了各自的作用，但它们是相互之间没有联系的信息孤岛。 所以很多人说选择区块链的时候要考虑互操作性，和其他区块链是否兼容，这样以后统一的时候就不用做太多的迁移工作了。 我承认互操作性非常重要，但坦率地说，在这个时间点上，我不建议在这上面花太多时间。 因为没有所谓的事实标准这样的实现。 比特币或以太坊是否会在未来完成统一还不确定。 这个时候，没有必要投入太多时间去预测不确定的未来。

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

共识算法，有人开玩笑说它解决了“今天午餐吃什么”的问题？ 这是一个非常恰当的描述。 所谓分布式共识算法，我有那么多分布式节点，它们需要网络通信，对某个状态达成共识，但是彼此之间又不信任。 这一点和我们在互联网应用中的分布式系统是很不一样的。 传统分布式系统的节点部署在自己的机房，不需要考虑拜占庭错误。 只需要考虑丢包、超时、死机等问题。 Paxos、Raft等算法就足够了。

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

有三种著名的共识算法。

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

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

另一类是拜占庭容错协议BFT，比较有名的是PBFT。 这类算法基于状态机同步算法（state machine replication），不需要token。 当客户端向节点发送请求时，每个节点都会广播所有其他节点发送的消息，以确认彼此之间的交易。 总的来说它的延迟比较低，吞吐量也比较高，但是相对来说对网络的压力比较大，比较适合网络节点有限的情况。 此外，BFT 算法对拜占庭错误的容忍度相对较低。 例如，当PBFT有f个节点出现拜占庭错误时，整个网络必须大于3f+1个节点才能保证正确性。

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

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

先说简单的账户模型。 这很简单。 我的转移支付是货币加减法支付。 UTSO 在构建每笔交易时，都有输入和输出。 我有一千美元的比特币。 当我给爱丽丝转一百块钱的时候，我不扣一百块钱。 我构造这样一个交易，输入一百美元，输出一百美元。 你的每一笔交易数据都会记录在这个账本里，方便以后做一些数据分析。 因为是比特币最先提出的，所以对于双发问题比较有效。 简单账户模型比较有效，就是简单转账，可以支持一些更高级的。 如果基于UTSO来做，可能会比较麻烦。

第三是对智能合约的支持。 很多人工作了一两年，发现我们只需要一个分布式账本，只需要一个簿记员。 如果只是做一个不可篡改的记账，很多公司和组织都很看重它的智能合约能力。 选择一项技术，技术雷达中有两项。 这是我们进行了一些常见实验的解决方案。

分散的

还有一点，在构建区块链应用的时候，应该怎么构建。 很多人说区块链是完全去中心化的，这与传统的思维方式完全不同。 如何构建我的应用程序是完全无知的。

在你的传统应用程序中，顶层是 UI 层，底层是数据库。 在区块链部署中，最上层是你的Cllent，它不运行真正的节点，而是一个轻客户端，负责在后层调用区块链的合约，包括你是否做网站，你熟悉的任何技术都可以使用. 真正核心的部分是SMART合约，最底层是分布式账本。 只有以下几层需要去中心化部署和建设。 上层和我们传统的技术没什么区别。

在构建区块链应用的时候，我们看到一些公司做咨询，发现他们把很多东西组合在一起。 因为是新东西，所以做成一块很方便。 但是区块链有一些共识算法，这使得以后很难进化，因为它的每一部分都可以独立进化和发展。

这里是hyperledger，我的身份管理，我的注册，其中一部分负责所谓的共识算法和分布式账本，这些跟共识算法很像，一部分是hyperledger里面的智能合约。 即使我们不使用 hyperledger，也类似于构建我们自己的公共云。 这部分必须和业务应用一起编译打包，不能放在同一个代码中。

另一部分可能不是由智能合约组成。 我们希望把这部分拿出来，做一个单独的服务模块。 一般来说，身份管理必须涉及到你的区块链。 不管你用什么技术，都会有这部分，我们也会独立建立。 它推荐一种架构。 我们看到它也让我们的分布式账本、身份和密钥管理服务成为一个公共服务，包括可以提取的加密算法，一些ML和BI服务都承载在上面。 最上面是应用程序、监控终端和运行一些真正的解决方案。 这是区块链相关的技术，也就是底层账本。 旁边还有其他的区块链定制工具可以结合市场做一些结构。

这是我们推荐的方式，因为区块链是很多技术的混合体，一定不能混在一起，必须一个一个形成独立的服务。 像身份管理一样，像区块链技术、共识算法、加密技术，你可以选择一个独立的技术提供商，或者一个独立的开源实现，来构建自己独立的业务，这样你就不会被某个平台所束缚。 ，才能有更大的发展空间。

部署和建议

说到部署，这里只是计划的应用程序的一小部分。 有同学问我，他们是做自己技术的创业者。 说到区块链技术，数据一旦写入，就无法被篡改。 很多情况下要改数据怎么办？

我说有两种情况。 在第一种情况下，监管审计确实需要篡改。 还有两种思想流派。 有人认为区块链技术应该提供这样的能力。 我站在另一边。 我认为不应该提供。 能力。 还有，你明明写错了，我也看到过个别开发者面临的问题，因为我自己的应用程序写错了，导致数据损坏，数据错误。 如果在正规企业做开发，必须要经过严格的开发和测试，必须提前测试，才能上生产环境。 我们一般在机器上开发几个节点，然后是一个网络。 开发完直接去是不可能的。 区块链必须有不同的测试网络节点。 在上生产环境之前，一定要进行全面的测试，确保这部分的逻辑没有问题，不会因为逻辑问题导致数据错误，才可以提升到生产环节。 如何在本地生产环境和开发之间保持一个统一的环境，包括基础设施和区块链网络配置，我们认为用这个技术很容易解决。

还有一点，你真的面临一个问题。 你现在部署的应用不只是在你自己的机房，你有全权部署。 为了建立分布式信任，你需要把你的应用程序分布在不同的节点，不同的各方，可能在你的组织之外在比特币中区块链的作用是，你没有苹果商店，你很难约束他们的环境，他们的技术环境，他们的条件。 这个时候我们认为你只是分发最新的软件包给他们升级，可能有很多不可控的因素。 包括他们使用的技术、软件版本、中间件，都会有一些冲突，可能会出现一些不可预知的问题。 在这种情况下，我认为将您的软件和环境作为一个整体进行标准化和分发是一个很好的策略。 所以我们建议大家在做应用的时候，还是按照原来的方案来管理环境，管理部署和发布。

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

● 当你选择区块链技术时，它必须是你的业务，它不是一个纯粹的技术，它必须是应用程序解决方案的一部分。

● 无论是区块链应用还是去中心化应用，我们都建议将其构建在一系列独立的服务之上，让不同部分可以独立演进和部署。

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