事实注册合约

  • starkware
  • 发布于 2019-07-05 14:51
  • 阅读 209

本文介绍了一种智能合约的设计模式——事实注册合约(Fact Registry Contract),该模式通过独立的合约来验证和记录声名的有效性。文章详细讨论了何时使用注册合约及其优缺点,特别是在高验证成本和利用简洁证明系统实现规模经济时的优势。作者强调了批量验证的方法如何降低气体成本,从而为不同合约提供经济规模效益。

证明、去中心化应用程序和规模经济

这是我们在 ethresearch 发布内容的稍作修改版本

在野外的压缩 | 摄影者 Niklas HamannUnsplash

介绍

在这篇文章中,我们介绍了一种智能合约的 设计模式,我们称之为 事实登记合约 模式,或简单称为 登记合约。该模式提供了一种将声明的验证与依赖其有效性的应用程序分开的方式。

其思路是编写一个单独的合约,其唯一目的是验证和记录满足该声明的元素。一个声明由一个谓词 P(x, witness) 定义,它接收一个元素 x 和一些辅助信息 witness,并返回 TrueFalse。如果已知某个 witness,使得 P 返回 True,我们将 x 称为 事实

一些声明的示例包括:

  1. isComposite(x, witness) 当且仅当 x 是一个合成数时返回 True。证明者是 x 的一个除数。
  2. merkleLeaf((leaf, root), witness) 当且仅当 leaf 是某个根为 root 的 Merkle 树中的一个叶子时返回 True。证明者是树中的相关认证路径。
  3. _signedText((text, publickey), witness) 当且仅当 text 出现在某个由 _publickey 签名的文档中时返回 True。证明者是包含文本及其签名的文档。

验证上述声明可能是某些应用程序合约的一部分。处理这样的谓词的常见方法是在应用程序合约内部编写一个函数,并在交易的 calldata 中传递证人。

然而,在某些情况下,写一个专门的 登记合约 会是更好的选择。登记合约是一个维护一组先前见证事实的合约(存储在以太坊上),并且有两个方法:add()isValid()add(fact, witness) 方法在声明成立的前提下将事实添加到集合中。isValid(fact) 方法如果事实在集合中则简单返回 True

在许多情况下,事实的大小(不包括证人)大于 32 字节。在这种情况下,最好维护先前见证事实的 hashes 集合,而不是事实本身。

请注意,如果 isValid(fact) 返回 True,这意味着不仅存在满足谓词的证人,而且这样的证人之前已呈现给合约。因此,isValid() 方法充当了一种 知识证明

图1:数据流,分为不同阶段。在阶段(1)中,事实和相应的证人被传递到登记合约中,该合约验证有效性并将事实添加到集合中。在阶段(2)中,当应用程序合约被调用时,它调用登记合约以检查事实的有效性。

何时使用登记合约?

使用登记合约相比于在应用程序合约中使用函数的单一解决方案引入了几个额外开销:

  1. 每个验证过的事实需要一次存储操作,来源于将事实添加到链上集合中。
  2. 多次传输事实:一次是为登记合约,再加上每个使用它的应用程序合约一次。
  3. 查询登记合约的事实有效性时的合约间通信。

当验证声明的总成本(计算和 calldata)较低时,使用登记合约可能会在Gas费用上增加不容忽视的开销,这时单一解决方案更优。

然而,当验证的成本较高时,这些开销变得微不足道,使用所提议的设计模式有许多优势:

  1. 应用程序合约与登记合约之间的清晰分离,包括在不更改另一合约的情况下升级一个合约的能力。
  2. 将Gas成本分割到多个交易中。当你遇到整个操作所需的Gas成本超过区块限制的情况时,这一点非常有用。
  3. 不同方之间分摊Gas成本。这在一个方应为验证声明支付Gas而另一个方应为引用经验证事实的应用程序合约支付时非常有用。
  4. 在同一合约的多次交易中或不同合约中重用事实(即缓存)。
  5. 规模经济:通过使用简洁的证明系统,如 STARK、SNARK 或 BulletProofs,可以使用显著少于逐个验证每个事实所需的Gas量来验证一批事实。因此,依赖于同一声明(甚至不是相同数据!)的不同合约可以从大规模的规模经济中受益。

让我们进一步阐述最后这一好处,我们认为其潜力巨大。

使用简洁的知识证明进行批处理

在上述示例中,验证事实的Gas成本是可加的,因为验证多个事实所需的Gas成本(大约)等于单独验证事实所需的成本之和。然而,有些技术可以减少验证(或在证明系统的术语中“验证”)一批事实的Gas成本。例如,简洁的知识证明(如 STARKs)允许证明某个计算具有给定的结果,而其成本低于计算大小的线性成本。尤其是,一起证明许多事实的成本低于单独证明每个事实的总成本。

考虑上述提到的 merkleLeaf() 的登记合约。如果我们扩展 add() 方法以获取一批新的事实(即一对 (leaf, root) 的列表),我们可以通过验证一个证明来检查它们的有效性,该证明证明了整个批次,而不是检查每个事实的认证路径。请注意,在这种情况下,认证路径根本未传输。随着添加到一个批次的事实数量增加,每个事实的摊销Gas成本下降(在现代简洁证明系统中,验证一个证明所需的Gas成本,排除处理公共输入所需的小线性成本,随批次大小的增加而(多项式)对数增长)。

简洁证明系统有一个效率阈值:验证一个证明相关的最小计算成本,因此为低于最小大小的批次生成证明在经济上是不合理的。因此,低带宽合约无法使用这种批处理机制,从中受益。登记合约通过允许我们收集来自不同应用程序的事实并将它们放在一个批次中,降低了这个效率阈值。这样,低带宽合约可以通过参与这样的批次受益,节省验证事实所需的Gas,从而实现规模经济。

Lior Goldberg & Michael Riabzev

StarkWare

  • 原文链接: medium.com/starkware/the...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
starkware
starkware
江湖只有他的大名,没有他的介绍。