如何看待蚂蚁区块链技术入选国际顶会？ 第1页

       目录（八千字长文）： 1.背景  2.狂欢过后，联盟链探索的这一年 3.区块链中只有链上计算才能保证可信吗？ 4.区块链中实用的TEE存在什么问题？换而言之，蚂蚁金服这次做了什么？     

背景：
1. ACM SIGMOD^[1]是计算机数据库领域的三大顶级会议之一，平均录取率大约仅为15%-17%，同为另外两大数据库顶级会议的VLDB和ICDE的录取率约为18%-20%，从录取率可以看出被ACM SIGMOD录取并发表的难度之大。
2. 我想SIGMOD的地位不需要过多评价，任何一所大学会议推荐列表都会把它放在数据库和数据挖掘领域首位。
3. 蚂蚁金服将在今年6月份美国波特兰召开的SIGMOD 20'^[1]峰会上宣讲一篇名为《Confidentiality Support over Financial Grade Consortium Blockchain》的论文。区块链并不是机器学习，IEEE的区块链协会至今都没有期刊。顶级会议对待这类论文也普遍非常谨慎，中国科技公司的区块链论文在顶会发表这算得上是个大新闻。
4. 为了解读这个新闻，我将尽力在下文向大家介绍区块链技术的发展现状、存在问题，以及蚂蚁金服为解决这些问题所作出的努力、成绩和这项工作本身。

相信很多人对区块链的回忆还停滞在戏剧化的2018年，从年初的一夜暴富、盛世狂欢到年终的神话破灭，普通用户可以直接参与的公链在互联网「风口」享尽荣华，也遭遇了滑铁卢之后的一地鸡毛。

出于热度冷却和对应用场景担忧的原因，公链渐渐退出公众视野。但正规军和学院派却好像从满地灰烬中找到了一些较为合适的应用场景，也带来了我们今天新闻的焦点问题：

阿里近期到底在区块链上做了什么？以及为什么要这样做？

正文开始之前，我想需要通过几个业内共识来纠正一些过度宣传带来的偏见。请特别注意我以下引号中的措辞：

1. 区块链可以构建 「难以篡改的分布式数据库」，在「参与方相互信任有限」的情况下，通过担保各个参与方「信息一致」和「链上计算可验证」来加深参与各方的互信程度。
2. 区块链其实是在通过技术保障一种「新型」的多方互信。说「新型」是因为，在传统情况下我们只能通过法律、道德或者担保来获得类似的信用保障，以上操作效率很低，很难自动化进行。

上述说法我用了一些术语，这并不是故弄玄虚，只是为了准确表述。如果各位觉得上述说法晦涩难懂，那么没关系，结论可以足够通俗：

• 区块链是较为封闭的系统，它提供的信任在数字世界中有边界，有条件，也有上限。需要一些其他手段作为补充才能信任链外世界的数据。同时，区块链上智能合约只能顺序执行，难以保证双方履约，同样也不保证完美。

有个粗糙但经典的例子，假如A和B通过智能合约设定了定时交易，如果A在约定时刻余额不足，那么区块链也很难做更多惩罚。

• 区块链能担保封闭世界里的储存过程和计算过程可被参与者信任，担保的方式是参与者达成共识。形象的说，就是任何心存怀疑的参与者都能够自己动手验证结果，并提出反对。

我想这是很简单的道理，不信的话自己动手算一算就好了。

• 传统互联网中不存在高效的多方互信机制。真实世界的多方协商过程中，参与方越多，沟通和验证难度越大，确定的条款越细节，执行和验证的难度越大。

只有先理解区块链的上述优势和局限，我才能够在接下来的回答中向大家介绍区块链可能在什么场景下找到自己的归属。实际上，目前比较普遍的观点是，区块链可以作为传统互联网的一种补充，在信用机制不完善的领域建立（相比多次协商）更高效的、具体到代码的 多方互信。

如果真实世界里的信用体系已经完备且成本低廉，那么以区块链技术提供的多方互信其实并非必要。尤其在传统金融领域，区块链可能只能充当一种锦上添花的信息化工具。于是有了个所有区块链从业者都在苦苦思考的问题：

