我们为什么需要模块化ZK服务Modular ZK As A Service（MZaaS）？

前言

至今为止，我们在 Web3 体验到的绝大部份协议都是具备一定程度的信任假设，当我们希望进一步追求“去中心化”时，我们不可避免地要牺牲一部分的隐私性。比如当协议提供 MEV-Protection 的时候，大概率使用的是 Private Mempool，用户需要假定这部分的节点提供方将诚实地工作，即存在第三方的信任假设，而事实上这对于所有的协议皆如此——存在一定程度的信任假设。根据我们先前一份研报观察，对于机构、大户而言，隐私保护是他们考虑是否将资产迁移链上的重要因素之一。这也意味着，一些第三方链上数据平台可能会加剧 MEV-Searcher、黑客对大户、机构的针对性攻击，因此引入链上隐私保护无疑天然适配他们的需求。

在此之前，我们也写过隐私赛道上针对暗池交易的项目 Singularity 的研报（扩展阅读：）。

那么问题来了：对于隐私保护，我们可以做什么？

常规听到的四大隐私计算方案有：全同态加密（FHE，Fully Homomorphic Encryption）、多方安全计算（MPC，Muti-Party Computation), 可信执行环境（TEE，Trusted Execution Environment）和零知识证明（ZKP，Zero Knowledge Proof）。他们其实在解决的是不同情况下的场景需求。

首先，对于加密数据而言，这串数据的所有权决定于谁拥有了解密/加密密钥。通常来看，隐私数据可分为个人可见、团体可见。

• 个人可见数据（Personal Private State）：数据仅能被一个主体看见并改变，比如个人余额。
• 团体可见数据（Shared Private State）：数据在保证隐私性的同时可被多个主体用于计算，比如流动性池里的余额。

对于 FHE，MPC，TEE 来说，他们都可以解决团体可见数据的难题。但是，FHE 要求高昂的计算资源，MPC 要求所有验证者在线，TEE 要信任服务提供商。当前行业对这几者的探索仅适配少数场景，比如暗池交易、私钥管理等。而虽然ZKP输出的结果信息有限（即“是非”题），并大多仅适用于个人可见数据，但其应用场景被现在的用户充分探索，比如跨链桥、Layer2、KYC 等。即便在未来，如果 FHE 和 MPC，乃至其他隐私计算方案的盛起，也不会因为蚕食效应/市场竞争而舍弃 ZKP，因为：

1. ZKP + FHE：比如采用了 UTXO 模型的 ZKVM 链，如果要验证每笔交易，验证者要下载整个 Merkle Tree 并且一个个地去解码才可以进行验证，所以引入了FHE可以在无需解码的过程下计算出同样的结果。
2. ZKP + MPC：比如采用了 MPC + ZKP 的暗池，用户可以在保证自身隐私的情况下进一步保证交易的原子性。
3. ZKP + TEE：比如对于 ZK-SNARK，生成 Common Reference String（公共参考字符串）可以由运行 TEE 的节点进行，以确保中间的信息不会泄漏。

我们可预见 ZKP 的广泛应用场景将井喷式出现，但是这种需求以当前主流的 Layer1 来看，还难以承担，不仅要面临高昂的 Gas Fee 还需要等候网络进行验证。而 Modular ZK As A Service（MZaaS）作为一个 ZKP 服务商的设计框架很好地解决了上述问题。MZaaS 提供一系列 ZKP 相关服务以减低ZKP 生成复杂度以提高效率。而这些服务可以进一步拆分成以下子类别：

• Proof Marketplace：主要以 Requester-Prover Separation 概念出发，通过拆分不同场景下的 Prover 以利用闲置 Prover 资源以提供公开 Proof 市场。可参考的项目有 Mina、=nil;、ZKPool。
• Verification Layer：主要以 Aggregation 概念出发，证明者收集多个证明并生成一个新的证明，以证明初始证明的有效性，并通过提供验证层以降低验证过程的成本。可参考的项目有 Aligned Layer、Horizen、Cloaking Layer(zCloak Network)、Nebra。

ZKP 该如何理解？

在了解 ZKP 市场之前，想让我们对 ZKP 生命周期有一个整体的概念。基本上 ZKP Proving System 都遵循下述的流程：

