阿里云基于区块链服务构建企业业务系统实践总结

笔者注：本文是在 2018 年 8 月 19 日由 InfoQ 主办的 BCCon 全球区块链生态技术大会的演讲内容基础上整理而成，从技术上对阿里云区块链服务解决企业落地问题的思路以及设计理念进行了解读。

大家好！很高兴有机会来到 BCCon 大会向各位同行交流学习，今天我会跟各位分享一下阿里云在基于区块链服务构建企业区块链业务系统方面的实践和设计理念，也欢迎大家在后面的提问的环节分享你的宝贵想法和建议。

关于区块链的基本概念，我想在座各位通过此前的了解以及这两天的大会分享已经有不少了解，我就不再赘述了。但这里希望跟大家补充的一点是，公有链类型和联盟链、私有链之间有着很大的不同，包括技术架构、共识算法、治理模型、应用场景、目标客户等方面，因此需要区分地看待。

阿里云目前业务上主要关注的是联盟链和私有链类型。区块链在我们看来，本质上是用来解决在多方交易中的信任问题。

大家通过许多区块链的落地案例，无论是跨境汇款、电子发票、还是这里的资产证券化等场景中可以看到，区块链的一个典型价值在于：提升效率、降低成本。这是由于在传统业务模式中，由于各方缺乏信任，引入了很多低效、冗余的流程以及中间人角色，这些都是为了建立信任带来的成本。而使用区块链之后，各方共享账本、基于共识建立信任，便可以去除这些冗余的流程和中介，提升业务效率、降低商业成本。

而区块链技术更加吸引我们的、更为重要的价值，在于能创造出全新的商业模式。

试想一下，如果没有移动技术的诞生和发展，我们今天就不会有像移动支付、基于定位的精准营销、抖音小视频这些全新的应用场景出现。

上周我正好参加了阿里云亚太峰会，新加坡外交部长在峰会上做了主旨演讲，他强调了数据是新时代的石油，以及新加坡举国对此的高度重视和投入。这个让我印象非常深刻。

但在今天，企业之间由于缺乏信任基础、以及出于对政策法规的顾虑，不敢互相开展数据业务；个人由于担心隐私泄露，以及担心无法获得公平的利益分配，因此不敢与企业和其他个人分享有价值的数据。

但我们相信，也许在不远的未来，企业之间可以基于区块链建立起可信的数据业务联盟，实现数据资产的流转；而个人贡献的数据资产在区块链上可以得到严格的隐私保护，并且通过智能合约实现数据确权、流转、交易、使用的全生命周期记录，以及实时、自动、公平透明的收益分配。而这些可以通过联盟链、公有链以及跨链技术来共同实现。

从长远来看，正如云计算、AI 带来了生产工具的革命，区块链将带来生产关系的革命。但另一方面，我们也要理性看待其中的挑战。

因为从本质上，区块链技术通过智能合约、共识算法和账本的不可篡改，来建立起来人对机器的信任。

而商业信用的本质是建立在人和人之间的信任关系上的。

因此，如何通过区块链技术，去加固、改变、创新商业信用，是我们需要共同思考的问题，只有这样才能使区块链真正成为生产关系的基础设施。

接下来让我们从未来回到现实。

这一页是我在今年 4 月份 QCon 大会上总结和分享过的企业落地区块链需要考虑的问题。如果大家有兴趣了解细节可以参考 InfoQ 将我当时演讲内容所整理成的文章（https://www.infoq.cn/articles/hyperledger-fabric-at-aliyun）。

可以看到，企业需要考虑和完成很多方面的工作，同时我们也一直在思考，如何能减轻企业在区块链技术方面的投入和负担，让企业能更加专注地投入到对他们来说更有价值的业务上去。

因此在刚刚过去的 7 月底 8 月初，我们正式上线了阿里云的区块链服务，它是定位于云平台 PaaS 层的服务，支持主流区块链技术，目标是解决用户在区块链部署、运维、应用开发方面的挑战。目前区块链服务正面向国内用户公测，欢迎大家申请免费试用和提供反馈。

下面这页展示了阿里云区块链产品大图。其中 BaaS 是大图中心，我们实现了一系列区块链服务的核心组件，并运行于容器服务 Kubernetes 集群上；底层我们使用了阿里云的丰富的资源服务，同时整合了一系列阿里云的安全管理和运维管理服务；在上层，我们可以通过解决方案或者中间件的形式对接各种区块链业务应用场景。

这里分享一下区块链服务中三引擎的设计思路。

首先让我们先来分析一下企业用户的需求。可能会有一些用户说我只关心业务不关心技术、或者对区块链底层技术没有特别要求。但对大多数用户来说，随着对区块链了解的深入，我们发现有以下这两大类需求。

一类是要求使用原生、开源、标准化的区块链底层技术。这是因为他们的技术栈和应用接口都是基于标准的开源项目，并且希望得到包括共识算法在内的原生、透明、白盒的技术，因为对他们来说区块链底层实现的代码也是信任基础的一部分。那对于这类用户需求，我们采用了在全球最为主流、和最有代表性的 Hyperledger Fabric 作为引擎之一，目前支持的是 1.2.1 的版本。而 Hyperledger Fabric 也具有如下的这些优秀的区块链功能，这个大家应该有不少了解了。

此外，针对在全球开发者中普及度很高的以太坊技术栈，我们也推出了面向企业场景的企业以太坊 Quorum 引擎的支持，并且可实现在不同云平台上的 Quorum 节点加入到阿里云 BaaS 的区块链网络中，构建多云业务联盟。

另一类需求，是希望使用金融级别的，具备核心技术领先性，以及高并发、高性能的技术。那对于这类需求，我们和兄弟团队蚂蚁区块链一起合作。它是从底层开始自研，具备高性能并行共识，高达每秒 25,000 TPS 的处理能力，以及在 2017 年获得全球专利排名第一的专利技术优势。

因此我们是通过这种三引擎的方式来满足不同类型的用户需求。

其实区块链服务的内容有很多，业内各家厂商也推出了各种优秀的功能。我们也一直在思考，什么才是企业用户最为看重、最为需要的东西。因此我们总结出了这三个核心方面：安全性、稳定性、易用性。这也是我们在打造区块链服务过程中始终在坚持的重点方向。下面我将分享一下这在三个方面企业会遇到的问题和挑战，以及我们的一些解决思路，希望能起到抛砖引玉的作用。

首先是最为重要的安全方面。

区块链业务系统所面临的安全挑战和风险其实要远远超过我们的想象。但是在我此前参加过的很多会议和技术交流，对区块链安全风险分析和防范的主要集中在公有链领域。那今天我们将从联盟链类型谈谈企业可能面临的安全风险。

从攻击方面，会存在木马、病毒、恶意代码、DDoS 攻击等风险；

从软硬件漏洞方面，会在硬件、操作系统、容器镜像等方面存在漏洞风险；

从身份账号授权方面，会存在账号被盗、身份验证或权限控制系统存在漏洞的风险；

从区块链技术本身，会存在密钥被窃取或滥用、智能合约存在漏洞、利用共识算法发起恶意交易攻击等风险；

从审计合规方面，会存在审计日志缺失、业务违反政府法规、人为误操作等风险。

安全是企业的生命线，但业务企业自身的力量是有限的，并且仅凭区块链技术和开源技术本身也无法完全应对和解决那么多方面的风险和挑战。

那接下来我们试着就如何以区块链服务为中心去应对这些风险的提供一些思路给各位参考。

首先，我们来分析一下以 Hyperledger Fabric 为代表的联盟链安全治理体系的特点。

