Tracing with non archive node

[gkozyryatskyy]

Description

Hello guys! I have a question regarding using besu trace functionality for not an archive node.

Currently I have:

• Besu: --network=sepolia --sync-mode=X_SNAP --data-storage-format=BONSAI ... etc
• Teku: --network=sepolia ... etc
• eth_blockNumber

  
  curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":51}' http://127.0.0.1:8545                                                   

{ "jsonrpc" : "2.0", "id" : 51, "result" : "0x2fefb8" }

- `eth_syncing`

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":51}' http://127.0.0.1:8545

{ "jsonrpc" : "2.0", "id" : 51, "result" : false }

- `trace_replayBlockTransactions`

curl -X POST --data '{"jsonrpc": "2.0", "method": "trace_replayBlockTransactions","params": ["0x2fefb8",["trace","vmTrace","stateDiff"]],"id": 1}' http://127.0.0.1:8545

{ "jsonrpc" : "2.0", "id" : 1, "result" : null }

The question is, why im getting `"result" : null` for `trace_replayBlockTransactions`? 
Doc says:

To use the ad-hoc tracing APIs, the requested block or transaction must be within the number of blocks retained with pruning enabled (by default, 1024).

I believe by `pruning-enabled` means I should use default `--pruning-enabled=false`

So how can I get result with `trace_replayBlockTransactions`? What im doing wrong?
Will be grateful for any help!

### Acceptance Criteria
`trace_replayBlockTransactions` should return the result

### Steps to Reproduce (Bug)
Execute `trace_replayBlockTransactions` on the last block

curl -X POST --data '{"jsonrpc": "2.0", "method": "trace_replayBlockTransactions","params": ["0x2fefb8",["trace","vmTrace","stateDiff"]],"id": 1}' http://127.0.0.1:8545

{ "jsonrpc" : "2.0", "id" : 1, "result" : null }

**Expected behavior:** 
`trace_replayBlockTransactions` should return the result

**Actual behavior:** 
`trace_replayBlockTransactions` return `"result" : null`

**Frequency:** Allways

### Versions (Add all that apply)
* Software version: `besu/v23.1.2/linux-aarch_64/openjdk-java-17`
* Java version: `openjdk-java-17`
* OS Name & Version: docker image `hyperledger/besu:latest`
* Docker Version: 

Server: Docker Desktop 4.17.0 (99724) Engine: Version: 20.10.23

* Consensus Client & Version if using Proof of Stake: `Teku 23.3.1`

[non-fungible-nelson]

This actually is an oversight that needs to be updated in the docs, thank you.

In the case of Bonsai, 'blocks retained' relates to this setting. Pruning means nothing in the context of Bonsai, it is automatically pruned.

Bonsai by default only allows you to query blocks in this range from head. So if you use the default, which is 512, and query a block older than 512 blocks from the head of the chain, Bonsai won't be able to fetch it.

Can you try raising this range and letting me know what result you get? Or tracing a transaction within the last 512 blocks?

[non-fungible-nelson]

I have updated the docs for clarity - closing this. let me know if you have any more issues.

[gkozyryatskyy]

@non-fungible-nelson Thank you for the reply! And sorry for the delay from my side.

Thank you for the explanation of Bonsai. But as I mentioned in original request, Im tracing exactly my last eth_blockNumber so it is "within the last 512 blocks".

• eth_blockNumber return 0x2fefb8 block
• Im requesting trace_replayBlockTransactions with ["0x2fefb8",["trace","vmTrace","stateDiff"]] and getting null as a response

[non-fungible-nelson]

can you paste your exact RPC call? are other calls successful?

[gkozyryatskyy]

@non-fungible-nelson please see first message in this issue. There is an exact RPC call under trace_replayBlockTransactions section

[gkozyryatskyy]

@non-fungible-nelson Yes, other calls like eth_blockNumber and eth_syncing are successful. Responses also in the first message.

[gkozyryatskyy]

@non-fungible-nelson My first guess was that it is because of --sync-mode=X_SNAP, but doc do not say that we need to have an archive node.

[non-fungible-nelson]

To confirm, the sepolia block number you specified is over 100k blocks behind head. Did you update your bonsai flag to be that large? this is a huge number usually not suitable for bonsai but it should work (will require a lot of CPU).

[gkozyryatskyy]

@non-fungible-nelson You right. This is because node is not fully synced.

This is also really the goal of the experiment: "Can I trace the blocks while node is syncing? If yes, I can store the trace results with out having an archive node"

So the "bonsai flag" is not updated, but im checking for eth_blockNumber and trying trace_replayBlockTransactions with it "last available block", expecting this block still have all needed info for the trace.

[non-fungible-nelson]

yes - sounds good. Your initial theory about snap sync was correct. Depending on when you finished your sync, you may not be able to trace that far before, even if you increase the amount on those flags. Forest mode may be better for your use-case.

[gkozyryatskyy]

@non-fungible-nelson Just to make it more clear for me.

1. I have --sync-mode=X_SNAP --data-storage-format=BONSAI node
2. Node is not fully synced and syncing right now
3. While it is synced (before it is fully synced), I cant do the trace_replayBlockTransactions with from eth_blockNumber to eth_blockNumber - 512 block.

But maybe with --data-storage-format=FOREST I will be able to do 3. while sync process? Am I understand you correctly?

Thank you!