链上隐私保护的难点、创新与落地方向

1

张卫（主持人）

大家晚上好，我是万向区块链通用架构技术部负责人张卫。今天的三位嘉宾是：Dimension CTO刘怿斯，Advanca联合创始人Deli以及 Phala隐私协议创始人尹航。 在开始讨论之前，首先请三位分别介绍下Maskbook、Advanca、Phala这三个项目。大家很好奇你们的项目解决了什么样的场景需求？挖掘了什么样的痛点？使用了什么样的技术去解决需求等？

刘怿斯

感谢介绍，大家好！我们在Web3.0 Bootcamp里带来的是Maskbook产品。这个项目的想法诞生于2016年Facebook“总统大选门”事件，这个事件暴露了很多的隐私泄漏问题。Maskbook的名字因此而得名，我们想的东西是“We want to put mask on face”，所以就叫Maskbook。

这几年隐私泄漏问题频繁发生，Maskbook通过浏览器插件的形式在大平台上增加了一层layer，把用户们发出的帖子都利用密钥加密起来，现在支持Facebook和Twitter，只有安装了 Maskbook 插件的人才可以解密出真正的内容。简单来说，我们就是做了一个运用了密码学的插件，用来Hide from no one but Facebook 。

Deli

大家好！我是Deli，我是Advanca的联合创始人，非常荣幸今天能参加Bootcamp隐私保护专场的讨论。Advanca是为分布式应用打造的具有隐私保护功能的基础设施，可以满足开发者在计算和存储方面对高隐私的需求。

在隐私保护方面，大家会有很多不一样的需求，其实已经有很多项目做出了尝试。比如Z-cash项目利用零知识证明试图隐藏账户资产、交易记录；Enigma、Oasis项目用了可信执行环境（TEE）来做私密计算。相比零知识证明这样的技术，使用TEE这种比较通用的技术不仅可以提供更通用的场景支持，在性能上也会略胜一筹。但是使用了这样的技术也会有隐私泄漏的可能性，尤其是在现在大部分公链的环境下，假设各个节点部署了TEE技术，但节点运营者不一定被人信任。所以即便是运行在TEE里的智能合约，节点还是有可能获取到对加密数据的访问模式的。

这个问题要怎么解决？学术界已经给了一些答案，比如说有一个技术叫ORAM，全称是“Oblivious RAM”，就是用来混淆应用数据访问模式的一种法。它的基本思路是扰乱攻击者收集到的应用访问信息。比如本来应用的真实意图是对数据块A访问很多次，但攻击者观察到的是没有任何含义的完全随机访问，可能看起来是在访问数据块B或者其他位置，这样就使得攻击者没法通过推理得到信息。

以上就是Advanca在试图解决的问题和使用的技术，总结一下就是结合TEE 和ORAM来提供平台，使得应用可以直接享受到高隐私带来的好处。

尹航

大家好！我是尹航，Phala Network的主要技术负责人，其实我不是CTO，因为我更偏研究，我们的CTO会更偏工程一点。Phala Network是在2018年成立的团队。

区块链能够解决去信任化的问题，但是如果要用区块链，很大的问题是所有东西在区块链上都是公开的，可能会有像Z-cash、门罗这样的链可以实现转账的隐私。但是如果想实现更复杂的隐私保护，比如以太坊智能合约的隐私保护的话就没有那么容易了。

除了零知识证明之外，MPC、TEE等技术也可以实现隐私保护。我们选择TEE，因为TEE是唯一一个在性能上比较可行的落地方案，用来实现通用的保密智能合约概念。MPC在某些特殊的环境下比较可行，但是并不适用于比较通用的智能合约，采用MPC有可能会导致百万级别的overhead。

2

张卫

那区块链是如何帮助解决这些问题的？

刘怿斯

区块链在我们的场景里没有特别明显地参与，我们就是做密码学相关的事情，毕竟是用密码学设计的插件。但我们也做了一些区块链相关的应用，也算是想要链接传统互联网和区块链世界的桥梁。把加密本身当成权限系统来用，谁能解密就代表谁有权限。

我们今年年初和MakerDao在Twitter上发起了“领区块链红包”的活动。这个活动类似微信红包，比如你在某个群里发红包可以设置金额和数量。Maskbook插件里也做了同样的事情，我们有明确的确权系统，只有能解密这段话的人才能领到红包。红包算是我们第一个在区块链里的尝试，之后计划会做更多和区块链相关的应用。

大平台也限制了我们能做的事情，比如Twitter本身不能发起投票，投票的功能是在去年或前年才被加进来的。用户没办法在想发起投票时就发起。但我们赋予了用户这样的权利，这也是赋予用户想干什么就干什么以及他们想做任何事情的自由，这也是我们插件比较认同的想法。

张卫（主持人）

有没有什么突破和创新以及难点。

刘怿斯

第一，说到创新，我觉得我们的产品就挺创新的，开玩笑。我们面临的很大问题是整套加密算法都是现成的标准，我们用到了SECP256K1和 AES 256 GCM mode。我们所做的事情是如何把它们高效地组合在一起，这是比较大的挑战。想要高效地把它们放在一起完成这套加密scheme还是要花比较多时间来做的。

第二，我们用了去中心化的数据库——GunDB，我们用GunDB来进行密钥分发。既然是去中心化的数据库，其实就没有中心化的状态，状态同步是其中很大的问题。如何解决不同机器间的状态同步问题，并且还能保证比较好用的用户体验，在我们这边是非常大的挑战。

我说完了，请其他几位介绍一下。

张卫（支持人）

接下来请Deli讲一下区块链和Advanca项目的关联。

Deli

区块链在我们项目里的用处和平台的结构是有关的，设计中Advanca平台上会有比较多不同类型的节点。主要是有控制层面的节点，另外是计算层面、存储层面的节点。

区块链应用主要是在控制层面，控制层面的节点会形成公开账本，目前我们使用的是Substrate的技术。账本上包含了平台核心信息以及核心逻辑。比如说有哪些节点已经注册平台；有哪些任务发布在平台上等待分配给节点运行；如何分发奖励；如何维护节点的声望。基本上是把链当成是一个分布式的控制中心。

控制层面重点利用了区块链本身的特性：数据高度透明；系统可用性非常高；扩展性比较好（节点可以很方便地加入控制层面，从而使控制层面的处理能力得到水平的扩展）。另外，所有数据都是不可篡改且已经保存在链上的账本中。

当然，区块链技术与其他层面的联系就是：计算层面、存储层面的节点需要直接连通到链上。在这个架构下他们相当于是链的用户，持有一些自己的私钥并签发交易到链上。

关于在项目中有哪些突破以及创新：

难点一：比较核心的一点是如何把对隐私的保护从系统的各个角度都做起来，尽量避免短板出现。需要安全性的系统一旦有一个地方可能是不安全的，其实会影响整个系统的安全性。

难点二：是如何兼顾高隐私性和性能之间的平衡。比如说我们引入了ORAM算法，实现对访问模式的隐匿。但其实这样的算法会引入比较大的开销，这就是高隐私保护的代价。如果我们想把把这个技术应用化的话需要进一步做优化，减轻对实际使用用户的影响。

张卫（主持人）

在设计的流程里一般的用户使用流程是什么样的？数据是以什么样的形式离开本地，在哪里进行什么样的计算？以及链上的交互是怎么样的？

Deli

比如说一个节点有TEE的可信执行环境，它想加入到计算层面成为worker，首先他需要做remote attestation，就是跟Intel拿到证明（report），然后向其他所有人证明确实是可信环境，这样就可以成为注册节点。如果开发者应用需要部署的话，开发者也是通过在控制层面发布任务信息，各个worker节点可以通过竞争争取到任务。

之后，任务的发布者可以和 worker节点建立起联系：直接通过链下的通道进行端到端的加密通信，由此实现数据流的传送。比如说用户就可以直接联系到worker节点，把私密数据传送进去。基本上就是这样的流程。

张卫（主持人）

接下来请尹航介绍一下Phala Network项目中应用到的区块链技术。

尹航

回答这个问题之前想先简单介绍一下，我们在做Phala时并不是做出基础设施就丢给大家去用这么简单，我们还是有非常大的责任去先告诉大家，拿着强保护隐私的系统能做点什么。

我们做了一个Pilot产品，叫 Web3 Analytics。道大家有没有用过Google Analytics，如果你是站长的话多半你是知道这个东西的。简单来讲，基本上全世界70%以上的网站都会在每一个网页、App里加一个插件，插件会统计看你访问了哪些页面，以及你在哪些页面停留了多长时间，按了哪些按钮，看了哪些内容，其实是为了收集用户的数据，是所有用户数据收集的“第一站”。所有的数据都收集到了Google那里，是不是Google拿着数据想做什么都可以？

我们认为这是一件非常不好的事情，用户的隐私应该由用户控制。所以我们做了Web3 Analytics的项目，项目的目的是可以照样让用户的数据被收集起来被统计，但是我们可以保证它完全地被去中心化，用户可以控制被收集到的数据被谁用了，允不允许他用。有点像你的手机里有控制每一个app能否访问你的摄像头、麦克风一样会有开关，你希望被别人用就打开，不希望被别开用就关掉，这是我们的应用。

张卫（主持人）

区块链在里面到底解决的是什么问题？怎么解决？

尹航

