In the world of Blockchain, we often face a paradox: All data is public, yet Smart Contracts are “blind” to their own history. While Smart Contracts excel at managing the current state, they are notoriously inefficient at accessing past data.
This is where Brevis steps in. Often described as the “key” to unlocking the blockchain black box, Brevis promises to bring Infinite ZK Compute capabilities to decentralized applications.
What is Brevis?
Brevis is a Smart ZK Coprocessor. It empowers Smart Contracts to read complete historical data across blockchains and perform custom computations in a completely decentralized (trust free) manner.
Unlike Layer 2 solutions that focus on scaling throughput or transaction speed, Brevis focuses on scaling data computation.
Current Smart Contracts face a significant limitation: they can only efficiently access current state. Retrieving historical data (e.g., transactions from 3 years ago) directly on chain is either impossible due to technical constraints or prohibitively expensive due to gas costs.
Learn more: Crypto Exchange – The Cornerstone of Crypto Market
Brevis resolves this bottleneck by:
- Historical Data Access: Allowing Smart Contracts to read data from any past block (transactions, events, states).
- Low Cost Computation: Offloading heavy computational tasks (such as aggregating trade volume or analyzing wallet behavior) away from the blockchain (off chain).
- Trust free Verification: Using ZK Proofs to mathematically prove the accuracy of calculation results, eliminating the need to trust third parties like Centralized Indexers or Oracles.
The strongest advantage of Brevis compared to older ZK solutions is its flexibility. It is not just a static ZK circuit. Developers can customize computational logic according to their dApp’s specific needs via SDK tools (notably the Pico Framework). This transforms Brevis into an open platform for all types of data applications.
What is Brevis? – Source Brevis
Brevis Architecture
To realize the vision of “infinite compute” while maintaining Ethereum level security, Brevis relies on an Asynchronous Architecture. This architecture completely decouples the computationally expensive execution from the low cost verification.
Below is an anatomical breakdown of the Brevis system and the lifecycle of a data request.
The Three Pillars of the Brevis System
The Brevis architecture is composed of three main layers:
- Interface Layer (SDK/API): Where developers define computational logic (Circuits) via code (such as Rust with Brevis Pico). This acts as the gateway between the dApp and the Brevis network.
- Prover Network (Off chain): The “Data Processing Factory.” This is a network of nodes responsible for retrieving historical data from source blockchains and generating ZK proofs.
- Verification Layer (On chain): Brevis Smart Contracts deployed on destination blockchains (Ethereum, BNB Chain, Base, etc.). The sole duty of this layer is to validate the authenticity of the ZK proofs.
Data Flow
To understand how the architecture operates, let’s follow the journey of a request from initiation to completion:
Step 1: Query Request – A user (or a dApp’s Smart Contract) sends a computation request.