注册
关闭
Hanada

Hanada

发布于 3周前 阅读数 4464

谁能建立隐私计算的“分布式数据湖”?

在信息时代裸奔,我们总会被数据挟持、出卖。因为你的数据不属于你。

时下,是应该聊聊数据和隐私的时候了。

2019年末,我曾把零知识证明、多方计算、可信执行环境等隐私计算技术的代表项目汇聚到一起做了一期极为深度的讨论。

那时,在区块链产业分布里已经有了隐私赛道,有少数项目在研究、拓展、尝试,只是对于隐私、隐私计算以及数据等维度并没有那么清晰的判断。

把时间线放的更长一些,从2018年至今,我们其实看到了隐私项目向隐私计算的迭代(两个技术标签很早就存在,但行业关注点有了迭代),这一现象代表了一些技术的发展和应用的趋向性。

在对这些项目分析解构,对市场需求进行考证后,笔者认为此时该提出一个有效的观点。

即:当今的区块链隐私计算项目里,谁想拿下隐私计算第一枪,要率先建立隐私计算的“分布式数据湖”。

原因很简单:数据存储在数据库里并不能直接产生价值,只有经过数据训练才有价值,也就是数据要有为深度学习、联邦学习服务的能力,而数据湖是这个路径里的必然选项,基于去中心化模型里,会出现新的“分布式数据湖”。

本文里,我会为这个名词开个脑洞,在符合逻辑推演的范围内为大家阐述一个框架。但这种模型目前并未有非常成熟的案例,如有偏颇,欢迎各位指证。

先谈一谈什么叫数据湖

数据湖的概念,来自大数据和机器学习业务。

我们日常一定听过数据库,数据库的形式可大可小,是非常独立的数据存储单位,每个数据存储位置都是一个数据库,当数据库之间被打通,形成一个大数据交互结构,就可以理解为数据湖的形象。

笔者在亚马逊的AWS Lake Formation服务定义里查到了数据湖的名词定义:

数据湖是一个安全的集中式辅助存储库,它以数据原始形式和可用于分析的形式存储所有数据。利用数据湖,可以分解数据孤岛并组合不同类型进行分析,获得分析结果指导更好的业务决策。

所以我们可以理解为,当若干个原始存储的数据库连接起来,就是数据湖。但这个数据湖怎么工作呢?

这一段描述可以粗略看到一些工作需求。

“设置和管理数据湖包括加载来自不同来源的数据、监控这些数据流、设置分区、打开加密和管理密钥、定义转换作业并监控其操作、将数据重新组织成列格式、配置访问控制设置、删除冗余数据重复数据、匹配链接记录、授予对数据集的访问权限以及随时间推移审核访问权限。”

所以数据湖的主要功能是数据的交互,而处理其关键问题是加密和数据集的访问权限。在我们所期待的去中心化数据湖里,似乎也是如此。

再谈一谈我们期待的去中心化数据结构

去中心化的数据结构,是去中心化的隐私计算的基础,很简单,就是数据是分散在生产者处,存在于我们的手机、电脑其他终端设备里。

当然,手机数据大多是有缓存的,有些数据是短时存储,我们所看到的那些互联网App收取用户的数据,都是其所需要的数据,而这些数据有些实时产生,在缓存里,有些存储在本地存储里。我们虽然在本地可以操作查看,但平台也可以随时拿走数据,因为所有权并非在用户这里。

在去中心化的数据结构里,数据在本地存储,还需要把所有数据加密,并且你所使用的App无法获取你的数据,除非你主动向App提供交互,或者允许授权。

这个场景里,我们期待的是:平台在没有授权时是拿不走我们的数据的。但这仅代表的是成型的存储数据。而我们有很多的数据,是需要经过中心化服务器处理的。

例如加入一个社交媒体,我们的用户名,手机号,邮箱等等数据都是容易暴露的,理想状态下,他人对我们选择不公开的数据不可见,而关键的是,平台也要对数据不可见,或者不可用。

这需要平台具备一些基本的功能,而平台的功能,一定是其背后开发功能中的体现,这就有关于我们知道的区块链项目了,例如账户ID具备隐私功能,信息访问权限的设定。

我们看到保护隐私的区块链项目,都会在这方面努力。

不过区块链和加密货币有一些天然隐私特性,例如区块链的归属权、加密货币的无需许可以及地址的匿名性。

只是当数据真的形成一定的体量之后,大部分的业务都与生活息息相关,所以匿名性之后会有kyc,kyc后,数据的隐私和隐私计算,无可厚非的成为最重要组成部分。

区块链世界里,谁能建立数据湖?

互联网大数据技术早已和云计算融合多年,在传统云计算里,AI需求的数据湖对数据的控制已经变得很简单,进展到了SaaS级别。

例如上文的AWS Lake Formation其创建过程很简单,只需定义数据源,制定要应用的数据访问和安全策略就行。Lake Formation模块会帮助使用方从数据库和对象存储中收集并按目录分类数据,将数据移动到新的数据湖里,使用机器学习算法清理和分类数据,并保护对敏感数据的访问权限。

而对外表象是,使用方建立应用的用户可以访问那些描述了可用数据集及其适当用法的集中数据目录。然后,用户可以通过所选的分析和机器学习服务,利用这些数据集。

