Unconditional inclusion lists

Proof-of-Stake Block proposer
22

Thanks for the response Mike, I can appreciate your counter angle.

Why do you think competition won’t increase? Running a relay atm is basically a free service, there are no economic incentives to enter the market, especially since (as you mentioned) the current relays are offering rather competitive services.

To add to that question, in the early ePBS concepts being proposed, is there a meaningful economic incentive to be builder? My assumption was that there will be, but if that’s not the case then I would fully agree with you.

I personally don’t think any level of censorship is acceptable. With that said, this particular form of censorship imo is less an issue of censorship than a philosophical pricing of risk by block builders.

The censorship in question is really more a case of builders thinking that a lack of an arbitrary incentive for creating a block is not enough to cover the risk of processing those txs.

I have no data to back this up but something tells me if the censored users were to increase priority fees (or increase slippage for a swap, etc) by a meaningful amount, some bock producer would pick up their txs and include it expeditiously by potentially bypassing the mempool/relays all together.

I think it’s quite difficult to enforce, what some builders would likely consider, a set price of risk (via ILs) for processing certain txs. Social layer economics are a non-trivial aspect of our society and they’re the primary reason why certain goods and services are more expensive in some countries vs others.

eg) Alcohol is much more expensive in middle east countries where it’s banned than in Europe/North America. Conversely alchohol in certain canadian jurisdictions is also more expensive due to government monopolies on the ability to sell liquor, leading to an uncompetitive market which ultimately over prices alcohol compared to most places in the first world.

Ultimately I think the concentration of relays makes for an environment where the risk of not censoring is priced too high and creates an environment which indirectly incentivizes censorship. Counteracting these effects requires more than a change in spec imo (which can easily be ignored). It really requires a fundamental change in the incentives to run a relay/be a builder, which equates to better competition.

I may need to brush up on what a post ePBS landscape looks like, but something tells me as long as builders (relays) have some economic incentive to participate, that competition is all but guaranteed to increase among actors. Especially considering the fact that there are like 3 relays atm. I just don’t see how it could possibly get more concentrated in the presence of incentives where it currently lacks.

To sum things up, I really wonder if the combination of the two points I made about lack of competition and the fair pricing of risk, will result in any meaningful change even in the face of ILs in a pre-ePBS world.

2 Likes
23

Does this proposal simplify down to the following?
“Give extra block space at the end of the block to people who pay a fee. This extra space is expected to increase the cost of censorship in the environment of an altruistic minority”

Does the reason it increases the cost of censorship simplify down to the following?
“We can weakly identify the censored user type and act upon it to help them. This can be accomplished by adding the ability to costly signal using an additional fee and worse transaction ordering. Then the protocol can safely act upon that signal within reason. For example it may grant additional unconditional block space to completely eliminate the opportunity cost of altruism in the face of out-of-protocol incentives.”

3 Likes
24

I’m not sure I agree that the two versions are equivalent. If you increase the gas limit to include extra IL transactions then you are increasing the throughput of the chain (there is on average more gas available) whereas if you use the IL only to ensure that the selected transactions are included by block n+1 at the latest then you are not reducing anything except the freedom of builders to to exclude those transactions.

Possibly I’ve misunderstood part of this proposal but it is not clear to me why a separate “IL gas limit” is required at all. If the IL is bounded by the same gas limit as the block (but does not itself ‘consume’ any gas), we can guarantee that any transaction that makes it onto the IL will be included in block n or block n+1. Sure, when there are sudden spikes in demand (i.e. when several consecutive blocks are full) the IL then brings an element of MEV back to the proposer. However my guess is that is a very small proportion of the time, and that most (all?) of that MEV would be capturable simply by including the highest paying transactions, rather than requiring sophisticated arb optimisations etc. - so would not necessarily lead to any centralisation or outsourcing of the IL.

25

IIUC, the idea proposed by imkharn would be to have say block 30M gas limit (15M target) that is filled like normal where each transaction has to pay baseFee to the protocol, and then perhaps another 5M on top of that at 2x base fee which can be filled by the proposer rather than the builder.

99%+ of the time builders can fit everything into the 30M gas cap (because it is almost never reached) so they have no incentive to want access to the 5M extension where transactions have to pay 2*baseFee, so presumably proposers wouldn’t bother outsourcing this space to them because they just lose on priority fee compared to including it in the regularly priced main blockspace. This allows proposers to include some transactions that they suspect the builder may leave out, but which have a sufficiently high maxFee set so as to fit into the extension space.

If a transaction makes it into the main blockspace (no censorship), then it would just be skipped if it later showed up in the extension space.

26

Ok but why not just have the proposer just construct a prototype block with the full gas limit (but with a min basefee of basefee+12.5%). Meanwhile the builder constructs the actual block for slot n, and any transactions which are in the prototype block but omitted from the builder block must be included in block n+1 instead?

