Brevis App Workflow

To build a Brevis-powered dApp, developers need to implement the following three things using Brevis's SDK:

1. The Data Access Module to specify the historical blockchain data needed by the App Contract.

2. The App Circuit to specify the computation logic to run on the specified historical on-chain data.

3. The App Contract to receive and process the ZK-verified computation results.

These three implemented modules are highlighted in Blue in the following workflow diagram:

The diagram illustrates how these modules interact with Brevis. In this section we'll only give a high-level walkthrough of the application flow with a more detailed explanation provided in the following sections.

The entry point of a Brevis-powered dApp is the App Service component, which receives input from users or operators. For example, an App Service of a DEX calculating the trading volume of a batch of traders during a certain period of time will accept a list of wallet addresses and an interested time interval as input parameters.

Then, the App Service is expected to obtain all the data that is needed, according to the application's business logic, through an off-chain blockchain data indexing solution such as Dune Analytics. Continuing with the DEX example, the Data Access Module in App Service will obtain all trade transactions of specified traders during the specified time period.

Note that Brevis is not an off-chain data indexing and query platform. Instead, Brevis's purpose is to generate ZK proofs to convince the application smart contracts that 1) the raw data obtained from off-chain indexing solutions do exist in the history of the blockchain and 2) the corresponding computation results on top of this data is correct.

With the raw blockchain data available, a ZK proof can be generated to show that both the computation of the application's business logic and the on-chain data dependency are valid and correct. The App Circuit's proof generation process can be hosted as part of the App Service as shown in the diagram. The historical on-chain data validity proof generation is hosted by Brevis Service. In this deployment model, the computation proof that is generated by the App Circuit will be sent to Brevis Service along with the raw blockchain data that this computation is dependent on. Brevis Service will then combine these two proofs into a single one that simultaneously asserts both the validity of the data and the computation results. In the context of the DEX example, the final proof can be used to convince a verifier that a certain user did make (say) 350 trades on the DEX and the total trading volume by adding all trades up is (say) $3M. Note that the proof generation of both the App Circuit and Brevis Service can be migrated to a decentralized prover network and Brevis coChain in the future.

Finally, the computation results and the corresponding ZK proof will be verified on-chain in Brevis Contracts. Once the verification is successful, Brevis Contracts will call the callback function on the App Contract, which will handle the results by matching it with the original request. This will compete the entire asynchronous coprocessor computation flow.

Next, we discuss each of the steps in more detail.