Skip to content

feat: txpool service #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

feat: txpool service #7

wants to merge 1 commit into from

Conversation

tynes
Copy link
Contributor

@tynes tynes commented May 13, 2024

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.

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.
also act as a first level of checking before the transactions reach full nodes.

## Implementation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should add this this needs rate limiting on the number of RPC requests it sends out and also can run with proxyd to load balance remote requests against a consistent backend

@tynes
Copy link
Contributor Author

tynes commented May 14, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

tynes commented Jun 18, 2024

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.

Drawing 2

@tynes
Copy link
Contributor Author

tynes commented Jun 19, 2024

Closing this in favor of the solution defined in ethereum-optimism/optimism#10956

@tynes tynes closed this Jun 19, 2024
@tynes tynes deleted the feat/txpool branch June 19, 2024 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants