Skip to content

Part III. The Mechanics

Chapter 7

Weeks of Epochs

From Qubic: The Long Version by · Qubic Church, · 19 min read

If chapter six described the network’s anatomy — what it’s made of — this one describes its physiology: how it breathes, how it metabolizes, how it regenerates. Recall the metaphor I carefully introduced in chapter six and promised to return to. Mycelium — a distributed network of fine threads stretching underground without a center and without an owner. Its individual sections continuously die off and are replaced by new ones; the whole, meanwhile, lives longer than any of its fragments. Chapter six ended with the promise that the weekly turnover of computors is — not metaphorically, but mechanically — the same thing. That promise will be kept here. Qubic is the frame on which a structure rests that has yet to be described; the gas pipe gets assembled in the chapters that follow. This one, the seventh, is still about the frame — but about its temporal dimension. Coalbrookdale of the digital age, day two: the floor laid down the night before is set onto supports that have to bear not only weight but also what flows through them.

What an Epoch Is Made Of

Take an arbitrarily chosen week in the life of the Qubic network — say, this one, from Wednesday evening to next Wednesday evening. What happens in it?

The composition of the six hundred and seventy-six computors is fixed. These specific six hundred and seventy-six — no fewer, no more — make up, for all seven days, the parliament we talked about in chapter six. Not one of them can be added in the middle of the week. Not one of them can be officially expelled. Regardless of whether the computor is working or has broken down, voting honestly or trying to sabotage, getting rich or going broke — for all seven days it holds its place in the composition. Within the week, time is sliced into ticks — that very basic round of voting we’ve already discussed. Ticks are many: in the current configuration, one tick takes around half a second to a second, which means there are roughly a million of them in a week. Each tick is a full round: one computor-leader proposes, the remaining six hundred seventy-five verify and vote, a quorum of four hundred fifty-one makes the new state canonical. A million such rounds in a row — and one epoch has been lived through. It’s important to understand what, exactly, the epoch accumulates. This isn’t just a journal of what happened; it’s the network’s structured memory. Each of the six hundred and seventy-six computors, at the close of the week, is assigned a numerical evaluation — sometimes called its “score.” That score measures how much useful work the computor performed over the week. What “useful work” is in Qubic is the topic of the next chapter, I promised, and the promise will be kept; for now it’s enough to know that this work has an objective metric, equally computable for all participants. At the end of the epoch the network has a ranking: six hundred and seventy-six names, each with a number.

In parallel, there’s another list. These are candidates — computers that aren’t part of the current six hundred and seventy-six but, over the course of the week, have also been performing valid work and accumulating their own score. They don’t vote, don’t take part in consensus, but the network sees them and counts them. At the end of the epoch the network has their ranking too — a separate one.

That is, an epoch isn’t just a week during which the network operates. It’s a week during which the network simultaneously operates and observes itself. All six hundred and seventy-six “inside” are constantly under measurement. All the candidates “outside” too. When the week ends, the network has at its disposal not only the blockchain of transactions but also a complete ranked list of who worked how.

Within an epoch none of these rankings goes into effect. For all seven days, the rules of the game are the same for everyone. No computor, no matter how high a score it has accumulated by midweek, gets any additional vote because of it, nor any additional transactional priority, nor even an informational advantage. Within an epoch the network is symmetrical with respect to all six hundred and seventy-six. I want to underline this separately, because this is where one of the subtlest things in the whole architecture of Qubic happens.

What does “the epoch as one round of an iterated game” mean? Axelrod’s tournament, which I worked through in chapter two, was made up of games: each pair of programs played against one another not once but two hundred rounds in a row. Only that structure allowed a cooperative strategy to win — because the opponent remembered past behavior and responded to it. A cooperative strategy doesn’t win in one round; in a thousand rounds, it wins.

