SmoothDAO, a governance body to tackle the vanilla proposers problem and development of Smooth
TL;DR:
- Some validators propose only vanilla blocks, extracting high MEV rewards from the pool while contributing low-reward vanilla blocks only, with no exposure to bigger blocks.
- it is impossible to prove on-chain how much ETH could have been earned in a block and what the difference is between that and what was actually earned
- The rewards distribution must be able to be resconstructable on-chain
- We can put the information we need on-chain ourselves.
- SmoothDAO would be in charge of committing information on-chain that would signal that the DAO has decided to penalize a validator
- SmoothDAO would only be governed by current smooth participants
Background
Smooth provides right now around double the amount of execution rewards per block than the median block.
This is thanks to the blocks that have a higher reward, blocks almost always built by block builders and distributed via MEV Boost. Block builders do not only use all sorts of tactics to extract value from the transactions in the mempool, but also have access to private order flow, bundles of transactions and provide higher value to almost any block, sharing part of this profit with the block proposer.
In Smooth, we have detected some users who consistently propose vanilla blocks, which indicates that they might not be utilizing MEV boost or not be subscribed to enough competitive relays.
Since vanilla blocks are usually below the median and not being subscribed to MEV Boost relays has no chance of lottery block to compensate for this imbalance, these proposers are not contributing to the pool, and are bringing everyone else’s rewards down because they always take more than they con possibly contribute without MEV Boost.
While it’s totally OK to not want to participate in the MEV ecosystem, which some consider exploitative and a negative element of the design of current blockchains, such users should also not participate in an MEV Smoothing Pool and benefit from higher profits due to MEV without contributing themselves to the pool.
A potential solution is henceforth proposed in the hopes of generating discussion as a community and figuring out the best way to go about it.
Hurdles to overcome: on-chain information
Smooth is formed by a smart contract, an oracle and a front-end.
The rewards tree is fully reconstructable on-chain. It does NOT depend on relays, which (ironically) are unreliable, specially for old data, nor 3rd party information aggregators like payload.de, which provides a level of transparency guaranteed by on-chain information, the strongest possible.
The problem with detecting differences between a vanilla block reward sent to the pool and the best MEV block that was available is that there is no information on-chain about the “potential” MEV blocks. Any relay could say “there existed a block with 5 ETH reward” and there would be no way to prove it on-chain. The only information that there is on-chain is what actually was sent to the pool and got effectively recorded on-chain. Hence, it is impossible to determine on-chain how much ETH could have been earned and what the difference is between that and what was actually earned.
Can we find a solution that can also be reconstructable on-chain?
We have seen that it is impossible to have on-chain information of the potential blocks that have not made it on-chain. But maybe we can get the oracle to look for another signal on-chain so it can be fully reconstructed by anyone and hence completely transparent.
If the information is not onchain, one solution would be that we put the information we need to take any desired action onchain ourselves.
Now, in order to avoid using this mechanism for nefarious purpose, we would need to define who has legitimacy enough so we can trust whatever is put on-chain. If we don’t want to depend on 3rd parties, we need to put this information on-chain ourselves.
The legitimacy of such information, if it cannot be programmatic, must be social: we as a consensus must decide that the information we receive from 3rd parties about the potential earnings of the block is valid and must decide to commit it online.
SmoothDAO
SmoothDAO is composed by all Smooth participants. It has the potential to vote in the accepted rules of participation in Smooth and effectively ban from Smooth the validators who break these rules.
Practically, I envision SmoothDAO as follows:
- We mint a Smooth token (non-transferrable, to avoid people buying votes) to Smooth participants
- We decide on the rules of participation on Smooth (for example, one rule could be 3 vanilla blocks in a row and you’re out - more detailed information on this below)
- We keep track of the infringements of the rules in a forum post in here (because the information comes from off-chain, 3rd parties, it must be verifiable socially by looking at links that are socially regarded to be trustworthy)
- Once the ban conditions are met, a vote to ban a specific validator is triggered. The passing of this vote results in an on-chain call function that is picked up by the oracle and the decided penalty is applied.
Discussion points
Voting power allocation
Smooth is formed by stakers with varying weights of interest. Some have hundreds of validators, others only one. Some are willing to invest time in the management and optimization of the rewards received by smooth, some others are happy to let it run on its own.
I suggest distributing tokens based on rewards received. This makes sure that people that have been a long time in the pool have more power than recent joiners, and also that people that have more validators also get more voting power, according to their economic interest.
Voting power should be revoked when validators leave the pool.
Alternatives and why I don’t like them:
- 1 withdrawal address = 1 vote: it doesn’t take into account that some withdrawal addresses have more economic interest than others
- 1 validator = 1 vote: It doesn’t take into account the time factor and creates opportunities of attack: someone with lots of validators could register to the pool, vote, and leave the pool.
Penalties
What are the penalties applied and what is the threshold from which the penalties apply?
I suggest applying a ban from the pool per validator (as opposed to per withdrawal address) and apply this ban at 3 vanilla blocks in a row.
I don’t have a strong opinion on this and would love to see feedback here.
Policy / Terms of use
SmoothDAO would govern the terms of use of the pool. In order to avoid arbitrary votes, the rules of engagement should be clear. A policy document should be approved by the DAO.
An example of such rules can be found here: Lido on Ethereum Block Proposer Rewards Policy - HackMD
Infringement of rules reporting
The way I see it, there would be a bot/script keeping track of the difference between the vanilla blocks proposed and checking whether there was an MEV Boost block. If such difference was of more than 10% of the submitted execution reward, a forum post would be created with the information from the sources (relays, payload.de, etc.) that have been decided to be reliable by the DAO.
Each validator would have their own thread of infringements and when the conditions for the penalty are met, a DAO vote would be triggered to signal the penalty on-chain.
All voters could then check in the thread whether the penalty is justified and verify the source of data. This step is what gives the vote the legitimacy to be accepted and where edge cases are brought up and discussed.
Additional considerations
- We could also give the DAO a budget to manage research on MEV, establish partnerships or do marketing activities to increase the amount of validators in the pool and increase exposure to lottery blocks. Dappnode is more than happy to lower the fee to 5% and send 2% to the DAO for the DAO to manage. Votes to spend this budget should be proposed by its members and passed by the DAO.
