Skip to content

Emerging Trust Technologies

Summary

This chapter looks beyond blockchain to the next generation of trust technologies. Students will examine zero-knowledge proofs, verifiable credentials, decentralized identifiers, and self-sovereign identity as alternatives or complements to blockchain. The chapter also covers regulatory considerations including GDPR compliance, data sovereignty, and the right to be forgotten — challenges that blockchain's immutability makes particularly difficult to address.

Concepts Covered

This chapter covers the following 11 concepts from the learning graph:

  1. Zero-Knowledge Proof
  2. Verifiable Credential
  3. Decentralized Identifier
  4. Self-Sovereign Identity
  5. Post-Blockchain Tech
  6. Emerging Trust Tech
  7. Regulatory Compliance
  8. Data Sovereignty
  9. GDPR and Blockchain
  10. Right to Be Forgotten
  11. Technology Readiness Level

Prerequisites

This chapter builds on concepts from:

Rex Says: Trust, but Verify!

Rex welcomes you Welcome, fellow analysts! Blockchain dominates the trust technology conversation, but it is not the only game in town — and in many cases, it is not even the best one. This chapter explores emerging technologies that solve trust problems with fundamentally different architectural approaches. Some complement blockchain; others may replace it entirely. Trust, but verify — especially when new technologies make extraordinary claims!

Learning Objectives

After completing this chapter, you will be able to:

  • Explain how zero-knowledge proofs enable verification without disclosure and assess their practical maturity for enterprise applications
  • Describe the architecture of verifiable credentials and decentralized identifiers, and evaluate their advantages over centralized identity systems
  • Assess self-sovereign identity as an alternative to both centralized identity management and blockchain-based identity
  • Evaluate emerging trust technologies using the Technology Readiness Level framework to distinguish production-ready solutions from research prototypes
  • Analyze the regulatory challenges that GDPR, data sovereignty requirements, and the right to be forgotten pose for immutable ledger architectures
  • Identify post-blockchain technologies that may address trust problems more efficiently than current distributed ledger approaches

The Landscape of Emerging Trust Technologies

Emerging trust technologies are systems and protocols that establish trust between parties using mechanisms beyond traditional centralized authorities or blockchain-based distributed ledgers. While blockchain has captured the majority of public attention since 2015, cryptographers and distributed systems researchers have been developing alternative approaches that address some of blockchain's fundamental limitations — particularly its computational overhead, privacy constraints, and regulatory conflicts.

The trust technology landscape can be organized into three categories:

  • Cryptographic primitives — mathematical techniques (such as zero-knowledge proofs) that enable new forms of trust verification at the protocol level
  • Identity frameworks — architectural standards (such as verifiable credentials and decentralized identifiers) that restructure how identity and claims are managed
  • Post-blockchain architectures — distributed systems that achieve trust properties similar to blockchain without using blockchain's specific consensus and data structure mechanisms
Technology Primary Trust Problem Solved Maturity Blockchain Relationship
Zero-knowledge proofs Verification without disclosure Production (ZK-rollups) Complement (Layer 2 scaling, privacy)
Verifiable credentials Portable, tamper-evident claims Standards-stage (W3C) Independent (works with or without blockchain)
Decentralized identifiers Self-controlled identity anchors Standards-stage (W3C) Optional (can use blockchain or other registries)
Self-sovereign identity User-controlled identity Pilot stage Can use blockchain; does not require it
DAG-based ledgers High-throughput distributed trust Production (limited) Alternative architecture
Trusted execution environments Hardware-enforced computation integrity Production Complement

Understanding these technologies is essential for the evidence-based evaluator because many blockchain proposals can be better served by one of these alternatives — either as a replacement or as a complementary technology that addresses blockchain's specific weaknesses.

Zero-Knowledge Proofs

A zero-knowledge proof (ZKP) is a cryptographic protocol that allows one party (the prover) to convince another party (the verifier) that a statement is true without revealing any information beyond the truth of the statement itself. The concept was introduced by Goldwasser, Micali, and Rackoff in 1985 and has evolved from theoretical curiosity to production technology.

The intuitive example: imagine you want to prove you are over 21 years old to enter a venue, without revealing your actual birthdate, name, or any other information on your ID. A zero-knowledge proof would allow you to demonstrate the truth of the statement "I am over 21" while disclosing nothing else.

