8. Privacy, Identity and Confidential Computing

Introduction and Context

Blockchain systems were initially associated with transparent ledgers, public addresses, and digitally signed transactions. That combination supports auditability and resistance to unilateral alteration, but it also creates a fundamental privacy tension: information that is permanently replicated and publicly verifiable may be difficult to remove, conceal, or contextualize later. A blockchain address is not necessarily a person’s name, yet transactions linked to that address can reveal financial behaviour, organizational relationships, location patterns, and operational routines.

Privacy in blockchain systems is therefore not achieved simply by hiding a real-world name. It requires analysis of the information exposed by transactions, smart contracts, network communication, identity credentials, metadata, and the interaction between on-chain and off-chain systems. At the same time, excessive confidentiality can undermine regulatory reporting, fraud investigation, governance, and accountability.

This chapter examines the principal technologies used to balance these competing objectives. It considers pseudonymity and transaction tracing, decentralized identity and verifiable credentials, zero-knowledge proofs, multiparty computation, trusted execution environments, and privacy-enhancing architectures. The discussion is directed toward security professionals who must evaluate not only whether a technique protects data, but also what it reveals, whom it empowers, how it can be audited, and whether it satisfies legal and organizational requirements.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish anonymity, pseudonymity, confidentiality, unlinkability, and privacy.

2. Explain how blockchain transactions can be traced and de-anonymized.

3. Evaluate decentralized identity and verifiable credential architectures.

4. Describe the operation and limitations of zero-knowledge proofs.

5. Compare multiparty computation, trusted execution environments, and other confidential-computing approaches.

6. Select privacy-enhancing technologies according to trust, performance, auditability, and compliance requirements.

7. Analyse the ethical, governance, and regulatory implications of privacy-preserving blockchain systems.

From Pseudonymous Addresses to Observable Behaviour

A public blockchain commonly records an address, a transaction amount or state change, a timestamp, and references to other addresses or contracts. The address is usually a cryptographic identifier rather than a civil identity. This is pseudonymity: activity is associated with an identifier, but the identifier is not inherently the person’s legal name. Pseudonymity differs from anonymity because activity may still be linked to the same identifier, and the identifier may eventually be connected with a person or organization.

Several distinctions are important:

• Anonymity means that an action cannot reasonably be linked to a specific individual.
• Pseudonymity replaces an identity with a persistent identifier.
• Confidentiality limits access to information to authorized parties.
• Unlinkability makes it difficult to determine that two actions belong to the same entity.
• Untraceability makes it difficult to reconstruct the origin, destination, or path of an activity.
• Integrity provides assurance that data has not been improperly altered.

A blockchain may provide strong integrity while providing weak confidentiality. In fact, its transparency can assist investigation. Analysts can construct transaction graphs in which addresses are vertices and transfers are edges. Clustering heuristics may infer that several addresses are controlled by one entity, particularly when they are used together in a transaction or funded from a common source. Exchange records, merchant databases, sanctions lists, IP logs, and publicly available information can then connect blockchain activity to real-world identities.

Transaction tracing typically combines graph analysis, temporal analysis, attribution data, and behavioural inference. A tracing system may examine repeated payment amounts, transaction timing, common counterparties, asset bridges, exchange deposits, smart-contract interactions, and movement through mixers or privacy protocols. Machine-learning techniques can rank suspicious patterns, but their conclusions are probabilistic and can produce false positives. A blockchain record proves that a transaction was recorded; it does not by itself prove who controlled every address involved.

Privacy risks also arise from metadata. Even where transaction values are encrypted, timing, frequency, network location, gas-payment patterns, contract calls, and validator or node observations may reveal information. A system that protects the ledger but exposes the peer-to-peer network can still leak valuable behavioural evidence.

Decentralized Identity and Verifiable Credentials

