Hi! Thanks for your post, it is very interesting! Although the demand for preconfirmations is clear, I would love some more clarity on how this design solves blob contention and censorship.
First, contention between blobs stems from too many blobs competing for a scarce protocol product. It is unclear to me how preconfirmations avoid contention since the protocol product is as scarce with this design as without, and bidding is also possible in-protocol.
Secondly, inclusion lists improve censorship resistance by tapping into the entropy that a decentralized validator set creates. Since proposers outsource their preconfirmation provider duties to a leader in this design, it is not clear to me that this design also taps into the entropy of the validator set. Wouldn’t the preconfirmation providers also become specialized entities, as in mev-boost?
In general, I think this design is very interesting but looks more like a parallel slot auction in which the proposer sells its rights to the preconfirmation leader. Therefore it may be more appropriate to see this not as an inclusion list but as a specific proposer commitment that is realized via a PEPC-like system. Parallel block auctions in PEPC may benefit censorship resistance, but that is because multiple parties are involved with block construction.