Brevis: A ZK Omnichain Data Attestation Platform

TL;DR

Web 2.0 applications often operate as walled gardens with limited data interoperability, resulting in user lock-in and fragmented identities. Web3 decentralized applications (dApps) built on top of blockchains have the potential to overcome these issues. However, smart contracts, which are the core of dApps, currently lack a trust-free way to access and utilize the vast amount of data stored in the full history of multiple blockchains. To address this limitation, we’re introducing you to Brevis, a Zero-Knowledge (ZK) omnichain data attestation platform that enables dApps to access, compute, and utilize arbitrary data across multiple blockchains in a completely trust-free way.

Brevis’s architecture consists of three components: zkFabric, zkQueryNet, and zkAggregatorRollup. zkFabric collects block headers from all of the connected blockchains and generates Consensus Proofs that attest to the validity of these block headers via ZK light client circuits. This is essential for dApps to be able to access the block headers and all of the states from all supported blockchains in a trust-free way. zkQueryNet is an open marketplace of ZK Query Engines that can accept data queries from on-chain smart contracts directly and is able to generate the query results and corresponding ZK Query Proofs via the ZK Query Engine circuits. These engines range from highly specialized, such as calculating the trading volume of a DEX during a specific time period, to highly generalized with data indexing abstractions and high-level query languages, catering to a diverse set of application requirements. zkAggregatorRollup is a specialized ZK rollup that acts as the aggregation and storage layer for zkFabric and zkQueryNet. It verifies the proofs from both of these components, stores the attested data, and commits its zk-attested state roots to all connected blockchains, allowing dApps to access the attested query results directly in their on-chain smart contracts’ business logic. 
With this modularized architecture, Brevis enables fully trust-free, flexible and highly efficient data access and computation capabilities across all supported chains for on-chain smart contracts. This enables entirely new paradigms for dApp development. Brevis has a wide range of use cases like data-driven DeFi, zkBridges, on-chain user acquisition, zkDIDs, social account abstraction, and much more.

In the initial Proof of Concept for Brevis, we built some of the fastest ZK light client circuits as parts of zkFabric with gnark for Ethereum PoS, Cosmos, and BNB Chain to enable any EVM and non-EVM chains to access the states of these three chains in a completely trust-free way. Some of the key circuit performance benchmark numbers are summarized in Table 1 (using a Linux Server with 20 cores@2.3GHz and 384GB of memory with no GPU acceleration). Using these ZK light client circuits, we implemented a user-facing asset zkBridge between Ethereum Goeril and BNB Chain Testnet for users to try out. 

For a more in-depth description of Brevis, continue reading this blog or you can refer to our Brevis White Paper for more comprehensive and technical details.

Web3 dApps are Missing Out on the Value of Utilizing Omnichain Data

Web 2.0 applications have revolutionized user interaction and content generation on the internet. However, these applications often operate as walled gardens, with user data stored in centralized databases controlled by platform providers. This leads to challenges such as limited data interoperability, fragmented identities, financial and social data lock-ins, and subsequent issues like hindered innovation, vendor lock-in, privacy issues, and fragmented user experiences. 

Web3 decentralized applications (dApps) have the potential to break these information silos by being built on top of blockchains, which have append-only and publicly accessible data storage. With the multi-blockchain expansion and adoption of dApps continuing to grow, L1 blockchains and L2 rollups have accumulated a wealth of raw data, such as asset transfers, contract function calls, in-contract events, and blockchain state roots. With all of this data, it makes it possible to extract valuable information such as ownership of assets, user activity profiles, social graphs, financial connections, market pricing trends, trading volumes and much more. 

Many off-chain products and projects are already leveraging this unique property of publicly accessible data storage. Products like Dune Analytics and Graph provide off-chain data indexing or data analytics for blockchain applications across time. They can also be used to provide stateful data, such as user transaction history for dApps’ frontend UIs. These applications access blockchain data in an off-chain way, recording, indexing, and computing data via the blockchain nodes’ RPC endpoints.

Intuitively, on-chain blockchain applications or smart contracts should be able to easily access and utilize these omnichain data insights in their business logic in a completely trust-free way, since all of these dApps are the “native residents” inside of the blockchains. 