1. Prover（证明者） 声明他知道某一信息，基于此问题以约束系统进行表达。
2. 根据制定的约束系统生成电路
3. Prover 输入符合该电路的解决答案（Witness）以计算出 ZK Proof
4. Validator（验证者）可对 ZKP 进行验证以辨认 Prover 是否真知道该信息

假设现在我们有一个用于记录用户账户余额的 Merkle Tree，正常情况要更新账户余额，我们需要按照下述流程进行：

• 验证发送方和接收方在叶节点记录
• 验证发送方的签名
• 更新发送方和接收方的余额
• 更新 Merkle Tree 的 Merkle Root

但在 ZKP 加持下，这个流程按照如下进行：

1. 将验证 Merkle Tree 的过程完整地构建成电路
2. 将更新前后的 Merkle Tree 和该交易记录（某人给 A 发了$10）当作输入，计算出 ZKP
3. 验证者对 ZKP 进行验证（以 ZKP、验证密钥和公开输入当作输入），如果输出结果为正确，那么该交易视作为可信。

在这个过程中，验证者本身无需对 Merkle Tree 进行反复验证，只需相信验证结果即可（前提是电路构建无误）。

如果从高纬度进一步将 ZKP 拆解，那么从定义问题到构建电路的过程都是前端进行（以高级语言编译），而后端（以低级语言编译）负责将这个电路嵌入/结合某一证明系统以生成 ZKP，具体来看是先将电路结合 Information-Theoretic Protocol，后以 Cryptographic Compiler 进行编译成一个适用的 ZKP System，比如 Groth16。

性和完整性的能力。健全性是说，如果一个声明在证明系统中得到证明，那么它就是真的。完备性则保证，如果一个声明为真，那么它在系统中是可证明的。

1. Interactive Proof (IP)： 验证者向证明者提出一系列 "随机 "问题。证明者做出回应。这种情况会持续很多轮，直到验证者确信证明者的陈述是正确的。
2. Probabilistic Checkable Proofs (PCP)：Proof 被转换成一种固定大小的格式，称为 "证明副本"。验证者可以随机查询副本中的少量数据进行验证证明。为了让证明者就无法提前预测查询值并准备伪造的证明，可以引入预言机（Oracle）生成随机值以让验证人用于随机查询。理论来看，这个方式比较有效，但是从验证者流程来看，相对效率较低。
3. Interactive Oracle Proof (IOP)：证明者和验证者相互交互，并可访问随机示例。IOP 通过使用部分数据副本来降低通信和查询的复杂性，从而提高了交互式证明的效率。这也是目前 ZKP System 常用的证明系统。

前面提到的 Information-Theoretic Proof System 都做出了在现实生活中难以实施的理想假设。例如，它可能假定验证者是可信的，对证明的访问受到限制。但 Cryptograph 的特性使得这些假设在特定环境下可以实现，例如常见的数学难题：

1. The Integer Factorization Problem：比如 RSA 的安全性依赖于大数的因子分解。
2. The Discrete Logarithm Problem：Diffie-Hellman Key Exchange 依赖于大数的离散对数计算。
3. The Elliptic Curve Discrete Logarithm Problem：Elliptic Curve Cryptography(ECC) 依赖于有限域的椭圆曲线和复杂的椭圆曲线离散对数。

Information-Theoretic Proof System 和 Cryptographic Compiler 结合后，便可以得到 ZKP System，因此 ZKP 的各项特征都会随着组合不同而出现改变：

• 计算方式：一般计算有两种主要模式： 电路和图灵机。虽然大多数主流编程语言都试图描述图灵机的计算路径，但对于加密计算来说，图灵机并不是最高效的编程模型，所有更高效的编程模型通常都会大大增加复杂性，从而使加密协议复杂化。因此，人们使用电路来代替图灵机，因为电路可以非常容易地表达许多直接语句，但其取舍是用户需要对处理的计算进行预处理。
• 计算成本：对于不同结合的情况下，验证者、证明者、通信的成本会不一样。比如在 PCP + Collision-Resistant Hash Function（CRFS）结合的 ZKP 系统，其计算成本如下：

