产品公告：ZK-Containers

与RockawayX[1]基础设施团队合作

加速ZK

ICICLE for ZK = PyTorch for AI
Ingonyama是ICICLE的开发者,ICICLE基于CUDA设计，因此目前仅支持Nvidia GPU。ICICLE使开发团队能够轻松地将ZK技术集成到他们的产品中，并为他们节省了大量的研究工作来实现加速的ZK原语 ICICLE 然而，目前还没有部署ZK应用程序的标准，这就是为什么我们引入ZKContainers：ZK开发者可以用来部署和扩展其零知识证明基础设施的构建模块

但是对于客户端的零知识证明（ZK）呢？如果我是一名普通用户，现在就想参与支持零知识验证的网络怎么办？

对于即将到来的2024年来说，最相关的用例是一个公司希望利用其现有的GPU参与ZK项目的证明网络。以Scroll[2]为例，它是目前正在生产中的领先零知识证明网络。要参与其中，有最低的硬件要求：

Scroll证明网络最低的硬件要求
64线程CPU、400GB CPU内存、2X RTX 3080 GPU

我们可以想象，为了参与Scroll证明网络并盈利，将会有ZK数据中心的用例，矿工可以快速扩大或缩小其操作规模。

随着零知识证明进入新的行业中，不难想象那些运营大量硬件并希望添加ZK作为特性的服务提供商（想象一下OpenAI和chatGPT的问责性）。在这个例子中，同样需要一种简单的方法来部署、测试、更新、扩展和试验证明软件的不同配置。目前市场上还没有解决方案。零知识证明开发者应该能够轻松地在单台机器或集群上部署他们的应用程序，并享受方便的DevOps工具和管理系统。

为了支持这些令人兴奋的用例和希望扩展其ZK操作的团队，我们提供了一套新的工具，与ICICLE相结合。让我们介绍ZKDC框架，一套为ICICLE应用程序提供的安全优化的零知识证明容器和一套部署基本零知识证明数据中心的脚本。在这篇文章的其余部分，我们将主要讨论我们解决方案的技术规格。要获取代码（仍处于alpha阶段）或安排演示，请联系hi@ingonyama.com

The ZKContainer

作为我们市场研究的一部分，我们采访了目前在大规模运行ZK的公司与项目方。我们想了解这个行业是否以某种方式独立地趋同于某种神奇公式。

答案是，并没有出现这种情况，这个答案并不令人意外。ZK的计算具有独特的特性，没有人可以提供一种适合所有人的解决方案（想象一下针对ZK的云服务），我们看到了不同的方法，从Kubernetes和Hadoop到一些定制软件。一些公司选择了本地部署，而其他公司则使用云服务提供商部署。Zk的数据中心多种多样，但是缺乏工具和最佳实践。

鉴于我们已经拥有ICICLE用于ZK应用程序开发，逻辑上的第一步是将这样的ZK程序打包成便携式且随时可用的形式。于是引入了ZK Container（ZK容器，简称ZKC）。

容器是虚拟机的轻量级替代品。它们允许开发人员将软件及其依赖项打包在一个隔离的单元中，这个单元可以轻松地部署在任何环境中。

容器是当今云计算中使用的基础技术之一。在人工智能（AI）领域，容器经常被用来部署和扩展AI工作负载。容器还开发了许多工具，这些工具允许在本地和云端的数据中心中自动扩展软件。 ZK Container架构 ZK容器是一个Docker镜像，其中包含了ICICLE及其所有依赖，以便在Nvidia GPU上运行优化的ICICLE应用程序。以下是使用ZKC所启用的功能列表：

快速原型制作：只需几条命令行即可在不同的证明者和硬件配置之间切换
存储解决方案：生成ZKP通常需要生成许多文件，ZKC使得配置存储位置、缓存和在证明后清理变得更加容易
快速扩展：从单个集群节点甚至单个GPU开始测试，并根据需求轻松扩展。容器还允许简单地实施负载平衡、资源配置和优化
内置多种用例：如运行不同的证明协议（Groth16、Plonk）和不同的实现（Gnark、Halo2）
内置日志解决方案：可以连接到中央日志解决方案
通用工具：由于我们目前仅支持Nvidia GPU，我们的容器可以与Nvidia的GPU数据中心工具，如NVIDIA GPU Operator配合使用
安全性：ZKC镜像会被扫描常见的CVEs
持续更新：ZK容器会与最新的Icicle改进保持同步更新
多容器平台支持，虽然Docker目前是我们的主要关注点，但我们也允许您为Singularity[3]、cri-o[4]和containerd[5]构建容器。
可在任何地方运行：本地、裸机、云平台、Kubernetes、虚拟机以及支持容器的各种架构。
持续测试：确保ZKC在各种系统上即插即用。您可以在找到我们的ZK容器[6]（需要我们提供访问权限，请发送邮件联系）。

演示示例-Aleo Prover

对于这个演示，RockawayX为我们提供了访问他们的GPU数据中心和基础设施支持。我们与他们合作的目标是在其拥有6000多个GPU的数据中心部署我们的Aleo证明者；这个集群中的每个节点包含8个GPU。我们的目标是保持每个节点100%的GPU利用率。

我们首先为我们的Aleo共识证明者创建了一个docker ZK容器。这个容器包含了所有必需的依赖、工具和优化，并使用Ingonyama的CLI工具和基本ZK容器创建。CLI工具允许您在本地为您的零知识证明应用程序和部署环境配置自定义容器。

配置、构建和部署 ZK 容器

这次部署的架构相对简单，因为我们没有对自动扩展、外部数据源或负载均衡的需求。我们部署的第一阶段是配置节点上的正确软件；第二阶段是在所有节点上启动容器化的证明者实例。为了配置集群中的每个节点，我们使用了Ansible[7]，这是一个开源的 IT 自动化软件。Ansible 使您能够启动机器、配置机器、在机器上运行脚本，并在许多机器上自动部署软件。

接着，我们使用 Ansible 脚本来部署容器化的 Aleo 证明者，由于 ZK 容器包含了它应该在机器上消耗的 GPU 数量和资源信息，因此它自动启动并开始证明。

正如预期，使用 ZK 容器，这个过程没有出现任何问题。手动配置 6000 个 GPU 本来会是一个噩梦，即使我们只需要调试其中 1% 的依赖或兼容性问题。由于使用了 ZK 容器内置的监控工具，监控过程也大大简化了。

在这次部署中，每个节点由 8 个 Nvidia GPU 组成，每个节点能够达到令人印象深刻的每秒约 56,000 个证明（Proofs per second）。毫不奇怪，整个数据中心的性能完全等于 GPU 数量乘以单个 GPU 的最大吞吐量。

总的来说，使用 ZK 容器极大地简化了部署和配置过程。未来的更改和更新也将简化，因为任何更新都可以通过更新容器并重新部署来立即部署。节点可以配置各种硬件、CPU、RAM、内存、一系列 GPU 和互连，而无需进行大规模软件更改，只需更新容器。最重要的是，更改可以在先在 1-2 个节点上测试后再部署到整个数据中心。