隐私计算 区块链：一次具体场景下的详细应用

来源：碳链价值

原文标题：隐私计算+区块链：一次具体场景下的详细应用

在本文中，我们假设了一个非常具体的业务场景，在这个场景中说明应用隐私计算的详细过程，以及区块链在其中扮演的作用。

编者按：本文转自公众号「一个洋葱」

作者：缪弘、毛苇

目前的人工智能模型大多依赖海量数据的训练，对于海量数据的需求导致了数据隐私问题的泛滥。而隐私计算可以实现在不聚合海量数据的前提下利用分散在多方的数据完成聚合计算和模型训练，保证整个过程中每一方的数据都不会暴露出来，是大数据时代解决隐私问题的关键。在本文中，我们假设了一个非常具体的业务场景，在这个场景中说明应用隐私计算的详细过程，以及区块链在其中扮演的作用。

隐私计算是一类技术的统称，其中包括安全多方计算、零知识证明、联邦学习等。近年来，学术界对于隐私计算相关算法的研究有了长足的进步，也发展出了许多成熟的、高效的改进模型。我们研究了其中的一些模型框架，并且将这些框架尝试应用于企业信息整合方面的实践。

场景假设

我们假设这样一个场景：每个企业有一个本地部署的信息中心。信息中心存储了企业内部文档、企业从外部获取的市场信息、团队成员之间的交流讨论等数据。信息中心还集成了一个区块链的节点，通过区块链网络实现受控的跨企业信息分享和协作。

在这样的场景下，我们可以通过信息中心的数据计算出企业内部的最热话题，代表着这家企业当下所关注的重点领域、新技术、发展趋势等等。信息中心的数据涉及到企业的隐私，绝对不能对外泄露。而另一方面，同一个行业的企业都想知道整个行业的大趋势，大家都在关注哪些事情，有什么热点事件，哪个技术现在大家应用的最多，等等。

这里就有了隐私计算发挥作用的地方，在保证企业内部信息不外露的情况下，联合所有企业的信息中心，通过区块链网络协调，完成全局的热点话题计算，并将计算结果公开给参与计算的企业使用。

举一个具体的例子：每个企业节点已经计算出了企业内部的最热话题排行，和每个话题的热度评分，我们需要在不暴露每个企业内部的最热话题和评分的情况下，对多个企业的话题评分进行累加，最后得到全局的话题热度排行。

比如，有三家企业部署了信息中心，在企业内部计算得到的热点话题和热度评分如下：

企业A：人工智能（90），大数据（45），健康（21），金融（10）

企业B：大数据（87），数据分析（55），交易（32），新闻（21）

企业C：PHP（80），Java（70），大数据（54），人工智能（31）

我们要基于上面的数据进行累加，得到全局的热点话题排行榜：

大数据（186），人工智能（121），PHP（80），Java（70）

并且最重要的是，在整个计算过程中，要保证企业A、B、C各自的热点话题和评分不对外暴露。

简化的问题：多节点安全数字求和

我们先考虑一个简化的问题：多节点安全数字求和。假设有N(N>2)个节点，各个节点都知道彼此的存在，且可以互相通信；每个节点都持有一个隐私的数字，这N个节点想要求得这些隐私的数字的和，同时不希望暴露自己持有的隐私数字。

这个简化的场景相对与原始场景，不需要考虑节点之间的通信问题，且每个节点只持有一个数，不需要考虑多个热门话题的对齐问题，问题简化为，如何在不泄露隐私数据的前提下，得到所有节点的持有数字之和的问题。

我们使用安全多方计算（MPC）的方法来解决这个问题。在使用安全三方计算协议（例如ABY3、SecureNN等）的情况下，如果只有3个节点(N=3)，那么能直接通过安全三方计算协议得到所有节点持有数字之和。但是，当节点数大于3个时(N>3)，我们就无法直接通过安全三方计算协议得到最后的结果了，需要在安全三方计算协议的基础上，进行进一步的算法设计（最新的研究已经有了支持任意多方安全计算的协议，比如SPDZ，但是出于工程化和方便使用的角度，我们采用了三方协议来实现这个功能）。

算法的具体步骤如下：

该算法的正确性是显然的，现在我们要确保的是算法的安全性，即算法中各个节点间的隐私数据没有被泄露：

