eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Blockchain Capstone: Decide a Shared Booking System from a Fixed Evidence Dossier

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous article

Blockchain learning · Article BC100

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

The final test of blockchain understanding is a defensible decision, not the number of technical words in the explanation. Can you identify the required authority, replay the supplied records, separate digital acceptance from physical events and explain what evidence is still missing?

This capstone gives you a new, self-contained case: three fictional arts organisations share rehearsal rooms. Two candidate record systems are available. You will choose one for a bounded next-stage pilot, trace six operations, design the evidence and data boundaries, and reconsider the decision when one governance fact changes.

Everything is synthetic. There are no real bookings, people, payments, private keys or contractual commitments. The model answer is complete, but it is worth writing your own decision first. A justified non-blockchain choice can demonstrate excellent blockchain knowledge.

Choose your reading route

In this guide

Sections 1–4 are the fixed dossier. Section 5 contains the assignment and marking rubric. Sections 6–11 provide a worked model answer and the changed-fact decision. Finish with the self-check and reading route. Do not use facts from an imagined deployment to fill gaps in the supplied case.

Back to contents · Next section

1. The shared service and its decision rule

Organisations P, Q and R share two rehearsal rooms, A and B. Coordinator H maintains their booking timetable. We consider one discrete session, slot1, in each room. A booking identifies the organisation, room, session and record revision; it does not identify individual performers.

The current governance fact is explicit: P, Q and R all accept H as the sole authority that orders valid booking requests and commits the shared timetable. They still require authenticated requests, a traceable history, a consistent current view and independently inspectable exports. They have not required independently operated consensus for its own sake.

The next decision is which candidate should enter a controlled pilot. Both candidate descriptions below are supplied as feasible for the specified classroom task, with their limited evidence qualifications. The budget cap is eight fictional resource units for that next pilot. The predeclared selection rule is to choose the lowest-cost candidate that meets the current requirements. These units are not a currency or real quotation.

A selected candidate is not approved for production. The larger pilot still needs its own acceptance evidence. If no candidate meets the requirements, “neither yet” is allowed. The rule does not require choosing a blockchain.

Back to contents · Next section

2. Candidate D and candidate B

Candidate D uses a conventional shared database operated by H, with authenticated requests, a versioned append-only signed change log, replicated read copies and an offline export verifier. H alone determines the accepted order. Its pilot cost is three units. Its specified trust model assumes H fulfils the accepted ordering role; read replicas do not turn it into joint ordering authority.

Candidate B uses a permissioned blockchain operated by four separate organisations: P, Q, R and H each control one validator and their own administrative approval key. Under the supplied configuration, a change to the defined rule set requires three of the four approval keys. No single organisation controls enough keys for that change. This rule describes administrative changes, not the protocol’s entire consensus mechanism.

B’s protocol and operating assumptions are documented in the fictional technical package. A bounded feasibility exercise reports that the given workload is processed with one specified validator unavailable and yields no conflicting accepted records in the tested cases. This is finite evidence, not a proof of arbitrary Byzantine-fault tolerance. B’s pilot cost is six units.

For both candidates, the supplied package establishes feasibility of the same booking rules and independent export task in this small setting. Neither package establishes production security, all failure conditions, legal readiness or physical room availability. We do not infer those conclusions from the word database or blockchain.

Back to contents · Next section

3. The application rules and initial state

Each room-session record contains an occupant organisation or Free, plus a nonnegative revision number. Initially A/slot1 and B/slot1 are both Free at revision0. Revision numbers belong to each record independently.

A reserve request succeeds only if the organisation is an authorised requester, the expected revision equals the current revision, and the record is Free. On success, the occupant becomes that organisation and the revision increases by one.

A cancel request succeeds only if the expected revision matches and the authenticated requester is the current occupant organisation. On success, the occupant becomes Free and the revision increases by one. Every failed request leaves the tracked booking state and its revision unchanged. Fees, account nonces and network-specific failed-transaction accounting are outside this toy.

Every ordinary request below has an authentic signature from the stated organisation and is processed exactly once in the listed order. A valid signature does not override a stale revision or allow one organisation to cancel another’s booking. The exercise supplies these application rules directly; it does not ask you to infer them from a real protocol.

Back to contents · Next section

4. The six operations and the physical exception

Process this sequence without resetting between operations:

  1. P reserves A/slot1, expecting revision0.
  2. Q reserves A/slot1, also expecting revision0.
  3. Q reserves B/slot1, expecting revision0.
  4. P cancels A/slot1, expecting revision1.
  5. R reserves A/slot1, expecting revision2.
  6. Q cancels A/slot1, expecting revision3.

After this sequence, a separately authenticated facilities notice says room A is physically closed for the session. Treat the notice as reliable physical evidence for the classroom case. It does not automatically execute a cancellation, refund or substitute booking. Those actions are not defined in the current application rules.

The project also has operational contact information for each organisation, but the stated design keeps it in a separate controlled directory. The replicated booking schema contains organisation identifiers, room/session identifiers, actions, revisions and approval evidence only. No raw contact field is supplied as part of a booking request.

A later real implementation might still create identifying metadata or extra logs. Our schema restriction is a design boundary for this synthetic dossier, not a declaration that every derived datum is anonymous or that privacy compliance has been established.

Back to contents · Next section

5. Your assignment and the 20-point rubric

Produce a concise decision memo with the following six parts. Award points for supported reasoning, not for choosing the more elaborate technology.

  • Architecture decision, 4 points: apply the current authority requirement, budget and lowest-cost selection rule; identify the next-stage limit.
  • State trace, 4 points: classify all six operations and give both final room records with their revisions.
  • Control map, 3 points: distinguish D’s sole ordering role, B’s joint administrative rule and the limited failure evidence.
  • Data and physical boundary, 3 points: keep contacts outside the specified replicated schema and explain the closure notice without inventing a state transition.
  • Evidence plan, 3 points: specify reproducible acceptance, export and failure observations for the next pilot.
  • Changed-fact decision and limits, 3 points: change only the governance fact stated later, explain the revised choice and retain unresolved production questions.

A full-credit answer can be brief if every necessary distinction is present. A long glossary that does not decide the case earns no substitute points. The sections below form one complete model answer, worth 20/20 under this supplied rubric when all parts are retained.

Back to contents · Next section

6. Model answer: choose D for the current pilot

Under the current facts, select D for the next controlled pilot. All three organisations accept H as sole ordering authority, and the supplied feasibility evidence says D can provide the required booking rules, authenticated history and independent export task. D costs three units, below the cap of eight.

B also falls below the cap at six units, but the current requirements do not demand its joint ordering architecture. Under the stated lowest-cost rule, paying three additional units is not justified by an unmet requirement in this dossier. The difference is half of B’s six-unit cost; it is not a claim about real-world blockchain costs.

This is a scoped choice, not a claim that D is universally more secure, faster or cheaper. We lack evidence for those broad conclusions. We also do not infer that a signed log makes a dishonest H harmless. The base governance model explicitly accepts H’s ordering authority; that assumption belongs in the decision memo.

The next pilot should test the proposed benefits and failure behaviour rather than treating the feasibility packet as final acceptance. The Magenta Book’s evaluation guidance supports designing evaluation around the question and planning it early. Here the question is readiness for a bounded pilot decision, not demonstrated production success.

Back to contents · Next section

7. Model answer: replay the records

Operation1 succeeds. A/slot1 becomes P at revision1. Operation2 fails: its expected revision0 no longer matches revision1, and the record is occupied. The failed request does not increment the revision or replace P.

Operation3 succeeds independently on B/slot1, which becomes Q at revision1. A’s revision does not affect B’s record. Operation4 succeeds because P is A’s current occupant and expects revision1. A becomes Free at revision2.

Operation5 succeeds because A is Free at revision2. It becomes R at revision3. Operation6 has the correct expected revision3, but Q is not the current occupant of A. It therefore fails the cancellation-authority condition and leaves A unchanged.

The final state is A/slot1 occupied by R at revision3, and B/slot1 occupied by Q at revision1. Four operations succeed and two fail. All six authentic signatures coexist with only four accepted state transitions; signature authenticity and application permission are separate checks.

Hyperledger Fabric’s read-write documentation illustrates real validation that compares recorded read versions with current versions. Our simple integer revisions and booking rules are an independent classroom model, not a reproduction of Fabric’s block-and-transaction version coordinates or full validation process.

Back to contents · Next section

8. Model answer: explain control and the room closure

D gives H the accepted-order decision. Its read replicas distribute access to records but do not give P, Q and R independent ordering votes. A dashboard showing several copies would not change this authority assignment.

B distributes the specified validator operation across four organisations, and its administrative rule requires three distinct approval keys. A single key holder cannot meet that administrative threshold. However, operator labels do not alone establish independent hosting or software failures, and the three-key rule does not prove every consensus safety or liveness property.

For the physical exception, retain the final booking state and separately mark the reliable closure evidence in the operational incident record. The timetable says R has the accepted booking for A; the facilities notice says A cannot physically be used. These statements concern different facts and can both be true.

An authorised human process must decide what action to take about the closed room. The current toy has no facilities-closure transition, so the analyst must not silently erase R’s booking or move it to B, which is already booked by Q. A future rule could support a clearly defined suspension or alternative offer, but that would be a versioned change requiring its own authority and testing.

This is the physical-input boundary in practical form. A digital ledger can preserve an accepted statement; it does not make a room usable. NIST IR 8202 provides the broader blockchain background, while the supplied closure notice makes this particular example decidable.

Back to contents · Next section

9. Model answer: specify the next pilot’s evidence