隐私保护，本质上是保护数据，数据到底是怎么被处理的？现在的情况是数据直接被大互联网公司收集起来了，所以用户没有数据的所有权。然而数据又很特殊，因为数据特别容易被复制，哪怕你把数据给了一些人，他在背后复制了拿去做一些你没有授权的事情，你也没有任何办法。因为数据的这一点问题，所以很难被确定数据的所有权。

另外，鼓励数据的流通，鼓励数据被更多人用起来，并不是说把数据公开的越多越好。如果要产生高效的市场一定要有“供”有“需”，如果数据拿出来后所有数据都在链上被随便复制的话，数据就缺少了稀缺性，因为没有所有权，所以也没有稀缺性，因为供给是无限量的，也不可能形成市场。

我们做的保密智能合约怎么解决这个问题？本质上是把数据放进了保险箱，只有经过了用户同意才能以一种用户同意的方式来使用数据。通过这样的设计把数据所有权重新还给了用户。

网站开发者只可以来使用，并且要经过用户的同意，而不能把数据复制走了想拿它做什么就做什么，所以它是为了避免公地悲剧的一种设计。

张卫（主持人）

在设计这套系统的时候有哪些突破和创新？

尹航

我们最大的突破创新在于可互操作，以及可组合性，如果大家对DeFi比较有了解的话。

TEE有一个特点，是和普通区块链网络很不同的性质，TEE的所有节点是非拜占庭的。什么是非拜占庭？如果你是普通节点可以修改节点的代码让它去作恶，但是TEE可以保证运行在TEE里的程序是没有办法被篡改的，所以是非拜占庭的。在以太坊这样的系统里，为了实现去信任化的做法是让全世界所有节点都运行同样的程序，其实这是很强的冗余。每执行一笔交易，这笔交易在所有的节点上都执行一遍，大家会互相验证，通过共识算法保证去信任化。但是在TEE没有了这个限制，有什么好处？可以实现合约级别的并行。

什么叫“合约级别的并行”？每个智能合约都可以部署在不同的TEE上，也就是说有一个节点可能可以执行一个合约，有一百个节点就可以同时执行一百个合约。

这样可以带来两个好处：

1、安全性会比全冗余更好，全冗余意味着一个节点被攻破，所有合约的数据都在节点里，就可以都拿到了。如果让每个节点只运行部分合约的话，那么你没有办法拿到所有的数据，这是安全上的考量。

2、可以让性能变的非常好，基本上是你有多少TEE的节点，可以实现线性的性能增长。这就类似于做互联网系统，从云服务里租服务器，如果服务器性能不够可以买更多的服务器解决问题。

但是这里遇到了非常大的挑战，大家知道智能合约和云服务器还是有很大区别的，因为智能合约突出可组合性。在DeFi的应用场景下大家都知道有MakerDAO、DYDX、以及各种DEX等独立的项目，才能有繁荣的DeFi系统，背后依赖着以太坊平台，在平台上合约和合约之间可以无缝组合。

但如果说每一个合约都执行在自己的TEE里，那每一个TEE其实只知道自己合约中的信息，并不知道其他合约现在是什么状态，这就涉及到特别复杂的一致性、可用性问题。这个问题非常复杂，所以这里我们就不会展开了。基本上我们最主要的突破是设计了一套读写分离的设计，并且利用区块链补足TEE的不足之处，利用区块链充当时间戳服务，并且为所有TEE提供可用性的保障。所以，可以把系统理解成链，有点像波卡的 Relay Chain，每个TEE有点像波卡里的平行链，每个TEE和TEE之间都实现了强一致性可互操作与组合性。这是Phala Network主要的与众不同之处。

张卫（主持人）

听起来挺酷的。我有一个小问题，一段程序在TEE里执行一段input（输入），有办法向外界证明确实是按照预设的预期代码逻辑去执行出来的结果，TEE本身有能力给出这样的proof吗？

尹航

有的，Deli也提到了，确实TEE提供了硬件上的保证，就是我往里面放什么程序就会怎么执行。但是如果不能对外生成任何证明的话就是本地的TEE，那应用场景就小很多了。

本地的TEE最常见的应用场景是什么？就是苹果手机、安卓手机的指纹解锁，不需要向外证明任何东西，只是把秘密保存在TEE里。但是对我们来讲，我们需要向外证明在TEE内部发生了一件什么事情，而且是按照预期的方式发生的。核心技术叫做Remote Attestation（远程认证）。

远程认证的原理大致是这样的，在CPU里会有硬件厂商烧录进去的一段密钥，按理来说这个密钥是硬件厂商以及其他任何人都不知道的。硬件厂商知道公钥，私钥是写入在硬件里的，而且没有任何方法能直接访问到私钥。

