中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC082
A software release does not make every node enforce the same rules. An upgrade announcement does not show which rules a particular operator installed. Even an observed readiness signal is different from a block being checked under an active rule.
To understand an upgrade, ask two questions separately. First, which records do the old and new rules accept? Second, which participants actually apply which rules, at what point? The answers explain why some changes can preserve one direction of compatibility while still producing disagreement about particular blocks.
This lesson uses a deliberately small validation exercise. It is not a deployment plan, a description of a complete consensus protocol or a recommendation to change real node software. Its numbered fields and activation heights are invented.
Choose your reading route
In this guide
- 1. Identify the layer and the rule
- 2. Four events that should not share one label
- 3. State the old rule completely
- 4. Restriction: the new accepted set is smaller
- 5. Expansion: the new rule admits a formerly invalid value
- 6. Installation before activation changes the timing answer
- 7. Signals are evidence about the signal
- 8. Follow disagreement without inventing the outcome
- 9. Build an adoption record, not a single percentage
- 10. A compatibility claim needs a stated boundary
- 11. Exercises with explained answers
- 12. Frequently asked questions
- 13. Sources and further reading
- Read sections 1–3 to separate specification, release, installation and activation.
- Work through sections 4–6 to compare a restrictive rule change with an expansive one.
- Use sections 7–9 to reason about signals, possible disagreement and the evidence needed for adoption.
- Complete the exercises before relying on labels such as “compatible” or “upgraded”.
Back to contents · Next section
1. Identify the layer and the rule
Our previous governance exercise concerned who could change one application’s catalogue limit. This lesson concerns a different task: comparing validation rules that nodes apply to candidate blocks.
A block can carry the same visible label while being judged under different rules. A node’s answer depends on the rules and activation configuration it actually enforces, together with the relevant history and state.
It is therefore incomplete to say that “version two accepts the block”. Which version-two implementation? Which network? Which activation conditions? Which parent history? And are we discussing validation, selection as the current head or finality?
The toy model will explicitly supply those conditions. It has no token balance, transaction fee, proof-of-work target, validator vote or execution virtual machine. We isolate one integer field so that readers can check every acceptance result without hiding the lesson behind implementation details.
Real upgrades can change several interacting rules at once. The small model teaches how to state a compatibility claim; it does not establish the compatibility of an actual network change.
Back to contents · Next section
2. Four events that should not share one label
A specification describes intended rules. A software release makes an implementation artifact available. Installation places a chosen implementation and configuration with an operator. Activation determines when the new rule applies under that implementation.
Those events can occur at different times. An operator can install software before its new rule becomes active. An operator can also keep old software after other participants activate a change.
EIP-1 distinguishes proposal documents and their process from implementation work and coordination. A proposal’s standards status belongs to that process. It should not be used as a universal substitute for observing what a particular node runs. EIP-1
For our toy, assume a new package is released when the observed chain reaches height 80. Some operators install it. The package preserves the old rule below height 100 and applies its new rule at height 100 and above.
No software defect, installation failure or network ambiguity is being smuggled into the arithmetic. Where we say an operator installed the specified package correctly, that condition is supplied. Outside such a case, installation is a question requiring evidence.
Back to contents · Next section
3. State the old rule completely
Each candidate block has a single integer field n. Under old rule O, the field passes if n is at least zero and at most eight, including both endpoints.
For this exercise, assume every candidate otherwise satisfies all shared checks and extends a parent history valid for the comparison being made. Therefore the n check determines the candidate’s validation result in each case.
The old accepted values are:
- Zero, one, two, three, four, five, six, seven and eight.
Nine is outside the range. A negative number is outside the range. A fraction such as 4.5 is outside the stated integer domain even though it lies numerically between zero and eight.
Specifying the domain matters. If one reader assumes integers and another allows fractions, they are not testing the same rule.
We will examine two independent proposed upgrades. R restricts the accepted set. E expands it. They are alternative scenarios starting from O, not sequential stages of one upgrade.
The letters describe our supplied sets. They do not identify a real blockchain, client version or standards proposal.
Back to contents · Next section
4. Restriction: the new accepted set is smaller
After activation, restrictive rule R accepts integers from zero through five. All of its accepted values also satisfy O.
Compare four candidate values at height 100:
- n equals four: O accepts and R accepts.
- n equals seven: O accepts and R rejects.
- n equals ten: O rejects and R rejects.
- n equals thirteen: O rejects and R rejects.
The direction is precise: passing R implies passing O for this field in the supplied model. Passing O does not imply passing R. Seven is the counterexample.
This is the set-containment intuition often used to explain a soft-fork-style restriction. It is a property of accepted records under stated assumptions, not proof that every operator adopted the new rule or that disagreement is impossible.
An old-rule node can accept a block containing seven while an R-enforcing node rejects it. The fact that R-valid blocks fit within O’s range does not force every producer to create only R-valid blocks.
Also notice what the old-rule node cannot establish. Accepting a block under O is not evidence that it checked the additional restriction. If n happens to be four, both answers agree, but the reasons and guarantees differ.
Agreement on one easy example is therefore weaker than evidence that the same rule is being enforced.
Back to contents · Next section
5. Expansion: the new rule admits a formerly invalid value
In the independent E scenario, the active new rule accepts integers from zero through twelve. Every O-accepted value passes E, but some E-accepted values fail O.
At height 100:
- n equals four: O accepts and E accepts.
- n equals seven: O accepts and E accepts.
- n equals ten: O rejects and E accepts.
- n equals thirteen: O rejects and E rejects.
Now ten is the witness to incompatibility in the other direction. A block permitted by the new rule can be rejected by a node still enforcing O.
This illustrates the compatibility issue in a hard-fork-style expansion. It does not mean that every real hard fork consists of enlarging one numeric range. Real changes can replace rules in ways that are more complicated than either of our nested sets.
Nor does it mean a lasting split must occur. If participants coordinate their adoption and produce a common accepted history, no such disagreement need be observed. Conversely, calling an upgrade “approved” does not prove that coordination succeeded.
The logical conclusion is limited to the candidate and rule pair. Under E, ten is permitted by the supplied field rule. Under O, it is not. Which histories are produced, followed or finalised requires additional information.
Back to contents · Next section
6. Installation before activation changes the timing answer
Return to the restriction scenario. The correctly installed R package still uses O below height 100.
At height 99, a candidate with n equal to seven passes both an old O node and a node running the not-yet-active R package. At height 100, the same field value passes O but fails the now-active R rule.
There is no contradiction. The package includes an activation boundary, and the two candidates are on opposite sides of it.
In the expansion scenario, n equal to ten fails both O and the not-yet-active E package at height 99. At height 100, it still fails O but passes active E.
“Installed” and “active” thus belong in separate columns. A monitor that records only the software package may overlook a different activation configuration. A monitor that records only an advertised activation date may overlook whether the operator installed the necessary rules.
Our toy uses a fixed height for clarity. Real systems may use different conditions, including timestamps or state transitions calculated from prior blocks. The lesson is to inspect the actual condition, not to replace it with a familiar calendar announcement.
Back to contents · Next section
7. Signals are evidence about the signal
Suppose some participants emit a readiness signal at height 90. The toy activation rule remains fixed at height 100; the signals do not change it.
A supplied signal can establish that a particular signal appeared in the observed record. It does not, by itself, establish the signaller’s complete software behaviour, every other operator’s adoption or the validity of a later block.
Bitcoin’s BIP 9 is a real, specific example of separating deployment states. It describes signalling and transitions including locked-in and active; new consensus rules are enforced in the active state under that mechanism. Its thresholds, periods and timeout rules belong to that specification, not to our invented height-100 exercise. BIP 9
Do not combine pieces of different mechanisms casually. A threshold taken from one proposal, an activation date from another and an operator count from a third do not define a coherent deployment rule.
The same care applies to a social announcement. “We support the upgrade” can be useful coordination evidence. It is not an authenticated execution trace of every future validation decision.
Back to contents · Next section
8. Follow disagreement without inventing the outcome
At height 100 in the R scenario, imagine two candidate blocks extending the same supplied valid parent. A contains four; B contains seven. Other checks pass for both.
O permits both candidates. R permits A and rejects B. That is a disagreement about B’s validity.
It does not tell us which candidate an O node selects as its head if it sees both. The toy supplies no ranking rule. It also does not tell us that A or B becomes final, or that either branch continues indefinitely.
In the independent E scenario, candidate A contains four and candidate C contains ten. O permits A and rejects C; E permits both. Again, acceptance sets differ, but a head-selection and finality conclusion would require additional rules and observations.
A large vote count or a persuasive announcement cannot substitute for the validity check that a particular node is specified to enforce. If its current rule rejects ten, describing ten’s branch as popular does not make that field pass O.
Equally, a temporary lack of disagreement does not prove universal compatibility. If all observed candidates contain four, both rule sets accept the sample. The discriminating values have not been tested or observed.
Back to contents · Next section
9. Build an adoption record, not a single percentage
A useful upgrade evidence record identifies the participant, artifact, configuration, activation condition and observed behaviour. It also records the scope of the sample.
For three fictional operators, the information could be:
- J: correctly installed R package, with the supplied height-100 condition.
- K: still enforces O.
- L: announced support, but installed rules and configuration are unverified.
At height 100, J rejects seven and K accepts it under the model. L’s result remains unknown. Treating L’s announcement as confirmed installation would overstate the evidence.
One can count two known configurations out of three named operators. That is not a network-wide adoption percentage, a stake percentage, a share of block production or a measure of user preference.
If J operates several public endpoints, counting each endpoint as an independent decision-maker would also need justification. This lesson does not infer ownership independence from addresses or logos.
Ethereum’s governance overview explains that protocol changes involve social and technical coordination among different stakeholders, and that developers and node operators have distinct choices. That supports asking about actual implementation and adoption; it does not supply missing measurements for our fictional network. Ethereum governance
Back to contents · Next section
10. A compatibility claim needs a stated boundary
Before accepting “the upgrade is compatible”, ask the writer to complete the sentence:
Compatible with which old rule, for which records, before or after which activation condition, under which shared history and assumptions?
For R, the answer is directional containment after activation: every permitted integer is also O-permitted. For E, old permitted integers remain permitted, but newly admitted ten is not O-compatible.
If a real change also alters interpretation, state transitions or encoding, checking the numeric range alone would be insufficient. Two implementations might both parse the field but derive different state. That is another compatibility question.
Likewise, a portal continuing to display a familiar balance does not prove protocol-level compatibility. The display may hide the changed validation behaviour or query only one branch.
The goal is not to make every upgrade description long. It is to give each conclusion a testable object. A short statement with a defined rule set and activation boundary is more useful than a broad assurance that everyone is “on the latest version”.
Back to contents · Next section
11. Exercises with explained answers
Exercise 1: A shared pass
At height 100, n is four. O and R both accept it. Does that prove the O operator installed R?
No. Four passes both rules. The observation does not distinguish their enforcement.
Exercise 2: A restrictive witness
At height 100, n is seven. What do O and R conclude?
O accepts; R rejects. This disproves the claim that every O-valid candidate is also R-valid.
Exercise 3: An expansive witness
At height 100, n is ten. What do O and E conclude?
O rejects; E accepts. A new-rule-valid candidate can be invalid to an old-rule node.
Exercise 4: Before the boundary
A correctly installed E package checks n equal to ten at height 99. Does it accept?
No. The package still applies O below height 100. Installation alone does not activate E early.
Exercise 5: Support without installation evidence
L announces support at height 90. Can we fill in L’s height-100 result for seven under R?
No. The announcement does not establish the installed rules and activation configuration. The result remains unknown.
Exercise 6: The fraction
A candidate contains n equal to 4.5. Does it pass R because it is below five?
No. The supplied domain requires an integer. Checking only the upper bound misses part of the rule.
Exercise 7: A popular invalid candidate
An O node observes many messages supporting a candidate with ten. Does popularity change its validity result?
No. Under the stated O rule, ten fails. The model supplies no mechanism by which those messages change O.
Exercise 8: Does disagreement guarantee a lasting split?
No. The acceptance table establishes the possibility of different validation answers for particular candidates. Production, propagation, head selection, participant choices and finality determine what actually happens next.
Back to contents · Next section
12. Frequently asked questions
Are soft forks always harmless to old nodes?
That broad claim is not established. A restrictive rule can preserve one direction of acceptance while old nodes do not enforce the new restriction. Operational consequences depend on the actual system.
Does a hard fork always produce two permanent chains?
No. The compatibility issue does not by itself prove a lasting split. Actual adoption and produced histories matter.
Can a released specification prove network adoption?
It establishes a published specification under the relevant evidence assumptions. Adoption requires information about implementations, configurations and participants.
Is signalling the same as validating?
No. A signal and an enforced validation rule are different observations. A particular deployment specification determines how signals affect activation.
Why leave head selection out?
Because validity and head selection answer different questions. Adding an unstated selection rule would make the exercise look more conclusive than its evidence allows.
Back to contents · Next section
13. Sources and further reading
Sources checked on 12 October 2026. Numeric ranges, heights and operators are fictional and do not implement any cited network’s complete upgrade process.
- BIP 9: Version bits with timeout and delay: Deployed, Informational; assigned 4 October 2015; a specific signalling and deployment-state mechanism.
- EIP-1: Living; created 27 October 2015; proposal and implementation coordination.
- Ethereum governance: page updated 6 June 2026; stakeholder coordination and distinct participation choices.
- How Blockchain Works: a broader introduction for readers who need the basic shared-record model first.
An upgrade explanation becomes useful when it connects an exact rule difference to an activation condition and observed participant behaviour. A release, signal or shared result on one candidate cannot stand in for that whole chain of evidence.