However, this is not the case. 

In reality, Web3 dApps simply have no way to access the vast majority of the data stored in blockchains in a trust-free way. This is because smart contracts deployed on a single blockchain are living in the context of blockchain virtual machines and can only access data: 

• (1) via explicitly defined interfaces of other smart contracts; 
• (2) That is on the same blockchain; 
• (3) Only in the most current state of the blockchain instead of with a complete historical view.

One might argue that solutions, such as parsing and computing data query semantics directly in smart contracts or validating consensus algorithms with pure smart-contract-based trust-free light clients, are in theory possible. However, these approaches are infeasible due to the high on-chain computation costs. Off-chain Oracle solutions can be used, but they require additional reliance on external Oracle security for data validity. 

So, how can we allow smart contracts to access and compute data from any blockchain over an arbitrary period of time?

Zero-Knowledge Succinct Proofs: The Magic of Computation Migration

Zero-knowledge succinct proof technology (ZKP) is an emerging field in cryptography with the potential to transform our digital interactions. It allows one party to prove the validity of a computation to another without revealing any information about the input value. The verifying party only needs to run a computationally inexpensive program, called a verifier, to confirm the computation’s accuracy.

ZKP not only offers privacy benefits but also enables the migration of computation from high-cost per unit locations to low-cost per unit locations. The prover performs a computationally expensive operation to complete the computation and generate a cryptographic proof, while the verifier runs a cheaper operation to validate the proof. This process shifts the computation location from verifier to prover, making it a worthwhile tradeoff if the prover’s unit computational costs are substantially lower than those of the verifier. This computation migration property is the driving force behind many ZK rollups. We will also leverage this property to design Brevis.

Brevis System Overview 

As shown in Figure 1, Brevis’s architecture consists of three main components: zkFabric, zkQueryNet, and zkAggregatorRollup. zkFabric collects block headers from all of the connected blockchains and generates ZK Consensus Proofs that attest to the validity of these block headers. These block headers are further zk-verified and stored in zkAggregatorRollup. zkQueryNet accepts data queries from dApps and generates ZK Query Proofs based on the attested block headers stored in zkAggregatorRollup. These query results are also zk-verified and stored in zkAggregatorRollup. Essentially, zkAggregatorRollup is a ZK rollup that acts as the aggregation and storage layer for zkFabric and zkQueryNet. By committing its zk-attested state roots to all Brevis connected blockchains, zkAggregatorRollup allows dApps to access attested query results and utilize them directly in their on-chain smart contract logic in a completely trust-free way. 

With this high-level overview in mind, let’s walk through each component. 

First, in order to utilize arbitrary data across multiple blockchains, dApps need to have a trust-free way to access the block headers from blockchains other than their native chain. This is because block headers contain state roots that can be used to access the data and states of the blockchains. To fulfill this need, zkFabric is introduced to generate ZK Consensus Proofs for block headers of all the supported chains. A Consensus Proof is generated by a light client circuit proving that the block header in question is generated according to the consensus rule of the corresponding blockchain. zkFabric itself is a decentralized system consisting of a network of block header relayers and provers.

To actually extract valuable information from the zk-attested block headers, zkQueryNet is built as an open marketplace of ZK Query Engines that directly interface with dApp developers and smart contracts. A dApp developer can choose a ZK Query Engine that fits their needs and then write queries via high-level APIs in smart contracts. 

At run time, a smart contract can call the Agent Smart Contract of zkQueryNet targeting a specific ZK Query Engine. This query will be picked up by the provers of this ZK Query Engine. Using the already zk-attested block headers provided by zkFabric, the ZK Query Engine can then compute the query results and generate a ZK Query Proof attesting that computation is done correctly. 

Different ZK Query Engines can have very different APIs ranging from generalized query languages to highly specific function calls with a fixed number of parameters. For example, on one side of the spectrum, a specific ZK Query Engine may only expose a function that accepts two block numbers and two chain IDs that will return the Time Weighted Average Price for the ETH/USDC pair during a specified time period on Uniswap for the specified two blockchains. On the other hand, a generalized ZK Query Engine can present developers with a blockchain indexing abstraction using high-level database queries such as SQL or GraphQL, which is very much like what they can do in off-chain data solutions such as Dune Analytics and Graph. 

