In memory tx pool

[ChihChengLiang]

We now have our tx pool implemented as accessing from disk/database.

We can have pending tx in memory. While executed tx are already available on chain, maybe we don't need to store them at all.

[vaibhavchellani]

Think we should store executed txs off-chain for explorers and wallets.

[ChihChengLiang]

I think we have two kinds of transactions to store: pending and executed transactions.

Pending Transactions are sent by the users to the coordinator, who then later picks from those to make a batch. Here list some of their properties:

• We want to query fast and with low overhead since the query is complicated. The coordinator has to sort them by the tokenID, and serves the most valuable transactions first. Needs better review and testing.
• We want to have multiple pools and specify their sizes. So that a popular token can have a larger size.
• It's ok to drop pending transactions when restart. Users can resend and speed up the same transaction by using the same nonce.
• They are nice to have in explorers and wallets. A user cares about their own pending transactions but probably not the other users'.
• Incorrect behavior hurts the coordinator.

Executed transactions are in the batches synced from the Eth1 chain.

• The node should offer a canonical view of the transactions. So it makes sense to have API to query historical executed transactions.
• Query logic is simple. The purpose is the exhibition of existing data.
• The executed transactions stored on-chain is in a compressed form. They have no nonce, no transaction hash/ID, and no status of submitted or finalized. So it makes sense for the node to offer those extra fields.
• They shouldn't be lost after a restart.
• Incorrect behavior hurts explorers and wallets, but not the coordinator.

I suggest keeping pending transactions in memory and executed transactions in the database to best serve the above properties.