Two Clocks, No Bottleneck

The problem: one clock cannot serve two different jobs

A hash-chained, tamper-evident record has to do two things that pull in opposite directions. It has to react — every new action should be provably linked into the chain close to immediately, because a record that only catches up periodically has a window in which “not yet recorded” and “never happened” look identical to an outside observer. And it has to anchor — periodically, the record’s current state has to be published somewhere external and independently checkable, so that even if every copy of the internal record were compromised at once, the outside world already has a fixed point to compare against.

The naive design ties both jobs to the same clock: recompute and publish the anchor every time something happens. That works at small scale and then stops working, because the publish step is the expensive one — verifying against an external, independent witness has a real cost — and paying that cost on every single event means the system’s total cost grows with the number of events, without bound, forever. That is the opposite of what “planet-scale” is supposed to mean.

The approach: split reaction from anchoring onto two independent cadences

The fix is to stop treating “record it” and “prove it to the outside world” as the same operation and put them on two separate clocks that run independently:

• An event-driven cadence for the record itself — every action gets linked into the chain right away, so the internal record is always current and nothing waits in a queue pretending not to exist yet.
• A time-driven cadence for the external anchor — the chain’s current state gets rolled up into one fixed-size proof and published on a steady schedule, regardless of how many or how few events happened in that window.

The insight that makes this sound rather than just convenient: the cost of publishing the anchor does not depend on how many events happened underneath it. A rollup of ten events and a rollup of ten million events both collapse to the same fixed-size proof. That is what decouples the two clocks safely — the expensive step’s cost is bounded by time elapsed, never by event volume, so a system doing this can absorb an arbitrarily larger number of events without the anchoring step getting more expensive at all.

The result: two scaling problems that no longer share a bottleneck

Put the two cadences on independent clocks and each one gets to be as fast or as economical as its own job actually requires, instead of both being throttled to whichever one is slower:

• Reaction stays fast. Nothing about the record itself waits on the publish schedule — an action is linked into the chain the moment it happens, always.
• Anchoring stays cheap at any scale. Because the published proof is a constant size no matter how much happened underneath it, the cost of proving integrity to the outside world stops growing with the size of the system. A swarm generating ten times the events pays the same anchoring bill it did before.

The combination is what lets a system claim genuinely unbounded scale rather than “scale up to the point where the anchor step becomes the bottleneck” — which is where a single-clock design always eventually lands.

The takeaway

When a system has two jobs with genuinely different natural rhythms, forcing them onto one shared clock does not simplify the design — it just makes the whole system as slow, or as expensive, as its slowest job. Split the clocks, let each cadence serve the job it’s actually suited to, and the ceiling that used to cap the whole system stops being a ceiling at all.