Traditional digital identity systems often depend on centralized identity providers. A provider registers a user, stores identity attributes, authenticates the user, and enables relying parties to request information. This can simplify administration but creates concentration of data, a single attractive target, and a risk that users disclose more information than necessary.

Decentralized identity (DID) models seek to give individuals or organizations greater control over identifiers, credentials, and consent. A decentralized identifier is a globally unique identifier whose control and verification method are described through a DID document or equivalent mechanism. Depending on the design, the document may be recorded on a blockchain, stored through a decentralized network, or resolved using another distributed method. The blockchain is not necessarily the identity database; it may provide a tamper-evident registry for keys, service endpoints, or status information.

A verifiable credential is a digitally signed statement issued by one party about a subject. Examples include a professional qualification, proof of age, organizational authorization, or membership status. The principal roles are:

1. Issuer, which creates and signs the credential.

2. Holder, which stores and presents the credential.

3. Verifier, which checks authenticity, validity, and relevant claims.

A credential may be presented directly, or the holder may generate a selective disclosure presentation. Instead of revealing a complete identity record, the holder could prove only that an age threshold is satisfied or that a person possesses a valid professional licence. This principle of data minimization is central to privacy-preserving identity.

A robust identity architecture must address key rotation, recovery, revocation, expiration, status checking, issuer trust, device loss, and the possibility of coercion. Immutability is not sufficient: an identity system must support correction and withdrawal of credentials without creating a permanent public record of sensitive personal data. For this reason, personal data should generally remain off-chain, while the ledger stores hashes, references, public keys, or revocation information. Even a hash may be personal data if it can be linked to an identifiable individual or used as a stable tracking identifier.

Zero-Knowledge Proofs: Proving Without Revealing

A zero-knowledge proof (ZKP) enables one party, the prover, to convince another party, the verifier, that a statement is true without revealing the underlying secret. A sound system should satisfy three conceptual properties:

• Completeness: an honest prover can convince the verifier when the statement is true.
• Soundness: a dishonest prover cannot convincingly establish a false statement except with negligible probability.
• Zero knowledge: the verifier learns no material information beyond the truth of the statement.

In blockchain applications, a prover may demonstrate that a transaction satisfies validity conditions without exposing the transaction’s inputs, outputs, or private business data. A proof can also establish that a user possesses a credential, that a balance is sufficient, that a computation was performed correctly, or that a dataset satisfies a policy.

ZK systems are often described as interactive or non-interactive. Modern blockchain applications commonly use non-interactive proofs, in which the prover produces a proof that can be checked without a live exchange. Different constructions make different trade-offs in proof size, verification time, prover cost, setup assumptions, and post-quantum considerations. Some systems require a trusted setup; others use transparent techniques. A trusted setup is not necessarily unacceptable, but its generation ceremony and failure assumptions must be understood.

Zero knowledge does not mean that every element of a system is private. Proof inputs may leak through transaction timing, public keys, repeated identifiers, application interfaces, or poorly designed circuits. The circuit or constraint system must encode the intended statement precisely. If a proof verifies only that a document was signed, it does not establish that the issuer was trustworthy, that the document remains current, or that the subject gave informed consent.

Multiparty Computation and Confidential Collaboration

Secure multiparty computation (MPC) allows several parties to compute a function over their combined inputs without revealing those inputs to one another. Each participant holds a share of a secret or private input. Protocols transform the inputs into messages or shares so that the agreed result can be calculated while individual values remain concealed.

An example is joint fraud analysis by several financial institutions. Each institution may wish to identify overlapping suspicious entities without disclosing its entire customer database. An MPC protocol can compute an intersection or risk score under defined conditions. In blockchain environments, MPC is also used for distributed key generation and threshold signing. Rather than placing a complete private key with one operator, several parties jointly authorize a transaction, reducing dependence on a single key custodian.

