IOSG OFR 13th Keynote Recap | Brevis | Build Data-driven dApps With Smart ZK Coprocessor
Hello everyone, and thanks a lot for coming. I’m Michael, Co-founder of Brevis.
We all know that AI is awesome, and bringing AI inference on-chain is even better. However, the biggest challenge we’re facing is that AI is expensive in terms of its required significant computational resources. So, the key question is: how can we enable AI inference and AI power in blockchain?
That’s where the fundamental challenge lies, because blockchains are not set up and built for this type of heavy and data-driven computation. They can’t handle computing or storage efficiently. Even with the advancement of Layer 2 scaling solutions, the technology is still ruled in Layer 1, which is run by consensus. Therefore, what we need to do here is to change how we build applications overall. Fortunately, we have some previous experience in the Web2 world.
Before 2000, the entire Web2 ecosystem was built on a highly synchronous architecture, where all tasks were handled by a single web server. However, this type of architecture couldn’t scale to the level of Web2 that we see today. Over the last 20 years, we transitioned to a more modern web architecture, where the web server acts primarily as a coordinator. It receives requests from users and, with high scalability, delegates these tasks to specialized backend services such as AI, databases, and authentication. Each of these services processes the request, then sends the results back. The web server simply coordinates and settles the request once all the results are returned.
If you look at Web3 today, the architecture faces the same issues. We have smart contract platforms on the blockchain, but they function as monolithic Web3 services.
These smart contracts offer very limited programming capabilities. For example, smart contracts cannot directly access a user’s historical behavior, like past trades on Uniswap.
It’s impossible to retrieve that data directly from smart contracts on the blockchain. To give you a simple example: if you wanted to build a trader loyalty program on-chain, where users earn rewards for trading within the last 30 days, it would take about 8 hours of block time and cost around $40,000 in transaction fees. This is just for the computation of a single user if done within the smart contract, because there is no native access to historical data on-chain.
Now, if you apply a modern asynchronous Web2 architecture to blockchain applications, the blockchain can be treated as a lightweight web server and a coordination point for off-chain computation resources, such as coprocessors, zkML, and zkEVM. So how does this work? We’ll walk through a concrete example using our zk data coprocessor Brevis.
The zk data coprocessor is a piece of software that generates zk proofs for any arbitrary computation performed on blockchain data off-chain. It then sends the proof back to the smart contract, allowing the blockchain to verify the computation efficiently and at a low cost. The result can be directly utilized by the smart contract. Building with our zk coprocessor Brevis is incredibly simple: instead of writing complex, data-accessible smart contracts, you can just write some off-chain code specifying the data you want to read. Brevis will then generate a zk proof, which you can send back to the blockchain for the smart contract to process. We support a variety of data types, including user state, log information, transaction receipts, events, and user behaviors.
You might wonder how using a coprocessor differs from using a data indexing solution to retrieve the same data. The key difference lies in the zk feature of Brevis. With Brevis, you get an end-to-end zk proof that ensures the data you gathered and the subsequent computations are accurate. Throughout the entire process, no additional trust is required beyond what the blockchain inherently provides. That’s the power of zk proofs. Moreover, once you’ve accessed the data through the universal port API, Brevis offers an easy-to-use data stream-like API. You don’t need to learn anything about zk circuit building; instead, you simply specify the data you want to compute and submit a callback function to the blockchain’s smart contract, where the business logic can be executed.
With Brevis, instead of performing all tasks on-chain, any smart contract can send requests to the off-chain environment where computation is performed end-to-end with zk proof encapsulation. The results are sent back to the blockchain, enabling the desired features to be built. This workflow significantly reduces costs compared to doing everything on-chain.
Brevis is now publicly available and ready for use. In fact, many companies are already building similar data-driven features with it. For instance, we recently launched on mainnet with Kwenta Network, one of the largest perpetual swap aggregators on Arbitrum. They leverage Brevis to process large volumes of data and generate proofs for their clients. One of the key use cases for Brevis is enabling data-powered intelligence to enhance DeFi applications, allowing them to customize user preferences based on historical behaviors. This capability is extremely powerful because it’s something that has been missing in Web3, but now, with Brevis, it’s readily accessible. Additionally, we’re collaborating with consumer applications like gaming, where customizing user feeds based on behavior is a major category. There’s also a significant opportunity within data and computation infrastructure, where trust-free access to data can drive more efficient block data markets.
Lastly, I want to highlight that we began with a pure zk model but have since introduced an optimistic processing model with zk fraud proof. This means that, instead of relying entirely on zk proofs, you can choose to use optimistic coprocessing.
For example, with Eigenlayer AVS, coprocessing results are proposed on the blockchain first, and if the result is incorrect, zk fraud proofs can be submitted to challenge the data. This approach provides a comprehensive range of tradeoffs: lower costs off-chain, zk usage, and additional features such as proof of completeness. This allows for the generation of a more secure and simple state without reducing security assumptions. With that, I’d like to conclude my presentation, and thank you all for listening.