Formally, a zero-knowledge proof must satisfy three properties:

  • Completeness — if the statement is true, an honest prover can always convince the verifier
  • Soundness — if the statement is false, no cheating prover can convince the verifier (except with negligible probability)
  • Zero-knowledge — the verifier learns nothing beyond the truth of the statement

The mathematics underlying ZKPs is complex, but the practical implications are profound. ZKPs enable a form of trust that blockchain alone cannot provide: verification without disclosure. Blockchain provides transparency through shared visibility — everyone can see the data. ZKPs provide trust through mathematical proof — you can verify a claim without seeing the underlying data.

Key Insight

Rex is thinking Blockchain and zero-knowledge proofs solve trust in opposite ways. Blockchain says "trust through transparency — everyone can see the data." Zero-knowledge proofs say "trust through mathematics — you can verify without seeing." For applications involving sensitive data, ZKPs may be the more appropriate trust mechanism.

ZKP Variants in Practice

Two ZKP constructions dominate current production use:

ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) produce small, fast-to-verify proofs but require a trusted setup ceremony — a one-time process that generates public parameters. If the setup ceremony is compromised, the entire system's security is invalidated.

ZK-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) eliminate the trusted setup requirement and are resistant to quantum computing attacks, but produce larger proofs that are more expensive to verify.

Property ZK-SNARKs ZK-STARKs
Proof size Small (~200 bytes) Larger (~50-100 KB)
Verification time Fast (~10 ms) Moderate (~50-100 ms)
Trusted setup required Yes No
Quantum resistant No Yes
Prover computation High Higher
Production examples Zcash, Polygon zkEVM StarkNet, StarkEx

ZKPs in Production

The most mature production application of ZKPs is in blockchain scaling through ZK-rollups — Layer 2 systems that execute transactions off-chain and submit a zero-knowledge proof to the main chain proving that all transactions were executed correctly. This allows thousands of transactions to be verified by checking a single proof, dramatically improving throughput.

Beyond blockchain scaling, ZKPs are being applied to:

  • Private transactions — Zcash uses ZK-SNARKs to enable cryptocurrency transactions where the sender, receiver, and amount are all hidden while the network still verifies that no double-spending has occurred
  • Identity verification — proving attributes (age, citizenship, credit score range) without revealing the underlying data
  • Supply chain privacy — proving that a product meets certain standards without revealing proprietary manufacturing details
  • Regulatory compliance — proving compliance with rules (e.g., sufficient reserves) without revealing exact financial positions

The evidence-based evaluator should note that while ZKP technology has reached production maturity for specific applications (particularly ZK-rollups), many proposed ZKP use cases remain at the pilot or research stage. The computational cost of generating proofs remains significant, and the developer tooling is still maturing.

Verifiable Credentials

A verifiable credential (VC) is a tamper-evident digital claim made by an issuer about a subject, structured according to the W3C Verifiable Credentials Data Model standard. Verifiable credentials bring the concept of physical credentials — a driver's license, a university diploma, a professional certification — into the digital world with cryptographic guarantees.

The verifiable credential ecosystem involves three roles:

  • Issuer — the entity that creates and signs the credential (a university issuing a degree, a government issuing a license)
  • Holder — the entity that receives and stores the credential (the graduate, the licensed professional)
  • Verifier — the entity that checks the credential's validity (an employer, a regulatory body)

The critical architectural innovation of verifiable credentials is that verification does not require contacting the issuer. The holder presents the credential to the verifier, who can cryptographically verify its authenticity using the issuer's public key — without the issuer knowing when, where, or to whom the credential was presented.

This architecture provides three advantages over centralized credential verification:

  • Privacy — the issuer does not learn when or where credentials are used
  • Availability — verification works even if the issuer's systems are offline
  • User control — holders choose which credentials to present and to whom
1
2
3
4
5
6
7
Traditional Verification:        Verifiable Credential:

Employer → University            Employer ← Graduate
   "Did Jane graduate?"            "Here is my signed credential"
University → Employer             Employer verifies signature
   "Yes, in 2020"                  using university's public key
                                   (No contact with university needed)

