After the recent changes in the RLP code of alloy_consensus::Header, the following code fails due to an invalid RLP encoding:
let provider = ProviderBuilder::new().on_anvil();
let block = provider.get_block_by_number(0.into(), false).await.unwrap().unwrap();
let header: alloy_consensus::Header = block.header.try_into().unwrap();
// RLP encode and decode the header
let rlp = alloy_rlp::encode(&header);
alloy_consensus::Header::decode(&mut &rlp[..]).expect("should decode");
This is because the Anvil RPC (observed in various versions including the latest nightly) returns a block that includes blobGasUsed and excessBlobGas, but notwithdrawalsRoot. This may be inconsistent or even wrong behavior by Anvil, but I raise it here first because this code worked in previous versions of alloy.
I would like to raise awareness about whether this particular response case should be handled in alloy, or if a failing try_into etc. would be the desired behavior.
klkvr
commented
4 weeks ago
Component
consensus, eips, genesis
What version of Alloy are you on?
alloy-consensus v0.5.4
Operating System
None
Describe the bug
After the recent changes in the RLP code of
alloy_consensus::Header, the following code fails due to an invalid RLP encoding:This is because the Anvil RPC (observed in various versions including the latest nightly) returns a block that includes
blobGasUsedandexcessBlobGas, but notwithdrawalsRoot. This may be inconsistent or even wrong behavior by Anvil, but I raise it here first because this code worked in previous versions ofalloy.I would like to raise awareness about whether this particular response case should be handled in
alloy, or if a failingtry_intoetc. would be the desired behavior.