介绍:VeeDo

  • starkware
  • 发布于 2020-06-25 18:33
  • 阅读 31

VeeDo是基于STARK的可验证延迟函数(VDF)服务,旨在提供信任无偏的随机数生成。文章详细介绍了VeeDo的技术构建块,包括延迟函数和STARK协议,并且阐述了其第一个应用案例,即以太坊链上的随机性信标。内容结构清晰,涵盖技术原理、实现与未来应用展望,显示出其较高的技术深度与创新潜力。

介绍:VeeDo

一个基于 STARK 的 VDF 服务

引言

我们很高兴地宣布,VeeDo——我们基于 STARK 的可验证延迟函数(VDF)服务——现在已在 Mainnet 上线。本文旨在作为 VeeDo 的初步介绍。首先概述 VeeDo 的构建模块。接着,我们描述 VeeDo 的第一个应用,一个随机性信标的 PoC,并将我们的解决方案与现有的随机性解决方案进行比较。最后,我们讨论一些未来的应用和我们对 VeeDo 的商业模型的设想。

VeeDo 的密码学构建模块

可验证延迟函数(VDF)最早在 Boneh 等人 的工作中被提出。如其名所示,VDF 是利用计算提供延迟、时间滞后的函数。

重要的是,任何人减少时间延迟超过一个恒定的、众所周知的因素应当是非常困难和/或昂贵的。

VeeDo 使用的 VDF 是一个函数 f,它具有以下特性:

  1. 计算缓慢
  2. 反转快速(即,计算 f ^(-1) 是快速的)
  3. 可以为 f 的计算完整性提供一个证明 π,以便无需重播缓慢的函数 f 的计算。

为了实现 VDF 的上述特性,VeeDo 将延迟函数 f 与另一种密码学原语,STARK 协议相结合。

延迟函数

延迟函数 f 接受一对输入:一个作为种子的字段元素 s 和一个迭代次数 n。它对该种子运行 n 次迭代的单循环。(迭代次数 n,超过一百万,是一个可以调整的参数,用来实现所需的延迟)。循环的每次迭代也很简单:找到一个大素数 p 模下的低度(立方)多项式的根,在 VeeDo PoC 中,这是一个 126 位的大素数。根查找步骤比评估一个立方多项式的反向过程大约难 42 倍。

STARK 协议

VDF 的可验证属性,即其多对数验证复杂度,是通过 STARK 协议实现的。当 f(s,n) 的计算完成后,三个元素 <s, n, f(s,n)> 被发送到 STARK 证明者。然后证明者证明计算是有效的。s 上的 f 计算和证明生成都是在链外进行的。< s, n, f(s,n)> 以及证明随后被发送到验证者,一个在链上运行的智能合约。高效的 STARK 验证者的运行时间与 n(f 计算的长度)是多对数级别的。

注意,对于小的延迟,通过计算 n 次 f ^(-1) 的简单验证方法可能就足够了。STARK 证明所扮演的角色是当需要较大延迟时,指数 压缩简单验证过程(从 n 到 poly-log(n))。

我们的分析指出 VeeDo 的 VDF 还有另一个重要特性:它是 抗硬件的。在计算 VDF 时,GPU 和 FPGA 在延迟方面相对于标准 64 位 CPU 并没有优势。此外,我们对潜在的定制 ASIC 对此计算的改进上限有详细的了解。对这些方面的详细分析将会包含在我们将要发布的 VeeDo 白皮书中。

首先:随机性

背景

我们打算使用 VeeDo 解决的第一个应用是在以太坊上实现无信任和无偏随机性。目前,以太坊最广泛使用的随机性来源是区块哈希。超过 3500 个智能合约使用它。区块哈希随机性易于使用,易于访问(每个区块都生成),且成本低。这些特性也使得区块哈希随机性容易被操纵,研究人员自然已经对此进行过演示(例如,Bunz 等人)。另外两个随机性来源是 Chainlink 的基于预言机的随机性服务和 Keep Network 的随机信标(基于 BLS 阈值中继)。为了保持无偏,这些解决方案要么需要诚实的多数,要么假设操作员与预言机提供者不串通。因此,它们的信任需要加密经济机制和非平凡的信任假设。

VeeDo:无信任,无偏随机信标

使用 VDF 作为随机信标 最初由 Justin Drake 提出,是 Eth 2.0 中 Beacon Chain 随机性的主要提案。基本思想是使用高熵源作为 VDF 的种子 s(例如区块哈希),然后运行 VDF n 次迭代,使用其输出 f(s,n) 作为无偏的随机性。假设没有人能在小于 t 秒的时间内预测 f(s,n),我们可以让玩家在 t 秒内进行各种操作和出价,并将结果 f(s,n) 用作发生在 t 秒前的事件的随机性。换句话说,VDF 随机性的无偏性并不依赖于加密经济或信任假设;而是依赖于对顺序计算最大速度的假设。