The W3C Verifiable Credentials Data Model (version 2.0, published 2024) standardizes the credential format, making credentials interoperable across different technology platforms. A credential issued using one VC-compatible system can be verified by any other compliant system.

Decentralized Identifiers

A decentralized identifier (DID) is a globally unique identifier that the subject creates and controls, without requiring registration with a centralized authority. DIDs are defined by the W3C DID Core specification (version 1.0, published 2022) and form the identity layer that supports verifiable credentials.

Traditional digital identifiers — email addresses, social media handles, domain names — are controlled by the organizations that issue them. Google controls your Gmail address. Twitter controls your handle. ICANN and registrars control your domain name. If any of these organizations suspends your account, you lose your identifier and everything associated with it.

A DID inverts this relationship. The identifier is cryptographically generated by the subject and anchored to a verifiable data registry (which may or may not be a blockchain). The subject holds the private key associated with the DID and can prove control of it at any time.

A DID has the format: did:method:specific-identifier

For example: did:web:example.com:user:alice or did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

The "method" component specifies which system anchors the DID. Over 150 DID methods have been registered, including:

  • did:web — anchored to a web domain (centralized, but simple)
  • did:key — self-contained in a cryptographic key (no external anchoring)
  • did:ion — anchored to the Bitcoin blockchain
  • did:ethr — anchored to the Ethereum blockchain
  • did:peer — established directly between two parties with no external registry
DID Method Anchoring Decentralization Practical Maturity
did:web Web server Low (server operator controls) High (easy to implement)
did:key None (self-certifying) Maximum (no dependency) High (simple, no infrastructure)
did:ion Bitcoin blockchain High Medium (depends on Bitcoin network)
did:ethr Ethereum blockchain High Medium (depends on Ethereum)
did:peer Peer-to-peer exchange High (for bilateral relationships) Medium

Rex's Tip

Rex shares a tip DIDs do not require blockchain. The did:web and did:key methods work without any distributed ledger. When evaluating identity solutions, do not assume that "decentralized identity" means "blockchain-based identity." The decentralization refers to who controls the identifier — the subject, not an authority — not necessarily to the underlying infrastructure.

Self-Sovereign Identity

Self-sovereign identity (SSI) is an identity management paradigm in which individuals own and control their digital identity without relying on any centralized authority. SSI combines decentralized identifiers, verifiable credentials, and secure digital wallets into a comprehensive alternative to both centralized identity systems (government databases, corporate directories) and federated identity systems (OAuth, SAML).

The principles of self-sovereign identity, as articulated by Christopher Allen in 2016, include:

  • Existence — users must have an independent existence; their digital identity represents a real entity
  • Control — users must control their identities; they are the ultimate authority on their identity data
  • Access — users must have access to their own identity data at all times
  • Transparency — the systems and algorithms governing identity management must be transparent
  • Persistence — identities must be long-lived, preferably permanent
  • Portability — identity information must be transportable; it cannot be locked into a single provider
  • Consent — users must consent to the use of their identity data
  • Minimization — disclosure of identity data must be minimized; only what is necessary should be shared
  • Protection — the rights of users must be protected even in the face of power asymmetries

SSI addresses a genuine problem: in the current digital identity landscape, individuals have limited control over their identity data. Companies collect, store, and monetize personal data, often without meaningful consent. Data breaches expose millions of records annually. Identity verification processes are fragmented and repetitive — you prove your identity to every new service provider from scratch.

However, the evidence-based evaluator must ask hard questions about SSI's practical viability:

  • Key management — if a user loses their private key, they lose their identity. No centralized authority can recover it. Is this acceptable for mainstream adoption?
  • Revocation — if a credential must be revoked (a license suspended, a degree invalidated), how is revocation communicated without centralized revocation lists?
  • Legal recognition — do SSI-issued credentials have legal standing equivalent to government-issued identity documents?
  • Adoption incentives — why would organizations that profit from controlling user identity data voluntarily adopt a system that gives that control to users?

SSI implementations are currently at the pilot stage in most jurisdictions. The European Union's eIDAS 2.0 regulation (adopted 2024) mandates that EU member states offer digital identity wallets to citizens by 2026, which may accelerate SSI adoption — though the EU implementation is a government-issued wallet, which arguably contradicts the "self-sovereign" principle by maintaining government as the identity authority.

