SNARK性能及安全——Verifier篇

1. 引言

前序博客:

  • SNARK性能及安全——Prover篇 中指出SNARK Prover为计算密集型的,Prover的前端开销(将计算转换为电路表示)和后端开销(对电路进行SNARK证明)都要比原始直接计算的计算量大3个数量级或更多,因此为大规模计算生成证明可能是不可行的。SNARK的实用性主要受限于Prover的性能。

不过,SNARK Verifier的验证开销要 远远低于 直接检查和处理数据。不过,SNARK验证成本差异很大。本文分析了这些验证开销,并比较了不同SNARK的安全特性。

本文将特别介绍具有可信后量子安全的使用SNARK方案(PQ-SNARKs),这种方案中,安全性与验证开销之间需进行权衡。当前,在某些情况下,总是倾向于更重视验证开销而不是安全性。

SNARKs为展现其潜力,需保证部署的SNARK系统是安全的,且用户也信任其安全性。在本文最后提出了web3社区可以采取的简单行动,以帮助确保这些属性长期有效。

2. SNARK安全性分析

2.1 SNARK安全性定量分析

如果在计算上无法提供虚假陈述的令人信服的证明,则SNARK是安全的。例如,在L2 rollups的情况下,想要窃取我的资金的攻击者需要证明以下形式的虚假陈述:“我知道一个数字签名交易,将Justin的所有资产转移到我自己的账户。”

SNARK的安全级别是通过为找到虚假陈述的令人信服的证明而必须完成的工作量来衡量的。与数字签名等其他密码原语类似,这一工作量的对数被称为“安全位(bits of security)”。例如,30位安全意味着 2 30 2^{30} 230≈ 需要10亿个“工作步骤(steps of work)”来攻击SNARK。这本质上是真实世界安全性的近似度量,因为one step of work的概念可能会有所不同,并且没有考虑内存需求或并行机会等实际因素。

2.2 SNARK安全性定性分析

bits of security为SNARK安全性的定量分析。
不同的SNARK也会有不同的定性安全属性。

如,某些SNARKs需要可信设置仪式来生成结构化的proving key,而根本不需要可信设置的SNARK是transparent的。

non-transparent SNARK要想安全,其可信设置仪式中需至少有一个参与者是诚实的,即其生成并丢弃了某“trapdoor”。若将其与其它参与者的trapdoor结合,将很容易找到任意虚假陈述的可信SNARK“证明”。可信设置仪式,如:

需由成百上千个的参与者,每人都生成并丢弃其“trapdoor”,以使可信设置的安全假设尽可能温和。

根据抗量子攻击能力也可对SNARK进行分类:

  • 1)依赖discrete logarithm安全假设的SNARKs:如Groth16PlonKMarlinBulletproofsNova等。对于量子计算机来说,可能可高效计算discrete logarithm难题,因此这些SNARKs不是post-quantum安全的(non-PC)。

虽然目前正在紧急努力转向后量子加密方案,但这主要是因为需要在未来几十年内保持加密消息的机密性。今天存储截获消息并等待量子计算机(比如50年后)到达的对手 可 使用计算机解密50年前的消息。SNARK的情况完全不同。今天使用非PQ-SNARK不应损害未来50年区块链的安全性,即使量子计算机届时确实到来。

2.3 SNARK多项式承诺

所有的SNARK都使用多项式承诺方案的密码学原语,多项式承诺方案通常也是性能瓶颈。详细可参看SNARK性能及安全——Prover篇 第5节“SNARK后端的瓶颈是什么?”。
而且,SNARK的transparency和plausible post-quantum安全性都完全由其所选择的多项式承诺方案决定。

现有的多项式承诺方案有:

上面的5种post-quantum secure多项式承诺方案均是基于纠错码,使用的唯一密码学原语为哈希。同时具有如下属性:

  • 验证开销随着bits of security的位数增加而增加。(所谓验证开销,是由 哈希evaluation数量以及field operation数量 来衡量的。)