在硬件里实现了Remote Attestation的模块，可以把在内部执行的程序进行校验。校验的内容，以及硬件当前运行的状态（比如说运行了什么版本的固件，运行在什么样的系统里），这些信息都会被硬件内部私钥签名发给Intel，Intel经过校验发现没有问题的话会产生report。这个report，任何第三方都可以验证，不需要有特殊的硬件，手机也可以做验证，report里包含的内容：

它是一个信任链条，从源头——硬件——Intel——用户端，可以做端到端的验证，确定在一个TEE里按照约定的方式执行了一个程序。

张卫（主持人）

本质上通过硬件加上Intel的商业背书实现了这一点。现在硬件加上Intel本身的商业背书做这件事情，如果最终把intel换成去中心化多个机构组成的联盟，会不会进一步提高硬件的大众接受度？毕竟Intel是独立的商业企业，如果某一天通过联盟、去中心化组织提供商业方面的保证，有对立博弈的多个厂商参与，是不是可以进一步迭代安全性？

3

今天的三个项目，各自都有自己的特点。接下来分别针对三个项目探讨一下各自的特点。

我在看Maskbook功能设计时，一直有一个小的疑问。比如说我们用微信，第三方厂商接入微信的时候不可能拿到微信的好友链，我发Twitter，虽然我的好友也安装了插件，但是Maskbook应该是读不到Twitter里的好友链，是怎么让好友能看到解密之后的数据但是其他人看不到呢？

刘怿斯

这个问题是真的是用过我们产品会问的问题，大家应该都比较好奇这样的事情，毕竟我们不是Twitter也不是Facebook，但我们怎么能知道一个人是一个人呢？我稍微讲一下原理，每一条Tweet、post都是由对称密钥加密的，我们是用AES GCM mode来做加密。每一条加密好的数据其实会被po到Twitter上，因为这是general的，由一个AES Key来加密的。我们现在需要做的事情是什么？你想要谁来解密到这条消息，你就需要把他的AES Key给它加密地分享出去。

我在Twitter上选的是要加密给所有的好友，我们定义的好友是相互关注的人。这怎么判断？因为没有办法知道好友是谁，因为不会存你的Twitter关系列表。其实我们做的是一个on demand的思想。

一开始分享的时候只会把已经记录到的好友分享给他们。所有的公钥都po在一条Twitter里，或者Twitter的profile里的。公钥只要访问到你的主页，其实我就可以知道你的公钥了，这种是已知的好友，但还有一些是未知的好友，我们做的是On demand。

比如说你发一条被Maskbook加密过的Twitter，我作为另外一个人看到这条Twitter的时候，碰巧我也装了Maskbook的插件，我会先判断一下我有没有资格解密。我做的事情是模拟用户打开作者的主页，然后判断关系是否是你follow我或者我follow你，或者我们互相follow。找到了关系后，再来确定是否符合作者设置好的范围。这个机制比较绕，叫做“好友发现机制”。因为这条Twitter的密钥是不会存在任何一个第三方，只会存在有资格解密这条Twitter人的电脑上。

当任何一个有资格、有密钥的人在线的时候，我们就会通过他来P2P地传给我，让我来解密这条Twitter。但是如果万一没有拥有这个密钥的任何人在线的话，必须要等到有任何一个拥有密钥的人上线才能解密这条Twitter。

这也是去中心化的问题，说实话，如果我们是中心化的服务，完全不需要思考这个问题，只需要把密钥存在上面就可以。但因为是去中心化的，没有办法保证所有人都时刻在线，所以并不能保证服务24小时在任何场景下都能够work。这也是一个trade off，毕竟用户想要隐私、安全就必须得牺牲一些。

这是我们的技术原理。

张卫（主持人）

确实这样能解决大部分场景下的问题。

刘怿斯

其实我们在线用户还蛮多的，现在比较活跃的用户圈子都比较小比较紧密，确实能够保证稳定性。

张卫（主持人）

我个人感觉做了一个非常酷的插件。刚才讲到了AS对称、隐私密钥。AS是加密这条Twitter，每一条Twitter都有可能生成加密密钥，或者一个人一个用户所有的Twitter。

刘怿斯

每条Tweet都会有独立的AES key来加密，保证一个密钥被crack之后 不会导致所有其他的加密Tweet被同一个key解密，这也是为了保证前向安全性（Forward Secrecy）。

张卫（主持人）

信息安全性。这是在不同好友关系链里流转的。刚才还讲到了公私钥对，这个是属于user的？

刘怿斯

对的。我们用公私钥对的用途是加密对称密钥，我们做的事情是要把对称密钥安全地share给你想要share的人，这时候需要用到非对称加密的方式。比如我想给你加密或者你可以解密我的消息，就必须用你的公钥对AESK做加密，这样你就可以用你的私钥解密出来，是比较轻量级的分享方式。

