reth: Stader Guardian is unable to send tx

Describe the bug

Sending tx via Stader Guardian fails. Pointing the app at a partial Geth archive instead works.

Tested with a Reth archive on Ethereum mainnet. Output from Stader Guardian:

New Exchange Rate data: {19072800 75029479908760713110197 73570042123220188356194}
Old Exchange Rate data: {19065600 75677193647928469732705 74211565812785576762603}
Submitting Exchange Rate price: {19072800 75029479908760713110197 73570042123220188356194}
Submitted transaction hash: 0x34fc20e1793965c22c83f9dd3e3a71f8c6954485e54f4e0b2001dd7733d0c73c
2024/01/24 11:24:44 failed to submit Exchange Rate: failed to check transaction status: transaction receipt not found after 10 minutes

Steps to reproduce

Run any Stader Guardian duty against an archive Reth

Node logs

Debug logs are long. Please download from https://www.dropbox.com/scl/fi/811e6vfylw9jxsln2r5x5/reth-debug.txt?rlkey=63qvr4awlysuzwk9lboq7eemd&dl=0

Search for 0x34fc20e1793965c22c83f9dd3e3a71f8c6954485e54f4e0b2001dd7733d0c73c then go up a little to see the estimateGas, and the sendRawTransaction is right after that.

Platform(s)

Linux (x86)

What version/commit are you on?

reth Version: 0.1.0-alpha.16 Commit SHA: d8a9b58 Build Timestamp: 2024-01-23T16:43:42.089594260Z Build Features: Build Profile: maxperf

What database version are you on?

What type of node are you running?

Archive (default)

What prune config do you use, if any?

None

If you’ve built Reth from source, provide the full command you used

No response

Code of Conduct

I agree to follow the Code of Conduct

About this issue

Original URL
State: closed
Created 5 months ago
Comments: 17 (10 by maintainers)

Most upvoted comments

upon closer inspection the geth implementation also does: find the highest nonce in the pool + 1 for eth_getTransactionCount(Pending)

so still unclear what caused the high nonce here…

mattsse on Jan 31, 2024

I see, this is slightly different than what reth does

https://github.com/ethereum/go-ethereum/blob/f55a10b64d511b27beb02ff4978a6ed66d604cd8/core/txpool/txpool.go#L334-L342

will get this fixed by mirroring geth, but I’m trying to find more info in the spec

mattsse on Jan 24, 2024

Oh interesting

eth-main-execution-1  | 2024-01-24T11:14:44.892422Z TRACE jsonrpsee_core::http_helpers: HTTP response body: {"jsonrpc":"2.0","id":7643,"method":"eth_getTransactionCount","params":["0x561b5893f3de795dfd270d20b24d11ba5e05e696","pending"]}
eth-main-execution-1  | 2024-01-24T11:14:44.892429Z TRACE method_call{method="eth_getTransactionCount"}: jsonrpsee_core::tracing: recv="{\"jsonrpc\":\"2.0\",\"id\":7643,\"method\":\"eth_getTransactionCount\",\"params\":[\"0x561b5893f3de795dfd270d20b24d11ba5e05e696\",\"pending\"]}"
eth-main-execution-1  | 2024-01-24T11:14:44.892436Z TRACE method_call{method="eth_getTransactionCount"}: jsonrpsee_types::params: [next_inner] Params JSON: "[\"0x561b5893f3de795dfd270d20b24d11ba5e05e696\",\"pending\"]"
eth-main-execution-1  | 2024-01-24T11:14:44.892444Z TRACE method_call{method="eth_getTransactionCount"}: jsonrpsee_types::params: [next_inner] Params JSON: ",\"pending\"]"
eth-main-execution-1  | 2024-01-24T11:14:44.892465Z TRACE method_call{method="eth_getTransactionCount"}: jsonrpsee_core::tracing: send="{\"jsonrpc\":\"2.0\",\"result\":\"0x2f4\",\"id\":7643}"

then the raw is submitted with same nonce 0x2f4 756

EDIT you were faster hehe

okay so this nonce is weirdly high, which makes me think that there’s something off with the implementation for the pending tag, need to check geth’s logic

mattsse on Jan 24, 2024