Interpret Celer's ZK full-link data calculation and verification platform Brevis

23-03-22 09:15
Read this article in 36 Minutes
总结 AI summary
View the summary 收起
Original source: Celer Network


As we all know, Web2 applications often run like walled gardens in isolation, resulting in limited data interoperability, user lock-in, and identity fragmentation. Web3 Decentralized applications (dApps) built on blockchain can indeed solve these problems. However, the smart contracts at the heart of DApps are currently unable to access and exploit vast amounts of data stored in the full history of multiple blockchains in a way that is untrusted.

To remove this restriction, we've launched.Brevis, a ZK full-link data computing and verification platform that enables DApps to access, compute, and leverage arbitrary data across multiple blockchains in a fully untrusted manner.

Figure 1. Brevis architecture

The architecture of Brevis consists of three components: zkFabric, zkQueryNet, and zkAggregatorRollup.

zkFabric collects "block heads" from all connected blockchains and, after proving their validity through the ZK Light client circuit, generates proof of consensus. This component is essential for dApps to freely access the "block header" and all states of the supported blockchain in a untrusted manner.

zkQueryNet is an open marketplace that provides a ZK query engine that accepts data queries directly from on-chain smart contracts and generates query results and corresponding ZK query proofs through the ZK query engine circuit. Some of these engines provide highly specialized queries, such as calculating the dex transaction volume over a configurable time period; Others are highly generic, supporting data index abstractions and high-level query languages to meet a variety of application requirements.

zkAggregatorRollup is a specialized ZK rollup that acts as the aggregation and storage layer for zkFabric and zkQueryNet. It verifies proofs from these two components, stores proof data, and submits its zk proof state root to all connected blockchains, allowing Dapps to access proof query results directly in the business logic of smart contracts on their own chain.

Through thismodularizationArchitecture that Brevis can provide for on-chain smart contractsCompletely trusting, flexible and efficienttheFull chainData access and computing power. Brevis unlocked itA new paradigm for dApp development, widely supportedUse case, for exampleData-driven DeFi, zk cross-chain bridge, on-chain user acquisition, zkDID, social account abstractionAnd so on.

In Brevis's initial proof-of-concept, we used  gnark  Some of the fastest currently running ZKS are built into zkFabricLight client circuit, for Ethereum PoS, Cosmos, and BNB chains, enabling any EVM and non-EVM chainsComplete distrustThe way to access the state of these three chains.

Table 1 summarizes some of the key circuit performance benchmarks (data obtained from a 20-core, 2.3GHz Linux server with 384GB of memory, tested without GPU acceleration). Using these ZK light client circuits, we have implemented a user-oriented cross-chain support between Ethereum Goeril and BNB ChainAssets zkBridge.

Table 1-ZK Light client circuit performance evaluation

(Linux server / 20 cores /@2.3GHz /384GB memory)

To learn more about Brevis, read on. Welcome toBrevis white paperTo obtain comprehensive technical information.

Web3.0 DApps are missing out on the potential value of full-link data

Web 2.0 applications have revolutionized the way Internet users interact and generate content. However, these apps often operate as separate walled gardens, with user data stored in centralized databases controlled by the platform vendor. This leads to limited data interoperability, identity fragmentation, locking up financial and social data, and so on, resulting in blocked innovation, vendor lock-in, privacy abuse, and fragmentation of the user experience.

Web3 decentralized applications (DApps) built on top of the blockchain will be able to break down these silos of information because the blockchain's data store only allows new information to be added to the existing one, and all data is publicly accessible. As the multi-chain ecosystem expands, and because of the increasing popularity of Dapps, L1 blockchain and L2 rollup accumulate rich raw data -- such as asset transfers, contract function calls, intra-contract events, and blockchain state roots -- that will allow us to extract valuable information, Examples include asset ownership, user activity profiles, social graphs, financial connections, market price trends, trading volumes, and so on.