粗略来说,这些post-quantum多项式承诺方案的单次“迭代”仅可实现小数量的bits of security(如2-4)。因此,需重复该协议多次来“放大”安全等级,而随着每次重复,验证开销也会随之增加。因此,控制PQ-SNARKs的验证开销(对应为区块链应用中的gas开销),协议设计者通常有动力将security level设置为较低值。

除极少数例外情况(见2018年论文 Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains)外,Non-PQ-SNARK(透明和不透明)中不会出现具体安全和验证成本之间的紧张关系。Non-PQ-SNARK使用椭圆曲线群,其中离散对数被认为很难计算,其安全级别由所使用的群确定。椭圆曲线群的合适大小,以及每个群操作的成本,随着所需的安全级别而增长。然而,proof 中群元素的数量与群的选择无关。

而在PQ-SNARKs中,不仅hash evaluation的size会随着所需的安全等级增加而增加,proof中所需的evaluation数以及Verifier计算的 evaluation数也将随着所需安全等级增加而增加。

3. 所部署SNARK的具体验证开销和安全等级

实际项目中,所部署SNARK的具体验证开销和安全等级 差别很大。

3.1 实际所部署SNARK的具体验证开销

根据:

可知,PlonK proof在以太坊上的验证开销低于30万gas。
而StarkWare proof的验证开销约为500万gas。StarkWare proof为transparent和plausibly post-quantum的,而PlonK proof不是。
不过,后续将说明,以太坊上的StarkWare proof的安全等级 要远低于以太坊上的PlonK proof的安全等级。

3.2 实际所部署SNARK的具体安全等级

以太坊中唯一预编译的椭圆曲线为altbn128,因此,所有部署在以太坊的non-PQ SNARK(包括AzteczkSync)都使用该曲线。早期认为altbn128曲线的安全性约为128bit,但随着攻击的改进,如2015年论文Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case 和 2016年论文Challenges with Assessing the Impact of NFS Advances on the Security of Pairing-based Cryptography,现在通常认为altbn128曲线的安全性在100bit到110bit。

当前一些EIP,如:【详细见ConsenSys团队的Prove schemes and curves

也在考虑引入新的安全性接近128bit的不同曲线预编译实现。这些曲线目前已在ZCash, Algorand, Dfinity, Filecoin, Aleo等非以太坊项目中使用。

相反,StarkWare的PQ-SNARKs(其称为SHARP系统,为SHAR的Prover的简称)配置的目标安全性为80bit。这种安全级别在某些关于FRI的统计可靠性的推测下成立(将在本文后面讨论)。在这种情况下,术语“80位安全性”是模糊的,接下来将详细解释。

在本上下文中,“80位安全性”术语是模糊的。粗略来说,其意味着,攻击者可通过evaluating a hash function(如以太坊使用的KECCAK-256哈希函数) 2 80 2^{80} 280 次,可生成a convincing proof of a false statement。更精确的来说,攻击者可执行 2 k 2^k 2k次hash evaluation,生成a convincing proof的概率约为 2 k − 80 2^{k-80} 2k80。如, 2 70 2^{70} 270次hash evaluation,找到a SNARK “proof” of a false statement的概率约为 2 − 10 = 1 / 1024 2^{-10}=1/1024 210=1/1024

而在其它上下文中“80位安全性”术语的概念更弱。如,配置为80位安全性的抗碰撞哈希函数(CRHF) 可生成160位的输出。若该哈希函数设计良好,最快的找到碰撞的流程为Birthday attack——暴力破解找到某碰撞需约 2 160 / 2 = 2 80 2^{160/2}=2^{80} 2160/2=280次hash evaluations。但是,通过 2 k 2^k 2k次hash evaluation,Birthday attack找到碰撞的概率仅为 2 2 k − 160 2^{2k-160} 22k160。如, 2 70 2^{70} 270次hash evaluation,找到某碰撞的概率为 2 − 20 ≈ 1 / 1 , 000 , 000 2^{-20}\approx 1/1,000,000 2201/1,000,000,该概率远低于 配置为80位安全性的攻击者伪造一个PQ-SNARK proof的概率(1/1,000)。

