At RISC Zero, we envision a future with boundless computation built on zero knowledge proofs. Today, we took a major step toward implementing this vision with tools available to all. We published v0.15 of the RISC Zero zkVM, which includes one of my favorite features: continuations.

In the context of our zkVM, continuations are a mechanism for splitting a large program into several smaller segments that can be computed and proven independently. This has many benefits, for instance:

• Parallelizing proving
• Enabling pausing and resuming a zkVM (similar to a “warm start” on AWS Lambda)
• Limiting memory requirements to a fixed amount, regardless of program size

I discuss each of these a bit more at the end of this post, but the main benefit I'll focus on today is that with continuations, programs are no longer bounded by a fixed maximal length of computation. With continuations, programs can run for however many instructions it takes to get the job done.

But what does an unbounded cycle count enable in practice? The pithy answer is that the possibilities are endless — our zkVM is general purpose and can run anything that compiles to RISC-V (e.g. Rust, but also C++, Go, etc.), and now, just like the device you're reading this on, our zkVM will execute programs for however long they take to complete. This possibility, while endless, is comprised of innumerable specific examples. For instance, with continuations, you can run an EVM engine inside the RISC Zero zkVM, and prove the state changes caused by an Ethereum transaction. By "you," I mean you, personally, right now, on your laptop. Whenever you like, you can head on over to our EVM example, check out the source code, and run it for yourself! In the meantime, keep reading for a deeper explanation on what continuations enable, including how we use them to prove the results of Ethereum transactions.

Running the EVM on the RISC Zero zkVM​

Erik recently described how the RISC Zero zkVM differs from a zkEVM. That post is worth reading in full, but I'm going to gloss over the details and nuances and instead pull a single key quote:

On the zkVM, you can run just about any software that runs on a computer rather than anything that can run on Ethereum.

The EVM is software that runs on a computer. This quote, then, suggests that the EVM can be run inside our zkVM — and indeed it can. In fact, a few different teams have done this already: Odra wrote a proof of concept with SputnikVM, zkPoEX also uses SputnikVM to produce proofs of exploits, and we have an EVM example using revm.

The revm crate is a Rust-based EVM interpreter. Like most Rust crates, the revm crate can be run in the RISC Zero zkVM. Our example does exactly that. When you point it at an Ethereum transaction, our example will use revm to execute the transaction to compute the new state. It will then create a receipt containing the difference in state after the transaction has been executed and a zero-knowledge proof that this result is accurate.

Before continuations, this process worked only for small transactions. Therefore, when we published our EVM example, we used this small transaction as a demonstration so we could prove the transaction without hitting the cycle cap. However, since we hadn't yet added continuations to the zkVM, we also published our EVM example with a warning that it wouldn't work for all transactions, and in particular was unlikely to be able to prove transactions with elliptic curve precompiles.

With continuations, we no longer have this limitation. You can, for instance, prove this fairly heavy transaction for a contract using the ecrecover precompile and 5 KECCAK256. On my M1 Max MacBook Pro, this took about 12 minutes and about 12 GB of memory. The runtime will of course vary from system to system, and depends on the length of the program execution. The memory requirements, however, should be similar regardless of what system you run the proof on, and also regardless of the length of your program.

And to be clear, it’s not just that this particular transaction can now be proven on the zkVM. It’s all transactions: with continuations, any Ethereum transaction can be proven on the RISC Zero zkVM using our EVM demo, and there is no limit on transaction size.

What Is a Continuation?​

I mentioned at the start of this post that continuations are "a mechanism for splitting a large program into several smaller segments that can be computed and proven independently." This mechanism works by tracking the state of the zkVM at the start and end of each of these smaller segments, in the form of Merkle trees of the memory image (plus the program counter). This lets us compare the ending state of one segment to the starting state of the next.

A zkVM program is automatically split into segments, based on the cycle count. If the program would run for more cycles than allowed in a single segment, it is automatically split. We use the term "session" to mean sequence of segments where the first segment was initiated by the user and the final segment was terminated by the user (as opposed to being terminated by an automatically generated split). Thus, while segments have arbitrary boundaries determined automatically to stay within the per-segment cycle limit, sessions instead represent semantic boundaries, both starting and ending at the request of a user.

A session receipt consists of multiple segment receipts, and is validated by confirming that:

