0xPARC

by gubsheep

A series on why new advances in cryptography may be important for digital identity primitives. The first post covers the “Why”; this post covers the “How.”

In our last post, we discussed why new cryptographic tools, such as zkSNARKs, will be crucial for constructing the next generation of digital identity infrastructure. In this post, we’ll dive into the weeds—what technical work needs to happen to build proof-of-concept ZK-based identity systems?

The ZK Identity “megaproject” is much larger than any one organization. Setting standards, building infrastructure, and iterating on identity primitives and application design questions will happen gradually, and require input from a variety of different stakeholders and areas of expertise. Given that ZK identity mechanisms have the potential to impact many people and also to rely heavily on public goods—open-source infra, tooling, standards, coordination—it is important that the effort arises bottom-up from an organic and community-driven “ecosystem,” rather than top-down from a single company; and that special attention is paid to sustainable development and incentive design.

It is also increasingly unlikely that an isolated company will succeed in such a dynamic ecosystem, as technology developed independently at all levels of the stack is changing rapidly. Instead, we’ll need to foster and coordinate an ecosystem of modular, fast-moving, and semi-independent teams sharing a common overall vision.

The 0xPARC ZK-identity working group hopes to contribute to the collective ZKID effort where we can, and we invite others who are actively thinking about this problem to join us and compare notes.

Building Blocks for ZK Identity

https://0xparc.org/static/zkid_building_blocks.png

ZK Identity tools must enable participants in digital systems to make claims about identity and reputation. Concretely, these claims boil down to mathematical statements about the execution of cryptographic operations like signature verification, key generation, hashing, and encryption in zero-knowledge. We can combine these “building blocks” together to build ZKPs for more complex claims: for a toy example, see our post on ZK Group Signatures.

Some operations and cryptographic schemes can be implemented more efficiently in zkSNARKs than others. In the long term, SNARK-friendly cryptographic standards may be adopted by new identity providers that don’t yet exist today—for example, blockchains with public/private key signature schemes based on SNARK-friendly cryptography (or more expressive systems like account abstraction). But in order to prove concept and to be useful in the near term, our tools need to integrate cleanly with existing cryptographic identity systems—for example, Ethereum’s present ECDSA signature scheme, or more recent cryptographic standards coalescing around pairing-friendly elliptic curves in other contexts.

We believe that building a usable toolstack for ZK Identity applications will require significant progress on four fronts: ZK application design patterns, implementation of ZK circuits for cryptographic primitives, circuit security tools, and developer tools and infrastructure. We summarize each area below.

ZK Apps and Design Patterns

https://0xparc.org/static/zkid_apps_design_patterns.png

First off, the output of our work should be touching end users and enabling impactful production applications. In parallel with developing ZK tools and building blocks, we’ll have to figure out the best way to use and compose them. Here are a few open questions:

The best way to answer these questions is just to start building! We hope that a robust developer community may start to form in the next few years, building applications with a variety of different approaches.

Several ZK-Identity apps can in fact be built today with the existing state of infrastructure. This is high-leverage work—beyond delivering useful applications, these projects will also inform development on tools and infrastructure. Here are some candidates for initial production applications of ZK Identity:

ZK Circuits for Cryptographic Identity Primitive

https://0xparc.org/static/zkid_circuits.png

Stepping one level deeper in the stack, we need efficient, audited implementations of ZK circuits for core cryptographic primitives and the mathematical operations underlying them. Here is a sample of some key operations, in a very rough dependency ordering.

Circuits for all of these might first be written for R1CS (allowing for groth16 setup and proving in the near term), and in the near future optimized further for PLONK-based proving systems.

Developer Tools and Infrastructure

https://0xparc.org/static/zkid_devex.png

Developer tooling for ZK circuit engineering is an important topic. Currently, ZK developers require a relatively high level of mathematical background and technical sophistication, they must write in relatively low-level development environments, and they rely on manual effort or ad-hoc scripts to manage files and carry circuits through the development pipeline from design to production. Furthermore, the developer tooling work that has been done is scattered and fragmented among multiple R&D teams, rollup companies, and more.

Of special note here is the importance of a robust toolstack for PLONK specifically. PLONK removes the need for per-circuit trusted setup, significantly speeds up compilation and proof generation for certain circuits thanks to custom constraints, and paves the way for recursive SNARK verification. However, tooling for PLONK is currently at a much earlier stage of development than Groth16 tooling, as provers are much less optimized and support for advanced protocol features is not yet implemented in certain systems. Furthermore, much work remains to be done on standards for IRs and the design of a language for custom constraints. Groups like AZTEC, Electric Coin Co, iden3, ZK-Garage, and more are hard at work building these tools.

Beyond PLONK toolchains, here are a few active areas of work in ZK developer tooling.

Auditing and Verification

https://0xparc.org/static/zkid_auditing.png

The above-listed circuits are complex and extremely hard to verify manually. Clever constraint optimizations actually compound the problem—highly-optimized circuits are hard to reason about, and its easy to miss a constraint during implementation if you’re doing something tricky. Furthermore, it can be impossible to tell if a bug in a ZK circuit has been exploited in the wild, due to the nature of ZK applications.

It’s fairly easy to write tests that give you confidence of completeness: demonstrating that you can generate witnesses and valid proofs for witnesses properly from inputs. Gaining confidence in soundness is harder. To do this, you’d have to verify that there is a unique witness that satisfies the constraint system of a SNARK for a given input—that a malicious prover can’t substitute in a faulty witness that generates a valid proof due to a missing constraint. Even harder than this is proving equivalence of a circuit to a specification, i.e. formal verification.

