feat: txpool service

[tynes]

Description

Adds a design doc for the txpool-service, which can be used to horizontally scale denial of service protection in the world of interop and beyond.

[tynes]

This needs an architecture diagram, but the tldr is:

• Stateless edge executor services that caches data and does execution of transactions
• Backend database nodes optimized for storing and serving data, optimized for consistency, runs no mempool
• The executor runs a forking evm on top of the backend database, starts with RPC over HTTP, will need to optimize to a binary based transport in the future
• Can horizontally scale the database serving and the execution and optimize them independently
  • can push commonly used data from the sequencer to these edge nodes
• The executor can also act as a proxy for eth_sendRawTransaction in the future

[hamdiallam]

for the design-doc of sendRawTransactionConditional, should we replace the proxy described with op-txpool? We can iterate on a single rpc server and consolidate early or we can start separately if it gets us to our goals faster

[tynes]

New Proposal

Based on convo with @axelKingsley and @protolambda

Instead of adding a completely new service to act as a transaction ingress, simply add execution and an op-supervisor client to a full node's mempool. This feature can be opt in, meaning that not all nodes need to do this, but nodes that sit in front of the sequencing node will need to have this feature on to filter out invalid transactions before forwarding them to the sequencer. Ultimately, the sequencer should also double check executing messages when building the block itself due to the lack of strong consistency with the check at the periphery and the downside of including a an invalid executing message resulting in an invalid block.

This cuts scope and simplifies the architecture. We shouldn't attempt to optimize here yet.

[tynes]

Closing this in favor of the solution defined in https://github.com/ethereum-optimism/optimism/issues/10956