1. each segment receipt is valid,
2. the starting receipt of each segment matches the ending state of the prior segment, and
3. the initial state (or image_id) matches what the validator expects (that is, that session is running the same code the validator wants to validate).

Benefits of Continuations​

As discussed with the EVM example, one of the most immediately apparent benefits of continuations is that you can now run a RISC Zero zkVM program for as long as you need to get the job done. But continuations enable more capabilities than just this. I want to touch on three I mentioned in the introduction: parallelization, pausing, and memory.

Parallelize​

These small segments can be distributed to many computers to parallelize the workload and reduce latency. The plan for where a zkVM program is split into segments and what work is done in each segment is computed ahead of proving by an "execution" phase. This gives a plan for proving each segment that is independent of the contents of all of the other segments. Thus, the hard work of proving the segments can be distributed amongst many systems, parallelizing the workload and reducing overall latency of the full proof.

Pause-Resume​

With continuations, a zkVM program can be paused and resumed. When describing segments, I mentioned that they lasted until the user asked for them to stop. This can be a traditional halt, indicating the end of computation. But it can also be a pause, which lets the user say "I want to do some computation now, and then come back at some later time and pick up where I left off."

For example, imagine a zkML workload in which an ML model is constructed, its weights are loaded, input data is provided, and an output is computed. In this example, the zkVM could be paused after the weights are loaded, just before input is provided. This has a couple of advantages. First, the model construction and weight loading could be performed prior to the user providing inputs, reducing the latency between inputs and outputs. Moreover, this initial setup phase could be performed once and paused, and then resumed multiple times for different inputs, saving the work of re-executing the shared setup.

Fixed Memory Requirements​

Prior to continuations, when a zkVM program took twice as many cycles, it roughly doubled the runtime and also roughly doubled the memory requirements. With continuations, memory requirements depend on segment length rather than total program length, so that programs of arbitrary execution length require a fixed amount of memory to run.

Continuations and Bonsai​

Continuations are a powerful tool. We want to simplify the complexities of continuations, and zero-knowledge proofs more generally, as much as possible. To this end, we are working on Bonsai, and so here I want to mention a few of the complications we expect Bonsai to simplify.

For one, while there is the potential for substantial latency improvement through parallelization, orchestrating the distribution of a program's segments is not built into the zkVM code.

For another, we currently only support flat continuations and not rollup continuations. With flat continuations, each segment produces its own receipt. Each of these receipts needs to be individually verified, and while we have helper functions to prove the overall program, the required verification work still increases with execution length. Rollup continuations would use proofs of verification to recursively rollup these individual segment proofs. The result would be that only a single receipt would be necessary for verification, and verification time would be constant regardless of execution length.

We are working on Bonsai, which we believe addresses these challenges and more. We expect Bonsai to make the power of zero-knowledge proofs and continuations easily accessible. If you're interested, sign up for the Bonsai waitlist!

The RISC Zero team is out in full force for ETHDenver! Come to our talks, booth, and developer meetup to learn more about what we have been hard at work building.

Bonsai

The RISC Zero team is excited to announce: Bonsai our Zero-Knowledge Proving Network

Bonsai is a general-purpose zero-knowledge proving network that allows for any chain, any protocol, and any application to take advantage of ZK proofs for scaling, privacy, and more. With Bonsai, ZK proof integration into ETH, L1 Blockchains, Cosmos App Chains, L2 Rollups, DApps etc. is possible in a matter of days with minimal development effort. Bonsai is a new kind of blockchain: a massively parallel, chain-agnostic, and general-purpose network designed to allow application developers to build new classes of applications.

Our RISC-V zkVM acts as the foundations of Bonsai and enables wide spread language compatibility with the potential for zero-knowledge provable code written in Rust, C++, Solidity, Go, and more. With a combination of recursive proofs, a bespoke circuit compiler, state continuations, and continuous improvements to the proving algorithm, Bonsai enables anyone to generate highly performant ZK proofs for a variety of applications.

Bonsai combines three key ingredients to produce a unique network that will enable new classes of applications to be developed across blockchain and traditional application domains:

• A general-purpose zkVM capable of running any VM in a ZK/verifiable context
• A proving system that directly integrates into any smart contract or chain
• A universal rollup that distributes any computations proven on Bonsai to every chain

