Current proveIncorrectPreconfirmation impl won't work for real-inclusion preconfirmation

[dantaik]

The current implementation of proveIncorrectPreconfirmation assumes that the inclusion of a Taiko L2 contract can be verified by simply checking if the txListHash in a preconfirmation receipt matches the block's blobHash. However, this assumption is incorrect. Here's why:

In Taiko's permissionless rollup design, multiple proposers (e.g., Alice and Bob) can propose blocks simultaneously. The final order of these blocks is only known once both transactions are confirmed on-chain. For example, if a specific transaction appears in both Alice's and Bob's txList (Data Availability - DA), and Alice's block is confirmed first, this transaction will be part of Alice's L2 block. However, in Bob's L2 block, the same transaction will be ignored, even though it was originally included in Bob's txList when his block was proposed.

In other words, the txList (provided as calldata or a blob) serves as the source for deriving the actual L2 block. The finalized L2 block will include only the valid transactions from the txList, and any invalid or duplicate transactions will be ignored. Therefore, the proveIncorrectPreconfirmation can only be valid if the block in question has been verified.

To handle this properly, you should use Taiko's getLastVerifiedBlock to check if the block is newer than the last verified block. If so, call getBlock to retrieve its verifiedTransitionId, and then use getTransition to obtain the block's blockHash. From here, the challenge becomes verifying whether or not a given transaction is included in the block with the corresponding blockHash.

Change to the Taiko BCR Protocol?

Initially, I considered modifying the Taiko protocol client code to ensure that all transactions included in a block are valid. If any invalid transactions are found, the entire block would be marked as invalid. However, this approach introduces significant complications. It would cause a mismatch between the number of L2 blocks and the number of L1 block proposals, further increasing the complexity of the protocol contracts.

[dantaik]

Regarding uint256 internal constant DISPUTE_PERIOD = 2 * SECONDS_IN_EPOCH;

Currently, both proveIncorrectLookahead and proveIncorrectPreconfirmation share the same dispute period constant. However, I believe it would be better to define two separate constants, as the dispute period for proveIncorrectPreconfirmation should be significantly longer.

A Taiko block is considered "verified" only when it is proven by a validity proof (such as ZK or SGX) and all preceding blocks have been verified. This process can take up to 3 days with the current mainnet setup, so the dispute period for proveIncorrectPreconfirmation needs to accommodate this extended timeline.

[linoscope]

Hi @dantaik , thanks for the comments and feedback! Really nice to have more eyes on the protocol/code.

The finalized L2 block will include only the valid transactions from the txList, and any invalid or duplicate transactions will be ignored. Therefore, the proveIncorrectPreconfirmation can only be valid if the block in question has been verified.

In proveIncorrectPreconfirmation, we check that the preconfirmed L2 block and the proposed L2 block match. Namely, we check that following two values match:

• (a) The txListHash in the PreconfirmationHeader, calculated here.
• (b) The blobHash in the metadata of the proposed L2 block, calculated here.

Since both values are computed using the unfiltered "raw" version of the txList, shouldn't we be fine?

[dantaik]

@linoscope, whether it works depends on the nature of preconfirmation. I think we can categorize preconfirmations based on the transaction status as follows:

1. TX-Inclusion-in-Proposal: This is what the current implementation achieves. It ensures the user that their transaction will be included in the block proposal.
2. TX-Inclusion-in-Block: This was my initial expectation. It guarantees that the transaction is part of the block, though the L2 block's transactions root isn't available to TaikoL1 until the block is verified with a proof (all preceding blocks need to be verified beforehand).
3. TX-Execution: This confirms that the transaction has been successfully executed without a revert in the block.

By the way, don't worry about the terminology—I'm not trying to push these terms! 😄

If we aim for TX-Inclusion-in-Block, with the new TaikoL1 ABI, we would need something like this:

  function proveReceiptViolation(
       Receipt calldata _receipt,
       bytes calldata _proof
   )
       private
       view
       returns (address preconfer_)
   {
       (
           TaikoData.BlockMetadataV2 memory meta,
           BlockHeader memory blockHeader,
           bytes32[] memory transactionHashes
       ) = abi.decode(_proof, (TaikoData.BlockMetadataV2, BlockHeader, bytes32[]));

       // For now only tx-inclusion preconfirmation are supported
       require(!_receipt.isExecutionPreconf, ExecutionPreconfNotSupported());

       // This function verifies that the provided list of transaction hashes matches the
       // transactions root in the block header.
       // Note: The data cost for _transactionHashes can be very high with this implementation.
       // Consider optimizing this function to reduce data costs.
       require(
           _blockHeader.transactionsRoot == _transactionHashes.merklize(), TxRootHashMismatch()
       );

       ITaikoL1 taiko; // Need initialization.

       // Verify chainId
       require(taiko.getConfig().chainId == _receipt.chainId, ChainIdMismatch());

       // Get the block data for the given block ID.
       // Note that this function may revert as only a few days of transactions are available in
       // Taiko BCR protocol's ring buffer.
       TaikoData.BlockV2 memory blk = taiko.getBlockV2(meta.id);

       // Verify the block has been verified.
       require(blk.verifiedTransitionId != 0, BlockNotVerified());
       require(blk.metaHash == keccak256(abi.encode(meta)), BlockMetadataMismatch());

       // Verify the preconfirmation is signed by the block's proposer.
       require(recoverPreconfer(_receipt) == meta.proposer, InvalidSignature());

       // Retrieve the block's block hash to verify the provided block header is correct.
       TaikoData.TransitionState memory tran =
           taiko.getTransition(meta.id, blk.verifiedTransitionId);
       require(LibBlockHeader.hashBlockHeader(blockHeader) == tran.blockHash, BlockHashMismatch());

       // Verify the transaction is not included in the block.
       require(
           _receipt.position >= transactionHashes.length
               || transactionHashes[_receipt.position] != _receipt.txHash,
           TxIncluded()
       );

       return meta.proposer;
   }