• 算法第3步中，使用安全三方计算协议，保证了两个节点进行求和的数字没有泄露到外部，只有最后求和的结果暴露到了外部

• 算法第3步中进行求和的数，只是原始隐私数字的一个拆分，进行求和计算的配对方也只能反推出这个拆分，无法得到原始的隐私数字

• 算法第4步中，第3步的N个求和结果都暴露了出来，可以得到N条方程，共2N个未知数。每个节点只知道自身的两个拆分数，所以对每个节点来说，共有2N-2个未知数。当2N-2>N，即N>2时，方程组没有确定解，所以各个节点的隐私数字也没有泄露

更进一步：多节点安全的热门话题聚合

现在我们考虑一个更复杂一点的问题，将上一小节中的计算单个数字的和，变为计算多个节点的热门话题的聚合。热门话题的聚合相比于计算单个数字的和，每个节点可以有多个话题，且每个节点之间的话题可以不相同。例如，节点A有热门话题1、2，节点B有热门话题2，3，节点C有热门话题1、3、4，现在需要得到这三个节点上热门话题1、2、3、4、5 的热度值。

由于每个节点持有的话题并不相同，想要进行多方的热门话题聚合，首先需要对话题进行同步。对话题进行同步，最简单的就是各个节点将自身的热门话题公开出来，但是处于隐私保护的考虑，各个节点不想公开自己有哪些热门话题。这种情况下，我们需要另一种方法，在不泄露各个节点的热门话题情况下，完成热门话题的同步。

对于这种情况，我们可以使用这种方法：

• 各个节点使用同一种方法，将热门话题映射到一个整数域[0, Z]上

• 各个节点将热门话题的热度值，填到话题对应的维度上，得到一个长度为Z的话题热度向量

• 各个节点无需将各自的热门话题公布出来，只需要对话题热度向量，按照上一小节的算法，进行安全多方计算即可

上述这种方法，将在节点间同步各自持有的热门话题，改为了在节点间同步一个热门话题到整数的映射函数。可以将这个热门话题到证书的映射函数看作是一种加密方法，各个节点之间只暴露加密过的热门话题，只要这个映射函数是不可逆的，就能避免明文暴露自己的话题。

在这个问题中，我们可以选用一种哈希函数，将热门话题映射为一个整数。同时，将整数的范围设定的比较大，防止不同节点间产生哈希碰撞。各个节点同步完哈希函数之后，可以将自己持有的多个话题的热度转化为一个定长的话题热度向量，各个节点的话题向量长度一致，可以按照上一小节的算法，进行安全多方计算。

在各个节点安全多方计算、得到话题向量的和之后，就可以得到最热门的几个话题的维度和热度值了。这时我们需要从热门话题的维度，得到对应的热门话题。因为哈希函数是不可逆的，所以需要各个节点将它们知道的热门话题公开出来，这样所有节点就都能知道完整的热门话题了。同时，每个节点只公开了自己持有的热门话题，并不会暴露其他非热门的话题，保证了数据的隐私。

实际场景

现在我们考虑实际的场景。在上一小节的场景中，我们假设各个节点之间是互相知道彼此的，可以互相通信。同时之前的算法还蕴含了一个假设，即存在一个各个节点都信任的第三方，帮助节点间实现配对、哈希函数的同步、最后热门话题的公开等操作。但是在实际的场景下，并不满足这些条件，各个节点间可能并不知道彼此，也不存在一个各个节点都信任的第三方。这时想要实现多节点的热门话题聚合，需要借助区块链，来在多个节点间进行协调。

通过之前的算法，我们可以看出，区块链需要帮助实现以下的功能：

• 各个节点间的互相发现

• 节点间计算配对的协调

• 节点使用的哈希函数的协调

• 各个节点计算结果的公开

我们可以通过智能合约，在区块链上实现这些功能：

• 在区块链上部署一个智能合约，各个节点都可以执行这个合约的方法

• 合约提供一个上报节点信息的方法，节点将自身的通讯地址、名字、等信息上报上去

• 合约提供一个上报哈希函数的方法，节点将自己支持的哈希函数通过该方法上报到链上

• 合约提供一个开始方法，当开始方法被调用时，会触发一个计算开始的事件，各个节点可以监听这个事件