Bonsai effectively allows for any application, blockchain, and appchain to easily integrate ZK proofs into their protocol without any custom ZK circuit development. This will enable a paradigm shift in how ZK proofs are used across the entire blockchain ecosystem.

The Bonsai Litepaper can be found AT THIS LINK.

🚀Get notified when Bonsai is released to the public🚀

The ETHDenver Bonsai Developer Website can be found AT THIS LINK.

💡 Early alpha access to Bonsai is currently controlled via a Whitelist.
💡 Developers looking to join the Bonsai Whitelist may fill out the form HERE

zkVM

One Page Overview

The RISC Zero zkVM is an open-source, zero-knowledge virtual machine that lets you build trustless, verifiable software in your favorite languages. The zkVM bridges the gap between zero-knowledge proof (ZKP) research and widely-supported programming languages such as C++ and Rust. ZKP technology enables programs' outputs to be checked for correctness by someone who cannot see its inputs. This verifiability enables game changing scalability and privacy across a wide variety of applications. The general-purpose nature of our zkVM also allows for it to be compatible across a variety of blockchain protocols.

The RISC Zero proof system implements a zk-STARK instantiated using the FRI protocol, DEEP-ALI, and an HMAC-SHA-256 based PRF. It also is compatible with recursion and has near unlimited proof complexity.

Current performance benchmarks can be found AT THIS LINK.

The RISC Zero zkVM Proof System Whitepaper can be found AT THIS LINK.

Getting Started​

The best place to started with our zkVM is our Docs. Within it you will find our project template, which acts as the foundations for any RISC Zero project. It will also help in giving a good feel for how each component of our project works together.

Moving on from this template, the RISC Zero Digital Signature Demo and Password Validity Checker are great examples of how our zkVM can be used to add security and privacy into existing technologies. Finally, our website and youtube channel have a variety of materials that should help you better understand the technical foundations of the RISC Zero zkVM.

ZKHack zkVM Demos

Our ZKHack presentation included a number of examples of zkVM projects. The full presentation can be found here. All demos can be found here.

Where to Find Us

Come to Our Talks!​

Building a Central Limit Order Book on Ethereum using ZK​

Brian Retford
Feb 27, 2023 11:10 AM - 11:30 AM MST
#BUIDLHub Mainstage, #BUIDLHub | 3403 Brighton Blvd, Denver, CO 80216

Zero-Knowledge Proofs have a lot of promise for both increasing privacy and scaling by verifying the correctness of off-chain computation. However, the development of traditional circuit based ZKPs is challenging, since the programmer needs to learn new languages, new concepts, and new development tooling. A new class of Zero-Knowledge Virtual Machines is attempting to allow ordinary code, such as Solidity or Rust to run inside ZKPs. This talk will describe how such ZKVMs work, including a basic background on ZKPs, arithmetic circuits, permutation arguments, and representations of memory, as well as providing resources for getting started using ZKVMs to implement off chain logic.

Just Prove It: ZK & the Future of Scaling​

Ash Schap
Mar 03, 2023 11:05 AM - 11:20 AM MST
Main Stage, National Western $SPORK Castle | 4655 Humboldt St Denver CO 80202

Zero-Knowledge Proofs will change computation as we know it, both inside Web3 and outside of it. But what do we need to get started on this vision? This talk will outline a generalizable, protocol-focused approach to empowering developers with accessible ZK tooling, unlocking the power of ZKPs for dapp and app developers and leading to the advent of truly scalable, verifiably correct computation for blockchain applications.

Zero-Knowledge Virtual Machines: Running Rust code inside a Zero-Knowledge Proof​

Jeremy Bruestle
Mar 04, 2023 1:30 PM - 1:50 PM MST
Decentralized Finance Stage, National Western $SPORK Castle | 4655 Humboldt St Denver CO 80202

A deep dive into how ZK can be used to execute complicated logic like order book matching off chain to build powerful apps on chain

If Knowledge is Power, What is Zero-Knowledge? An Intro to zkVMs​

Erik Kaneda
Mar 04, 2023 2:00 PM- 2:20 PM MST
Bunny Slopes, National Western $SPORK Castle | 4655 Humboldt St Denver CO 80202

In the past decade, we have seen the rise in popularity of zero-knowledge proof systems along with terminologies that are used to describe them such as STARK, SNARK, PLONK, etc. But what sorts of applications does zk tech actually enable? This talk aims to illuminate what is possible today through zkVM’s and what it means to write programs for them. The focus of this presentation is to describe the features of a zkVM and how developers can use it to build applications on blockchains and beyond!

