3月29日，「隐语开源社区开放日」活动顺利举办。隐语社区不仅在当日正式开源隐语SCQL多方安全数据分析引擎，这是业内首个将SQL 做到多方安全计算（MPC）技术的数据分析系统，提供工业级的多方安全联合分析功能，目前已在隐语 GitHub 社区开源，面向全球开发者免费开放推动隐私计算迈向更加易用，活动现场社区也广邀行业、企业、高校、科研的隐私计算开发者与使用者，开展了一场平等双向的开放交流。

(相关资料图)

社区互动零距离：小小便利贴走近与聆听开发者的关注

社区在现场设置了开放留言及拍照打卡区，“全同态加密的效率问题，多久才能产品化？”“MPC SQL 的具体落地场景有哪些？”“隐私计算市场规模？人才需求？”留言内容从技术性能的突破、到产业应用的前景、再到个人职业的发展，开放包容地探讨着关于隐私计算的方方面面。

开源生态全方位：企业、科研、社区之星分享共建故事与成果

活动邀请到各界代表共话隐私计算技术现状与未来趋势，内容核心紧紧围绕隐语代码共建&使用开展，联通隐私计算各层生态、内容视角涵盖开发者、使用者、共建者。浙江大学求是讲席教授、ACM/IEEE Fellow任奎为活动致辞，以数据要素为切入点，强调当前隐私安全石责任也是核心竞争力，隐私计算作为此间的核心技术之一，其开源是必要趋势、也是技术产业化加速的重要推动力。

蚂蚁集团副总裁兼首席技术安全、北京大学客座教授韦韬以《数据要素大潮的技术挑战》为题进行了演讲。拆解分析了数据要素密态发展三个阶段所面临的不同挑战，在此过程中，方法体系、平台框架、技术标准等方面都面临全新变革。“目前，我们密态时代处于计算密态化和大数据密态化中间，计算密态化中的安全挑战依然是行业中非常需要重视的问题；未来大数据密态化之时，核心则要拓展技术应用深度，才足以面对数据要素全面密态化的挑战。” 

隐语框架负责人王磊在现场发布中讲到：“在实际场景中，BI的应用面更广。对于大部分数字化转型起步较晚、正在进程中的企业，更多是通过一些规则、数据分析、人工分析的方式进行数据处理。数据要素市场化是要赋能行业应用和实体经济、是要驱动经济的整体发展。所以，BI数据分析将会逐渐变得越来越重要，隐私计算技术整体也会从顶层的企业逐步向下渗透。”

但是，BI的隐私计算面临着巨大的挑战，主要有如下几点：

第一，高应用性。刚步入数字化转型或者正在数字化转型进程中的企业，整体技术能力有限，高应用性对于他们来说就格外重要。SQL是平常使用最多的数据分析语言，使用上手门槛相对较低，但这项技术本身是非常复杂的，MPC（多方安全计算）技术也是非常复杂的。那么，使用SQL语言完成MPC（多方安全计算）并保证正确运行，则无论站在技术难度的角度，还是站在工作量的角度来讲，都是一个巨大的工程。

第二，即时性。SQL数据分析采用交互的方式，与AI建模不同，虽然需要调参，但本身交互没有那么强。但是SQL分析则需要频繁交互，此时对整体的响应速度和时间需求则更高，需要整个分析过程中都能够及时响应，如此对整体性能的要求也会非常高。

第三，安全性。多方安全计算需要保证中间结果没有任何信息泄露，而数据分析又需要看到每次交互的结果，并且需要通过频繁交互的结果调整下一个环节。两者之间天然存在矛盾。同时，SQL的灵活性非常高，如何保证基于多方安全计算的SQL分析整体的安全性也是巨大的挑战。隐语在这些方面提出了一些新思路，进行一些尝试和探索，也取得了一些成果，但是距离真正解决这些问题还有很长的路要走。

核心发布：隐语SCQL多方安全数据分析引擎

基于如此背景，王磊于开放日现场开源发布隐语SCQL多方安全数据分析引擎：

从技术上来看，隐语基于MPC技术内核的底层抽象SPU设备，创新实现了一种多方安全数据分析系统 SCQL。SCQL支持类 SQL 的查询语言，它继承了 SQL作为常用数据分析语言的普及性、易学性和高成熟度，同时还拓展了标准 SQL 的语义，可以描述基于多个数据参与方的安全数据分析任务。

如图是隐语SCQL的架构示意，它是一种多方合作语言，大致分成两个部分：上部称之为SCDB，构建了一个SCQL数据库，可以认为部分程度延续了一个传统SQL数据库的样式。对于用户来说，可以直接发起一条传统SQL请求，请求首先会经过Parser，转为抽象的语法树，再通过Planner成为Logical plan。这两个模块我们只做了少量的改动，基本也是基于开源技术。