MPC requires careful consideration of the threat model. Some protocols tolerate a limited number of malicious participants; others assume participants follow the protocol but try to infer information. Communication complexity, participant availability, synchronization, and computational overhead can be significant. Output privacy also matters: a party may infer private inputs from repeated queries or overly detailed results. Rate limits, query governance, and minimum group sizes may therefore be necessary.

Confidential Computing and Trusted Execution Environments

Confidential computing protects data while it is being processed, rather than only while stored or transmitted. A trusted execution environment (TEE) is an isolated hardware-backed area in which code and data are protected from parts of the host operating system, hypervisor, or cloud administrator. Remote attestation allows a remote party to verify that a particular approved program is running in an expected environment before releasing sensitive data.

A blockchain application might use a TEE to match private records, execute a confidential smart-contract function, or manage an oracle computation. The blockchain supplies consensus, ordering, and auditability, while the TEE performs computation on data that should not be publicly replicated. The result, an attestation, or a cryptographic commitment can be recorded on-chain.

TEEs introduce a different trust model from ZK proofs and MPC. Security depends partly on hardware design, firmware, vendor update processes, side-channel resistance, and the correctness of attestation. Historical hardware vulnerabilities demonstrate that isolation claims require continuous assessment. A TEE may also be vulnerable to rollback, malicious code updates, denial of service, or leakage through memory access patterns. Consequently, confidential computing should not be treated as a universal replacement for cryptography; it is a mechanism with particular operational assumptions.

Privacy-Enhancing Blockchain Architectures

Privacy is usually achieved through architecture rather than one isolated feature. A practical design may combine several layers:

1. Data minimization: store only what must be replicated and retained.

2. Off-chain storage: keep personal or commercially sensitive data in controlled systems, recording only commitments or references on-chain.

3. Selective disclosure: issue credentials that support disclosure of individual attributes rather than complete identity profiles.

4. Confidential transactions: use encryption, commitments, range proofs, or privacy-preserving transaction protocols where transaction content must be hidden.

5. Confidential computation: apply MPC or TEEs when several parties must compute over private data.

6. Network privacy: reduce exposure of IP addresses and communication metadata through suitable relay or routing mechanisms.

7. Access governance: define who may request, verify, revoke, or correlate information.

8. Auditable compliance: provide controlled disclosure, lawful access procedures, and evidence of policy enforcement.

Public, permissioned, and hybrid ledgers create different privacy conditions. A public chain maximizes independent verification but exposes replicated data and metadata to a broad audience. A permissioned network restricts participation and may support confidential channels, but the operators become important trust and governance points. A hybrid architecture can place commitments and proofs on a public chain while retaining underlying records within regulated organizations.

A useful decision framework asks five questions: What must be hidden? From whom? For how long? Who must be able to verify the result? What evidence must be retained for audit or legal investigation? The answers determine whether encryption, ZKPs, MPC, a TEE, access control, or a combination is appropriate.

Applied Case: Privacy-Preserving Professional Licensing

Background

Consider an illustrative case involving a national engineering regulator, universities, employers, and licensed engineers. The regulator wants employers to verify that applicants hold a current licence. Engineers, however, do not want every employer, service provider, or blockchain observer to see their full identity history, date of birth, examination results, or employment record.

Situation and Problem

The existing system uses a centralized portal. Employers upload identity documents and receive a yes-or-no response from the regulator. The portal contains valuable personal data, has limited interoperability, and encourages organizations to retain copies of documents. The regulator seeks stronger auditability without creating a permanent public register of personal information.

Analysis

The relevant privacy objectives are data minimization, issuer authenticity, credential integrity, revocation, and selective disclosure. The employer needs proof of current authorization, not the engineer’s complete file. A public blockchain record of names and licence numbers would improve visibility but would create unnecessary correlation and retention risks.

Approach

