Redstone's Implementation

This chapter's thesis: at the implementation layer, redstone is an implicit virtual machine with no spec sheet — its "specification" is not any document but the long-term observation record of code behavior; and facing the fact that players depend on implementation details, the officials chose compatibility over correctness, freezing implementation details into a public API. If the officials ever corrected an implementation detail and the player community felt nothing at all, this thesis is wrong.

1The problem

The design volume covered redstone as a design miracle: the misusable system, computation invented by players (see Redstone: Physics as Programming). This chapter turns the ledger over: the implementation layer that supports that miracle has never had a spec sheet.

A spec sheet is common sense in the engineering world — chips have datasheets, programming languages have language specifications, even home appliances come with manuals. Redstone has none. Its entire "specification" is a body of word-of-mouth accumulated across a dozen years of players running observation experiments against code behavior: how many blocks the signal travels, when the torch goes dark, who wakes a piston, which of two pistons moves first within the same tick. These behaviors were, from the beginning, byproducts of how the code happened to be implemented — no one's design promise — and they later became the foundation of millions of machines.

When an "implementation byproduct" becomes a "de facto specification", something rare happens: fixing a bug is the same act as shipping a breaking change. This chapter lays out every link in that causal chain: the true shape of the signal model, the cause of the famous quasi-connectivity quirk, why update order is so lethal, and the social process by which "undefined behavior became an API".

2Why fixing a bug triggers a redstone revolution

First, fix the implementation layer's actual position: there is no concept of "circuit" in redstone's code. There are only the rules of a batch of blocks — dust recomputes its strength when a neighbor notifies it, a torch checks the state of the block it is attached to, a piston checks whether it should extend — each part governing itself, tugging at the others through the universal notification mechanism of the "block update" (chapter 4). What we call a "redstone circuit" is the aggregate emergence of these local rules interacting, and the emergent whole is defined nowhere in any single part's code.

This structure determines the revolution's nature. In an ordinary game, fixing a bug changes "wrong behavior"; in redstone, fixing a bug changes observed causality — players neither know nor care how the code is written; they know "arranged like this, that block lights up," and behind "arranged like this, that block lights up" stands a whole set of implementation details (how far notifications travel, who computes first in the same tick, how wide the check range is). Change an implementation detail and the observed regularity changes; change the observed regularity and every machine built on it changes.

History supplied the standard case. Snapshot 20w18a of 1.16 fixed an old ailment of redstone wire: before it, "looks connected" and "logically powers" could be two different things — dust that visually formed one unbroken line might not be powering itself along that line, and compact machines had long exploited the discrepancy to save space. The snapshot aligned the two: only what looks connected powers together¹. On the ticket this is a correct fix; in the players' ledger it reads differently — a batch of mature machines had their parts redefined by the officials overnight. The pressure valve added afterward — an isolated dot of dust can toggle between "cross" and "dot" shapes, and the dot powers nothing around it — amounts to an admission: even "which way the dust in this one cell connects" had become semantics that require user configuration.

There is the complete mechanism of "a bug fix triggers a revolution": in a world without a spec sheet, behavior is the spec, and repairing is legislating.

3The signal model: strength, power, and what causes quasi-connectivity

The first scene of the spec sheet's absence is the signal model. Three concepts hold it up, and each has an implementation-layer origin.

Strength is an integer from 0 to 15 (the design volume covered why it is "a number line, not voltage"). In implementation it is simply a state value on the dust's block: a power source sets 15, the dust sheds 1 for every block it crosses, and at zero it goes dark — the "signal" is a counter that decays block by block.

Power comes in strong and weak — the distinction players most easily overlook, and implementation's most elegant cut. A strongly powered block (say, the one a lever points at directly) may pass the signal on to dust attached to it; a weakly powered block (say, the one a line of dust points into) may only light the components touching it — pistons, doors, lamps — and may not pass the signal to adjacent dust. Why make the cut? Because dust bills by the block: if any powered block could re-power dust, the signal would never decay. Strong versus weak is, in essence, issuing two different sets of permissions to "the blocks the signal passes through" and "the signal's destination" — only with this cut does the decay mechanism stand. The game offers no hint of any of this; players mapped it by trial, error, and word of mouth.

Quasi-connectivity is the most famous quirk of the three. The phenomenon (the history volume recorded its promotion into a feature): a piston can be activated by a power source "in the block above itself" — note, not the piston's own cell but the one on top, even when nothing occupies the space between. The cause is in the code: when a piston decides "should I extend," the range it checks for power runs one block beyond the range that update notifications reach — it takes one extra look at the space over its head, while the notification mechanism never knocks for changes up there. Hence a subtle state: the power source above the piston is in place (the check knows), but the piston has received no notification (none is coming), so it keeps lying down — until any unrelated neighbor update happens to pass by and wake it, at which point it "extends in arrears." That one block of difference between check range and notification range is the quirk's entire cause: an accidental misalignment of implementation that grew into the sharpest weapon in the players' hands.

4Pistons and update order: within one tick, who moves first

The second scene of the spec sheet's absence is order. The design volume said the redstone world settles tick by tick, slow but never chaotic; but to the question "within one tick, which of two things happens first," the implementation layer's answer is a sentence to drive a spec-sheet lover to despair: the order in which the code happens to traverse them.

Which is traversed first depends on how the blocks sit in memory, the order in which chunks loaded, even the parity of coordinates — no design-level rule anywhere, purely the terrain of the implementation. In most scenes the order does not matter (two unrelated doors each open on their own); but players quickly found that order itself could be exploited: the interlock of two pistons, the direction a push chain travels, the gait of a flying machine — all of it steps to the beat of "same-tick order," an undefined behavior. The player community accumulated a whole body of observed conclusions (which direction computes first, which placements race), precise enough to write into tutorials — and the "official documentation" they correspond to does not exist, not one line of it.