Delendum Future Computing Research Workshop​

• Brian Retford, Our ZK-Enabled Future
  • Mar 01, 2023 10:45 AM - 11:00 AM MST
• Tim Carstens, Practical Benchmarks for ZK Systems
  • Mar 01, 2023 2:00 PM - 2:15 PM MST

RISC Zero Developer Meetup​

Click Here To Register Now!
Feb 27, 2023 4:00 PM - 6:30 PM MST
Shift Bannock | 1001 Bannock St, Denver, CO 80204

• 4:00 - Sign-In + Social
• 4:20 - ZK Panel + Questions
• 5:00 - Break
• 5:15 - Group Discussions
  • General ZK Developer & Ecosystem Concerns
  • zkVM & AppDev
  • Platform & Integrations
• 6:00 - Signups + Social + Feedback

Booth Location​

Come stop by our booth to meet the team and try live demos of our zkVM in action!

The booth is at marker (X) located inside the DeFi District next to the Coffee Lounge (15)

Bounties

ETHDenver Bounty Page: https://app.buidlbox.io/guidl/risc-zero

Bounty #1: Build on RISC Zero or Integrate RISC Zero into your project​

RISC Zero’s core technology is our RISC-V Zero-Knowledge Virtual Machine. On top of that, we’re building a zero-knowledge computing platform called Bonsai. Bonsai supports the ability to do arbitrarily complex computations in plain Rust and access proofs of those computations on-chain, effectively adding Rust support and zero-knowledge scaling to Layer 1 Ethereum.

Bonsai is currently in a pre-release stage and, as part of this bounty, we’d like you to build an application using Bonsai. Doing so requires getting early access, which you can request here. However, even prior to getting access, you can participate in this bounty.

To build such an application, you’ll need two major components: your application logic written in the form of zkVM guest code and a solidity contract as an interface to the Ethereum world. Communication between those two components will happen via the Ethereum Bonsai bridge.

Because Bonsai is in a pre-release state, we expect you to need some help getting going - to support this, we’ll have Bonsai developers available to help via discord (and a few in person, as well).

For application ideas, think about computationally intensive tasks. What have you always wanted to see on Ethereum but development complexity or gas costs/caps have kept you from building?

Prize Amount - 15,000 USDC

We are offering a total of 5 prizes, with a top prize of 7,000 USDC and a minimum prize of 2,000 USDC to qualifying projects.

We reserve the right to withhold prizing in cases where low-quality submissions do not meet our bounty requirements.

Resources​

• Bonsai Bounty Developer Website: https://dev.bonsai.xyz
• Get Started With Bonsai: https://dev.bonsai.xyz/get-started
• Explainers: https://www.risczero.com/docs/explainers
• RISC Zero Source Code: https://github.com/risc0/risc0
• zkVM Workshop: https://www.youtube.com/playlist?list=PLcPzhUaCxlCgig7ofeARMPwQ8vbuD6hC5

💡 Early alpha access to Bonsai is currently controlled via a Whitelist.
Developers looking to join the Bonsai Whitelist may fill out the form HERE

Bounty #2: Reduce the RISC Zero zkVM boilerplate by removing the methods crate​

Allow RISC Zero zkVM code to be written without needing to invoke specialized build code for the guest. In particular, after fulfilling this bounty zkVM users will be able to:

• build guest code in the same crate and workspace as host code
• build guest code without using a custom build.rs script
• freely locate the guest code in whatever part of the source tree is most sensible for their project
• without reducing the functionality or performance of the zkVM.

This means a successful completion of the bounty will be able to take zkVM guest code, compile it into an ELF binary, and supply that binary to for the host to use all while meeting the above requirements.

We believe that this bounty would be most easily accomplished by using the bindeps artifacts dependency functionality of Cargo, described here. Use of bindeps is not a requirement of the bounty, but we do believe it is the most likely path to successfully accomplishing the bounty.

Prize Amount - 5,000 USDC

In the case of multiple bounty submissions meeting our criteria, we will split the prize among successful submissions in proportion to their completeness and code quality, as described above. At our discretion, we may award a partial prize to submissions that make substantial but incomplete progress towards fulfilling the four criteria outlined.

