Taiko preconfirmation slashing conditions

[dantaik]

I’m putting my thoughts on slashing here to gather feedback. While the implementation of slashing is a low priority, the design must be solid; otherwise, the entire approach could become invalid.

Block-Based Slashing

Taiko’s new Soft Block APIs will enable a locally connected preconfirmation AVS node to build or update local tentative blocks, referred to as Soft Blocks, with one or more Transaction Batches (formerly Transaction Groups). Each batch is signed by a registered preconfer. If the actual Taiko block does not exactly match the transactions from these batches in the correct order, or if the block has different block-level parameters (such as coinbase, L1 anchor ID, block hash, etc.), we can generate a proof to slash the preconfer.

If the only difference between a soft block and the actual block is the header fields (indicating that the block was proposed by the next preconfer), we can slash the preconfer who signed the transaction batches and reward the actual coinbase address (we don't know the actual block proposer on L2, only know the block's coinbase who is the preconfer's fee recipient address).

Transaction-Based Slashing

Assuming transaction-based preconfirmation receipt also includes the preconfer's signature, we can generate a proof if the transaction is not included in the actual block as well.

[dantaik]

How to Slash for Block-Level Confirmation Violations

The promise of block-level confirmation is as follows:

• Every transaction in a block's corresponding batches (signed by the preconfirmer) must be included in the actual L2 block.
• The order of transactions within the block is not guaranteed.
• It is not guaranteed that transactions won’t revert.

How to Prove a Violation Off-Chain in a Prover:

• A party identifies a transaction in one of the block’s batches and gets its hash t.
• The party collects evidence: 1) a list of transaction hashes T (the full list of transactions in the block), and 2) the block header H and block hash b.
• The prover verifies that the batch has the correct signature from the preconfirmer, confirms that t is not part of T, computes the transactionsRoot r from T, and verifies that H.transactionsRoot == r. Then, it verifies that hash(H) == b.
• The prover generates a proof p.

Verify the Proof On-Chain:

• The on-chain verifier verifies the proof p against the public inputs.
• It checks that the L2 block has already been verified (i.e., its blockhash is known to the L1 contract) and that its blockhash is indeed b.
• Finally, the preconfirmer is slashed.

Note: Computing MPT tree root in Solidity is expensive and error-prone, while doing so in SGX is less costly and much easier. Additionally, we do not need the block proposal’s txList data (either as calldata or blob) at all. The txList in blob format is compressed.

---

Stronger Promise

We can offer an even stronger preconfirmation promise:

• Transactions will appear in the order they are included in the batches.
• Transactions will not revert.

Adjustments to the Off-Chain Prover:

• Change t is not part of T to t is not the transaction at the given index in T.
• Verify that the receipt at index t has a return code of 1 (indicating a successful transaction).
• User merkle proof for the above verification instead of a list of transaction hashes or a list of receipts.

[linoscope]

Hi @dantaik , thanks for the suggestion!

The prover generates a proof p.

I assume this proof is a SGX proof. I am thinking if this can be done via Merkle-trees or KZG commitments. The on-chain cost will be more expensive, but that shouldn't be an issue as slashing should be a super edge case, and if it happens, the cost can be compensated by the slashed tokens. TEEs are great when they have a non-TEE backup (e.g, multi-prover) or when they are not super security critical (e.g., sequencing), but fully relying on TEE for slashing sounds risky, and may scare proposers from opting in.