Brevis will provide a set of ZK Query Engines that address many immediate use cases with reasonable flexibility and high performance. As zkQueryNet is an open marketplace, we expect dApp developers and other third parties to provide other ZK Query Engines to better serve a diverse ecosystem of applications. 

Finally, zkAggregatorRollup is a ZK rollup blockchain powered by a lightweight ZK virtual machine that aggregates different proofs and their inputs from zkQueryNet and zkFabric. Specifically, zkAggregatorRollup VM runtime has the following functionalities: 

• (1) Recursively verify proofs generated by zkQueryNet and zkFabric; 
• (2) Store the zk-verified block headers from zkFabric; 
• (3) Store queries and the zk-verified results. 

When plugging in a ZK Query Engine or adding a new type of consensus, zkAggregatorRollup will be extended to support the verification of the corresponding ZK proofs. Moreover, unlike many ZK rollup chains where the proofs of state root progression are only committed to a single blockchain, zkAggregatorRollup’s state root proofs are committed to all the blockchains supported by Brevis. 

With zkAggregatorRollup’s state roots available on all connected chains, smart contracts can access the query results and block headers via data inclusion proofs. The primary benefit of using zkAggregatorRollup as an aggregation point is to reduce the block header communication or verification overhead from O(N^2) to O(N) (where N is the number of blockchains supported by Brevis), and to share query results on-demand and efficiently across all connected blockchains. 

To sum up, Brevis has the following key advantages: 

• Trust-free: Brevis does not rely on any off-chain party to attest data and computation integrity. Instead, it relies solely on ZK succinct proofs. Therefore, applications using Brevis do not need to accept any additional trust assumptions other than those of the underlying blockchains and cryptographic protocols. 
• Omnichain: Brevis integrates with multiple blockchains running on different consensuses and therefore enables omnichain data access and computation.
• Modularized: Brevis uses a highly modularized design in its zkQueryNet and therefore can cater to a wide range of application requirements through different flavors and implementations of ZK Query Engines. 
• Low-cost: Brevis’s zkAggregatorRollup essentially works as a batching and aggregation layer for block headers and query results. Therefore, zkAggregatorRollup significantly reduces the on-chain costs by orders of magnitude by removing the otherwise N-to-N communication overhead and by enabling cross-chain and cross-application query results sharing.

It is important to note that the key difference between Brevis and off-chain data indexing solutions such as Dune Analytics and Graph is that Brevis can generate zk-attested query results that can be directly utilized by the business logic of on-chain smart contracts in a trust-free way. Compared to off-chain solutions whose data results can only be used in the web2-based data analytic context. 

An Example Walkthrough

Before we discuss a wide range of application use cases, we present a concrete application example to provide an overview of Brevis. Note that this overview abstracts some key details and we refer readers to the full white paper for more details. 

Multi-blockchain decentralized exchanges (DEXes), such as PancakeSwap, often need to dynamically adjust farming rewards for incentivized pools based on trading pair quality scores such as average daily volume, 14-day volume, price volatility, number of active traders, and liquidity providers across all supported blockchains.

Currently, such adjustments must be made through governance proposals, which entail significant human overhead and can only be done when the setting deviates severely from optimal. This causes things to lag behind market trends and often leads to a decline in user engagement, revenue loss, and a waste of treasury funds due to suboptimal reward configurations.

Brevis can address these challenges by enabling DEXes to adjust the liquidity farming schedule programmatically and in a trust-free way based on omnichain market trends. For simplicity, let us assume that volume is all we care about. Let’s also assume that there is a ZK Query Engine 𝑄 in zkQueryNet that provides a set of highly optimized circuits for DEX volume data with an API that looks like the following:

uint_64 get_trading_volume(uint_64 chain_id, 
                           uint_64 start_block, 
                           uint_64 end_block, 
                           address pair)