这二者之间的不同之处,将极大的改变攻击的吸引力。假设某攻击者有10万$的预算,可购买 2 70 2^{70} 270次hash evaluations,假设,攻击者若赢了,可获得20亿 的汇报。对配置为 80 位安全性的 P Q − S N A R K 攻击的期望值为 的汇报。对配置为80位安全性的PQ-SNARK攻击的期望值为 的汇报。对配置为80位安全性的PQSNARK攻击的期望值为(1/1,000)*$20亿 ,即为 20 万 ,即为20万 ,即为20,为成本的2倍。而对CRHF赢的概率为 1 / 1 , 000 , 000 1/1,000,000 1/1,000,000,则攻击的期望值仅为200$。

这2个“80位安全性”的概念对对独立攻击的鲁棒性也有显著差异。如,假设有1000个独立方,每个对PQ-SNARK执行 2 70 2^{70} 270次hash evaluation攻击,由于每个赢的概率约为1/1000,即至少有一个大概率将赢。而对于 1 / 1 , 000 , 000 1/1,000,000 1/1,000,000概率来说,该情况则不成立。

设计良好的椭圆曲线群可与CRHF的表现类似 ,具有类似birthday的攻击,如最有名的Pollard’s rho algorithm攻击。这意味着,提供128位安全性的群, 2 k 2^k 2k次群操作,破解discrete logarithm problem的概率仅为 2 2 k − 256 2^{2k-256} 22k256。如, 2 70 2^{70} 270次群操作,破解discrete logarithm难题的概率仅为 2 − 116 2^{-116} 2116(很小)。此外,每个群操作要 慢于 单次CRHF evaluation。

4. 当今的哈希算力?

2020年1月,使用GPU计算 2 64 2^{64} 264次SHA-1 evaluation的成本为45000$,使用GPU计算 2 70 2^{70} 270次仅需要数百万刀(且随着以太坊合并迁移之前的GPU主宰的PoW mining之后,GPU计算的需求降低,成本可能会进一步降低)。

而validity rollups已存储了数亿刀用户资金,找到一个convincing proof of a false statement将获利数亿美金。在攻击性推测下,将PQ-SNARK配置为80位安全性,在盈利攻击和PQ-SNARK的推测安全性之间留下不到10位的摇摆空间。

另一方面,Bitcoin网络的哈希rate当前约为 2 64 2^{64} 264次hash evaluations per second,这意味着,bitcoin miners每18小时可总共执行 2 80 2^{80} 280次SHA-256 evaluations。当然,这个令人瞠目结舌的数字是由于比特币mining ASICs的巨额投资。

假设每小时产6个比特币区块,当前每个区块奖励为6.25 Bitcoin,这 2 80 2^{80} 280次SHA-256 evaluations的成本大概低于 22 , 000 ∗ 18 ∗ 6 ∗ 6.25 ≈ 1.5 亿 22,000*18*6*6.25\approx 1.5亿 22,0001866.251.5亿刀。否则,当前价的bitcoin mining将无利可图。

5. 健康生态倡议

rollup中使用SNARKs的根本目的是,使得用户无需盲目信任rollup service而达到扩容目的。由于rollup service编写智能合约来承担SNARK verifier角色,公众必须可检查该合约并确认其确实是verifying SNARK proofs of the appropriate statements。公众对智能合约的审查也可能是必要的,以确保rollup service无法审查自己的用户。抗审查的推荐方案为:当rollup服务处理用户交易失败时,要求rollup合约支持用户强制提取资金。

