1. 课程导入与全景认知
跨机构联合计算，指的是两个或多个法律上独立、系统上异构、管理上分治的组织，在不直接交换原始明文数据的前提下，通过密码学协议、可信执行环境或联邦学习等技术，共同完成统计、查询、建模或推理任务的一类工程实践。它的核心特征不是“把数据集中起来算”，而是“数据不动、计算动”——各方数据留在本地域内，只有加密中间量、梯度、分片或受控结果跨域流动。理解这一点，是理解后续所有安全机制的前提。
从业务驱动力看，跨机构联合计算通常由四类需求推动。第一类是合规约束：金融、医疗、政务数据受《数据安全法》《个人信息保护法》及行业监管限制，原始数据不得出域，但业务又需要跨机构统计与风控。第二类是数据价值密度不足：单一机构的样本维度有限，例如一家银行只有自身信贷记录，缺少他行的多头借贷信息，联合后才能提升模型区分度。第三类是成本与效率：相比自建数据采集渠道，联合计算复用他方已有数据能力，边际成本更低。第四类是生态协作：供应链金融、医保结算、跨行反欺诈等场景天然需要多方参与，联合计算是支撑这类协作的基础设施。
然而，跨机构联合计算面临的安全挑战远比单机构内部计算复杂。我们可以从“信任边界”角度梳理：参与方之间互不完全信任，甚至可能存在竞争关系；计算节点可能被入侵或作恶；网络链路可能被窃听或重放；结果可能被用于推断他方原始数据。具体而言，主要挑战包括：输入隐私（如何保证各方输入不被泄露）、中间态泄露（协议执行中的密文、梯度、分片是否可被反推）、结果授权（谁有权获得什么粒度的结果）、行为可审计（如何证明各方按约定协议执行）、身份与权限（跨域身份如何互认、最小权限如何落地）以及性能与安全平衡（同态加密、多方安全计算带来的计算与通信开销）。
工程化目标可以概括为“可定义、可度量、可验证、可运维”。可定义，指安全边界、参与方角色、数据流向、协议版本必须显式声明；可度量，指隐私预算、通信量、时延、准确率损失等指标可量化；可验证，指通过形式化分析、测试向量、审计日志证明协议按预期执行；可运维，指密钥轮换、节点扩缩容、异常熔断、版本升级有标准流程。这四点贯穿本课程全部章节。
为了把上述内容组织成可学习的路线，本课程按“认知—基础—协议—工程—运维—复盘”六个层次展开，共 30 章。下图给出课程全景路线图，同时标注了每层对应的核心问题与关键交付物，便于你在学习时定位当前章节在整个工程体系中的位置。
这张路线图不是简单的章节罗列，而是按“先建立边界认知，再掌握原语，再组合协议，再落地工程，再保障运维，最后复盘”的工程逻辑组织。第 1–4 章解决“为什么做、做到什么程度、谁参与、信任从哪来”；第 5–10 章解决“用什么密码学工具”；第 11–16 章解决“工具如何组合成可证明安全的协议”；第 17–22 章解决“协议如何变成可运行系统”；第 23–27 章解决“系统上线后如何持续安全”；第 28–30 章通过综合案例与攻防演练检验前五层能力。
作为导入，你不需要立刻掌握所有技术细节，但需要建立三个基本判断。第一，安全目标必须与业务目标同时定义：只谈“不泄露”而不谈“能算出什么结果”，工程无法验收；只谈“能算”而不谈“泄露边界”，合规无法通过。第二，没有绝对安全，只有可度量、可接受的风险：同态加密、MPC、TEE 各有安全假设与性能代价，选型本质是风险与成本的权衡。第三，跨机构联合计算是系统工程，不是单一算法：它涉及密码学、分布式系统、身份权限、运维审计、法律合规多个维度，任何一层缺失都会导致整体失败。
学习建议：每学完一层，回到本路线图确认自己能否回答该层的“核心问题”并产出对应“交付物”。例如学完基础层，应能针对一个具体场景（如两家银行联合反欺诈）说明为什么选秘密分享而不是同态加密，并给出安全假设与性能预估。这种“场景—原语—协议—系统—运维”的闭环思维，是本课程希望培养的核心能力。
接下来第 2 章将具体展开跨机构联合计算的典型业务场景与参与方角色，帮助你把上述抽象定义落到真实行业语境中。在此之前，请先记住本课程贯穿始终的一句话：数据不动、计算动；边界先定、协议后行；安全可度量、工程可运维。