I just don’t understand why we need a special IL gas limit at all, since all IL transactions are guaranteed to be included within one slot anyway and therefore are guaranteed to pay their gas fees (i.e. there is no new DOS vector or free DA).

1 Like
27

No incentive beyond getting to build the block! In the ePBS designs so far the enshrinement of the auction mechanism doesn’t directly reward the builders beyond giving them a protocolized way to participate in the auction to buy blocks.

Right, I think if the premise here is that builder competition would be good news for CR (which I agree with), then I haven’t seen a compelling reason to believe builder competition is going to increase. Currently the most successful builders are either directly running CEX-DEX arb or working closely with searchers who are. That doesn’t feel like it’ll go away with any version of ePBS.

For latest research on ePBS, check out ePBS – the infinite buffet - HackMD!

2 Likes
28

I don’t see where the “costly signal using an additional fee” part comes in. B/c of 1559, so long as the transaction pays the appropriate base fee and there was remaining gas in the previous block, it’s safe to assume it was actively being censored.

I like this phrasing! Making opportunity cost of altruism approach zero by giving some agency back to the proposer.

29

I don’t see the need for the 2x base fee!

30

What i meant when i describe it as “reducing blockspace” is probably better phrased as “constraining builders”. For example, consider a situation where there is 35mm gas worth of txns that are paying the base fee for a slot and tipping 2X ETH, now imagine the situation where the IL for the previous slot can be the full 30mm ETH the IL is full of txns that only tip X ETH. Then the full block has to be filled with the IL txns and the proposer misses out on X ETH. So the builder would be fully constrained in that all they could do is reorder the transactions in the IL to extract whatever MEV they can. I find the blockspace extension to be slightly cleaner, but i think this is a design parameter that is still up for consideration honestly!

1 Like
31

What’s the problem you see arising from that situation? If the builder is constrained to reordering only as a result of a full IL from the previous slot then that sucks for them (indeed under such circumstances block building might not be profitable and therefore the proposer might need to submit a local block) but so what?

Similarly in your example of a proposer missing out on some tips because demand for block space has risen even further since the last block. What’s the problem? In that rare situation then yes the proposer misses out on some fee revenue which would have been available, but I don’t see that this causes incentive compatibility problems.

On the other hand if the IL is constrained to be something less than a full 30M gas, the proposer must actively identify and include suspected censored transactions, rather than simply including all transactions which meet the basefee+12.5% requirement. It seems like the censorship resistance would be less effective in this case.

I suppose the other thing is that I just don’t see introducing new protocol variables as a cleaner way of doing things, when it seems that there’s a very natural size limit on the IL, set by the block gas limit.

1 Like
32

To disincentivize handing control of the 5M chunk over to block builders. If it is just a bigger gas limit, then the expectation we should have is that this extra 5M gas will be given to builders to “optimize”. The goal is to make it so the only thing that actually ends up in this 5M chunk is stuff that is being actively censored by builders. It is expected to be empty all the rest of the time.

2 Likes
33

def think this is part of the design space! will keep thinking on it; i think from discussions francesco might also prefer this version. :slight_smile:

i am thinking about the right way to get closer to rough consensus on these design decisions. i went through the spec considerations and outlined them in here: Inclusion list consensus, engine, & execution spec overview - HackMD. the main goal of this doc is to show the scope of the ILs change can be pretty small and well contained.

2 Likes
34

ya this is a good point. the bribery games are probably much stronger if the proposer knows that the IL can determine their entire block

35

Since the protocol doesn’t force or incentivize a non-empty IL, as you mention, some participants might choose to propose empty ILs.

From the specification perspective, the content of the IL is optional. In addition to the participants, there is also a chance that the client devs choose not to populate the IL for any reason (performance concern, not enough dev resource to implement, just do the bare minimum etc.). So it would become something like reorg-ing out late blocks where it is good for the overall network, some client teams choose to implement it, some don’t, some postpone til a later time.

36

So it would become something like reorg-ing out late blocks where it is good for the overall network, some client teams choose to implement it, some don’t, some postpone til a later time.

If it becomes like that we would be in a very good shape. Before that PR merged, over 70% of the network already were reorging late blocks. Some clients did not postpone it lightly: they chose to postpone it until the PR actually merged in the CL repo. They are now working on implementing it because it has finally merged.

Besides this, client devs have already expressed broad support for sane defaults in regards to ILs.

37

Unconditional inclusion lists is a an amazing iteration over the previous one. I read through all the discussion and it seems to me that we are forgetting why we have or want an IL.

  1. first of all there seems to be no actual/effective way of forcing proposers to include tx. The ILs dont solve this problem. They solve the problem of making builders include the txs they want to include. So simple question is why couldn’t they themselves include it? because payload is revealed when the block is published, and IL is the way to say that i don’t know what payload builder is building but I want to get these txs included. If there were no unbundling issues or late block issues, ideally the proposer would have fetched the bundle from builder, and included these txs himself/herself.