• 合约提供一个获取配对节点的方法，当计算开始后，节点可以通过这个方法，请求得到其配对的节点信息

• 合约提供一个获取哈希函数的方法，节点可以通过这个方法，得到其需要使用的哈希函数

• 合约提供一个提交计算结果的方法，各个节点完成自己的计算后，可以通过这个方法，将结果上传上链

• 当所有节点都提交其计算结果后，合约会触发一个计算结束的事件，各个节点可以监听这个事件

• 合约提供一个获取当前轮次全部计算结果的数据，当计算结束后，节点可以通过该方法获得所有的计算结果

• 合约提供一个上传热门话题对应关系的方法，节点可以在得到最终的热门话题后，通过该方法将自身的已知的热门话题上传上链

• 合约提供一个查询热门话题对应关系的方法，可以查询得到其未知的热门话题（前提是别的节点上传过了）

由此，我们通过结合区块链与安全多方计算，就可以在实际场景下，实现多个企业平台的安全的热门话题聚合了。整体流程如下：

• 首先由一个节点在链上部署智能合约，实现上述的功能

• 参与的节点调用合约的方法，上报自己的节点信息、支持的哈希函数，并开始监听计算开始与计算结束事件

• 某一个节点可以调用合约的开始方法，开始一轮计算

• 各个节点收到计算开始事件后，向合约请求统一的哈希方法，并用得到的哈希方法，将自身的热门话题与热度转换为热门话题向量，并将热门话题向量拆分为两个子向量

• 各个节点向合约请求这轮计算中与其配对的节点信息，根据配对的信息配置，启动对应的计算节点。例如：4个节点A、B、C、D，节点A会收到3个配对信息，分别为（A，B）和辅助节点C，（C，D）和辅助节点A，以及（D，A）和辅助节点B；节点A则启动两个计算节点，一个辅助节点，两个计算节点分别持有两个拆分的热门话题向量，与配对的节点进行通信，完成计算

• 节点的计算完成后，将得到结果通过合约提供的方法提交上去。为了防止计算结果的重复提交，我们可以在上一步的配置中约定好提交的节点。例如，配对（A，B）中，A提交计算结果，配对（D，A）中，D提交计算结果

• 当所有节点都提交了计算结果后，智能合约会发布计算结束事件。节点监听到计算结束事件后，从合约中获取这一轮计算的全部结果，本地进行聚合，得到最终的热门话题向量

• 各个节点将自己已知的最热门话题上报给合约，同时查询未知的话题，就能得到最终的热门话题及热度了

总结

我们通过区块链和安全多方计算技术实现了多个企业节点数据不公开的前提下计算全局的最热话题排行。安全多方计算技术提供了多个节点间进行数据聚合计算的功能，而区块链在其中起到了计算协调和部分可信性保证的作用。

说到计算过程的可信性保证，仍然是目前的一个开放问题。用我们的全局最热话题功能来举例：由于最热话题的来源是企业内部未公开的文章、讨论等内容，并且我们无法看到最原始的文章、讨论等数据，那我们如何相信最后拿到的全局热度排行是可信的？

如果有一个节点在参与计算的过程中，不断的上报错误数据干扰计算结果怎么办？甚至是说，企业可以在信息中心内不断提交随机的文章和评论，来干扰计算结果。这样的情况下，我们如何相信最后的热度排行的正确性？

上述的两种情况，可以被总结成两个可信性问题：

• 数据来源可信

• 计算过程可信

对于第2个问题，我们可以在计算过程中嵌入零知识证明，来保证节点在计算过程中无法篡改数据。而第1个问题，目前似乎也没有完美的解法，针对信息中心的场景，我们只能要求企业不断在区块链上提交内容存证，然后在计算时证明自己使用的数据是之前存证的数据，这种方法可以提高企业的作恶成本，在一定程度上解决这个问题。

在整个功能的实现过程中，我们测试了多个国内外的MPC的开源框架，比如PySyft、百度的Paddle-FL、微众的FATE、矩阵元的Rosetta等，最终使用矩阵元的Rosetta完成了MPC部分的开发，在这里我们对各位隐私计算开源贡献者表示感谢：

https://github.com/LatticeX-Foundation/Rosetta

对于MPC相关模型和工具的介绍，我们推荐下面这个repo：

https://github.com/mpc-sok/frameworks/wiki