Giter Club home page Giter Club logo

risc0-foundry-template's Introduction

Crates.io MIT licensed Build Status Discord chat Twitter

WARNING: This software is still experimental, we do not recommend it for production use (see Security section).

RISC Zero is a zero-knowledge verifiable general computing platform based on zk-STARKs and the RISC-V microarchitecture.

A zero knowledge proof allows one party (the prover) to convince another party (the verifier) that something is true without revealing all the details. In the case of RISC Zero, the prover can show they correctly executed some code (known to both parties), while only revealing to the verifier the output of the code, not any of its inputs or any state during execution.

The code runs in a special virtual machine, called a zkVM. The RISC Zero zkVM emulates a small RISC-V computer, allowing it to run arbitrary code in any language, so long as a compiler toolchain exists that targets RISC-V. Currently, SDK support exists for Rust, C, and C++.

Protocol overview and terminology

First, the code to be proven must be compiled from its implementation language into a method. A method is represented by a RISC-V ELF file with a special entry point that runs the code of the method. Additionally, one can compute for a given method its image ID which is a special type of cryptographic hash of the ELF file, and is required for verification.

Next, the host program runs and proves the method inside the zkVM. The logical RISC-V machine running inside the zkVM is called the guest and the prover running the zkVM is called the host. The guest and the host can communicate with each other during the execution of the method, but the host cannot modify the execution of the guest in any way, or the proof being generated will be invalid. During execution, the guest code can write to a special append-only log called the journal that represents the official output of the computation.

Presuming the method terminated correctly, a receipt is produced, which provides the proof of correct execution. This receipt consists of 2 parts: the journal written during execution and a blob of opaque cryptographic data called the seal.

The verifier can then verify the receipt and examine the log. If any tampering was done to the journal or the seal, the receipt will fail to verify. Additionally, it is cryptographically infeasible to generate a valid receipt unless the output of the journal is the exactly correct output for some valid execution of the method whose image ID matches the receipt. In summary, the receipt acts as a zero knowledge proof of correct execution.

Because the protocol is zero knowledge, the verifier cannot infer anything about the details of the execution or any data passed between the host and the guest (aside from what is implied by the data written to the journal and the correct execution of the code).

Security

This code is based on the well studied zk-STARK protocol, which has been proven secure under the random oracle model, with the only assumption being the security of the cryptographic hash used. Our implementation uses SHA-256 for that hash and targets 100 bits of security.

That said, this code is still under heavy development and has not been audited. There may be bugs in the zk-STARK implementation, the arithmetic circuit used to instantiate the RISC-V zkVM, or any other element of the code's implementation. Such bugs may impact the security of receipts, leak information, or cause any other manner of problems. Caveat emptor.

Getting Started

To start your own project, you can use our cargo risczero tool to write the initial boilerplate and set up a standard directory structure.

First, install Rust if you don't already have it, then install the cargo risczero tool. We'll use cargo binstall to get cargo-risczero installed. See cargo-binstall for more details.

cargo install cargo-binstall
cargo binstall cargo-risczero

Next we'll need to install the risc0 toolchain with:

cargo risczero install

Then, create a new project (named my_project in this example):

cargo risczero new my_project

More details and options for cargo risczero are given in its README.

For more guidance on how to use RISC Zero, how RISC Zero projects are typically structured, and other resources useful to developers new to RISC Zero, see our Getting Started page.

Building from source

Building from source requires some additional tools and steps. Please refer to CONTRIBUTING.md for the full instructions.

Rust Binaries

crate crates.io
cargo-risczero x
risc0-r0vm x
risc0-tools x

Rust Libraries

crate crates.io docs.rs
bonsai-sdk x
risc0-binfmt x
risc0-build x
risc0-build-kernel x
risc0-circuit-recursion x
risc0-circuit-recursion-sys x
risc0-circuit-rv32im x
risc0-circuit-rv32im-sys x
risc0-core x
risc0-sys x
risc0-zkp x
risc0-zkvm x
risc0-zkvm-platform x

Feature flags

The following feature flags are present in one or more of the crates listed above:

Feature Target(s) Implies Description Crates
client all except rv32im std Enables the client API. risc0-zkvm
cuda prove, std Enables CUDA GPU acceleration for the prover. Requires CUDA toolkit to be installed. risc0-circuit-recursion, risc0-circuit-rv32im, risc0-zkp, risc0-zkvm
disable-dev-mode all except rv32im Disables dev mode so that proving and verifying may not be faked. Used to prevent a misplaced RISC0_DEV_MODE from breaking security in production systems. risc0-zkvm
metal macos prove, std Enables Metal GPU acceleration for the prover. risc0-circuit-recursion, risc0-circuit-rv32im, risc0-zkp, risc0-zkvm
prove all except rv32im std Enables the prover, incompatible within the zkvm guest. risc0-circuit-recursion, risc0-circuit-rv32im, risc0-zkp, risc0-zkvm
std all Support for the Rust stdlib. risc0-circuit-recursion, risc0-circuit-rv32im, risc0-zkp, risc0-zkvm

License

This project is licensed under the Apache2 license. See LICENSE.

risc0-foundry-template's People

Contributors

0xalizk avatar 3lkn avatar amosel avatar capossele avatar carterbrett avatar flaub avatar hashcashier avatar jjtny1 avatar justinfrevert avatar mothran avatar nategraf avatar pdg744 avatar tzerrell avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

risc0-foundry-template's Issues

Deployment testing: `HTTP error from reqwest`

Following the deployment guide I can get to:

cargo run --bin publisher --     --chain-id=31337     --rpc-url="http://127.0.0.1:8545"     --contract=${EVEN_NUMBER_ADDRESS:?}     --input=12345678

...

Error: HTTP error from reqwest

Caused by:
    0: builder error: relative URL without a base
    1: relative URL without a base

Although the error isn't helpful... I did end up tracing to find the culprit:

client.upload_img(&image_id_hex, elf.to_vec())?;

Seems like there is a problem in https://github.com/risc0/risc0/blob/a6b884aa41dec6ae345013b7292e868d6e7685da/bonsai/sdk/src/alpha.rs#L421-L430 ?

Note: I have not set BONSAI evn vars, but don't think that would lead to this error ๐Ÿคž

Refactor prover to use the risc0-zkvm API

Currently the Foundry template includes code to call Bonsai with the Bonsai SDK. Proving with Bonsai is also provided under the unified API with risc0-zkvm, and this API is a much better user experience. We should refactor the template to use the risc0-zkvm API and drop the BonsaiProver type. This may require changes to the risc0 monorepo.

Note that using the risc0-zkvm API does not immediately mean support for local proving. The blocker for local proving as an easily supported mode is the fact that the only prover option that works today is rapidsnark, and rapidsnark does not integrate nicely with our Rust workflows. As a result, we cannot yet provide a seemless local proving experience for Groth16, as some of the steps are manual and require Docker on x86 to run.

The section about publish-mode is confusing

I felt quite confused reading this section. It felt like there was a disconnect between the heading and the text of the section; not clear immediately what "publish" means or how the words in the section connect to the phrase "publish mode."

image

Some concrete suggestions:

  • Introduce/define the term publish. As of this writing, the term only appears in a section heading and a code snippet.
  • Consider dropping the term publish-mode; the current name implies publish only, while the text of this section reflects call Bonsai from off-chain and then publish.
  • Consider moving this section (and the previous section?) out of the ## Testing your Program section
  • Revise to reflect user oriented framework of ## call bonsai from on-chain and ## call bonsai from off-chain

Refactor CLI and SDK in general

  • Make CLI an example - remove it from the sdk
  • Get rid of Query
  • Make the API more consistent with risc0 (both data structures and functions)

[Naming] Bonsai Foundry Template vs. RISC Zero Foundry Template

The new version of Bonsai on Eth refers to the foundry template as the "RISC Zero Foundry Template."

I'd like to be consistent in what we call things; are we changing the name of the Bonsai Foundry Template to the RISC Zero Foundry Template? This sounds like a good choice to me, but right now it feels like we're floating in between two names.

Dockerfile optimization

In the Dockerfile line 8 we have:

COPY rust-toolchain.toml .

And then on line 12:

COPY . . 

which copies the same file again. It would more efficient to simply make the COPY . . first and not do the COPY rust-toolchain.toml.

