Sorry, what is a MEVil exactly ?
"Specifically, MEV which results in a financial incentive for miners to employ sophisticated technology in order to ensure the transactions they include in the next block have the maximal value is MEVil”.
This is neither a definition in terms of structural aspects (e.g exploiting a base-layer policy mechanism against the interest of L2 counterparties), neither a quantitative premium in terms of block template efficiency construction and neither said what is “sophisticated technology” exactly. Is applying rigorously high school integral calculus to build your block template considered as “sophisticated technology” ?
"We believe that these two issues can be addressed through the construction of a “mevpool marketplace” standard that takes the place of accelerator/private mempool services, applying PBS only for a narrow subset of transactions in a block. This enables the miner to remain the block “builder” while still allowing for end users or third-parties specialized in MEV extraction to directly bid for individual transaction inclusion. The Marketplaces will host order books containing bids with varying properties, including position within blocks, restrictions in relation to individual smart contracts, etc.”
How can you be sure that you’re receiving the block template in real-time from the marketplace operators, not even saying how do you verify builder’s block templates have not been selectively marginally downgraded in terms of feerate by weight unit ?
No proposed seal-based solutions are realistic, for the 1st one the only dry escrow mechanism is (1) old school bank’s letter of credits… and for cypherpunk trust-minized escrow (2) anything which is bitcoin-script based though any 2-phases commit protocol would have to fit in 2 transactions included in 2 blocks at least, so in 20 min in average to settle a dispute on the correctness of a data structure (i.e block-template) that can happen every 10 min in average in the worst-case.
For the 2nd one, running templating infrastructure in a thing like a TEE is the last thing I would do as in block templating it’s a latency-race as anyone who has worked on BIP152 knows it. That’s just so many more kernel context-switch due to enclave transisition that you’re better off to re-design your own commitment attestation scheme to fit bitcoin block entropy structure and get native support on enclave HW…Good luck with that.
I do not disagree on the problem, and I do think it’s an important problem.
However, I don’t think the proposed solutions are improving the problem at all, or even worsen it.