Hello ariard, thank you for your comments.
Sorry, what is a MEVil exactly ?
For some further specificity, please refer to the mevpool writeup linked in the OP:
Instead of consensus-computable variables (fees, weight, sigops) being the sole data required for block templating, they become a subset. Miners would require in-house financial engineers capable of analyzing on-chain contracts and designing and deploying value extraction schemes.
You might also find further understanding by studying the MEV vectors available across the Ethereum ecosystem which are fairly well documented. But more generally you can think of MEVil, distinct from pure MEV (e.g. RBF), as transaction sequencing that relies on generalized financial sophistication (i.e. what you might find at a HFT firm with quants), domain-specific understandings of smart contracts on the Bitcoin blockchain, as well as access to significant liquidity to take advantage of MEVil opportunities.
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.
Unlike Intel SGX, modern TEEs (e.g. TDX) are near-native guest performance so the latency issue described is negligible. There is some research available on this, an example of which you might find here: An Experimental Evaluation of TEE technology Evolution: Benchmarking Transparent Approaches based on SGX, SEV, and TDX
How can you be sure that you’re receiving the block template in real-time from the marketplace operators
Yes this is a significant hurdle to Proposal One, and thus in our opinion it is sub-optimal. That said, if the Marketplace’s payout depend on the block being accepted by the network, you might assume the incentives are aligned to ensure quick delivery.