Tag: SIEVE IR

In prior posts to this blog, we’ve certainly aired our grievances with the prior IR release (v1, whereas we’re now at v2). You may want to go back and skim the previous retrospective and our BOLT fast interpreter. But if you don’t want to review those, IR1’s (IR1 was the old IR’s code name) memory layout was completely disorganized, and some of its higher level features proved difficult (@switch) or slow (@for) to implement. We spent a bit of time developing the BOLT interpreter with a few tricks for greatly accelerating how loops could be processed.

During development of the IR, the SIEVE Program sort of decided that circuits are not expressive enough to express certain functionality. For example, the comparison and division operations previously described on this blog cannot be encoded with the IR because they require plaintext computations to be performed and passed into the circuit. Certainly the frontend could do that, but so could the backend — and many already can, with further tricks that a frontend can’t reliably expect to exist. Hence, we created the plugin system to enable backends to implement certain functionalities on their own and provide an interface through the IR.

The SIEVE IR’s function gates will encapsulate a subcircuit so it may be reused many times over. Doing this can drastically reduce the size of a circuit. This may seem unimportant, considering how an interactive proof is likely to have communication proportional to the number of gates, however IO of the relation has proved to be a bottleneck in the past, and some relations have taken terabytes of space. So, its worth it to attempt to compress the circuit as much as possible.

In this series, we are examining the new SIEVE Circuit-IR. This installment will examine its type system and how it enables multiple types to be combined within the same relation.

The DARPA SIEVE Program has been developing the SIEVE Intermediate Representation for about three years, and we recently achieved our second public release: the Circuit Intermediate Representation. As one of the primary developers of it, team Wizkit will again blog about its development and workings. Today we’ll start a series overviewing the SIEVE Circuit Intermediate Representation (Circuit-IR) language and semantics, and of course our own WizToolKit library for this revision of the Circuit-IR.

Over this summer, Team Wizkit developed a concrete proposal for an overhaul of the SIEVE Intermediate Representation. While our proposal is a fairly radical departure from the original IR, we believe this proposal addresses our concerns about wire memory management and interoperability in the presence of wide differentiation between backend capabilities. In the upcoming months the SIEVE Program will internally agree upon a final draft for the Phase II IR, but we hope that sharing our IR proposal with the wider community will help others engage with the IR as it continues to evolve.

By now, you’ve read up on the SIEVE IR, you’re interested in ZK, and you’re ready to try it out the IR, but you’re not sure where to start. For a ZK frontend, the IR opens up a world of backends, while for a backend it enables a wide variety of users to leverage your backend. Well, here’s where to start: Team Wizkit has open sourced WizToolKit a collection of tools and libraries for working with the IR and EMP-IR a ZK Backend which uses the IR.

During most of 2021, the Wizkit team worked with other SIEVE Performers to develop and implement the SIEVE IR. Since it was finalized during summer 2021, we continued to push the envelope beyond what was demonstrated during the Phase I Testing Event. We’ve also been one of the most active voices, within the SIEVE program, critically analyzing this IR. In this blog post, we put the results of the critique to good use in making design suggestions for the next IR revision.

In this installation about the SIEVE IR, we’re going to talk about speeding up a proof system without changing the underlying zero-knowledge mathemagic. When we time a ZK backend using the IR we inadvertently time two distinct components — the backend itself and the time it takes to ingest a circuit. The first component, the backend, is fairly well understood and many groups are working on optimizing this — faster math and less communication. The second component is the topic of today’s post; it’s the time spent reading a gate and loading its operands before it can be processed in ZK.

In our previous post we took a first look at the SIEVE IR, presenting it as impartially as possible. Today we will take a more "opinionated" or normative look at the IR. On the one hand, we are very proud of this accomplishment — (to our knowledge) the first widely implemented circuit representation for ZK. However, we’d also like to acknowledge that the IR has its flaws and highlight where we think there is room for improvement.

Recently the DARPA SIEVE Program released a 1.0.1 version of its primary program-wide deliverable, the SIEVE Intermediate Representation (IR). As one of the primary developers of the IR, team Wizkit will write a series of posts about the IR, what it got right, what it got wrong, and what we’d like to see in upcoming versions. But today we will start the series with this post as more of an impartial introduction to the SIEVE IR. It is our hope that this will ease you into using the SIEVE IR in your own work, and (most importantly) enable you to read further posts in this series.