张卫（主持人）

不然的话效率可能会是问题。刚才说这些是放在插件里？那会有安全性上的风险吗？

刘怿斯

对的，其实现在都保存在插件的indexed db里，是浏览器自带的DB。设计还是安全的，但是也有一些paper讲到有被bridge的风险。我们也做了很多的考虑，考虑过把所有密钥做加密，先加密再存在indexed db里。等到用户想要用的时候再用密码解密。但是这个用户体验非常差，所以我们最后做了妥协，还是会把密钥直接放在indexed db里。这也是我们不得已而为之的做法。

私钥是用户最大最重要最concern的安全的问题，我们在这方面是比较无能为力的，又要保证安全性、又要保证用户体验性，所以我们做了trade off，还是比较相信indexed db本身还是比较安全的。

有些论文讲到了indexed db被bridge的风险的case。我们所有代码都是开源的，也不会做任何的网络请求，唯一的网络请求都是跟GunDB （音）去中心化数据库做交互。所有人都会知道网络请求是什么，保障了不会对你的私钥做任何的危险举动。

稍微多说一点，设计最重要的就是安全性，有三大设计原则：

不依赖于任何平台的API。我们是不信任平台的，如果平台知道我们在做的事情，他们完全可以操纵我们的API请求，而且我们也比较害怕哪一天平台突然关闭/限制了API的使用，不希望这样的事情发生，我们算是比较追求自由的产品，所以完全没有用到任何平台/官方所提供的API，都是自己做了用户模拟的操作。

没有任何中心化的服务，这也是我们保障用户安全性很重要的地方，所有网络请求都和去中心化数据库进行交互，不用担心有任何中心化服务做所谓的恶码。其实去中心化数据库所有人都可以随意进来、退出，我们也没有办法在里面做任何的不好事情。因为会被任何想要all date我们代码的人都可以捕捉到我们所干的不好的事情。

不信任平台，有用过我们插件的知道我们在Facebook和Twitter上做了很多代码注入的东西，毕竟我们希望把界面做的好看一些。我们所注入进去的代码都是在shadowroot下的，完全不用担心平台会知道代码的存在，因为shadowroot本身在设计上就是不会被本身代码所能够探知到的shadow的隐形代码。

通过这样的方式来隐藏在Facebook、Twitter上的举动，尽可能地保护到用户使用插件安全。

回到私钥存储问题，希望提供又安全又好用的插件，但是由于用户体验实在是太差，每次都解密都要输新密码，用户肯定是不愿意的，所以我们不得不在这里做了妥协。如果有人真的希望用比较高级的模式，每次解密，每次用到私钥都输一次密码的话，我们也可以推出相应的功能，都是比较愿意倾听大家的想法。

张卫（主持人）

谢谢刘怿斯。因为这是社交网站上行为，是不是以后可以跟Facebook或者Twitter联合做校验？虽然我们发的内容Facebook和Twitter解不开，但是通过Facebook或者Twitter本身的登录校验等流程和机制去解开插件里的相应问题。

刘怿斯

我觉得这个问题蛮好的，因为对用户体验是比较好的帮助。问题就在这里，我们建了“去中心化身份”的概念，从最早的设计开始就相信Decentralized ID。用户想创建1000个身份、10000个身份都可以，没有任何的平台设计，但我们完全希望能够摆脱平台对于用户的限制。一开始的想法是不信任平台，不希望自己依赖于平台本身的，希望依赖于ID，我们对ID负责，而不是平台对任何事情负责。这是我们的设计理念。

张卫（主持人）

谢谢刘怿斯。接下来有些问题想要请教Deli，看到官网上对TEE重度使用，TEE其实是用了市面上大厂现成的一些设备硬件，还是自己有这方面的研发计划？如果有这方面的计划，相对于现在目前的大厂有什么样的优势？

Deli

其实主持人说的非常对，现在我们用的确实是比较成熟的技术，Intel SGX。原因是它已经有比较大的生态了，包括开发环境、硬件以及对应的 Attestation服务的支持，确实已经比较成熟了。就像之前另外几位嘉宾有提到的，它是落地且已经可以实现应用的技术了。

在学术方面有很多论文也在关注 Intel SGX，正是因为有很多人关注，它可能在安全性上会有更好的提升。至于新的TEE技术，我们的看法是会保持关注，因为这个技术的基本原理是相通的。

比如大家知道苹果最新的MacBook有一个T2 chip，上面有secure enclave，被用来处理一些需要高安全和高隐私的任务，即便kernel被攻击了enclave保护的数据也是安全的。但它的问题是不够开放，因为它的接口只对自己系统级的应用进行开放，作为开发者如果你想用到这些功能的话是比较难的。再比如说ARM平台上的 TrustZone，大部分ARM平台应该都是移动端的，我们目前重点还是看服务器端，所以用Intel还是比较直接的办法。

还有更新一些的技术，有一个项目叫做Keystone，是UC Berkeley的一些教授（小编注：Dawn Song参与）主导的项目，他们其实是想做open-source 的尝试。目前他们还在不断更新、发展中，官网也有自己的roadmap大家感兴趣可以自己看一下。

我们的看法是一旦新技术可以真的落地，我们肯定会考虑应用。只要节点能提供可信环境、计算能力、存储能力，它都可以连接到我们整个平台上的。

最后还有一点，现在Intel也意识到了，如果要求大家都依赖于它的attestation服务的话，是不现实的。所以后来Intel开放了第三方 attestation的接口，相当于每一个组织、公司可以自己设置 attestation服务，从而在这方面可以和Intel割离。

张卫（主持人）

Intel提供service其实是给第三方在上面注册attestation服务，然后发放认证的attestation设备。

Deli

其实相当于给每个enclave发一个证明，然后大家可以验证之后再把私密数据放进来。

张卫（主持人）

刚刚讲到了ORAM技术，能跟我们进一步介绍下ORAM技术的特点和应用吗？

Deli

ORAM技术一开始针对的场景和现在可信计算的场景非常类似。它讨论的是一种攻击，假如我看不到你的CPU在做什么，但是可以看到CPU对内存的访问，那我其实是可以推断出你在试图做什么。

ORAM怎么解决这个问题？要求CPU按照他的算法，依照一定的模式去访问内存，这样即便攻击者观察到了访问模式，但其实看起来就像在随机访问一样，是拿不到任何额外的信息的。

我举个简单点的现实例子，比如说有一个间谍要通过储物柜来传递情报，储物柜就好比是加密的存储，只有有钥匙的人可以打开拿东西。在看不到柜子里东西情况的时候是不能确定他是不是间谍的。但如果他很有规律每周去固定号码的柜子拿东西，这么做肯定是会被怀疑的。或者他稍微变通一点，他放进去，但是不自己去拿，而是找另外一个人接头。可如果接头这个人被认出来，他还是可以被联系起来的。

如果想要类似于ORAM的思路来解决要怎么做呢？比如说可以开始雇人去访问柜子，可以先放到柜子里，然后再找一个人帮他转移。因为观察者也不知道帮忙的这个人到底拿了东西还是没有拿。找很多帮忙的人去帮他进行转移，最终观察者拿到的都是已经混淆后信息，都很混乱，推断不出他是不是最可疑的人。

所以基本思路是增加额外的访问让观察者无法去推断，使他不可能再和已有的信息联系起来，也不可能单纯通过访问来判断是不是同一个人在做。

张卫（主持人）

刚才例子里面，间谍情报移动到另外一个地方是能被观察到，但是多个进行混淆的移动能不能被观察到呢？

Deli

其实每一个访问都是可以观察到的。回到可信环境里面，CPU每一次对加密内存的访问也都是可以被看到的，但是如何隐藏真实意图呢？有一些访问是没有任何实质性作用的，但是却增加了信息量，给攻击者提供了过多的信息，导致他没法精确地推断到底发生了什么。

张卫（主持人）

谢谢。可以通过这种方式规避掉用户监测CPU对内存访问的行为，提炼特点，来形成攻击？

Deli

对，基本是可以这样。

张卫（主持人）

关于Advanca相应角色设置上的小问题，worker在建task的时候，是每个worker建一个task，还是会有多个worker建同一个task？在早期的某些区块链场景里是通过多个worker交叉对比，去抑制worker作恶，这些机制去保证算力任务放到链上或者链外围一些相应的worker上可以得到正确的执行。在Advanca的技术设计里，会有类似于这样机制的设计吗？就是多个worker去进行对比。

Deli

对，这个场景其实是存在的。我们现在可以说一个worker只建一个，也可以多个worker合作完成task。具体的细节我觉得可以暂时不用介绍，重点是说worker怎么互相进行对比，有了Attestation保证我们是可以知道worker运行的代码是一样的，进一步只要保证他们拿到的输入是确定的，我们其实就可以相信worker不会作恶。

多个worker执行同样的任务，其实是一种冗余，但也非常有必要。比如将来Intel SGX技术出现了漏洞，如果只攻击到一个enclave，其他的enclave还没有受影响，这种情况下还是能保证正确性的。

张卫（主持人）

谢谢Deli。接下来有些问题想咨询一下尹航，刚刚尹航聊到了保密智能合约，能不能给我们更详细地介绍一下现在保密智能合约大概能实现哪些功能模块？