简而言之,这个逻辑把分布在各处的数据,最终在数据服务上体现了价值,这是去中心化世界里,很多项目想要实现的,如果只是简单的把数据控制在用户手里,那用户仍只是体验了平台的服务,而并非将数据可以变现,虽然说数据token化就可能有交易价值,但这种交易价值暴力程度远不及在人工智能里实现的产业价值。

例如,如果微信去中心化了,我们在微信的行为数据就再也不会直接拿走被利用到广点通里,你的朋友圈里不会出现“你刚刚和其他人说过的”你想买的物品,也不会被粗暴的推荐某些产品。

区块链项目想实现这样的愿景,但发展之路可能略有曲折。因为这样的应用很难实现。

我们看到的区块链项目,除了Defi、Nft这些应用层项目,其他都是基础设施,而以区块链的基础设施,性能很难完成互联网平台的业务需求。

当随着区块链以及加密货币不断扩展,网络中的用户增加,每个地址的关联数据也开始增加,所有用户的数据集中呈现了庞大的规模。这些存在本地的数据,就也组成了庞大的数据集群。

在这基础之上,能实现数据湖的,并不多。因为实现数据湖,需要单独的算力、存储、算法等等。在区块链项目的设计里,这个部分可能需要单独的一层网络,或某一个参与网络建设的角色。

大部分区块链项目并不能建立这样的功能,因为大部分区块链项目的网络只有能力维持Defi项目的运行,而缺乏足够的存储和计算能力。

除存储和算力外,在这基础设施里,需要有去中心化的数据结构,例如以DID为单位的用户数据,需要有算力和存储的经济模型,还需要有安全的代码和便于开发应用的中间件。

这些都让隐私计算的项目屈指可数。

当然我们这样判定的前提,是我们所指的隐私计算,是关于数据的隐私处理。而并非简单通过合约执行的匿名、混币、交易隐私等等。

在交易处理分层的概念已经在加密货币项目设计里得到共识后,我们期待的是区块链负责数据的权益证明,而其他层控制的算力和存储,完成隐私计算。

定义一个可实时的框架

在文章的最后,我们用数据湖的最终命题,去推论出一个加密货币隐私项目的设计框架。通过这个框架,可以部分对比如今市面上的隐私计算项目。

首先,区块链为加密货币项目提供共识层的总帐本。在这个总帐本里,是所有公开留存的数据证明。

接下来,是如何将项目设计为具备隐私计算能力。

从初代的隐私项目看,主要是增加了匿名性和交易隐私,例如具备混币合约的隐私币,其可以将合约当作一种dapp服务,让代币进入合约之后的操作无法查询。这样的设计,主要是在链上部署合约,可能会使用密码学算法或者零知识证明等标志性技术,以保证交易过程在不可见的情况下正确执行。

而如果是有硬件要求的隐私计算设计,那在前文我们所提到的区块链网络,其网络节点搭建,就需要特殊的设备,或者在区块链共识层外,再次搭建一个由特殊设备组成的计算网络。

例如通过集合具备TEE计算区的硬件设备连接成网,就可以利用TEE保护区块链上的交易执行、合约执行等,TEE是对计算进行的物理保护,有一些独特的通信方式,让可信计算区和其他需求点交互。

而如果区块链网络具备MPC等对计算要求较高的技术部署,就需要搭建区块链网络的节点设备经过特殊定制,或者在区块链共识层外,建立一个layer2计算、存储层,将算力和存储都共享出去,提供数据隐私计算需要的资源。

有趣的是,因为MPC很多情况下还是依靠加密算法,为了更周密的隐私部署,MPC和TEE会在非区块链的可信案例里组合应用比较多,而MPC在区块链项目里,与零知识证明、加密算法融合应用比较多。

当我们确认了有足够的算力和存储资源。

一旦需要数据湖,如AWS数据湖模块一样,需要建立数据湖,并且定向收集需求点位的数据,汇集后,对数据所有权进行分类,在数据湖里,除了数据所有权外,进行机器学习训练的训练方,数据执行方等都需要明确对数据湖的权限,例如训练方可能具备管理训练算法的权限,而其对部分数据是可用不可见。

数据最终的价值表现,与数据在训练等过程中的作用也需要在数据湖的作用中进行评估。而这些辅助的计算都是基本功能,数据在数据湖的进进出出都会在区块链上留下公开的痕迹,以保证所有权的公平。

最后,当技术上完善之后,就是数据变现后的权益分配,需要对数据贡献进行定义,可能需要通证化的量化工作来实现公平的分配。

以上的参与者,理想状态下,是很多方。而将这个模型放小,可能只会关于如今具备数据交叉训练需求的几方。

因为大部分数据的处理难度也是显而易见的,例如数据的清洗、筛选、脱敏等等。

但如果这种模型已经成为标配,必然会有一个标配的经济模型支持,例如这些资源的消耗需要需求者买单。而数据的训练结果,可能将塑造下一个惊艳的产品。

如果我们只是因为自由选择区块链网络,那你也许会因为产品体验的不自由而离开,但如果你希望可以通过数据塑造价值,那必然要等待你的数据可以因为隐私计算变得有价值,并且这个价值可以回归于你自己。

那个时候用户才不会因为数据成为待宰羔羊,因为你可以对不认可的授权者say no,拿好你的个人数据库。

PS:文章篇幅有限,接下来笔者会继续完成一些补充文章,例如数据湖中的数据仓,例如权益分配的详细方案。敬请关注《金色深核》栏目的后续文章。

  • 0
Hanada
Hanada

0 条评论