Currently, the approach taken by most teams using ZK circuits in production is to commission manual, human audits, though the quality of these audits is inconsistent and the total number of people capable of performing audits is very small. We may be reasonably certain that applications like Tornado.Cash, whose circuits total only about 100 lines of circom code, are probably secure. However, our proof-of-concept groth16 ECDSA implementation relies on thousands of lines of circom code, with circuit sizes in the hundreds of thousands or millions of constraints. More complex primitives will be even harder to verify, and PLONK custom constraints will add additional complexity.

We suggest a handful of approaches for the ZK application security space. In the future, we’ll publish a blog post with a deeper overview of current approaches in this domain that we are aware of.

一系列关于为什么密码学的新进展可能对数字身份原语很重要的系列。第一篇文章涵盖了“为什么”；这篇文章涵盖了“如何”。

在上一篇文章中，我们讨论了为什么新的加密工具（例如 zkSNARKs）对于构建下一代数字身份基础设施至关重要。在这篇文章中，我们将深入探讨——构建基于概念验证 ZK 的身份系统需要进行哪些技术工作？

ZK 身份的“大型项目”比任何一个组织都要大得多。设置标准、构建基础设施以及迭代身份原语和应用程序设计问题将逐渐发生，并且需要来自各种不同利益相关者和专业领域的投入。鉴于 ZK 身份机制有可能影响许多人，并且严重依赖公共产品——开源基础设施、工具、标准、协调——重要的是，这种努力从一个有机的和社区驱动的自下而上产生“生态系统”，而不是从一家公司自上而下；并且特别关注可持续发展和激励设计。

一家孤立的公司也越来越不可能在这样一个动态的生态系统中取得成功，因为在堆栈的各个级别独立开发的技术正在迅速变化。相反，我们需要培养和协调一个由模块化、快速移动和半独立的团队组成的生态系统，共享一个共同的整体愿景。

0xPARC ZK-identity 工作组希望尽我们所能为 ZKID 的集体努力做出贡献，我们邀请其他积极思考这个问题的人加入我们并进行比较。

ZK 身份的构建块

https://0xparc.org/static/zkid_building_blocks.png

ZK 身份工具必须使数字系统中的参与者能够对身份和声誉进行声明。具体来说，这些主张归结为关于在零知识中执行签名验证、密钥生成、散列和加密等加密操作的数学陈述。我们可以将这些“构建块”组合在一起，为更复杂的声明构建 ZKP：有关玩具示例，请参阅我们关于ZK 组签名的帖子。

在 zkSNARKs 中，一些操作和加密方案可以比其他的更有效地实现。从长远来看，对 SNARK 友好的密码标准可能会被当今尚不存在的新身份提供者采用——例如，具有基于 SNARK 友好密码学的公钥/私钥签名方案的区块链（或更具表现力的系统，如帐户抽象） ）。但是为了证明概念并在短期内有用，我们的工具需要与现有的加密身份系统干净地集成——例如，以太坊目前的 ECDSA**签名方案，或者在其他领域中围绕配对友好**椭圆曲线合并的更新的加密标准上下文。

我们认为，为 ZK 身份应用程序构建一个可用的工具堆栈将需要在四个方面取得重大进展：ZK 应用程序设计模式、加密原语的 ZK 电路实现、电路安全工具以及开发人员工具和基础设施。我们在下面总结了每个领域。

ZK 应用程序和设计模式

https://0xparc.org/static/zkid_apps_design_patterns.png

首先，我们工作的输出应该是触及最终用户并启用有影响力的生产应用程序。在开发 ZK 工具和构建块的同时，我们必须找出使用和组合它们的最佳方式。以下是一些未解决的问题：

回答这些问题的最好方法就是开始构建！我们希望在未来几年内可以开始形成一个强大的开发者社区，使用各种不同的方法构建应用程序。

事实上，现在可以使用现有的基础设施状态构建几个 ZK-Identity 应用程序。这是一项高杠杆工作——除了提供有用的应用程序之外，这些项目还将为工具和基础设施的开发提供信息。以下是 ZK Identity 初始生产应用的一些候选对象：

加密身份原语的 ZK 电路

https://0xparc.org/static/zkid_circuits.png

在堆栈中更深一层，我们需要针对核心密码原语及其背后的数学运算对 ZK 电路进行有效、经过审计的实现。这是一些关键操作的示例，以非常粗略的依赖顺序排列。

所有这些的电路可能首先为 R1CS 编写（允许在短期内进行 groth16 设置和证明），并在不久的将来进一步优化基于 PLONK 的证明系统。

开发人员工具和基础设施

https://0xparc.org/static/zkid_devex.png

ZK 电路工程的开发人员工具是一个重要主题。目前，ZK 开发人员需要较高的数学背景和技术水平，他们必须在较低级别的开发环境中编写，并且从设计开始，他们依靠人工或 ad-hoc 脚本来管理文件和承载电路。到生产。此外，已经完成的开发人员工具工作分散在多个研发团队、汇总公司等之间。

这里需要特别注意的是，强大的工具栈对于 PLONK 的重要性。PLONK 消除了对每个电路可信设置的需求，由于自定义约束，显着加快了某些电路的编译和证明生成，并为递归 SNARK 验证铺平了道路。但是，PLONK 的工具目前处于比 Groth16 工具更早的开发阶段，因为证明者的优化程度要低得多，并且在某些系统中尚未实现对高级协议功能的支持。此外，关于 IR 的标准和自定义约束的语言设计还有很多工作要做。AZTEC、Electric Coin Co、iden3、ZK-Garage等团体正在努力构建这些工具。

除了 PLONK 工具链之外，这里还有一些 ZK 开发人员工具的活跃工作领域。