举个例子，现在要生产一个proof，链上的共识节点去验证，比如说转账，转出的金额和转入的金额是相等的，两个都是明文。还有其他的proof，怎么保证隐私体系没有受到影响，总额是一定对的，有足够的余额去做转出。这个例子是典型的Z-cash方式的流程。

Phala里提供的保密智能合约大概有什么样的流程、原理能和我们分享一下吗？

尹航

刚才主持人描述了很典型的基于零知识证明的隐私保护，从用户端到区块链端的流程。

可以看到，这个过程里是比较复杂的过程，因为每个环节都是和密码学做了很紧密的结合，毕竟是基于纯密码学的设计。保密智能合约，因为采用了和TEE结合的方式，保密性是由TEE提供的。我们可以把系统变的非常非常简单，可以简单到什么地步呢？类似于和你做以太坊的合约完全一样，只不过在以太坊合约内所有存在的数据，输入、输出都是在链上可见的，或者可以通过执行得到。

但是在保密智能合约这边，所有的输出、输入、中间状态都是完全加密的。具体用户怎么去使用保密智能合约呢？首先，会让开发者把智能合约编译好之后提交到链上，类似于在以太坊上部署合约。部署到链上的合约大家都能看得到里面每一个操作是什么，有点像EVM的字节码一样。当然，我们采用的是WASM，会把WASM的代码载入到TEE内。从它载入到TEE内开始的这一刻，所有在内部产生的数据、输出/输入都直接对外不可见了。

如果用户想要调用合约，为了让输入保密，TEE和用户都有自己的公私钥对，所以就可以执行ECDH协议（迪菲赫尔曼协议）来做密钥协商。其实就是和HTTPS的原理非常类似。用户把自己的交易输入加密之后提交到链上，链上的交易会被读入到TEE内部做解密，所以说实现了用户到TEE之间的端到端加密，可以保证输出、输入都是完全保密的。

比如说在以太坊上如果你想查询内部的状态，是可以做任意查询，只要你知道合约的ABI就可以查询到数据库里所有的数据，但是保密智能合约很大的区别是因为内部的状态对外不可见了，需要额外定义query，只有经过验证的请求才能回答。这就类似于中心化服务器上的开发，例如向微信发一个query，要先发给微信正确的密码，才能允许登录，在我们这里也是一样的道理。

我们和以太坊很大的区别是，用户如果发一个query到TEE来，就需要对自己的query做签名。TEE收到query之后会先验证用户的身份。开发和在合约内部，可以通过代码自己来定义用户在什么情况下能访问哪些数据。TEE只有先做了身份的验证，验证通过了才会把对应的数据返回给你，如果身份验证没有通过，就只会返回一个错误信息。

现在我们做了一个非常简单的demo，用户可以以自己的身份来查询自己的余额，或者以自己的身份来查询别人的余额，如果去查询别人的余额就会返回not authorized错误，我觉得这是和以太坊最直观的差别。

与此同时，如果你看这个过程，会发现它跟以太坊的合约开发，以及和大家熟悉的中心化后端开发是很类似的，在中间没有涉及到特别复杂的密码学，像零知识证明或者MPC等密码学工具。所以它对于开发者、用户来讲门槛都是相对比较低的。

张卫（主持人）

通过尹航刚才的介绍，我确实能感觉到这里面会有一系列的优点，比如说它是相对轻量级的，冗余并不高。

我有一个小的疑问，这里面的风险在于冗余高有效率上的缺点，但是冗余高也保证相关数据的安全性相对高一些，丢失的风险相对低一些。如果发了隐私Token的合约放在TEE里，只有这一个TEE设备里才有状态和逻辑，这样一个TEE有没有可能成为单点风险？Phala 项目会不会因此设计一些适当的冗余保证在单点故障情况下出现的数据保护。

尹航

这是我们设计整套系统的核心问题之一，首先要确定的一点是TEE内部所有的数据都只有同一个CPU访问才能拿到。比如说这个TEE里产生数据，因为它是加密的，我把这份数据拿到另外的电脑里，肯定是访问不到的。基本上只要这个TEE消失了，使用它来加密的数据也消失了，这肯定是大家都不能接受的情况，因为必须要保证可用性。

对于任何区块链来讲，如果只是保证正确性是不行的，还要保证可用性的特点。怎么解决这个问题？首先，要允许矿工自由地进出，不是把数据跟矿工绑定，而是为每一个合约都分配一个密钥，密钥可以用来加密合约相关的所有数据，但是如果矿工掉线了，没有关系，可以引入另外一个TEE节点，只要它可以得到之前的密钥，就可以接替上一个TEE接着执行。