Figure 2 shows the step-by-step process of how this use case works. To use this data compute API, the DEX smart contract first needs to make a function call to the Agent Smart Contract (denoted as 𝐴) of zkQueryNet with the above query parameters specified. Note that this function is asynchronous and only immediately returns a 𝑞𝑢𝑒𝑟𝑦_𝑖𝑑 so the DEX’s smart contract needs to remember this ID and has a handler to process the return value later.

This function call is then picked up by 𝑄’s prover, denoted by 𝑃_𝑞. Using the block headers for 𝑐ℎ𝑎𝑖𝑛_𝑖𝑑 (which has already been verified and stored in zkAggregatorRollup), 𝑃_𝑞 will generate a ZK proof 𝜋 proving that on 𝑐ℎ𝑎𝑖𝑛_𝑖𝑑 during the time period from 𝑠𝑡𝑎𝑟𝑡_𝑏𝑙𝑜𝑐𝑘 to 𝑒𝑛𝑑_𝑏𝑙𝑜𝑐𝑘 the DEX’s 𝑡𝑟𝑎𝑑𝑖𝑛𝑔_𝑝𝑎𝑖𝑟 indeed has 𝑣𝑜𝑙𝑢𝑚𝑒.

𝑄’s proof verifier in zkAggregatorRollup verifies 𝜋, then the result 𝑣𝑜𝑙𝑢𝑚𝑒, as well as the corresponding query parameters, are stored in zkAggregatorRollup. This state is later included in a state root 𝑆 of zkAggregatorRollup and committed to the chain on which the DEX is deployed.

Now, 𝐴 can retrieve and verify the query result by using a state inclusion proof against 𝑆. This retrieved query result will then be returned back to the DEX’s smart contract’s handler function. The handler function will be able to match the stored 𝑞𝑢𝑒𝑟𝑦_𝑖𝑑 with the returned query result and adjust the liquidity farming schedule based on the volume data.

zkFabric PoC: Ethereum PoS, Cosmos Tendermint, BNB Chain Light Client ZK Circuits and ZK Bridge

Although on-chain light client solutions are trust-minimized in theory, they are prohibitively expensive to implement in practice. Brevis addresses this challenge by combining light client protocol and ZKP, where zkFabric generates a ZK Consensus Proof for all connected blockchains and stores the corresponding block headers in zkAggregatorRollup. In the initial Proof of Concept of zkFabric, we implement light client protocols in the ZK circuits for Ethereum PoS, Cosmos Tendermint, and BNB Chain.

• Light client for Ethereum PoS. The circuit for the Ethereum PoS light client mainly consists of 2 sub-circuits. One is the SSZ Sync Committee Commitment circuit that updates the SSZ commitment for the 512 current validators in the sync committee, which rotates every 27 hours. The other is the aggregate BLS12-381 signature verification for the 512 validators, which mainly conducts hash-to-curve calculations and BLS12-381 pairing over the scalar field of BN254 so that it can be efficiently verified in Ethereum smart contracts. Here, the non-native pairing requires a massive non-native field of arithmetics. Following various tricks for BLS pairing implementations and using the efficient range check gadgets provided by gnark, we are able to achieve the accelerated BLS12-381 signature verification over BN254 scalar field when compared to existing implementations. For the SSZ Sync Committee Commitment circuit, we are working on the optimizations using lookup tables and will release an optimized circuit soon.
• Light client for Cosmos Tendermint and BNB Chain. The BNB chain adopts a two-layer architecture, comprising the base layer, referred to as the BNB Beacon Chain (BBC), and the execution layer, called the BNB Smart Chain (BSC). The BBC utilizes Tendermint consensus, while the BSC employs a Proof-of-Authority (PoA) consensus called Parli. Each BSC block is signed off by one of the validators in the set. As a specialized Tendermint application, the BBC manages the election and updates of the BSC validator set. Every 24 hours, a new set of BSC validators are elected and synchronized to the BSC via an IBC-like cross-chain mechanism that predates the official IBC specification. For the BBC (essentially Tendermint), the light client mainly involves verifying a batch of Ed25519 signatures, which are expensive to verify directly on-chain. We implement the non-native Ed25519 signature verifications over the BN254 scalar field in gnark. Using the range check gadgets in gnark, we achieve state-of-the-art performance for non-native Ed25519 signature verification. For BSC, the PoA consensus involves secp256k1 signature verifications which are verified directly in the smart contract due to the existence of pre-compiles.

