TL;DR
We are excited to introduce you to Brevis coChain! An innovative advancement designed to enable a new “propose-challenge” ZK Coprocessor model. With this new architecture, developers are given the ability to build data-driven dApps that operate at a significantly lower cost, reduced latency and a significantly enhanced user experience when compared to the existing “pure-zk” model. It also enables new features like proof of non-existence that were previously not possible.
Brevis coChain is a Proof-of-Stake (PoS) blockchain featuring on-Ethereum staking and slashing functionalities. It accepts coprocessing requests from smart contracts and “optimistically” generates coprocessing results through PoS consensus. These PoS-generated results are submitted to blockchains as “proposals” that are subject to be “challenged” via Zero-Knowledge (ZK) proofs. Successful ZK-proof challenges will trigger the slashing of the corresponding validators’ stakes directly on Ethereum. If no challenge is initiated, the results can be used by dApps directly without incurring ZK proof generation costs. Additionally, Brevis coChain is set to integrate with EigenLayer, empowering developers to dynamically adjust the level of crypto-economics security used in the proposal stage. This fusion of crypto-economics and ZK proofs not only ensures the secure and trustless nature of Brevis but also provides developers with a versatile tradeoff space to explore so they can design according to their specific use case.
Also as an important note, developers will be able to seamlessly integrate with Brevis coChain with no extra effort required. By leveraging the Brevis SDK 2.0, they only need to write their application’s business logic once. Then, they have the flexibility to deploy their applications in either the “pure-ZK” model or the coChain model.
The “Pure-ZK” model is not a one-size-fits-all solution
As a quick review, Brevis is a Zero-Knowledge (ZK) coprocessor, enabling smart contracts to access and use the comprehensive historical on-chain data from any blockchain in a completely trustless way. With Brevis, developers are able to create a wide array of data-driven decentralized finance (DeFi) applications and other exciting projects.
Prior to the creation of Brevis coChain, Brevis exclusively operated using a “pure-ZK” model. In this model, ZK proofs for data access and computation results are always generated upfront. Smart contract applications could utilize these results only after the on-chain verification of the ZK proofs.
While the pure-ZK model provides simplicity and a trustless framework to work from, it is not without its own set of drawbacks:
- High Proof Generation Costs and Limited Scalability: While Brevis delivers world-leading performance in ZK Coprocessing, and we are confident in the innovations of ZK performance optimization, we must acknowledge the fundamental computational overhead introduced by ZK at this current stage. The costs of ZK proof generation and the resulting delays still present challenges. These costs ultimately contribute to a suboptimal user experience and act as barriers to the widespread adoption of data-driven dApps.
- Inability to Generate Proofs for Some Key Use Cases: Within the pure-ZK model, it is extremely challenging to generate proofs of non-existence. As an example, proving that a user did not engage in a transaction with a specific protocol using ZK is very difficult to do. It would require a comprehensive ZK proof encompassing every transaction across all historical blocks—a feat that is practically infeasible. However, non-existence proofs can be utilized in important use cases such as new user acquisition, identity, account abstraction and compliance.
These limitations, if left unaddressed, render ZK Coprocessors impractical for numerous high-value applications, especially those involving substantially large amounts of data and users, where maintaining a minimal cost per user is crucial.
To help address these challenges, we created a “propose-challenge” architecture that significantly reduces costs and broadens the scope of applications that can be integrated into the ZK Coprocessor framework. In this model, a proposer can generate and submit coprocessing results on-chain without completing the entire ZK proof computation. Following the initial proposal, a challenge time window defined by the developer begins. During this period, any observer on the chain can initiate a challenge by submitting a ZK proof that contradicts the initial claim. Successful challenges result in penalties for the proposer and the challenger receives a reward. Conversely, if no challenges emerge during this window, the application considers the results valid.
Brevis coChain: How does it work?
Building on these high-level concepts, let’s dive into a more detailed system design with a focus on a few key nuances.
We now introduce Brevis coChain as the proposer within the architecture.
The coChain Architecture
Brevis coChain is a specialized Proof-of-Stake (PoS) blockchain, incorporating on-Ethereum staking and slashing capabilities. Upon receiving a coprocessing request, individual validators within Brevis coChain generate coprocessing results based on raw data extracted from the corresponding blockchain’s archive nodes. After achieving PoS consensus among validators, Brevis coChain pushes the results, along with the aggregated quorum signatures, to the requesting blockchain in the form of a proposal.
The proposal initiates two timers: an application-specified challenge window and a coChain slashing window. The application challenge window is a parameter configurable by developers and is expected to be shorter than the coChain slashing window, which is a system-wide parameter.
Within this system, anyone, including validators and developer-hosted challengers, can challenge a result by submitting a challenge claim along with a monetary bond on-chain. Please note that challengers are not required to present their challenge ZK proof to submit a challenge claim, but only need to declare the start of the challenge process on-chain should they detect any invalid result. Therefore, the application challenge window does not need to accommodate the time required to generate the challenge ZK proof and can generally be kept short.
PoS Result Challenged
Once the challenge process is initiated, a proof submission window, as requested by the challenger, will begin. The longer the requested proof submission window, the higher the challenge bond will need to be.
A successful challenge triggers an on-chain slashing contract, penalizing malicious validators and rewarding the challenger. If a challenge fails, either due to a timeout of the proof submission window or by receiving a proof that does not meet the correctness requirements, it will result in the forfeiture of the challenger’s bond.
Brevis coChain offers robust decentralization and resistance to censorship, presenting a significant advantage over single-proposer solutions. Furthermore, it provides developers with a diverse and broad spectrum of trade-offs by enabling them to customize the challenge delay and the crypto-economic security level for each application.
Developers even have the option to use Brevis coChain without implementing a challenge period. This approach is particularly suited for lower-stake scenarios like validating a user’s loyalty status. It offers a cost-effective solution with minimal latency, catering to situations where the challenge mechanism may not be necessary.
So in the case of a zero challenge period, isn’t the security level of Brevis reduced to just PoS security?
Well, not exactly.
It is important to highlight that Brevis coChain’s slashing window is a system-wide parameter spanning multiple days. This means that even if an application has accepted a faulty result, as long as the slashing window has not expired, malicious validators can be slashed and incorrect results can be rectified.
PoS Result Unchallenged
This decoupling between the app-level challenge window and the coChain-level slashing delay provides developers with the flexibility to adopt a “better-late-than-never” design pattern. In this framework, incorrect coprocessing results can be rectified during the slashing window via ZK challenges, thereby minimizing their impact on the application.
Let’s walk through an example using a Uniswap v4 hook that dynamically adjusts trading fees based on a trader’s past trading volume. Let’s say the developer chose not to set a challenge delay in this instance. In this example, if more than ⅔ of coChain validators maliciously submit a higher VIP tier for specific users to a “VIP tier lookup table” connected to the dynamic fee hook, some users may initially get higher fee discounts. However, when a ZK proof proving that the VIP tiers are not the intended ones, is submitted during the slashing window, malicious validators will be slashed and the incorrect VIP tiers can be corrected to the intended ones by allowing the challenge callback to update the VIP tier lookup table.
For more cautious use cases, developers have the option to implement extended application-level challenge windows, offering an added layer of security and flexibility.
So how long should these windows be?
Unlike the seven-day delay typical in optimistic rollups, a conservative challenge window for Brevis coChain only needs to be around 30 minutes. This timeframe takes into consideration the time required to recompute coprocessing results without ZK proofs and to initiate the challenge on-chain.
Does this imply that Brevis coChain always experiences higher latency than the Brevis pure-ZK model due to the challenge window? Not necessarily.
In scenarios involving extensive on-chain data and complex computations, the latency introduced by generation of a ZK proof can be significant. As highlighted earlier, the challenge window for Brevis coChain only needs to account for the detection, rather than proof, of faulty results. So it can be considerably shorter than the total time needed for ZK proof computation. In many cases, Brevis coChain can actually achieve lower latency overall.
A notable example to illustrate this latency improvement in Brevis coChain is in the case of the non-existence proof. Pure-ZK computation for a non-existence proof is impractically time-consuming due to the necessity of traversing all relevant historical data.On the other hand, to challenge a non-existence proof requires only a single existence detection, allowing for a much shorter challenge window. During the challenge submission window, a simple ZK existence proof can be swiftly generated. It is in situations like this that Brevis coChain can offer better latency than the pure-ZK model, even after factoring in the entire proof generation process.
Brevis coChain currently uses Ethereum as the data availability (DA) layer for coprocessing requests, ensuring that the original requests are highly available for challengers to access. However, there are plans to incorporate a dedicated DA solution in the future.
Furthermore, Brevis coChain leverages EigenLayer’s restaking infrastructure. This provides developers the option to enlist more validators for Brevis coChain or designate them as dedicated challengers, allowing them to adjust the crypto-economic level to further reduce the application-level challenge window, enhancing overall user experience.
In conclusion, ZK Coprocessors have a wide array of use cases, each involving distinct trade-offs. Brevis coChain is purposefully designed to expand and broaden the available trade-off options and enable developers to find their ideal balance between latency and crypto-economic security for their specific applications.
What about developer experience?
The great news for developers is that Brevis coChain offers a seamless opt-in experience, requiring just minimal adjustments through a simple configuration flag while developing data-driven dApps. The upcoming Brevis SDK 2.0 further streamlines the process, where developers only need to write their data access and computing logic once! The SDK then automatically generates the necessary circuits for both the pure-ZK model and the Brevis coChain challenge model. In the meantime, the business logic will also be deployed to Brevis coChain without any extra effort or work required from the developers.
Upon its release, Brevis SDK 2.0 will initially support only the pure-zk model. However, developers who have built their applications in the pure-zk model will be able to seamlessly switch to the Brevis coChain model later, without needing to refactor their original code. This flexibility ensures a smooth transition and a user-friendly development experience, allowing developers to easily adapt to the evolving capabilities of Brevis coChain.