有没有信用体系还没有完整建立，信用成本高昂的场景呢？

1. 狂欢过后，联盟链探索的这一年

技术本身并无善恶，问题在于适合技术的场景是什么？联盟链为了实现这些场景，又面临哪些技术问题？
本节关键词：落地场景、模块化、可定制和机密性

或许谁都想不到，公众热潮退去后的2019年，正规军和学院派对区块链技术的兴趣又创新高。在 2019 年，有超过 13700 篇学术论文和谷歌学者的文章提到了区块链和比特币协议，其中包括MIT、哈佛、斯坦福和牛津等常春藤高校，和各国央行及金融机构。在美国电气工程师协会，关键字「blockchain」的搜索趋势常年占据IEEExplore数据库趋势榜前十。2019年，在全球排名前50的大学中，超过56%都开设了区块链课程。

繁华散去，技术回归带来的影响不只是技术研究热度高涨，各类头部公司也纷纷建立各自的区块链研究部门，试图在区块链领域找到落地场景，在细分行业建立专利壁垒，参与行业标准来竞争领导地位。

截止2019年3月，中国第一季度区块链的专利数量比2018年增长8倍，截至 2019 年底，全球现有区块链专利分布上，中国专利占比达到 63%，遥遥领先于其他国家和地区。

另外，IPRdaily 与 IncoPat 的统计报告也显示，截止 2019 上半年，全球区块链技术发明专利申请数量排名前 10 名的企业包括阿里巴巴、中国平安、NChain 等。其中阿里巴巴连续三年位居榜首，专利主要来自蚂蚁金服的区块链团队。

18年后到19年初那会儿，一时之间仿佛所有互联网公司都在布局联盟链，当时各个区块链技术群都充斥着来自五湖四海、四面八方的暗探，进群发红包提问，github勾搭，线下约见畅聊这都是基本操作，更有甚者，昨天还在说打死不走的同事，第二天突然发现桌子清空人影不再，也是屡见不鲜。

我把这些当时积极投入区块链的公司分为两种：自带场景的公司和区块链解决方案提供商。前者以阿里的蚂蚁区块链BaaS^[2]平台为代表，包括腾讯、百度等，在服务自身业务的基础上向其他行业提供解决方案；后者以趣链、井通、云象和布比区块链为代表，通过和其它行业合作升级、区块链化为主。

你看，从我的划分原则就能看出来，当时各家领导的脑海中肯定只有四个字。

落地场景

一年之后，随着蚂蚁金服为代表的国内外区块链公司和政府部门的积极探索，也交出了一份还算不错的答卷。事实上，现代社会依然有很多信用机制不完善的领域需要区块链，以此建立高效的多方互信。其中包括：

a) 跨境结算：

传统的跨境结算需要经过visa等国际结算机构，经过汇出行、中间银行、代理银行、收款行等多个机构，而众所周知，国际贸易和国际金融存在不小的风险，不同国家多机构的互信体系很难建立，而且跨境结算需要涉及记账、 清算、对账等多个环节，每个中间部门均需要人工复验，流程繁琐复杂，因此现有的结算机制速度慢、成本高且具有很大的操作风险。

Visa、中国人民银行都纷纷推出了自己的国际区块链结算平台，利用法定货币和区块链数字资产的转换，进行支付转账，同时追溯查询洗钱行为。蚂蚁金服也已经在港版支付宝中上线了自己的区块链跨境汇款功能，可以做到安全透明、实时到账，这在小额国际结算领域相当不易。

b) 供应链金融：

供应链金融是所有区块链公司一致看好的领域。众所周知，在供应链的上下游中往往存在具有统治地位的龙头企业，同时存在多级供应商。一般来说，竞争力较强、规模较大的龙头企业往往会在交货、价格、账期等条件上对供应链上的配套企业要求苛刻，而这些上下游配套企业往往又是中小型企业，本身信用不强，难以依靠自身信用从银行融资。虽然龙头企业可以通过「应收账款」等票据方式提供担保，但是这种票据往往无法只能担保直接合同方，也就是一级供应商。龙头企业难以通过二级合同继续向二级供应商提供担保，信任无法穿透和流转。

