Further Work
===

What follows are some ideas of future lines of work to explore after the execution of this proposal:

### Discrete weighed voting

Producing weighted proofs for >1 fixed amounts of tokens (e.g. 2, 5, 10 tokens) for voter accounts holding multiple tokens.

### Native multisig support

At present, the proposal supports multisig voting only indirectly via delegation. Given the time constrains of the project (3 months) and that apparently there are no technical challenges to include explicit multi-sig support we decided not to address this issue so that we can devote our efforts to other areas.

Technically speaking, one potential area of exploration is for a multisig representative to collect ECDSA signed votes from other signers from the same multisig, then generates a proof that verifies the signatures and votes on behalf of the multsig.

### Ballot batching

Exploring aggregation of several votes into one for gas savings. One potential challenge could be on managing nullifiers.

### Relay / Time-lapse services: Enhanced decentralisation

Extending the number of participants & contributing nodes.

### Private gas payment

When submitting an anonymous vote, the transaction cannot come from an account linked to the voter. Paying the gas costs for this transaction is nontrivial unless the vote organiser subsidises costs and acts as a relayer.

Potential areas to explore include:

#### ZK MEV bounty

Attract frontrunners to submit votes on behalf of voters using precommitted bounties locked on-chain.

1. Voters must, ahead of time, fund the voting contract by sending it a fixed amount of ETH, enough to cover the costs of 1 vote plus a relayer fee
2. As part of the funding transaction, `hash(secret)` is committed to by the voter and is stored on the smart contract (i.e. locking the bounty on-chain)
3. The voting circuit uses a storage proof to prove the existence of the above hash. `secret` is provided as a private input to validate the Prover can spend the deposited ETH (i.e. capable of unlocking the bounty)
4. The voting circuit computes a nullifier of the secret preimage (e.g. `nullifier = hash(secret, salt)`), which is assigned to a public input to the voting circuit
5. When the voting contract validates the ZKP, it also validates the provided `nullifier` does *not* exist in a mapping it uses to log nullifiers
6. If the voting proof is valid, the voting contract stores the produced `nullifier` and liberates the fixed amount of ETH and sends it to `msg.sender` (i.e. whomever managed to frontrun the voting transaction)

Prior to EIP-1159 it would have been possible to send the voting transaction from a dummy address with 0 gas. Arbitrage bots would have seen the transaction in the tx pool and front-run it to recover the Eth payment. However post EIP-1159 such 0-gas transactions will be ejected from the tx pool by Ethereum nodes.

Post EIP-1159, a dedicated relayer network is required to broadcast these voting transactions; this mechanism provides a way to automatically pay the relayer on-chain without additional coordination requirements.

#### Dummy / Ephemeral voting account

While it is not possible to send a 0-gas transaction, it is possible to send a >0-gas transaction from an ephemeral address with 0 balance.

Using special builders like [builder0x69](https://medium.com/@builder0x69/50-000-blocks-and-small-new-feature-31b1d67f6fb9), these transactions can be included in a bundle as shown below:


The voting bounty / fee payment will be collected directly by the builder (instead of by the `msg.sender` in the _private MEV bounty_ approach), and the ephemeral account will be the "voter" on chain.