The more I think about this, the more I am convinced that inclusion lists would be a terrible addition to the Ethereum ecosystem. We should be careful not to force it in just because it was on the roadmap and just because work was put into the idea.
I strongly feel that inclusion lists would rarely see actual anticensorship use. If implemented, what is going to happen is that shared sequencing systems will turn these inclusion lists into preconfirmations and profit from that. terence briefly alluded to this in the video. Think about it: validators have no rational incentive to include censored transactions in their inclusion lists. Rational validators must sell this block space. Worse, validators who don’t want to participate in shared sequencing or MEV will have their blocks walked all over by the previous validator who takes the profit from them, encouraging validator centralization and increasing their sophistication requirements to remain competitive. Also, the problem of validators “sabotaging” the next one’s profits still hasn’t been addressed: Spec'ing out Forward Inclusion-List w/ Dedicated Gas Limits - #3 by terence - Block proposer - Ethereum Research. Ironically, inclusion lists become a censorship tool in this case.
There is too much additional complexity in this proposal (another gossip protocol??) for something that affects Ethereum users “basically not at all” according to franceso in the video (https://youtu.be/oRjG0RMnK5U?t=2778). Censored users can just increase their priority fee, and non-censoring builders can hold onto the censored transactions until one of their blocks gets included. EIP-1559 naturally makes blocks that include censored transactions eventually profitable over blocks that censor them.
Further, there are myriad ways for censorship to remain. If in this model, block builders have so much control over the network, then what’s to stop them from denying block-building services to validators who have a history of creating transaction inclusion lists that conflict with their censorship policy. Then validators would decide not to include censored transactions in their inclusion lists, defeating the whole purpose of them. This proposal makes it seem like block builders have this much control.
The “95% of blocks produced by a single builder” statistic might sound shocking, but there’s no protocol risk to that. I will reiterate my bid against inclusion lists - too much complexity, and another network protocol, for something with little effect, for which competitive transaction pricing and a little bit of waiting fix the issue already, today.
@poojaranjan, as you asked at the end of the video, these are my comments.