Author: Haotian
On eth_proofs Day, Justin Drake used the zklighthouse client to live verify BrevisPico ZKVM proofs—finalizing blocks directly without re-executing transactions—and proclaimed that the Gigagas ETH era was coming.
There's no doubt that Brevis has once again been handpicked by the Ethereum Foundation. So what exactly is Brevis planning?
After reviewing their latest ProverNet white paper and demo, I found that it is indeed different from other zk solutions:
1) In general, the ZK proof market follows a single-vendor model, but Brevis found an awkward problem in the production environment: for example, Uniswap's off-chain rebate process requires ZK to provide a transparent solution, PancakeSwap's VIP fee rate requires sub-second proof checks before each transaction, and Euler Labs, which requires a certain amount of time to process the incentive allocation of more than 100,000 addresses, has throughput requirements.
Logically, different demand scenarios require completely different hardware configurations, verification system specifications, and optimization directions. If it's a single vendor, they can either perform in-depth scenario optimizations for temporary needs or offer a compromised, generic solution. This clearly makes it difficult to meet the demanding and differentiated needs of specific scenarios.
2) Brevis's ProverNet solution is quite simple: it establishes a two-sided marketplace where application developers submit their requirements, and professional provers bid to accept the orders—a TODA (Truthful Representation Double Auction) mechanism. This "market-driven" solution can naturally handle multiple heterogeneous proof types simultaneously, allowing application developers with specific needs in different scenarios to receive specialized services from the most professional and capable provers.
In fact, this can be taken a step further. For more complex tasks, different developers can break down the tasks and collaborate. For example, a zkVM proof might be handled by developer A for chunking, developer B for compression, developer C for aggregation, and developer D for final encapsulation. In short, professional division of labor and task breakdown can meet more diverse market demands.
above.
The logic is actually quite simple: it's about shifting from the old mindset of "selling shovels" to building a "marketplace," and moving from a purely centralized supplier service system to a decentralized marketplace.
The so-called Gigagas ETH era requires more than just a single tool service; it requires an infrastructure capable of orchestrating the entire network of prover.
