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.
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:
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.
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 core of a Bonsai application is a Solidity contract and a zkVM guest program. Let's take a deeper dive into the guest program in methods/guest/src/bin/finalize_votes.rs, where you'll uncover the full zkVM program definition.
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.
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 main() function ends by committing the public outputs, using env::commit_slice().
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:
To learn more about writing applications for Bonsai & the zkVM, check out our dev docs site.
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!