• 抗量子：一些加密算法可以有效抵御量子计算机的暴力破解，比如 ZK-STARK 采用的 Collision-Resistant Hash Function 在当前发展下，量子计算机无法直接破解。但仍会存在被破解的风险，比如有两位山东大学的学者在 2009 年发布的论文中讲述了如何破解 SHA1 和 MD5。因此我们仍需要有信任假设。
• 可信配置：可信配置通常两大类：Uniform Reference String（URS），URS 生成的随机数是公开可见的，意味着这个“随机性”是公允的；Structured Reference String（SRS 分两种，Universal Setup 和 Specific Setup，前者允许多个主体参与生成随机数，通常会以 MPC 的方式进行，后者允许针对某一特定场景参与生成随机数。

如果在点对点的场景中，做恶分子知道该随机值，那么他可以伪造该系统的输出并生成正确的 ZKP。

从上文也可以看出，不同的结合可以延伸出多种类型的 ZKP 系统。概括来说，主要可以分为 ZK-SNARK、ZK-STARK 和 Bulletproof，以下几个核心差别，可以方便我们更好理解：

• 可信配置：ZK-SNARKs 通常会采用了可信配置，ZK-STARKs 和 Bulletproof 则无需这类配置。
• 计算成本：
  • 证明时间：Bulletproof > ZK-SNARKs > ZK-STARKs
  • 验证时间：Bulletproof > ZK-STARKs > ZK-SNARKs
  • 通信复杂度/证明大小：ZK-STARKs > Bulletproof > ZK-SNARKs ，但是当数据量提高的时候，ZK-STARKs & Bulletproof 所需的存储空间则会比 ZK-SNARKs 小。
• 抗量子性: ZK-STARKS 通常具备抗量子性，ZK-SNARKs 和 Bulletproof 则无需这类特性。

Zero-Knowledge Proof 市场潜力与规模

目前 ZKP 赛道主要以两大方向发展：隐私、扩容。

扩容方案

主要指的是采用了 ZKP 作为提高可扩展性的解决方案，包括 Layer2 可用性证明、跨链等。目前常见的方案有 Starknet、ZKsync、Polyhedra等。通常可以分为 Layer1/Layer2、协议两种构建体系。在 Layer1/Layer2 构建体系中，Rollup 交易和应用程序在 ZKEVM上执行，并具备零知识证明特性。一个理想的 ZKEVM 应该是等效于 EVM，意味着可以完全兼容 EVM 现有的协议、开发体验。根据Vitalik 博客中提到，当前的 ZKEVM 共可分成 5 个类别：

• Type1：完全等同于以太坊，其状态或交易树、哈希代码或其共识中的任何其他逻辑都不会发生变化。Type-1 将与所有以太坊本地应用程序完全兼容，但需要更长证明时间，因为没有进行任何预编译来加快证明生成速度。当前可参考的项目有 Scroll、Taiko。
• Type2：外表与以太坊相似，但内部略有改动，比如状态树、区块结构等，以方便开发并加快证明生成。当前可参考的项目有 Polygon Hermez。
• Type2.5：通过提高 Gas Fee 来限制部分 ZK 功能以减少潜在的验证时间，本质上治标不治本。
• Type3：可能会删除一些在 ZK-EVM 实现中特别难以实现的功能。此外，有时在如何处理合约代码、内存或堆栈方面也会有细微差别，因此对以太坊兼容性会更弱。这个类别更像是产品发展过渡期，而不是一个产品定位。
• Type4: 用高级语言（如 Solidity）编写的智能合约源代码编译成某种明确设计为 ZKP 系统 友好的语言，如 Cairo。虽然证明时间可以加速。但是其兼容性最差，比如某些使用了以太坊字节码开发的 DApp可能无法进行迁移。当前可参考的项目有 ZKsync和 Starknet。

以太坊设计之初也没有设想未来会以 ZKEVM 的的方式进行扩容，因此开发难度无疑是很高的，因此 ZKsync、Starknet 的选择也是为了尽早推出市场一个泛用型的 ZKEVM，而事实上他们应当被称之为 ZKVM，因为他们对以太坊的兼容性（面向开发者）比较低，但换来的则是更高的架构灵活性、更低的 ZKP 生成成本。