So IL for slot N is actually an extra payload which proposer for N wanted to add. In builder free world, we don’t need IL as it doesn’t solve any problem. again the problem being how to force inclusion of some txs without needing to know builder payload

  1. Because these are the txs which slot N wanted included, these should be included on TOP of the payload N+1 for various reasons:
    i) Again these are txs N wanted included
    ii) builders could run these txs as soon as they see the block and start building next payload on top rather than end moment including them just before they have to handover the block to next proposer
    iii) these txs don’t need to be part of actual builder payload and cesnoring builders could still give payloads for N+1 because the IL it won’t be a part of their bundle ( not sure how mitigating this is for builders to say that our bundle didn’t carry censored data and hence we are off hook)
    iv) because of point iii) and also because that the builders don’t switch out competing same nonce txs of the sender (sender’s low fee tx can be part of IL causing it to “pre-confirm” a spot in next block top , and by the time the next block has to be constructed it can replace it by an mev extracting higher paying tx), the summary should carry the IL transactions root has been clarified that this causes free DA

Another point which I wanted to raise is which is more so an implementation detail but still affecting design space is:

  1. the IL’s summary shouldn’t be signed but carry a inclusion proof of the block which proposed the IL (a la blobs), that means the block should have a proposed_ils list with root of proposed ILs against which proof to signed beacon block header could be constructrted and included in IL (and similarly validated)
    i) it can keep the signing flows unchanged for blinded blocks (as well as normal blocks even though validator produceblock will carry the extra content)
    ii) no new slashing conditions need to added, can ride on top of signed block slashing conditions
    iii) the signing infra (web3signer) doesn’t need changed

Like the blobs this can be done later but it would be nice if things can be neat from the begining.

38

as i understand from discussions with Mike and others, adding on top causes next slot mev extraction. so I have another wild (or may be stupid) proposal

Before the start of slot N (so last interval of slot N-1), slot N+1 proposer emits the signed (by N+1 proposer) IL based on its view of mempool (txs executable at slot N, to be fullfilled in N or N+1), and the slot N proposer can choose to add it (and get extra protocol rewards) or not.

This way N+1 can force builders for its slot to include the txs it want (in N or N+1) if they get preconfirmed by slot N proposer by including N+1’s summary in slot N beaconblock (so just a reverse declaration than forward declaration). This way slot N+1’s rights remain with slot N+1 (again problem to be solved is enforcing a constraint on slot N+1 builders)

39

Proposal:

  1. Builder builds a blinded block and gives header to proposer.
  2. Proposer signs over block header plus inclusion list.
  3. Builder submits signed header + body + inclusion list to the network.
  4. When validating a block:
    A. Transactions in body are executed.
    B. State root in header is validated.
    C. Transactions in inclusion list are executed, skipping any that were already executed in the body.
    D. Internal state is updated, but updated state root isn’t validated against anything (consensus on IL updated state will happen in the following block)

Assuming blocks are almost never full (current case on mainnet, and by design), outsourcing IL building is pointless as the builder can just add whatever transactions they want to the block body, so they gain nothing by taking over IL building other than the ability to censor.

Since the header/body is created before the IL is generated, we need to come to consensus on pre-IL state. Consensus on post-IL state will happen naturally in the next block which will build on top of the post-IL state.

We can either have the proposer published the IL, or have the builder publish the IL. I like having the builder publish the IL because it allows the proposer to force them to publish censored transactions after the builder has already committed to a header, so it will now cost them the whole block plus penalties if they fail to publish the censored transactions.

The big downside of this strategy is that the IL likely has a lot of duplicated transactions with the block body. We can reduce this to just transaction hashes by deduplicating during propagation, but if a block has 100 transactions duplicated in both the body and the IL, then we are looking at 3.2kb of wasted space in each block.

2 Likes
40

The only difference in your proposal with the current one is that the IL is executed in the same block (after the payload has been executed) instead of in the next one. This has a number of drawbacks.

  1. The execution state transition would now have the signature:
state, payload, IL --> state

And the IL has no way of being validated by the EL since it doesn’t know about validator signature. How are these blocks even broadcast and synced then?

  1. The inclusion list cannot be on the block, if the IL is fully included in a block then you get free DA which is the main point this EIP aims to solve with this design.

  2. You break any compatibility with ePBS since you are tying IL inclusion/validity with the builder revealing the block. We want to prevent censoring even if the builder decides to avoid and miss the block, by making the IL remain in place until eventually one builder includes the censored txs. Notice that you break this condition even without ePBS. The inclusion lists in this EIP proposal have the following property: if the proposer includes his block on chain, then no other block can extend this chain unless it satisfies the IL. On this proposal this happens even if the proposer is not building locally and his builder is a censoring builder: the censoring builder does not have any incentives to lose the payload rights by not revealing, they can send their block knowing that when the IL is included the next builder will have to satisfy it, not them. Once the block is included, no matter how many builders try to censor it, the IL remains valid. On the other self-block approach, the block, and hence the IL, never make it on chain.