Really nicely outlined, Terence and Potuz!
I like the fact that, as described, ILs are strictly enforced and don’t come with escape hatches for proposers, e.g. stuffing up blocks.
One aspect I’m uncertain about is the incentive compatibility for proposers.
Desiderata 1:
We want to encourage proposers to fill entries in their ILs based on economic incentives instead of altruism.
The dedicated IL gas limit is a great fit for that. It can provide additional, only-non-censoring-parties-are-allowed-to-tap-in space within a block to compensate economically rational proposers for filling up ILs.
Desiderata 2:
A proposer with a full block and a filled-up IL (many entries, up to the limit) should have an economically advantageous position compared to a proposer not putting anything on the IL.
The IL, then acts as a little “bonus” (IL bonus) for the next proposer. In other words one could say that proposers are allowed to build bigger blocks than usual, only if they fulfill the wish of the previous proposer. Thus, proposers may seek to always include those transactions and rake in the money.
But who gets the bonus?
Now, by agreeing that the block gas limit bonus advantages the next proposer, allowing them to construct a larger block and gain from the additional gas released through the IL transactions, we encourage collusion between proposer n+1 and n .
- The proposer in
n+1will want to get an IL close toMAX_GAS_PER_INCLUSION_LISTin order to maximally benefit from the IL bonus. - The proposer in
nhas no incentive to put anything on the ILs.
Ideally, we would want the entity building the IL to also profit from it. This could either work by having side-channels where proposers fill up the ILs for the next for some compensation, or by somehow directing the IL bonus to go to the proposer that built it. This then comes with incentives for proposers to put transactions on the IL that are not yet included in their blocks, allowing them to tap into the IL bonus.
This could be realized by having a fee_recipient field in the InclusionList to indicate the recipient of the IL gas fees (IL bonus).
So, we could have a payment to the proposer of slot n, triggered by the proposer of slot n+1 including all entries on the IL.
Does this make sense?
From a censorship perspective this comes with clear disadvantages because no economically rational slot n proposer would ever risk putting a sanctioned tx on its IL, risking that the next proposer misses the slot n+1 leaving the proposer in slot n without the IL bonus. Thus, there might be an incentive to fill up the IL with transactions that are not threatened to be forcibly discarded (obeying the sanctions) by the next proposer.
Large entities
Getting back to your described design. Large parties with consecutive slots would be incentivized to build full IL for their own next proposer, excluding transactions from sanctioned entities and thereby enabling to access the full set of builders. As soon as these large entities see that the next proposer isn’t they themselves, they’d leave the IL empty.
The reality that proposers of consecutive slots can always perfectly set up slot n+1 during slot n for their own benefit introduces centralizing tendencies. We need ways to enable proposers to impose constraints on any arbitrary proposers in the close future, in order to dismantle this “consecutive proposer shield”.
Summarizing
| NO Free DA | IL gas limit < Block gas limit | Strictly enforced (no escape hatch) | Non-expiring | |
|---|---|---|---|---|
| No Free Lunch |  |
 |
|
|
| No Free Lunch (Non-expiring) | |
|
|
|
| Dedicated Gas Limit (the above post) | |
|
|
|