Freeze the candidate and application versions, initial room records, request sequence, acceptance endpoint and expected outcomes. The six-operation trace becomes a reproducible fixture: the test must produce the four successes, two failures and exact final revisions above. A result with six successes fails, even if its interface looks responsive.

Add independently reset negative cases for an unauthorised organisation, a mismatched expected revision and an attempt to cancel another occupant’s booking. Require evidence of the protected state before and after each attempt. This is a bounded test set, not proof that every vulnerability has been excluded.

For export, require an independent evaluator to reconstruct the accepted transitions and their authority from the identified initial state, rules, history and any relevant configuration changes. It must not rely on the original dashboard for missing answers. Specify which trust material is accepted and preserve rejected-request observations separately from accepted state transitions.

For failure handling, define the outage condition and observable restoration endpoint before the trial. D’s coordinator outage and B’s single-validator outage are different scenarios; do not claim equal failure tolerance because both display a recovery time. Include an explicit check for conflicting accepted histories, along with the limits of the finite exercise.

For data placement, inspect the specified replicated request, event and state surfaces for a designated synthetic contact marker. Retain the contact directory separately, with access and lifecycle requirements that would need appropriate review in real use. Record the complete resource boundary and compare pilot spending with the eight-unit cap without hiding export or support dependencies.

Back to contents · Next section

10. Model answer: respond to failure without rewriting history

If the room closure reaches the support team, preserve its source, observation time and relationship to the booking. Notify the responsible fictional operations role through the defined classroom procedure; this article itself sends no message or changes any booking. Keep the unresolved physical-use decision separate from a false claim that the chain has failed validation.

If a signing role is suspected compromised in a future scenario, do not assume historical records disappear. A response plan would need an authorised restriction or revocation, evidence of when it became effective, review of affected actions and a controlled recovery process. The dossier supplies no such incident, so the memo should identify this as a required test scenario rather than claim it has already passed.

If an export cannot reconstruct authority for an accepted change, hold the relevant acceptance decision and retain the missing-evidence finding. Do not substitute a current-state screenshot or silently declare the change invalid. The evidence may be incomplete even when the historical action was legitimate.

These responses preserve a useful distinction: a rejected request, a stalled service, missing verification evidence and a physically unavailable room call for different actions. A single red status label would conceal the information needed to choose correctly.

Back to contents · Next section

11. Change one governance fact and decide again

Now replace only the base governance fact: P, Q and R no longer accept any single organisation, including H, as sole ordering authority. They require the jointly operated ordering option described in B. All other supplied candidate capabilities, costs, operators and next-stage limits remain unchanged.

D no longer meets the authority requirement, regardless of its three-unit price. B meets the changed structural requirement under the supplied description and costs six, still below eight. Select B for the next controlled pilot, with the same need to validate its documented assumptions and evidence boundaries.

This reverses the candidate choice without changing the six booking outcomes or inventing a new performance figure. The reason is a changed governance requirement, not the disappearance of database technology or a proof that blockchains are uniquely capable of joint control. Other architectures could be evaluated if supplied; this dossier contains only D and B.

If the four operator identities later prove to share one controlling party, or the available export cannot support the required verification task, that would be new evidence requiring reassessment. Do not quietly assume such a defect now, but do not grant permanent approval in advance either.

Back to contents · Next section

12. The complete decision memo in short form

“Under the base dossier, choose D for the controlled pilot: the organisations accept H’s sole ordering authority, D meets the supplied task requirements and its three-unit cost is the lowest eligible cost below eight. Replay yields A/slot1 = R, revision3 and B/slot1 = Q, revision1, with four successes and two failures.

“Keep organisation contacts outside the specified replicated schema, preserve the room-A closure as separate physical evidence, and require an authorised operational response rather than automatic reassignment. The pilot must test exact state transitions, authority, export reconstruction, defined outages and resource boundaries.

“If the sole-ordering-authority acceptance is withdrawn as specified, choose B for the next pilot at six units because D no longer meets the changed requirement. Neither choice establishes production security, legal readiness, physical availability or superiority over architectures absent from the dossier.”

This memo earns its conclusion by keeping the evidence, assumptions and decision rule visible. Its brevity does not remove the need for the supporting trace and test plan.

Back to contents · Next section

Self-check and next learning steps

Can you explain why operation6 fails even with a correct revision? Can you explain why a physical closure does not automatically cancel a booking? Can you name the fact that reverses the architecture choice without claiming a universal technology winner?

If any answer is unclear, revisit transaction validity, authority, physical inputs or acceptance evidence before adding more terminology. For a broader method of linking claims to evidence, use How Assurance Cases Work.

The next useful exercise is to change one supplied requirement, write the resulting decision and identify which existing evidence no longer suffices. Keep the change explicit. That habit transfers to new systems long after a particular protocol version has changed.

Back to contents · Next section

Sources and further reading

Understanding blockchain includes knowing when its additional coordination machinery answers a real requirement, and when the supplied evidence supports a simpler choice.

Back to contents