Feedback request on an idea to improve the current design

[dantaik]

As I mentioned in the meeting, I appreciate Nethermind's preconfirmation design, particularly the absence of a gateway. However, I prefer that preconfirmation happens within 1 second, and the number of Taiko blocks with the same number of transactions (e.g., per day) should decrease rather than increase.

I want to share my thoughts on how we could achieve this based on Nethermind's current design and implementation.

---

Instead of building a Taiko block every 3 seconds across AVS nodes or propagating proposeBlock(s) transactions in L1’s mempool (as mentioned in this doc), the preconfer could propagate signed transaction groups every 200ms. A transaction group contains a list of transactions with a strictly incremental groupId, allowing for faster and more granular preconfirmation.

For example:

{
  "blockId": 10000,
  "groupId": 1,
  "transactions": ["tx1", "tx2"],
  "sig": "signature_of_group_hash"
}

The Taiko Geth client would accept these transaction groups from AVS nodes, verify their integrity and the preconfer’s authorization using the signature and an on-chain lookahead mechanism. The transactions within the group would be applied sequentially to tentative blocks in the local Taiko Geth instance. As more transaction groups for the same block arrive, the tentative block would be updated accordingly. These tentative blocks would eventually be replaced by the actual blocks once they are proposed on-chain.

Preconfers can decide how frequently to broadcast transaction groups, with the most granular approach being a single transaction per group.

Even if a tentative block is discarded, all transaction group data will be stored locally for up to X days. This data allows AVS nodes to help users challenge and potentially slash preconfers who fail to honor their commitments, using the transaction groups as evidence against the actual block’s root hash. As long as transaction groups are signed, they serve as preconfirmation promises, eliminating the need for individual receipts per transaction.

Transaction groups for the next block will be discarded unless the last transaction in the last group of the current block is a small end-of-block transaction. We can use the marker tx.msgSender = preconfer && tx.to == address(0) && tx.data = "" as an indicator of the end of a block.

If the marker transaction satisfies tx.msgSender = preconfer && tx.to == address(0) && tx.data = "last_block", it marks the block as the last one from this preconfer. If the next block is proposed by the same preconfer, the transaction group data can be used to slash the preconfer.

Preconfers should avoid signing transaction groups that build the same L2 block differently, as this would lead to slashing.

A preconfer can also include the same transaction in multiple groups for the same tentative block. In such cases, all earlier occurrences of the transaction are removed from previous groups, and the final occurrence determines the transaction’s position in the block, allowing the preconfer flexibility to revise decisions.

We can include the parent block hash in transaction groups, and the Taiko Geth client will only accept a group if its parent block hash matches the local chain’s parent block hash. In the event a preconfer is slashed due to the local tentative block differing from the on-chain proposed block, the subsequent preconfer will remain immune from slashing for that discrepancy.

---

The idea is not fully developed and may have serious bugs, but I hope to get your feedback.

[dantaik]

A question I haven’t figured out yet: What if a preconfer is “lazy” and fails to publish transaction groups (or in the origianl design, the 3-second blocks) on time, or not at all? Can AVS enforce timely publishing?

[AnshuJalan]

I think this too would fall under the fair-exchange issue. Lin has suggested it be mitigated at the user level itself: https://ethresear.ch/t/based-preconfirmations-with-multi-round-mev-boost/20091#user-actions-9

[AnshuJalan]

We have had a discussion on a similar approach last week. This seems to fit our current approach well. Quoting the original discussion text:

I’m thinking of a naive solution that could address this issue without making significant changes to the node and related infra. Instead of creating a preconfirmed L2 block every three seconds, we could create a preconfirmed “soft-L2 block” every three seconds. These soft blocks would have the exact same structure as the usual L2 block, but with an additional “tag” called “soft.” They would be clearly marked as “soft” on the block explorer (I believe the open-source explorer can be modified to show this distinction with minimal changes) and would display “intermediate state updates.”
Then, we would have the actual block formed via an L2 block proposal on L1. The node would accept this block via a block proposed event. These blocks would contain all the transactions from the soft blocks, following the order in which they appear.
The smart contract should be able to verify the ordering and inclusion of these soft blocks during preconfirmation faults.

I think this can also be more generally applied to your idea, and we may have soft-blocks every 200ms.

The main concern that we have with this approach is how would indexing services (say, graph protocol) interface with this, and will this soft-block/transaction-group approach fit the way wallets work with existing JSON RPC interface.
From my understanding, this would cause the RPC endpoint to return a different response for a certain block height, every time a transaction group is processed.

[dantaik]

