从Sui推出的亚秒级MPC网络lka看待FHE、TEE、ZKP与MPC的技术博弈

原文作者：YBB Capital Researcher Ac-Core

图源：Ika

Sui 基金会提供战略支持的 Ika 网络，近期正式公开了技术定位与发展方向。作为基于多方安全计算（MPC）技术的创新基础设施，该网络最显著的特征是其亚秒级的响应速度，这在同类 MPC 解决方案中尚属首次出现。lka 与 Sui 区块链的技术适配性尤为突出，两者在并行处理、去中心化架构等底层设计理念上高度契合，未来 Ika 将直接集成至 Sui 开发生态，为 Sui Move 智能合约提供即插即用的跨链安全模块。

从功能定位看，Ika 正在构建新型安全验证层：既作为 Sui 生态的专用签名协议，又面向全行业输出标准化跨链解决方案。其分层设计兼顾协议灵活性与开发便利性，有一定概率成为 MPC 技术大规模应用于多链场景的重要实践案例。

1.1 核心技术解析

Ika 网络的技术实现围绕高性能的分布式签名展开，其创新之处在于利用2PC-MPC 门限签名协议配合 Sui 的并行执行和 DAG 共识，实现了真正的亚秒级签名能力和大规模去中心化节点参与。Ika 通过2PC-MPC 协议、并行分布式签名和密切结合 Sui 共识结构，想打造一个同时满足超高性能与严格安全需求的多方签名网络。其核心创新在于将广播通信和并行处理引入阈签名协议，以下为核心功能拆解。

2PC-MPC 签名协议：Ika 采用改进的两方 MPC 方案（2PC-MPC），实质上将用户私钥签名操作分解为“用户”与“Ika 网络”两个角色共同参与的过程。把原本需要节点两两通信的复杂流程（类似微信群聊里每个人私聊所有人），改成广播模式（类似群公告），对用户而言的计算通信开销也保持常数级别，与网络规模无关，让签名延迟仍可保持在亚秒级。

并行处理，把任务拆开同时干：Ika 利用并行计算，将单次签名操作分解为多个并发子任务在节点间同时执行，想以此大幅提升速度。这里结合了 Sui 的对象并行模型（object-centric model），网络无需对每笔交易达成全局顺序共识，可同时处理众多事务，提高吞吐量并降低了延迟。Sui 的 Mysticeti 共识以 DAG 结构消除了区块认证延时，允许即时出块提交，从而使得 Ika 可以在 Sui 上获得亚秒级的最终确认。

大规模节点网络：传统 MPC 方案通常只能支持 4-8 个节点，而 Ika 能扩展到上千个节点参与签名。每个节点仅持有密钥碎片的一部分，即使部分节点被攻破也无法单独恢复私钥。仅当用户和网络节点共同参与时才能生成有效签名，任何单一方均无法独立操作或伪造签名，这样的节点分布是 Ika 零信任模型的核心。

跨链控制与链抽象：作为一个模块化签名网络，Ika 允许其他链上的智能合约直接控制 Ika 网络中的账户（称为 dWallet）。具体来说，如某链（如 Sui）的智能合约若要管理 Ika 上的多方签名账户，则需要在 Ika 网络中验证该链的状态。Ika 通过在自身网络中部署相应链的轻客户端（state proofs）来实现这一点。目前 Sui 状态证明已被首先实现，使得 Sui 上的合约可以将 dWallet 作为构件嵌入业务逻辑，并通过 Ika 网络完成对其他链资产的签名和操作。

图源：Ika

Ika 上线后，有可能拓展 Sui 区块链的能力边界，也会给整个 Sui 生态的基础设施带来一些支持。Sui 的原生代币 SUI 和 Ika 的代币 $IKA 将协同使用，$IKA 会被用来支付 Ika 网络的签名服务费，同时也作为节点的质押资产。