We reserve the right to withhold prizing in cases where low-quality submissions do not meet our bounty requirements.

Resources​

• The Cargo documentation for bindeps: https://doc.rust-lang.org/cargo/reference/unstable.html#artifact-dependencies
• Our zkVM documentation: https://docs.rs/risc0-zkvm/latest/risc0_zkvm/
• Documentation for our current guest build tools: https://docs.rs/risc0-build/latest/risc0_build/

Bounty Support​

Connect directly with our team for any help regarding the bounty and hackathon on our Discord!

https://discord.gg/risczero

Contact Us

Reach out to us this ETHDenver through our Discord LINKED HERE

Get notified when Bonsai is released to the public!

Interested in partnering with us? Let us know HERE

Excited to announce that I have joined RISC Zero as the VP of product growth. We are building a general-purpose zkVM and ushering the wave of ZK compute for all!

If you know me, you know I have done my research! As I explored my next career move, I scanned the entire crypto landscape and had conversations with numerous companies. I am most excited about DeFi's potential to solve real financial challenges, DAOs as revolutionary coordination mechanisms, and decentralized infrastructure (storage, compute, identity, etc.) as essential building blocks for disintermediation.

The 2020-22 period brought significant growth in the crypto industry, attracting widespread attention and new talent. The rising popularity of DAOs, the explosion of DeFI applications, and the NFT boom were all made possible by the previous cycles of infrastructure building. But very quickly, we hit scaling barriers, exposing the gaps in our infrastructure.

Bear markets give us the space to build infra needed for the next wave of adoption. We are again in the infrastructure part of the app-infra cycle for crypto.

Refer this USV piece on the myth of infrastructure.

And today’s infrastructure will bring tomorrow’s killer app.

One thing I knew for sure: I wanted to work on something that truly moves the needle for crypto use cases and adoption. Having worked on decentralized storage infra for the last 3.5 years, I have witnessed first-hand the difficulties developers encounter when building complex real-world applications on-chain.

ZK tech is uniquely positioned to address the challenges facing crypto infrastructure today by enabling verifiable complex computations off-chain. Here’s an explanation from ChatGPT’s 😎

In the past six months, there have been remarkable advancements, resulting in a surge of teams developing ZK scaling solutions. ZK protocols and applications enabled by ZKPs are still in their infancy, and the excitement is only going to be multifold this year. If we can harness the potential of ZK and make it available to developers of all levels, we can open up a whole new realm of previously impossible applications. Jill Gunter predicted ZKP applications becoming the norm. I think we will be seeing it sooner than 2026!

Building ZK circuits, leveraging ZKPs, and building ZK applications is no small feat! Requires millions of dollars of investments, assembling a team of rare crypto and math experts, and learning new custom programming languages with inadequate tooling.

Enter RISC Zero!

RISC Zero is removing these resource and time-intensive barriers by bringing existing languages, tools, and developer skills to ZKP development. Built on the open RISC-V instruction set, RISC Zero’s zkVM will enable developers to generate highly performant ZKPs for a variety of applications with code written in Rust, C++, Solidity, Go, and more.

When choosing my next project, my top priority was the people involved and the potential impact it would make. One of the best things about joining RISC Zero is its team of brilliant individuals with decades of experience across distributed systems, cryptography, security, and cloud computing. The combination of technical expertise and genuine kindness is truly rare!

RISC Zero will play a key role in ushering in the era of verifiable computing. We are bringing trusted computing into trustless environments. And I couldn’t be more excited to work on this alongside Brian Retford, Jeremy Bruestle, Choong Ng, Frank Laub, Ash Schap, and the rest of the team.

If you haven’t guessed already, I am totally ZK pilled. And you will be too! I will be posting accessible ZK content, so join me in this journey @manasilvora.

HMU if you want to chat ZK or are building an L2 rollup, appchain, dapp, or an L1 that wants to leverage ZK tech!

Alright, back to building!

Hello everyone! I'm Bolton Bailey, a Ph.D. student and software engineer at RISC Zero. I'm writing this blog post to discuss a project that I've been working on, in conjunction with Runtime Verification Inc., to run a Metamath checker inside the RISC Zero zkVM. Although this project is just getting started, I think it's headed in a very exciting direction. In this post, I'd like to share with you all what makes it so interesting, how we've gone about it, and what it could look like going forward.

