---
# System prepended metadata

title: 'Anounamous- Private Governance for NounsDao: Storage Proofs'

---

# Anounamous- Private Governance for NounsDao: Storage Proofs
<div style="text-align:center;">
  <img src="https://i.imgur.com/9tckCXx.png" alt="Storage Slots">
    <p><em><a href="https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/">Mental Model for EVM Storage Slots</a></em></p>
</div>

If you’re familiar with traditional operating systems, you might know that computers store information in “[memory addresses](https://www.techopedia.com/definition/323/memory-address)” with each address holding 8 bits (1 byte). The Ethereum Virtual Machine (EVM) emulates this with “[storage slots](https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/).” Every piece of data residing on Ethereum’s blockchain is indexed in one or more storage slots. Storage proofs, which are a superset of account proofs, can convince a verifier of the state of some variable inside an Ethereum smart contract at a given point in time. In the case of NounsDao, it means that we can convince a zero-knowledge verifier of a Nouns holder’s vote weight.

Asides from an additional step of snapshotting the account storage proof (see below), ERC721Checkpointable.sol provides us with everything we need to extract the votes a given holder can control at any given point in time. Specifically, the [`Checkpoint` struct’s `votes` field](https://github.com/nounsDAO/nouns-monorepo/blob/master/packages/nouns-contracts/contracts/base/ERC721Checkpointable.sol#L49) is the data we are targeting for Nouns storage proofs. This enables intrinsic support for delegate voting using the existing sum of votes available to a given Nouner, rather than trying to evaluate the tokens held. This requires delegation to be public; however, we understand this to be an acceptable or even desired tradeoff.


<div style="text-align:center;">
  <img src="https://i.imgur.com/V3q05JH.png" alt="Account State Roots">
    <p><em><a href="https://arxiv.org/pdf/2108.05513.pdf">Traversing the EVM to a storage slot</a></em></p>
</div>

The full traversal of the block header to the smart contract’s account state root can be documented completely with the proof of concept and, of course, be demonstrated in the codebase. Proofs can be locally verified using the rpc method [eth_getProof](https://docs.alchemy.com/reference/eth-getproof), which returns the RLP-serialized account proof (merkle proof internal sibling nodes) and similar storage proofs for the targeted storage slot(s). Multiple storage slots will need to be queried to prove the [`numCheckpoints`](https://github.com/nounsDAO/nouns-monorepo/blob/ca4dbe199e835706636776ef201ffbaecfde8774/packages/nouns-contracts/contracts/base/ERC721Checkpointable.sol#L56)  and [`checkpoints`](https://github.com/nounsDAO/nouns-monorepo/blob/ca4dbe199e835706636776ef201ffbaecfde8774/packages/nouns-contracts/contracts/base/ERC721Checkpointable.sol#L53) mappings for a given address to provably extract the latest state for a voter.

Storage proofs must [cache the account storage root](https://docs.axiom.xyz/axiom-architecture/caching-block-hashes) of the NounsToken smart contract for each block where a proposal is made. We can add a step to [`NounsDaoLogicV1.sol:propose()`](https://github.com/nounsDAO/nouns-monorepo/blob/ca4dbe199e835706636776ef201ffbaecfde8774/packages/nouns-contracts/contracts/governance/NounsDAOLogicV1.sol#L165-L267) that computes and caches the account state root. The on-chain Zero Knowledge verifier for a vote on a said proposal can then inject the account storage root as a public input to trustlessly verify that storage proofs of Nouns tokens were not forged with fake block hashes. This caching step can be thought of as a type of trustless snapshot.

We can save on gas by using optimistic zero knowledge for the cached account storage root. Anyone can easily compute, verify, and challenge the optimistically posted storage root by verifying the zero-knowledge proof. The obvious slashing mechanism would be for a proposal to require some sort of financial stake that is forfeited if fraud is proven. A sufficient safety deposit would incentivize chain watching to claim free money if a false root is posted. However, if the NounsDao does not want to require financial stake in a proposal, a temporary/ permanent ban could be made on an address that sends an invalid state root.

While a storage proof convinces a verifier that a value exists at a certain point in time in the EVM, it has no concept of proving ownership associated with that data. Thus, a Nouns holder needs to produce an ECDSA signature from the pubkey holding the vote weight. As mentioned in ECDSA, this signature can be reasonably verified inside an Aztec Noir UltraPlonk Zero Knowledge circuit.

Note: this construction was proposed to us by Aztec Network in February.
