Today we are talking about 👇
Brevis
Summary
What is Brevis building?
Market Overview & Limitations
Brevis Architecture
Advantages of Brevis
Example of Brevis in action
Use cases
Core components of Brevis
zkFabric
zkQueryNet
zkAggregatorRollup
Team
How to get involved & references
What is Brevis building?
Brevis is building a Zero-Knowledge (ZK) driven omnichain data attestation platform that enables dApps to access, compute, and utilize arbitrary data across multiple blockchains in a completely trust-free way
Market Overview & Limitations
Web2 applications tend to keep user data separate, making it hard for users to switch to other platforms (interoperable). This leads to challenges such as
limited data interoperability
fragmented identities
financial and social data lock-ins
hindered innovation
vendor lock-in
privacy issues
fragmented user experiences
Decentralized applications (dApps) built on Web3 have the potential to break down information silos by utilizing the publicly accessible and append-only data storage of blockchains.
As the adoption of dApps grows, they generate vast amounts of raw data on asset transfers, contract function calls, and blockchain state roots.
This data can be used to extract valuable information on user activity profiles, ownership of assets, market trends, financial connections, and more.
In addition, off-chain products and projects use publicly accessible blockchain data storage to provide data indexing and analytics. This enables them to record, compute, and index blockchain data via the nodes' RPC endpoints, providing stateful data like user transaction history for dApps' frontend UIs. Examples include Dune Analytics and Graph.
Web3 dApps simply have no way to access the vast majority of the data stored in blockchains in a trust-free way.
Smart contracts on a single blockchain have limited data access capabilities.
They can only access data through explicitly defined interfaces of other contracts on the same blockchain.
They cannot access data from other blockchains.
Smart contracts can only view the most current state of the blockchain, not it’s complete historical data.
Also, smart-contract-based solutions for parsing and computing data query semantics are infeasible due to high on-chain computation costs.Off-chain Oracle solutions require external reliance for data validity.
So, it becomes crucial to have a solution, which can help driven the interoperable data access between multiple blockchains.
This is where Brevis coms in!
Brevis Architecture
So, there are primarily 3 core components which make up the Brevis infrastructure. They are:
zkFabric
zkQueryNet
zkAggregatorRollup
Let’s get an overview of each in simple words 👇
→ zkFabric
Collects block headers from all connected blockchains
Generates Consensus Proofs to attest to the validity of these block headers via ZK light client circuits
Allows dApps to access block headers and all states from all supported blockchains in a trust-free way
→ zkQueryNet
An open marketplace of ZK Query Engines
Can accept data queries from on-chain smart contracts directly
Generates query results and corresponding ZK Query Proofs via ZK Query Engine circuits
Offers highly specialized and highly generalized query engines to cater to diverse application requirements
→ zkAggregatorRollup
A specialized ZK rollup that acts as the aggregation and storage layer for zkFabric and zkQueryNet
Verifies proofs from both components
Stores attested data
Commits zk-attested state roots to all connected blockchains
Allows dApps to access attested query results directly in their on-chain smart contracts' business logic
If you’re interested in a much more deeper & tech heavy breakdown as well, please keep reading, I hope you are :)
Advantages of Brevis
Trust-free
Brevis relies solely on ZK succinct proofs to attest data and computation integrity, without relying on any off-chain party.
Thus, applications using Brevis don't need to trust any other party apart from the underlying blockchains and cryptographic protocols.
Omnichain
Brevis can integrate with multiple blockchains using different consensus mechanisms, enabling omnichain data access and computation.
Modularized
Brevis has a highly modular design in its zkQueryNet, allowing it to cater to various application requirements through different implementations of ZK Query Engines.
Low-cost
Brevis's zkAggregatorRollup functions as a batching and aggregation layer for block headers and query results.
This significantly reduces on-chain costs by removing N-to-N communication overhead and enabling cross-chain and cross-application query result sharing.
Example of Brevis in action
Multi-blockchain DEXes need to adjust farming rewards for incentivized pools based on trading pair quality scores.
Currently, adjustments are made through governance proposals, which can be time-consuming and only done when the setting deviates severely from optimal.
This can lead to a decline in user engagement, revenue loss, and sub-optimal reward configurations.
Brevis can help DEXes adjust liquidity farming schedules trust-freely based on omnichain market trends.
Here’s a flow of how the request flows through the Brevis network to serve the request
Use cases
Brevis already has a great number of practical use-cases, here are some of them:
ZK Multi-blockchain Interoperability
Most interoperability solutions require trust in an intermediary entity.
On-chain light client solutions are expensive, but Brevis combines light client protocol and ZKP to generate ZK Proof of Consensus for all connected blockchains and store block headers in zkAggregatorRollup
This provides trust-minimized interoperability for multi-chain dApps without altering their smart contracts.
Data-driven DeFi
The use of ZQEs enables the creation of novel exercise conditions for derivatives like options, using historical and omnichain trading flows like: Time Weighted Price or Time-Volume Weighted Price
It also allows for the creation of alternative derivatives that track user behavior, price trends, protocol or blockchain TVL changes, volatility, price correlations, and more.
On-chain active fund management solutions can use Brevis to demonstrate algorithmic-based position adjustments with privacy-preserving ZK proofs.
This also allows for maintaining a competitive advantage by keeping the precise model parameters concealed.
User Acquisition with Trust-free Revenue Sharing (one of my favorite ones)
Currently in Web2, advertisers pay upfront prices for user acquisition without being able to differentiate based on their Lifetime Value, leading to a suboptimal arrangement.
This is because post-acquisition user data falls within the advertiser's private domain, making it impossible for advertising channels to access post-acquisition user statistics in a trust-free way.
Web3 can transform the user acquisition model by providing access to user activity data in the public domain.
Brevis enables advertising channels to generate revenue proofs for all users they acquire, which will incentivize them to match users with advertisers optimally.
zkDID
Prevent Sybil Attacks
Sybil Attacks have been a persistent issue for the blockchain community since creating an account on the blockchain has a negligible cost.
Off-chain solutions to combat Sybil Attacks can pose regulatory and trust issues by creating a centralized token distribution entity.
Brevis enables applications to generate ZK proofs of individual or aggregated users' identities based on on-chain behaviors, helping prevent Sybil Attacks in a fully trust-free manner.
User Life Cycle Management
Internal data accounting and analysis logic can help build a trust-free user life cycle management process within a dApp.
Brevis can help generate zkDID proofs for specific user behaviors, which can be used for loyalty programs or LiveOps campaigns.
Solutions built with Brevis offer low-cost, future-proof, and portable advantages compared to incorporating in-app accounting.
Tracking statistics with in-app accounting means that data are isolated, but zkDIDs generated via Brevis are publicly stored and can be reused across different applications.
Account Abstraction
Current social recovery designs rely on a static set of predefined multi-signatures.
Brevis enables a smart wallet to implement social recovery capability based on recent social and financial transaction connections.
This approach will significantly reduce maintenance overhead and lower the barrier of entry for new users in the blockchain ecosystem.
Okay we till now we’ve discussed an overview about:
What is lacking in the current solutions?
What is Brevis building?
An overview of the architecture & it’s core components
Advantages
Example of Brevis in action
Use cases
Let’s now get into the final segment, where we will try to understand more about how does Brevis do it? The tech side of things!
Core components of Brevis
As we discussed above, the three core components of Brevis are:
zkFabric
zkQueryNet
zkAggregatorRollup
Let’s understand about each of them!
zkFabric
Brevis uses zkFabric as a trust-free interoperability layer that allows any blockchain to access attested states of every other blockchain.
zkFabric's light clients use zero-knowledge proofs, making it fully trust-free and secure, solely relying on the underlying blockchains and mathematically sound proofs, without needing external validation entities.
What are the currently existing interoperability solutions?
External Validation Bridge
External validation bridges enable interoperability among blockchains by using an external entity to validate and relay messages.
Various designs, such as multi-signature validation, multi-party computation threshold signature, relay and oracle co-validation, and PoS-based middle chains, can be used for external validation bridges.
The security of cross-chain communications in external validation bridges depends solely on the external entity's designs, making it decentralized but not trust-free.
Optimistic-like Bridge
Optimistic-like Bridge is a type of design that incorporates a two-phase commit with a delay and sourcechain slashing functionality.
It requires an external validation layer to deposit collateral and a watchdog service to monitor the bridge state and penalize malicious actors by slashing their collateral.
Although it introduces a delay, its security still depends on the deposited collateral and is different from Rollup bridges.
Light-Client Bridge
Light-Client Bridge eliminates the need for a trusted third party and is trust-free by implementing the entire light client logic in a smart contract on the destination chain for the source chain.
However, directly implementing generalized light clients as a smart contract is prohibitively expensive, and light-client bridges such as NEAR-Ethereum Rainbow bridge use an optimistic model that relies on a watchdog to monitor and results in a long delay and weakened security model.
zkFabric implements light-client protocols in polynomial arithmetic circuits, allowing it to generate ZK Consensus Proofs that prove block headers are generated through the corresponding chains' consensus protocols.
These Consensus Proofs can be efficiently and recursively verified through zkAggregatorRollup on all connected blockchains, achieving trust-free interoperability.
The architecture of zkFabric which consists of two components:
Block Header Relay Network: This network synchronizes block headers from various blockchains, forwarding them to the zkFabric prover network to generate validity proofs.
zkFabric Prover Network implements circuits for each blockchain’s lightclient protocol, this network generates validity proofs for block headers.
Here’s a flowchart of how the interactions take place
zkQueryNet
zkQueryNet is a network of Zero-Knowledge Query Engines (ZQEs) that can be integrated into smart contracts.
It provides a standardized API and design pattern for developers to build decentralized applications that rely on data from multiple blockchains.
For ZQE providers, it offers a unified Keeper service and interfaces for Provers and Query Services to be integrated into Brevis.
Let’s understand the components of zkQueryNet:
→ Agent Smart Contract and Application Design Pattern
Brevis zkQueryNet is a network of Zero-Knowledge Query Engines that can be integrated into smart contracts for decentralized applications.
The Agent Smart Contract serves as an interface between application smart contracts and other components of the zkQueryNet system.
The query function is the entry point for smart contracts to utilize data query and computation capabilities, with a deadline specified for optimal scheduling and prevention of stale data.
Query results are returned asynchronously using a unique query ID and metadata recorded in the application smart contract.
Keeper fetches the zk-verified query result and its proof from zkAggregatorRollup and attests to its inclusion in the committed rollup Verkle tree.
→ ZK Query Engine Network
The ZK Query Engine Network is the core of the zkQueryNet system, transforming queries into zk-attested results.
The network is designed as an open marketplace, allowing for easy integration of any ZK Query Engine.
A ZK Query Engine consists of Query Service and Query Prover, with Query Service defining Query APIs and generating query results.
→ Keeper Network
The Keeper Network is a trust-free component in zkQueryNet that connects ZQEs to the rest of the system.
It is utilized to relay query events emitted from the Agent Smart Contract to the Query Service and Query Prover.
The Keeper retrieves the query results and their inclusion proof from the rollup and delivers them back to the application through the Agent Smart Contract.
The Keeper and other off-chain components in zkQueryNet do not introduce any trust assumptions into Brevis, and queries made by dApps solely rely on the security of the blockchains that the query referred to.
Brevis zkAggregatorRollup
zkAggregatorRollup is an aggregation layer that verifies and stores block headers from zkFabric and query results from zkQueryNet.
It acts as a "rollup" of information from both systems and stores attested block headers and query results.
It commits compressed information to different blockchains connected to Brevis.
This layer enhances the security and trustlessness of the overall system by providing a unified storage mechanism for verified data from multiple sources.
The core functionalities of zkAggregatorRollup:
zkAggregatorRollup verifies block headers and query results
Verified data is stored in a data structure for later retrieval and verification
Aggregate proofs are generated for computations
zkAggregatorRollup reduces on-chain verification costs by aggregating multiple proofs for block headers/query results and submitting a single proof for verification on each connected blockchain.
It allows each blockchain to only store the state root for the rollup, reducing overall connections from O(N^2) to O(N).
Implementing the rollup as a lightweight state machine reduces computational costs compared to a Turing-complete virtual machine.
System Components
Rollup Sequencer:
This component receives block headers and query results, verifies their validity, and stores them in the rollup storage.
It is responsible for committing the data to each connected Base Chain.
Rollup Prover Network:
The Prover Network generates validity proofs to demonstrate that the block headers and query results are verified and that the rollup storage is accurately updated.
This component ensures the trustworthiness of the rollup.
Base Chain Rollup Contract:
This component is deployed on all connected Base Chains and verifies the validity proofs of each rollup block.
It stores the corresponding state roots in the chain.
Data Availability Layer:
This component provides data availability for zkAggregatorRollup and can leverage existing solutions such as Celestia and Eigenlayer.
It ensures that all data necessary for the rollup is available to all participants.
Let’s understand about the rollup sequencer and the rollup prover network
→ Rollup Sequencer
The sequencer in zkAggregatorRollup verifies validity proof of block headers and query results and maintains Verkle trees for storage of attested block headers and query results.
Initially, the sequencer is a centralized server, but it will become a decentralized sequencer network in the future.
When the sequencer processes an InsertBlockHeaders or InsertQueryResults transaction, it updates the Verkle tree and generates a new rollup block.
→ Rollup Prover Network
The rollup prover network generates proofs for rollup blocks and utilizes accelerators such as GPUs, FPGAs, and ASICs to reduce proving time and cost.
The sequencer dispatches either a single-rollup-block proof job or a multi-rollup-block aggregation-proof job to a rollup prover, and multiple rollup provers may generate proofs in parallel.
Single rollup block proofs involve a Verkle tree circuit that proves the correctness of the tree update after inserting a key-value pair and a recursive verification circuit that proves the correctness of the block headers or query results.
Multi-rollup-block aggregation proofs involve aggregating multiple rollup block proofs into a single aggregate proof.The generated proofs will be later submitted to the Base Chain for on-chain verification.
Team
It's being built by the amazing team at Celer Network (@CelerNetwork) - a project by Computer Science PhDs from MIT, Princeton, UC Berkeley and UIUC
You can check out the updates shared by them on this thread
The white paper is authored by:
Mo Dong
Qingkai Liang
Xiaozhou Li
Junda Liu
How to get involved & references
Here are all the important links / references you’d want to get involved / explore more:
I hope you had a great time reading through the newsletter and found it interesting enough - if you did feel free to drop by and say hi :)
Thanks for reading!