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 Data Protection: Trace Every Copy Before Promising Deletion

—

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 BC089

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.

A blockchain application can remove a field from its current screen while earlier transaction data, event logs, node-held history and exported records still contain it. Before promising correction, deletion or limited access, trace the field through every place the application actually sends it. A database address, a contract address and a support team’s location describe different parts of that journey.

This lesson builds a small, entirely fictional service-record system. We follow one synthetic contact placeholder through three designs, test several proposed deletion actions and identify what each action can establish. The aim is a precise engineering description that a data-protection reviewer can assess. It is not a compliance certificate or a procedure for putting real personal information on a chain.

For a China audience, the distinction matters especially when people discuss blockchain persistence alongside personal-information duties and cross-border access. A technical label such as “private,” “hashed” or “encrypted” does not by itself settle those questions. Sources and their dates were checked on 12 October 2026.

Choose your reading route

In this guide

If you design application fields, read sections 1–4 and then the comparison in section 8. If you review a deletion promise, use the action trace in sections 5–7. If you assess support access, focus on section 9. The exercise and answers test whether you can keep current state, retained history, derived copies and legal conclusions separate.

Back to contents · Next section

1. Start with a field, not a platform slogan

Imagine a museum maintenance service that records whether equipment Q has completed a check. Its operational question is simple: what is the latest approved service status for Q? A technician’s contact detail might help an authorised coordinator arrange follow-up, but it need not be part of the shared status record.

Use these invented values throughout:

  • Equipment identifier: Q.
  • Service record: R7.
  • Technician label: T17.
  • Contact placeholder: CONTACT-A.
  • Initial status: checked.

CONTACT-A is a synthetic string, not anyone’s telephone number, email address or actual identity. We nevertheless model it as a field that a real design might use for contact information. Calling the exercise synthetic prevents disclosure; it does not prove a production version would contain no personal information.

The design question is whether every recipient needs this field to do its job. A replicated status service and a restricted contact directory can have different purposes, readers and retention arrangements. Combining them because one transaction is convenient creates a connection that later screens cannot necessarily undo.

Back to contents · Next section

2. Define the places before counting copies

Our first design, A, has six named components. They are logical components, not a claim that there are exactly six physical copies anywhere in the world.

C is current contract state. N1 and N2 are two node operators. Both retain the original transaction and its event log for the whole exercise; this is an explicit assumption, not a universal statement about every node’s storage policy. I is an indexer that reads those events and creates a searchable contact row. O is an offchain service file containing the same contact placeholder. Z is an overseas support team that can read I through an authorised support interface.

The interface sends CONTACT-A as transaction input. The fictional application writes it into C and emits it in an event. N1 and N2 retain the included transaction input and emitted log. I extracts the field into its row. O also contains it because the coordinator created that file separately.

There are now several representations and paths. C is a current value. The retained input and log describe an earlier execution. I is a derived record that can be rebuilt from that retained log. O is an independently maintained file. Z’s access is a read path; whether Z has also downloaded a copy is a separate fact we have not supplied.

A useful inventory records all of these distinctions. Merely writing “stored on blockchain” hides the relevant operations.

Back to contents · Next section

3. Why a language visibility modifier is insufficient

In Solidity’s documented execution setting, marking a state variable private limits access through the language’s contract interface; it does not make the underlying information secret from observers. The Solidity 0.8.30 security guidance explicitly warns about visibility of information used by contracts. This is a narrow technical point, not a claim that all permissioned networks expose everything to everyone. Solidity 0.8.30 security considerations

For design A, the leak in the design description is even easier to see: the field is deliberately included in both input and an event. Renaming the state variable private would not remove those other paths. Hiding the field in the portal would alter a presentation, not the transaction already retained by N1 and N2.

The event documentation describes event arguments being recorded in transaction logs. We use that mechanism to motivate the model, while explicitly supplying the retention assumptions rather than claiming that every possible historical record is always available forever. Solidity 0.8.30 events

Back to contents · Next section

4. Draw the field-flow record

A compact field-flow record for design A reads as follows:

  • Submission: CONTACT-A enters transaction input for R7.
  • Execution: C receives CONTACT-A and an event carries CONTACT-A.
  • Retention: N1 and N2 keep that input and event under the supplied policy.
  • Derivation: I creates a searchable row from the event.
  • Separate storage: O holds the coordinator’s service file.
  • Access: Z can view the row in I from overseas.

Now attach evidence questions to the arrows. Does the submitted payload actually include the raw field? Does the event schema include it? Which retention policy and node behaviour support the historical availability claim? What filter and transformation does I apply? What can Z see, and can the support interface export it?

These are different questions from whether the service status is correct. A flawlessly validated transaction can still contain a field that did not need to be shared. Consensus about an execution does not decide the appropriate audience for its input.

The record should also name what is unknown. We have not established browser caches, backups, screenshots or downloads. Their absence from this example is not evidence of their absence from a real system. A production inventory needs investigation rather than an optimistic empty box.

Back to contents · Next section

5. Test four proposed actions

Suppose the coordinator discovers CONTACT-A is obsolete. Evaluate each action independently against the original design A, unless a sequence is expressly stated.

Action D1 clears CONTACT-A from current state C through a valid new transaction. The latest C query no longer returns that field. However, our retained original transaction and event at N1 and N2 remain. I and O are unchanged. A sentence such as “the current contract field is cleared” fits the evidence; “every copy has been deleted” does not.

Action D2 removes I’s contact row. A query of that row now returns no entry. But the original event remains at the nodes, and the supplied indexer can rebuild the row from it. C and O are unchanged. This is a deletion in one derived store, not proof that the source has disappeared or that re-ingestion has been prevented.

Action D3 deletes the service file in O. That removes the specified file under the exercise’s stated successful deletion assumption. It changes neither C nor the retained input, log or I row. “Offchain deletion completed” is meaningful only when the sentence identifies which offchain store and which record.

Action D4 revokes Z’s future interface access. Z can no longer obtain new responses through that interface after the effective revocation. No supplied rule erases information Z already read or downloaded. We do not know whether such a download occurred, so the correct result is uncertainty about past copies, not an allegation that Z retained one.

Back to contents · Next section

6. Combine the actions without exaggerating the result

Apply D1, D2 and D3 successfully, then D4. Current state has no contact field, the specified indexer row is removed, the specified offchain file is deleted, and Z’s future interface access is revoked.

Yet N1 and N2 still retain the original transaction input and event under our assumptions. I could recreate the row if its ingestion process resumes unchanged. This conclusion requires no claim that blockchains are metaphysically indestructible. The limited facts of this particular system already defeat the universal deletion statement.

There is a second design task: prevent the application from treating an obsolete value as current. A corrected status or replacement pointer may help readers identify the authorised current record while preserving a trace of the earlier entry. That is a versioning solution to an accuracy problem. It does not establish removal of the old bytes.

A precise completion report therefore separates current display, current state, historical sources, derived stores, independent files and access rights. It also identifies any remaining unknown copies. Without those categories, a green “deleted” badge can combine several quite different outcomes.

Back to contents · Next section

7. Keep legal duties and engineering evidence connected

China’s Personal Information Protection Law was adopted on 20 August 2021 and took effect on 1 November 2021. It includes correction and deletion provisions in Articles 46–47. Article 47 also addresses specified retention or technical-deletion difficulties with restrictions on further processing; difficulty is not a general permission to continue ordinary use. The official republication checked here is dated 23 March 2026, which is not a new enactment date. Official PIPL text

This lesson does not decide whether a particular request triggers a duty, which records must be retained, or whether a particular technical response satisfies the law. Those conclusions need the actual facts and applicable rules. The engineering contribution is to stop a reviewer being told that clearing C necessarily removed every historical or derived representation.

The same law distinguishes de-identification from anonymisation. A substituted label, hash or encrypted field is not automatically an anonymity finding. PIPL definitions, Article 73

Back to contents · Next section

8. Compare two alternative designs

Design B changes the submission boundary. The shared application receives only an opaque record identifier, equipment status and a version reference. The raw contact field stays in O behind a separately reviewed access process. Crucially, the raw field is never submitted in transaction input, emitted in an event or copied into I by this design.

Under those supplied facts, deleting the raw contact record in O does not face an onchain raw-contact copy created by B. That is a useful improvement over A. It does not establish that every backup or export of O is gone, or that the remaining opaque identifier cannot be linked to a person through another record.

A team must test the actual payload, event schema and indexing rule. A front end that appears to submit only a reference could still include a raw field in an auxiliary argument. A statement about the intended screen is weaker than an inspected data path.

Design C puts an encrypted contact payload onchain. It changes who may read intelligible content under stated cryptographic and key-management assumptions, but the ciphertext still follows the replication and retention paths. Deleting one key copy does not prove that no other key copy or earlier plaintext export exists. Nor does the word encrypted settle a legal deletion or cross-border conclusion.

B and C therefore answer different design questions. B limits which raw data enters the replicated channel. C attempts to protect the intelligibility of data placed there. Both require careful assessment, and neither is a universal certificate of compliance.

Back to contents · Next section

9. Map overseas access as an edge

Return to Z. In design A, the servers for I may be located domestically, while Z reads the contact row from overseas. A storage-location diagram that omits readers would miss that path. Conversely, the presence of an overseas team does not prove it can read every field in O or every node’s records. Access scope needs evidence.

China’s CAC published the third edition of its data-export security-assessment application guide on 27 June 2025. Its announcement directs processors within applicable assessment circumstances to the relevant rules and guide. This lesson does not determine a transfer mechanism, exemption or filing requirement for our unspecified organisation. CAC third-edition announcement

For a useful review, record the field, recipient, access location, purpose, permissions and possible onward copies. Then have the actual activity assessed under the current applicable framework. Server geography alone cannot supply those facts, and blockchain terminology does not remove the need to establish them.

Back to contents · Next section

10. Exercise: mark the strongest supported statement

Use the original design A and its explicit retention assumptions.

  1. D1 succeeds. Can the coordinator say CONTACT-A is absent from current C? Can it say CONTACT-A is absent from all retained history?
  2. D2 succeeds, but the unchanged indexer replays the original event. Can the row return?
  3. D1, D2 and D3 all succeed. Which named components still retain the original input and event?
  4. D4 succeeds. Does that prove Z never downloaded the old row?
  5. Design B never submits the raw contact field to the chain or I. Does this remove the specific raw-contact replication path present in A?
  6. Design C’s team deletes one key copy. Is complete deletion of all intelligible copies established?
  7. I is hosted domestically and Z reads I from overseas. Should a field-flow review include that access edge?

Answers and reasoning

  1. Yes to the current C claim; no to the universal history claim. They concern different records.
  2. Yes, under the supplied replay rule. Removing a derived row did not remove its source or change ingestion.
  3. N1 and N2. The exercise deliberately preserves their historical records.
  4. No. Future access revocation supplies no evidence about whether a past download happened.
  5. Yes, for the specified raw field and supplied design facts. This is not proof that all remaining identifiers are anonymous or every offchain copy is controlled.
  6. No. Other keys and prior plaintext copies remain unexamined possibilities.
  7. Yes. It is a concrete access path for review, without predetermining its legal classification or permitted route.

Back to contents · Next section

11. A review note that an engineer can stand behind

A useful note names the exact field, schema version, transaction path, event path, current store, historical retention source, indexer rule and independent file. It states what each corrective action changed and how that change was checked. It records unresolved copies and identifies who must answer the applicable legal questions.

For design A, an honest note might say: current C was cleared; I’s row and the specified O file were removed; Z’s future interface access ended; N1 and N2 still retain the original input and event; re-ingestion behaviour requires a separate decision. That is much more useful than an unqualified promise that the information has vanished.

Before introducing a new field, repeat the exercise in the other direction: which recipients actually need it, which transformations occur, and which future obligations become harder after replication? Preventing an unnecessary raw field from entering a durable shared channel can be easier to demonstrate than trying to retract every resulting representation later.

Back to contents · Next section

Frequently asked questions

Does deleting contract state erase transaction input?

Not in our model. The nodes retain the earlier input independently of the current value. Actual historical availability depends on the network and storage arrangements being assessed.

Is a permissioned blockchain automatically private?

A membership rule identifies some access boundaries, but it does not by itself describe every participant’s copies, exports, support access or retention. Inspect the actual field paths.

Is a hash automatically anonymous?

No such conclusion follows merely from the label hash. The input, linkability, surrounding records and relevant legal definition need assessment. This lesson does not ask readers to hash real personal information.

Can a correction preserve history?

Yes, a model can designate a new current version while retaining an earlier one. That describes record behaviour; it does not independently resolve a deletion request.

Back to contents · Next section

Sources and further reading

Primary references checked on 12 October 2026:

For a wider introduction, read China’s personal-information and digital-trust context. For document-reading practice, use Reading a Cross-Border Data Transfer Assessment. Return here for the narrower blockchain task: locating each representation and testing exactly what a correction or deletion action changes.

Back to contents