What are Formal Methods?​

My field of research lies at the intersection of cryptography and formal methods. Formal methods are a mathematically rigorous approach to software development that ensures a piece of code does what it is supposed to do. A formal methods approach goes farther than simply examining a piece of code line-by-line or writing a test suite to ensure the code runs correctly on a number of examples. Instead, we write out a mathematically precise specification of what the code is supposed to do and prove that the code will always behave as specified, no matter what input it is given.

Rather than writing down specifications and proofs on paper and checking them by hand, we get the computer itself to help us. Formalists use specialized computer languages known as formal systems to express their proofs, and they write programs to check these proofs so that they can be sure they made no mistakes. The language I've been working with is the Metamath system.

What is Metamath?​

Metamath is a formal system that's designed to be flexible enough to represent proofs in a variety of mathematical frameworks, but also very simple for the computer to understand. The way a computer processes logic can be unintuitive for a human, but this section will hopefully give you an idea of how it works.

Here is an example of some simple Metamath code from the manual. This code describes a simple mathematical system for talking about numbers, with addition and zero as the basic concepts:

$( Declare the constant symbols we will use $)
$c 0 + = -> ( ) term wff |- $.
$( Declare the metavariables we will use $)
$v t r s P Q $.
$( Specify properties of the metavariables $)
tt $f term t $.
tr $f term r $.
ts $f term s $.
wp $f wff P $.
wq $f wff Q $.
$( Define "term" and "wff" $)
tze $a term 0 $.
tpl $a term ( t + r ) $.
weq $a wff t = r $.
wim $a wff ( P -> Q ) $.
$( State the axioms $)
a1 $a |- ( t = r -> ( t = s -> r = s ) ) $.
a2 $a |- ( t + 0 ) = t $.
$( Define the modus ponens inference rule $)
${
  min $e |- P $.
  maj $e |- ( P -> Q ) $.
  mp $a |- Q $.
$}
$( Prove a theorem $)
th1 $p |- t = t $=
$( Here is its proof: $)
tt tze tpl tt weq tt tt weq tt a2 tt tze tpl
tt weq tt tze tpl tt weq tt tt weq wim tt a2
tt tze tpl tt tt a1 mp mp
$.

There is a lot of boilerplate, but the critical part of the definition is the two axioms listed on the lines that start with a1 and a2. Respectively, these axioms state that:

1. If t = r and t = s, then r = s.
2. For any term t, t + 0 = t.

As an example of how detailed these proofs can get, let's unpack the very last theorem at the end of the example above, which proves t = t for any term t. The proof consists of a very low-level list of invocations of rules and axioms that show the theorem holds. At a high level, the proof says that if we substitute t from the first axiom above with t + 0, and r and s are substituted for t, then the first axiom becomes "If t + 0 = t and t + 0 = t, then t = t". By the second axiom listed above, the t + 0 = t conditions hold; therefore, the first axiom is telling us that t = t. Notice that we have to use the first axiom once and the second axiom twice (once for each condition of the first axiom). While not all of the symbols in the proof of th1 might be familiar, we can see it includes one reference to a1 and two references to a2.

This may seem like an overly convoluted way of proving a very simple fact. This is because computers need to have every detail spelled out to them. Metamath in particular is designed to not have a lot of built-in optimizations, in order to keep the Metamath checking program as simple as possible. Unlike a human, the Metamath needs to be reminded of the fact that "t is a number" every time t comes up again in the argument. This is essentially what the tt token does - you can see it comes up 15 times in the proof of th1!

What are the possibilities for formal methods?​

The example theorem above is a simple one. In principle, however, there's no limit on what can be proven within a formal system like Metamath: we can describe logical systems that deal with set theory or even outline the semantics of programming languages. Within formal methods, programs and data are just different types of mathematical objects, ones for which confidence can be of the utmost importance. The software industry in general, and the cryptocurrency industry in particular, has a lot at stake when it comes to bugs in their systems: billions of dollars have been hacked out of blockchains, and entire organizations exist that look to use formal analysis to help plug these holes.

Zero-Knowledge Proofs for Formal Methods​

Having established what formal methods are and why they're useful, let's ask why someone might want to use succinct zero-knowledge proofs in conjunction with them.

