Sequencer Mempool

[greged93]

This thread is used to discuss the mempool implementation for the custom Kakarot sequencer.

[greged93]

Given the work invested in Reth, we should try to stick to their implementation as much as possible. The first step in order to do this would be to scope out all problematic features of their mempool.

Right now, I can see two implementation that we will certainly need to redefine and one implementation which might need to be slightly modified, respectively the EthTransactionValidator which implements the TransactionValidator trait, the base fee pool implementation and the CoinbaseTipOrdering which implements the TransactionOrdering trait.

Kakarot's TransactionValidator implementation

The total change to be made the validator are still TBD, currently I can see at least one change for sure: Kakarot should currently refuse pre-EIP 155 transactions and EIP 4844 blob transactions. This section can be extended when more changes can be determined.

Base fee pool

The base fee pool is used in Reth in order to hold transactions which cannot currently be included in the pending block due to a base fee which doesn't satisfy the minimum requirement. In an execution client which correctly implements EIP-1559, the base fee for each block will change based on the gas used in the parent block. The issue is that for now, Kakarot doesn't implement EIP-1559 at the execution layer (Cairo code). This means that the base fee will never change, causing transactions from the base fee pool to never get promoted. We could thus update the TxPool implementation and/or the TransactionValidator in order to just avoid setting any transactions in the base fee pool.

Kakarot's TransactionOrdering implementation

The total change to be made the ordering are still TBD, currently I can see at least one change for sure: Kakarot doesn't currently totally implement EIP-1559. An initial implementation of the ordering could be to order transactions in a FIFO fashion.

[tcoratger]

I agree about pre-EIP 155 transactions and EIP 4844 blob transactions. We should try to stick as much as possible to reth implementation, just provided some flags to eliminate these transactions for now while remaining as flexible as possible for future integrations.