There is a lot to be said about the references you posted here, some of the analysis hinges on control over the gas limit (in the first reference it also incorrectly assumes that you can change it without changing the gas target), which is not at all a requirement of EIP-1559 anyways. To me, the most relevant flaws of EIP-1559 are the following:
- The mechanism can be defeated by (smart contract) coordination. This is pretty much true of any other mechanism, and I think the details of how this is done matter quite a bit to think through defences.
- Not giving part of the fee to the block producer (BP) mechanically lowers censorship-resistance, as the value for the BP to include a transaction is no longer equal to the fee-value of its inclusion, so a censor only needs to promise to pay the partial fee received by the BP + epsilon to convince the BP to leave out a transaction. Note that the censor would actually need to pay the partial fee + the MEV induced by the transaction + epsilon, in a fully rational model and without a mechanism for mev-capture.
- That being said, I am actually not convinced that the fee market should be the place to enforce censorship-resistance, since high CR is then predicated upon high fees, which are undesirable by construction. In an ideal world, users pay subcent fees to transact, which in this case means anyone’s tx is cheap to censor.
- The naive censorship attack also doesn’t hold when it is fully played out. Naively, a user makes the first move and it is their only move: they issue a tx that declares some priority fee PF for the BP. The censor then replies by bribing the BP to not insert the tx, against a payment of PF + epsilon. But if the user had the opportunity to move again, the user would be willing to then keep raising their PF until the total fee they paid was equal to their willingness to pay. In other words, in a fully rational model, the censor must pay the willingness to pay of the user minus the base fee to censor. WTP is assumed to be many multiples beyond the base fee in a world with low fees, so this would not significantly decrease the cost of censorship to the censor.
- The question is whether the user can make this second move (and possibly iterate until they either reach their WTP or the censor decides it’s not worth it anymore). In my opinion, if we assume a world where the per-tx bribing infrastructure is mature enough for censors to bribe BPs, we should also assume that an equivalently mature infrastructure would exist for users to reply to the bribe. (Note that per-tx bribing infrastructure is very different from per-block bribing infrastructure, which is more like PBS)
- Note also that a world where the user is always fully extorted for their surplus is a terrible world, and we better hope that there is a better solution. So if fee markets aren’t the place to resolve CR, I believe Multiplicity-style gadgets are better suited instead.
- Known proposers might give opportunities for BPs to schedule load in their favour. This has also been known for a while, but again I think the details matter quite a bit. You can schedule load ex ante but demand is not known in advance, so it might not turn out in your favour.
As you mentioned, Cosmos validators being more altruistic than Ethereum validators seems to me an argument for why these are less of a problem here, but still problems to some extent.
To EIP-1559, value extraction opportunities by validators is user demand. EIP-1559 (at least in Ethereum) doesn’t intend to price on-chain economic opportunities accurately, it merely attempts to arrive at a price for network resources which is compatible with long-term targets and short-term limits. In fact, as recent literature shows, the willingness to pay base fee is not always a good signal for the BP of whether the transaction should be included or not: a high MEV tx which carries low user fees (below what base fee requires) would induce a rational BP to subsidise the user tx so that they can include it and extract the MEV from it. Such scenarios might be good for users, which is why I suggested looking into charging base fee over the block rather than per-transaction, as is currently done in Ethereum. These scenarios lower the utility of the base fee as an oracle for inclusion (in the sense that willingness to pay basefee should highly correlate with your chances for inclusion), but here the lanes explored by Skip might allow you to discriminate between different types of demand.
It seems that the fee market question here is entangled with other questions relative to the mempool, on which I have less of an opinion, but I hope these arguments illuminate the conversation around EIP-1559, and why it may or may not be desirable in this case.