中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC087
A consortium chain needs more than a list of organisations allowed to connect. It needs an agreement about what each organisation may assert, how membership changes become effective, who examines disputed evidence and how the service continues when a member leaves.
These questions are easiest to test with a departure. Removing one participant can change access, application roles, record-completion paths and cost commitments at different times. It does not automatically remove old records or resolve disagreements about the outside world.
This lesson follows a fictional four-organisation equipment consortium. All organisations, dates, records and costs are invented. The example is a governance worksheet, not a production configuration, contract template or legal clearance for an enterprise project.
Choose your reading route
In this guide
- 1. Begin with the shared task
- 2. Membership and application roles answer different questions
- 3. The agreement must describe a complete record
- 4. A departure notice is not yet an effective permission change
- 5. Replacement requires both admission and the right role
- 6. Preserve the difference between old authority and current authority
- 7. Test a disputed delivery without voting physical reality into existence
- 8. Exit access and retained copies are separate
- 9. Reconcile costs after the member leaves
- 10. Run a departure rehearsal on paper
- 11. Exercises with explained answers
- 12. Frequently asked questions
- 13. Sources and further reading
- Read sections 1–3 for the consortium’s purpose, roles and agreement.
- Follow sections 4–6 through a member’s notice, effective departure and replacement.
- Use sections 7–9 to analyse a disputed delivery, retained copies and the funding gap.
- Complete the stress tests and exercises before treating membership as the whole design.
Back to contents · Next section
1. Begin with the shared task
The consortium maintains equipment-inspection and delivery records. A manufactures equipment, B carries shipments, C performs laboratory inspections and D receives equipment.
They want to compare which organisation submitted each statement and preserve a traceable sequence of later corrections. They do not assume that recording a statement makes it physically true.
The model uses synthetic organisation codes and fictional equipment records. It contains no personal information, token offering or investment arrangement.
Mainland China’s 2021 MIIT/CAC guidance discusses blockchain applications in supply-chain management, traceability and data sharing. That provides context for studying this kind of collaboration. It does not approve this fictional project or prove that any particular enterprise arrangement meets applicable obligations. MIIT/CAC guidance
The task should be described in business terms before a platform is chosen. If the partners cannot agree what counts as an inspection statement or delivery acknowledgement, a shared ledger will preserve their disagreement more consistently, not solve it automatically.
Back to contents · Next section
2. Membership and application roles answer different questions
At the start, agreement revision 4 recognises A, B, C and D as members. Their roles are distinct:
- A may submit manufacturing records.
- B may submit carrier statements.
- C may submit laboratory inspection results.
- D may submit receiver acknowledgements.
A member is not automatically authorised to perform every role. D cannot certify a laboratory test merely because D can read the ledger.
The system also has identified governance administrators who can implement approved membership and role changes. Their procedure is supplied as valid where a case explicitly says it has completed; this lesson does not prescribe a voting threshold or administrator configuration.
Hyperledger Fabric’s membership documentation distinguishes recognised identities, organisations and roles at different scopes. Its policy documentation explains how allowed actions depend on configured policies. These are useful technical examples of why a network connection and an application permission should not be treated as synonyms. Fabric membership Fabric policies
The fictional consortium is not claimed to implement the full Fabric workflow. The worksheet asks what needs to be specified, regardless of the eventual software.
Back to contents · Next section
3. The agreement must describe a complete record
For a shipment record, the consortium distinguishes a carrier’s “delivered” statement from the receiver’s acknowledgement. Both have an author, an identified shipment and a time reference.
An inspection result likewise identifies the equipment, test version and organisation responsible. A later correction links to the original statement rather than pretending the first statement never existed.
The partners also define how a disputed status is represented. A record can remain visible while being marked as contested; visibility does not require declaring the dispute resolved.
This separation prevents a common shortcut. If B writes “delivered”, the application can establish that a recognised carrier submitted that statement under the supplied technical checks. It cannot infer D’s agreement unless D’s acknowledgement is actually present.
The agreement should therefore say what a completed workflow means. A single available record is not necessarily a complete evidence packet.
In the toy, governance decisions, application statements and external evidence are different record types. Mixing them into a generic “verified” label would hide who verified what.
Back to contents · Next section
4. A departure notice is not yet an effective permission change
B submits a departure notice on day 20. Under the supplied agreement, B’s departure is scheduled for day 30. The necessary governance procedure is completed, and the resulting removal becomes technically effective on day 30.
On day 21, the notice exists, but B still has its current membership and carrier role. A report saying “B’s access ended when it sent the notice” would be wrong for this model.
From the effective day-30 state onward, B cannot submit new carrier statements through the specified application path. Assume the supplied access controls cover that path and that no alternative active credential or access path is being granted in the case.
This is an explicit exercise assumption, not a universal promise that one removal action closes every real endpoint. A real system would need to identify and verify its relevant access paths.
Fabric’s configuration-update documentation illustrates that changes to a running channel’s configuration have a defined process. A business announcement alone is not evidence that the relevant technical configuration changed. Fabric configuration updates
The useful evidence is the approved change and its effective state, not only the member’s intention to leave.
Back to contents · Next section
5. Replacement requires both admission and the right role
A new organisation E is proposed as the carrier replacement. In this independent continuation, E is admitted as a member on day 32 but receives the carrier role only on day 33.
On day 32, E’s membership alone does not permit carrier statements. On day 33, the role is effective and E can submit them, subject to the application’s other conditions.
The distinction matters during the gap after B leaves. Between the effective removal and E’s carrier-role activation, the consortium has no active carrier authorisation under the supplied model.
That does not mean all stored records vanish or every consortium function stops. Manufacturing and laboratory statements may still be possible under their unchanged rules. The affected workflow is the one requiring an active carrier.
E’s arrival also does not authorise it to claim that it witnessed B’s earlier deliveries. A replacement role permits specified future actions; it does not manufacture historical knowledge.
An orderly transition therefore needs a task map, not simply a replacement name. Which actions lack an authorised performer? Which records remain incomplete? What evidence must be preserved for unfinished cases?
Back to contents · Next section
6. Preserve the difference between old authority and current authority
Suppose B submitted a carrier statement on day 10, while its role was valid. Its later departure does not make that historical role fact disappear.
However, historical authorisation does not prove the delivery happened. It establishes who was allowed to make that type of statement at that time.
Conversely, a day-31 statement cannot rely on B’s earlier membership to pass the current role check. The model requires authority at the relevant action point.
A useful record therefore includes the applicable agreement or role revision, rather than looking only at the current member list. An investigator asking “Was B authorised on day 10?” needs historical context.
This does not instruct a system to accept every old signature indefinitely. The toy gives the accepted day-10 record as a fact. Rules for submitting late or replayed statements would need separate specification.
The lesson is to avoid using today’s role list as a universal explanation of both past and future actions.
Back to contents · Next section
7. Test a disputed delivery without voting physical reality into existence
The day-10 record says B delivered shipment S7. D later supplies a conflicting statement that the equipment was not received. The exercise does not establish which outside-world account is correct.
The ledger can preserve both statements, their authors and the order in which they were recorded. It cannot decide physical truth merely by counting how many members prefer one story.
The consortium’s designated dispute reviewers need an evidence task: compare the shipment identity, timing, receipt documents and relevant observations. Each item must be evaluated for provenance and scope.
A laboratory inspection may establish a test result for identified equipment, but it does not necessarily establish receipt at D’s site. A carrier timestamp may establish when B submitted a message, but not the time of physical handover.
E cannot resolve the conflict just by becoming the new carrier. It did not acquire knowledge of S7 through admission.
If the authorised review later supports a correction, the toy adds a linked correction record identifying the original statement and the basis for the change. It does not overwrite the historical fact that B made the earlier assertion.
If the evidence remains insufficient, the record remains disputed. Calling the entry “onchain” is not a substitute for resolving the evidence gap.
Back to contents · Next section
8. Exit access and retained copies are separate
Before leaving, B received some ledger records and supporting documents. Removing its future access does not, by itself, erase copies already delivered to B.
The consortium therefore needs to distinguish technical access termination from duties concerning retention, return, permitted use or deletion. Those duties depend on the applicable arrangements and rules; this lesson does not invent a universal retention period.
Similarly, the remaining members may need historical evidence to interpret earlier transactions or disputes. Deleting every reference to B would undermine that context rather than simply tidy the member list.
The model does not claim that all data should remain onchain forever. It asks the partners to decide what belongs in shared records, what remains in controlled document storage and what promises each design can actually support.
A privacy or deletion promise should not be based only on a membership button. It must account for replicas, received files and any external systems involved.
For real Mainland projects, data and sector-specific obligations require their own current analysis. A permissioned architecture is not a general exemption from those questions.
Back to contents · Next section
9. Reconcile costs after the member leaves
The fictional consortium’s next operating period costs 120 accounting units. Initially, four members committed 30 each, covering the 120.
Under the supplied exit arrangement, B has no contribution obligation for the next period. A, C and D’s existing commitments remain 30 each. No replacement contribution from E has yet been agreed.
The committed total is therefore 90, leaving a gap of 30 against the stated cost.
A proposal to charge the three remaining contributors 40 each would arithmetically cover 120. But arithmetic does not establish that they agreed to that change. The model does not authorise an automatic revised invoice.
Nor does admitting E automatically create a 30-unit commitment. Membership, operational role and funding terms are separate records.
The supported conclusion is a funding decision still required, not immediate shutdown or inevitable failure. The exercise supplies no reserve, borrowing arrangement, cost reduction or other funding source.
This is why an exit plan should include operating obligations. A technically successful member removal can leave the service with an unresolved resource question.
Back to contents · Next section
10. Run a departure rehearsal on paper
A useful rehearsal asks what changes at each point.
At day 20, the consortium has notice of an intended departure. At day 30, the specified access and role removal is effective. At day 32, E is a member. At day 33, E becomes an authorised carrier.
These are four different facts. They should not be compressed into a single “migration completed” label.
Then test the unfinished work: S7 is still disputed, historical B records remain evidence, received copies have not automatically disappeared and the next-period budget is short by 30.
Assign an owner to each unresolved issue. Governance administrators handle authorised role changes. Dispute reviewers examine external evidence. The responsible members negotiate funding under their decision procedure. Data stewards evaluate the actual retention and access commitments.
One team may perform several tasks, but the tasks still need distinct evidence. A screenshot of E’s membership cannot close the budget gap or settle S7.
Back to contents · Next section
11. Exercises with explained answers
Exercise 1: Notice versus effect
B sends notice on day 20; removal is effective on day 30. Is B’s role already gone on day 21?
No. The supplied effective-state change occurs on day 30. Notice alone does not alter the model’s role state.
Exercise 2: A member without a carrier role
E joins on day 32 and receives the carrier role on day 33. Can E submit a carrier statement on day 32?
No. Membership and the application role are separate conditions.
Exercise 3: Historical evidence
Does B’s departure erase the fact that it was authorised when it submitted the accepted day-10 record?
No. Historical authority remains part of that record’s context. It still does not prove the physical delivery.
Exercise 4: The replacement witness
Can E confirm S7’s physical delivery solely because it replaced B?
No. Role succession does not supply knowledge of the earlier event.
Exercise 5: The unresolved budget
After B exits, three commitments of 30 remain against cost 120. What is the gap?
Thirty. Charging 40 each would close it mathematically, but agreement to that new allocation has not been supplied.
Exercise 6: Received documents
Does revoking B’s future access prove that B no longer has any previously received file?
No. Access termination and removal of existing copies are different claims.
Exercise 7: Conflicting reports
B’s recorded delivery statement conflicts with D’s non-receipt statement. Which is true?
The exercise does not establish that. The appropriate status is a dispute requiring relevant evidence, not an invented verdict.
Exercise 8: A later correction
An authorised review supports a correction. Must the earlier statement be treated as though it never existed?
No. The toy preserves a linked correction and the original historical statement, allowing readers to understand the sequence.
Back to contents · Next section
12. Frequently asked questions
Does a consortium chain eliminate trust between organisations?
No. It can make certain records and permissions explicit, but external assertions, governance choices and operating duties still require evidence and accountability.
Does every member have the same authority?
Not in this model, and membership alone cannot establish that in a real system. Application roles and administrative policies need examination.
Does a departed member automatically lose every copy?
No. A technical access change does not establish deletion of previously delivered information.
Can the ledger settle a physical dispute?
It can preserve relevant statements and evidence references. Whether the physical event occurred requires suitable evidence beyond the presence of a ledger entry.
Does the policy context approve this design for China?
No. The cited guidance supplies context. A real project’s obligations depend on its complete activities and current applicable rules.
Back to contents · Next section
13. Sources and further reading
Sources checked on 12 October 2026. All consortium facts, day numbers and budget amounts are fictional.
- MIIT/CAC blockchain development guidance: dated 27 May 2021, published 7 June 2021; shared-application context.
- Hyperledger Fabric membership documentation: release-2.5 documentation path; recognised identities, organisations and role scopes.
- Hyperledger Fabric policies: release-2.5 documentation path; explicit policy-based authority.
- Updating a Fabric channel configuration: release-2.5 documentation path; configuration changes as a defined process.
A durable collaboration plan explains what happens when cooperation changes. It follows permissions, evidence, records and costs separately enough that a member’s departure does not conceal the work still required.