它在企业之间是一套基于策略 Policy 的、企业对等的治理体系；在每个企业组织内部，是基于 PKI 机制的治理模式，大家知道 PKI 机制最核心的部分是公钥、私钥等密钥，所以核心问题就是对密钥的保护。因为一旦密钥被窃取，影响的不仅是一家企业内部的业务安全，在联盟链中可能会进一步影响多家参与企业的业务数据安全。

在这个问题上，我们采用了芯片级安全防护密钥的思路。

其基本原理是：

• Fabric 密钥的生成、签名过程均在 CPU 内的安全计算单元 Enclave 中进行。

• 密钥的保存是将被加密后的 Fabric 密钥、以及用来加密 Fabric 密钥的密钥也进行加密，进行安全的封存。

• 在涉及到多节点的场景，Fabric 密钥本身不做分发，而是将密钥的密钥进行分发、并结合远程证明 Remote Attestation 等手段来实现多节点的协同。

此外，对密钥的芯片级安全防护还会结合后面要介绍的多维度安全隔离，来形成一个更加完备的安全体系。

采用芯片级安全防护这种方式的最大好处在于，即使宿主机被黑客或恶意人员攻破并获得了 root 权限，也无法窥探或窃取到上面的密钥。

接下来，如果我们需要扩展 Fabric 的加密算法，去更好地保护交易数据的安全，那么可以通过 Fabric 的 BCCSP，Blockchain Cryptographic Service Provider 的机制来添加新的加密算法。

但这里存在的问题是，今天的 Fabric BCCSP 的 plugin 机制实现还不够完善，它的依赖较多，仍未 100%实现插件化。而我们在 BaaS 开发过程中，对 BCCSP plugin 方面的代码进行了完善，使得增强后的 BCCSP 可以跟依赖解耦，实现完全的插件化和 API 化。

在这个基础上，我们得以高效地实现了对 SGX 技术的支持，以及对国密算法的支持。

这里阿里云的区块链服务是全球第一款实现了将 Intel SGX 技术与 Hyperledger Fabric 结合的区块链产品。

在国密算法的实现方面，业界主流的选择有：OpenSSL 1.1.1 开始全面支持 SM2/SM3/SM4, 以及同济贡献的国密算法开源实现。

在区块链业务系统面临的各类攻击威胁中，DDoS 攻击是最具威胁性的一类。这是因为，诸如病毒、木马、黑客攻击等都需要很高的技术以及付出不小的代价，突破重重安全保障才能进入到系统内部发起攻击。但是 DDoS 是在外部便可以对服务端口发起攻击，因此是更为普遍的威胁。

对这类攻击的防护思路包含这两点，首先光靠企业单枪匹马是不行的，因为 DDoS 的攻击流量都会非常巨大，这时候需要利用云厂商提供的高达百 GB 级别的抗 DDoS 攻击能力来抵御。

第二点是，在区块链服务对外暴露的服务端口，例如 peer, orderer，或者更上层的业务服务，我们利用了阿里云 SLB 的服务负载均衡能力的同时，可以借助其自定义黑名单、白名单的功能，来实现对服务访问来源的过滤，进一步增强对 DDoS 攻击的防御能力。

当然还有其他的攻击防护思路，这里没有全列上，比如将服务限定在一个或多个 VPC 企业专网内开放，也可以控制相应的 DDoS 风险。

IT 硬件和软件都是人设计和实现的，因此漏洞是无法避免的，这是一个普遍的事实。我们主要思路是如何去预防、发现和及时地修复漏洞。这里的方式主要包括：

无论是区块链本身还是业务应用，如果用到容器的话，那么其 docker image 均有存在漏洞的风险。这里我们可以使用例如阿里云容器镜像服务自带的 docker image 漏洞扫描的功能，这样可以避免容器镜像本身对我们成为一个黑盒，无法知晓里面的漏洞风险。

此外，对于虚拟机、云服务器本身使用的操作系统镜像，如果有操作系统层面的漏洞的话，需要第一时间集成操作系统厂商的官方补丁，这方面云平台做得是比较及时和规范的。

