Thanks for the thoughtful questions @ryanb!
Q1: I believe where our thinking might differ from yours is that we don’t expect the current market structure to hold because of two key centralization risks: cross-domain MEV and exclusive orderflow. While crLists, enshrined PBS, etc can address some of the degenerate cases of the MEV market structure today, it doesn’t address these risks. Cross-domain MEV in particular touches the actual validator set instead of just the builder market, and exclusive orderflow is a threat even with local block building. These issues need to be addressed head on, unfortunately, and they are existential threats to the decentralization of crypto.
Q2a: We want SUAVE to be maximally ETH aligned. A part of that is using the EVM as the way that preferences are expressed in SUAVE, which has the added benefit of being a “language” that searchers/builder/validators already have experience with, and which there is a lot of tooling around already.
Another thing to be mindful of is that we want SUAVE to provide an environment for preferences that is universal, which is to say that you should be able to express any preference and have it executed for you. As a part of that you need a very expressive language and computing environment for preference expression, which was another reason we’ve used the EVM.
In case you’re interested, there are folks inside of Flashbots on the research side who are arguing that we need to limit the expressivity of the language that can be used for preferences. The argument is that this is needed to minimize MEV. Personally I think it’s too early to make product decisions on this research, but it is interesting, and possible that we end up with something like “EVM–”, which is to say using a more restricted version of the EVM.
Finally, while SUAVE Chain is an EVM fork we have no intention or desire for SUAVE Chain to rival any smart contract platform. We want it to be exclusively used as a chain for sequencing and preference expression/execution. I don’t think this can be “enforced” given the goal of also being a universal environment for preferences, but if there is a way to enforce then I think we’d be open to it.
Q2b: MEV on SUAVE is an open area for research, and using SUAVE to handle SUAVE MEV is very difficult to reason about (at least personally). But, SUAVE Chain is optimized for MEV in a way that Ethereum is not. In practice this means that there is a new transaction type (it looks and acts a lot like bundles do) and its fees are much lower than Ethereum’s. The new transaction type is necessary to decentralize our builder by providing a decentralized way to pass preferences (think bundles), and the lower fees are necessary for the economics to make sense. We’re exploring other optimizations too. Moreover, a lot of what SUAVE (including and greater than the chain) does would be out of protocol for ETH, e.g. running an auction for orderflow.
Q3: It’s a little nuanced. For some parts of SUAVE the answer is “not at all dependent on oracles or bridges.” If you want to use SUAVE Chain for preference expression and settlement though, oracles are important, and you do need to bridge some funds. We’re very aware of the risk this introduces and are exploring ways of mitigating that, e.g. how we can trustlessly get data from ETH L1 onto SUAVE.
Q4: There aren’t any protocol level changes required to support SUAVE. SUAVE would work with Ethereum as it is today; and there would be no enshrined dependencies on SUAVE. There can be multiple competing SUAVEs or SUAVE like systems.