The aforementioned circuits are implemented in gnark and open-source. Their benchmark performance is shown in Table 1 at the beginning of this blog. Note that we are continuously optimizing the circuit and also expect to utilize hardware acceleration and parallelization in the near future.

Additionally, Nearly all existing interoperability solutions fall into the “external validation model” which necessitates trust in an intermediary entity. As a first step, we built a proof-of-concept demo for a ZK Bridge between the Goerli testnet and the BNB Chain Testnet demonstrating the capabilities of Brevis. Built upon the light clients, we built a bi-directional asset ZK bridge between the Goerli testnet and the BNB Chain Testnet. It should be noted that for the Goerli-to-BNB direction, the expected bridge delay is about 25 minutes since the block header that includes the source chain tx is only considered finalized and relayed after 2-3 epochs (64-96 blocks). 

Numerous Exciting Use Cases Enabled by Brevis

Aside from the above example of a ZK Bridge, Brevis empowers developers to create dApps that can access omnichain data across arbitrary time horizons in a way that was previously impossible. This innovation will undoubtedly establish a new paradigm, transforming how dApps are developed across all sectors. In this section, we will present several immediate applications, however we anticipate the community will discover many more use cases.

Data-driven DeFi

In addition to the liquidity farming reward auto-adjustment example discussed previously, we believe data-driven DeFi will become a broad class of applications leveraging Brevis, thanks to the scalability and privacy it enables.

With trust-free access to comprehensive historical and omnichain trading flows, derivatives such as options can now incorporate novel exercise conditions, like Exponential Time Weighted Price or Time-Volume Weighted Price. Alternative derivatives tracking user behavior, price trends, protocol or blockchain TVL changes, volatility, price correlations, and more will also be possible through various implementations of ZQEs.

On-chain active fund management solutions can generate ZK proofs demonstrating that position adjustments are based solely on specific algorithmic models derived from market data, without any unauthorized human intervention. Furthermore, due to the privacy-preserving property of Brevis, the precise model parameters can remain concealed to maintain a competitive market advantage.

User Acquisition with Trust-Free Revenue Sharing

In Web 2.0, the user acquisition process ends when a user downloads or registers, with advertisers paying a fixed price for all users, regardless of their Lifetime Value. This arrangement is not ideal for both advertisers and advertising channels, as the former cannot differentiate user value, and the latter cannot share long-term revenue. This issue arises because post-acquisition user data is private and inaccessible to advertising channels.

Web3 can potentially change this model, as most of the user activity data is public. However, current platforms still follow the Web 2.0 paradigm. Brevis revolutionizes this by allowing advertising channels to generate trust–free revenue proofs for acquired users. This will lead to a fundamental shift in Web 3.0 user acquisition, where advertisers pay only for high-value users, and advertising channels are incentivized to optimally match users with advertisers.

zkDID

Brevis is an essential tool for constructing trust-free zkDID solutions, helping prevent Sybil Attacks and facilitating user life cycle management in various use cases. By generating ZK proofs based on hard-to-fake on-chain behaviors, Brevis enables dApp developers to operate in a fully trust-free manner while preventing Sybil Attacks in campaigns or rollouts.

By leveraging query results and data of aggregated user behaviors, a trust-free user life cycle management process can be built, allowing for loyalty systems, VIP trader programs, and LiveOps campaigns in blockchain gaming. Brevis offers several advantages over in-app accounting, such as lower costs, future-proofing, and portability. zkDIDs generated via Brevis are stored in zkAggregatorRollup, making them accessible to different applications.

Account Abstraction

Brevis offers a compelling use case in Account Abstraction (AA) by improving security and usability in blockchain applications. One key benefit is social recovery, which helps regain wallet access even when the main controlling key is lost. Brevis enables smart wallets to implement social recovery based on recent transaction connections rather than a fixed set of external wallets. This approach reduces maintenance overhead and lowers the entry barrier for new users in the blockchain ecosystem. 

Brevis also has potential applications in many other areas such as social and NFT gaming. We encourage developers to explore and discover more exciting use cases for Brevis.