这样就形成了一个典型的信用机制不完善的多方互信问题：

对银行来说，龙头企业、二级供应商之间存在信息不对称；对龙头企业来说，只能向一级供应商提供信任，而且信任无法在多方传递，二级、三级供应商无法自证清白，结算、贷款效率低下。

区块链可以提供简单有效的方式，把供应链中的资金流、物流、信息流统一，确保参与各方之间的信息对称和信任传递，供应链上的小微企业拿着上游核心企业的「欠条」，也就是「应收凭证」，可以直接向合作银行申请贷款。

供应链金融是个非常具有社会价值的区块链应用场景。据统计，过去传统的供应链金融服务大约仅能为15%的供应链上的供应商们（中小微企业）提供融资服务，而采用区块链技术以后，85%的供应商们都能享受融资便利。区块链让小微企业的融资时间成本从3个月缩短到1秒。

疫情期间，蚂蚁区块链上的核心企业1919酒类直供^[3]，已经通过这种模式为供应链上的小微企业提供了接近1亿的资金流量。为经济回暖「报春」。

除此之外，联盟链在医疗行业的隐私保护、保险行业的数据共享已经有了多家成功案例，限于篇幅这里不能多做介绍。

让我们把目光从应用转回技术本身，为这次的论文新闻继续铺垫一些必要的背景。

为了落地，联盟链的技术问题？

即使已经存在很多开源区块链代码可供参考，也找到了比较合适的应用场景，联盟链落地这条路也依然没有想象中那么一帆风顺。

众所周知，区块链在落地场景上面临的最大问题是性能瓶颈，这个问题在以公链为基础的解决方案上尤其严重。比特币网络的每秒最大交易数（TPS）是7 ^[4]左右，当然在不损失安全性的情况下，它可以通过参数调整扩展到25 TPS^[5]，而Paypal网络的平均交易量大约维持在193 TPS，全球结算网络VISA可以在服务5千万用户基础上支持高达 65,000 TPS^[6]。

性能低下在某些看重安全性的公链中可以接受，但是在直接对接业务的联盟链中不能。

我们在之前已经论述过，对传统互联网公司来说，区块链的主要任务是「提升」多方互信水平。如果这种「信任提升改造」影响到公司的核心业务性能，那么大多公司会把保证用户体验放在首位。这就是联盟链和公链的第一个不同：公链需要考虑严格的安全性来保障用户资产，联盟链中安全性和性能的优先级要根据业务调整。具体来说，如果业务要求高吞吐量，那么联盟链需要在保证基本信用水平的情况下尽量提升性能，反之亦然。

同时，因为直接面向业务而不是面向普通用户，联盟链中各个用户存在上下级关系，它们的权限等级也因此不同。权限管理和机密性^[7]（论文中题目的confidentiality）就成为了联盟链中独有的概念，相对而言，公链中普遍称此为用户隐私 (Privacy)，这是联盟链和公链的第二个不同。

也正是因为这两种不同，在针对业务定制联盟链时，需要引入很多不同的技术来满足特定业务的强制要求，但是这些技术本身有可能是相会冲突的。比如我们在试图增加链上存储容量和吞吐量时，可能会考虑提高区块大小和降低区块间隔，但是这样做可能降低安全性；如果我们考虑采用多链结构，却会增加数据查询复杂度，需要考虑优化查询时的路由寻址。因此，在规划联盟链结构时，为了尽量满足不同场景的复用要求，一个非常重要的设计原则就是「模块化」，也就是技术之间尽量降低耦合程度。

理解了联盟链中「模块化」的设计思路，才能理解为什么蚂蚁区块链需要设计一个由加密传输、加密存储、秘钥管理和可信执行环境（TEE）构成的「端到端」、「全生命周期」机密性保护机制，而不是分拆开来加密 or 执行。

这个机制被官方称为蚂蚁区块链硬件隐私保护技术，下文为了简写我将以它论文中的英文缩写代替：confidentiality in financial grade blockchain（CONFIDE）。

