Open tynes opened 5 months ago
May I work on this issue?
May I work on this issue?
Sure - can we work on a small design doc here before starting? It should include specifics around the implementation, like an overview of what the diff would look like. Just to make sure we know the full scope of the problem.
Cool, will work on it. Can you please share your Telegram ID for smooth discussion?
Please follow up with a design doc directly in this thread, we are not at a stage where we can provide individual support
This is a duplicate of https://github.com/ethereum-optimism/optimism/issues/10890
https://github.com/ethereum-optimism/op-geth/pull/422
Here's an implementation which should reject transactions from the mempool as they enter if any "Ingres Filters" should deny the Tx. The one Igress Filter I wrote gets the logs from execution and passes them through the Supervisor.
Since the validity of an interop block depends on the invariant that all executing messages must have valid initiating messages and it requires execution to find the executing messages, this creates a denial of service risk for the sequencer/block builder. The best way to fight denial of service attacks is with horizontal scalability. An approach was proposed in https://github.com/ethereum-optimism/design-docs/pull/7 but it was ultimately decided that we do not want to introduce more microservices into the architecture.
Instead we can take the approach of adding some logic directly into the
op-geth
mempool. Ifop-geth
is configured with theop-supervisor
RPC URL, then the mempool will execute the inbound transaction on thelatest
state and then check against the supervisor that each executing message has a valid initiating message before adding the transaction to the mempool. This allows a simple cloud architecture where sentry nodes can be deployed in front of the sequencer and provide the denial of service protection.