[Bug] Fail to deserialize 7702 transactions on Mekong

[iankressin]

Component

rpc

What version of Alloy are you on?

0.6.4

Operating System

macOS (Apple Silicon)

Describe the bug

Fetching a EIP-7702 transactions from Mekong testnet using the method provider.get_transaction_by_hash, results in a deserialization error below.

async fn fetch_7702_tx(
    provider: &RootProvider<Http<Client>>,
) -> Result<(), Box<dyn std::error::Error>> {
    let transaction = provider
        .get_transaction_by_hash(b256!(
            "adc3f24d05f05f1065debccb1c4b033eaa35917b69b343d88d9062cdf8ecad83"
        ))
        .await?;

    println!("{:?}", transaction);

    Ok(())
}

Error logs:

Error: DeserError { err: Error("data did not match any variant of untagged enum MaybeTaggedTxEnvelope", line: 1, column: 948), text: "{\"blockHash\":\"0xb14eac260f0cb7c3bbf4c9ff56034defa4f566780ed3e44b7a79b6365d02887c\",\"blockNumber\":\"0xb022\",\"from\":\"0x6d2d4e1c2326a069f36f5d6337470dc26adb7156\",\"gas\":\"0xf8ac\",\"gasPrice\":\"0xe07899f\",\"maxFeePerGas\":\"0xe0789a0\",\"maxPriorityFeePerGas\":\"0xe078998\",\"hash\":\"0xadc3f24d05f05f1065debccb1c4b033eaa35917b69b343d88d9062cdf8ecad83\",\"input\":\"0x\",\"nonce\":\"0x1a\",\"to\":\"0x6d2d4e1c2326a069f36f5d6337470dc26adb7156\",\"transactionIndex\":\"0x0\",\"value\":\"0x0\",\"type\":\"0x4\",\"accessList\":[],\"chainId\":\"0x1a5ee289c\",\"authorizationList\":[{\"chainId\":\"0x1a5ee289c\",\"address\":\"0x529f773125642b12a44bd543005650989eceaa2a\",\"nonce\":\"0x1a\",\"v\":\"0x0\",\"r\":\"0x9b3de20cf8bd07f3c5c55c38c920c146f081bc5ab4580d0c87786b256cdab3c2\",\"s\":\"0x74841956f4832bace3c02aed34b8f0a2812450da3728752edbb5b5e1da04497\"}],\"v\":\"0x1\",\"r\":\"0xb3bf7d6877864913bba04d6f93d98009a5af16ee9c12295cd634962a2346b67c\",\"s\":\"0x31ca4a874afa964ec7643e58c6b56b35b1bcc7698eb1b5e15e61e78b353bd42d\",\"yParity\":\"0x1\"}" }

For other transaction types (Legacy and 4844), the method works as expected.

I've tested for the following transactions:

• 7702 (error): 0xadc3f24d05f05f1065debccb1c4b033eaa35917b69b343d88d9062cdf8ecad83
• 4844 (success): 0x127aeaeb1ddc81ade042d3a4e4e6fe907885db8a563c1d1dbd537c0e050ba952
• Legacy (success): 0x987a287073082584307615363e7802b72020cc9a55cbbadd1894dde0d2bee9f1

The same also happens for provider.get_block_by_number passing a block containing a 7702 transaction, in this case block 45090 and BlockTransactionsKind::Full

async fn fetch_block_with_7702_tx(
    provider: &RootProvider<Http<Client>>,
) -> Result<(), Box<dyn std::error::Error>> {
    let block = provider
        .get_block_by_number(BlockNumberOrTag::Number(45090), BlockTransactionsKind::Full)
        .await?;

    println!("{:?}", block);

    Ok(())
}

Error logs: Can be found here due to Github's character restriction.

The deserialization errors doesn't occur for get_block_by_number when the block specified doesn't contain any type 4 transactions.

A minimal reproduction can be found here

[mattsse]

this is an issue with v field of the signed auth, imo this should be yParity but unsure if there's an rpc spec for this already

cc @klkvr

[mattsse]

yeah... https://github.com/ethereum/execution-apis/issues/561

[klkvr]

yeah iirc geth serializes this as v

[mattsse]

@iankressin you can fix this by bumping alloy-eip7702 to 0.4.1

[iankressin]

Works perfectly now! Thanks @mattsse @klkvr.