中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC099
A blockchain proposal becomes easier to evaluate when each important promise names a deliverable, the evidence needed to accept it and the party responsible for supplying that evidence. “Decentralised,” “exportable” and “always available” are starting claims, not completed specifications.
This lesson converts a fictional supplier proposal into a technical acceptance schedule. We inspect control of nodes and upgrade keys, follow a missing configuration transition through an export, define a service observation and reconcile a bounded cost quotation. The worked decision rejects an attractive score because a mandatory exit requirement remains unmet.
This is an educational requirements exercise. It is not a real purchase, vendor ranking, contract, legal opinion or instruction to move data or credentials. All organisations, records, credits and service conditions are invented. Proposed wording would need appropriate procurement and legal review before use in a real agreement.
Choose your reading route
In this guide
- 1. Fix the proposal’s identity and scope
- 2. Replace the node-count slogan with a control map
- 3. Record who can change the rules
- 4. Specify what a complete export must allow
- 5. Diagnose the missing transition in the supplied package
- 6. Turn the gap into a specific deliverable
- 7. Describe retained data instead of promising universal deletion
- 8. Define the service being promised
- 9. Reconcile the bounded cost quotation
- 10. Apply the decision order
- 11. Build the six-row evidence schedule
- Exercise and model answers
- Frequently asked questions
- Sources and further reading
Start with sections 1–3 for the proposal and control evidence. Sections 4–6 build the independent export requirement. Sections 7–9 cover retained data, service boundaries and costs. Section 10 makes the decision, followed by a worksheet and answers. For the broader supplier-review framework, read Writing a Vendor Due-Diligence Questionnaire.
Back to contents · Next section
1. Fix the proposal’s identity and scope
Fictional supplier V offers consortium K a managed catalogue-record service, product R version R1. The assessed network is N, with a specified initial configuration C0 and application rules A1. The proposal covers a fixed twelve-month classroom scenario, a fixed record-volume envelope and one planned export at exit.
Its front page promises “four-node decentralisation,” “complete ledger export,” “high availability” and “360 credits for the year.” An attached evidence packet contains more precise details. The buyer’s task is to connect those details to acceptance conditions, not merely count affirmative answers.
K requires an independently usable record package after exit. That condition is mandatory. A separate preference score evaluates usability, support, price and documentation, but it applies only after mandatory conditions are met. This decision order is supplied before inspecting R1’s score.
The NIST SP 1326 due-diligence guide, finalised in July 2026, treats relevant supplier research as support for informed acquisition and lifecycle decisions. Our task is narrower: specify the exact blockchain artefacts that would make this particular proposal checkable.
Back to contents · Next section
2. Replace the node-count slogan with a control map
N has four nodes, but V operates three and K operates one. The dossier does not establish four independent operators. It also does not establish independent hosting, client software or identity dependencies merely from the node count.
The proposed deliverable is a versioned control map: node identifier, operating organisation, hosting dependency, validation role, access dependency and the evidence date. V supplies the map; K’s technical reviewer checks it against the defined deployment evidence. Any unknown dependency remains marked unknown.
Acceptance means the map accurately describes R1’s supplied scope. It does not mean the buyer has adopted a universal minimum decentralisation score. The classroom requirement is disclosure, not a claim that four nodes necessarily satisfy a particular fault model.
This gives a precise change obligation for the proposed schedule: material changes to operator or dependency assignments should produce an updated map before the buyer relies on the new arrangement. A notification promise is distinct from a technical restriction preventing unilateral change. If K needs a veto, that requires a separately specified control and decision process.
Back to contents · Next section
3. Record who can change the rules
The supplied upgrade rule requires two of three named approval keys, A, B and C. V controls A and B; K controls C. Under this exact rule, V can supply enough technical approval signatures without K. That is a capability statement, not evidence that V has abused the power or that every such change is organisationally permitted.
The schedule should identify which changes this rule covers: the particular application upgrade path in the dossier, rather than every possible network action. It should also require the effective rule version, approval evidence and activation point for any accepted upgrade. Separate maintenance access and other administrative powers need their own entries if relevant.
Hyperledger Fabric’s channel-configuration documentation provides a concrete example of versioned configuration elements and policies governing modification. It supports the habit of examining actual change policies. Our two-of-three application rule is fictional, not a universal Fabric policy or a deployment recommendation.
An appropriate proposed deliverable is therefore an effective-authority record, not a slide saying “community controlled.” A policy document describing what administrators should do and evidence of what the software permits are related but different parts of that record.
Back to contents · Next section
4. Specify what a complete export must allow
K’s mandatory exit task is to validate the accepted catalogue history independently after the original live provider is unavailable. It is not enough to display a current balance or open a spreadsheet. The task includes reconstructing effects and checking the authority governing each accepted event.
The proposed export package includes the identified initial state and trusted configuration C0, application rules A1, ordered events, their relevant inclusion context, authenticated configuration transitions and the evidence needed to verify approvals under the effective rules. Identifiers and ordering must bind these artefacts to network N and the same exported history.
The evaluator receives documented offline verification tools and the necessary public trust material. The proposed schedule requires that this specific verification function remain usable for the stated two-year post-exit classroom period without an online activation call to V. That is a requested service condition, not a claim that such a licence or obligation already exists.
The acceptance test uses a disconnected test environment and a specified fixture. It checks that the evaluator reaches the expected results without the original dashboard. It should record tool versions and any remaining external assumptions. Independence from V’s live service does not mean freedom from every trusted starting point.
Back to contents · Next section
5. Diagnose the missing transition in the supplied package
The fictional history contains twenty application events, E1 through E20. The supplied authoritative dossier establishes that E1–E10 use configuration C0. An authorised configuration transition to C1 takes effect before E11; E11–E20 use C1. These event labels are sequence labels, not block-height claims.
The export includes all twenty event records, their stated effects and the supplied inclusion context. The evaluator verifies the relevant record hashes and can replay the current effects. However, the export omits the authenticated transition evidence establishing C1 from the trusted C0 path. The evaluator is not allowed to retrieve it from V’s live endpoint under the exit test.
As a result, E1–E10 satisfy the stipulated independent authorisation-verification task, while E11–E20 do not. The count is ten verified and ten unresolved for that task. It is not twenty verified merely because all twenty rows exist, and it is not ten proven-invalid events.
The authoritative classroom dossier lets us know what happened; the exported evidence available to the hypothetical departing buyer is intentionally incomplete. Keep those perspectives separate. Otherwise, a reader may accidentally use information outside the export to award a pass the buyer could not reproduce.
Back to contents · Next section
6. Turn the gap into a specific deliverable
The repair request is to supply the missing authenticated transition and its binding context, together with an export process that includes such transitions for the specified history. Acceptance requires the offline evaluator to establish the C0-to-C1 authority path and verify the applicable approvals for all twenty events.
A newly supplied file labelled C1 is insufficient by itself. It must satisfy the defined authentication and transition rules relative to the trusted starting configuration, and correspond to the same network and sequence. A hash matching a provider’s own manifest does not independently authorise a new trust anchor.
The technical reviewer records the fixture identifier, package version, verification-tool version, outcomes and exceptions. V is responsible for supplying the corrected artefacts. K’s reviewer decides whether the evidence satisfies the proposed technical acceptance rule. Those assigned responsibilities do not by themselves create an enforceable contract.
Avoid asking V to transmit private signing keys as proof. The requirement is verification evidence and appropriately scoped public material, not control over secret credentials. A technical acceptance package should reveal enough to perform the task without unnecessarily exposing operational secrets.
Back to contents · Next section
7. Describe retained data instead of promising universal deletion
The proposal’s exit page says “delete the account.” That describes an interface or access action, not the fate of every ledger replica, exported package, index or backup. The proposed schedule needs a data-location map for the exact service.
For the classroom scenario, catalogue events contain only synthetic identifiers and approved nonpersonal labels. Separate contact information is excluded from the replicated event design. Even here, the schedule should identify which historical records remain on consortium nodes, which provider-controlled indexes can be removed, and what happens to ordinary backups under the specified retention process.
A deliverable can state the categories retained, responsible party, stated purpose, access treatment and verification evidence for a requested deletion operation. It should distinguish an observed deletion from an unsupported claim about unknown past copies. This article does not determine a lawful retention period or supply a legal basis for retaining real personal data.
The acceptance reviewer should reconcile the retained-data map with the export obligation. Deleting the only copy of evidence before a verified export would undermine the stated exit task. Conversely, fulfilling an export requirement does not grant unlimited permission to retain every unrelated field.
Back to contents · Next section
8. Define the service being promised
“High availability” could refer to a node process, an RPC endpoint, a current index or the ability to complete an authorised catalogue change. Those are different observations. K’s proposed technical schedule names the last of these: the specified end-to-end catalogue task, with its evidence endpoint.
An illustrative test contains ten scheduled, separately identified probes. Each is successful only if the authorised update obtains the specified accepted-state evidence within its defined deadline. In the supplied result, nine succeed and one times out. The observed sample success fraction is 9/10 = 90%.
That fraction is not a monthly or annual availability estimate. We have no continuous service-time observation, no representative sampling argument and no large-run uncertainty analysis. A node-process uptime percentage cannot silently replace the failed application probe either.
The proposed schedule should define the measurement window, start and endpoint, observer, exclusions, missing-observation treatment and evidence access. If later commercial terms attach remedies or payment consequences, qualified reviewers must define them. This classroom worksheet neither imposes a remedy nor accepts a service-level agreement.
Back to contents · Next section
9. Reconcile the bounded cost quotation
The headline 360 credits equals twelve monthly service charges of 30 credits. The detailed proposal also lists a one-time setup charge of 120 credits and one planned exit export charge of 40 credits. Under the supplied fixed-volume scenario, no other charge applies.
The relevant twelve-month scenario total is 120 + 12 × 30 + 40 = 520 credits. The headline omits 160 credits from this scenario. That is an omission from the labelled comparison, not evidence that the monthly arithmetic is wrong.
Credits are invented classroom units, not a currency, price quote or spending recommendation. Different volumes, additional exports, extensions or future changes are outside the supplied quotation. Their costs remain unknown rather than zero.
A useful proposed cost deliverable names the included workload envelope, setup, service period, support scope, export conditions and change-pricing process. The requirement is to make the evaluated scenario reproducible. It does not authorise a purchase or settle which commercial allocation would be fair.
Back to contents · Next section
10. Apply the decision order
The supplied preference scoring gives R1 30/30 for usability, 25/25 for support, 25/25 for price and 10/20 for documentation: 90/100 in total. Treat these as the fictional committee’s recorded preference scores, not an independently derived vendor-quality measurement.
Despite 90 points, the mandatory independent-exit gate fails because the exported configuration-authority chain is incomplete. The proper decision is “not eligible for acceptance under the current requirements,” with a named evidence gap and repair route. A high preference score cannot change the order of the decision rule.
The control map also reveals vendor concentration, but the given requirement there is accurate disclosure. Do not invent an additional numerical independence gate after seeing the result. K may propose a different control requirement for a revised specification, but that change needs to be explicit.
Similarly, the ten service probes establish a bounded observation; the dossier supplies no mandatory numerical service threshold for this procurement decision. Record the result and the need for a defined obligation rather than pretending that an unstated threshold was passed or failed.
Back to contents · Next section
11. Build the six-row evidence schedule
A complete model schedule can be written in six rows, each with a responsibility and acceptance artefact.
- Control: V supplies the N/R1 operator and dependency map; K checks the four-node ownership description and records unknowns.
- Changes: V supplies effective upgrade policies, scoped powers, approval records and activation context; K checks technical authority against the declared rule.
- Exit: V supplies the complete independent-verification package; K’s evaluator tests all twenty events offline, including the authenticated C1 transition. This is the mandatory failed gate.
- Retention: V and K identify their respective replicas, indexes, exports and backups; the reviewer checks that proposed deletion and retention statements match those specific surfaces.
- Service: V supplies the defined end-to-end observation evidence; K checks the nine-of-ten result without converting it into unsupported annual availability.
- Cost: V supplies the fixed-envelope schedule; K reproduces 520 credits and records unknown costs outside the envelope.
These are proposed technical deliverables, not an executed agreement. An eventual contract would need authorised parties, reviewed wording and appropriate treatment of obligations, exceptions and remedies. The educational value lies in making each promise testable before anyone mistakes it for proven capability.
Back to contents · Next section
Exercise and model answers
- Do four nodes prove four independent operators? No. The supplied allocation is three operated by V and one by K; other dependencies also require evidence.
- Can V satisfy the supplied two-of-three upgrade rule without K? Yes, because it controls A and B. This establishes technical capability, not legitimate intent or an actual upgrade.
- Does the export prove E11–E20 are invalid? No. It lacks the evidence needed for the defined independent authority check.
- Would an unauthenticated C1 document fix the gap? No. The transition must be established under the trusted starting path and bound to the same history.
- Is the scenario total 360 credits? No. Including the supplied setup and exit charges gives 520.
- May the 90/100 preference score override the failed exit gate? No. Eligibility comes first under the predeclared rule.
For a writing extension, replace “complete export” with two sentences naming the artefacts, offline verification task and required result. Include the configuration transition; an answer listing only current rows has missed the central dependency.
Back to contents · Next section
Frequently asked questions
Is this just another supplier questionnaire?
The broader prerequisite covers how to ask and assess supplier questions. This lesson turns a specific blockchain record package and control model into proposed deliverables with acceptance evidence.
Does independent verification require a fully trust-free system?
No. Here it requires independence from the original live provider for a defined task, while retaining the explicitly trusted starting configuration and documented verification assumptions.
Can a future promise count as current export capability?
No. Record it as a proposed remediation obligation with evidence still due. A repaired package needs its own versioned acceptance result.
Back to contents · Next section
Sources and further reading
- NIST SP 1326: final publication dated July 2026, document history records 8 July 2026; checked 12 October 2026. Narrow supplier-research framing only.
- Hyperledger Fabric channel configuration: versioned configuration and modification policies, checked 12 October 2026; not a specification for the fictional network.
- Hyperledger Fabric ledger documentation: current state and retained transaction history, checked 12 October 2026.
- Writing a Vendor Due-Diligence Questionnaire: the general supplier-review prerequisite.
The best technical schedule lets a reviewer point to the exact evidence that would make a promise acceptable, and the exact missing item that prevents acceptance today.