Skip to content

On deserialization error: invalid value: string "0x2d79dd80ff729c000" #33

@0xOmarA

Description

@0xOmarA

When running transactions against kitchensink the flow (not the tx submission itself, but somewhere in the flow) fails with the following error:

2025-07-11T06:25:15.322799Z ERROR alloy_provider::blocks: failed to fetch block, number: 0, err: deserialization error: invalid value: string "0x2d79dd80ff729c000", expected a 8 byte hex string at line 1 column 1369
    at alloy-provider-1.0.9/src/blocks.rs:164 on tokio-runtime-worker ThreadId(81)
    in revive_dt_node::geth::Submitting transaction with transaction: TransactionRequest { from: Some(0x90f8bf6a479f320ead074411a4b0e7944ea8c9c1), to: Some(Create), gas_price: Some(5000000), max_fee_per_gas: None, max_priority_fee_per_gas: None, max_fee_per_blob_gas: None, gas: Some(5000000), value: None, input: TransactionInput { input: Some(0x36303830383036303430353233343630313435373562363065323930383136303139383233396633356235663830666466653630383036303034333631303135363030653537356235663830666435623566333536306530316336333039613331656134313436303231353735623566383066643562333436306138353735623630323036303033313933363031313236306134353735623336363032333132313536306130353735623630323038313031383138313130363766666666666666666666666666666666383231313137363038633537356236303430353238303930333636303234313136303838353735623630323039313630303439303562363032343832313036303739353735623530353035313630343035313930383135326633356238333830393138333335383135323031393130313930363036363536356235663830666435623633346534383762373136306530316235663532363034313630303435323630323435666664356235663830666435623566383066643562356638306664666561323634363937303636373335383232313232303736636533313630616337646137326631373331633936613464343965636136653263363663326464633866393436646338393239623430656666303265303636343733366636633633343330303038316430303333), data: None }, nonce: Some(0), chain_id: Some(420420420), access_list: None, transaction_type: None, blob_versioned_hashes: None, sidecar: None, authorization_list: None }

Digging a little bit more in the logs, we can see that this was the JSON response of the RPC when alloy was attempting to get information about a certain block, which we can see here:

2025-07-11T06:32:45.956011Z TRACE alloy_json_rpc::result: deserializing response, ty: core::option::Option<alloy_rpc_types_eth::block::Block>, json: {"baseFeePerGas":"0x3e8","difficulty":"0x0","extraData":"0x","gasLimit":"0x2d79dd80ff729c000","gasUsed":"0x0","hash":"0x3c2026eabebb20d6727479c2dbe522748566a2abdcba39e31fc5bb7a78da79f5","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","miner":"0x0000000000000000000000000000000000000000","mixHash":"0x0000000000000000000000000000000000000000000000000000000000000000","nonce":"0x0000000000000000","number":"0x0","parentHash":"0x0000000000000000000000000000000000000000000000000000000000000000","receiptsRoot":"0x03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c111314","sha3Uncles":"0x0000000000000000000000000000000000000000000000000000000000000000","size":"0x0","stateRoot":"0xa6928950b301794fda56c470dd79d9e4869afb92a9ef8f868bab3d29a32fab05","timestamp":"0x0","transactions":[],"transactionsRoot":"0x03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c111314","uncles":[]}
    at alloy-json-rpc-1.0.9/src/result.rs:63 on tokio-runtime-worker ThreadId(92)
    in revive_dt_node::geth::Awaiting transaction receipt with transaction_hash: 0xce436093b27ecf1f1c6b65a0458dc8a9a059470b54e996b858ede8d1e344b932
    in revive_dt_node::geth::Submitting transaction with transaction: TransactionRequest { from: Some(0x90f8bf6a479f320ead074411a4b0e7944ea8c9c1), to: Some(Create), gas_price: Some(5000000), max_fee_per_gas: None, max_priority_fee_per_gas: None, max_fee_per_blob_gas: None, gas: Some(5000000), value: None, input: TransactionInput { input: Some(0x363038303830363034303532333436303136353735623631303133323930383136313030316238323339663335623566383066646665363038303830363034303532363030343336313031353630313235373562356638306664356235663335363065303163363364373364333666373134363032353537356235663830666435623334363066383537356236303430363030333139333630313132363066343537356233363630323431313630663035373562363032343335363030313830363061303162303338313136383039313134313536306563353735623831363032343831363032303933363330323638633761393630653231623832353238343630303438303834303133373561666138303135363065313537356235663930363038333537356236303230393036303430353139303831353266333562353036303230336436303230313136306462353735623630316631393630316638323031313638323031383238313130363766666666666666666666666666666666383231313137363063373537356236303230393138333931363034303532383130313033313236306333353735623630323039303531363037383536356235663830666435623633346534383762373136306530316235663532363034313630303435323630323435666664356235303364363038653536356236303430353133643566383233653364393066643562356638306664356235663830666435623566383066643562356638306664666561323634363937303636373335383232313232303630366562336238376335393562353166306664303736313861376661303735373233313936393135386666646264646564656237313164656666323930316536343733366636633633343330303038316430303333), data: None }, nonce: Some(1), chain_id: Some(420420420), access_list: None, transaction_type: None, blob_versioned_hashes: None, sidecar: None, authorization_list: None }

Sadly, alloy attempts to decode the gasLimit into a u64, which in this case fails since our gasLimit has 9 bytes, which is one more than the 8 bytes that can be represented by a u64. This is despite the EIP mentioning nothing about how many bytes should be in a Quantity.

One way that we can fix this is by adding a custom kitchensink network, which alloy already has support for. We would use identical types for everything except for the gas_limit field of the block, it would use a u128 instead of a u64. I believe that if we did that then this issue of invalid value: string "0x2d79dd80ff729c000", expected a 8 byte hex string would be solved.

Note

I opened this issue just to have a written understanding of the issue, it's causes, and what we can potentially do in order to fix it so that it's not forgotten. Discussion is welcome.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions