1

I came across a weird situation when checking blocks through the RPC of the ghostnet SmartPy public node. A block that should not exist is returned by the RPC.

On Ghostnet, the block at level 1960484 has the hash : BMDh9XL14gy78rP9wXK4exeQZ7LhaejdDjPuZ69wj443iajYEQR

We can see this with an indexer like tzkt.io or tzstat.com

https://ghostnet.tzkt.io/1960484

https://ghost.tzstats.com/1960484

But when I try accessing the block with a different hash "BMHQcH1HYGmxzY11b15B2QgRgWfC4DEgYY8jQsozC87bXwMRzPi", SmartPy's RPC returns a response as if the block exists on the blockchain and has the same level 1960484:

https://ghostnet.smartpy.io/chains/main/blocks/BMHQcH1HYGmxzY11b15B2QgRgWfC4DEgYY8jQsozC87bXwMRzPi

{
    "protocol": "PtLimaPtLMwfNinJi9rCfDPWea8dFgTZ1MeJ9f1m2SRic6ayiwW",
    "chain_id": "NetXnHfVqm9iesp",
    "hash": "BMHQcH1HYGmxzY11b15B2QgRgWfC4DEgYY8jQsozC87bXwMRzPi",
    "header": {
        "level": 1960484,
        "proto": 5,
        "predecessor": "BM1LvzK6nGdMu6D5wMtSVbGDD96ya7xEFqsWQAHBgAuYVPGnR6K",
        "timestamp": "2023-02-09T10:00:25Z",
        "validation_pass": 4,
        "operations_hash": "LLoa7QoohR11U94rGPCVwJjoRJCF5UKGQ3PM3mnStU5aLSq6iYwYw",
        "fitness": ["02", "001dea24", "00000000", "ffffffff", "00000001"],
        "context": "CoVHiyy29nseb45t1rja3YdgyJuoJhs2nMFyJ5Fb52D9pwsU9eue",
        "payload_hash": "vh2MLtTmfwsLo4CZ3mVWNwTk4brL28eRc3ubg9M4xCP5FHiYHoWc",
        "payload_round": 0,
        "proof_of_work_nonce": "763259c596ae0500",
        "liquidity_baking_toggle_vote": "pass",
        "signature": "sigrwKoa5nqtnTsviwv1HBVZhHG76R2N8sKaFw4VhQsANidufsz7vspPErWyXD54j3F9iuUmT9uFmRzx2zZdzt5ttSQ73D3K"
    },
    [...]

Indexers will not find it:

https://ghostnet.tzkt.io/BMHQcH1HYGmxzY11b15B2QgRgWfC4DEgYY8jQsozC87bXwMRzPi

https://ghost.tzstats.com/BMHQcH1HYGmxzY11b15B2QgRgWfC4DEgYY8jQsozC87bXwMRzPi

Even more strange, using the other RPC endpoint with the level of the block I get the real block:

https://ghostnet.smartpy.io/chains/main/blocks/1960484

{
    "protocol": "PtLimaPtLMwfNinJi9rCfDPWea8dFgTZ1MeJ9f1m2SRic6ayiwW",
    "chain_id": "NetXnHfVqm9iesp",
    "hash": "BMDh9XL14gy78rP9wXK4exeQZ7LhaejdDjPuZ69wj443iajYEQR",
    "header": {
        "level": 1960484,
        "proto": 5,
        "predecessor": "BM1LvzK6nGdMu6D5wMtSVbGDD96ya7xEFqsWQAHBgAuYVPGnR6K",
        "timestamp": "2023-02-09T10:00:10Z",
        "validation_pass": 4,
        "operations_hash": "LLoat5GyXUGUe5vYNx82aZGRGzcKFiu5Ns9u495V1HDv1kh59zLyy",
        "fitness": ["02", "001dea24", "", "ffffffff", "00000000"],
        "context": "CoVcZjRwvNMN3wgjQp89JC2xGoz6KMJnGLqVdBh3RyhhAKyXdEnt",
        "payload_hash": "vh2MLtTmfwsLo4CZ3mVWNwTk4brL28eRc3ubg9M4xCP5FHiYHoWc",
        "payload_round": 0,
        "proof_of_work_nonce": "a8a325a1b53c0200",
        "liquidity_baking_toggle_vote": "pass",
        "signature": "sigjpwkkN1BvgVnwwWKaPP9eMPj6bf3TareSGKvGYSJtkNhxtTx3qsYX6WKuBFfWLimu1fdMa7sy6rxDnSXeUPN3RyV7Vv79"
    },
    [...]

2 Answers 2

2

It turns out my problem is a normal behaviour of a Tezos node.

The case I mention is typical when there are several blocks proposed at the same level (for example if the first proposed block did not get enough endorsements, and a second baker is then allowed to propose a new block).

By default, the node keeps the orphaned block(s) in memory for 5 cycles (which explains why you can find an orphaned block by requesting it from the node, with its hash). One of the reasons for this is that we want to be able to refer to these (orphaned) blocks if a double baking/endorsement operation is found.

1

Sorry, your problem is not repeatable as the node is in rolling mode and the block is not in the node anymore. I suggest you to close this question or to bring another example if you can find one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.