202510230955 - brevis
Main Topic
Q: What is Brevis, and what problem does it solve for onchain applications?
Brevis is a zk-coprocessor / proof system that helps Ethereum (and other EVM) applications consume verifiable results computed from offchain data and/or historical onchain state without requiring the target chain to re-execute the full computation.
The high-level idea:
- Developers define a computation over some data (for example: “compute a user’s historical volume over the last N blocks,” “prove a particular event sequence happened,” or “aggregate actions across multiple contracts”).
- The computation runs offchain.
- A zero-knowledge proof is generated attesting that the computation was performed correctly over the committed inputs.
- A verifier contract onchain checks the proof and exposes the result to smart contracts.
This pattern is useful when the desired computation is too expensive to do onchain (gas) or requires data that is awkward to access directly in a contract. It is also a way to create “verifiable read models” for contracts: derive higher-level facts from raw history, then prove them.
Brevis appears to provide multiple product surfaces (documentation sets like Coprocessor, Incentra, Pico) and developer tooling (quickstarts) to integrate proof generation and verification.
🌲 Branching Questions
Q: What kinds of use cases are a good fit for a zk-coprocessor?
Good fits:
- Historical aggregation: balances, activity counts, rolling windows, volume, reputation-like signals derived from history.
- Event-driven proofs: prove that a sequence of logs occurred, or that some condition held across many blocks.
- Cross-domain computations: combine data sources (multiple contracts, potentially multiple chains) and prove the aggregate.
Bad fits:
- Simple checks that are already cheap onchain.
- Fully trustless data availability needs. A coprocessor proves computation over inputs, but you must still define how the inputs are selected and committed.
The key question is: can the computation be expressed deterministically with well-defined inputs, and is the onchain verifier cost acceptable relative to doing it directly?
Q: How does this compare to or complement other approaches (oracles, ZK rollups, storage proofs)?
- Oracles: good for bringing new external facts onchain, but usually rely on trust assumptions (committee, staking, reputation). zk-coprocessors aim to minimize trust by proving computation correctness, but input selection still matters.
- ZK rollups: scale transaction execution for an entire chain. A zk-coprocessor is more like a service for proving specific computations that L1 contracts can consume.
- Storage proofs / state proofs: prove a particular piece of state at a given block. A coprocessor can build on those primitives to prove derived computations across many blocks or objects.
In practice, teams often combine these: use an oracle or indexer to select the dataset, and a ZK proof to ensure the computation over that dataset is correct.
Q: What should I evaluate before adopting Brevis in a production protocol?
Checklist:
- Security model: who runs provers, what are the failure modes, how upgrades are managed.
- Cost model: proof generation time and cost, verifier gas cost, expected throughput.
- Latency: how quickly proofs can be produced after new blocks.
- Developer ergonomics: how computations are specified, how debugging works, how to run locally.
- Data selection: how you define and commit inputs to avoid “cherry-picked” proofs.
If any of these are unclear from docs, treat that as a risk and write down what you would need (threat model, audits, uptime guarantees, decentralization roadmap).