在硬件层面，比如 CPU、存储设备等，如果是业务企业自己去紧盯硬件厂商的最新漏洞补丁修复，去更换硬件或升级固件的话，操作上会比较困难。因此更高效低成本的做法，是借助云厂商跟硬件厂商的密切合作关系，在云平台上自动实现了硬件和固件的漏洞修复。例如阿里云和 Intel 等硬件厂商建立了战略合作关系，对于一些 CPU 漏洞我们均可以得到很早的预警和进行修复方案的实施。

在这一页以及后面的另一页，我将回答一下经常被问到的问题，就是区块链在云平台难道不会中心化吗？区块链用户之间到底是怎样隔离的？

实际上，在阿里云的区块链实践中，不同云账号，也就是不同的企业之间，是具有如下的多维度安全隔离机制的。

首先，各企业的组织是通过 VPC 内的网络安全组实现网络层隔离。

接下来，各个企业组织均有完全独立的服务访问 SLB，智能合约运行环境及 chaincode container，独立的区块链组织内的节点，无论是 peer,orderer, CA 等等；每个企业组织独立的 CA 服务，提供独立的根证书和证书颁发和管理服务；独立的 Kubernete 集群及其底层账号独享的云服务器、账本数据存储等资源。

因此，任何两个用户之间，都可以实现在这些维度上的完全隔离和独立。

因为我们关注的主要是联盟链类型，所以参与者身份是需要经过许可的。那这里我们将谈谈如何对账号体系进行安全防护。

首先，使用区块链服务的用户账号都必须是实名认证的，这也能满足国家在监管方面的一些要求。进一步的，考虑到类似账号冒名使用的风险，更高级的认证方式还包括实人认证，就是结合人脸识别等手段来证明用户不仅使用了正确的用户名和密码，而且确实是其本人，不过这只是备选手段。

对企业来说需要的不止是一个主账号，还需要为不同部门或团队开通多个子账号，因此这里我们在区块链服务中提供了基于策略的子账号操作权限管理以满足企业需求。

区块链应用程序绑定使用的一般是组织的 user 类型账号密码或证书，这里万一在程序端发生了丢失或窃取事件，我们需要为用户提供重置密码或者撤销证书的能力。

此外，我们基于了 Fabric CA 的多级证书体系，通过二级 CA 来隔离背书节点和普通用户，实现证书风险在不同角色之间的隔离。

大家应该还记得证券行业涉及几十亿资金的乌龙指事件，以及 IT 圈里的诸如“rm -rf /”跑路指南等段子，但对区块链业务系统运维来说，这些风险都是实实在在的，因为一个误操作，很可能就会删除或影响一家企业甚至多家企业的数据和业务的安全。而一旦发生事故，如果没有操作记录的话，也完全无法进行审计和追责。

因此，我们认为，在区块链服务的基本要求中，需要包含对关键操作的风控措施，比如我即使要重置一个组织用户的密码，也要通过账号绑定手机的风控短信验证，要不然一旦密码被误操作重置了，造成的就是业务应用无法连接、导致业务中断的重大事故。

此外，对于区块链服务任何主子账号的操作，都会记录审计日志，记录具体操作的方法和时间、调用 ID 等信息，以便实现审计合规的目的。

上面分享了在安全方面的一些风险应对思路。接下来谈谈稳定性方面的一些实践经验。

其实稳定性方面我们做了大量的工作，包括系统全流程的高可用设计、管控和升级流程的稳定性提升等等，但这些都属于内功类型的修炼，或者说就像冰山一角一样，很多工作是水下看不见的部分。并且由于对外披露的限制，我们这里就不能分享太多。但这里我们可以重点介绍一下对业务非常关键的数据存储的问题。