Thank you @AnshuJalan for your feedback.

From my understanding, this would cause the RPC endpoint to return a different response for a certain block height, every time a transaction group is processed.

That’s correct, but we can also view it as normal, yet frequent, reorgs. The latest tentative block continues to change unless an end-of-block marker transaction is detected within a transaction group. Until this occurs, the block header can use placeholder values rather than continuously updating hashes to simplify the user experience.

[dantaik]

The main concern that we have with this approach is how would indexing services (say, graph protocol) interface with this, and will this soft-block/transaction-group approach fit the way wallets work with existing JSON RPC interface.

I believe we should avoid modifying the existing block structure as much as possible, as this would involve extensive discussions with wallets, explorers, analytics platforms, and might even require changes to open-source libraries. Additionally, I don’t think we should alter Taiko’s core protocol to support soft blocks, as doing so would require months of debugging and testing.

Instead, we could introduce a new JSON-RPC method in Taiko Geth, perhaps called preconfirmTransactions, which would accept a transaction group as input and build a new tentative block or update the latest tentative block. With this approach, aside from the new RPC, we wouldn’t need to make further changes to Taiko Geth. From the Taiko protocol’s perspective, the transaction group (or soft blocks) would not exist at all.

If a Taiko Geth instance does not authorize an AVS node to call preconfirmTransactions, it would continue to function as a regular Taiko node, without managing tentative blocks.

[dantaik]

After reviewing the design documents from Nethermind and Gattaca, I realized there are two distinct types of preconfirmation for users:

1. Receipt-based preconfirmation: In this approach, a user (or their trusted gateway) receives a receipt for a preconfirmed transaction. This receipt can later be used to challenge or slash the preconfer if necessary. The receipt is expected to be issued by the preconfer in real-time and can be displayed by apps like wallets to inform users of preconfirmation status. Gattaca’s approach leans more towards this model.

2. Preconfirmation for mempool transactions: This method would preconfirm transactions from the mempool that a preconfer selects, even if the senders didn’t explicitly request preconfirmation. The transaction group ("soft block ) model assumes that every transaction sender wants preconfirmation as soon as possible. This aligns more with Nethermind’s approach.

I believe it’s feasible to combine both approaches into a unified solution: the preconfer could issue receipts directly to users while simultaneously including transactions from both users and the mempool. By utilizing the new preconfirmTransactions JSON-RPC mentioned earlier, it could efficiently build tentative blocks without requiring any changes to the existing protocol and very little, non-intrusive changes to Taiko-geth which explorers/wallets won't even notice.

[Brechtpd]

So the proposal is to make it work like FlashBlocks? Which is kind of the Nethermind approach on steroids. :)

Seems like they have the implementation already figured out (e.g. I believe here for rbuilder: flashbots/rbuilder#214).

[dantaik]

Good to learn about this project. The concepts are similar, but Flashblock will begin with a permissioned sequencer, requiring TEE proofs when a partial block is published. In contrast, we build tentative blocks that are local to each node, and the transaction groups used to construct these tentative blocks can serve as evidence to slash malicious builders or pre-confirmers.

[Brechtpd]

But that doesn't really matter for the tech itself no? It's just how you use it.

The solana-fication of block building: https://youtu.be/oNLPglf2cQY?list=PLJqWcTqh_zKHDFarAcF29QfdMlUpReZrR&t=243

And while the TEE proof doesn't have to be there, it can be very useful to ensure some important properties!

[dantaik]

While some code can likely be reused, we can’t use it directly as-is. To accelerate progress, we can implement the code to build the tentative blocks for preconfirmed transactions ourselves.

[smartprogrammer93]

This direction sounds awesome to me. I like where this is going. Shall this be part of our next endeavor here?
What do you think @linoscope ?

[dantaik]

I’m uncertain if my approach of building local tentative blocks will still be compatible with @linoscope’s Based Preconfirmations with Multi-round MEV-Boost idea, since we won’t be building and proposing real blocks as frequently anymore.

[smartprogrammer93]

The current design of the Taiko POC does not conform to @linoscope's MR-MevBoost design. We dont build real blocks either in our current design. They only become real blocks once they land on L1, and they get reorged out if they dont land on L1.

[linoscope]

However, I prefer that preconfirmation happens within 1 second,

We must also consider the negative impact of subsecond, especially around centralization. Like PBS compatibility without centralized gateway, "self-preconfing" capabilities (maybe not important but I think it's cool that our approach can support this), hardware requirements of the full nodes that follow the preconfs (especially considering the potential overhead of reorging and reexecuting these soft blocks), etc.