这类型的 ZKVM 可以脱离 EVM 体系的限制成为一条 Layer1，开发人员用高级语言编写针对特定虚拟机架构的代码，然后编译成 ZK 电路，或者使用特定领域语言（DSL）（如 Circom）编写代码，直接生成 ZK 电路。

如果单独考虑 ZK Layer2 市场规模，根据 L2Beat 数据来看，目前 ZK Layer2（包括 ZK Rollup、Validium）的 TVL 大概有 $5.015 B，占总 Layer2 中 Layer2 TVL 和以太坊 TVL 分别是 10% 和 7%。如果将 OP Rollup 市占率作为 Benchmark，ZK Rollup目前还有大概 10 倍 TVL 的增长空间，预计推出额外 10 – 12 条新的 ZK Layer2。

当中 Linea、Starknet 和 ZKsync 为前三，分别占有 $1.22 B，$1.06 B, $855 M，Three-Firm Concentration Rate为 62%，意味着当前 Layer2 竞争被少数项目垄断。进一步观察 Layer2 TVL 增长情况，TVL 增速主要出现在 2024 年 2 月 20 日，其原因是 Starknet 原生代币的流入&增值，目前链上仍保留着 75% 的 Starknet 原生代币。

当中 Linea 属于 Type2 ZKEVM，Starknet 和 ZKsync 为 Type4 ZKEVM。且前三名都为 ZK Rollup 而非 Validium，前者以以太坊作为 DA，后者 DA 将放在链下由 DAC 管理。在 Validium 中，Immutable X 的 TVL 达到近 $200 M，位列第一。另外值得注意的是，OP Rollup 中，TVL 最高的前 10 个 Layer2 大多都是采用了 OP stack，意味着某一 Stack 的市场占有率很高。但在 ZK Rollup 中，TVL 最高的前 10 个 Layer2 基本选择开发自己的 ZK Stack。

除了上述 Layer1/Layer2，ZKP 在扩容的主要场景还有协议层，比如跨链。跨链中引入 ZKP 主要服务于轻节点验证、Maker&Sender 的跨链基建，比如 Polyhedra、Orbiter Finance 等。在轻节点原本验证过程中，目标链部署的合约需要持续地获取源链的区块头以做后续的跨链信息校验，将不可避免地消耗 Gas，但如果将校验过程放在链下，链上只储存一个 Commitment，那么这个存储成本将会大幅减少，且不会因为源链的更新频率越高，而 Gas 成本越高。而 Commitment 的构建方式可以用 ZKP 进行，可以有效地压缩一笔或多笔交易。在 Maker&Sender 模式，ZKP 结合了欺诈证明，进一步减少了 ZKP 生成。在市场规模方面，以 Orbiter Finance 为例，虽然目前每个月大概有 $628 M 交易量和 $1.48 M 的 TVL，但是在高周转的情况下，ZKP 的需求也会提高。

隐私方案

主要指的是以 ZKP 作为其隐私安全保障方案的协议/网络，包括 Zcash、Aztec、Tornado Cash。

与注重扩容的发展方向相比，注重隐私的解决方案的开发工作较少。现有的隐私应用主要集中在支付隐私方面，可编程性不高。将隐私和可编程性结合起来是一项具有挑战性的任务。注重隐私的解决方案有两种构建方式:

• 协议：这些协议主要使用 ZKP 创建私人资金池。用户通过这些私人资金池作为隐私保护方案，比如 Tornado Cash。对于这些应用，证明由用户执行，验证在链上进行。由于 Layer1 没有对加密计算进行设计，因此对于主流用户来说，验证成本往往很高，从而限制了这些应用的采用。直观的解决方案是将私人交易应用转移到 Rollup 中，以降低 Gas Fee。在这种情况下，私人交易证明需要包含在 Rollup 证明中，即递归证明，而目前以太坊上的常规 ZK Rollup 还无法做到这一点。
• Layer1/Layer2：这些 Layer1/Layer2 主要通过 ZKP 实现的隐私保护，比如 Manta Network 和 Aztec。大多数以隐私为重点的链还不能支持通用计算，只能专注于特定场景用例。例如，Penumbra 和 Renegade 专注于私人交易。这些 Layer1/Layer2 采用的账户模型可以分为：Account-Based 和 UTXO-Based。两者各有缺陷：前者可能会因为交易路线泄漏部分隐私并且需要串行处理，而后者在验证、更新交易余额的时候都需要对每个子节点进行解密才可以正确查询。