You've likely noticed the following challenges:

1. We need the list of transaction hashes for all transactions in the actual L2 block to build the transactionsRoot. This is quite expensive on-chain (though, fortunately, users won't need to call this frequently). In the future, this could be optimized using SGX proofs or ZK proofs.
2. Users would have to wait a long time for the block to become "verified." Until then, L1 doesn't know the actual state of L2, including which transactions were included or their execution status.

[dantaik]

Upon reviewing the PreconfirmationHeader struct, I realized that the current preconfirmation operates at the block proposal level, which differs from all three types I mentioned earlier.

[linoscope]

I realized that the current preconfirmation operates at the block proposal level,

Yes, exactly. In a sense, this provides the "TX-Execution" preconfirmation in your categorization. By preconfirming at the L2 block level, Taiko clients can synchronize their head using these preconfirmed L2 blocks. This allows users to query the Taiko client to retrieve the exact result of their preconfirmed transactions.

[dantaik]

@linoscope I agree that By preconfirming at the L2 block level, Taiko clients can synchronize their head using these preconfirmed L2 blocks. However, for most users, they will assume a preconfirmation (with a valid signature) means they can rest assured that the transaction is guaranteed to be included in the specified block without a further verification by looking into the actual block.

Do you think it's a good idea to move PreconfirmationHeader and related code to a separate contract so they can be implemented differently in decoupled files?

[linoscope]

However, for most users, they will assume a preconfirmation (with a valid signature) means they can rest assured that the transaction is guaranteed to be included in the specified block without a further verification by looking into the actual block.

There is a fundamental difference between our "batch preconf" (preconf at the L2 block level) design and other "tx preconf" (preconf at the individual tx level) designs, which may be causing some confusion.

In tx preconf designs, the process works as follows:

1. The user locates the RPC endpoint of the next preconfer through some peer discovery mech. The preconfer is often a "gateway" delegated by the proposer ahead of their slot.
2. The user's wallet sends their tx to the RPC.
3. The RPC responds with a preconfirmation for the tx.
4. The user's wallet updates its state based on the preconfirmation result.

In contrast, with our batch preconf design:

1. The user's wallet sends the tx to the public mempool.
2. The next preconfer picks up the tx from the mempool, constructs an L2 block, and publishes the L2 block to the P2P network—effectively "preconfirming" the entire L2 block.
3. The user's wallet (more specifically, the L2 full node it is connected to) updates its state based on the preconfed L2 block from the P2P network.

So there isn't really a "further verification by looking into the actual block". The act of looking at the preconfed L2 block is how users get the result of their preconfed tx in the first place.

And batching has multiple benefits compared to non-batching solutions:

• Since we can utilize the existing mempool, there is no need for additional peer discovery mech to find exact RPC endpoints of preconfers.
• "Out of the box" tooling support by operating at the L2 block level (wallets, indexers, L2 full nodes, etc).
• Greater flexibility in the proposer-builder separation (PBS) approach. Tx preconfirmation requires proposers to commit to specific gateways ahead of their slot, which centralizes the process. Such centralization may be fine for L2s, but once we consider L1 composability, then we must introduce similar centralization to the L1 block building, which would probably lead to strong community pushback. Batch preconfirmation allows for more decentralized PBS, similar to just-in-time auctions in L1 MEV-Boost (see our MR-MEV-Boost post for more details on this topic).
• Simple pricing mechanisms are enabled by batching, allowing txs to be ordered by fees. Pricing individual txs without seeing competing txs is much more difficult.

The downside is that batching can't offer speed-of-light responses, but I believe a 3-second response time should be sufficient for most use cases.

Do you think it's a good idea to move PreconfirmationHeader and related code to a separate contract so they can be implemented differently in decoupled files?

Separating the slashing logic into a separate file sounds reasonable to me, especially if you are thinking of trying out different preconfing/slashing designs, but I will let @AnshuJalan answer this one as he has most context around the code structure.