PoC 描述

PoC 包含一个链下组件和链上的智能合约。链下组件包括 VDF 的重计算部件,即计算延迟函数和生成证明。在链上,有两个智能合约:一个验证者智能合约负责验证证明,及一个信标智能合约用于注册计算出的随机性(针对已验证的证明)。

具体的流程如下:

  1. 每 820 个区块选择一个区块(大约每 3 小时一次)
  2. 从区块哈希计算种子 s
  3. 计算 VDF 输出 f(s,n)——对 s 运行延迟函数 fn 次迭代
  4. 生成证明以证明计算的有效性
  5. 将证明发送至 验证者智能合约
  6. 将新的随机性发送至 信标智能合约

在 PoC 中,迭代次数为 10*2**25–1,相当于大约 3.5 分钟的延迟(在强大的最新一代 CPU 上,每次迭代大约需要 634 纳秒)。新的随机性以及证明预计将在所选区块被挖掘后大约 20 分钟接受上链。这个时间可以改善,但不在这个 PoC 的范围内。有关技术方面的更详细说明,请查看 github 仓库

重要声明:作为 PoC,没有对运行时间或服务的持久性的保证。这是一次探索性的举措,旨在征求社区的意见和想法。

未来应用

我们正在研究的还有其他几个应用,超越随机性。我们将简要讨论其中的两个:时间锁和下一代 PoW 机制。我们相信,随着生态系统开始认真探索 VeeDo,会有许多其他应用出现。

时间锁:时间锁是一个重要的密码学构建模块。它允许信息在预定的时间段内被封存,然后公开。通常,时间锁是使用 承诺方案 实现的。这种方案的主要缺点在于,承诺方在以后的时间内仍需在线以揭示承诺的信息。隐含地,这也意味着承诺方有选择不揭示其承诺的选项。这相当于一个免费选择,如果这个选项未能得到适当定价,市场的效率就会降低。在无需许可的区块链中特别有趣的两个用例是去中心化投票和密封竞标拍卖。VeeDo 可以提供帮助:正如我们上面提到的,VeeDo 的延迟函数一个有趣的特性是,反向( f ^(-1))的计算要短得多。有意在时间锁定一个秘密 b(例如一个出价或一个投票)的用户可以快速计算并发布 s= f ^(-1)(b, n)。现在公众可以通过计算 f(s,n) 来了解 b,从而在希望的延迟后揭示 b

下一代 PoW:在区块链领域,一个稳健的 PoW 算法依然是一个具有挑战性的问题。当试图 启动 一个区块链及其代币经济时,这个问题更为复杂。现有解决方案都有缺陷:空投容易受到 Sybil 攻击。ICO 仅限于合格投资者。最后,“一个 CPU = 一个 投票/代币”的原始愿景证明是相当难以实现的,因为定制硬件总是迅速建立以加速任何给定的 PoW 算法。结果是挖矿的网络去中心化程度下降。VeeDo 提供了一个替代方案,公平化竞争场:拥有昂贵和定制硬件的用户在 CPU 用户面前几乎没有优势(并且这种优势有上限)。

商业模型创新

VeeDo 不仅是一个技术实验,也是一个商业实验。DeFi 正在迅速发展,生态系统才刚开始理解这些天正在开发的许多金融积木可以做什么。可以按照其操作的层级进行分类:

  • 第一层(L-1):正如 Uniswap 等给我们展示的,可以直接在 L-1 上使用这些积木构建很多东西。
  • 第二层(L-2):从我们非常以区块链为中心的宇宙视角来看,可以说金融科技(PayPal,Coinbase 等)是全部 L-2。
  • L-1/L-2 接口:如果我们能够有效地跨越 L-1/L-2 的鸿沟,并利用 L-2 中可用的资源(云/移动的计算和存储)来推动 L-1 上的交互,那么金融积木可能会变得更强大。

VeeDo 是我们首次探索此接口的尝试。VeeDo 的“前端”是一个以太坊上的智能合约(L-1);其“后端”在云中计算 STARK 证明(L-2)。

第一批挑战涉及到服务可用性:我们如何确保足够的正常运行时间?我们如何确保整个服务足够去中心化?在这里,有几个方向可以探索,包括开源、许可和让智能合约收取费用。

通过智能合约费用进行货币化可能会面临 “搭便车问题”,特别是在考虑公共产品时,比如这种稳健的随机来源。对此,我们还有些想法将在未来一段时间内探索。

结论

VeeDo 是 StarkWare 基于 STARK 的 VDF,目前其 PoC 已在 Mainnet 上线。我们看到前方有许多令人兴奋的应用。第一个应用是利用 VeeDo 生成稳健的随机性。这些都是实验性的内容,因此我们期待听到你的反馈,讨论感兴趣的应用等。请通过电子邮件与我们联系 veedo@starkware.co

~Kineret Segal, Tom Brand

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

0 条评论

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