Ingonyama:为什么 zkp 计算需要硬件加速?

Franci热度: 6370

Ingonyama正在构建硬件,以加速零知识证明(zkp),以替代工作量证明(POW),并可用于游戏、虚拟世界、人工智能、银行系统等。ICICLE支持NVIDIA GPU,允许开发者将zk协议移植到GPU,以提高性能,并且支持原语,API应该非常直观和简单。

摘要由 Mars AI 生成
本摘要由 Mars AI 模型生成,其生成内容的准确性、完整性还处于迭代更新阶段。

原文作者:Franci

原文来源:Antalpha Labs

「引介」

虽然我们都关心 zk 如何让我们的生活更美好,但工具也至关重要。在过去的播客中,我们讨论了 zkp 证明系统,使得证明生成更有效的算法。我们还从应用程序和用户用例的角度讨论了 ZKML。在这期播客中,我们将从软件和算法转向硬件。硬件是如何让 ZK 变得更加无缝和去中心化的。我们请来了 Ingonyama 的 CEO 和 Co-founder Omer Shlomovits。此外,还邀请了一位 cohost 来帮助我深入探讨一些问题,他就是 Ingonyama 中文社区的大使 Miles。

Guest: Omer Shlomovits, the CEO and Co-founder of Ingonyama, X(twitter)@OmerShlomovits

Cohost: Miles, the Chinese Ambassador of Ingonyama, X(twitter) @Sixmiles0825

Host:Franci@FrancixDeng

ZKP「为什么 zkp 计算需要硬件加速」

  为什么需要硬件加速,它是如何整个系统服务的

首先,通常来说一项技术要进入主流并取得成功,你需要软件、硬件和算法。如果你看看今天的人工智能,它比我们成熟得多,你会发现我们衡量或谈论人工智能的方式都是从系统的角度来说的。比如我们从硬件开始,你需要有 NVIDIA GPU,你在 GPU 上测量性能,你知道如何在 GPU 上运行所有的人工智能模型。因此你需要为此开发软件。显然,为了改进和优化,你需要更多的算法。虽然最终这是我们需要的,但这并不意味着它是这样开始的。像零知识这样的技术,都是从算法开始的。40 年前,学术界小部分人提出这个东西。从那时起,算法就一直在改进,向我们展示了复杂性可以越来越底层,直到我们能够理解我们想要做出的权衡。当我们真正接近这个行业并尝试在生产系统上取得第一次突破时。你要做的第一件事就是在你拥有的硬件上实现最容易实现的硬件,就是 CPU。但是 CPU 是用于通用计算的。大多数密码学,有限域算法等等适用于另一种方式。所以就这个行业而言,我们开始使用这个基于 CPU 的软件。但现在我们已经能够在不同类型的硬件上观察和测量结果,所以我们可以更好地理解硬件,从而获得更好的性能。

 zkp 计算与过去的 PoW 挖矿有什么不同?

至少对于这种类型的加密,很明显存在瓶颈,其中一些是计算瓶颈。其中一些是其他瓶颈,比如内存网络,但它们可以用硬件来解决,就像摩尔定律。在某种程度上,如果我们想继续改进技术,我们需要在某种程度上与摩尔定律保持一致,并开始改进硬件,以便能够更有效地运行 zkp。

现在,你可以用零知识证明作为工作量证明的一种方式。实际上有论文证明了这一点,甚至有一些区块链的实验,比如 Aleo,也做了类似的事情。

所以在探索方面,一些矿业公司有大量的 GPU 用于以太坊。但不是比特币矿工,因为他们非常具体。也许零知识的第一个用例将来自这种类型的工作量证明共识。

因此,如果你从更广泛的角度考虑,它最终会导向一些更好的硬件设计,零知识证明并不止于此,它可以被视为许多其他事情。例如,在人工智能产品中添加 zkp 作为功能可能会有很大的市场。我想象一家人工智能公司现在想要使用零知识证明来实现这种可验证性。

所以,我们可能会在未来看到一些为 zkp 量身定制的不同类型的数据中心,我们所做的部分工作就是努力实现这一点。首先要思考和构想这些数据中心,它们会是什么样子,以及如何让最终用户很好地使用它们,如何让任何人都能以去信任的方式访问它们。

简而言之,你可以用 zkp 来代替 pow,但是 zkp 的潜力要大得多。

  从区块链以外的需求角度谈 ZKP 的硬件采用

我们从很早开始就在公司里尝试着探索这个领域内外的不同垂直领域,因为想做的是,我们可以采用任何类型的硬件,在硬件上运行零知识证明,给你带来完整的解决方案。

所以当你从这个角度思考这个问题时,它使我们能够与不同类型的行业进行对话。举个例子,比如我们进入了摄像头和物联网行业。

所以你有一些用于监控的物联网,你想监控一些周边。通常,一种方法是从这些物联网设备的数据点收集数据,在设备上进行一些处理,然后将其发送到某个集中服务器。很明显,这里有一个问题,因为你正在向这个数据中心发送大量的数据,这些数据基本上是无用的数据,或者什么都没有。

但你仍然需要在数据中心中运行这个逻辑,因为没有其他方法,你需要获取这些数据。但是如果我们可以使用零知识证明,假设它运行一些机器学习模型,比如检测事件。如果我们要在上面运行 zk,来表明在一段时间内什么都没有发生。最终,你不需要发送所有的原始数据,你只需要发送证明,这是非常小的,就像数学证明一样,在这段时间里什么都没有发生。所以我认为省钱可能是这项技术被采用的主要因素之一。