An epoch in Qubic is one such round, only with six hundred and seventy-six players at the same time. Each of their weeks of behavior becomes one cell in the overall results table. In the next week, conditions may change — the composition will be different, rules may be refined — but the changes aren’t random; they follow deterministically from what happened in the previous epoch. The ones replaced will be precisely those who showed the worst result; the ones admitted will be precisely those who showed the best. No one appoints “the bad ones”; the process itself determines them. This is sharply different from how Bitcoin lives. Bitcoin has no discrete epochs. The network operates in continuous time: block after block, a new one every ten minutes. Changes to the protocol happen through forks — through public, sometimes painful processes in which part of the community accepts the new version and part doesn’t, and sometimes the network splits. Bitcoin is a long, long sequence without seams, in which any structural change requires opening it up. Qubic lives differently. It has seams, and they fall every Wednesday.

What Happens on Wednesday

What exactly happens at the moment of an epoch transition I’ll now describe step by step. But first — one warning. I’ll be describing the process as a deterministic algorithm; that’s true, but it isn’t the whole truth. In the real history of Qubic, in the four-plus years since the first epoch in April 2022, this algorithm hasn’t always run smoothly. Why, will become clear later in the section; for now, let’s assume the algorithm works. So, the sequence.

A few ticks before the epoch boundary — call it moment T — the network locks in the final scores of all six hundred and seventy-six active computors. It ranks them from bottom to top. The list is known: these names worked best, these worked worst. In parallel, the network already has a ranked list of candidates. These are the very computers that were performing valid work all week but didn’t belong to the six hundred and seventy-six. Their score is an objective parameter, equally computable, based on the same metric as for the active ones. The two are competing on a single ruler, not on different ones.

At moment T — more precisely, at a stipulated moment on Wednesday UTC — the network compares. If the best external candidate has a score higher than the worst active computor, they swap places. The worst is dropped, the best is admitted. The process repeats: now the next-worst of the remaining six hundred and seventy-six is compared with the next-best of the externals. And so on.

But not infinitely. At the two hundred and twenty-fifth replacement, the process stops, even if the next external candidate is still formally better than the next active one. Two hundred twenty-five is a rigid ceiling, we worked through this in detail in chapter six; it’s structural protection of the network against too rapid an invasion. So: if it has turned out that one hundred and twenty computors really did work badly, all one hundred and twenty of them are dropped. If three hundred such ones turned up, only the two hundred and twenty-five worst out of the three hundred are dropped; the rest stay another week, under the promise of doing better. And if there were only fifty such, all fifty are dropped, and no one fills slots up to two hundred and twenty-five; openings for new entrants don’t appear in such numbers.

A new epoch begins. The composition of the six hundred and seventy-six is refreshed. Last week’s score is recorded in the blockchain as historical fact; the network remembers it, but in the new epoch it confers no privileges. The new week is a clean slate by accumulated work. Everyone starts again.

The selection mechanic isn’t manual. Nobody from the Qubic team sits on Wednesday morning with a spreadsheet deciding whom to swap. The process is deterministic, executed simultaneously by all six hundred and seventy-six nodes independently. Each computor, knowing the full list of ticks of the past epoch, can compute the score of each participant on its own — both internal and external. If all six hundred and seventysix computed the same thing — and they should, because the input data are the same for everyone — the new epoch begins automatically. No central decision. In CfB’s descriptions, the mechanism by which an active computor officially loses its status sounds like this: a computor behaving incorrectly or failing to keep up with its load, at some moment, starts emitting cryptographically invalid ticks. These invalid ticks become their own proof of its problem — they get included in the blockchain as evidence the whole network sees. At the epoch boundary, such a computor automatically loses its place. Its replacement isn’t carried out by people, or even by the Arbitrator — it’s carried out by the computors themselves through the protocol, processing the proof.

Separately, on transitions. An epoch change isn’t an atomic operation. It doesn’t happen in one microsecond. The actual procedure, as far as is known from the team’s descriptions, is stretched out over hours. In the early epochs, in 2022, when gradual transitions were being tested, a change could take six hours — from 9:00 UTC to 15:00 UTC; mining would stop for the entire interval, and the network would “reassemble” itself. By the end of 2024, gradual transitions had been replaced with so-called seamless transitions — transitions without a full halt. The network keeps ticking, but at some moment the internal computor list at each node updates — and the next tick goes through with the new composition. How exactly the synchronization happens, I’ll work through a paragraph from now.