Suppose a technology firm wants to be assured that their products have no bugs. They open a bug bounty and offer a prize to anyone who can find a flaw. A formal analysis firm writes a specification of what the code is supposed to do and then attempts to find a proof that the code meets the specification. In their analysis, they end up finding a bug, and they create a formal proof that the specification is not satisfied.

At this point, the formalist firm is nervous that the software writers will look at the proof and say that actually, the bug isn't a problem at all, and this doesn't merit paying out the bug bounty. Besides, the technology firm doesn't want to run this long formal check themselves. It might not even be a technology firm offering the bounty at all, but instead a smart contract.The smart contract is limited in how much gas it can use, so it can't reasonably check the whole formal analysis.

This scenario is ripe for a succinct proof application. The formalists can prove the bug is real without a big data transfer or computation by sending a STARK proof that the formal proof check validated their code in Metamath or another formal system. As a bonus, they can make the STARK a zk-STARK if they are worried about someone seeing the proof, reverse-engineering the bug, and making an exploit.

Making it a Reality with RISC Zero​

How does all this work? In a succinct argument system like a zk-STARK, we have a prover and a verifier. The prover is meant to prove that the outcome of some computation gave some result, and the verifier checks the proof is correct. These two roles are analogous to the formal proof writer and the formal proof checker. In the case of this application, they coincide completely!

The prover first makes a Metamath file to prove their theorem. They then run a Metamath checker for the file as a computation inside the ZK proof system. This gives them a cryptographic output proof that they then pass to the verifier. In order to make this work, we need to be able to encode the Metamath proof checking process inside a zkVM.

This is where RISC Zero enters the picture. If we were doing this project in a zkEVM or using a circuit model, it would be necessary to write a Metamath checker in Solidity, Circom, or some other specialized language. But because RISC Zero has a zkVM for the RISC-V architecture, I can write my Metamath checker in a language like Rust. In fact, I don't even need to know Rust, because a Metamath checker written in Rust already exists, and I can just drop it into the RISC Zero VM and have it work! Even if formal methods aren't of interest to you at all, the implications for making STARK cryptography accessible are profound and exciting.

The Repository​

You can find the GitHub repository for our project here. I exaggerate a little when I say you don't even have to know Rust to make a Rust program run in the RISC zero zkVM, but not by much. The repository is a fork of the much simpler risc0/rust-starter, which has the same basic structure. There are two Rust programs in each: a host that sends data to the zkVM through the add_input() method and a guest that runs inside the zkVM, receives input via the env::read() method, and commits to outputs using the env::commit() method.

When you're designing a zk-STARK, it's good to think about what data is part of the statement and what is part of the witness. The statement is the data that is known to the verifier. In the case of our Metamath verifier, it includes the statement of the theorem that is being proven. It also includes the list of the axioms on which that theorem is based (otherwise, the prover might create their own axiom which says that the theorem is true). The witness is all the data that is known to the prover. In our case, this is simply an entire Metamath file, along with an indication of which of the theorems within that file is the one for which we are requesting the proof.

Our project has been able to run a variety of small Metamath programs, such as the one in the example above. Our primary bottleneck is the execution time within the VM; because producing a STARK proof requires memory proportional to the size of the execution trace, we can only check Metamath files of a few hundred lines before we hit the limit. The RISC Zero team has been working hard though, and I suspect we will soon have engineering solutions to remove this obstruction. From there, the only limit on the space of STARKed formal methods will be our own imaginations!

I am excited to announce that I have taken a new role as the Chief Strategy Officer of RISC Zero.

RISC Zero is focused on bringing the magic of Zero Knowledge Proofs to blockchains to unlock the potential of Web3 through scaling. We have built a ZKVM around the RISC-V instruction set architecture. This means the RISC Zero ZKVM can support any language that can be compiled to RISC-V, including Rust, C++, and (soon) Go. To our knowledge, this means it is the first and only ZKVM in the Web3 space that does not require developers to adopt a custom or unfamiliar language.

For those of you that know me, this may come as a surprise. I have been an Ethereum maximalist for a long time. I started my crypto journey doing business development for MakerDao, and my most recent role was Head of Growth for Uniswap, the largest and most widely used Dapp on Ethereum.

I love Ethereum. I am so proud of what we, as a community, have built. Today it is possible for users around the world to access powerful financial infrastructure in a decentralized, permissionless way. The NFT space empowers creators every day to experiment with new forms of art and new ways of engaging with their fans and collectors. There is so much that is happening on Ethereum that is groundbreaking, cutting edge and truly inspiring to watch.

