t8n crashes on invalid blob tx

[winsvega]

this issue

Error: rlp: input string too short for common.Address, decoding into (types.Transactions)[0](types.BlobTx).To
 (StateTests/stEIP4844-blobtransactions/createBlobhashTx, fork: Cancun, TrInfo: d: 0, g: 0, v: 0, TrData: ` :raw 0x00..`)

is that I managed to crash t8n. instead it should detect malicious transaction and put rejectedTransaction information.

inputs:
https://drive.google.com/file/d/1eVT-FYewYUsg91YrF3ZuCGhtVSRu3jE1/view?usp=drive_link

[holiman]

Ah, wait. I think I know. The input must be valid rlp. Sending non-valid rlp is like feeding non-json to something expecting json. It is a usage error, so t8n exits as it should (not crash)

[winsvega]

It's a valid rlp structure.

Just that blob transaction can't be create transaction. Apparently like intrinsic oog exception.

[holiman]

So, you are correct that it is valid rlp. It's a bit tricky to handle this, though. I'm not sure how to best handle it, because "normally" invalid txs are caught during "apply", when we iteratively apply them to the state.

This error happens much earlier in the pipeline. So if we have three transaction, and reject the first during rlp parsing, at index 0, then hand off the remaining two to "apply", then that part will again number them remaining ones from index 0.

So in order to fix it, we need to pass a list of tuples like ( nil , error), (tx, nil) ... into the apply. Or something like that.

rlp:

0xf8dbb8d903f8d601800285012a05f200833d090080830186a000f85bf85994095e7baea6a6c7c4c2dfeb977efac326af552d87f842a00000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000010ae1a001a915e4d060149eb4365960e6a7a45f334393093061116b197e3240065ff2d880a0fc12b67159a3567f8bdbc49e0be369a2e20e09d57a51c41310543a4128409464a02de0cfe5495c4f58ff60645ceda0afd67a4c90a70bc89fe207269435b35e5b67

[winsvega]

Or use tx hashes?

We can actually make it an exception and handle on test generation tools side.

[holiman]

That is the problem though, this error is so lowlevel that we cannot even figure out a txhash. As far as we're concerned, it's just gibberish

[holiman]

There is evm t8n / evm transition, but there's also evm t9n/evm transaction. The latter is more suited for experimenting with oddball transactions, and checking invalid ones.
Whereas transition is more about state progression. The failure to even parse a transactions:ish looking object from the rlp cannot be handled by t8n in a good manner. It's a failure at the wrong level.

I think it would be better to work around this with the other tooling.

[winsvega]

it is not transaction ish. it is a perfectly valid transaction just that one check is missing. like we already have with intrinsic gas.

[holiman]

If you omit an rlp-field (the to), it will try to parse the to out of the next field, which is the value. The value is a bigint, meaning it has a dynamic-size encoding. So it's a couple of bytes.
So then, we try to read that as to: expecting to read a fixed-size 20-bytes field. And the field is not large enough.

The "overall" rlp structure is valid, yes, but the "local" rlp structure of the blob tx is not valid.

[winsvega]

can at least the t8n drop the transaction with an exception instead of exiting?
because I treat t8n crash as terminal error. the tool must process the input and return the outAlloc.json with invalid transactions dropped.