How Blockchain Works | All-or-Nothing Execution and Its Boundaries

A fictional club lends a camera and a tripod as one kit. Its policy says that a kit reservation should succeed only when both items can be reserved.

The club does not want a completed camera-only reservation to remain when the required tripod step fails.

This introduces atomicity: a defined unit’s changes are treated together according to the system’s commit-or-discard rules.

The unit must be named. It might be one transaction or one call scope in the relevant execution model, not every activity a person associates with the task.

Our equipment and requests are fictional. No live contract is involved.

The beginner question is what changes belong inside the promised all-or-nothing boundary. A strong-sounding phrase becomes useful only when we know what it covers, how failure propagates and what remains outside it.

Contents · Next chapter

The fictional operation checks eligibility, marks the camera reserved, marks the tripod reserved and records the kit reservation.

These are several logical steps. The application can still define a transaction whose required execution changes are accepted together or reverted together.

Atomic does not mean the machine performs no intermediate computation. It concerns which effects persist under the execution rules.

Our paper model writes tentative changes on a working sheet and commits the final state only when the defined conditions are met.

The analogy is simplified. Real execution environments have precise semantics for storage, calls and exceptions.

For a beginner, the working sheet makes the idea visible: an intermediate mark can be attempted without becoming an accepted lasting result.

A trace can therefore show work that later disappears from the application state. That does not contradict the all-or-nothing property of the defined unit.

Contents · Previous chapter · Next chapter

Both fictional items are available and the borrower is eligible. The operation reserves the camera and tripod and records one kit reservation.

Under the exercise’s rule, the application changes persist together.

The result is not merely that each independent step looked promising. The operation reached its successful completion condition.

A useful evidence note names the kit identifier and the resulting reservation state. A green button animation is not a substitute for the relevant execution evidence.

This connects the guide to block explorers and receipts. Status should be interpreted against what the transaction was designed to do.

Our story gives the success condition explicitly so a reader can compare intention and result.

In a real application, determining whether all required conditions were enforced can need code and tests. Transaction success alone does not invent missing requirements that the program never checked.

Contents · Previous chapter · Next chapter

The fictional camera step succeeds, but the tripod is unavailable. The program rejects the kit operation and reverts its required application changes.

The camera should not remain reserved as an accepted effect of that reverted unit in our model.

This is the key benefit of the defined all-or-nothing behaviour. The application avoids leaving a half-completed reservation from that execution path.

The real rules determine which scope reverts and which effects are included.

Our paper exercise erases the working-sheet marks and leaves the original accepted state card unchanged for the reservation.

Do not confuse attempted work with surviving state. The machine can have executed instructions before recognising the failure.

The logs-and-events guide explains the same distinction for attempted messages. What a diagnostic trace shows and what the accepted outcome retains are different views.

Contents · Previous chapter · Next chapter

The borrower wanted the kit, but the tripod was unavailable. The request failed, while the program correctly enforced the all-or-nothing reservation rule.

A failed action can therefore be a successful test of a required boundary.

This distinction helps readers avoid describing every revert as a software defect.

A program can reject an ineligible, incomplete or otherwise disallowed action exactly as intended.

The testing guide asks for expected results before running a case. Here the expected failure should include the required absence of a lingering camera reservation.

If the camera stays reserved despite the defined full-unit revert, the model has not behaved as required.

The lesson is concrete: inspect both the error result and the after-state. A rejection message alone does not establish every intended invariant, just as an unsuccessful user request does not automatically mean the system violated its specification.

Contents · Previous chapter · Next chapter

The fictional kit operation fails after consuming some processing effort. The application reservation changes are discarded, but that does not mean no work was performed.

On Ethereum, a reverted included transaction can still use gas and have protocol-level effects such as the sender’s transaction nonce advancing.

The reverted application changes and the surrounding transaction-processing consequences are different categories.

This is why all-or-nothing must not be described as “nothing anywhere happened.”

Our paper model keeps a separate processing record while discarding the tentative reservation marks.

The fee guide and transaction-nonce material provide the surrounding context. This chapter gives only the conceptual boundary, not instructions for handling a real failed transaction.

