With voting currently being a signaling mechanism I’m floating the idea of using gasless voting.
In such a design the cost of voting would be significantly less then the current on-chain mechanism and should bring in more participation from YFI holders assuming YIP-10 passes.
In the simplest form it could involve taking the current voting UI and instead of submitting a vote to the chain, it could be sent to a chat room or discussion thread as a signed messages. The votes can then be validated by anyone and individual multisig holders would be able to use the same tool to determine the outcome of a vote.
Using Fraud Proofs:
A step up from that in complexity could be when a voting period ends there is a tabulation period (ie: 24 hours) in which anyone can aggregate all the votes into a merkle proof and submit the root hash for the vote along with the vote FORs and AGINSTs. If the submitter has misrepresented the vote outcome in the submission, anyone can submit a the full merkle proof to nullify the submission and a slashing mechanism can be implemented here as well. A ZK fraud proof can be used here as well. Such a design could work with onchain consequences where at the end of the tabulation period a transaction gets executed.
Using Validity Proofs:
In this design only valid proofs can be submitted to the contract which eliminates the need for the tabulation period above. Given that staking is linked to the voting contract this design maybe possible.
If there is enough interest we can research further to determine feasibility of the different approaches and as a starting point building a prototype soft consensus polling that could be used in before voting to determine interest and likely outcome of proposed votes.
I am strongly AGAINST this. Voting should be done on chain for transparency. If you want to vote, pay the gas costs. It has not been a problem thus far, and while it is important to be inclusive, gas costs will not matter when significant voting blocks are in action.
Do not fix what is not broken.
Of course contracts should be optimized to minimize gas costs. You are already getting rewarded by staking your YFI in the governance pool. Don’t get greedy.
With that logic why not store the YIP information on chain so it’s visible on the proposal vote? Using the same logic the transaction to execute should be stored along with the proposal and executed or denied when the vote ends.
Instead a message board is used for YIP descriptions and a multisig takes the outcome and creates a transaction.
I agree there should be a permanent record of the votes for transparency but there are other decentralized mediums better suited for data storage such as IPFS. Storing the votes in such a medium and a root hash onchain will allow anyone to verify that those are all the ballots cast of a vote.
I was suggesting to consider using it first for soft consensus polling on what should actually get moved to a vote as a way to try it without disrupting the current process.
Also, gas costs for voting introduce an interesting and valuable game theory element to governance via quoroms.
If people propose some garbage on chain, then nobody will vote because there is a gas cost for doing so. Having a gas cost for voting ensures that people will only vote for things they really care about. Thus, the quorom concept has a financial implication.
Even though the gas cost to vote is low, it is still enough to disincentivize spam voting.
Hi hc.link
In voting, sometimes full transparency is not the best thing. Why?
If someone can confirm how someone else voted, then it enables an opportunity for bribery. i.e I’ll pay you x if you vote y.
If they cannot see how someone voted then they cannot be bribed easily, because the voter could be bribed, but they could vote whatever way they like.
So ideally, the best system would be if we could verify that someone voted, but not see their vote.
Gassless voting would be a step in the right direction.
@napoleon I think this is highly unlikely. The tokens have been decentralised in a very robust fashion, so even at current relatively small market cap, I don’t think it would be possible to influence the outcome of a proposition in this fashion.
This does seem like a tragedy of the commons type problem because the main chain has limited transactional throughput capacity and once that capacity is hit some transactions will not make it in to a block and die in the mempool.
If the only users of the Ethereum are Yearn stakeholders and transactional capacity is hit then Yearn stakeholders will start to crowd out other stakeholders by bidding up gas fees and I’ll concede there might be an argument for this being a filtering mechanism so that high conviction votes get in but it also could just mean to whales where the extra cost is marginal to them will only end up voting. ie: The cost of paying $100 in gas is marginal when you have $1mm in YFI but significant to $1,000 YFI holder.
This contrived scenario above is not the reality. The reality is more perverse. YFI stakeholders not only compete with each other to vote but with users of other protocols running on Ethereum. To now say a vote paying high gas is a signaling mechanism is to say that a YFI vote is more or less valuable than a MakerDAO vote or a Compound vote or even a Cryptokitty hatching or any of the other various types of transactions being done.
The flipside is that if these different protocols can start to offload voting from the main chain than the stakeholders of all these protocols collectively benefit.
I’d like to see delegated voting supported, I think it’ll take a little bit of the pressure off.
It would let users both batch votes up, as well as have that process done during times of lower gas fees.
Use lightweight on-chain polling which only emits events that are later tallied off-chain. We can have the result pre-computed via thegraph or fall back to in-browser tallying if it’s unavailable.
Collect signatures and batch relay them. Someone has to pay for putting them on-chain and it’s susceptible to censorship on the relayer’s side.
While off-chain voting is controversial, an easy way to move at least some of the votes off-chain is to create UI that matches opposers and supporters off-chain.
Before you vote on-chain and pay the gas, you look for token holders with the opposite vote on this UI. Once found, the tool verifies signatures and creates a match. Now both sides don’t vote on-chain and cancel each other. If your counter-party decides to vote on-chain eventually you get notified so you can vote on-chain as well.
