Dankrad Feist pfp
Dankrad Feist
@dankrad
I'm starting to worry that based preconfirmations lead to too much centralization pressure, creating a small oligopoly of shared sequencers and provers. Is this really better than centralized sequencers (which can also give preconfirmations)? At least the centralization here is per rollup and not global.
4 replies
4 recasts
62 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
An alternative proposal: Accept the centralized sequencer, but make forced inclusions super attractive (same price as normal rollup transactions, just no preconfirmations).
2 replies
0 recast
12 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
Here is a possible design: - Forced inclusion blobs can be created by anyone (they are "based") - They have to be included after the next sequencer blob
1 reply
0 recast
9 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
In this case, the sequencer can always give one blob worth of preconfirmations, after which they have to include the "based" forced tx. Worst case for based tx is to be included after 2 sequencer blobs. (We should also add a max space between sequencer blobs so they can't delay indefinitely)
1 reply
0 recast
6 reactions

treethought pfp
treethought
@treethought.eth
I don't have a ton of context, but would making them blobs and being the same price open up the possibility of crowding out preconfirmations and basically flipping things so preconfs are being excluded?
1 reply
0 recast
0 reaction

Dankrad Feist pfp
Dankrad Feist
@dankrad
That's why the sequencer blob would get priority.
0 reply
0 recast
1 reaction