chainhook icon indicating copy to clipboard operation
chainhook copied to clipboard

Genesis block is mostly empty when scanning

Open aulneau opened this issue 1 year ago • 2 comments

Hey all -- question about the data we'd expect to get when scanning blocks from genesis. I'm wondering if this is expected behavior, or not? I know there is some importing of data from v1 that the hiro api is doing. I'd thought that the contract deploys would be included here, but is that also something that you'd have to do manually? cc @rafaelcr

This is my block payload:


    "block": {
      "block_identifier": {
        "hash": "0x918697ef63f9d8bdf844c3312b299e72a231cde542f3173f7755bb8c1cdaf3a7",
        "index": 1
      },
      "metadata": {
        "bitcoin_anchor_block_identifier": {
          "hash": "0x0000000000000000000254567a2521ab99e62b14ad99f5648768a794693391b3",
          "index": 666053
        },
        "confirm_microblock_identifier": null,
        "pox_cycle_index": 0,
        "pox_cycle_length": 2100,
        "pox_cycle_position": 2,
        "stacks_block_hash": "0x6b2c809627f2fd19991d8eb6ae034cb4cce1e1fc714aa77351506b5af1f8248e"
      },
      "parent_block_identifier": {
        "hash": "0x55c9861be5cff984a20ce6d99d4aa65941412889bdc665094136429b84f8c2ee",
        "index": 0
      },
      "timestamp": 0,
      "transactions": [
        {
          "metadata": {
            "description": "coinbase",
            "execution_cost": {
              "read_count": 0,
              "read_length": 0,
              "runtime": 0,
              "write_count": 0,
              "write_length": 0
            },
            "fee": 0,
            "kind": {
              "type": "Coinbase"
            },
            "nonce": 0,
            "position": {
              "index": 0
            },
            "raw_tx": "0x00000000010400405561bc3bafa7e9f4f56149cb4a4cbcf8bc0f7d0000000000000000000000000000000000011761127ca20b264f1adec67318574ec2583395fdfb4ecdc8297def450fe7687a6fcc4f1d8dc7d3342c4414f30e654f9e3ca03a75da49f14cb31a55eb4b9d862901020000000004466f72776172642074686520466f756e646174696f6e21000000000000000000",
            "receipt": {
              "contract_calls_stack": [],
              "events": [],
              "mutated_assets_radius": [],
              "mutated_contracts_radius": []
            },
            "result": "(ok true)",
            "sender": "SP105ARDW7EQTFTFMYNGMKJTA9JYFHF0FFMW9K815",
            "sponsor": null,
            "success": true
          },
          "operations": [],
          "transaction_identifier": {
            "hash": "0x73dd0f3c2915dd25936c5c52598498c1d4089fe6f043bd414346a0895dc0fe87"
          }
        }
      ]
    }

aulneau avatar Nov 02 '24 19:11 aulneau

I don't have a solution to offer, but I can give some context:

The genesis block (at block height 1) doesn't actually include the genesis data (i.e. boot contract-deploys and genesis STX transfers). An older version of stacks-core used to include all this genesis data in block 1, but then a later version of stacks-core changed that behavior and introduced a "block 0" in order to include all the genesis data.

The stacks-blockchain-api detects the "block 0" data and merges it into block 1 in order to prevent breaking changes for clients. However, my guess is that chainhook isn't aware of the block 0 behavior and/or chainhook isn't merging block 0 data into block 1.

zone117x avatar Nov 11 '24 17:11 zone117x

I see, that makes sense. So is it the case that there is technically a "block 0"? because I've tried to set a chainhook predicate to start at 0, but chainhook fails to process that. is that expected?

aulneau avatar Nov 11 '24 17:11 aulneau