我们不依赖矿工来保证系统的可用性，只要一个矿工掉线可以拿另一个矿工顶上。怎么来保证密钥的可用性？密钥相对于所有数据来讲量是比较小的，所以说设计是在链里有三种角色，第一个角色是区块链，第二个角色是TEE的worker（矿工），第三个角色比较特殊，和矿工有点像，把它叫Gatekeeper，但是它的责任和矿工是不同的。

我们会从全网中选出大概几十个Gatekeeper，这个数量大概和NPoS的Validater是类似的，它们需要时刻保持在线。我们会把所有合约的密钥都保存在Gatekeeper的TEE内部，这样只要保证Gatekeeper在线的概率，在线比例比较高，没有全部同时下线，整个系统就可以恢复。

具体来讲，这就有点涉及到里面一些密码学的细节。会在几十个Gatekeeper之间做Shamir密钥分享协议，会把所有的密钥拆成很多份，大概可以理解成只要几十个节点里，最少保证几个节点时刻在线就可以恢复出原始的密钥。

通常情况下会用一些Staking的方式确保节点，会激励他一直保持在线，如果他不保持在线会去Slash它，希望在很长的时间里Gatekeeper至少有一定的数量保持在线，就可以保证可用性。

张卫（主持人）

通过秘密分享来保证N&M，只要N个节点里面M在线就可以保证系统的可用性。时间过的很快，三位之间还有想要互相了解的问题或者对对方项目的疑问点吗？

Deli

我其实有个问题想问Maskbook，你们下一步对插件的发展方向大概是什么样的？

刘怿斯

现在很多诟病都是说用户使用的门槛还是蛮高的。首先，我们给他生成了一对私钥，需要把公钥贴在Twitter或者放在公开可见的Twitter上，之后所有的发帖过程都是需要有学习成本的。因为我们面对的更希望是小白用户，也希望看看有什么样的方法可以将门槛降低下去。

第二，我们本身可能没有那么区块链，但我们认为自己是桥梁，连接传统互联网和区块链的“桥梁”。之前用红包做了demo，证明我们完全可以让大家在Twitter上执行一段智能合约，实现了在微信或者QQ群里给别人发红包的事情。也希望看看未来有没有其他的像Advanca、Phala Network（的地方）。

你们肯定也希望用户能够更简单地access到你们的服务，比如说你们也希望用户可以通过很简单的点击就可以直接使用到TEE，或者说直接使用到你们的一些服务了，我觉得我们的插件可以帮助大家做到这件事情。之前讲了，我们算是权限系统，可以让应该能看到结果的人看到结果，看不到结果的人看不到结果，这算是我们未来想做的事情。

尹航

非常有意思，我们也希望能够把隐私保护技术用到用户更容易能够接触到的地方，毕竟大家都在开玩笑说，搞了这么多区块链，到底用户能用它做点什么。

你们确实是非常非常不错的尝试，我们也在做我们这边的尝试。我有一个问题给Advanca的Deli，我想知道你有非常强大的隐私保护计算系统/存储系统，能做很多很多非常复杂的应用，你们会把应用落地放在哪个方向上做尝试？

Deli

重点还是面向用户，比如说提供平台应用直接面向终端用户。我们认为这种具有非常高隐私的技术，最大的价值还是在保护每个普通人的隐私上。当然了，如果是公司级的应用也是非常有用的。相对来说，个人的隐私保护更关键一点。我们团队本身也很信奉每个人自己要控制自己数据的理念，这也是未来我们努力的方向。

张卫（主持人）

基于Deli刚刚的回答我有一点疑问，像我们在做商业项目以及各种各样项目的时候，不单想要保护用户的隐私，还想要基于保护用户隐私的基础上做些数据可用性。就基于这些数据想做分析、推送，数据分析的同时不想侵犯用户的隐私性。用TEE是不是比较好的解决方法？

Deli

在这种情况下TEE是有机会的，比如说你有一个开源的分析查询的应用部署在TEE里，这个应用是没有做坏事的，因为代码已经被大家审核过了。只要代码逻辑里不把大家的隐私发送出去，大家就可以相信它是可信的服务。重点是把最终要实现的功能所用到的数据拿出来，而不是直接把用户数据暴露出去。

张卫（主持人）

感谢三位的分享，隐私保护是个很有意思的话题，期待后面有更多的探讨和碰撞，也谢谢大家。

关于Phala

Phala Network是波卡上的隐私计算平行链，基于类pow的经济激励模式，Phala释放无数CPU中隐私算力并运用于波卡平行链，进而服务于波卡上的Defi、数据服务等其他应用。基于Phala的应用pLibra和Web3 Analytics已经获得web3基金会grant。2020年3月，Phala成为首批加入Parity Substrate Builders计划的项目之一。

Phala社区日历

—-

编译者/作者：Phala可信网络

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。