-
Notifications
You must be signed in to change notification settings - Fork 2
Description
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.