Ika 对 Sui 生态最大的影响是给 Sui 带来了跨链互操作能力，它的 MPC 网络支持把比特币、以太坊等链上的资产，以比较低的延迟和较高的安全性接入到 Sui 网络，从而实现像流动性挖矿、借贷这类跨链 DeFi 操作，有助于提升 Sui 在这块的竞争力。因为确认速度快、扩展性强，Ika 目前已经被多个 Sui 项目接入，也在一定程度上推动了生态的发展。

在资产安全方面 Ika 提供的是去中心化的托管机制。用户和机构可以通过它的多方签名方式来管理链上资产，相比传统的中心化托管方案更灵活更安全。哪怕是链下发起的交易请求，也能在 Sui 上被安全执行。

Ika 还设计了链抽象层，让 Sui 上的智能合约可以直接操作其他链上的账户和资产，无需经过繁琐的桥接或资产封装流程算得上是简化了整个跨链交互的过程。而原生比特币的接入， 也让 BTC 能直接在 Sui 上参与 DeFi 和托管操作。

在最后一个方面，我还认为 Ika 还为 AI 自动化应用提供了多方验证机制，能避免未经授权的资产操作，提升 AI 执行交易时的安全性和可信度，也为 Sui 生态未来在 AI 方向的拓展提供了一种可能。

1.3 lka 面临的挑战

虽然 Ika 跟 Sui 紧密绑定，但如果想成为跨链互操作的“通用标准”，还得看其他区块链和项目是否愿意接纳。现在市场上已经有不少跨链方案，比如 Axelar、LayerZero，分别在不同场景中被广泛使用。Ika 想要突围，就得在“去中心化”和“性能”之间找到一个更好的平衡点，吸引更多开发者愿意接入，也让更多资产愿意迁移进来。

说到 MPC 但也存有不少争议，常见问题是签名权限很难撤销。就像传统的 MPC 钱包，一旦把私钥拆分发出去了，即便重新分片，拿到旧片段的人理论上还是有可能恢复出原始私钥。虽然 2PC-MPC 方案通过用户持续参与提高了安全性，但我觉得目前在“怎么安全、高效地更换节点”这一块，还没有特别完善的解决机制，这可能是一个潜在的风险点。

Ika 本身也依赖于 Sui 网络的稳定性和它自己的网络状况。如果未来 Sui 做了重大升级，比如将 Mysticeti 共识更新为 MVs 2 版本，Ika 也必须做出适配。Mysticeti 这个基于 DAG 的共识，虽然支持高并发、低手续费，但因为没有主链结构，可能会让网络路径更复杂、交易排序变得更难。再加上它是异步记账，虽然效率高，但也带来新的排序和共识安全问题。而且 DAG 模型对活跃用户的依赖非常强，如果网络使用度不高，就容易出现交易确认延迟、安全性下降等情况。

2.1 FHE

Zama & Concrete：除了基于 MLIR 的通用编译器，Concrete 采用了“分层 Bootstrapping”策略，将大电路拆成若干小电路分别加密，再动态拼接结果，显著减少了单次 Bootstrapping 的时延。它还支持“混合编码”——对延迟敏感的整数操作用 CRT 编码，对并行度要求高的布尔操作用位级编码，兼顾性能与并行度。此外 Concrete 提供了“密钥打包”机制，在一次密钥导入后可重用多次同构运算，降低了通信开销。

Fhenix：在 TFHE 基础上，Fhenix 针对以太坊 EVM 指令集做了若干定制化优化。它用“密文虚拟寄存器”替代明文寄存器，在执行算术指令前后自动插入微型 Bootstrapping 以恢复噪声预算。同时，Fhenix 设计了链下预言机桥接模块，将链上密文状态与链下明文数据进行交互前先做证明检查，减少了链上验证成本。Fhenix 对比 Zama，更侧重于 EVM 兼容和链上合约的无缝接入

全同态加密（FHE）：一种加密方案，允许在不解密的情况下对加密数据进行任意计算，实现输入、计算过程和输出全程加密。基于复杂的数学难题（如格问题）保证安全，具备理论上的完备计算能力，但计算开销极大。近年来，业界和学术界通过优化算法、专用库（如 Zama 的 TFHE-rs、Concrete）及硬件加速（Intel HEXL、FPGA/ASIC）来提升性能，但仍是“缓行快攻”的技术。 

可信执行环境（TEE）：处理器提供的受信任硬件模块（如 Intel SGX、AMD SEV、ARM TrustZone ），能够在隔离的安全内存区域运行代码，使外部软件和操作系统无法窥视执行数据和状态。TEE 依赖硬件信任根，性能接近原生计算，一般仅有少量开销。TEE 可为应用提供机密执行，但其安全依赖于硬件实现和厂商提供的固件，存在潜在后门和侧信道风险。 

多方安全计算（MPC）：利用密码学协议，允许多方在不泄露各自私有输入的前提下，共同计算函数输出。MPC 没有单点信任硬件，但计算需多方交互，通信开销大，性能受网络延迟和带宽限制。相对于 FHE，MPC 在计算开销上小得多，但实现复杂度高，需要精心设计协议和架构。

零知识证明（ZKP）：密码学技术，允许验证方在不泄露任何额外信息前提下验证某个陈述为真。证明者可以向验证者证明自己掌握某项秘密信息（例如密码），但无需直接公开该信息。典型的实现包括基于椭圆曲线的 zk-SNARK 和基于哈希的 zk-STAR。

图源：biblicalscienceinstitute

不同的隐私计算技术各有侧重，关键在于场景需求。拿跨链签名来说，它需要多方协同、避免单点私钥暴露，这种时候 MPC 就比较实用。像门限签名（Threshold Signature），多个节点各自保存一部分密钥碎片，一起完成签名，没人能单独控制私钥。现在还有些更进阶的方案，比如 Ika 网络它把用户当一方系统节点当另一方，用2PC-MPC 并行签名，一次能处理上千笔签名，而且可以横向扩展，越多节点越快。但 TEE 也能完成跨链签名，可通过 SGX 芯片运行签名逻辑，速度快，部署方便，但问题是一旦硬件被攻破，私钥也跟着泄露，信任完全寄托在芯片和制造商身上。FHE 在这块比较弱，因为签名计算不属于它擅长的“加法乘法”模式，虽然理论上能做，但开销太大，基本上没人在真实系统里这么干。

再说 DeFi 场景，如多签钱包、金库保险、机构托管，多签本身是安全的，但问题在于私钥怎么保存签名怎么分担风险。MPC 是现在比较主流的方式，如 Fireblocks 这类服务提供商，把签名拆分成几份，不同节点参与签名，任何一个节点被黑了也不会出问题。Ika 的设计也挺有意思，通过两方模型实现私钥的“不可合谋”，减少了传统 MPC 那种“大家商量好一起作恶”的可能。TEE 这方面也有应用，像硬件钱包或云钱包服务，用可信执行环境来保障签名隔离，但还是绕不开硬件信任问题。FHE 在托管层面目前没太大直接作用，更多是在保护交易细节和合约逻辑，比如你做一笔隐私交易，别人看不到金额和地址，但这和私钥托管没太大关系。所以这个场景下，MPC 更注重分散信任，TEE 强调性能，FHE 则主要用在更上层的隐私逻辑上。

在 AI 和数据隐私方面，情况又会有不同 FHE 的优势在这里就比较明显。它可以让数据从头到尾都处于加密状态，比如你把医疗数据丢到链上做 AI 推理，FHE 能让模型在看不到明文的前提下完成判断，然后把结果输出出来，整个过程中没人能看清数据。这种“加密中计算”的能力非常适合敏感数据处理，尤其是在跨链或跨机构协作的时候。像 Mind Network 就在探索让 PoS 节点通过 FHE 在互不知情的状态下完成投票验证，防止节点抄答案，保证整个过程的私密性。MPC 也能用来做联合学习，比如不同机构合作训练模型，各自保有本地数据不共享，只交换中间结果。但这种方式一旦参与方多了，通信成本和同步就成了问题，目前还主要是实验性项目居多。TEE 虽然能直接在受保护的环境里跑模型，也有联邦学习平台用它做模型聚合，但它的限制也明显，比如内存限制、侧信道攻击。所以 AI 相关场景里，FHE 的“全程加密”能力是最突出的，MPC 和 TEE 可以作为辅助工具，但还需要具体方案配合。

