implement a mempool for the sequencer

[rianhughes]

This PR implements a mempool required for the sequencer.

[codecov]

Codecov Report

Attention: Patch coverage is 65.78947% with 78 lines in your changes missing coverage. Please review.

Project coverage is 74.60%. Comparing base (27b6968) to head (5286584).

Files with missing lines	Patch %	Lines
mempool/mempool.go	60.52%	59 Missing and 16 partials ⚠️
mempool/db_utils.go	92.10%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2341      +/-   ##
==========================================
- Coverage   74.62%   74.60%   -0.03%     
==========================================
  Files         110      112       +2     
  Lines       12024    12252     +228     
==========================================
+ Hits         8973     9140     +167     
- Misses       2354     2403      +49     
- Partials      697      709      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rodrigo-pino]

Half review! Will continue in January!

[weiihann]

From my understanding, the current implementation seems to work as such:

• Receives new tx
• Validates the tx
• Puts new tx into DB directly
• The order is FCFS

This architecture is simple and straightforward, but I'm not sure how effective it would work it would be in real life. Here are a few things we need to consider:

1. In-memory mempool
   It's way too expensive to store and retrieve txs only through the DB. There should be an in-memory implementation of it for fast access.

2. Order of sequencing
   The current method is FCFS, but how about other factors like fees?

3. Transaction validation
   I'm not fully aware what the ValidatorFunc actually contains, but few things we need to check for:

• Account balance checks
• Nonce validation
• Gas limit validation

There should also be a separation between pending txs and ready txs. Ready tx means tx that has higher nonce than the next immediate nonce of an account. Ready tx means the next immediate one and it's ready to be executed.

Mempool design and architecture could get complex, as it can be exploited for MEV. I'm not sure how far we want to take it at the current stage, but I'll suggest to look into existing architecture like Erigon's mempool design and go-ethereum one and see how they do certain things.

[rodrigo-pino]

Haven't checked functionality. Will do that on a second round. I am sharing now a bit of stylistic changes which I think will improve the code. Let me know what you think

[rodrigo-pino]

LGTM! Adding some final comments

[rodrigo-pino]

I believe SetUint64(0) is not necessary. If you want to be explicit, I think returning &felt.Zero is a better option

[rianhughes]

I've updated it to &felt.Zero, but just out of curiosity, why do you think new(felt).SetUint64(0) is suboptimal? Just because it might get allocated on the heap?

[rodrigo-pino]

Oh, in this instance it was from a legibility point of view. It is easier to read that your returning zero than creating a new felt and setting it's value to zero

[rodrigo-pino]

LGTM!