Transactions crossing the epoch boundary aren’t lost. If a user sent a transaction a minute before Wednesday and it didn’t make it into a block of the old epoch, it goes into the first possible tick of the new one. From the user’s standpoint there’s no difference at all between a transaction “Wednesday before noon” and “Wednesday after noon.” For the user, the network is one and the same. Only inside, under the hood, has it slightly changed the composition of its voters at the moment of the transaction. Why Wednesday, specifically. The answer is simple and pragmatic. Wednesday is the middle of the working week in most time zones of the world where Qubic has operators. It’s a day when the maximum share of computors is most likely to be online and monitoring what’s happening. Monday and Friday are tied to start- and end-of-week effects — when operators haven’t yet fully settled into work mode or are already partially distracted by the weekend. Saturday and Sunday — fewer people at the consoles. Wednesday is a reasonable compromise, nothing mystical.

Why a week, specifically. Here the answer is a bit more interesting. Too short an epoch — say, a day — would make the score evaluation statistically noisy: random fluctuations in performance would produce equally random ejections, and the composition would jitter without substantive cause. Too long — say, a month — would mean a slow reaction to bad participants: a malicious or simply broken computor could damage or impede the network for months before being replaced. A week is an empirically found compromise. It isn’t an “optimum” proven mathematically; it’s a reasonable value at its design point.

Here, by the way, it’s worth remembering that Qubic isn’t unique in the idea of dividing time into epochs. Other networks with discrete time exist — Cardano uses five-day epochs, Solana’s epochs are significantly shorter. The originality of Qubic isn’t in the concept itself, but in the parameters and in what, exactly, gets fixed at the epoch boundary. In most other networks, an epoch is the time between recalibrations of some single parameter. In Qubic, an epoch is the full life cycle of the voter composition. And one more observation worth lingering on. The epoch is the unit in which one round of an iterated game takes place. Here a promise left unclosed earlier begins to turn into an engineering fact: the fourth condition of cooperation — a win in the game must not give the player the ability to change the rules of the game itself. This condition now has two implementations: a static one — no accumulated wealth increases the weight of a vote; and a dynamic one — a computor that earned a great deal over an epoch gets the right to remain in the next epoch, but not the right to change its rules. Two different kinds of prize, and the division between them is wired into the epoch boundary.

How to Switch Without Stopping

The epoch transition in Qubic is not a simple engineering task. Imagine you have to swap out a quarter of a soccer team’s roster mid-match in such a way that the match doesn’t stop. The incoming players have to already know the tactics, know where the ball is, who passes to whom, what combinations are being run. The outgoing have to clear the field but not take with them anything the team will need going forward. And all of this — in the moment, without a whistle.

In the programmer’s world the task sounds like this: at moment T we have up to two hundred and twenty-five nodes leaving consensus and the same number entering. The new ones have to know the network’s full current state — the most recently accepted blocks, all open obligations, all states of smart contracts. The outgoing have to correctly hand them this state without halting the flow of new transactions. And the network at this moment must neither lose validation, nor allow conflicts, nor get stuck trying to come to an agreement.

The Qubic protocol solves this through what can be called phase-in and phase-out. An incoming candidate knows that it can become a computor on the upcoming Wednesday in advance — by its own accumulated score. This isn’t a last-minute surprise; it can prepare. For several days already it’s been pulling down the current state of the network, getting it not in one big chunk at moment T but gradually, in the background. By moment T it already has everything it needs for the very first tick of the new epoch. It doesn’t vote — because it isn’t yet part of the six hundred and seventy-six — but it’s already ready.

At the boundary T the switch happens in one step. Each of the six hundred and seventy-six independently computes the new composition. Each updates its internal participant list inside itself. From the very first tick of the new epoch the new ones are voting. The old ones, just departed, can still remain in contact for some time as observers — their votes are no longer accepted, but they see the network, can finish their technical business, can try to come back as candidates the following week. No abrupt breaks.

