Interop: block building (sequencer update)

[tynes]

Update the block building code in op-geth to use the superchain backend to validate executing messages. It should work with unsafe messages since we are optimizing for low latency.

This looks like adding an RPC client for op-supervisor into the op-geth block building code here that drops transactions that include invalid executing messages. If a block is built that includes an invalid executing message, it will result in the block being considered invalid. See ethereum-optimism/specs#128 (comment) for some thoughts on the topic.

The block-building and tx-pool invalidation code must be covered in op-e2e tests.

On PBS API

We want to add in a PBS API per ethereum-optimism/specs#116. We don't need to utilize the PBS API as part of interop directly. If we did want to utilize it, we would fork op-geth into op-geth-interop and add the block building code there and then use that geth to build blocks. This seems like it just adds extra infra + dev requirements that aren't necessary, its easier to just add the diff to op-geth directly

[axelKingsley]

We want to add in a PBS API per ethereum-optimism/specs#116. We don't need to utilize the PBS API as part of interop directly. If we did want to utilize it, we would fork op-geth into op-geth-interop and add the block building code there and then use that geth to build blocks. This seems like it just adds extra infra + dev requirements that aren't necessary, its easier to just add the diff to op-geth directly

Totally agree, PBS would be the location for this work, but wouldn't change the work significantly.

Another way of framing this is that filtering out invalid "executing messages" is a matter of protocol, not of policy. Therefore, delivering only protocol-acceptable transactions to the block builder is a concern which lives outside of the block builder.

[tynes]

I believe we will want a similar architecture to what is used today - a set of sentry nodes that receive inbound transactions and forward them to the sequencer. These sentry nodes would be configured to execute the transactions when entering the mempool, look for ExecutingMessage events and check them against op-supervisor before accepting them into the mempool and forwarding the transactions to the sequencer. The sequencer would still need to double check when building the block due to the system being eventually consistent. Not ideal but works