自从公司成立以来,我们在游戏、虚拟世界和人工智能等领域探索了很多很棒的内容。还有一些其他的正在进行中,银行系统,身份和隐私广告。这些例子显然都涉及硬件。

因此,你无法逃避 zkp 最终需要在某些硬件上运行的事实。有些东西将在不同类型的硬件上运行,最终我们需要指向哪种硬件更好,更合适,我们如何开发硬件来支持这种类型的计算并使其成为可行的用例。

「如何制造满足不同需求的硬件」

  Ingonyama 此刻的主要关注点

我确实认为我们的行业现在专注于构建我们称之为中间件的东西。这听起来可能是件坏事,应用程序在哪里? 但换个角度思考,让开发者可以使用工具消除复杂性,获得友好的开发体验(这是非常直觉的东西)也十分关键。

我看到了社区中大家所做的一些努力,比如 Starkware 开源了他们的证明器。它不一定会让其他人更容易使用,但现在它为许多开发团队打开了大门,他们可以在此基础上构建工具,让其他人也能享受到这个复杂的证明器。我觉得随着时间的推移,这些东西变得越来越简单,看起来很好。

我想我们的关注点在某种程度上与这些是一致的,这意味着我们需要一些时间来了解我们在硬件采用行业的位置。

很明显,今天当一个新的开发团队正在构建一个协议时,他们通常会采用现有的框架,然后开始调整它并优化算法,这在软件上还有很大的空间可以做。但它们仍然缺少在正确的硬件上运行的这一部分。这甚至不像优化。想象一下,今天写一篇人工智能论文,发表它,并使用 CPU 来测试你的人工智能基准和性能。

你无法想象,现在没有人在 zk 领域这么做。所以我们现在需要对 zk 做同样的处理。我认为在这一点上,我们需要使其标准化,有一个好的方法来衡量。这是什么意思?比如我们如何比较不同的应用解决方案,然后有了这些最佳实践,团队就可以在正确的硬件上进行部署。这是我们目前的主要关注点。

介绍 zkp 加速的主要解决方案和 Ingonyama 采用的路径

目前我们仍然没有 zk 的 ASIC,而世界上有很多公司在这方面上已经走得很前。所以,最终这可能会成为我们的一种商业类型。

我们现在提供的是,我们可以访问相当多不同的硬件设备,其中一些我们已经开始了解它们如何在零知识证明的情况下工作。

所以 CPU 显然是最经得起考验的,但是当你尝试将 zkp 带入云端时会发生什么呢?现在的云实例有各种不同的设置和配置。zkp 能在云端高效运行吗?这是我们可以探索的一种路径和解决方案,我们与一些云提供商进行了讨论,试图更好地优化能够实际支持 zkp 的实例类型。然而结果并不是很好。但我们希望最终任何人都能使用它。因此,将其放在云实例上可能是一个很好的解决方案。

同样的道理也适用于可以以不同方式配置的数据中心,这仍然是一个好问题。从成本方面来说,显然,最容易使用的两个类别是 GPU 和 FPGA。

我的公司刚开始是先为 FPGA 和 ASIC 构建 IP,但这不是很优的方案,所以我们改变了我们的设计,总体来说就是构建 GPU。我们也在探索 GPU 运行 Snark、Stark 和一些混合解决方案。

当你想在 Mac 上运行 GPU 时会发生什么?在浏览器?在移动端呢?所以这里有很多硬件方面的开放性问题和未来的发展方向。我们正试图找到最适合多数用例的方法,并支持这些公司构建 zkp。

ICICLE 是用来做什么的?

假设你有你自己的基于 zk 的产品,它在你自己的 CPU 上,你有自己的用户并想要扩容。如果你想让它更快,你需要转向硬件,那你基本上需要放弃 CPU,开始在特定的硬件上运行。

ICICLE 支持 NVIDIA GPU,它允许你作为一个开发者,如果你已经有一个现有的 zk 协议,可以将其移植到 GPU。所以你基本上每次移动一个部分在 GPU 上运行,而不仅仅是在 CPU 上运行,直到你可以在 GPU 上运行所有内容,从而立即提高性能。

它最终也会允许你使用其他类型的硬件,但目前只能支持 GPU,它非常容易访问,也很容易编程。我确实希望将来可以在硬件上进行基准测试。

这就是未来的方向。你可以从 ICICLE 中获取组件,将它们像乐高积木一样组合起来,并从中获得一个新的协议,然后对其进行基准测试。API 应该非常直观和简单。

这个库的目标是任何使用 zk 的开发者,它可以在被允许在 GPU 上运行。强调一下,我指的是使用 Rust 和 Go 等语言的开发者,他们不需要了解它的内部结构,所以应该很简单。

从某种意义上说,我们是从支持 snark 开始的。像以前一样,它们只支持 MSM、NTT、默克尔树中的哈希函数等原语。未来,我们会同时支持更多的原语,更多的证明器,更多的协议,让 API 更好。对我们来说,API 是最重要的部分。

声明:本文为入驻“MarsBit 专栏”作者作品,不代表MarsBit官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
免责声明:本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况,及遵守所在国家和地区的相关法律法规。
关键字:ZKP