在今年 4 月 QCon 大会上，我们通过对 Fabric 源代码的分析和容量测试，总结和分享了如左图所示的基于 Fabric 的数据存储容量分析及估算公式，这些内容也可以在 InfoQ 的文章中找到。当时这些知识对大家更好地了解 Fabric 工作机制、以及在我们当时的私有云客户项目落地过程中起到了一定的作用。

而到了区块链服务，我们进一步简化了数据存储的管理，就是随着账本存储等业务数据的增长，底层存储是无需管理员或程序的任何操作便能自动扩容。这一点对业务稳定性来说至关重要，因为这样业务应用完全无需中断，甚至不会感知到任何存储扩容的发生。

但话说回来，因为区块链仍是持续增长的，我们还是需要在区块链账本存储上的 Pruning 修剪或者 Archiving 归档的能力，去清除不再需要的账本数据。其实 Fabric 社区在 post-v1 的设计文档中也提到了 pruning 的功能设计，但个人认为，仅仅清理掉账本里的 invalid transactions 是远远不够的。因为在我们的客户项目实践中，即使是 valid 的 transaction 也是几十万、上百万条的非常可观的规模，因此在这方面仍需有进一步技术突破。

第三部分我将分享在易用性方面的一些实践经验和设计思路，这里也可能会包含一点安全方面的内容。

在设计区块链服务的交互模型过程中，我们遇到了以下几个方面的挑战。

首先，大多数区块链技术实际上都比较复杂、概念很多；其次，传统上大多数软件和服务都只是解决单个企业内部的问题，但区块链尤其联盟链涉及到多家企业之间的协作和治理流程，往往会非常复杂；此外，我们遇到的企业客户在对区块链技术的掌握程度也是差异巨大，有一点也不了解的，也有精通 Fabric 工作机制和 chaincode 及 SDK 开发的。

针对这些挑战，我们也是花费了很大精力多次修改设计、也推翻重来过。目前我们采取以下几种对策。

一是尽量简化和统一概念模型，并尽量隐藏底层技术细节，我们希望在多种区块链技术之间包括 Fabric 和蚂蚁等，让概念能尽量接近；同时让用户不必关心底层节点、资源、集群、配置、等等，而是更多地去关心业务本身。

二是以用户和任务为中心，所以你可以看到左侧导航栏里会很简洁，而不是在我们早期版本里一堆技术术语的列表，让用户不知所云、或不清楚它们之间的关系。

三是提供快速模式，为占大多数的初级用户简化操作。在区块链服务控制台首页中的第一个大 button 便是快速模式入口。

客户经常会问，我应该怎样使用区块链服务去开展业务？我们总结下来大致有以下两种模式，而且经常是由业务模式来决定，而不是技术来决定的。

第一种，这项业务如果是核心企业发起或主导的，其他业务参与方是从属或跟随核心企业的话，那么，核心企业可以通过快速模式建立起自己管理的联盟以及自身的业务组织；同时业务参与方也创建自己的业务组织；然后核心企业邀请各业务参与方加入联盟。

第二种，多家业务参与方委托一家运营企业仅作联盟运营，但运营企业不参与实际业务（也可以参与部分业务）。这样便可以通过右边的常规模式来创建和邀请。

无论哪种模式，未来都可以动态添加更多的业务参与方加入联盟和业务通道之中。

下面这页讲的是从易用性和安全性两个方面的考虑，同时也进一步回答了区块链上云是否会中心化的疑问。

在我们的区块链服务设计之初，我们便定位满足客户跨 region 部署联盟链的场景需求。这背后的需求是，企业可以实现区块链业务就近部署，能为企业自己的本地市场客户提供更好的服务质量保证；同时在业务联盟中，各家企业实现了对自己组织真正独立的治理，而不用担心被集中分配在一个机房甚至一台服务器上。

此外，跨 region 部署的联盟链，具备最高级别的隔离性，因为包含了物理隔离、地域隔离、网络 VPC 隔离。