鉴于这些协议的复杂性,这种公众审查模式给专家们带来了一些负担,让他们公开和坦率地讨论部署的合同的安全性。

但是对于PQ-SNARKs,确定所部署协议的安全级别,即使对于专家来说也可能是困难的,原因同样在于这类SNARK中security与Verifier性能 之间的紧张关系:

  • 安全等级(和Verifier cost)取决于该SNARK中的内部参数。
    如对于StarkWare的智能合约,这些内部参数为logBlowupFactor、proofOfWorkBits和n_Queries,这些参数并没有直接在智能合约代码中指定,而是以public data的方式传入。

就作者目前所知,从链上信息中识别这些参数的最简单方法是通过四步过程:

  • 1)通过block explorer,如Etherscan,查看合适的智能合约
  • 2)点击某合适的“verify proof”交易
  • 3)将该交易的input data解码
  • 4)figure out how to interpret the decoded input data to learn the key SNARK parameters that together determine the security level。【最后一步需要找到实现该交易的合适的Solidity代码,这本身是一项令人困惑的任务】

2022年夏天,在做:

时,Etherscan可将SHARP verifier交易的以上步骤2)之前的相关input data解码,但这似乎不再有效。

5.1 倡议一:审查

考虑到这一点,对web3社区的第一个建议是,更容易审查部署的post-quantum SNARK的安全级别。这可能需要更好的工具来理解链上数据,并增加项目本身在这些已知参数方面的透明度。

5.2 倡议二:更强的规范

80位安全性太低了,特别是当 2 70 2^{70} 270次hash evaluation就足以形成概率约 1 / 1000 1/1000 1/1000的成功攻击时——考虑到对密码学原语的long history of surprising attacks,实际成果概率可能更高。如,pairing-friendly 椭圆曲线altbn128存在更好的攻击。更著名的例子是SHA-1,其标准安全位80位,但最终仅能达到60位的安全性。将这些历史牢记,PQ-SNARK设计师者在配置安全级别时,应预留多余10位的摇摆空间,特别是当安全分析涉及到有关FRI等相对较新协议的统计安全性的强猜想时。

即使对于PQ-SNARKs,可通过简单的增加verification costs来达成合适的安全级别。如,将SHARP verifier的安全级别由80提升到128位(在FRI的统计安全性假设下),相应的gas开销将增加约2倍,由略多余500万,增加到,捋多余1000万。没有FRI猜想的前提下,gas开销将再增加2倍,将超过2000万。

另一个建议是,web3社区应围绕所部署SNARKs的合适安全级别,开发更强的规范。个人建议不低于100bit,若SNARK的安全性基于的不是标准假设,则应不低于128bit。在ZKProof Community Reference中也做出了类似的建议。

在这里,如果部署的SNARK中的随机预言机是用标准哈希函数(如KECCAK-256)实例化的,将其归类为随机预言机模型中的“标准假设”无条件安全。随机预言机模式是一种理想化设置,旨在捕获精心设计的加密哈希函数的行为。它通常用于分析PQ-SNARK的安全性。

非标准假设的一个例子是关于协议(如FRI)定量可靠性的推测(如下所述),无论是将FRI用于交互设置中还是作为随机预言模型中的非交互协议。

SNARK设计者正在以许多令人兴奋的方式进行创新,其中一些可能会在安全方面有所突破——例如,通过使用SNARK友好的哈希函数,这些哈希函数没有像标准哈希函数那样经过大量的密码分析。并不是在呼吁结束这种努力——远非如此。但是,这些原语应该在安全级别实例化,其安全级别应远远超过已知的、可行的攻击10位。

参考资料

[1] a16z团队2022年8月博客 Measuring SNARK performance: Frontends, backends, and the future
[2] a16z团队2022年9月博客 SNARK security and performance
[3] twitter SNARK security

猜你喜欢

转载自blog.csdn.net/mutourend/article/details/126930430