Where this description starts to seem too smooth, I have to stop and add an honest caveat. CfB’s own commentary directly says: “Not all epoch transitions are smooth.” That’s true. The history of Qubic knows two different kinds of transitions. One is “seamless”: no new features get rolled out, rules don’t change, only the computor composition refreshes. Such a transition has, since 2024, indeed proceeded without a network halt. The other is “breaking”: along with the change of composition, a new version of the protocol, new logic, new capabilities are deployed. In this case all computors must update their code, and the transition can be accompanied by downtime — sometimes several hours, and in the very early days even more.

And here’s an important detail: the Qubic team does breaking transitions regularly. Every Wednesday, if there are new features for rollout that week — the transition is breaking. If there aren’t any — seamless. When over the holidays, in December 2024, the team decided to do a series of seamless transitions in a row, CfB himself explained it simply: “no breaking updates which means no progress with monero.” That is, seamless is stability at the cost of an absence of development; breaking is development at the cost of possible downtime. Qubic in practice constantly balances between these two modes, and from week to week the choice can shift.

This may seem strange to a reader accustomed to the crypto discourse around Bitcoin, where any hard fork is an event that triggers months of discussion and sometimes splits the community. In Qubic a hard fork is a routine midweek event. The reason is that consensus in Qubic is built differently. In Bitcoin, a change of rules requires the voluntary agreement of miners, each of whom can keep working under the old protocol indefinitely — and if enough hashrate stays on the old version, you get a parallel chain. In Qubic, hashrate and voice are separated: hashrate is needed only to land in the six hundred and seventy-six and to fight for a place among them; within an epoch the rules apply identically to all the voters, and if six hundred and seventy-six have agreed to a new version — the new version becomes canonical. A faction left on the old one simply won’t enter the next composition. No fork happens.

Now a brief historical aside that explains a great deal. Seamless transitions are not what existed in Qubic from the beginning. This was a major multi-year engineering task. The first records of work on it date to December 2022; back then CfB wrote to the team: “This epoch we should develop and test seamless epoch transition, expect daily updates.” In 2023 — a series of preparation changes. In 2024, in January, seamless mode was finally deployed to mainnet. That is, the network for two years — 2022 and 2023 — lived with transitions that sometimes took hours and stopped mining. Only afterward did what most users today see as “the invisible Wednesday change” appear. This is important to remember for two reasons. The first is honesty: to claim that Qubic was born with a ready seamless architecture would be untrue. The second is a demonstration of method. Developing critical infrastructure in an open network with real users and real money flowing through it is work that doesn’t get done in a month. Four years ago, on the day of Qubic’s first epoch on April 13, 2022, most of what now runs automatically didn’t yet exist even on paper. The network was learning to live — and while it learned, it lived, little by little.

Four years isn’t a random number. The mainnet launch date — April 13, 2022. The planned date of the Arbitrator’s departure — April 13, 2027. Five years between them, and the coincidence of numbers is definitely not accidental. It’s too early here to discuss this date in detail; its full treatment is in chapter fourteen. It’s enough to note that the weekly cycle of epochs we’ve just described becomes the unit of count for these five years. Not calendar, but network.

Under the Hood: Symmetries and Arithmetic

Chapter six showed how the number six hundred seventy-six gives rise to the quorum of four hundred fifty-one and the replacement limit of two hundred twenty-five through one and the same BFT mathematics. It’s worth pausing on the arithmetical symmetry between these two defenses — and seeing that it isn’t decorative but functional.

The quorum of four hundred fifty-one protects the network within an epoch — at the moment of voting. It’s protection against a minority, even a large one, pushing through a false decision. The two hundred and twenty-five, by contrast, is protection between epochs, at the boundary of a transition. It’s protection against an attacker rotating the composition in his favor too quickly. The first works on the scale of milliseconds; the second on the scale of weeks.

