Checkpoints & Anchoring
Checkpoints commit chain state at regular intervals. Anchoring publishes checkpoint hashes to immutable external stores, preventing history rewrite even by key holders.
Why are checkpoints needed?
Without checkpoints, a key holder could create an entirely new chain with forged history. Checkpoints commit to specific chain states at known times, limiting the rewrite window.
- ■Time-bound rewrite: Can only forge between checkpoints
- ■Fork detection: Conflicting checkpoints reveal tampering
- ■Efficient verification: Start from checkpoint instead of genesis
- ■Recovery point: Known-good state for resumption
What does a checkpoint contain?
A checkpoint summarizes chain state at a specific point:
{
"checkpoint_v": "1",
"checkpoint_id": "sha256:abc123...",
"run_id": "run_xyz789",
// Chain state
"receipt_count": 1000,
"head_counter": 1000,
"head_receipt_hash": "sha256:def456...",
// Merkle root (if using batching)
"merkle_root": "sha256:ghi789...",
// Timing
"timestamp": "2024-01-15T10:30:00Z",
"tsa_token": "base64:...", // Optional TSA
// Previous checkpoint reference
"prev_checkpoint_id": "sha256:aaa111...",
// Signature
"signer": {
"public_key": "base64:...",
"key_id": "a1b2c3d4e5f67890",
"signature": "base64:..."
}
}How does Merkle batching work?
Instead of checkpointing every receipt, batch receipts into a Merkle tree. The checkpoint contains only the Merkle root.
Merkle Root (in checkpoint)
│
┌─────────┴─────────┐
│ │
Hash(A+B) Hash(C+D)
│ │
┌───┴───┐ ┌───┴───┐
│ │ │ │
Receipt Receipt Receipt Receipt
#1 #2 #3 #4
// To prove Receipt #2 is in checkpoint:
// 1. Hash Receipt #2
// 2. Combine with Hash(Receipt #1)
// 3. Combine with Hash(C+D)
// 4. Result should equal Merkle Root
// This is the "inclusion proof"What is external anchoring?
Anchoring publishes checkpoint hashes to immutable external stores. Once published, even the key holder cannot create a different history for that checkpoint.
Blockchain Anchoring
Publish checkpoint hash to Bitcoin, Ethereum, or purpose-built chains. Transaction proves checkpoint existed at block time.
Time-Stamping Authority (TSA)
RFC 3161 TSA provides signed timestamp over checkpoint hash. Trusted third-party attests to existence at specific time.
Immutable Storage (Arweave, IPFS-pinned)
Content-addressed storage guarantees checkpoint retrieval. Combined with TSA provides time attestation.
Transparency Log (CT-style)
Append-only log with consistency proofs. Multiple monitors can verify log integrity.
How often should checkpoints occur?
Checkpoint frequency balances security against overhead:
Frequency Rewrite Window Overhead Use Case ─────────────────────────────────────────────────────── Every receipt None Very High Paranoid/regulated Every minute 60 seconds High High-security Every hour 1 hour Medium Standard Every day 24 hours Low Cost-sensitive Event-triggered Variable Variable Milestone-based
How is a checkpoint verified?
Checkpoint verification confirms the anchor matches the local chain:
- 1.Retrieve anchor: Get checkpoint hash from external store
- 2.Verify anchor authenticity: Check blockchain proof, TSA signature, etc.
- 3.Compute local checkpoint: Hash the checkpoint object from bundle
- 4.Compare: Local hash must match anchored hash
- 5.Verify chain to checkpoint: Confirm receipts lead to checkpoint state
Frequently asked questions
What if the anchor service is unavailable?
Continue with local checkpoints. Mark them as UNANCHORED. When service recovers, batch-anchor accumulated checkpoints. Verification notes the unanchored period.
Can I use multiple anchor services?
Yes. Multi-anchoring provides redundancy and stronger guarantees. Verification can require any one anchor to match, or require multiple for high-assurance scenarios.
Is checkpointing required for MVP?
No. MVP can mark checkpointing as SKIPPED. The chain is still internally consistent and verifiable; it just lacks external anti-rewrite protection.