Coin RevolutionAn independent
reading edition

Inside the infrastructure

Consensus and Execution Answer Different Questions

A valid transaction, an accepted block, a chosen history and a programmable application are related properties, not synonyms.

1,179 words6 min readCoin Revolution Editorial Desk

New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.

Two historical opinion pieces in the recovered collection compare Bitcoin and Ethereum Classic and argue for a restrictive use of the word blockchain. They are useful records of an author's position, not definitions that this edition automatically adopts. A clearer technical comparison starts by separating the questions that the terminology bundles together. Which state changes are valid? How are operations executed? How is an accepted history selected? What makes competing behaviour costly? What can an application express? This article develops a fictional comparison framework and uses primary Bitcoin and Ethereum documentation for a few underlying distinctions. It does not rank tokens, predict their value or treat a consensus label as a complete security assessment.

Validity is a rule check, not a popularity contest

Imagine a fictional ledger in which a spend must identify an existing unspent item and satisfy its authorisation condition. A proposed operation that fails those rules does not become valid merely because many machines repeat it. The system needs an agreed rule set and a procedure for evaluating proposals against it. In Bitcoin's developer documentation, discussion of chain selection explicitly concerns valid blocks; a proof-of-work result does not remove the other validity requirements. This distinction prevents an economic or consensus claim from being mistaken for permission to ignore transaction rules.

Use a simple fictional test. A proposed batch includes two spends of the same item, even though the rules allow only one. Separately, the batch carries whatever ordering credential the fictional consensus process expects. The reviewer should ask two questions, not one: does the credential satisfy its own conditions, and does the represented batch satisfy the ledger rules? Passing one check does not imply passing the other. An architecture diagram that shows only block production can hide the validation work performed by participants who decide whether to accept the resulting data.

Execution determines what an ordered operation does

Execution concerns the consequences of operations under a defined state-transition model. Ethereum's EVM documentation describes this relationship in terms of an existing state, valid transactions and the resulting state. That is a different role from deciding which competing history the network follows. A programmable operation can update several pieces of state, invoke other code or fail under its execution rules. The important comparison is which behaviours the system supports and how their results are determined, not whether the interface happens to use the same word transaction as another network.

In the fictional ledger, let one operation register a reservation and another cancel it. Executing register and then cancel produces a different result from executing cancel and then register if the cancellation requires an existing reservation. The operations' logic determines the result given an order; another mechanism must establish which order is accepted. This example also explains why deterministic execution is not the same as simultaneous global knowledge. Participants can agree on how to evaluate a sequence while still needing a protocol to resolve competing proposals about which sequence to evaluate.

Consensus concerns agreement under specific assumptions

A consensus discussion should identify its participants, its fault assumptions and the property being investigated. A proof-of-work system and a proof-of-stake system use different mechanisms and assumptions; neither name alone lists every relevant implementation detail. Ethereum's primary documentation describes its proof-of-stake mechanism as such. That establishes a concrete technical subject to examine, rather than requiring the reader to accept an opinion article's preferred vocabulary as a universal taxonomy. Comparing mechanisms is more productive when the claims are specific enough to test against their actual rules.

For the fictional comparison, suppose two candidate histories are individually well formed but contain different operation orders. Ask how a participant decides which one to follow, what evidence it needs and what can cause its decision to change. Then ask what assumptions support the expected agreement. This separates the selection procedure from the execution engine and from the software used to display results. A claim that a system is decentralised should not substitute for those answers. It is a conclusion that needs a stated meaning and evidence about the relevant dependencies.

Programmability has dimensions, not a single switch

A comparison that says one network has contracts and another has none can conceal the actual question. Bitcoin's transaction documentation describes a script-based authorisation system; Ethereum's EVM documentation describes a different execution environment. These are not identical programming models. The useful question is which conditions and state changes each model can express, under which resource limits and with which verification costs. A restriction can be a deliberate design choice rather than evidence that no programmable condition exists at all. More expressive does not automatically mean more suitable for every application.

Consider two fictional application requirements. One needs a fixed spending condition involving several authorisations. Another needs a shared registry whose entries change according to application logic and interact with other programs. A meaningful design comparison maps those requirements to the mechanisms available in each candidate system. It also identifies what must run outside the base protocol. The result may favour different architectures for different requirements. That is a more precise outcome than compressing the comparison into a slogan about which chain is a better version of another.

Economic incentives do not specify every security property

Economic mechanisms can make certain forms of behaviour costly or reward participation, but a security review must still identify the behaviour being constrained. Reordering accepted operations, submitting invalid operations, withholding data, compromising an application key and misleading a user through an interface are different events. A mechanism designed to address one does not automatically address the rest. A high cost assigned to one attack path is not evidence that every dependency in an application is protected by the same barrier or even participates in that mechanism.

In the fictional reservation system, an attacker might try to change the chosen history, but a separate failure could come from a legitimate administrator using an overly broad application permission. These scenarios cross different boundaries. The review should name which protocol rule, application check or operational control bears on each one. It should also distinguish a theoretical assumption from a measurement of an actual deployment. No present monetary estimate follows from this exercise. Its purpose is to prevent one appealing property from standing in for an examination of the rest of the system.

Compare claims one row at a time

A useful comparison sheet has separate rows for state representation, transaction validity, execution, history selection, data requirements, participation assumptions and application authority. Each row asks for evidence from the relevant specification or implementation. Unknowns stay visible. This avoids a common rhetorical shortcut: demonstrating a property in one row and then declaring victory in every other row. It also makes historical material easier to read. An author's prediction, definition or economic preference can be recorded without being silently promoted into a current engineering finding.

The final result should explain what a system does and what assumptions the explanation relies on. It need not force every network into the same design or deny their differences. Separating the layers makes those differences more legible. Validity tells us which changes satisfy rules; execution tells us their effects; consensus addresses an accepted history under a specified mechanism; applications add further behaviour and authority. Once those questions are distinct, comparisons become less dependent on labels and more useful for readers trying to understand what has actually been claimed.

Technical references

From the recovered archive

Keep reading.