A careful explanation says which state changes reverted and which protocol consequences still apply. The word failed describes an outcome within a system, not a universal eraser for every cost, record and observation.

Contents · Previous chapter · Next chapter

The fictional kit coordinator asks a camera component and a tripod component to perform sub-operations.

In Ethereum execution, a contract’s call to another contract can be part of the same overall transaction. It is not necessarily a separate top-level transaction with independent settlement.

This matters because the failure and revert scope depend on the call structure.

Our paper drawing places the component calls inside one larger transaction box.

The reader can now ask whether a failure propagates outward or is handled by the caller.

A simple story in which every sub-operation is always entirely independent would miss the point. A simple story in which every sub-operation failure always forces the whole transaction to fail would also be wrong for all possible code.

The actual control flow and execution rules determine the surviving result.

Contents · Previous chapter · Next chapter

The fictional club has an optional engraving service. If engraving fails, the coordinator may still complete the required camera-and-tripod reservation and record that engraving was unavailable.

This is a different policy from requiring every sub-operation to succeed.

Solidity can handle certain external-call failures through defined mechanisms, including try/catch. The reverted effects of the failed call do not imply that the caller must always revert its entire execution.

The details depend on the code and failure type.

Our paper model draws the optional engraving call inside its own scope and marks the accepted handling path.

The beginner lesson is to read the policy and control flow. A nested failure and a top-level failed transaction are not interchangeable descriptions.

The outer transaction can succeed while faithfully recording that an optional inner operation did not succeed.

Contents · Previous chapter · Next chapter

The fictional member first registers an account in one completed action, then requests a kit in another.

If the later kit request fails, the earlier registration does not automatically disappear. The two actions are separate units in the model.

Atomicity is not a promise to reverse every step in a person’s entire visit.

This is why diagrams should mark transaction boundaries instead of drawing only a smooth user journey.

An interface can present several operations as one task while the underlying system processes them separately.

The token-approval guide provides a related example: a successful authorisation can remain even when a later intended transfer does not complete.

A careful workflow explanation identifies which actions have already become accepted and which are still tentative. The user’s single intention does not, by itself, create a single technical rollback boundary across all those actions.

Contents · Previous chapter · Next chapter

The fictional club stores a camera reservation in one system and a delivery booking in another. One system’s local all-or-nothing rule does not automatically govern the other.

Cross-chain or cross-service workflows need their own coordination design, assumptions and failure handling.

This chapter does not claim such coordination is impossible. It rejects the assumption that one local atomic transaction supplies it for free.

The bridges guide explains why messages between networks have their own acceptance and trust boundaries.

Our paper exercise draws separate boxes and arrows between them. The arrows take time and can fail.

A useful claim says which effects are atomic within which system, then explains how the larger workflow handles partial completion.

The word blockchain should not collapse two independently governed systems into one invisible shared execution unit merely because an application links them together.

Contents · Previous chapter · Next chapter

A volunteer physically hands out the camera while a digital kit request is still provisional. The request later reverts because the tripod is unavailable.

The camera does not fly back into the cupboard.

Application-state reversal and physical consequence reversal are different tasks.

Our fictional club would need an outside procedure to reconcile the handover. The atomicity mechanism cannot supply an observation or action outside its execution boundary.

This is the same distinction developed in incident recovery and supply-chain handovers.

The example is deliberately ordinary. No financial transfer is needed to see the limitation.

A complete explanation should identify the point where an outside action depends on a digital result. It should not claim that a revert guarantees a complete human workflow returned to its exact earlier condition.

The technical guarantee remains valuable when its boundary is stated truthfully.

Contents · Previous chapter · Next chapter

The fictional camera component tentatively emits CameraReserved, then its containing required operation reverts.

An attempted event in a reverted execution scope should not be treated as a retained successful receipt log from that scope.

A debugging trace may expose the attempt, while the final receipt and application state show the accepted outcome differently.

The exact scope matters, especially when nested failures are handled and outer execution continues.

This is why the event guide asks which evidence source is being read.

Our paper exercise keeps a diagnostic working sheet but does not post the reverted reservation slip on the accepted noticeboard.

A reader can acknowledge the attempted computation without claiming that the reservation survived. The apparent contradiction disappears once attempted steps, retained logs and accepted state are kept as separate concepts.