因此，在实际业务流程中，A 企业可以用自己的云账号在北京 region 建立联盟，而 B 企业和 C 企业分别在杭州 region、深圳 region 用自己的账号创建各自的业务组织和节点，然后通过邀请、在逻辑关系上加入到 A 的联盟之中。实现了一个跨 region 的联盟链建立。

随着各家企业业务的全球化发展需求，联盟链还可能有全球化部署的需求，这方面可以借助云厂商的全球化能力来实现。这里展示的是目前阿里云遍布全球的数据中心。

此外，还有一些企业客户希望组建起混合云的联盟链，即在公有云、私有云分别都有区块链节点和应用，然后可以互联互通形成一个联盟链。我们不仅会支持这种部署模式，而且会进一步提供这种场景下的安全的联盟链网络方案去解决企业的网络安全需求。

相信这两天大家从 BCCon 大会上看到了区块链在许多领域的成功应用。在区块链服务上线之后我们也正在和几家企业客户、合作伙伴在上面这些领域共同落地区块链服务以及区块链的业务解决方案。这里由于时间关系就不一一展开了。

另一方面，无论是阿里云、还是阿里集团，其能力都是有限的，因此我们诚挚欢迎有行业经验、或者有技术实力的企业进来共同合作，一起推动区块链在各个行业的业务创新。

最后，我想说的是，虽然我们在实践中尝试解决了许多高优先级的挑战和问题，但实际上在区块链服务落地以及区块链技术本身仍面临着不少技术挑战，在这里简单列举了一些。

其中跟企业的业务应用关系非常紧密、并且经常容易被忽视的问题有这几个。

一个业务应用的分布式事务处理。例如企业的业务流程是从前端获得用户的请求，经过业务应用的处理、以及 insert 或 update 到业务数据库之后，再去调用区块链服务将交易数据上链。但由于数据写到链上的过程往往是异步的，如果最终数据上链实际上是失败的，但是应用没有考虑到或者处理好这种情况，那么就会带来全局事务的不一致性。

第二个是海量交易数据处理。刚才我们提到了在落地项目中遇到了几十万、上百万的交易数据，这种大规模的数据处理对区块链技术来说是很大的挑战，例如频繁查询链上某个 key 的所有的大量 transaction history，其性能就会很成问题。

第三个是真实企业环境下业务系统端到端性能调优。其实区块链技术本身的性能，根据我们从大量企业客户的业务场景的经验、以及业内如矩阵元分享过的，通过大量金融项目的实践，区块链本身几百 TPS 的性能已经能满足绝大多数场景的需求。但问题是，在一个真实的企业环境中，整个业务系统端到端的性能可以达到多少。这个是遵循木桶原理，即最短板决定了整体性能。即使你的区块链有几千 TPS 的能力，但是如果流程中的存储 IOPS 不够高、或者网络很慢、或者应用没有并发能力、或者数据库读写很慢，都会让整体性能极大下降。这里就需要更成熟的端到端调优的方法论、更好的工具、以及更专业的人才去实现。

上面这几个问题是需要企业的业务应用开发团队的高度重视、以及和区块链服务的提供商共同设计解决方案。

以下还有很多涉及到区块链技术本身、以及服务平台等等方面的典型技术挑战。这些都需要与各位同仁一起共同去探索和推动解决的。

以上便是我今天分享的全部内容。感谢大家的聆听！谢谢！

作者介绍：余珊，阿里花名御功，目前在阿里云容器服务部门担任高级技术专家，负责容器技术、区块链产品和解决方案的研发工作。本科和硕士毕业于中国科技大学。在 IBM 中国开发中心的十年工作期间带领了 IBM MQ、Kubernetes、微服务、Hyperledger Fabric 等相关产品和技术的研发工作，并且积累了丰富的银行、金融、政府、零售、制造、医疗、能源等行业的企业客户项目经验。

相关文章：

华为云区块链服务技术决策和落地实践

京东分布式BaaS的设计与实践