Ephemeral Sidechains: pruning headers, not just bodies, by anchoring the checkpoint to Bitcoin
(Follow-up to a previous discussion with @SergioDemianLerner about RSKIP215.)
TL;DR. RSKIP215 (Ephemeral Blockchain) removes old block bodies from consensus, but a syncing node still downloads every RSK header from genesis — the spec explicitly starts by “requesting all block headers from genesis”. For Rootstock that is the expensive part: ~500 B per header, ~600 B of merge-mining proof, plus uncles on roughly half the blocks. Even a Superchain-style 20× reduction leaves a lot of data. But a merge-mined sidechain has an asset that standalone chains lack: Bitcoin itself, whose headers are 80 bytes and whose canonical blocks provide external timestamps and difficulty-weighted samples of hashrate. Ephemeral Sidechains use Bitcoin as the header backbone, so initial sync downloads zero RSK headers before a well-defined checkpointing period.
Assumptions and security model
We assume the following:
- Majority of Rootstock miners in the past 14 days are honest.
- Reorganizing more than 14 days of Rootstock blocks is impossible.
These are fair assumptions especially giving that currently the PowPeg makes it impossible to reorg that deep without a hard fork, and in any future trust minimized or trustless bridge situation, reverting 14 days worth of Rootstock blocks is most probably going to cause a catastrophic failure of the peg, as the challenging period of a withdrawal attempt is most likely less than two weeks.
Sync algorithm
Finding Checkpointing Period
-
Download all Bitcoin headers, as any SPV wallet does (~70 MB total today, and checkpointable).
-
Partition them into difficulty-adjustment periods of 2016 blocks. Call the latest (possibly incomplete) period
P(L), and the ones before itP(-1),P(-2), … Within a period every block shares one difficultyD(P), read directly from the already-downloaded headers — so difficulty weighting below costs zero extra data. -
Walking backwards from the Bitcoin tip, download each block’s coinbase transaction + Merkle inclusion proof (~600 B per block) and count how many coinbases in each period carry an
RSKBLOCK:tag. Define each period’s observed merge-mining work asW(P) = tags(P) × D(P) -
Checkpoint Period: the first
P(i), walking back, such thatW(P(i+1)) + … + W(P(L)) > W(P(i))i.e. the merge-mining work observed after the period exceeds the work observed inside it. This mirrors the removal condition of RSKIP215 and serves the same purpose: if participation suddenly drops, the checkpoint retreats until the tail accumulates enough observed work to make re-mining from inside the Checkpoint Period at least as expensive as the honest tail.
Bitcoin headers: ...──| P(-4) |──| P(-3) |──| P(-2) |──| P(-1) |──| P(L) partial |──▶ tip
tags per period: 1450 1500 380 410 260
difficulty D(P): 100 110 120 130 135 (relative units)
W = tags × D: 145,000 165,000 45,600 53,300 35,100
walk back from tip:
i = -1 : tail = 35,100 35,100 > 53,300 ? no
i = -2 : tail = 53,300 + 35,100 = 88,400 88,400 > 45,600 ? YES
→ Checkpoint Period = P(-2)
Finding Latest Checkpoint Block
Our purpose is to ensure that the checkpoint block has NOT being mined in a long range attack to overpower other forks in a the fork choice rule. To achieve that, our main constraint is that the checkpoint has to be mined later than the Checkpoint Period start.
To prove that, we define the Checkpoint Block as the earliest block that has in its merge mined bitcoin header a Previous Block hash points to an actual Bitcoin block in the canonical chain, within the Checkpoint Period.
BITCOIN (canonical headers, from SPV sync)
[B*]...──[b2015]────[ b2016 ]──[ t1 ]──[ t2 ]──[ t3 ]── ... ──▶ btc tip
└───── Checkpoint Period ───┘ └───────────── tail ─────────────┘
▲
└──────┐ Previous Block
┌───┴──────────────────────────┐
│ Bitcoin Merged Mining Header │
└──────────────────────────────┘
ROOTSTOCK │
┌───┴────┐
(pruned headers) ── ✂ ────────│ RSK_C │──[c1]──[c2]── ... ──▶ rsk tip
└────────┘
Checkpoint Block
Fork Choice and SAFE block
Given two forks with valid Checkpoint Blocks, the one with the heaviest observed subtree (GHOST) is the canonical rootstock chain.
Once a block in the canonical chain is buried under enough confirmations we can consider it SAFE from reversion.
Armadillo
Even if we only see one Rootstock fork, we can then depend on the Armadillo algorithm to detect any hidden forks, and if we think there is one, we delay our subjective SAFE block tagging until we are satisfied a block is buried under enough blocks that don’t seem to be contested with a hidden fork.
FINAL Block
Once we settle which Checkpoint Block is in the canonical chain, using the fork choice rule with or without Armadillo’s help, we can then consider that Checkpoint Block to be FINAL.
┌─────────┐
Fork A: ─── ✂ ───│ RSK_C_A │──[a1]──[a2]──[a3]──[a4] subtree work W_A
└─────────┘ └──[a2'] (uncles count, GHOST)
┌─────────┐
Fork B: ─── ✂ ───│ RSK_C_B │──[b1]──[b2] subtree work W_B
└─────────┘
Both Checkpoint Blocks reference canonical BTC >= B* ⇒ both ADMISSIBLE
Fork choice: heaviest observed subtree, W_A > W_B ⇒ Fork A canonical
Fork A's Checkpoint Block ⇒ FINAL
Node downloads state at RSK_C_A, validates forward
Fork X: ──[x1]──[x2]──[x3]── ... every prevHash < height(B*)
(pre-mined long-range fork)
⇒ INADMISSIBLE — never reaches GHOST
State Download
The state at the FINAL block is then trusted to be downloaded by full nodes that are willing to validate blocks going forward. Otherwise, light clients can check state proofs at any block they consider SAFE.
Cost comparison (initial sync, before the horizon)
| RSKIP215 | Ephemeral Sidechains | |
|---|---|---|
| RSK headers from genesis | ~500B × 2 * 60 * 24 *365 (~500MB/yr ) | none |
| Merge-mining proofs | ~600B × 2 * 60 * 24 *365 (~600MB/yr) | ~600B × 2 * 60 * 24 *14 (~25MB) |
| Uncle headers | ~50% of blocks | ~50% of blocks |
| Bitcoin headers | — | 80 B × ~52.5k/yr (~4 MB/yr, checkpointable) |
| Coinbase + Merkle proof | — | ~600B × 2016 × (2-5) (~2.5-6MB) |
| Sum | 1.65 GB | ~50MB |
Implementation
I am keeping track of a reference implementation here.
Feedback very welcome.