Chapter 4 covered this order-sensitivity's greatest cost (the graph computation of cascading updates and the window for duplication bugs); this chapter adds its greatest gain: order sensitivity is the flying machine's engine. The officials' posture here matches their posture on quasi-connectivity: don't fix, don't promise, don't take responsibility — because the moment you "fix order," every one of those tutorials and machines becomes a collective lie.

As for the most famous device standing on top of the quirk — the BUD (block update detector, the community's name) — it is a direct product of quasi-connectivity: a switch made of the suspended state "powered but not notified," waiting for some accidental neighbor update to trigger it. The community built automated devices with it for a dozen years and more; the officials later formally enlisted the "detect updates" requirement as the observer block, giving this piece of folk engineering an official posting — but quasi-connectivity itself, to this day, remains in service under the "works as intended" label².

5How undefined behavior becomes an API: a four-step social process

Lay a dozen years of quirk history side by side and a reusable four-step model comes out — the social process by which undefined behavior becomes a public API:

Step one: implementation. An engineer writes code for some local goal (a piston must be activatable by a torch) and leaves behind a boundary behavior no one asked about (the check range runs one block over). Nothing is wrong at this step — in a system without a spec sheet, implementation is everything.

Step two: observation. Players do not read the code; they read behavior. Someone notices "torch in that position, and the piston extended by itself"; observation records begin to pile up, the causality verified again and again. This step is the community's natural strength: the free testing power of millions of players outranks any QA department.

Step three: dependence. The verified causality enters tutorials, enters terminology, enters the core design of machines. "We need a BUD here" becomes a design decision communicable in one sentence — once dependence forms a web, the behavior has become infrastructure.

Step four: freezing. The officials face a choice: correct it (break everything that depends on it), or acknowledge it (mark the behavior "works as intended"). Ticket MC-108 chose the latter². Freezing is not indulgence; it is respect for sunk assets — those dependencies are investments players made with real building time.

Four steps, and an implementation detail is an API. The model's value is not archaeological; it is portable: any open system with a huge player ecosystem passes through these four steps, openly or in the dark. The only thing a maintainer gets to choose is the timing and the posture of speaking up between steps three and four — fix too early and you strangle emergence; too late and the demolition bill is enormous; the observer-style answer of "open a new front door and leave the old door alone" remains the most decent solution found so far. (Volume IV asks which of the frozen behaviors can someday be discarded — see Discardable Accidents.)

6The engineering reality of an implicit virtual machine

The design volume said redstone is Turing-complete; this chapter adds the engineering bill and grounds the phrase "implicit virtual machine".

It is an interpreter lodging inside the game tick: no standalone runtime; every "instruction cycle" is amortized within the world tick's budget (chapter 5's fifty milliseconds); its "registers" are the state bits of blocks, its "bus" is the block update notification, its "instruction set" is the community's word-of-mouth body of observed regularities. Three engineering consequences flow straight out of that identity. The performance ledger: a large redstone machine is a pure TPS tax (a graph recomputed every tick, chapter 4) — a server's redstone budget is a budget for player creativity. The debugging ledger: no breakpoints, no logs, no error messages — redstone's debugger is the player: watch the signal lamps, listen for sounds, pull half of it apart and try again. The detail that dust dims as it weakens (the design volume noted it) is the one "debug display" the officials supplied by accident. The spec ledger: this chapter's subject — to maintain a virtual machine with no spec sheet means its "documentation" is the Wiki, the tutorials, and a few generations of players' memory; every time the officials touch the implementation they simultaneously revise the entire stock of all three carriers. That bill explains a phenomenon unique to redstone: every official "optimization" here must pass review to the standard of compatibility legislation — the technical-debt chapter sets it in the larger picture (see Technical Debt as Product Strategy).

Set the script layer beside it (command blocks and datapacks — the design volume's chapter on commands and datapacks) and the fork between the two roads comes into focus: the script is an explicit virtual machine — syntax, error messages, version numbers; mistakes are intercepted at the entrance. Redstone is an implicit virtual machine — no syntax, no errors, no version numbers; mistakes grow directly into a dangling state inside the machine. The explicit road has a high threshold but predictable behavior; the implicit road has a low threshold but behavior recoverable only by archaeology. That Minecraft keeps both roads open is a decision to let "programming" possess a mystical and a scientific form at once — and players love them both.

7What this chapter leaves behind

• For players: every redstone "rule" you ever memorized is a spec sheet that someone before you wrote by observation — this discipline has no textbook, and you are the co-author of its newest page.
• For developers: what you can take away is the four-step model — recognize what players depend on, respect sunk assets, answer dependence with enlistment rather than correction, and treat "compatibility over correctness" as a formal commitment to the ecosystem; plus the lesson of misalignments like "check range versus notification range": an interface's semantics should be one inch more, and not one inch less. What you cannot take away is the scale of the player observation network: millions of eyes doing reverse specification for you — QA power like that exists only in a community with fifteen years of accumulation.

注释

1. Minecraft Wiki, "Java Edition 20w18a" (a 1.16 snapshot: redstone wire's powering directions were aligned with its visual connections; toggleable cross and dot shapes were added for redstone dots, and the dot does not power its surroundings), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Java_Edition_20w18a . ↩

2. Minecraft Wiki, "Quasi-connectivity" (a piston's activatable range includes the block directly above itself, misaligned with the range of update notifications; the community-filed bug report MC-108 was marked "Works as Intended" by the officials), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Quasi-connectivity . ↩ ↩²