Post-Blockchain Trust Technologies

Post-blockchain technologies are distributed systems that achieve some or all of blockchain's trust properties — immutability, transparency, distributed verification — using fundamentally different architectural approaches. These technologies merit attention because they may address blockchain's limitations (throughput, energy consumption, finality time) more effectively than blockchain itself.

Directed Acyclic Graphs (DAGs)

DAG-based ledgers, such as IOTA's Tangle and Hedera Hashgraph, replace blockchain's linear chain of blocks with a graph structure where each transaction directly references and validates previous transactions. This architecture allows multiple transactions to be processed in parallel, potentially achieving higher throughput than sequential block-based systems.

  • IOTA's Tangle: designed for IoT microtransactions; no mining or transaction fees; throughput scales with network activity. However, IOTA has struggled with security (the original coordinator node was a centralized bottleneck) and has undergone multiple architectural revisions.
  • Hedera Hashgraph: uses a patented gossip-about-gossip protocol and virtual voting for consensus; claims 10,000+ TPS. However, it is governed by a council of large corporations, which raises centralization concerns.

Trusted Execution Environments (TEEs)

TEEs, such as Intel SGX and ARM TrustZone, provide hardware-enforced isolated execution environments where code runs in a secure enclave that even the host operating system cannot access or modify. TEEs enable a different trust model: instead of trusting a distributed network, you trust the hardware manufacturer's guarantee that the enclave is secure.

TEEs are used in production for confidential computing in cloud environments (Azure Confidential Computing, AWS Nitro Enclaves) and have been proposed as alternatives to blockchain for scenarios where computation integrity is the primary trust requirement.

Conflict-Free Replicated Data Types (CRDTs)

CRDTs are data structures that can be replicated across multiple nodes and updated independently, with a mathematical guarantee that all replicas will converge to the same state without coordination. Unlike blockchain consensus, which requires nodes to agree before updating state, CRDTs allow updates first and guarantee eventual consistency.

CRDTs are ideal for collaborative editing (Google Docs uses a CRDT-like approach), distributed databases, and scenarios where availability matters more than strict consistency. They do not provide the immutability or auditability of blockchain, but for many trust scenarios, eventual consistency with guaranteed convergence is sufficient.

Technology Trust Model Throughput Energy Cost Immutability Best For
Blockchain (PoW) Distributed consensus Low (7-30 TPS) Very high Strong Censorship-resistant value transfer
Blockchain (PoS) Stake-weighted consensus Medium (100-1000 TPS) Low Strong Programmable value, DeFi
DAG Transaction-validates-transaction High (1000+ TPS) Low Moderate IoT, microtransactions
TEE Hardware manufacturer guarantee Very high Low None (ephemeral) Confidential computation
CRDT Mathematical convergence guarantee Very high Low None (mutable) Collaborative data, eventual consistency

Regulatory Compliance and Blockchain

Regulatory compliance presents some of the most fundamental challenges to blockchain adoption, particularly in jurisdictions with strong data protection laws. The tension between blockchain's core properties (immutability, transparency, distributed storage) and regulatory requirements (data deletion, access control, jurisdictional data residency) is not a bug to be fixed — it is a structural conflict inherent in the architecture.

GDPR and Blockchain

The General Data Protection Regulation (GDPR), effective since May 2018, establishes data protection rights for individuals in the European Union and European Economic Area. Several GDPR provisions create direct conflicts with blockchain architecture:

Article 17: Right to Erasure (Right to Be Forgotten) — individuals have the right to request deletion of their personal data. Blockchain's immutability makes deletion architecturally impossible — data written to a blockchain cannot be removed without invalidating the entire chain from that point forward.

Article 5(1)(c): Data Minimization — only data that is necessary for the specified purpose should be collected and stored. Public blockchains, by design, replicate all data to all nodes — the antithesis of data minimization.

Article 5(1)(e): Storage Limitation — personal data should be kept only as long as necessary. Blockchain stores data permanently by design.

Articles 25-26: Data Controller and Processor Obligations — GDPR requires identifying data controllers (who determine how data is processed) and data processors (who process data on behalf of controllers). In a public blockchain, every node is both controller and processor, creating regulatory ambiguity.

GDPR Requirement Blockchain Conflict Proposed Workaround Workaround Limitation
Right to erasure Immutable ledger cannot delete data Store personal data off-chain; on-chain hashes only Hash may still constitute personal data under GDPR
Data minimization All data replicated to all nodes Encrypted data with destroyable keys Encrypted data is still data under GDPR
Storage limitation Permanent storage by design Off-chain data with expiration policies On-chain references remain permanent
Controller identification Distributed nodes; unclear controller Designate a governance entity as controller Undermines decentralization premise
Cross-border transfer Nodes in multiple jurisdictions Permissioned networks in specific jurisdictions Limits network participation

Bias Alert

Rex warns you Some blockchain advocates claim that storing hashes of personal data (rather than the data itself) solves GDPR compliance. This is not settled law. Multiple data protection authorities have indicated that hashes derived from personal data may themselves constitute personal data under GDPR. Do not accept "just use hashes" as a compliance solution without legal review specific to your jurisdiction and use case.

Data Sovereignty

Data sovereignty is the principle that data is subject to the laws and governance structures of the nation in which it is collected or stored. Data sovereignty requirements create additional challenges for blockchain networks that operate across borders.

When a blockchain node in Germany stores transaction data that includes information about a Brazilian citizen, which country's data protection laws apply? The answer depends on complex jurisdictional analysis, but the architectural reality is that public blockchains cannot guarantee data residency in any specific jurisdiction because nodes anywhere in the world store copies of all data.

Permissioned blockchains can address data sovereignty by restricting node locations to specific jurisdictions, but this restriction limits the network's geographic distribution and may undermine the trust properties that justified using a blockchain in the first place.

The Right to Be Forgotten

The right to be forgotten (RTBF), codified in GDPR Article 17, is the most direct conflict between data protection law and blockchain architecture. The RTBF gives individuals the right to request that their personal data be erased when it is no longer necessary for its original purpose, when consent is withdrawn, or when the data was processed unlawfully.

Blockchain's immutability is not merely an implementation detail — it is a core value proposition. The guarantee that historical records cannot be altered is precisely what makes blockchain useful for auditability, non-repudiation, and tamper evidence. Removing this property to comply with the RTBF would fundamentally undermine the technology's purpose.

Proposed technical solutions include:

  • Off-chain storage with on-chain pointers — store personal data in a mutable database and place only cryptographic pointers on the blockchain. Deletion removes the off-chain data, leaving orphaned pointers.
  • Chameleon hashes — use special hash functions that allow authorized parties to modify hash values, enabling "editing" of the blockchain. This directly contradicts immutability guarantees.
  • Encryption with key destruction — encrypt personal data before placing it on-chain, then destroy the encryption key when erasure is requested. The encrypted data remains but is (theoretically) unrecoverable.

None of these solutions fully resolves the tension. The off-chain approach is the most widely adopted, but it reduces the blockchain to a hash registry — raising the question of whether the blockchain component is adding sufficient value over a centralized hash database with digital signatures.

Technology Readiness Levels

Technology Readiness Level (TRL) is a measurement system originally developed by NASA to assess the maturity of new technologies. The TRL scale ranges from 1 (basic principles observed) to 9 (actual system proven in operational environment). Applying TRL to trust technologies provides a standardized vocabulary for discussing maturity without relying on vague terms like "emerging" or "mature."

TRL Description Trust Technology Examples
1-2 Basic principles observed; concept formulated Fully homomorphic encryption for general computation
3-4 Proof of concept; validated in lab Multi-party computation for general business logic
5-6 Validated in relevant environment; demonstrated in pilot Self-sovereign identity wallets, many enterprise blockchain pilots
7-8 System prototype demonstrated; qualified in operational environment ZK-rollups, verifiable credentials in government pilots
9 Actual system proven in operational environment Public blockchain (Bitcoin, Ethereum), centralized PKI, TLS

The TRL framework is particularly useful for blockchain evaluation because the industry has a tendency to conflate proof-of-concept demonstrations (TRL 3-4) with production readiness (TRL 8-9). When a vendor claims their blockchain platform "supports 100,000 transactions per second," the evidence-based evaluator asks: at what TRL was this measured? A lab benchmark (TRL 4) has very different implications than a production deployment under real-world conditions (TRL 9).