看到这里，我估计很多同学会感觉到奇怪，为什么CONFIDE要强调它是一个硬件隐私保护技术？以及我在上文中提到的可信计算环境，即TEE到底是什么？

我将在下一部分简单介绍。

2. 区块链中只有链上计算才能保证可信吗？

又名，对联盟链中智能合约有效性和可信程度的思考。 本节关键词：隐私性、可信计算环境（TEE）、远程认证

我在上文中提到过，区块链通过智能合约和共识机制来担保链内计算过程是可信的。这里智能合约实质上是一个可编程的状态机，我们举个不很严谨的例子来理解智能合约的整个计算过程：

假如小明到了一个酒店，需要通过酒店提供的智能合约入住，智能合约的使用过程分三步：
1. 小明发送自身身份信息到智能合约，2.智能合约和链上存储数据比对，3.智能合约给小明开房并提示小明可以入住。那么要完成整个流程，就至少需要3个区块时间才能把状态1变成状态3。

那么很明显，在这个例子里，区块链智能合约的性能瓶颈就变成了出块速度，而在大多数区块链中，区块时间是固定不变的，有的共识协议甚至需要把它设置的非常长（比如PoW系列共识）。那么我们有没有可能把部分业务处理流程放在区块链外，只在链上储存业务初始化状态（状态1）和最终状态（状态3），并通过保证链下计算的可信度和链上数据可验证来获得近似的安全性呢？

答案是可以，这种做法被称作区块链的Layer-2扩展，也有人称之为业务逻辑和共识逻辑分离^[8]，或者是业务逻辑off-chain。所谓的区块链 Layer-2扩展的关键特征是，计算部分被移动至链下，以实现隐私或节省计算资源的目的。很明显，业务逻辑越复杂，这种做法给区块链带来的速度提升就越明显。

Layer-2扩展带来的另一个好处是，如果我们在区块链中储存加密过的初始状态（状态1）和最终状态（状态3）数据，这种方案就能同时完成高效的隐私保护。此时，蚂蚁金服论文里提到的技术方案就出现了：

基于可信计算环境（TEE）的加密计算协议。

TEE其实是一个很广泛的概念，它可以保证数据和代码在其中执行是足够安全的，并能通过密码学手段保证其中代码和数据的机密性和完整性。在区块链中应用TEE，基本都是通过在CPU中隔离出一块「安全区域」来实现，对于Intel CPU，这块安全区域被称为Enclave（飞地）。

区块链的部分操作将会被封装在Enclave中，在这个参与方节点中，Enclave可以保护这部分代码和数据不受任何未授权的软件攻击和修改。Enclave也可以向其他参与方提供自己数据和计算完整性证明（这个非常重要）。

换句话说，TEE可以提供一个隔离的执行环境，能提供包含隔离执行、可信应用的完整性、可信数据的机密性、安全存储在内的各种安全特征。一旦区块链的部分合约在Enclave中执行，那么即便操作系统被攻破，也完全无法影响这些代码和数据， Enclave只信任自己和CPU。基于此，区块链就可以就放松对共识计算的要求，改为通过Intel的提供的证书来验证数据完整，间接验证合约结果的真实性。

我们依然可以采用上文提到的小明的例子来介绍TEE可以带给我们什么：

假如小明又一次来到了采用TEE+区块链的酒店，需要通过酒店提供的智能合约入住，智能合约的使用过程依然会被分四步：
1. 小明发送自身身份信息到智能合约，这时候自身信息并非明文，而是一长串的加密数据。2. 区块链随机选择节点，在可信计算环境（TEE）中对比接收到的加密数据和链上存储的加密数据，确认入住身份。3. 区块链会比对公安系统的要犯数据库，4.智能合约给小明开房并提示小明可以入住。

我们在这个例子中完成了4个区块链内操作，却只需要花费2个区块链时间（状态1和状态4），同时链上的储存和传输的数据全部是加密过的数据，明文数据全部在TEE中计算，除了CPU以外没人能看到，也就没有暴露用户隐私。

