Relayed questions from Open Zeppelin

[dantaik]

The following questions are from OpenZeppelin.

---

• As I understand it, during intermediate proposer slots (where the L1 proposer has not opted into the protocol), the next proposer (or their delegated preconfer) will be issuing pre-confirmations for all intermediate slots. In this time, the L1 state does not get updated at all, but an L2 user that assumes preconfs work correctly will not be affected. However, if there is a large sequence of consecutive intermediate proposers, there might be too many transactions to fit into a single block. How would you manage that?

  • Daniel noted that perhaps Taiko can have a privileged role to be able to post transactions during the intermediate proposer slots. In that case, I'd like some clarification about how they could deconflict preconfs with the next proposer. Also, since they can't guarantee their transaction is included, what would happen if the intermediate proposer does not include it?

• The design seems to allow one preconfer to mess with the next. In particular:

  • if preconfer A constructs issues 20 different preconfirmations, then an end-of-sequence message, preconfer B will start issuing preconfirmations based on the complete block (before it lands on chain)
  • if preconfer A then creates an actual block with a different 20th transaction, they have invalidated one of their preconfirmations (and they will lose a small fraction of their stake when the user submits their proof) but they may have invalidated ALL of preconfer B's preconfirmations. In fact, they could just add a 21st transaction to their own block so there is no aggrieved user and they don't suffer any slashing.
    • perhaps it makes sense for preconfer B to be able to slash based on the end-of-sequence message.

• If preconfer A doesn't submit their block (or submits just the first half or something), would preconfer B be expected to include the missing transactions in their sequence? Perhaps this is one way to address the first point (about having too many preconfirmed transactions in a block), because the next preconfer could then just continue from where the previous one left off.

  • the problem with this is that preconfer A would be making a commitment that preconfer B has to carry out, so they could potentially pass-the-buck on unprofitable transactions.

• The documentation says that we assume some level of "social guarantees" between preconfers. Can we walk through what that means?

[linoscope]

However, if there is a large sequence of consecutive intermediate proposers, there might be too many transactions to fit into a single block. How would you manage that?

We allow the elected proposer (the 'preconfer') to submit their preconfirmed L2 blocks to the L1 public mempool (or via private orderflow to a builder) before their assigned L1 slot. This enables the preconfer to spread their L2 blocks across multiple slots. However, there's no guarantee that these L2 blocks submitted through the mempool will actually be included, as the preconfer doesn’t control those slots. As a result, they may decide to stop preconfirming if their L2 blocks are not being included and the preconfirmed L2 transactions exceed the capacity of their assigned slot. Preconfers can fine-tune this strategy based on their risk tolerance.

Daniel noted that perhaps Taiko can have a privileged role to be able to post transactions during the intermediate proposer slots. In that case, I'd like some clarification about how they could deconflict preconfs with the next proposer. Also, since they can't guarantee their transaction is included, what would happen if the intermediate proposer does not include it?

Yeah, having Taiko act as an intermediate proposer would require Taiko to trust either the next preconfer or the public mempool to include their preconfirmed L2 transactions in a timely manner. The advantage of letting the next preconfer in the lookahead handle the intermediate slots is that, eventually, their assigned slot will come, and at that point, they can utilize all the blobs they need to ensure their preconfirmed transactions are included.

But letting Taiko be privalleged preconfer is itself an interesting approach, and we are considering letting Taiko be the default fallback preconfer in cases where the lookahead contains no opted-in proposer.

The design seems to allow one preconfer to mess with the next. In particular:

• if preconfer A constructs issues 20 different preconfirmations, then an end-of-sequence message, preconfer B will start issuing preconfirmations based on the complete block (before it lands on chain)

In our design, even if the previous preconfer doesn’t include their L2 blocks as preconfirmed, the next preconfer won’t be slashed. This is because Taiko L2 blocks are proposed as a TX list (without a state root), and our preconfirmation solution also preconfirms a TX list, so equivocation by the previous preconfer could invalidate some transactions, it won’t invalidate the entire list.

If preconfer A doesn't submit their block (or submits just the first half or something), would preconfer B be expected to include the missing transactions in their sequence?

In our current design, we don’t expect any coordination between preconfer A and preconfer B. Preconfer A is solely responsible for ensuring their preconfirmed L2 blocks are included on time, using both the public mempool and their assigned slot. If we were to introduce coordination between preconfers, we’d need to enable off-protocol collaboration and establish an incentive structure that motivates proposer B to participate in this process. This could be an interesting future step, but needs further considerations.

The documentation says that we assume some level of "social guarantees" between preconfers. Can we walk through what that means?

Which document are we referring here? Couldn't find such mention of "social guarentees" in our design doc