Actually I take that back 
If an L2 transaction is force-included at L1 and the L2 sequencer has been compromised (e.g. so that the sequencer is no longer settling anything) then that L2 transaction can’t execute until after some timeout. This timeout can’t be made arbitrarily small because otherwise that would completely break preconfirmations. To summarise, based sequencing gives the same settlement guarantees as the L1 (no need for a timeout to force settle).
1 Like
Yes, while you can have preconfirmations on inclusion with based forced transactions and L2 sequencing, if the sequencer halts or doesn’t post batches in order (OP derivation window is 12h!) then preconfirmations on post state break.
It’s not just preconfirmations that break. You also suffer a liveness failure during the derivation window.
1 Like
@JustinDrake I just saw your recent episode on Bankless. I understand your vision on this better now. Yes, if we have shared sequencing and real-time settlement then we can have synchronous composability. And that would be amazing.
The problem is that real-time settlement is only theoretical for now. AFAIK it is 5+ years away, maybe more. With shared sequencing alone, we can only do atomic inclusion, not atomic execution. So no synchronous composability. All of this is known to you.
Shared sequencing does come with a some big drawbacks (loss of sovereignty, loss of sequencing revenue, more complexity). But by itself it only has one advantage: no need to code your own consensus and maintain a validator set. But to be honest, a based rollup (the one described in the original proposal) is a better option if someone really doesn’t have the resources to build/maintain a consensus layer.
It doesn’t make sense for a decently-funded rollup team today to use a shared sequencer, in the hope that it will pay off 5+ years down the road. Better to build your own consensus today, have asynchronous composability with bridges and if real-time settlement becomes a reality then change to shared sequencing.
I really think you’re underestimating the importance users/devs place on sovereignty. Two examples. First example, Polkadot and Cosmos. Polkadot’s model has all chains sharing the same validators, while Cosmos has sovereign chains and just handles inter-chain communication. If you compare the two ecosystems, Cosmos has bigger projects and more users. Second example, Celo has signaled their intention to migrate to a L2 and one of their hard requirements is exactly the ability to keep their existing validator set.
2 Likes
How should the case where the previous preconfirmers block is re-orged be handled?
E.G block X was the L1 block of the previous preconfirmer, the next preconfirmer is at X+5 and has issued post-execution state root preconfirmations. Now block X gets re-orged and the preconfirmer at X+5 is left with a bunch of pre-confirmations that they can not honour and it’s not their fault.
How should the case where the previous preconfirmers block is re-orged be handled?
I think we don’t need to do anything special to handle reorgs? The next preconfer will have a monopoly over the sequencing of the L2 txs, so even if there is a reorg, no other entity can insert L2 txs that violate the state root preconfermations.
I don’t think this is correct unless you are implying that the next preconfer is forced to not reorg the previous preconfer which is impossible to do without something akin to SSF. Imagine a world in which every L1 validator is a preconfer. Then either L2 has reorgs or L1 does not have reorgs.
Hmm, it is still unclear to me how a safety slashing attack, where the preconfed state is invalidated, could happen via reorgs. For a reorg to invalidate the preconfirmed state of a preconfer, either the L2 tx ordering in that preconfer’s assigned slots changes, which won’t happen since the preconfer has monopoly over ordering in their slots, or the tx ordering in some slot prior to the preconfer changes. But for a previous slot’s preconfer to change their L2 tx ordering, they must have signed two conflicting txs at the same position. And I think the slashing mechanism would/should only slash the earliest invalid preconf in terms of L2 tx ordering.
But if we are talking about a liveness slashing attack, where a preconfer’s slot is forced to be missed via a reorg, I agree it is possible. I think it can be mitigated to some extent by having liveness slashing less severe than safety slashing (which should be so anyway as missing a slot can happen by accident). And there is also below idea of having some insurance market by @JustinDrake:
Liveness and safety slashing offenses are completely equivalent, if I hold two consecutive slots as a preconfer, I can “be offline” for the first one and do whatever I want to the second one, just paying the liveness slashing on the first one.
Why does this post assume preconfs must be included with inclusion lists instead of other methods that allow the proposer to include transactions, even with PBS, when self-building is non-economical? Is there a special property of inclusion lists that cannot be achieved with, for example, an out-of-protocol version of PEPC?
Using inclusion lists for preconfirmations may mean that inclusion lists are not used or are used to a lesser extent for censorship resistance. Do you see this as a problem? If not, how do we ensure that censored transactions find their way on-chain even when inclusion lists are used for preconfirmations?
2 Likes
Right, inclusion lists are a red herring—totally unnecessary. It took me a couple months to realise that we could just use offchain PBS, and that no hard fork is required
I updated and rewrote the based preconfirmations idea here 
3 Likes