But Ethereum has not yet scaled. And that has been painful at times. I started my career in crypto so optimistic that we could bring the power of smart contracts to everyone on earth, lowering the barrier to entry to Web3 and providing cheap, reliable, safe financial tools to everyone in the world who may have a need for them. But today, only the wealthy can afford to interact with Ethereum Layer 1. I didn't help build MakerDao and Uniswap so that only whales could use it. So as I took time off after leaving Uniswap last September, I started to look around and really dig into the technical forefront of the scaling question.

Layer 2 solutions like Optimism are paving the way here, and I am very excited to see the application layer maturing as those solutions gain adoption. But as I learned more about how Layer 2 works, I realized that we will never be able to build sophisticated web applications of today's Web2 without a substantial increase in throughput. Existing Layer 2 solutions will allow Web3 to grow faster and allow for the creation of more advanced applications that are far more affordable for users. But there is a cap on that throughput. As the complexity of dapps increase, that throughput will begin to max out. The only way to realistically scale blockchains is to abandon linear state and begin to experiment with parallel execution.

Zero-Knowledge Proofs can take us one step closer to that reality. My team at RISC Zero is working on a lot of clever math that makes me extremely optimistic that we can reliably scale in a parallel way without sacrificing decentralization or security, while also adding optionality for private transactions.

Our first product will be a Devnet built using Tendermint consensus, the goal being to get something into the hands of developers quickly so that we can better understand what challenges they face in building with ZKPs. Longer term, we have a lot of options on how we will deploy our products. My personal hope is that we can create an interoperable blockchain that demonstrates the power of this technology while also deploying as a Layer 2 on top of several other L1s including Ethereum and maybe even Bitcoin. Our plan is to open source everything, so my hope is that this tech will be a resource for any blockchain that needs it.

I have often said that I think I will probably spend the rest of my career trying to make the dream of global borderless money a reality. Right now this feels like the next step in that journey. I am excited to be going deeper in the stack! The magic of ZKPs has totally captured my imagination, and I searched the industry really thoroughly for the team with the right set of technical skills and the right set of ideological objectives to take this tech to the next level. RISC Zero is that team, and I could not be more thrilled to be starting this new chapter.

If you are interested in joining us, check out our careers page here:

• https://jobs.lever.co/risczero.com

If you want to learn more about how Zero Knowledge works, here are some resources:

• https://www.youtube.com/watch?v=fOGdb1CTu5c&t=683s
• https://blog.chain.link/what-is-a-zero-knowledge-proof-zkp/

And for more on RISC Zero, check these out:

• https://github.com/risc0/risc0
• https://www.risczero.com/docs/explainers

We're excited to share a new kind of computing platform with the world – one that can't lie about anything it does. RISC Zero enables any developer to build zero-knowledge proofs that can be executed and verified on any modern computer in the languages they are most familiar with.

RISC Zero is the first fully free-and-open-source general-purpose ZK computing platform. Our prover and verifier are available under the Apache2 license, along with several simple but powerful examples of this technology written in Rust and C++.

General Purpose Verifiable Computing

RISC Zero is a fully-compliant software implementation of the RISC-V microarchitecture (RV32IM). The RISC-V ISA is implemented as a set of polynomial constraints inside a zk-STARK based proving system.

So RISC Zero is what, exactly?​

RISC Zero is zero-knowledge virtual machine that can run on any platform. It's a virtual microcontroller / co-processor that produces receipts for every program it runs, kind of like a secure virtual Adruino. These receipts can be verified at anytime by anyone in milliseconds – even if you don't trust the party that executed the code.

How is it different from other ZK projects?​

Our initial release of RISC Zero is different in a few critical ways:

1. Both the prover and verifier are fully open. This means programs can be proven locally, preserving privacy and information hiding.
2. The verifier has implementations in C++ and Rust. As such is can easily run on many different platforms and on many different blockchains.
3. Because our ZKVM supports a standard ISA and looks like a normal von-Neumann machine, it is both familiar to a broad set of developers and can be programmed using standard languages.

What's Next?

We are working on several exciting projects internally that will be announced, explained, and released over the coming months. Please join our Discord or follow us on Twitter