A number of off-chain products and projects are already taking advantage of these publicly accessible data stores - products such as Dune Analytics and Graph provide off-chain data indexing or analysis across time periods for blockchain applications. They can also provide status data, such as user transaction history, to the dApp's front-end UI. These applications access blockchain data in an off-chain manner, recording, indexing, and calculating data through RPC ports on blockchain nodes.

It's natural for us to thinkon-chainBlockchain applications or smart contracts should be able to easily access and utilize this whole-chain data in their business logic in a fully untrusted manner. After all, these Dapps are "native residents" within the blockchain.

However, this is not the case.

In fact,Web3 Dapps cannot access most of the data stored in the blockchain in a fully untrusted manner. This is because smart contracts deployed on a single blockchain exist in the scenario of a blockchain virtual machine, and therefore can only access data in the following ways:

,  (1) Interfaces clearly defined by other smart contracts;

,  (2) The data must be on the blockchain where the dApp itself resides;

,  (3) Only the current state can be obtained, and complete historical data cannot be obtained.

One could argue that there are solutions that could theoretically solve the above problems, such as parsing and computing data query semantics directly in smart contracts, or using a pure smart contract-based, de-trusted light client to validate consensus algorithms. However, these methods are not practical due to high on-chain computing costs. We can use off-chain seers, but they rely on the external security of the seer itself to ensure data validity.

So how do we get smart contracts to access and compute data over any period of time within any blockchain?

Zero-knowledge Concise Proof: The Magic of computational Migration

Zero-knowledge concise proof technique (ZKP) is an emerging field in cryptography that has the potential to change the way we interact digitally. It allows one party to prove the validity of a calculation to another without disclosing the input valuesanyInformation. The verifier only needs to run a computationally cheap program called a verifier to verify the accuracy of the calculation.

ZKP not only provides privacy, but also migrates computing from high unit cost to low unit cost. The prover completes the calculation and generates the cryptographic proof by performing an expensive computational operation, while the prover runs a less costly operation to verify the proof. This process will generate a large number of computational positions from the prover to the prover. If the prover's computational cost per unit is much lower than the prover's computational cost, it will be a more efficient processing method for the whole proof system. This computational migration attribute is the driving force for many ZK rollup, and we will use this attribute to design Brevis as well.

Brevis System overview

As shown in Figure 1, Brevis' architecture consists of three main components: zkFabric, zkQueryNet, and zkAggregatorRollup. zkFabric collects "block heads" from all connected blockchains and generates ZK consensus proof of their validity. These "block headers" are further zk validated and stored in zkAggregatorRollup. zkQueryNet accepts the data query from the dApp and generates the ZK query proof based on the already proven "block header" stored in zkAggregatorRollup. These query results are also stored in zkAggregatorRollup after being validated by zk.

Essentially, zkAggregatorRollup is a ZK rollup that acts as an aggregation and storage layer for zkFabric and zkQueryNet. By submitting a ZK-proven state root to all Brevis connected blockchains, zkAggregatorRollup allows Dapps to access proven query results and use them in a trusted manner directly in their on-chain smart contract logic.

Now that you have the overall overview, let's examine each component in detail.

First, in order to take advantage of arbitrary data on multiple chains, a dApp needs to access the "block header" of a chain other than its local chain in a way that is de-trusted. This is because the "block head" contains state roots that can be used to access data and state in the blockchain. To meet this need, we introduced.zkFabric  To generate ZK consensus proofs for the "block heads" of all supported chains. A light client circuit generates a consensus proof that the verified "block head" was generated according to the consensus rules of the corresponding blockchain. zkFabric itself is a decentralized system consisting of a network of "block header" Repeaters and provers.

In order to extract valuable information from the already ZK-proven "block heads", we construct.zkQueryNet, an open marketplace offering a variety of ZK query engines that dApp developers and smart contracts can interact with directly. dApp developers can choose the ZK query engine that suits their needs and write query requests through advanced apis in the smart contract.