Low level contract vs. other contract

It's not clear why there are two contracts in the contracts folder.
My understanding is that one of these is enabled by default, and the other is included as an alternative option.

Some suggestions:
[ ] Document which one is enabled by default
[ ] Document how to switch to the alternative option
[ ] Document the differences between the contracts, and what would motivate a user to choose one option or the other
[ ] Consider altering the setup process so that the first user experience only contains one contract in their template. Perhaps by adding an option to the terminal command that lets users choose between initializing their project with low_level or with regular

Error when updating `risc0-zkvm` to `0.21.0`

The issue arose from the fact that Bonsai currently only supports one version.
Running a previous version of the foundry template results in:

Error: server error zkVM version mismatch: Bonsai supports only the risc0-zkvm '0.21.0' version

To solve this, it was taken the approach of updating the risc0-zkvm dependency to 0.21.0. Compiling a project works, but then after running the publisher we get:

Error: HTTP error from reqwest

Caused by:
    0: error decoding response body: missing field public at line 1 column 993
    1: missing field public at line 1 column 993

Then updating other related dependencies was also tried, namely bumping these dependencies to the versions below:

bonsai-sdk = { version = "0.7" }
risc0-build = { version = "0.21", default-features = false, features = ["docker"]}
risc0-build-ethereum = { git = "https://github.com/risc0/risc0-ethereum", branch = "release-0.8" }
risc0-ethereum-contracts = { git = "https://github.com/risc0/risc0-ethereum", branch = "release-0.8" }
risc0-zkvm = { version = "0.21", default-features = false }
risc0-zkp = { version = "0.21", default-features = false }

But then, running the publisher results in:

Error: (code: 3, message: execution reverted, data: Some(String("0x")))

It seems to be a decoding problem when submitting the data to the verifier contract, but further investigation is needed.

Update Foundry template readme

There may be other updates but at a minimum we should:

  • call out that you get SNARK w/ Bonsai proving mode
  • nit: can we make the videos URL's instead of embedding them? (too much noise)
  • describe that there are now two separate flows: pub-sub mode where you invoke from chain, and the pub-only mode where you can publish a proof via API.
  • remove references to Eth Waterloo

Can't complete the quick start

When running the quick start command:

forge init -t risc0/bonsai-foundry-template ./my-project

it ends with an error, see the logs below:

โœ” Checking your system
โœ” Initializing Project Directory
โœ” Initializing Git Repository
โœ” Copying Starter Files
โœ” Initializing NPM Module
โœ” Installing NPM Dependencies
โœ– Locating custom template: "risc0/bonsai-foundry-template"

Electron forge was terminated:
Failed to locate custom template: "risc0/bonsai-foundry-template"

Try `npm install -g electron-forge-template-risc0/bonsai-foundry-template`

The npm install suggested in the code doesn't work either:

$ npm install -g electron-forge-template-risc0/bonsai-foundry-template

npm ERR! code 128
npm ERR! An unknown git error occurred
npm ERR! command git --no-replace-objects ls-remote ssh://[email protected]/electron-forge-template-risc0/bonsai-foundry-template.git
npm ERR! ERROR: Repository not found.
npm ERR! fatal: Could not read from remote repository.
npm ERR!
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.

npm ERR! A complete log of this run can be found in: /Users/simone/.npm/_logs/2024-03-26T14_45_54_864Z-debug-0.log

Unsupported protocol

The process is simple :

  • run the setup command :
    forge init -t risc0/bonsai-foundry-template ./your project

  • cargo build

Then this message appears :
error: failed to download from https://crates.io/api/v1/crates/validator_derive/0.16.0/download
Caused by:
[1] Unsupported protocol (Received HTTP/0.9 when not allowed)

Reproducible builds sometimes get bypassed

In the Governance example of the risc0 repo, specifically on this branch: cardosaum/refactor-governance-example-new-foundry-template, the same instructions that work within the foundry template (e.g., RISC0_USE_DOCKER=1 cargo build) do not work, resulting in the build being built bypassing Docker.

Drop `methods` terminology?

Do we need/want to be using the term methods in this repo?
We might re-name the methods folder to zkvm-program, for example.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.