根据 Defillama 显示，当前隐私赛道 TVL 大概为 $709 M，Three-Firm Concentration Rate占据接近 99%，分别是 Tornado Cash（$595 M）、Railgun（$96.97 M）、Aztec（$9.45 M）。其中 Tornado Cash 和 Railgun 为协议，Aztec 属于Layer2。

其中 Tornado Cash 面临着合规性的打压，也意味着很多“合规隐私“需求将逐步迁移到其他协议、网络，Concentration Rate 只会逐渐下降。另外，市场目前很多的第三方数据平台、中心化节点提供商都有损抗审查性，部分大户、机构希望通过更安全、隐秘的方式进行大额资金转移。截止 6 月 3 号，受 OFAC 审查的区块大概有 37%，这些是公开 Mempool 所无法避免的。

这也进一步延伸了合规性的要求，因此 KYC 等服务商也十分重要。但往往用户还是希望最大程度保有个人隐私，ZKP + KYC 的潜在场景会随着隐私交易的提高而提高，目前市场的主要服务商是 zCloak，zkMe 等。在传统 KYC 过程中，当我们需要委托多个 KYC 服务商时，我们需要进行反复的验证，但在 ZKP + KYC 的情况下，其他服务商可以尝试验证该 ZKP 以保证身份有效性。而且 KYC 过程中，服务商需要记录一些必要信息，比如身份证等敏感信息，如果在多个服务商进行，那么信息泄露风险也会线性激增。

ZKP 现在面临什么问题？

正如我们之前提到的，ZKP 生成需要大量計算资源。以常见的 ZK-Rollup 为例，ZKsync 的 ZKP 生成时间大概是1个小时。进一步拆解的话 ZK-SNAKS 的ZKP生成过程主要涉及多标量乘法（Multi- Scalar Multiplication，MSM）和数论变换（Number Theoretic Transform，NTT）。这两项过程就能占到证明生成时间的 80% 到 95% 。而 ZK-STARKs 虽然用了不同的算法，但也同样面临低效率的问题。

另外近年来，ZKP 系统提供了一系列不同权衡的选择，种类繁多且不断地扩展。例如，更快的证明速度的取舍是更大的证明大小或内存使用量。具有各种定制功能的证明系统种类繁多，并在不断扩展。但以太坊并不能够支持不断发展的证明系。例如，只有 BN-254 椭圆曲线能够在低成本基础下支持。但如果迁移到更安全的曲线（如 BLS12-381），是很复杂的任务，更别说要去兼容新的 ZKP 系统。

再者，在 Layer1 验证 ZKP 方面，验证 STARK 的成本约为 5,000,000 Gas，而基于 Plonk 的证明则低于 290,000 Gas fee。如果直接在以太坊中验证的证明系统，目前有几个局限性，例如，基于内积论证的证明系统，如 Mina 的 Kimchi（通过 Pickles 实现高效递归）或基于 Brakedown 的 Binius（具有平方根大小的证明），他们所涉及的运算量或证明大小比较大，因此验证成本也会十分昂贵。为此我们可能需要转制成 Ethereum-Friendly 的 ZKP。

模块化 ZK 服务如何加速 ZKP 过程

因此如何提高效率成为了下一个 ZKP 发展要探讨的方向，除了在算法/电路上进行改变，当前主要的解决方案可以分为两大类：

• Hardware Acceleration： 通过改善硬件以提高 ZKP 生成过程。GPU 通常对 ZKP 验证时间的改善有限，另一种选择是使用专用硬件，如 FPGA 或 ASIC，进而延伸出 Hardware Abstraction Layer，可参考 AI 云服务。由于本文重点不是讨论硬件加速，便不进行细致探讨。
• Modular ZK-As-A-Service（MZaaS): 通过提供一系列 ZKP 相关服务以减低 ZKP 生成复杂度以提高效率。而这些服务可以进一步拆分成以下子类别：
  • Proof Marketplace：主要以 Requester-Prover Separation 概念出发，通过拆分不同场景下的 Prover 以利用闲置 Prover 资源以提供公开 Proof 市场。可参考的项目有 Mina、=nil、ZKPool。
  • Verification Layer：主要以 Aggregation 概念出发，证明者收集多个证明并生成一个新的证明，以证明初始证明的有效性，并通过提供验证层以降低验证过程的成本。可参考的项目有Aligned Layer、Horizen、Cloaking Layer(zCloak Network)、Nebra。