最大的挑战在Logical plan到Execution Graph的过程，传输过程实际是一个优化的过程，原本他们之间的差异不大，但是在隐私计算场景，他们之间的差异就会变的非常大。Translator实际是进行多约束条件下的最优协议选择，这件事的本质是无论AI还是BI，隐语的整体设计理念是明密文混合，即在保证安全性的前提下，如能明文计算则尽量不进行密文计算，因为密文成本相对较高。在整个计算当中有安全性的约束，同时会有数据类型、数据来源，还有数据状态，数据状态还会随着计算过程不断发生迁移和改变，再加之每一个协议适用的模式是不同的。我们会根据所有这些约束，最终选择一个最优协议出来，这就是Translator的本质。

那么怎样理解最优协议？如上图举例，此处有四种Group By，这四种Group By是为了适应不同场景。第一种是明文Group By，当密态计算时，Group Key以及聚合表达式处于单边，直接调用即可，一个典型的明文计算场景，无需密态计算性能很好；第二种是当Group Key与聚合表达式分散在两边，但聚合函数是求和，此时可以使用同态求和Group By来实现，只需将聚合列进行同态加密后传输至Group Key列，就可以进行聚合计算，性能也相对不错；第三种是Vertical Group By，此时Key处于多方，这件事情变的更复杂，隐语提供了新的、非常高效的、非常巧妙的算法，可以将分布在多方的Group Key进行高效的合并；最后，如果所有以上优化都无法进行，也就是纯密态Group By，此时会以满足安全性为前提，进而选择一个性能最好的协议。

Translator进行优化后，就会下发至下部的计算引擎，如图展示三个party构成，具体情况中两方或三方，则与采用的协议有关。计算引擎会先将DB的数据读出并进行计算，图中右下是SCQL计算引擎的架构，其中包含很多算子实现，也是明密文的混合，明文计算直接使用Arrow进行计算，密文使用隐语已经开源的SPU，如果大家对隐语有了解，就知道两个密态计算引擎完成这个计算。

Translator在进行协议转换时会执行CCL检查，其本质上是数据拥有者可以对数据做约束定义，Translator转换时就根据约束执行检查，如果SCQL不满足安全约束条件，则会被禁止运行。

左侧是目前业内常见的多方安全分析保障模型，如前文所讲SQL是非常灵活的，解决安全性的问题无外乎两种方式，一个是事前审核，二是事后审计，事后审计很好理解，所有的执行都需要存证。事前审核现在更多是通过人工，本质把安全性责任完全抛给了用户。

假设Party1写一段SQL，此时因参与方是三方，所以Party2和Party3用户都需要审核SQL，确认没有问题再执行。这就产生两个问题：第一，对于审核者来说工作量非常大，因为SQL是频繁交互的，且难免在审核中存在疏忽误判；第二，还是与SQL的交互式相关，每一个都需要多方审核，用户的操作体验较差。

而CCL的作用如图右，在事前审核之前，数据拥有方设置一个针对数据的CCL，是一次性的设置动作，此后用户每次提交SQL时，都需先经CCL检查，确认通过才会执行下一步，否则被禁止不能执行。接下来可以进行事前审查，即可运行至多方数据分析引擎中。

既然有CCL的安全性检查，为什么需要事前审核这个模块呢？因为，此处需要强调CCL不等于安全。与ACL相类似，不满足CCL约束一定不安全，但是满足CCL约束也不一定安全，所以CCL只是提供了辅助的工具。

CCL描述是一个三元组，数据拥有者对某一列进行约束，针对某个参与方进行约束。如Alice与Bob进行数据分析合作，有三列数据，设置CCL针对salary一列要求Bob参与者只有使用了聚合函数之后才可以看到。如此，Bob必须对salary列进行聚合之后才可以看到结果且只能看到一个统计结果，不允许看到明晰列数据，这就是CCL约束。

王磊也提到，此次SCQL发布的功能为Preview版本，虽然目前这些能力尚不完备，但Preview版本已经能够满足很多的场景，并举了几个例子：

据悉，隐语SCQL计划会分别在6月、9月、12月开源更多能力。具体发版内容则将基于社区对Preview版本的反馈建议，酌情调整优先级。

现场除了隐语新版本核心开源发布，众多来自业界和学界的多位嘉宾也进行了主题演讲。英特尔产品安全和保障部高级总监郭伟、蚂蚁集团高级技术专家祝森林、浙江大学百人计划研究员张秉晟、中国信通院云计算与大数据研究所高级业务主管袁博、中银金科隐私计算实验室算法工程师石新蕾和厦门掌讯信息技术有限公司CTO王艺团，从技术和产业角度切入，带来隐私计算前沿分享。

（完整回放及文字实录欢迎前往「隐语的小剧场」公众号获取）

此外，来自北京邮电大学、厦门大学、浙江大学、厦门掌讯、Intel的社区之星也受邀来到开放日，任奎、深圳国家金融科技测评中心董事长钟剑以及韦韬，为这些高校、企业isv用户、行业企业的社区开放共建力量代表进行现场表彰。