Legacy chain snapshot

Before Hedgehog existed, the Unigrid foundation ran an earlier blockchain, and its block files are the only record of who held what. The legacy chain snapshot turns that history into one compact, signed file that a Hedgehog node can download, check against the foundation’s keys and use to answer balance and transaction-history questions, without anyone having to trust the host that served the file.

How it works

The snapshot is produced once per release by whoever holds the legacy data directory, and every node afterwards only consumes it.

flowchart LR
    A["Legacy blk*.dat files"] --> B["Link blocks into one chain"]
    B --> C["Replay the chain into balances and history"]
    C --> D["Write snapshot file"]
    D --> E["Foundation key signs it"]
    E --> F["Published with the release"]
    F --> G["Node downloads and verifies it"]

Rebuilding the chain. The legacy daemon kept every block it ever saw, including blocks on branches that lost. Reading the files in order would count coins moved by blocks the network never settled on, so the converter instead links every block to its parent by hash and keeps only the path from the genesis block to the deepest block. In the run that produced the current snapshot, 145,942 of the 3,318,609 stored blocks were discarded this way.

Replaying it. The kept chain is walked block by block to build the balance and the dated history of every address. Coins minted into the zerocoin pool are tallied separately rather than credited to an address.

The file. The result is a single file laid out so that it can be memory-mapped. Addresses are sorted by hash, so a balance lookup is a binary search, and each address’s history is one contiguous run of entries. Nothing is loaded into the heap, and a lookup does not read the whole file.

Signing. Signing hashes the file with SHA-512 and signs the digest with an ECDSA key on the P-521 curve. The signature is appended after the content, so an unsigned local rebuild and the signed release file are identical over everything they share. Anyone can therefore rebuild the snapshot from the legacy data and compare it with the published one. A node reports a snapshot as signed only if the signature verifies against one of the four foundation board keys it ships with; the same key machinery signs the network-wide settings described in Grid sporks.

Distribution. hedgehog bootstrap fetch downloads bootstrap.dat.gz from the node’s own GitHub release. It first fetches a SHA-256 hash file and its detached signature, which must verify against the release key bundled in the program, and installs the snapshot only if the downloaded bytes match that hash. The file goes to a temporary name and is renamed into place only after verification, so a failed download never replaces a working snapshot. A daemon that starts without a snapshot runs the same download in the background and reports its progress, or its failure, on GET /status; the node keeps running either way.

Using it. The same data is available from the command line (bootstrap info, balance and history) and over HTTP, see REST interface. The balance endpoint also adds funds that the MintStorage spork has promised to an address but the chain has not minted yet, see Grid sporks. How the command tree and its shared options are built is covered in Architecture overview.

Key facts

Fact Value
Chain tip of the current snapshot Height 3,172,666
Addresses in the snapshot 28,431, of which 3,296 still hold coins
Ledger entries 16,799,121
Total unspent 15,900,032.04557988
Snapshot size 556,361,944 bytes, roughly 314 MB as bootstrap.dat.gz
Amount precision 8 decimal places
Default snapshot file bootstrap.dat in the per-platform user data directory
Trusted signers Four foundation board keys (--network-keys overrides them)
REST history paging limit defaults to 100 and is capped at 1000

Commands

Command Purpose
hedgehog bootstrap import -b <dir> Convert the legacy blk*.dat files into a snapshot
hedgehog bootstrap sign -k <key> Append a foundation signature
hedgehog bootstrap fetch Download, verify and install a published snapshot
hedgehog bootstrap info, balance, history Inspect a snapshot locally

An unsigned snapshot can be inspected locally, but fetch installs only a signed one, and a file with an invalid signature is refused everywhere.

In the source

  • application/src/main/java/org/unigrid/hedgehog/command/bootstrap/ holds the six bootstrap commands.
  • application/src/main/java/org/unigrid/hedgehog/model/bootstrap/SnapshotBuilder.java runs the conversion pipeline from block files to snapshot.
  • application/src/main/java/org/unigrid/hedgehog/model/bootstrap/ChainLinker.java rebuilds the active chain and drops the stale branches.
  • application/src/main/java/org/unigrid/hedgehog/model/bootstrap/SnapshotFormat.java defines the on-disk layout.
  • application/src/main/java/org/unigrid/hedgehog/model/bootstrap/SnapshotSignature.java signs and verifies a snapshot.
  • application/src/main/java/org/unigrid/hedgehog/model/bootstrap/SnapshotDownload.java is the verified download and install.
  • application/src/main/java/org/unigrid/hedgehog/server/rest/BootstrapResource.java is the HTTP interface.