Skip to main content

​
Default: Merkle Inclusion Proofs

By default, Boundless delivers proofs on-chain as merkle inclusion proofs:
  1. Proofs are batched together are aggregated into a single Groth16 proof.
  2. The aggregated proof is verified once on-chain
  3. Individual proofs are verified through cheap merkle inclusion proofs into this root
This design is what makes Boundless cost-effective for on-chain verification.

​
Requesting a specific proof type

While merkle inclusion proofs are efficient for on-chain verification, there may be cases where you need to access the underlying proof instead of a merkle inclusion proof. For example:
  1. Cross-chain verification where you need to verify the proof on a different chain
  2. Integration with other systems that expect a specific proof type
  3. Custom verification logic that requires the full proof
Boundless supports requesting a raw Groth16 proof instead of a merkle inclusion proof. You can specify this in your proof request by setting the proof_type to ProofType::Groth16: 
# use alloy_primitives::utils::parse_ether;
# use boundless_market::{Client, request_builder::OfferParams};
# use url::Url;
# async fn create_groth16_request(
#     client: Client,
#     program: &'static [u8],
#     input: &[u8]
# ) -> anyhow::Result<()> {
let request = client.new_request()
    .with_program(program)
    .with_stdin(input)
    .with_groth16_proof()  // Request raw Groth16 proof
    .with_offer(
        OfferParams::builder()
            .min_price(parse_ether("0.001")?)
            .max_price(parse_ether("0.002")?)
            .timeout(1000)
            .lock_timeout(1000)
    );
# Ok(())
# }
In addition, Boundless also supports requesting a Blake3 Groth16 proof. This proof type allows for proofs to be verified in environments where SHA2 hashing is impossible or expensive (e.g. BitVM). You can specify this in your proof request by setting the proof_type to ProofType::Blake3Groth16: Note: Blake3 Groth16 proofs require is only supported with the ClaimDigestMatch predicate, meaning that you should only use this if you do not require the journal to be delivered on-chain. 
# use alloy_primitives::utils::parse_ether;
# use boundless_market::{Client, request_builder::OfferParams};
# use url::Url;
# async fn create_blake3_groth16_request(
#     client: Client,
#     program: &'static [u8],
#     input: &[u8]
# ) -> anyhow::Result<()> {
let request = client.new_request()
    .with_program(program)
    .with_stdin(input)
    .with_blake3_groth16_proof()  // Request Blake3 Groth16 proof
    .with_offer(
        OfferParams::builder()
            .min_price(parse_ether("0.001")?)
            .max_price(parse_ether("0.002")?)
            .timeout(1000)
            .lock_timeout(1000)
    );
# Ok(())
# }

​
Considerations

When choosing between proof types, consider:
  1. Gas Costs
    • Merkle inclusion proofs are much cheaper to verify on-chain
    • Raw Groth16 proofs require full SNARK verification each time. This will increase the price of the proof
  2. Use Case Requirements
    • If you only need on-chain verification, use the default merkle inclusion proof
    • If you need cross-chain verification or raw proof data, use Groth16
    • If you need to compose the proof by verifying it within another zkVM guest program, use Groth16
    • If you don’t need the journal to be authenticated, consider using the ClaimDigestMatch predicate

​
Predicate Types

When constructing a Proof Request, we can set a Requirement with some predicate type. The available predicate types are DigestMatch, PrefixMatch, and ClaimDigestMatch. These predicates ensure that the journal of our guest program match what we expect. Specifying the DigestMatch and PrefixMatch predicates will require delivery of the journal when a request is being fulfilled. There are times where we are building an application that does not require the journal to be delivered on-chain. If this is the case, ClaimDigestMatch will save potentially a lot of gas, since Provers will not need to submit potentially large journals on-chain.

​
Example: Proof Composition using Proof Types

In the Proof Composition example, we demonstrate how to compose a proof from multiple proofs. Composing a proof requires us to verify a previously generated Groth16 proof within the zkVM guest program. This requires us to request a raw Groth16 proof from the Boundless Market. In the composition example, we first request a raw Groth16 proof from the Boundless Market using the ECHO guest program. 
# use alloy_primitives::utils::parse_ether;
# use boundless_market::{Client, request_builder::OfferParams};
# use url::Url;
# async fn create_groth16_request(
#     client: Client,
#     program: &'static [u8],
#     input: &[u8]
# ) -> anyhow::Result<()> {
let request = client.new_request()
    .with_program(program)
    .with_stdin(input)
    .with_groth16_proof()  // Request raw Groth16 proof
    .with_offer(
        OfferParams::builder()
            .min_price(parse_ether("0.001")?)
            .max_price(parse_ether("0.002")?)
            .timeout(1000)
            .lock_timeout(1000)
    );
# Ok(())
# }
We then provide the Groth16 proof as input to the IDENTITY zkVM guest program, and verify the proof. 
use risc0_zkvm::guest::env;
use risc0_zkvm::{Digest, Receipt};

fn main() {
    let (image_id, receipt): (Digest, Receipt) = env::read();
    let claim = receipt.claim().unwrap();
    receipt.verify(image_id).unwrap();
    ....
}