Skip to main content

· 7 min read
Victor Graf

Where’s Waldo is a favorite analogy for zero-knowledge proofs. In particular, if you want to prove you know where Waldo is, without revealing his location, you can:

  1. Have your friend, the verifier, print a Where’s Waldo puzzle on a big poster board.
  2. Take the poster board, turn around and cut out Waldo from the image. Dispose of the rest.
  3. Hand the cut out of Waldo to your friend, who makes sure it’s really Waldo.

This is kind of like a zero-knowledge proof (with less cryptography and more craft supplies), but why not implement a real zero-knowledge proof to show you know where Waldo is?

This example implements a RISC Zero program which allows a prover to convince a verifier they know Waldo’s location in a public Where’s Waldo puzzle, without revealing Waldo’s coordinates.

To get a better understanding, browse the source code and run the example yourself.

Overview

This example of implementing a proof for Where’s Waldo is designed to help you understand some useful techniques in creating more advanced programs with RISC Zero.

In particular, it should help you understand:

  • Merkleizing large data to give the guest verifiable access to small parts of it.
  • Using external libraries in the guest to avoid reinventing the wheel.

This tutorial will not include:

Implementing Where’s Waldo

The approach for this example is similar to the analogy. It takes the full Where's Waldo puzzle image and “cuts out” just Waldo.

This cutting out operation takes place in the zkVM guest which keeps the inputs, and in particular Waldo’s coordinates, private while allowing the verifier to confirm that computation was done correctly. In this case, the guest’s journal includes a commitment to the Where’s Waldo puzzle image and the cut out image of Waldo.

Once the verifier has checked the receipt and the source image commitment in the journal, and given the cut out image a look to verify it really is Waldo, they can be sure that Prover knows where Waldo is in the puzzle.

Key to this procedure is that the verifier checks that the Prover did not cut Waldo out of some other source image than the verifier was expecting (e.g. that they didn't go and cut Waldo out of a different puzzle because they don’t actually know where Waldo is in the puzzle the verifier gave them). This is a common problem when implementing verifiable programs, and this is what the source image commitment handles in this example.

Now let’s talk about one strategy to tackle this problem, especially for large data such as images, Merkleization.

Merkleization

In the simplest approach, the guest program could create a commitment simply by hashing the whole Where’s Waldo image in memory and use the hash as a commitment. Unfortunately, hashing the whole image, which we expect to be rather large, is cost prohibitive in the guest. So how can the guest access the data it needs without giving the host an opportunity to give it inconsistent data (e.g. swapping out the Where’s Waldo puzzle)?

Because we only need access to a relatively small portion of the image to produce the cutout, a viable approach is to split the image into a vector of small image chunks and use a Merkle tree to commit to this vector. As needed, the zkVM guest can then ask the host chunks of the image, and along with each chunk the host can provide a Merkle path that proves the chunk is part of the committed image. This gives the guest access to the data it needs, while ensuring it is all part of the committed image.

Merkle trees are an example of a vector commitment. Given a Merkle root, which is simply a SHA-256 digest, the guest has a commitment from the prover binding it to the full data vector. In particular, the guest can then send a request to the host for a specific element in the full vector, and the host will respond with the data and a Merkle path. With this Merkle path, which is a short chain of hashes leading back to the root, the guest can verify the data came from the committed vector. This is great because it means the host can commit to very large data vectors, on the order of gigabytes or even terabytes, and the guest can access small portions of it on demand without reading the whole thing. This trick, of having the prover commit to a large amount of data then the verifier reading a small portion, is actually at the core of the RISC Zero zero-knowledge proof.

In the Where's Waldo example, the data we want to Merkleize is the source Where's Waldo puzzle image. In order to turn it into a vector, we cut the image up into chunks and the give each an one-dimensional index. E.g. an image split into four chunks could be numbered 0 as the top-left quadrant, 1 as the top-right, 2 as the bottom-left, and 3 as the bottom-right. This vector of chunks is then hashed into a Merkle tree and the guest is given the root.

When the verifier wants to check the receipt, they first repeat the same Merkleization procedure as the prover, starting from the source image. If they started with the same image, they will get the same root. They can then compare this root with the commitment in the journal. If it is equal, the can be assured that the prover ran the guest with the same image as the verifier expected.

In the waldo_core::merkle module is implemented a wrapper on the merkle_light crate with support for using the SHA-256 guest circuit, and providing a VectorOracle abstraction. In the waldo_core::image module is implemented a specific MerkleTree type for images, and an ImageOracle type which can be used in the guest for image operations. These modules implement the ideas described above.

Similar Merkle tree abstractions can be used to, for example, ensure a secret word is part of a dictionary, a payment destination is not in a list of banned addresses, or that a user is in the set of authorized users.

Image Manipulation

In order to manipulate the image and cut-out Waldo, and in particular to crop and apply a mask, this example utilizes the popular image crate. This is enabled by implementing image::GenericImageView on ImageOracle. With that trait, many of the image operations provided in the image crate, and by others, can be used on ImageOracle inside the guest. A similar approach could be used to produce a provable blur, image down-scaling, and more.

One the most powerful aspects of RISC Zero is the ability to use your favorite libraries, and avoid reinventing the wheel.

Get Involved

Just as the current ecosystem of amazing open-source applications is powered on amazing open-source libraries, so will be the zkVM programs you write. And if you ever try to import a library and it doesn't work for some reason, it would be greatly appreciated if you let us know by filing an issue on GitHub.

Run this example

You can find the source code and build instructions for this example (and many others) in the risc0/examples folder on GitHub. Run it yourself, and use it as a starting point to to create your own projects!

Note: This example is memory-intensive; we recommend using a machine with at least 64GB of RAM. If you run into issues, file a GitHub issue or ask for help on Discord.

· 10 min read
Steven Li

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)

RISC Zero Booth Location

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

💡 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

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

· 4 min read
Manasi Vora

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!

· 10 min read
Bolton Bailey

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!

· 4 min read
Ash Schap

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:

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

And for more on RISC Zero, check these out:

· 2 min read

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