Regression: "Failed to decode transaction"

[kayabaNerve]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

Latest

What command(s) is the bug in?

No response

Operating System

Linux

Describe the bug

Since 4 days ago, the version of anvil downloaded by installing foundryup via the script at https://foundry.paradigm.xyz (and then running it) has yielded

ErrorResp(ErrorPayload { code: -32602, message: "Failed to decode transaction", data: None })

when I run the following block of code:

        let provider = RootProvider::<_, Ethereum>::new(
          ClientBuilder::default().transport(SimpleRequest::new(rpc_url.clone()), true),
        );
        let _ = provider.send_raw_transaction(tx).await.unwrap();

The tx value in that case is an opaque byte array generated as follows:

        let tx = TxLegacy {
          chain_id: None,
          nonce: *nonce,
          gas_price: 1_000_000_000u128,
          gas_limit: 200_000u128,
          to: TxKind::Call(router_addr.into()),
          // 1 ETH
          value: one_eth,
          input: ethereum_serai::router::abi::inInstructionCall::new((
            [0; 20].into(),
            one_eth,
            if let Some(instruction) = instruction {
              Shorthand::Raw(RefundableInInstruction { origin: None, instruction }).encode().into()
            } else {
              vec![].into()
            },
          ))
          .abi_encode()
          .into(),
        };

        *nonce += 1;

        let sig =
          k256::ecdsa::SigningKey::from(k256::elliptic_curve::NonZeroScalar::new(*key).unwrap())
            .sign_prehash_recoverable(tx.signature_hash().as_ref())
            .unwrap();

        let mut bytes = vec![];
        tx.encode_with_signature_fields(&Signature::from(sig), &mut bytes);

You can observe this failure in my CI: https://github.com/serai-dex/serai/actions/runs/11162161674/job/31026214470 (where the commit prior worked, and this commit didn't touch any of our work with Ethereum).

This obviously isn't a MRE and I apologize for that. I just wanted to file this ASAP until I have time to poke more later. I didn't see any filed issues/open PRs recently which seems to be relevant here. Off-hand, I have some loose guess this a quirk with publishing legacy TXs (outside of an envelope) but I truly don't know. https://github.com/serai-dex/serai//blob/55fb8a588922dcae8a13a6f269fc98f9c2843e1b/Cargo.lock#L102-L507 for my alloy versions, which is 0.3 for the non-core libs and not yet 0.4 (which may be of relevance here).

[yash-atreya]

This should be fixed by alloy-rs/alloy#1428 which will be available in the next alloy release

[klkvr]

@yash-atreya alloy-rs/alloy#1428 only fixed into_signed fn. If incorrect signature is passed directly to encode_with_signature_fields (like in this example), this would still result in incorrect encoding. do we want to handle it there instead?

[kayabaNerve]

If incorrect signature is passed directly to encode_with_signature_fields (like in this example),

Sorry, what did I do which was incorrect? I'm not saying my code is absolutely 100% correct, yet the above seems without issue to me. I'm not manually specifying any recovery ID value. I also am specifying one (one is returned by sign_prehash_recoverable and is accordingly passed into Signature::from).

This also was accepted by anvil in the past (meaning if this was an invalid encoding, which it sounds like it was, there's also an invalid decoding/validation issue which has yet to be linked here).

[klkvr]

If incorrect signature is passed directly to encode_with_signature_fields (like in this example),

Sorry, what did I do which was incorrect? I'm not saying my code is absolutely 100% correct, yet the above seems without issue to me. I'm not manually specifying any recovery ID value. I also am specifying one (one is returned by sign_prehash_recoverable and is accordingly passed into Signature::from).

This also was accepted by anvil in the past (meaning if this was an invalid encoding, which it sounds like it was, there's also an invalid decoding/validation issue which has yet to be linked here).

when converting k256 signature from sign_prehash_recoverable to alloy's signature, RecoveryId is getting converted to a boolean parity https://github.com/alloy-rs/core/blob/172aa98d4c0d20b0f1fe1812a8d378d7005a4011/crates/primitives/src/signature/parity.rs#L28, because we don't know anything about the transaction type when converting it. this boolean value ends up being rlp encoded, resulting in invalid legacy transaction encoding because it is expected to encode as either 27 or 28

this error didn't occur earlier because we've only recently enforced this in alloy during decoding

[kayabaNerve]

Hm. I think I'd label that an issue with encode_with_signature_fields but sounds like it'll be on me to handle (at least for now). Thank you for the context. Sorry that it appears I've opened issues re: alloy in foundry.

[klkvr]

Tracking in alloy-rs/alloy#1510, should be fixed soon by alloy-rs/core#776