Contents · Previous chapter · Next chapter

The fictional coordinator catches every failed component call and returns success without recording whether the required tripod was reserved.

The outer execution may complete, but the club’s intended kit policy is not enforced correctly.

This does not show atomicity itself failed. It shows that the program’s success path allowed an outcome the policy did not want.

A technical guarantee about reverting one execution scope cannot repair a missing requirement or an inappropriate error-handling choice.

The testing guide supplies the next step in our teaching model: define the required relationship and choose a case that exposes its violation.

A useful explanation therefore asks both what the execution mechanism guarantees and what the application actually made mandatory.

The word successful in a receipt has a defined technical meaning. It should not be expanded into proof that every human requirement was satisfied.

Contents · Previous chapter · Next chapter

Two fictional kit requests run in a sequence. The first reserves the last tripod successfully. The second then finds no tripod and reverts under the required rule.

Each transaction can be atomic while the outcome still depends on order.

Atomicity and fairness are separate properties.

The transaction-order guide explains this dependency in more detail. Here we only need to prevent another overclaim: all-or-nothing execution does not guarantee every participant gets the same opportunity or result.

Our paper model updates accepted state after the first request before evaluating the second.

If a reader gives both requests the original available tripod, the reader has changed the experiment.

The correct question is whether each defined unit preserves its required commit-or-discard behaviour in the state it encounters, not whether atomicity makes prior transactions irrelevant.

Contents · Previous chapter · Next chapter

The fictional kit transaction has executed on a currently selected branch. Its local execution result and the network’s later settlement condition are different aspects of the record.

A reorganisation can change the selected-history context in systems where that is possible under the relevant conditions.

Atomicity describes the execution unit’s effects under the applicable rules; it is not a substitute for explaining finality.

The confirmations and forks guides provide that broader context.

Our paper timeline marks execution and settlement separately rather than labelling everything final at the moment a component returns success.

This does not weaken the execution model. It prevents one property from being asked to establish another.

A complete report says which operation executed, what survived and what settlement evidence applies. Those answers can support a strong conclusion when their scopes are connected accurately.

Contents · Previous chapter · Next chapter

A short error message says ReservationFailed. Without the call structure, the reader may not know whether the camera call failed, the entire kit operation reverted or an optional engraving path was rejected.

The error label is an aid, not the complete execution story.

Our paper diagram uses nested boxes for transaction, required kit operation and optional service. Then it marks the point of failure and whether the caller handles it.

This makes the surviving effects easier to reason about.

A real investigation may need code, receipts, traces and state evidence. The beginner lesson is simply to ask which scope the evidence describes.

Do not assume the most dramatic interpretation from one word. A caught inner failure, top-level revert and outside-service cancellation can all need different explanations even when a website displays a similar message for each.

Contents · Previous chapter · Next chapter

Draw one transaction box containing camera reservation and tripod reservation. Require both.

Run a success case and commit both paper changes. Then reset the model, make the tripod unavailable and discard the required operation’s tentative changes.

Next add optional engraving with an explicit handled-failure path. Explain why the kit can succeed without engraving under that different policy.

Finally place registration in an earlier separate transaction and a physical handover outside all the boxes.

Ask which effects a later kit revert can undo.

No real execution occurs. The exercise is complete when a reader can identify the unit, failure propagation, handled exceptions and outside consequences without treating all-or-nothing as a promise about every event in the broader user journey.

Contents · Previous chapter · Next chapter

Atomic execution can prevent a defined unit from leaving unintended partial application changes when its required path reverts.

Its meaning depends on execution scope and control flow. A caught failure can allow outer work to continue; separate transactions and outside systems have their own boundaries.

Gas, nonce handling and physical actions should not be erased from the explanation merely because application changes reverted.

Carry three questions into the technical companion: which unit, which required conditions and which surviving effects?

Our fictional kit reservation shows why the property is useful and why it must be stated precisely. A reliable explanation can recognise both the strength of a transaction’s commit-or-discard rules and the additional coordination needed around them.

The result is a clear system map, not a slogan that every failure makes everything return to how it was before.

Contents · Previous chapter · Worked situations