Proof Marketplace

首先，我们从上文应用场景中能够发现，ZKP 的应用场景中并不是所有交易都会进行生成，所以我们可以归类为两种生成方式(以跨链为例）：

1. 全 ZK (Full ZK)：每一笔交易都会生成 ZKP。比如 ZK Bridge 的每一笔交易，Maker 都会生成 ZKP 用于验证。
2. 半 ZK (Half ZK)：只有满足特定条件下才会生成 ZKP。比如 Orbiter Finance 当出现错误、不可信的交易信息的时候才需要生成 ZKP。

所以在 Half ZK 场景下，不是所有的 Prover 都充分利用。当我们将 Prover 的角色拆分成 Requester和 Prover，并且创建出 Prover 共享平台/Marketplace，就能够提高 Prover 的利用率，并在 Full ZK 的场景中潜在减少 ZKP 生成的所需的时间。但问题来了，如何选定 Prover？

如何选出 Prover 的具体设计其实可以分多个维度思考：Performance、Cost、Decentralization。本质上跟共识机制的不可能三角相似，比如选择了多节点验证以确保去中心化，但无疑反复验证只会提高验证时间（Performance 降低）。根据 Taiko 探索的各种 ZKP 经济模型，他们总结了下图。笔者在此不进行过多着墨。

Verification Layer

首先要厘清 Aggregation 和 Verification Layer 的区别：前者只是将 ZKP 进行某种方式压缩，比如 Recursion、Folding；后者在此基础上添加了初步验证（Soft Finality）的过程。而 Soft Finality 的过程可能是要依赖外部合约/网络，需要一定程度的信任假设。

在实际 Aggregation 过程中，不同项目采取的架构略有不同，但大体有以下四个环节（以 Polymer 采用的 ZKTree 为例）：

• ZKP Composition : 将任意电路组合进一个新的 ZKP，可能借助 Recursion、Folding。
• ZKP Uniformation : 将上述过程新的 ZKP 统一化处理。
• ZKP Recursion : 将刚生成的一批子节点（统一化的 ZKP）再次进行递归，并用这批次 ZKP 作为 Proof of Verification 达成 Soft Validity/Finality。
• ZKP Transformation : 如果需要服务于某一特定 VM ，他们可能对不同的 ZKP 系统有着自身的适配程度，因应情况而去进一步映射成不同系统的 ZKP 以减少验证成本。

Verification Layer 可以通过 Soft Finality 提供即时的验证，并与各种系统集成（不局限在以太坊），对于安全性追求相对不高的需求时，可以通过 Soft Finality 以追求更高的效率。而且通过 Verification Layer 也可以让并行计算成为一种可能，进一步摆脱以太坊的技术债务。更重要的是他能够让验证成本降低。根据 Nebra 实际测试，在以太坊链上提交的每份证明可节省多达 184k gas（约 75%），在链下提交的每份证明可节省多达 207k gas（约 85%）。另外 Aligned Layer 也预估在 Groth16 和 STARKs 验证成本要比原本在以太坊验证节省 29 倍和 80 倍，且使用的是家用级别的硬件。

Cloaking Layer 如何实现 Verification Layer

简介

Cloaking Layer 是 zCloak Network 的一款新产品，专注于为 ZKP 提供验证层服务。其核心思想是利用 Internet Computer（ICP）的超高效率和超低成本，使用基于 WebAssembly（WASM）的 Canister 合约，对每个 ZKP 进行直接验证。然后再基于同样的信任假设，使用阈值签名技术将验证结果发送到任意目标公链上，实现覆盖全链的 ZKP 验证服务。（扩展阅读：）

主要架构

首先，Cloaking Layer 的核心是 ICP Canister，可以直接以 WASM 形式运行 ZKP 的验证器（Verifier），对 "SNARK" 和 "STARK" 证明进行直接验证。ICP Canister 可以理解为 EVM 链上的智能合约，具有部署后不可篡改，运行结果需要全网共识等特点。与 EVM 合约需要用 Solidity 语言进行编写不同，Canister 合约可以很好地支持 WASM 编译对象。由于目前绝大多数 ZKVM 系统如 Polygon Miden、RISC0、SP1、Jolt 等都是用 Rust 编程语言编写的，很容易就可以编译为 WASM，所以 Canister 很适合担任 ZKP 的验证器的角色。

ICP 公链由多个子网（Subnet）组成，每个子网包含数量众多的节点（Replica）。一个 Canister 合约部署之后，会在每个子网节点内保存一份，运行时也会在每个节点中独立运行，然后子网对所有节点的运行结果进行比较并取得共识，从而保证 Canister 的运行结果正确无误。当 Cloaking Layer 收到 ZKP 后，每个节点内部署的验证器 Canister 都会对该 ZKP 进行独立计算和验证。一旦证明结果在子网内取得共识，子网就会使用阈值 ECDSA 签名技术对验证结果进行数字签名。经过签名的验证结果可以被发送到任意支持 ECDSA 签名验证的公链，如比特币、以太坊和 Solana 进行使用。

竞争分析

重点：

• 目前市场的方案估值都差距比较大
• 目前大部分方案已经在 Testnet
• 预估平均降低验证成本 10 倍+，其中 Cloaking Layer 的效能最高
• 大部分信任假设是基于 Layer1
• 大部分项目仅针对以太坊进行“验证扩容”

评价

Cloaking Layer 与目前其他 Verification Layer 方案最大的不同在于其信任假设的部分。目前申请成为replica（ICP 的节点）要求极高，既需要 ICP 基金会的审批，也需要承担更高的节点的硬件配置需求（比 Solana、Sui 等节点配置较重的 Layer1 要更高），因此在门限 ECDSA 签名的效率中仍保持着一定的信任限制，本质上还是要依赖于网络有 2/3 的诚实节点。另外，由于 ICP 节点性能优势，Cloaking Layer 无需借助繁杂的ZKP recursion scheme以实现 ZKP 压缩，这种方式也最直接、方便。

延展讨论

如何才能在 Verification Layer 中建立抗审查机制？

最简单有效的做法就是用 Layer1 的抗审查机制，只要 Verification Layer 中的 Verifier/Unified Prover 无法拦截递交交易，那就可以继承 Layer1 的抗审查能力。实际理解就是用户/协议可以直接递交 ZKP 到 Verification Layer 在 Layer1 的智能合约（ICP 上是 Canister ），并存进一个等候队列中等待被Verifier/Unified Prover 打包。按照 Arbitrum 的方式来看，任何人都可以在 Sequencer 没有相应的一段时间后将交易纳入 Layer2 的交易历史中。

什么是 ZKP-EV 市场？

通过以上思考，我们可以通过提供额外的手续费以优先打包，如果规模比较大，也可能发展出类 MEV 市场的 ZKP-EV （Extractable Value) 市场。

Soft Finality 和 Hard Finality 如何权衡？

所有 Verification Layer 都会提供 Soft Finality，并且由于这些 Verification Layer 的性能都要比以太坊高，所以在验证速度上来看也是优于以太坊。但如果需要经过 Layer1 的 Hard Finality 那么这个时间就要比没运用 Verification Layer 的时间要长，这个也是保有 Hard Finality + Aggregated ZKP 的一个弊端。因此对于 Hard Finality 要求比较谨慎的协议来说，现阶段的 Verification Layer 不一定是足够好的解决方案，应当引入 Slashing 模块、声誉系统、保险机制以在效率和安全性中取得平衡。可参考我们过往的文章（扩展阅读：）。

ZK-As-A-Service 的收益来源是什么？

当前所有的 ZaaS 的商业模式仍比较模糊，除了能够在 ZKP 过程中抽取部分的佣金，就是发币。但是业务的现金流本质上是与代币价值脱钩的，除非通过强硬的buyback 承诺绑定（比如 MakerDAO的 MKR）。所以虽然当前的市场规模预期很大，但实际收益表现还有待市场验证。

Reference