Incorrect totalDifficulty value

[sjmini]

Description

When we execute the attached test case, the output states that the totalDifficulty is "0", which seems an incorrect value.

Steps to Reproduce (Bug)

1. Download test files test_cases.zip

2. Run the node with the following command besu --data-path test_cases/data-besu --genesis-file test_cases/besu.json --rpc-http-port 8549 --rpc-http-enabled --rpc-http-api ETH --network-id 15 --discovery-enabled false

3. Execute the javascript test case test1.js

Expected behavior: [What you expect to happen] Returns the correct totalDifficulty value.

Actual behavior: [What actually happens] totalDifficulty is 0

Frequency: [What percentage of the time does it occur?] Always

Versions (Add all that apply)

• Software version: besu/v22.4.4/linux-x86_64/openjdk-java-16
• OS Name & Version: Ubuntu 20.04.4 LTS

[non-fungible-nelson]

Hi there - can you paste In the test-case in the issue? depending on your genesis (and network) no TTD will be passed. 22.4.4 does not have all of our TTD configs in place.

[sjmini]

Hi, @non-fungible-nelson

Below is the test case that led to the issue.

const Web3 = require("web3"); 
const web3_besu = new Web3("http://localhost:8549");
(async () => {
  async function besu() {
        try {
            let aa0 = "0x4ea43ec4e28ce7b4ae567f42928f26dc4e183dfd1fadb17c37d170ab4e24d52a";
            let aa1 = 0;
            let aa2 = false;
            return await web3_besu.eth.getUncle(aa0, aa1, aa2);
        } catch (error) {
            return "[ERROR] " + error.message;
        }
    }
    let rv = await besu(); 
    console.log(rv);
})();

Below is the genesis json file that we used to construct test network.

{
    "config": {
        "chainId": 15,
        "homesteadBlock": 0,
        "daoForkSupport": false,
        "eip150Block": 0,
        "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "eip155Block": 0,
        "eip158Block": 0,
        "byzantiumBlock": 0,
        "constantinopleBlock": 0,
        "petersburgBlock": 0,
        "istanbulBlock": 0,
        "muirGlacierBlock": 0,
        "berlinBlock": 0,
        "londonBlock": 1,
        "ethash": {}
    },
    "difficulty": "1",
    "gasLimit": "8000000",
    "nonce": "0x0000000000000000",
    "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "coinbase": "0x0000000000000000000000000000000000000000",
    "timestamp": "0x0",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "extraData": "",
    "alloc": {
        "0x91c94e565750a50E1b0d0779De01823E8F4D20f2": {
            "balance": "850000000000000000000"
        }
    }
}

You can find the test network that we have constructed (data-besu.tar) from the attached zip file (test_cases.zip).

If we execute the above test case, Besu client returns "0" for the totalDifficulty field. I'm wondering if this is an expected behavior of the Besu client. I would appreciate your comments on this matter.

[sjmini]

Any comments or suggestions on this issue would be appreciated.

[non-fungible-nelson]

Hi @sjmini - can you try specifying the milestone blocks? The docs here have more info: https://besu.hyperledger.org/en/stable/public-networks/reference/genesis-items/#milestone-blocks

This might fix your issue, please let me know if this is not the case.

[non-fungible-nelson]

I'd also recommend updating to 22.7.1

[sjmini]

@non-fungible-nelson Thank you for the suggestions. Unfortunately, the problem still occurs even though I specified the 0 for the milestone block, and updating to 22.7.1 doesn't solve this problem.

[non-fungible-nelson]

Bumping this up.

[Gabriel-Trintinalia]

Geth does not track totalDifficulty for non-canonical blocks. https://github.com/ethereum/go-ethereum/issues/25505#issuecomment-1215127020

Can someone confirm if Besu has the same behaviour?

[mark-terry]

Besu does not calculate totalDifficulty for ommer blocks - the difficulty is explicitly set to 0. See: UncleBlockResult.java:36

Given ommers shouldn't be a concern post-merge, it's probably not worth updating. I'll close this ticket.