At the time of publishing, MEV-Boost is run by 50%+ of Ethereum mainnet validators and trusted as a core part of the block production infrastructure.
Acknowledging the trust and responsibility, I want to propose a set of core tenets for MEV-Boost, to guide future design decisions and a responsible, open and effective R&D process.
Primary development goals:
Stability, security and performance.
Safe and reliable upgrades for proposers.
Deliberate, considerate and calm (slow) development.
Further principles and objectives:
Alignment with Ethereum ecosystem on goals and incentives.
Innovation towards builder decentralization ([1], [2], etc).
Active, thoughtful and deliberate discussion, prioritization, development and shepherding of ideas and improvements, by the community and core contributors.
Consideration towards needs of underrepresented parties (for instance solo stakers).
Note that it’s not the place of mev-boost to define the Ethereum ecosystem’s goals though; we’d seek that alignment by close coordination with, and the involvement of, ecosystem stakeholders like yourself @Micah.
Alignment with Ethereum ecosystem on goals and incentives.
In order to meet this target, I feel like MEV Boost should be looking for opportunities to break/brick Flashbots relay, Flashbots RPC, and the censoring bloxroute relay. Either by adding code that is openly malicious toworad them, or adding code that makes censoring by them not a viable business strategy, or by removing all defaults/links to choose products in the MEV Boost documentation, website, code, etc.
I’m assuming this document applies to MEV Boost only, and not to any of the other components like the relay and RPC server?
This is only about mev-boost, yeah.
In order to meet this target, I feel like MEV Boost should be looking for opportunities to break/brick Flashbots relay, Flashbots RPC, and the censoring bloxroute relay. Either by adding code that is openly malicious toworad them, or adding code that makes censoring by them not a viable business strategy, or by removing all defaults/links to choose products in the MEV Boost documentation, website, code, etc.
Thanks for your input. I’d prefer we keep this discussion to what the development philosophy of mev-boost should be, rather than how mev-boost could achieve that development philosophy. If you’d like you could open a new thread in this category on the above, though.
The “order” of these goals is important as it will determine which goals get priority when there is conflict. For example, performance is number 1 at the moment along with stability and security, but I think those should be broken out more clearly with security first, then stability, then performance last. If there is a choice that requires trading either security or performance, then performance should almost always get trumped. Having these ordered more clearly would help make that more clear to future developers and outside contributors.
I would like to see censorship resistance as a primary target, rather than embedded in a secondary objective.
I think that “Alignment with Ethereum ecosystem on goals and incentives” is too vague as the Ethereum ecosystem includes a very broad set of people many of whom may hold differing opinions. This value drift is only going to get worse over time, and attaching to a vague set of drifting values doesn’t help provide clarity on the mission of Flashbots.
Innovation towards builder decentralization ([1] , [2], etc).
Decentralization is a means to an end, but it generally shouldn’t be a goal in and of itself. Censorship resistance is usually the actual goal and decentralization can help achieve that but I don’t think we should be targeting it as a primary objective. There are solutions to hard problems (especially in the MEV space) where centralization may actually give us better protection against censorship than decentralization when used prudently and these options should be explored. rather than avoided.