What’s remarkable is that both defenses are mathematically the same. Six hundred and seventy-six minus four hundred and fifty-one equals two hundred and twenty-five. If the maximum number of those simultaneously replaceable equals the difference between the full composition and the quorum, then you get the following property: even under an epoch change ideal for the attacker, when his people occupy all two hundred and twenty-five seats, the remaining four hundred and fifty-one old computors make up exactly a quorum. The new ones can’t pass a single decision on their own — there are only two hundred and twenty-five of them, and at least four hundred and fifty-one votes are needed. To push through any decision, they need votes from the old. This means that whether one likes it or not, any attempt to capture the network from within is doomed to be a drawn-out process. Chapter six already showed it arithmetically: a minimum of four epochs, that is, four weeks, with ideal competitive performance — and during all of that time control belongs to the previous composition. What’s also important is that the previous composition is not obliged to sit passively over those four weeks. It sees what’s happening, sees the ranked list of candidates, understands the structure of incoming force, and can — at the protocol level, with nothing illegal — take measures. For example, vote on a change of rules complicating mass simultaneous entry. Or change the score itself, making it more resistant to a specific type of attack. Voting on a rules change isn’t permitted within an epoch, but at the epoch boundary — as we’ve seen — it is.

There’s another nuance worth noting. The selection mechanic is built so that a rationally minded attacker won’t try to capture all six hundred and seventy-six seats in a single week. Why would he? His own mining is bounded — he can produce, say, this much score per epoch. If he scatters that score across all six hundred and seventy-six positions, he won’t take a single one: for each individual position his strength turns out to be weaker. It’s more rational to concentrate all his strength on the two hundred and twenty-five best candidates — that is, on the maximum allowed simultaneous rotation. That gives him three times the efficiency per position. But it also slows him down threefold: instead of one step toward capture he has to take three.

Put differently, the structure of the protocol doesn’t merely defend against rapid attack — it actively steers the rational attacker toward a slow one. And a slow attack is an attack visible for months. This is a fundamental difference from situations like GHash.IO in 2014, where concentration from thirty percent to fifty-five could happen in a few weeks and where there was no mechanical brake to slow the process. In Qubic the brake is built in as a constant.

A computor’s earnings don’t convert into the weight of its vote, nor into the speed of its entry into or exit from the composition. The maximum that earnings give is an objective chance to remain or to land in the composition, and that chance is bounded by the same threshold of two hundred and twenty-five, which doesn’t depend on how much, exactly, the computor earned. The winner’s prize inside the game is to stay in the game. No more.

What’s Next

To sum up. The Qubic network lives not in continuous time but in discrete cycles of one week each. Within an epoch the composition of six hundred and seventy-six computors is fixed, all vote with equal weight, every tick is a full round of consensus. At the end of the week the network has at its disposal a ranked list of all the active computors and all the candidates — by an objective metric of work performed. At the epoch boundary, automatic replacement happens: the worst yield their seats to the best, up to two hundred and twenty-five replacements at a time, under a rigid arithmetical limit that preserves four hundred and fifty-one old computors in the new composition. Transactions go through without interruption, the network doesn’t stop if the week has no breaking updates; and if it does — a brief downtime is possible, and the team consciously chooses what matters more to it on each particular week: stability or progress. At the level of the human metaphor, the mycelium regenerates every seven days: some threads die off, some appear, the whole goes on living. At the level of game theory, every epoch is one round of a large iterated game with six hundred and seventy-six participants, and it’s precisely this, as Axelrod showed in 1980, that turns cooperation from an unstable exception into a stable equilibrium.

Two engineering anchors — the quorum of four hundred and fifty-one and the replacement limit of two hundred and twenty-five — are arithmetically symmetrical, and together they make capturing the network a task requiring not hours and not days but weeks, in plain sight of the entire community.

We’ve now described the network’s space — six hundred and seventy-six voices occupying seats — and its time — weekly cycles during which those seats refresh. But not once have we answered the question this whole book started over. What, exactly, are these six hundred and seventy-six participants doing during the seven days of their epoch? What work earns them their place in the next week — and why is it “useful,” rather than, as in Bitcoin, arbitrary? What is the force that turns this mycelium? Not the meaningless hashes we discussed in chapter one. Not arithmetic for arithmetic’s sake. Something else — what Qubic was conceived for. What in chapter one we called “Murdoch’s gas,” collected into a pipe.

The next chapter is the key one in this book. It’s about useful work of computation that simultaneously defends the network and produces something that did not previously exist in the world. It’s called “Murdoch’s Gas in Action — UPoW.”