During runtime, a smart contract can invoke zkQueryNet's proxy smart contract for a specific ZK query engine. The prover of the ZK query engine will receive this query request. The ZK query engine uses the ZK-certified "block header" provided by zkFabric to compute the query result and generate the zk query proof to prove that the calculation has been completed correctly.

Different ZK query engines can provide a wide variety of apis, ranging from generic query languages to highly specific function calls with fixed parameters. For example, in a use case serving a very specific query request, a ZK query engine might expose only a function that accepts two block numbers and two chain ids to query the weighted average price of ETH/USDC transaction pairs on both blockchains over a specified time period on Uniswap. On the other hand, a general-purpose ZK query engine can use high-level database query languages, such as SQL or GraphQL, to provide developers with block chain abstraction, which is very similar to what is performed in down-chain data solutions, such as Dune Analytics and Graph.

Brevis will provide a set of ZK query engines that address many existing use cases with reasonable flexibility and high performance. Since zkQueryNet is an open marketplace, we expect dApp developers and third-party platforms to offer other ZK query engines to better serve the diverse application ecosystem.

Finally,zkAggregatorRollup  Is a ZK rollup blockchain powered by lightweight ZK virtual machines, which aggregates different proofs and inputs from zkQueryNet and zkFabric. Specifically, zkAggregatorRollup VM runtime has the following features:

,(1) Recursively verify proofs generated by zkQueryNet and zkFabric;

,(2) Store block headers from zkFabric that have been verified by zk;

,(3) Store query requests and zk verification results.

When a new ZK query engine is plugged in or a new consensus type is added, zkAggregatorRollup expands support for the corresponding ZK proof validation. In addition, while many ZK rollup chains only submit their state root series proofs to a single blockchain, zkAggregatorRollup is different in that it submits its state root proofs to Brevis All blockchains supported.

Because all chains supported by zkAggregatorRollup have state roots, smart contracts can retrieve query results and block headers through proof of data inclusion. The main benefits of using zkAggregatorRollup as an aggregation point are the reduction of block header communication or validation costs from O(N^2) to O(N) (where N is the number of blockchains supported by Brevis) and efficient on-demand sharing of query results between all connected blockchains.

In summary, Brevis has the following key advantages:

· To trust:Brevis does not rely on any down-chain to prove data and computational integrity; Instead, it relies only on the ZK concise proof. Therefore, applications using Brevis do not have to accept any additional trust assumptions other than the underlying blockchain and cryptographic protocols;

· Full chain support:Brevis can integrate multiple blockchains operating on different consensus mechanisms to support full-link data access and computing;

· Modularity:Brevis is highly modular in its zkQueryNet, so it can build different ZK query engines to meet the needs of a wide range of audiences and designs;

· Low cost:Brevis' zkAggregatorRollup is essentially a batch and aggregate layer of block headers and query results. Thus, zkAggregatorRollup significantly reduces on-chain costs by eliminating the cost of n-to-n communication and sharing cross-chain and cross-application query results.

Notably, the main difference between Brevis and down-chain data indexing solutions such as Dune Analytics and Graph is that Brevis can generate ZK-proven query results that can be used directly by the business logic of the on-chain smart contract in a trusted manner, The data results of the off-chain solution can only be used in the context of web2 based data analysis.

Use case presentation

Figure 2 - Use case demonstration

Before discussing broad use cases, we provide a concrete application example to outline the workflow of Brevis. Note that this overview abstracts some key details, and we recommend that readers refer to the full whitepaper for details.

Decentralized trading platforms (DEX) like PancakeSwap deployed on multiple chains typically need to dynamically adjust the rewards of all on-chain liquidity pools based on trade pair quality scores (e.g., average daily volume, 14-day volume, price volatility, number of active trading users and number of active liquidity providers).

Currently, such adjustments must be made through community governance proposals, which require significant human overhead and can only be done when the incentive setting deviates significantly from the optimal scenario. This sub-optimal allocation of rewards is often behind market trends and leads to decreased user engagement, lost revenue, and wasted budget money.