性能与延迟：FHE（Zama/Fhenix）由于频繁 Bootstrapping，延迟较高，但能在加密态下提供最强数据保护；TEE（Oasis）延迟最低，接近普通执行，但需要硬件信任；ZKP（Aztec）在批量证明时延可控，单笔交易延迟介于两者；MPC（Partisia）延迟中低，受网络通信影响最大。

信任假设：FHE 与 ZKP 均基于数学难题，无需信任第三方；TEE 依赖硬件与厂商，存在固件漏洞风险；MPC 依赖半诚实或至多 t 异常模型，对参与方数量与行为假设敏感。

扩展性：ZKP Rollup（Aztec）和 MPC 分片（Partisia）天然支持水平扩展；FHE 和 TEE 扩展需考虑计算资源和硬件节点供给。

集成难度：TEE 项目接入门槛最低，对编程模型改动最少；ZKP 与 FHE 都需要专门电路与编译流程；MPC 则需协议栈集成与跨节点通信。

四、市场的普遍观点：“FHE 优于 TEE、ZKP 或 MPC”？

似乎无论 FHE、TEE、ZKP 还是 MPC，四者在解决实际的用例中也存在着一个不可能三角问题：“性能、成本、安全性”。虽然 FHE 在理论隐私保障上具有吸引力，但并非在所有方面都优于 TEE、MPC 或 ZKP。性能低下的代价使 FHE 难以推广其计算速度远落后于其他方案。在对实时性和成本敏感的应用中，TEE、MPC 或 ZKP 往往更具可行性。

信任和适用场景也不同：TEE 和 MPC 各自提供了不同的信任模型和部署便利性，而 ZKP 则专注于验证正确性。正如业界观点所指出的，不同隐私工具各有优势与局限，没有“一刀切”的最优方案，好比对于链下复杂计算的验证，ZKP 可高效解决；对于多方需要分享私有状态的计算，MPC 更为直接；TEE 在移动端和云环境提供成熟支持；而 FHE 适用于极度敏感数据处理，但当前仍需硬件加速才能发挥作用。

FHE 不是“普适优越”，选择何种技术应视应用需求和性能权衡而定，或许未来隐私计算往往是多种技术互补和集成的结果，而非单一方案胜出。好比 Ika 在设计上偏重密钥共享和签名协调（用户始终保留一份私钥），其核心价值在于无需托管即可实现去中心化的资产控制。相比之下，ZKP 擅长生成数学证明，以供链上验证状态或计算结果。两者并非简单的替代或竞争关系，而更像互补技术：ZKP 可用于验证跨链交互的正确性，从而在一定程度上减少对桥接方的信任需求，而 Ika 的 MPC 网络则提供了“资产控制权”的底层基础，可以与 ZKP 结合构建更复杂的系统。此外 Nillion 开始融合多种隐私技术以提升整体能力，它盲计算架构无缝集成了 MPC、FHE、TEE 和 ZKP，以在安全性、成本和性能之间取得平衡。所以未来隐私计算生态将倾向于用最合适的技术组件组合，构建模块化的解决方案。

参考内容：

( 1)https://docs.dwallet.io/#:~:text=Ika has a native token,to authorities according to their

( 2)https://blog.sui.io/ika-dwallet-mpc-network-interoperability/

( 3)https://research.web3 caff.com/zh/archives/29752? ref= 416  

( 4)https://medium.com/partisia-blockchain/mpc-fhe-dp-zkp-tee-and-where-partisia-blockchain-fits-in-c8e051d053f7