Arbitrum integration: Handle Invalid Transactions

[sveitser]

The arbitrum sequencers are expected to remove invalid transactions because any valid transactions will lead to the whole batch being dropped. At least until we have builders we need to prevent this from happening for demo purposes.

Experiments

To better compliment our theoretical understanding do some experiments and inspect how the arbitrum components behave. Is the transaction filtered? Does anything panic? etc.

1. Malformed TX (fails to deserialize): submit a tx with a payload that can't be deserialized into an Ethereum transaction for example [1, 2, 3] with the correct VM ID (I think it's 100) of the rollup to the local sequencer. E. g. something like

curl -v -H "Content-Type: application/json" --data '{"vm": 100, "payload": [1,2,3] }' http://localhost:50000/submit/submit

2. Duplicate TX: send a valid transaction twice. This might be happening anyway because the sequencer often tends to sequence the same transaction a few times.

It may be beneficial to figure out how to turn on more verbose logging for arbitrum. We should know how to do this anyway so whoever figures it out please document it somewhere.

Document the results here, or on notion with a link to the document here.

Implementation

• Figure out where and how to filter the invalid transactions.

Requirements:

1. It should happen inside the wasm VM. I think this is required for proving to work because otherwise we can't verify the executed transactions against the sequencer's commitment in the wasm VM because we no longer have all the transactions. Let me know if you disagree @ImJeremyHe @nomaxg .
2. An invalid transaction in an espresso block should not make the entire rollup block invalid. This is important because contrary to nitro we don't have a sequencer that is expected to filter out invalid transaction before making a batch. Until we have a builder invalid transactions will be common.

Related

PR to workaround the same issue for the OP integration. Note however, that the requirement about the WASM VM didn't apply.

• Discard invalid transactions from blocks, but keep them in the batch op-geth#2

Zulip thread.

[ImJeremyHe]

A fix here for discarding malformed transactions:
EspressoSystems/nitro-espresso-integration#14

As for other invalid transactions, I think arbitrum itself has already solved them.

The sequencer uses arbos.ProduceBlockAdvanced to produce a block. This function validates the tx before appending a block to the chain. And there is a simlar function named arbos.ProduceBlock producing blocks from messages.
I will figure out the relationship between transaction and message and document it.

But it seems that invalid transactions are all handled before creating a block and I will have a look at whether we should handle the invalid message.

Please let me know if I have any misunderstanding.