Brevis enables DEX to address these challenges by adapting liquidity incentive programs in a stylized and de-trusting manner in line with current full-chain market trends. For simplicity's sake, suppose we want to capture only one piece of data, volume, and we have a ZK query engine in zkQueryNet that provides a highly optimized set of circuits for DEX volume data, with the following API:

uint_64 get_trading_volume(uint_64 chain_id,

uint_64 start_block,

uint_64 end_block,

address pair)

Figure 2 above shows the step-by-step flow of this use case run. To use this data computing API, the DEX smart contract first needs to call zkQueryNet's proxy smart contract (denoted as) with the above query parameters. Note that this function is asynchronous and only returns a query_id immediately, so the smart contract of DEX remembers this ID and also provides a handler to process the return value later.

This function call is then captured by the prover P_q. P_q uses the block header that chain_id has verified and stored in zkAggregatorRollup to prove that DEX's trading_pair does have volume from start_block to end_block in the specified time period. And generate a ZK proof.

Q's proof validator verifies π and volume results in zkAggregatorRollup and stores the corresponding query parameters in zkAggregatorRollup. This state is then included in the state root S of zkAggregatorRollup and submitted to the chain where DEX is deployed.

Now, A can obtain and validate the query results by using the state inclusion proof of S, and then return the obtained query results to the smart contract handler function of DEX. The processing function can match the stored query_id with the returned query result and adjust the liquidity incentive plan accordingly based on the volume data.

zkFabric Proof of concept: Ethereum PoS, Cosmos Tendermint, BNB Chain Light Client ZK Circuits, and ZK Bridge

Almost all existing interoperability solutions belong to an "external validation model" that requires trusting an intermediary entity. While in theory, a solution based on light clients on a chain minimizes trust, it is expensive to implement. Brevis addresses this challenge by combining the Light client protocol and ZKP, where zkFabric generates ZK consensus proofs for all supported blockchains and stores the corresponding block headers in zkAggregatorRollup. In Brevis's initial proof-of-concept, we implemented a light client protocol for ZK circuits on Ethereum PoS, Cosmos Tendermint, and BNB Chain.

· Ethereum PoS Light client. The Ethereum PoS light client circuit consists mainly of two subcircuits. One is the SSZ Sync Committee Commitment circuit, which is used to update the SSZ commitments of 512 current Sync Committee validators, rotated every 27 hours. The other is the aggregated BLS12-381 signature verification of 512 verifier, which mainly does hash-to-curve calculations and BLS12-381 pairing over the BN254 scalar domain for efficient verification in Ethereum smart contracts. Here, non-native pairing requires large-scale non-native domain algorithms. By implementing various BLS pairing techniques and using the efficient range checking tools provided by gnark, we achieved the fastest implementation of BLS12-381 signature verification based on the BN254 scalar domain relative to existing implementations. For the SSZ Sync Committee Commitment circuit, we are using lookup tables for optimization and will release an optimization circuit soon.

· Cosmos Tendermint and BNB Chain Light clients. BNB Chain consists of two layers of architecture, including the base layer (BNB Beacon Chain-BBC) and the implementation layer (BNB Smart Chain-BSC). BBC adopted Tendermint Consensus, while BSC adopted Parli's Proof of Authority (PoA) consensus. Each BSC block is signed by one of the verifiers set. As a dedicated Tendermint application, the BBC manages the selection and updating of the BSC verifier collection. Every 24 hours, the BBC elects a new set of BSC validators through a cross-chain mechanism similar to IBC (which predates the official IBC specification) and synchronizes it with the BSC. For the BBC (essentially Tendermint), the light client will primarily validate a batch of Ed25519 signatures, and the cost of doing this directly on the chain is high. We implement non native Ed25519 signature verification in gnark based on BN254 scalar field. With the range checking tool in gnark, we achieved the highest performance for non-native Ed25519 signature verification. For BSCS, the PoA consensus involves secp256k1 signature validation, which is directly verified in the smart contract due to pre-compilation.

The above circuits are deployed in gnark and open source. The benchmark performance is shown in Table 1 at the beginning of this article. Please note that we are constantly optimizing the circuit and hope to do so in the near future using hardware acceleration and parallelization.

Based on the lightweight client, we built a support for two-way asset transfer between the Goerli test network and the BNB Chain test networkZK Asset Bridge. Note that for an asset cross-chain from Goerli to the BNB Chain test network, the expected delay time is about 25 minutes, since the block header including the source chain transaction will only be finally confirmed and transmitted after 2-3 epoches (64-96 blocks).

Multiple innovative use cases based on Brevis

In addition to the ZK Bridge example above, Brevis enables developers to create DApps that provide unprecedented access to data across the entire chain at any time. There is no doubt that this innovative technology will set a new paradigm and change the way DApps are developed in all areas. In this section, we'll show you some immediate applications, and we look forward to the community exploring more use cases with us.

Data-driven DeFi

With the exception of the automatic adjustment of liquidity incentives discussed above, we believe that "data-driven DeFi" will become one of the broad categories of applications based on Brevis, thanks to its scalability and privacy.

With trusted access to all full-chain trade data and historical status, derivatives such as options can now add new execution conditions, such as index time weighted price or time volume weighted price. By deploying various ZK query engines, new types of on-chain alternative derivatives will also be possible that track user behavior, price trends, protocol or blockchain lock-in changes, volatility, price correlations, and more.

On-chain active fund management solutions can generate ZK certificates that demonstrate that position adjustments are based solely on a specific algorithmic model of market data, without any unauthorized human intervention. In addition, due to Brevis' privacy features, precise model parameters can be hidden to maintain a competitive market advantage.

User acquisition channel to trust for attribution sharing

In Web 2.0, the user acquisition process ends when a user downloads or registers for software, and advertisers pay a fixed price for the acquired user, regardless of retention value. This model is not ideal for both advertisers, who cannot distinguish user value, and advertising channels, who cannot share in long-term revenue. This problem arises because the user data after the customer is only owned by the advertiser, the channel cannot access.

Web 3.0 is likely to change this pattern, since much of the user activity data is public. However, the current platform still follows the Web 2.0 paradigm. Brevis generates for acquired users by allowing advertising channelsProof of income to trust, revolutionized the dilemma. This innovation will drive a fundamental shift in Web 3.0 user acquisition, where advertisers only pay for high-value users and channels are incentivised to match users and advertisers in the best way.

ZK decentralized identity solution

Brevis is an important tool for building a de-trusting zkDID solution that helps prevent Sybil attacks and optimizes user lifecycle management in various use cases. By generating ZK proofs based on hard-to-counterfeit on-chain behavior, Brevis enables dApp developers to operate in a fully de-trusted manner while preventing Sybil attacks in campaigns or promotions.

By leveraging query results and data that aggregate user behavior, Brevis can help build a de-trust user lifecycle management process that facilitates loyalty systems, VIP transaction programs, and LiveOps activities within the blockchain game. This process, built through Brevis, has several advantages over in-app billing, such as lower cost, future-oriented, and portability. The zkDID generated by Brevis are stored in the zkAggregatorRollup and can be accessed by different applications.

Account abstraction

Brevis provides a compelling use case in the account abstraction (AA) space by improving the security and availability of blockchain applications. One of the key applications is social account recovery, where Brevis helps users regain access to their wallets if they lose their primary control key. Brevis enables smart wallets to perform social account recovery based on recent transaction connections rather than a fixed set of external wallets. This approach reduces maintenance costs and lowers barriers to entry for new users of the industry.

Brevis has potential applications in many other areas, including social and NFT gaming. Developers are welcome to explore and build more new Brevis use cases!

This article is from submissions and does not represent the views of BlockBeats.  

欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:

Telegram 交流群:

Twitter 官方账号:

举报 Correction/Report
Choose Library
Add Library
Add Library
Visible to myself only