Postern Labs
MAINNET BETA. Unaudited · k=8 gate now active (hardened from the earlier relaxed k=4) · not a security claim by itself · low hashrate → blocks slow for now · very few nodes, 51%-attackable · not a security · for evaluation — not to protect real secrets yet. Full disclaimer →

Sync the easy way

Set up your node from a snapshot.

On the now-active k=8 gate, syncing a brand-new node from the genesis block is not practical — it becomes a very hard mission. A signed snapshot makes it one command: your node boots straight at the tip and mines forward.

⬇ Download snapshot (~160 MB) SHA256SUMS

Pruned chain at the current tip. Verify the SHA-256 before use (sha256sum -c SHA256SUMS). Restore + start commands below.

Why you need this

Why a fresh genesis sync is a hard mission now.

The Module-SIS gate is active at k=8. Two independent facts make a from-scratch sync impractical on today's chain:

  1. The early history predates the gate. Blocks before the k=8 activation carry the earlier relaxed k=4 witnesses, which do not satisfy the active k=8 rule. A node validating the chain from genesis would reject the ~350k historical blocks — a k=4 witness passes k=8 only about 1 in 4096 times — so a from-genesis initial block download cannot complete with the current binary.
  2. The history is pruned network-wide. Every node prunes old block bodies (a ~10k-block window), so the middle of the chain isn't even available to serve to a newcomer. There is no peer that could stream it to you.

Together, that's why a fresh sync "turns into a very hard mission." The practical, supported path is a snapshot: a restored node trusts the snapshot's already-validated chain state and mines k=8 forward from the tip — it never re-validates the old k=4 history, so neither problem applies.

Honest tradeoff

This is a trust-the-operator bootstrap: you trust the snapshot's chain rather than verifying it yourself from genesis. That is a real, disclosed weakening versus full validation — reasonable for an unaudited, zero-value research chain whose early history predates the active gate, but you should verify the SHA-256 and the signature before trusting any snapshot, and prefer one you can cross-check. The coin carries no value claim.

How to do it

One command to be on the network.

You need the built bloch binary first (see Run a node, steps 1–2). Then:

# 1) download the signed snapshot + checksums, and verify
curl -O https://pub-dca67fd26bfb4a6b98115e596095ecd3.r2.dev/bloch-db-snapshot.tar.gz
curl -O https://pub-dca67fd26bfb4a6b98115e596095ecd3.r2.dev/SHA256SUMS
sha256sum -c SHA256SUMS            # must print: bloch-db-snapshot.tar.gz: OK

# 2) restore it into your data dir (it holds the pruned chain at the tip)
mkdir -p ./bloch-data
tar xzf bloch-db-snapshot.tar.gz -C ./bloch-data     # → ./bloch-data/db

# 3) start — boots at the snapshot's tip, syncs the small remaining gap, mines
./target/release/bloch --testnet --data-dir ./bloch-data \
  --listen /ip4/0.0.0.0/tcp/16110 \
  --peer /dns4/blochv-node.fly.dev/tcp/16110 \
  --mine

Confirm with bloch-cli getblockcount (it should already be near the network tip) and bloch-cli getpeerinfo. The snapshot excludes node identity, so your node generates its own — run as many as you like. Drop --mine to run a pure relay/seed.

Snapshot published to the downloads host. It is a periodic capture of a Postern-operated node's pruned state — one operator, not official infrastructure; verify it, or produce your own from any node you trust with tar czf snap.tgz -C <data-dir> db.

Worked example · deploy on a VPS

Standing a node up on Edgevana (what actually worked).

No affiliation — read this

Postern Labs has no association, partnership, sponsorship, or endorsement relationship with Edgevana. It is simply one host we happened to use successfully while testing; any routable VPS or bare-metal box works identically. Nothing here is a recommendation to buy from Edgevana or any provider.

The model we ran — nothing special, a small routable Linux box:

  • Ubuntu 24.04 LTS · ~2 vCPU · ~8 GB RAM · ~33 GB disk
  • A public, routable IPv4 (so it can reach the bootstrap and be reached back) + SSH-key access

On GPUs, honestly: the PoW is SHAKE-256 hashcash + a Module-SIS gate, and the reference miner is CPU-bound — there is no GPU miner today, so a GPU instance buys you nothing for mining right now. A modest CPU box is the working recipe. (A SHAKE/lattice GPU or ASIC miner is buildable — see the ASIC page — but none exists yet.)

# on the VPS (Ubuntu): deps + Rust, then build
sudo apt update && sudo apt install -y git clang cmake pkg-config build-essential curl
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && . "$HOME/.cargo/env"
git clone <gitlab.com/blochsispow-group/BlochSISPoW-project> bloch && cd bloch
cargo build --release --bin bloch --bin bloch-cli

# restore the snapshot (above) into ./bloch-data, then run as a seed + miner
./target/release/bloch --testnet --data-dir ./bloch-data \
  --listen /ip4/0.0.0.0/tcp/16110 --max-peers 500 \
  --peer /dns4/blochv-node.fly.dev/tcp/16110 --mine

Keep --max-peers 500 so it can act as a hub/seed for others. Confirm with bloch-cli getpeerinfo and getblockcount. The chain is unaudited and the coin is worthless by design — run it to strengthen the research network, not as an investment.