Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Genesis block is mostly empty when scanning #679

Open
aulneau opened this issue Nov 2, 2024 · 2 comments
Open

Genesis block is mostly empty when scanning #679

aulneau opened this issue Nov 2, 2024 · 2 comments
Assignees

Comments

@aulneau
Copy link

aulneau commented Nov 2, 2024

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"
          }
        }
      ]
    }
@zone117x
Copy link
Member

zone117x commented Nov 11, 2024

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.

@aulneau
Copy link
Author

aulneau commented Nov 11, 2024

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?

@smcclellan smcclellan assigned rafaelcr and unassigned zone117x Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🆕 New
Development

No branches or pull requests

3 participants