Scaling Onchain DAO Governance with Bonsai zk Coprocessor
Victor Graf
DAOs are transforming asset management with billions in treasuries. These funds are allocated to achieve each DAO's distinct mission, which is enacted by decentralized governance maintained by its members. Governance plays a crucial role in deciding actions that align with a DAO's objectives. However, it also presents challenges, such as the significant gas costs associated with on-chain voting.
High gas costs not only make voting expensive but also less inclusive, posing serious implications for the democratic nature of DAOs. DAOs today are faced with two bad options: use fully on-chain governance systems like Tally, which are accompanied by high gas costs, or use traditional off-chain systems that lack Ethereum’s verifiability.
The Bonsai Governor offers a new option for DAOs: use ZKPs to enable fully verifiable governance, without the high gas costs.
Bonsai utilizes ZK proofs to execute application logic off-chain while maintaining on-chain verification. Traditionally, using ZK proofs requires advanced cryptography expertise and extensive development efforts, but Bonsai handles these complexities by allowing developers to easily implement application logic in rust while the complex work of cryptography is handled for you. By using Bonsai as a Coprocessor, data and off-chain computation can be verified on-chain.
Bonsai Governor: A Deep Dive
The Bonsai Governor is a demonstration of how an existing smart contract’s logic can easily be moved off-chain, drastically reducing gas fees without sacrificing Ethereum’s guarantees. By starting with the well-established OpenZeppelin Governor standard, and then moving the ballot-processing logic off-chain, voting costs were reduced 66%.
The Bonsai Governor leverages the ZK coprocessor architecture, offloading expensive compute to Bonsai for execution and proving. This design simplifies the on-chain compute required for voting, especially when dealing with signed votes, since signature verification and double-voting checks can be handled off-chain.
A voting system, at its core, must prioritize two critical properties:
No Unauthorized Voting: It should be impossible for anyone to manipulate the system by casting more votes than they're authorized.
Censorship Resistance: Every voter must have confidence that their vote will be counted and not suppressed.
The OpenZeppelin Governor contract relies on Ethereum’s guarantees to achieve these two requirements, but this binds all voting to being processed and cast via pricey on-chain transactions. Bonsai allows for cheaper off-chain voting and processing without losing Ethereum’s guarantees.
Instead of verifying signatures or updating the EVM state, methods like Governor.castVote and Governor.castVoteBySig focus on logging events and updating a hash accumulator. These logs are subsequently gathered and sent to the zkVM for the finalization of votes, with results relayed back to the Bonsai Governor smart contract via the Bonsai relay.
The Bonsai Governor delivers a substantial reduction in gas costs while upholding the security features of L1 voting. In practical terms, it consumes approximately 66% less gas per vote compared to the OpenZeppelin Governor baseline. This translates into significant savings for both voters and DAOs, fostering a more inclusive voting environment. To put it in perspective, based on July 2023 gas prices, a proposal involving 1000 active voters could save anywhere from $4000 to $6000 per proposal.
As DAOs continue to reshape our financial landscape, tools like this will be pivotal in ensuring their democratic ethos remains intact.
Exploring the Codebase
Bonsai is minimizing the complexity of building with ZK. Using Bonsai allows you to leverage a highly performant and horizontally scaled proving system, without writing circuits or managing hardware.
At the top of the file, we see a huge benefit of building with the zkVM: rather than having to build circuits for each of the primitives we need, we can simply import the crates for k256, ecdsa, and keccak.
Read and Process Inputs
The main() function starts by using env::stdin() to read the inputs, which are organized into a 32-byte proposal ID followed by a 100-byte chunk for each vote.
For each vote, the guest program will (verifiably) reconstruct the ballot box hash accumulator value, and record the vote.
The journal of the resulting receipt will contain the proposal_id and the results of the voting.
This general structure applies to most zkVM applications. The guest program typically just needs to:
read some inputs
compute some logic
commit some outputs
To learn more about writing applications for Bonsai & the zkVM, check out our dev docs site.
Looking Forward
As DAOs continue to reshape our financial landscape, tools like this will be pivotal in ensuring their democratic ethos remains intact. If you’re Interested in exploring further - dive into the example in Github and discuss with the team in Discord!