Key Insight

Rex is thinking Most enterprise blockchain platforms are at TRL 5-7: validated in relevant environments but not yet proven at scale in production. Most post-blockchain technologies (DAGs, CRDTs for trust applications) are at TRL 3-6. Making architecture decisions based on TRL 3 technology for a mission-critical system is like building a hospital based on Phase 1 clinical trial results.

The gap between TRL 6 (demonstrated in pilot) and TRL 9 (proven in production) is where the majority of technology projects fail. This gap — sometimes called the "valley of death" — requires not just technical maturation but also organizational readiness, regulatory clarity, ecosystem development, and market adoption. The evidence-based evaluator budgets significant time, cost, and risk for crossing this gap.

Diagram: Technology Readiness Level Assessment Tool

Interactive TRL Assessment for Trust Technologies

Type: MicroSim sim-id: trl-assessment-tool
Library: p5.js
Status: Specified

Learning objective: Evaluate (L5) — Assess the technology readiness level of emerging trust technologies and use TRL assessment to inform architecture decisions with appropriate risk budgeting.

Description: An interactive vertical thermometer-style TRL gauge for each of five trust technologies (blockchain, ZKPs, VCs, DIDs, SSI). Each thermometer fills to the technology's current TRL level, color-coded from red (TRL 1-3) through yellow (4-6) to green (7-9). Clicking a thermometer reveals a detail panel showing: current TRL with justification, key milestones needed to advance, estimated timeline to TRL 9, and risk assessment for adopting at current TRL. A comparison mode allows selecting two technologies to display a side-by-side maturity comparison. A slider control labeled "Your Risk Tolerance" (Low/Medium/High) highlights which technologies fall within the acceptable TRL range.

Canvas: Responsive width, 550px height. Background: aliceblue.

Controls:

  • Click thermometers to see detail panels
  • "Compare" toggle for side-by-side view
  • Risk tolerance slider (Low/Medium/High)
  • "Show All Details" toggle

Visual elements:

  • 5 vertical thermometer gauges with TRL scales (1-9)
  • Color gradient fills (red→yellow→green)
  • Technology labels below each thermometer
  • Detail panel with TRL justification, milestones, timeline, risk
  • Risk tolerance overlay highlighting acceptable TRL range
  • Comparison panel for side-by-side analysis

Implementation: p5.js with responsive canvas, interactive thermometer gauges, click-to-reveal panels, slider control

Key Takeaways

This chapter examined the trust technology landscape beyond blockchain, revealing a rich ecosystem of alternatives and complements:

  • Zero-knowledge proofs enable verification without disclosure — a fundamentally different trust model from blockchain's transparency-based approach — and have reached production maturity for specific applications like ZK-rollups and private transactions
  • Verifiable credentials provide tamper-evident, portable digital claims that can be verified without contacting the issuer, following the W3C standard for interoperability
  • Decentralized identifiers give subjects control over their digital identity anchors, and notably do not require blockchain — did:web and did:key methods work without any distributed ledger
  • Self-sovereign identity offers a compelling vision of user-controlled identity but faces practical challenges in key management, revocation, legal recognition, and adoption incentives
  • Post-blockchain technologies including DAGs, TEEs, and CRDTs address specific trust problems with different architectural tradeoffs, often providing higher throughput or lower energy costs
  • GDPR and blockchain are in fundamental architectural tension — the right to be forgotten, data minimization, and storage limitation requirements conflict directly with blockchain's immutability, and proposed workarounds do not fully resolve the conflict
  • Data sovereignty requirements challenge cross-border blockchain deployments where nodes in multiple jurisdictions store copies of all data
  • Technology Readiness Levels provide a standardized vocabulary for assessing maturity, revealing that most enterprise blockchain and post-blockchain technologies sit at TRL 5-7, well below the TRL 9 required for mission-critical production deployment

Excellent Analytical Work!

Rex celebrates You now have a panoramic view of the trust technology landscape — not just blockchain, but the full spectrum of cryptographic, identity, and distributed systems technologies that address trust problems. More importantly, you can assess each technology's maturity using the TRL framework and identify regulatory obstacles before they become expensive surprises. In the next chapter, we put all of this knowledge to work in structured architecture decisions. Keep verifying, fellow analyst!