本文介绍了一种智能合约的设计模式——事实注册合约(Fact Registry Contract),该模式通过独立的合约来验证和记录声名的有效性。文章详细讨论了何时使用注册合约及其优缺点,特别是在高验证成本和利用简洁证明系统实现规模经济时的优势。作者强调了批量验证的方法如何降低气体成本,从而为不同合约提供经济规模效益。
这是我们在 ethresearch 发布内容的稍作修改版本
在野外的压缩 | 摄影者 Niklas Hamann 在 Unsplash
在这篇文章中,我们介绍了一种智能合约的 设计模式,我们称之为 事实登记合约 模式,或简单称为 登记合约。该模式提供了一种将声明的验证与依赖其有效性的应用程序分开的方式。
其思路是编写一个单独的合约,其唯一目的是验证和记录满足该声明的元素。一个声明由一个谓词 P(x, witness) 定义,它接收一个元素 x 和一些辅助信息 witness,并返回 True 或 False。如果已知某个 witness,使得 P 返回 True,我们将 x 称为 事实。
一些声明的示例包括:
验证上述声明可能是某些应用程序合约的一部分。处理这样的谓词的常见方法是在应用程序合约内部编写一个函数,并在交易的 calldata 中传递证人。
然而,在某些情况下,写一个专门的 登记合约 会是更好的选择。登记合约是一个维护一组先前见证事实的合约(存储在以太坊上),并且有两个方法:add() 和 isValid()。add(fact, witness) 方法在声明成立的前提下将事实添加到集合中。isValid(fact) 方法如果事实在集合中则简单返回 True。
在许多情况下,事实的大小(不包括证人)大于 32 字节。在这种情况下,最好维护先前见证事实的 hashes 集合,而不是事实本身。
请注意,如果 isValid(fact) 返回 True,这意味着不仅存在满足谓词的证人,而且这样的证人之前已呈现给合约。因此,isValid() 方法充当了一种 知识证明。
图1:数据流,分为不同阶段。在阶段(1)中,事实和相应的证人被传递到登记合约中,该合约验证有效性并将事实添加到集合中。在阶段(2)中,当应用程序合约被调用时,它调用登记合约以检查事实的有效性。
使用登记合约相比于在应用程序合约中使用函数的单一解决方案引入了几个额外开销:
当验证声明的总成本(计算和 calldata)较低时,使用登记合约可能会在Gas费用上增加不容忽视的开销,这时单一解决方案更优。
然而,当验证的成本较高时,这些开销变得微不足道,使用所提议的设计模式有许多优势:
让我们进一步阐述最后这一好处,我们认为其潜力巨大。
在上述示例中,验证事实的Gas成本是可加的,因为验证多个事实所需的Gas成本(大约)等于单独验证事实所需的成本之和。然而,有些技术可以减少验证(或在证明系统的术语中“验证”)一批事实的Gas成本。例如,简洁的知识证明(如 STARKs)允许证明某个计算具有给定的结果,而其成本低于计算大小的线性成本。尤其是,一起证明许多事实的成本低于单独证明每个事实的总成本。
考虑上述提到的 merkleLeaf() 的登记合约。如果我们扩展 add() 方法以获取一批新的事实(即一对 (leaf, root) 的列表),我们可以通过验证一个证明来检查它们的有效性,该证明证明了整个批次,而不是检查每个事实的认证路径。请注意,在这种情况下,认证路径根本未传输。随着添加到一个批次的事实数量增加,每个事实的摊销Gas成本下降(在现代简洁证明系统中,验证一个证明所需的Gas成本,排除处理公共输入所需的小线性成本,随批次大小的增加而(多项式)对数增长)。
简洁证明系统有一个效率阈值:验证一个证明相关的最小计算成本,因此为低于最小大小的批次生成证明在经济上是不合理的。因此,低带宽合约无法使用这种批处理机制,从中受益。登记合约通过允许我们收集来自不同应用程序的事实并将它们放在一个批次中,降低了这个效率阈值。这样,低带宽合约可以通过参与这样的批次受益,节省验证事实所需的Gas,从而实现规模经济。
Lior Goldberg & Michael Riabzev
StarkWare
- 原文链接: medium.com/starkware/the...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!