到了这里可能会有同学疑问，如果不采用TEE，传统区块链就不能保证用户隐私吗？

并不是，只是付出的代价不同。区块链的隐私保护方案有很多种，此前的方案类似同态加密、零知识证明、环签名或者分布式秘钥都需要区块链软件中实现，而且这些几乎都需要或多或少的牺牲性能来保证数据隐私性。TEE本质上是通过对区块链参与方增加硬件约束（需要支持TEE的CPU），来换取性能和隐私保障。因此相比公链来说，TEE也更适合联盟链这种带有一定准入门槛的区块链体系。

当然TEE在区块链中的应用很新颖也很前沿，正在面临很多问题。这也是蚂蚁金服在论文里突出的贡献，我将在下一节中简要介绍。

3. 区块链中实用的TEE存在什么问题？换而言之，蚂蚁金服这次做了什么？

关键词：去耦合、端到端、全生命周期

基于TEE的区块链隐私保护在去年才开始兴起，微软^[9]和超级账本^[10]和伯克利、康奈尔等大学的研究Ekiden中都曾经研究过相应方案^[11]。

• 微软希望把区块链的所有关键组件(PRFT共识，链上的内存数据库和用以交互的RPC服务）都加载在TEE环境中。这种想法当然很棒，只是没有考虑太多工程和实现问题，而且模块耦合度过高，对不同业务的需求匹配较为困难，在大量计算过程中会对CPU本身会造成极大压力。
• Ekiden则试图把所有智能合约计算都放在TEE里，这同样只适合小型的智能合约。比如在Intel SGX ( Intel 的TEE解决方案）中，供应链金融一个月的合约计算量就可能超过SGX物理上限，区块链本身就会面临停工危险。

因此，在商用场景下需要进一步去耦合、同时需要考虑业务的易用性，能够让客户在最开始的合约调用时就能够确定哪部分属于隐私交易、需要TEE，哪部分属于明文交易、可以使用正常合约。

也就是需要建立端到端、全业务生命周期的设计方案。

按照端到端、全业务生命周期的设计思路，数据在区块链中流转时需要经过节点间数据库同步、智能合约里要考虑基于TEE的隐私计算、密文储存等等，在这些过程中都存在隐私暴露风险，需要分段规划设计相应的隐私保护方案。

具体来说，需要四种不同的秘钥体系（其中部分可复用），分别用于：

• 1)TEE的签注秘钥、
• 2)传输过程中的加解密、
• 3)存储数据的接入控制、
• 4)用户控制的CONFIDE秘钥

在进入不同流程时，上述秘钥存在交互流程，这些流程比较复杂而且数量繁多。为了用户体验考虑，上述所有的秘钥协商和管理过程最好对用户不可见。

所以说：

蚂蚁区块链硬件隐私保护技术核心由数据加密传输协议、数据加密存储协议、远程认证及密钥协商协议和一个基于可信执行环境（TEE）的智能合约引擎组成。

1. 数据加密传输协议：

确保交易数据端到端的隐私安全，交易数据从客户端加密发出后，仅在需要的时候载入TEE环境进行解密运算。

简单说就是在数据传输过程中，最安全加密方式是一次一密，因此在每次数据传输过程中，需要尽量针对每次传输都设置不同的秘钥，同时可能利用某些秘钥分发和生成机制来更有效的管理这些一次秘钥。

2.数据加密存储协议：

充分考虑区块链数据持久化的特性，建立了完善的数据安全加密和数据完整性保护机制，确保数据持久化安全。

如果数据存储在链上时，只有授权过的用户才可以访问，而且这些访问很可能是智能合约发起，因此储存数据的授权需要与智能合约的逻辑相结合。

3. 远程认证及密钥协商协议：

确保了区块链节点上在TEE内运行的程序的可认证性，同时各节点TEE内协商的密钥对外不可见，确保节点TEE运行时数据安全。

正如我之前所说，对于一个端到端的系统，用户需要知道的最好只是自己的公私钥，所以在保证安全性的的前提下，各个节点和各个加密、储存、TEE调用和认证过程中所需要的秘钥协商最好对用户不可见。