The regulator issues a verifiable credential to each engineer. The credential contains an identifier, licence category, validity period, and issuer signature. The engineer stores it in a digital wallet. When applying for a role, the engineer presents a proof that the credential was issued by the regulator, has not expired or been revoked, and authorizes practice in the relevant category. A zero-knowledge presentation reveals only the necessary attributes. The ledger records issuer key information and credential-status commitments, while personal records remain in the regulator’s systems.

For high-risk appointments, the employer may request a regulated disclosure process. Such disclosure is governed by policy and legal authority rather than by unrestricted public ledger visibility. The regulator also designs key recovery, credential suspension, and correction procedures.

Outcome

Employers receive cryptographically verifiable evidence without routinely collecting complete identity files. The regulator retains authority over issuance and revocation, while the engineer controls presentation. The system does not eliminate trust: employers must still trust the regulator, wallets must protect keys, and the status service must remain available. It does, however, reduce unnecessary disclosure and central storage.

Learning Points

The case illustrates that decentralized identity is not equivalent to putting identity data on a blockchain. Privacy results from minimizing data, separating verification from disclosure, defining governance, and designing recovery and revocation mechanisms. It also shows that cryptographic proof cannot resolve questions of institutional legitimacy or legal authority.

Risks, Limitations, and Common Design Errors

Privacy technologies can fail through implementation, governance, or inference. Common errors include placing names, identity documents, or detailed business records directly on an immutable ledger; treating a hash as automatically anonymous; reusing a single address or credential identifier across contexts; omitting revocation; and assuming that encryption prevents metadata analysis.

A second error is confusing technical validity with social trust. A valid signature proves control of a key, not that the key holder is honest or that the underlying claim is true. Similarly, a valid ZKP proves the statement encoded by the circuit, not every surrounding assumption. Poorly specified circuits, compromised issuer keys, malicious wallet software, and insecure recovery processes remain serious threats.

Performance is another limitation. Proof generation, MPC communication, confidential execution, and status checking may create latency and operational cost. Privacy mechanisms can also complicate incident response. A security team may be unable to inspect transaction content directly and must instead rely on carefully governed evidence requests, aggregate signals, or selective disclosure.

Anonymity can facilitate legitimate activities such as personal safety and political participation, but it can also support fraud, sanctions evasion, extortion, or abuse. Privacy architecture must therefore be assessed against proportionality, due process, and misuse risk rather than marketed as absolute secrecy.

Governance, Compliance, and Professional Responsibility

Organizations should define a data-governance model before deploying privacy-enhancing technology. It should identify data controllers and processors, retention periods, lawful purposes, access rights, incident obligations, and procedures for correction or deletion where applicable. Immutability may conflict with legal requirements concerning rectification or erasure; off-chain storage, revocable references, encryption-key destruction, and minimal on-chain commitments can reduce that conflict, although no technique guarantees legal compliance in every jurisdiction.

Compliance should be designed as a controlled-disclosure capability. A regulated entity may need to demonstrate transaction provenance, verify a customer, respond to lawful requests, or investigate fraud. Selective disclosure and ZKPs can reduce routine exposure while preserving targeted evidentiary access. Governance should specify who can initiate disclosure, what threshold of authorization is required, how requests are logged, and how affected individuals are notified where legally permitted.

Professional responsibility includes assessing unequal effects. A privacy wallet that requires advanced hardware may exclude vulnerable users. A failed identity-recovery mechanism can cause permanent loss of access. Automated risk scoring based on transaction graphs may discriminate against legitimate users whose financial patterns resemble suspicious activity. Human review, appeal mechanisms, explainability, and independent audit are therefore necessary.

Emerging Directions and Best Practices

Current development is moving toward interoperable verifiable credentials, more efficient zero-knowledge systems, privacy-preserving rollups, threshold custody, confidential decentralized finance, and confidential data-sharing networks. Advances in proof systems may reduce verification cost, while standardized credential formats may improve portability. At the same time, post-quantum migration, hardware assurance, cross-chain correlation, and wallet security remain important research and engineering concerns.

A sound professional practice is to:

• perform a privacy threat model before choosing a protocol;
• classify data and identify the minimum necessary disclosure;
• separate identity, transaction, and analytics layers where possible;
• avoid putting personal data directly on an immutable ledger;
• use independent audits for cryptographic circuits, smart contracts, wallets, and attestation logic;
• design revocation, recovery, key rotation, and incident response from the beginning;
• test linkage and metadata leakage, not merely encryption strength;
• document trust assumptions for issuers, validators, hardware vendors, and administrators;
• provide proportionate, accountable procedures for lawful disclosure; and
• monitor performance, usability, false positives, and unintended exclusion after deployment.

Chapter Summary

Blockchain transparency provides integrity and auditability but does not provide confidentiality. Public addresses are generally pseudonymous, and transaction graphs, metadata, external records, and behavioural patterns can support tracing and de-anonymization. Decentralized identity and verifiable credentials can return control of presentation to users and support selective disclosure, but they still require trusted issuers, secure wallets, recovery, and revocation.

Zero-knowledge proofs establish statements without revealing their underlying secrets, while MPC enables joint computation without exposing individual inputs. Trusted execution environments protect data during processing through hardware-backed isolation and remote attestation, but introduce hardware and vendor trust assumptions. Effective privacy-enhancing architecture combines data minimization, off-chain storage, commitments, selective disclosure, confidential computation, network protections, and accountable governance.

The central design challenge is balance. Privacy must be strong enough to prevent unnecessary surveillance and disclosure, yet the system must retain proportionate mechanisms for verification, audit, fraud prevention, and lawful investigation. Technical guarantees, institutional trust, usability, and regulation must therefore be evaluated together.

Key Terms

Pseudonymity: Use of a persistent identifier that is not inherently a real-world name.

Anonymity: Condition in which activity cannot reasonably be linked to a specific individual.

Confidentiality: Protection of information from unauthorized access or disclosure.

Unlinkability: Difficulty of determining that separate actions belong to the same entity.

Transaction graph: Representation of addresses and transfers as vertices and edges for analysis.

Decentralized identity: Identity model in which identifiers and credentials can be controlled and presented without dependence on one central identity repository.

Decentralized identifier: A uniquely resolvable identifier associated with control and verification information.

Verifiable credential: Digitally signed claim issued by one party about a subject.

Selective disclosure: Presentation of only the attributes necessary for a particular purpose.

Zero-knowledge proof: Cryptographic proof of a statement that reveals no unnecessary information about the secret underlying it.

Completeness: Property that an honest prover can establish a true statement.

Soundness: Property that a false statement cannot be successfully established except with negligible probability.

Multiparty computation: Protocol allowing parties to compute jointly over private inputs without revealing those inputs.

Threshold signing: Authorization method requiring a specified number of participants or shares to sign.

Trusted execution environment: Hardware-isolated environment intended to protect code and data during execution.

Remote attestation: Evidence allowing a party to verify the software and state of a remote execution environment.

Data minimization: Collection, processing, and disclosure of no more data than is necessary.

Selective auditability: Capability to provide authorized evidence without exposing all underlying information publicly.

Privacy-enhancing technology: Technical mechanism designed to reduce unnecessary collection, disclosure, or linkage of information.

Review Questions

Short Answer Questions

1. Why is a blockchain address generally pseudonymous rather than anonymous?

2. Define unlinkability and explain its importance in transaction privacy.

3. What are the roles of issuer, holder, and verifier in a verifiable credential system?

4. State the completeness, soundness, and zero-knowledge properties of a ZKP.

5. Why is remote attestation relevant to confidential computing?

Long Answer Questions

1. Explain how transaction tracing combines blockchain data with external information to identify users.

2. Compare decentralized identity with a centralized identity portal, including privacy and governance implications.

3. Describe the operation, uses, and limitations of zero-knowledge proofs in blockchain systems.

4. Compare MPC and TEEs as methods for confidential computation.

