我们为什么需要模块化ZK服务Modular ZK As A Service（MZaaS）？
2024-06-13 • By okx交易所
前言至今为止，我们在Web3体验到的绝大部分协议都是具备一定程度的信任假设，当我们希望进一步追求“去中心化”时，我们不可避免地要牺牲一部分的隐私性。比如当协议提供MEV-Protection的时候，大概率使用的是PrivateMempool，用户需要假定这部分的节点提供方将诚实地工作，即存在第三方的信任假设，而事实上这对于所有的协议皆如此——存在一定程度的信任假设。根据我们先前一份研报观察，对于机构、大户而言，隐私保护是他们考虑是否将资产迁移链上的重要因素之一。这也意味着，一些第三方链上数据平台可能会加剧MEV-Searcher、黑客对大户、机构的针对性攻击，因此引入链上隐私保护无疑天然适配他们的需求。
在此之前，我们也写过隐私赛道上针对暗池交易的项目Singularity的研报（扩展阅读：详解Singularity：透明区块链上的隐私交易）。
那么问题来了：对于隐私保护，我们可以做什么？
常规听到的四大隐私计算方案有：全同态加密（FHE，FullyHomomorphicEncryption）、多方安全计算（MPC，Muti-PartyComputation),可信执行环境（TEE，TrustedExecutionEnvironment）和零知识证明（ZKP，ZeroKnowledgeProof）。他们其实在解决的是不同情况下的场景需求。
首先，对于加密数据而言，这串数据的所有权决定于谁拥有了解密/加密密钥。通常来看，隐私数据可分为个人可见、团体可见。
个人可见数据（PersonalPrivateState）：数据仅能被一个主体看见并改变，比如个人余额。团体可见数据（SharedPrivateState）：数据在保证隐私性的同时可被多个主体用于计算，比如流动性池里的余额。对于FHE，MPC，TEE来说，他们都可以解决团体可见数据的难题。但是，FHE要求高昂的计算资源，MPC要求所有验证者在线，TEE要信任服务提供商。当前行业对这几者的探索仅适配少数场景，比如暗池交易、私钥管理等。而虽然ZKP输出的结果信息有限（即“是非”题），并大多仅适用于个人可见数据，但其应用场景被现在的用户充分探索，比如跨链桥、Layer2、KYC等。即便在未来，如果FHE和MPC，乃至其他隐私计算方案的盛起，也不会因为蚕食效应/市场竞争而舍弃ZKP，因为：
ZKP+FHE：比如采用了UTXO模型的ZKVM链，如果要验证每笔交易，验证者要下载整个MerkleTree并且一个个地去解码才可以进行验证，所以引入了FHE可以在无需解码的过程下计算出同样的结果。ZKP+MPC：比如采用了MPC+ZKP的暗池，用户可以在保证自身隐私的情况下进一步保证交易的原子性。ZKP+TEE：比如对于ZK-SNARK，生成CommonReferenceString（公共参考字符串）可以由运行TEE的节点进行，以确保中间的信息不会泄漏。我们可预见ZKP的广泛应用场景将井喷式出现，但是这种需求以当前主流的Layer1来看，还难以承担，不仅要面临高昂的GasFee还需要等候网络进行验证。而ModularZKAsAService（MZaaS）作为一个ZKP服务商的设计框架很好地解决了上述问题。MZaaS提供一系列ZKP相关服务以减低ZKP生成复杂度以提高效率。而这些服务可以进一步拆分成以下子类别：
ProofMarketplace：主要以Requester-ProverSeparation概念出发，通过拆分不同场景下的Prover以利用闲置Prover资源以提供公开Proof市场。可参考的项目有Mina、=nil;、ZKPool。VerificationLayer：主要以Aggregation概念出发，证明者收集多个证明并生成一个新的证明，以证明初始证明的有效性，并通过提供验证层以降低验证过程的成本。可参考的项目有AlignedLayer、Horizen、CloakingLayer(zCloakNetwork)、Nebra。ZKP该如何理解？在了解ZKP市场之前，想让我们对ZKP生命周期有一个整体的概念。基本上ZKPProvingSystem都遵循下述的流程：
Prover（证明者）声明他知道某一信息，基于此问题以约束系统进行表达。根据制定的约束系统生成电路Prover输入符合该电路的解决答案（Witness）以计算出ZKProofValidator（验证者）可对ZKP进行验证以辨认Prover是否真知道该信息假设现在我们有一个用于记录用户账户余额的MerkleTree，正常情况要更新账户余额，我们需要按照下述流程进行：
验证发送方和接收方在叶节点记录验证发送方的签名更新发送方和接收方的余额更新MerkleTree的MerkleRoot但在ZKP加持下，这个流程按照如下进行：
将验证MerkleTree的过程完整地构建成电路将更新前后的MerkleTree和该交易记录（某人给A发了$10）当作输入，计算出ZKP验证者对ZKP进行验证（以ZKP、验证密钥和公开输入当作输入），如果输出结果为正确，那么该交易视作为可信。在这个过程中，验证者本身无需对MerkleTree进行反复验证，只需相信验证结果即可（前提是电路构建无误）。
如果从高纬度进一步将ZKP拆解，那么从定义问题到构建电路的过程都是前端进行（以高级语言编译），而后端（以低级语言编译）负责将这个电路嵌入/结合某一证明系统以生成ZKP，具体来看是先将电路结合Information-TheoreticProtocol，后以CryptographicCompiler进行编译成一个适用的ZKPSystem，比如Groth16。
性和完整性的能力。健全性是说，如果一个声明在证明系统中得到证明，那么它就是真的。完备性则保证，如果一个声明为真，那么它在系统中是可证明的。
InteractiveProof(IP)：验证者向证明者提出一系列"随机"问题。证明者做出回应。这种情况会持续很多轮，直到验证者确信证明者的陈述是正确的。ProbabilisticCheckableProofs(PCP)：Proof被转换成一种固定大小的格式，称为"证明副本"。验证者可以随机查询副本中的少量数据进行验证证明。为了让证明者就无法提前预测查询值并准备伪造的证明，可以引入预言机（Oracle）生成随机值以让验证人用于随机查询。理论来看，这个方式比较有效，但是从验证者流程来看，相对效率较低。InteractiveOracleProof(IOP)：证明者和验证者相互交互，并可访问随机示例。IOP通过使用部分数据副本来降低通信和查询的复杂性，从而提高了交互式证明的效率。这也是目前ZKPSystem常用的证明系统。前面提到的Information-TheoreticProofSystem都做出了在现实生活中难以实施的理想假设。例如，它可能假定验证者是可信的，对证明的访问受到限制。但Cryptograph的特性使得这些假设在特定环境下可以实现，例如常见的数学难题：
TheIntegerFactorizationProblem：比如RSA的安全性依赖于大数的因子分解。TheDiscreteLogarithmProblem：Diffie-HellmanKeyExchange依赖于大数的离散对数计算。TheEllipticCurveDiscreteLogarithmProblem：EllipticCurveCryptography(ECC)依赖于有限域的椭圆曲线和复杂的椭圆曲线离散对数。Information-TheoreticProofSystem和CryptographicCompiler结合后，便可以得到ZKPSystem，因此ZKP的各项特征都会随着组合不同而出现改变：
计算方式：一般计算有两种主要模式：电路和图灵机。虽然大多数主流编程语言都试图描述图灵机的计算路径，但对于加密计算来说，图灵机并不是最高效的编程模型，所有更高效的编程模型通常都会大大增加复杂性，从而使加密协议复杂化。因此，人们使用电路来代替图灵机，因为电路可以非常容易地表达许多直接语句，但其取舍是用户需要对处理的计算进行预处理。计算成本：对于不同结合的情况下，验证者、证明者、通信的成本会不一样。比如在PCP+Collision-ResistantHashFunction（CRFS）结合的ZKP系统，其计算成本如下：抗量子：一些加密算法可以有效抵御量子计算机的暴力破解，比如ZK-STARK采用的Collision-ResistantHashFunction在当前发展下，量子计算机无法直接破解。但仍会存在被破解的风险，比如有两位山东大学的学者在2009年发布的论文中讲述了如何破解SHA1和MD5。因此我们仍需要有信任假设。可信配置：可信配置通常两大类：UniformReferenceString（URS），URS生成的随机数是公开可见的，意味着这个“随机性”是公允的；StructuredReferenceString（SRS分两种，UniversalSetup和SpecificSetup，前者允许多个主体参与生成随机数，通常会以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则无需这类特性。图源：https://github.com/matter-labs/awesome-zero-knowledge-proofs?ref=blog.pantherprotocol.io图源：https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffaZero-KnowledgeProof市场潜力与规模目前ZKP赛道主要以两大方向发展：隐私、扩容。
扩容方案主要指的是采用了ZKP作为提高可扩展性的解决方案，包括Layer2可用性证明、跨链等。目前常见的方案有Starknet、ZKsync、Polyhedra等。通常可以分为Layer1/Layer2、协议两种构建体系。在Layer1/Layer2构建体系中，Rollup交易和应用程序在ZKEVM上执行，并具备零知识证明特性。一个理想的ZKEVM应该是等效于EVM，意味着可以完全兼容EVM现有的协议、开发体验。根据Vitalik博客中提到，当前的ZKEVM共可分成5个类别：
Type1：完全等同于以太坊，其状态或交易树、哈希代码或其共识中的任何其他逻辑都不会发生变化。Type-1将与所有以太坊本地应用程序完全兼容，但需要更长证明时间，因为没有进行任何预编译来加快证明生成速度。当前可参考的项目有Scroll、Taiko。Type2：外表与以太坊相似，但内部略有改动，比如状态树、区块结构等，以方便开发并加快证明生成。当前可参考的项目有PolygonHermez。Type2.5：通过提高GasFee来限制部分ZK功能以减少潜在的验证时间，本质上治标不治本。Type3：可能会删除一些在ZK-EVM实现中特别难以实现的功能。此外，有时在如何处理合约代码、内存或堆栈方面也会有细微差别，因此对以太坊兼容性会更弱。这个类别更像是产品发展过渡期，而不是一个产品定位。Type4:用高级语言（如Solidity）编写的智能合约源代码编译成某种明确设计为ZKP系统友好的语言，如Cairo。虽然证明时间可以加速。但是其兼容性最差，比如某些使用了以太坊字节码开发的DApp可能无法进行迁移。当前可参考的项目有ZKsync和Starknet。图源：https://vitalik.eth.limo/general/2022/08/04/zkevm.html以太坊设计之初也没有设想未来会以ZKEVM的的方式进行扩容，因此开发难度无疑是很高的，因此ZKsync、Starknet的选择也是为了尽早推出市场一个泛用型的ZKEVM，而事实上他们应当被称之为ZKVM，因为他们对以太坊的兼容性（面向开发者）比较低，但换来的则是更高的架构灵活性、更低的ZKP生成成本。
这类型的ZKVM可以脱离EVM体系的限制成为一条Layer1，开发人员用高级语言编写针对特定虚拟机架构的代码，然后编译成ZK电路，或者使用特定领域语言（DSL）（如Circom）编写代码，直接生成ZK电路。
图源：https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d如果单独考虑ZKLayer2市场规模，根据L2Beat数据来看，目前ZKLayer2（包括ZKRollup、Validium）的TVL大概有$5.015B，占总Layer2中Layer2TVL和以太坊TVL分别是10%和7%。如果将OPRollup市占率作为Benchmark，ZKRollup目前还有大概10倍TVL的增长空间，预计推出额外10-12条新的ZKLayer2。
当中Linea、Starknet和ZKsync为前三，分别占有$1.22B，$1.06B,$855M，Three-FirmConcentrationRate为62%，意味着当前Layer2竞争被少数项目垄断。进一步观察Layer2TVL增长情况，TVL增速主要出现在2024年2月20日，其原因是Starknet原生代币的流入&增值，目前链上仍保留着75%的Starknet原生代币。
当中Linea属于Type2ZKEVM，Starknet和ZKsync为Type4ZKEVM。且前三名都为ZKRollup而非Validium，前者以以太坊作为DA，后者DA将放在链下由DAC管理。在Validium中，ImmutableX的TVL达到近$200M，位列第一。另外值得注意的是，OPRollup中，TVL最高的前10个Layer2大多都是采用了OPstack，意味着某一Stack的市场占有率很高。但在ZKRollup中，TVL最高的前10个Layer2基本选择开发自己的ZKStack。
图源：https://l2beat.com/scaling/summary图源：https://l2beat.com/scaling/summary除了上述Layer1/Layer2，ZKP在扩容的主要场景还有协议层，比如跨链。跨链中引入ZKP主要服务于轻节点验证、Maker&Sender的跨链基建，比如Polyhedra、OrbiterFinance等。在轻节点原本验证过程中，目标链部署的合约需要持续地获取源链的区块头以做后续的跨链信息校验，将不可避免地消耗Gas，但如果将校验过程放在链下，链上只储存一个Commitment，那么这个存储成本将会大幅减少，且不会因为源链的更新频率越高，而Gas成本越高。而Commitment的构建方式可以用ZKP进行，可以有效地压缩一笔或多笔交易。在Maker&Sender模式，ZKP结合了欺诈证明，进一步减少了ZKP生成。在市场规模方面，以OrbiterFinance为例，虽然目前每个月大概有$628M交易量和$1.48M的TVL，但是在高周转的情况下，ZKP的需求也会提高。
隐私方案主要指的是以ZKP作为其隐私安全保障方案的协议/网络，包括Zcash、Aztec、TornadoCash。
与注重扩容的发展方向相比，注重隐私的解决方案的开发工作较少。现有的隐私应用主要集中在支付隐私方面，可编程性不高。将隐私和可编程性结合起来是一项具有挑战性的任务。注重隐私的解决方案有两种构建方式:
协议：这些协议主要使用ZKP创建私人资金池。用户通过这些私人资金池作为隐私保护方案，比如TornadoCash。对于这些应用，证明由用户执行，验证在链上进行。由于Layer1没有对加密计算进行设计，因此对于主流用户来说，验证成本往往很高，从而限制了这些应用的采用。直观的解决方案是将私人交易应用转移到Rollup中，以降低GasFee。在这种情况下，私人交易证明需要包含在Rollup证明中，即递归证明，而目前以太坊上的常规ZKRollup还无法做到这一点。Layer1/Layer2：这些Layer1/Layer2主要通过ZKP实现的隐私保护，比如MantaNetwork和Aztec。大多数以隐私为重点的链还不能支持通用计算，只能专注于特定场景用例。例如，Penumbra和Renegade专注于私人交易。这些Layer1/Layer2采用的账户模型可以分为：Account-Based和UTXO-Based。两者各有缺陷：前者可能会因为交易路线泄漏部分隐私并且需要串行处理，而后者在验证、更新交易余额的时候都需要对每个子节点进行解密才可以正确查询。根据Defillama显示，当前隐私赛道TVL大概为$709M，Three-FirmConcentrationRate占据接近99%，分别是TornadoCash（$595M）、Railgun（$96.97M）、Aztec（$9.45M）。其中TornadoCash和Railgun为协议，Aztec属于Layer2。
图源：https://defillama.com/protocols/Privacy其中TornadoCash面临着合规性的打压，也意味着很多“合规隐私“需求将逐步迁移到其他协议、网络，ConcentrationRate只会逐渐下降。另外，市场目前很多的第三方数据平台、中心化节点提供商都有损抗审查性，部分大户、机构希望通过更安全、隐秘的方式进行大额资金转移。截止6月3号，受OFAC审查的区块大概有37%，这些是公开Mempool所无法避免的。
图源：https://www.mevwatch.info这也进一步延伸了合规性的要求，因此KYC等服务商也十分重要。但往往用户还是希望最大程度保有个人隐私，ZKP+KYC的潜在场景会随着隐私交易的提高而提高，目前市场的主要服务商是zCloak，zkMe等。在传统KYC过程中，当我们需要委托多个KYC服务商时，我们需要进行反复的验证，但在ZKP+KYC的情况下，其他服务商可以尝试验证该ZKP以保证身份有效性。而且KYC过程中，服务商需要记录一些必要信息，比如身份证等敏感信息，如果在多个服务商进行，那么信息泄露风险也会线性激增。
ZKP现在面临什么问题？正如我们之前提到的，ZKP生成需要大量计算资源。以常见的ZK-Rollup为例，ZKsync的ZKP生成时间大概是1个小时。进一步拆解的话ZK-SNAKS的ZKP生成过程主要涉及多标量乘法（Multi-ScalarMultiplication，MSM）和数论变换（NumberTheoreticTransform，NTT）。这两项过程就能占到证明生成时间的80%到95%。而ZK-STARKs虽然用了不同的算法，但也同样面临低效率的问题。
另外近年来，ZKP系统提供了一系列不同权衡的选择，种类繁多且不断地扩展。例如，更快的证明速度的取舍是更大的证明大小或内存使用量。具有各种定制功能的证明系统种类繁多，并在不断扩展。但以太坊并不能够支持不断发展的证明系。例如，只有BN-254椭圆曲线能够在低成本基础下支持。但如果迁移到更安全的曲线（如BLS12-381），是很复杂的任务，更别说要去兼容新的ZKP系统。
再者，在Layer1验证ZKP方面，验证STARK的成本约为5,000,000Gas，而基于Plonk的证明则低于290,000Gasfee。如果直接在以太坊中验证的证明系统，目前有几个局限性，例如，基于内积论证的证明系统，如Mina的Kimchi（通过Pickles实现高效递归）或基于Brakedown的Binius（具有平方根大小的证明），他们所涉及的运算量或证明大小比较大，因此验证成本也会十分昂贵。为此我们可能需要转制成Ethereum-Friendly的ZKP。
模块化ZK服务如何加速ZKP过程因此如何提高效率成为了下一个ZKP发展要探讨的方向，除了在算法/电路上进行改变，当前主要的解决方案可以分为两大类：
HardwareAcceleration：通过改善硬件以提高ZKP生成过程。GPU通常对ZKP验证时间的改善有限，另一种选择是使用专用硬件，如FPGA或ASIC，进而延伸出HardwareAbstractionLayer，可参考AI云服务。由于本文重点不是讨论硬件加速，便不进行细致探讨。ModularZK-As-A-Service（MZaaS):通过提供一系列ZKP相关服务以减低ZKP生成复杂度以提高效率。而这些服务可以进一步拆分成以下子类别：ProofMarketplace：主要以Requester-ProverSeparation概念出发，通过拆分不同场景下的Prover以利用闲置Prover资源以提供公开Proof市场。可参考的项目有Mina、=nil、ZKPool。VerificationLayer：主要以Aggregation概念出发，证明者收集多个证明并生成一个新的证明，以证明初始证明的有效性，并通过提供验证层以降低验证过程的成本。可参考的项目有AlignedLayer、Horizen、CloakingLayer(zCloakNetwork)、Nebra。ProofMarketplace首先，我们从上文应用场景中能够发现，ZKP的应用场景中并不是所有交易都会进行生成，所以我们可以归类为两种生成方式(以跨链为例）：
全ZK(FullZK)：每一笔交易都会生成ZKP。比如ZKBridge的每一笔交易，Maker都会生成ZKP用于验证。半ZK(HalfZK)：只有满足特定条件下才会生成ZKP。比如OrbiterFinance当出现错误、不可信的交易信息的时候才需要生成ZKP。所以在HalfZK场景下，不是所有的Prover都充分利用。当我们将Prover的角色拆分成Requester和Prover，并且创建出Prover共享平台/Marketplace，就能够提高Prover的利用率，并在FullZK的场景中潜在减少ZKP生成的所需的时间。但问题来了，如何选定Prover？
如何选出Prover的具体设计其实可以分多个维度思考：Performance、Cost、Decentralization。本质上跟共识机制的不可能三角相似，比如选择了多节点验证以确保去中心化，但无疑反复验证只会提高验证时间（Performance降低）。根据Taiko探索的各种ZKP经济模型，他们总结了下图。笔者在此不进行过多着墨。
图源：https://www.theblockbeats.info/news/45260VerificationLayer首先要厘清Aggregation和VerificationLayer的区别：前者只是将ZKP进行某种方式压缩，比如Recursion、Folding；后者在此基础上添加了初步验证（SoftFinality）的过程。而SoftFinality的过程可能是要依赖外部合约/网络，需要一定程度的信任假设。
在实际Aggregation过程中，不同项目采取的架构略有不同，但大体有以下四个环节（以Polymer采用的ZKTree为例）：
ZKPComposition:将任意电路组合进一个新的ZKP，可能借助Recursion、Folding。ZKPUniformation:将上述过程新的ZKP统一化处理。ZKPRecursion:将刚生成的一批子节点（统一化的ZKP）再次进行递归，并用这批次ZKP作为ProofofVerification达成SoftValidity/Finality。ZKPTransformation:如果需要服务于某一特定VM，他们可能对不同的ZKP系统有着自身的适配程度，因应情况而去进一步映射成不同系统的ZKP以减少验证成本。VerificationLayer可以通过SoftFinality提供即时的验证，并与各种系统集成（不局限在以太坊），对于安全性追求相对不高的需求时，可以通过SoftFinality以追求更高的效率。而且通过VerificationLayer也可以让并行计算成为一种可能，进一步摆脱以太坊的技术债务。更重要的是他能够让验证成本降低。根据Nebra实际测试，在以太坊链上提交的每份证明可节省多达184kgas（约75%），在链下提交的每份证明可节省多达207kgas（约85%）。另外AlignedLayer也预估在Groth16和STARKs验证成本要比原本在以太坊验证节省29倍和80倍，且使用的是家用级别的硬件。
CloakingLayer如何实现VerificationLayer简介CloakingLayer是zCloakNetwork的一款新产品，专注于为ZKP提供验证层服务。其核心思想是利用InternetComputer（ICP）的超高效率和超低成本，使用基于WebAssembly（WASM）的Canister合约，对每个ZKP进行直接验证。然后再基于同样的信任假设，使用阈值签名技术将验证结果发送到任意目标公链上，实现覆盖全链的ZKP验证服务。（扩展阅读：CloakingLayer—aZKVerificationInfraforAllChains）
主要架构图源：https://zcloaknetwork.medium.com/cloaking-layer-a-zk-verification-infra-for-all-chains-1162d3fcc37b首先，CloakingLayer的核心是ICPCanister，可以直接以WASM形式运行ZKP的验证器（Verifier），对"SNARK"和"STARK"证明进行直接验证。ICPCanister可以理解为EVM链上的智能合约，具有部署后不可篡改，运行结果需要全网共识等特点。与EVM合约需要用Solidity语言进行编写不同，Canister合约可以很好地支持WASM编译对象。由于目前绝大多数ZKVM系统如PolygonMiden、RISC0、SP1、Jolt等都是用Rust编程语言编写的，很容易就可以编译为WASM，所以Canister很适合担任ZKP的验证器的角色。
ICP公链由多个子网（Subnet）组成，每个子网包含数量众多的节点（Replica）。一个Canister合约部署之后，会在每个子网节点内保存一份，运行时也会在每个节点中独立运行，然后子网对所有节点的运行结果进行比较并取得共识，从而保证Canister的运行结果正确无误。当CloakingLayer收到ZKP后，每个节点内部署的验证器Canister都会对该ZKP进行独立计算和验证。一旦证明结果在子网内取得共识，子网就会使用阈值ECDSA签名技术对验证结果进行数字签名。经过签名的验证结果可以被发送到任意支持ECDSA签名验证的公链，如比特币、以太坊和Solana进行使用。
竞争分析重点：
目前市场的方案估值都差距比较大目前大部分方案已经在Testnet预估平均降低验证成本10倍+，其中CloakingLayer的效能最高大部分信任假设是基于Layer1大部分项目仅针对以太坊进行“验证扩容”评价CloakingLayer与目前其他VerificationLayer方案最大的不同在于其信任假设的部分。目前申请成为replica（ICP的节点）要求极高，既需要ICP基金会的审批，也需要承担更高的节点的硬件配置需求（比Solana、Sui等节点配置较重的Layer1要更高），因此在门限ECDSA签名的效率中仍保持着一定的信任限制，本质上还是要依赖于网络有2/3的诚实节点。另外，由于ICP节点性能优势，CloakingLayer无需借助繁杂的ZKPrecursionscheme以实现ZKP压缩，这种方式也最直接、方便。
延展讨论如何才能在VerificationLayer中建立抗审查机制？
最简单有效的做法就是用Layer1的抗审查机制，只要VerificationLayer中的Verifier/UnifiedProver无法拦截递交交易，那就可以继承Layer1的抗审查能力。实际理解就是用户/协议可以直接递交ZKP到VerificationLayer在Layer1的智能合约（ICP上是Canister），并存进一个等候队列中等待被Verifier/UnifiedProver打包。按照Arbitrum的方式来看，任何人都可以在Sequencer没有相应的一段时间后将交易纳入Layer2的交易历史中。
什么是ZKP-EV市场？
通过以上思考，我们可以通过提供额外的手续费以优先打包，如果规模比较大，也可能发展出类MEV市场的ZKP-EV（ExtractableValue)市场。
SoftFinality和HardFinality如何权衡？
所有VerificationLayer都会提供SoftFinality，并且由于这些VerificationLayer的性能都要比以太坊高，所以在验证速度上来看也是优于以太坊。但如果需要经过Layer1的HardFinality那么这个时间就要比没运用VerificationLayer的时间要长，这个也是保有HardFinality+AggregatedZKP的一个弊端。因此对于HardFinality要求比较谨慎的协议来说，现阶段的VerificationLayer不一定是足够好的解决方案，应当引入Slashing模块、声誉系统、保险机制以在效率和安全性中取得平衡。可参考我们过往的文章（扩展阅读：TeleportDAO：数据验证安全与效率之弈，轻节点设计最新实践）。
ZK-As-A-Service的收益来源是什么？
当前所有的ZaaS的商业模式仍比较模糊，除了能够在ZKP过程中抽取部分的佣金，就是发币。但是业务的现金流本质上是与代币价值脱钩的，除非通过强硬的buyback承诺绑定（比如MakerDAO的MKR）。所以虽然当前的市场规模预期很大，但实际收益表现还有待市场验证。
Referencehttps://medium.com/casperblockchain/verified-merkle-tree-updates-without-zk-90d8f5100ccd
https://www.zkcamp.xyz/blog/information-theory
https://x.com/iam_preethi/status/1656411033366396929https://crypto.stackexchange.com/questions/92018/which-is-the-relation-between-zero-knowledge-proofs-of-knowledge-and-circuitshttps://web.archive.org/web/20090521024709/http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa
https://www.paradigm.xyz/2022/04/zk-hardware
https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4?ref=blog.pantherprotocol.io
https://x.com/jaosef/status/1730313497513476326
https://l2beat.com/scaling/summary
https://defillama.com/protocols/Privacy
https://docs.zksync.io/zk-stack/concepts/finality.html#finality-on-zksync-era
https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
https://dune.com/nebra/zkp-verify-spending
https://medium.com/@eternal1997L/icp没落的原因-特立独行的技术与冷清单薄的生态-51dd7a9362fb