4. 智能合约处理引擎：

运行在TEE内部的智能合约处理引擎，可以高效处理智能合约数据，在保证数据隐私的情况下，最大限度的保留的性能和通用性。

为了解释这一点，我再次祭出上图^[12]：

在 TEE 合约链中，交易和合约都分为隐私交易/合约和明文交易/合约。明文交易即无需隐私保护的交易，其执行过程与现有明文逻辑一致；隐私交易/合约是利用密码学技术进行保护的交易，交易/合约内容只有在 TEE 内才安全可见，其执行过程中产生的全局状态数据以及交易回执均采用密码学技术进行加密保护。

从系统设计角度，这其中的关键点是如何正确识别、分发隐私交易和明文交易。

蚂蚁区块链的设计思路是增加了交易分发和交易存储这个阶段，把待处理的交易放入缓存池中识别、预处理，同时扩展智能合约的隐私标识。如果该交易存在隐私标识，那么转给隐私合约引擎执行，如果该交易不存在隐私标识，那么交给正常智能合约引擎，这样可以在保证隐私的情况下尽量不影响其他合约的性能和速度。（个人猜测）

总结：目前区块链商业公司只有趣链和微软有在考虑基于TEE的区块链解决方案，但是都离商用较远，在此基础上，这确实可以被称作首个基于TEE的可商用的硬件区块链解决方案。蚂蚁金服声称已经在此基础上运行了若干金融业务，日均交易达上千万。

众所周知，虽然目前的区块链学术研究很多，但是顶级会议/期刊对这类追热点的研究方向普遍非常谨慎，蚂蚁金服能够在此类顶会上发表论文，据描述是「中国科技公司区块链原创技术在CCF国际A类学术会议的第一篇独立论文」，这也代表了学术界对这项工作完成度和创新性的认可，希望能有更多更优秀到的研究出现在世界舞台。

PS。

结尾来个对CONFIDE的测试彩蛋。

在Synthetic workload的模块测试里，不论在有没有TEE的情况下，CONFIDE的虚拟机均大幅度领先EVM（ETH的虚拟机），这也说明了蚂蚁金服对CONFIDE做出的优化之多。

参考

1. ^ ^{a b} https://sigmod2020.org/
2. ^蚂蚁区块链 https://tech.antfin.com/blockchain
3. ^联合国点赞数字金融抗疫案例，蚂蚁金服区块链位列其中 http://www.xinhuanet.com/fortune/2020-03/25/c_1125765558.htm
4. ^ “Global bitcoin nodes distribution,” Bitnodes. [Online]. Available: https://bitnodes.earn.com/
5. ^ K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, E. G. Sirer et al., “On scaling decentralized blockchains,” in International Conference on Financial Cryptography and Data Security. Springer, 2016, pp. 106–125.
6. ^ “VISA fact sheet,” VISA Inc. [Online]. Available: https://usa.visa.com/dam/VCOM/download/corporate/media/ visanet-technology/aboutvisafactsheet.pdf
7. ^ Cheng, Raymond, Zhang, Fan, Kos, Jernej,等. Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contract Execution[J].
8. ^ 朱立, ZHU Li, 俞欢, et al. 高性能联盟区块链技术研究[J]. 软件学报, 2019, Vol.30Issue(6):1577-1593.
9. ^ Microsoft Corp. 2018. Confidential Consortium Framework. https: //microsoft.github.io/CCF/
10. ^ Marcus Brandenburger, Christian Cachin, Rüdiger Kapitza, and Alessandro Sorniotti. 2018. Blockchain and Trusted Computing: Problems, Pitfalls, and a Solution for Hyperledger Fabric. CoRR (2018).
11. ^ R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson, A. Juels, A. Miller, and D. Song. 2019. Ekiden: A Platform for ConfidentialityPreserving, Trustworthy, and Performant Smart Contracts. In 2019 IEEE European Symposium on Security and Privacy (EuroS P).
12. ^ https://cloud.tencent.com/developer/article/1408971