5. Discuss how a hybrid blockchain architecture can balance auditability, confidentiality, and regulatory disclosure.

Analytical / Application Questions

1. A financial consortium wants to detect common fraudulent entities without sharing customer databases. Which privacy technologies and governance controls would you recommend, and why?

2. An organization proposes storing employees’ names and professional certificates directly on a public blockchain. Analyse the privacy, compliance, and operational risks and design a safer alternative.

3. A privacy-preserving payment system hides transaction values but uses a permanent public address for each customer. Evaluate what information may still be inferred and propose design improvements.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes pseudonymity from anonymity in a blockchain system?

A. Pseudonymity prevents all transaction tracing

B. Pseudonymity uses an identifier that may later be linked to a real identity

C. Anonymity requires every transaction to be publicly visible

D. Pseudonymity means that transaction data is encrypted

Correct Answer: B. Pseudonymity uses an identifier that may later be linked to a real identity

Question 2

Which combination most directly supports transaction de-anonymization?

A. Only block timestamps, without any external data

B. Transaction graphs, exchange records, and behavioural patterns

C. Private keys stored in hardware wallets

D. A credential’s expiration date alone

Correct Answer: B. Transaction graphs, exchange records, and behavioural patterns

Question 3

In a verifiable credential architecture, what is the holder primarily responsible for?

A. Issuing the regulator’s signature

B. Consensus validation for the blockchain

C. Storing and presenting credentials when required

D. Rewriting revoked credentials on the ledger

Correct Answer: C. Storing and presenting credentials when required

Question 4

What does a zero-knowledge proof allow a prover to do?

A. Reveal all private inputs to an auditor

B. Prove a statement without revealing the underlying secret unnecessarily

C. Guarantee that the issuer of a claim is honest

D. Prevent all metadata leakage

Correct Answer: B. Prove a statement without revealing the underlying secret unnecessarily

Question 5

A consortium wants to compute a shared fraud score without revealing each institution’s customer records. Which technology is most directly suited to this requirement?

A. Secure multiparty computation

B. Public key publication

C. A conventional transparent database

D. A single permanent blockchain address

Correct Answer: A. Secure multiparty computation

Question 6

What is a major trust assumption introduced by a trusted execution environment?

A. That no participant needs authentication

B. That hardware, firmware, and attestation mechanisms remain trustworthy

C. That all computation becomes publicly verifiable

D. That encryption keys never require rotation

Correct Answer: B. That hardware, firmware, and attestation mechanisms remain trustworthy

Question 7

Which architecture best follows data-minimization principles for professional licensing?

A. Publishing names, birth dates, and licence records on a public chain

B. Storing complete identity files in every verifier’s database

C. Using a credential and proving only current authorization when needed

D. Using one reusable address for every professional activity

Correct Answer: C. Using a credential and proving only current authorization when needed

Question 8

Why may a hash placed on a blockchain still create a privacy concern?

A. Hashes always reveal the original plaintext immediately

B. A hash may remain linkable to an identifiable person or stable record

C. Hashes cannot support integrity verification

D. A hash automatically grants editing rights

Correct Answer: B. A hash may remain linkable to an identifiable person or stable record

Question 9

Which statement about a valid zero-knowledge proof is most accurate?

A. It proves every fact surrounding the transaction

B. It proves only the statement encoded by the relevant circuit or protocol

C. It eliminates the need to trust credential issuers

D. It guarantees protection against all side-channel attacks

Correct Answer: B. It proves only the statement encoded by the relevant circuit or protocol

Question 10

A privacy system hides transaction amounts but reuses one public address for every user activity. What is the principal weakness?

A. The address may enable activity correlation despite hidden amounts

B. The system cannot provide transaction integrity

C. The system necessarily requires a trusted setup

D. The system prevents all lawful auditing

Correct Answer: A. The address may enable activity correlation despite hidden amounts