Argument Map
Have Public Chains Been Expelled from Identity Infrastructure? A De-Blockchain Path for SSI
DID/VC Public Blockchain Deployments — Argument Map (v2, retrofit R4)
DID/VC had clear public chain DNA in its early stages, but after four misaligned forces (GDPR + eIDAS + KYC/AML + operational responsibility) piled pressure on top of each other, the mainstream trust root moved toward consortium chains or PKI. Three counterexamples emerging in 2024–2026 (Argentina's QuarkID on ZKsync L2, Bhutan's NDI migrating to Ethereum mainnet, and Taiwan's Digital Identity Wallet anchoring its trust list on a public chain) demonstrate that public chains in identity infrastructure are not structurally infeasible — it is more like a function of governance and regulatory conditions. Five positions in identity infrastructure where public chains can still stand: immutable redundant copies of revocation status, timestamp anchoring of cross-organizational trust lists, cross-domain audit event locks, direct trust roots in specific governance contexts, and experimental space for edge-case trial and error. This article serves as the trust root foundation for main series article 08 (dns-vs-identity-trust-roots) + article 12 (no-phone-home) + article 07 (passport-rooted-paradox), supplying the primary draft for Ch11.2.
DID/VC's de-blockchain evolution is a function of four overlapping pressures (GDPR + eIDAS + KYC/AML + operational responsibility), not a structural inevitability; public chains retain five viable positions in identity infrastructure, validated by 2024-2026 counterexamples.
Trust_root_choice(j) ∈ {public_chain, consortium, PKI, no_chain}
De-chain_path = f(GDPR, eIDAS, KYC_AML, operational_responsibility)
¬structural_inevitability(de-chain) ; ∃ counter-examples {QuarkID, NDI_Bhutan, TW_DIW}
Public_chain_positions = ⟨revocation_mirror, timestamp_anchor, audit_event_lock, contextual_trust_root, experimental_space⟩
Counter-example(c) ⇔ governance(c) ∧ regulatory(c) ∧ tech_readiness(c) compatible_with_public_chain
The mainstream trust root moving toward consortium chains or PKI is the result of four overlapping pressures, not structural infeasibility. Three counterexamples prove that public chains can still serve as trust roots under specific governance and regulatory contexts; public chains retain five viable positions in identity infrastructure (revocation mirror + timestamp anchor + audit event lock + specific trust root + experimental space).
Trust_root_choice(j)- Jurisdiction j's choice of trust root architecture
De-chain_path- De-blockchain evolutionary path
Public_chain_positions- Five viable positions that public chains retain in identity infrastructure
⇔- If and only if
¬- Negation
∧- Conjunction
⇒- Implies
The formula states the position; the next step is to separate common misreadings. Discourse on SSI and identity infrastructure is often simplified to a universal denial that "public chains are unsuitable for identity" — four structural barriers (right to be forgotten, revocation latency, operational responsibility, KYC regulatory pressure) mean public chains have no place in identity infrastructure. This universal denial was a reasonable approximation before 2025, but the three counterexamples of 2024–2026 (QuarkID + NDI + TW DIW) have invalidated the universal denial. The map's first move is to separate the universal denial that "public chains are unsuitable for identity" from "public chains have specific viable positions in identity infrastructure, determined by governance and regulatory conditions."
Public chains have no place in identity infrastructure (universal denial)
Reducing the relationship between public chains and identity infrastructure to a universal denial of "structural unsuitability." Four structural barriers — the right to be forgotten (GDPR Art 17), revocation latency (Bitcoin 10-minute block time), operational responsibility (QTSP legal entity), and KYC regulatory pressure (FATF Travel Rule) — mean public chains have no place in identity infrastructure. This position was a reasonable approximation in 2022–2024 — at that time, empirical deployment of public chains in government-grade identity programs was close to zero. However, three counterexamples in 2024–2026 (QuarkID 2024 on ZKsync L2, Bhutan's NDI migrating to Ethereum mainnet in October 2025, and Taiwan's DIW anchoring its trust list on a public chain) have invalidated the universal denial. The question is no longer "whether public chains have a position" but "under what governance and regulatory conditions, assuming what specific position."
Trust_root_choice ≠ public_chain (structural universal denial, already refuted by counterexamples) Public chains have specific viable positions in identity infrastructure, determined by governance and regulatory conditions
Public chains retain five viable positions in identity infrastructure — immutable redundant copies of revocation status, timestamp anchoring of cross-organizational trust lists, cross-domain audit event locks, direct trust roots in specific governance contexts, and experimental space for edge-case trial and error. The five positions retain different degrees of viability under the four pressures — these are not marginal concessions but the structural positions at which public chains excel (load-bearing wall analogy). Actual adoption is a function of governance and regulatory conditions — the fact that the mainstream market (EU + major East Asian economies + North America) follows consortium chain/PKI has not been overturned; but the universal denial of "no position" has also been overturned.
Public_chain_positions = ⟨revocation_mirror, timestamp_anchor, audit_event_lock, contextual_trust_root, experimental_space⟩ ; ∀ position p : feasibility(p) = f(governance, regulatory, tech_readiness) The distinction is merely a declaration. To prove that "public chains have specific viable positions in identity infrastructure" holds, five independent sources of support are needed. On the genetic front, the public chain default stage in 2015–2018 SSI and DID specifications is traced; on the neutralization front, the compromise consensus of W3C DID Core 1.0 method neutralization reveals factional power struggles; on the pressure front, four legal and operational pressures and their accumulation are catalogued; on the engineering front, the misalignment between revocation latency and immutable ledgers is elaborated at the specification level; on the empirical front, three categories of cases — mainstream (EBSI / Singpass / Aadhaar / gov.br / My Number / FidO) + counterexamples (QuarkID / NDI / TW DIW) + failures (German ID Wallet / Huduma Namba / Sovrin) — are laid out for comparison. Five pillars correspond to five types of argument.
§2 — Genetic (public chain default in 2015–2018 SSI specifications)
Early DID did have public chain DNA
whyProvides historical context; without awareness of the public chain DNA in SSI's origins, "de-blockchain" would be misread as "public chains were never suitable." Christopher Allen 2016 + early method design + Sovrin's early compromise provide the starting point for the historical path.
In the SSI and DID documents of 2015–2018, public blockchains were treated as the default stage. Christopher Allen 2016's "The Path to Self-Sovereign Identity" — its "Existence," "Control," and "Persistence" principles directly treated permissionless ledgers as the default carrier for SSI. The early methods collected in the W3C DID Specification Registries — did:btcr (Allen et al. 2017), did:ethr (uPort/ConsenSys 2018), did:ion (Microsoft 2019), did:sov (Sovrin / Hyperledger Indy) — had public chain advocates speaking loudest. But compromise had already occurred along this same timeline — the Sovrin Foundation 2017 Trust Framework set the goal of being a "global public utility," but the implementation backend chose Hyperledger Indy, a permissioned consortium chain, representing an early concession in the SSI community between "publicly readable, permissioned-write." During the same period, did:web and did:key began taking shape from 2019 onward.
Genesis(SSI, 2015-2018) ⊨ ⟨public_chain_default, early_compromise(Sovrin_Indy_2017)⟩ §3 — Neutralization (W3C DID Core 1.0 method compromise consensus)
Engineering compromise left by factional struggles at W3C
whyProvides specification-level evidence; with only the surface statement that "DID/VC is neutral," the political-economic motivations for "why neutral" are obscured. The W3C Director's 2022 ruling on DID 1.0 Formal Objections is direct evidence that "neutralization is a compromise consensus."
W3C DID Core v1.0 became a Recommendation on July 19, 2022. §1 Introduction states: "This specification does not require any specific blockchain or distributed ledger technology." Method design is made pluggable; DID resolution is left to each method to handle independently. But behind this neutrality lies real factional struggle — the W3C Director's June 30, 2022 ruling record on DID 1.0 Formal Objections shows that Mozilla and Google objected, questioning the elevation of the specification to Recommendation status without a method evaluation mechanism; the Director ultimately approved the specification and required the working group to subsequently address method selection concerns. Reading method neutralization as "the result of a compromise between the public chain faction and the no-chain faction" is abductive reasoning — currently one of the best available explanations, not yet of deductive conclusion strength; raising it to a higher level requires a systematic review of W3C DID WG GitHub issues and mailing list records. Neutralization may also simply be engineering pragmatism of "different use cases require different solutions."
W3C_neutrality ⇐ ⟨pragmatic_engineering, factional_compromise⟩ ; defer(method_selection) → deployment_layer §4 — Pressure (four mutually accumulating de-blockchain forces)
GDPR + eIDAS + KYC/AML + operational responsibility
whyProvides core causal mechanisms; without individual and cumulative analysis of four pressures, "de-blockchain" would be misread as a single-cause (e.g., GDPR) linear derivation. Counterfactual testing of each pressure establishes a multiple common-cause equilibrium.
**First pressure — GDPR**: France's CNIL 2018 "Blockchain – Solutions for a Responsible Use" explicitly identifies the conflict between public blockchains and GDPR Article 17 (right to erasure), recommending off-chain storage of personal data and only hashes on-chain. EDPB's subsequent multiple opinions continue this position. "Immutability," originally seen as a public chain advantage, became a direct burden under the European personal data governance framework. **Second pressure — eIDAS**: Regulation (EU) 2024/1183 eIDAS 2.0 Articles 5a + 5b require that EUDI Wallet and QEAA issuers be Qualified Trust Service Providers subject to review by member-state-designated supervisory bodies. EUDI ARF v1.4.0 §6 Trust Model follows the eIDAS 1.0 Commission Implementing Decision (EU) 2015/1505 + ETSI TS 119 612 XML Trusted List model; ARF's framing is "following" rather than "rejecting." **Third pressure — KYC/AML**: FATF Recommendation 16 Travel Rule's KYC and record-keeping requirements for VASPs and issuers, combined with various countries' anti-money laundering laws' evidence chain requirements, place "revocable" and "legally accountable entity" needs above "algorithmic guarantees." **Fourth pressure — operational responsibility**: Government programs require clear responsible agencies, budget sources, operational contracts, and appeals channels; permissionless chains have no corresponding roles, and nodes cannot bear administrative responsibility. **Four counterfactual tests**: In a world without GDPR Article 17, eIDAS QTSP accountability would still force a Trusted List model; in a world without eIDAS, the Sovrin case shows that operational responsibility subjects have already pushed communities toward consortium chains; removing the FATF Travel Rule, QTSP accountability and the right to erasure would already have locked in the architecture; the last counterfactual is most interesting — even in a purely private scenario without government accountability, once a service takes on identity issuance at any significant scale, the operator will still be forced by funding sources, SLAs, and appeals processes to find a node cluster with a legal entity (Sovrin records).
De-chain_path ⇐ ⋀ᵢ Pᵢ where P ∈ {GDPR_17, eIDAS_QTSP, FATF_KYC, operational_legal_subject} §5 — Engineering (revocation latency vs immutable ledgers)
Engineering misalignment between revocation requirements and public chain base layer
whyProvides a technical argument independent of regulation; with only the regulatory arguments of the four pressures, the independent axis of "whether it is engineeringly feasible" would be missed. The revocation latency argument establishes engineering constraints while leaving an opening for the L2/ZK route.
VC revocation requires real-time, repeatedly rewritable, batch-updatable capabilities; public chains' high finality latency and write costs do not align with this set of requirements. Microsoft ION uses Sidetree to do batch anchoring on Bitcoin; each write is still constrained by Bitcoin's block time (stable at approximately 10 minutes since 2009). Writing each VC revocation status directly on-chain is impractical in terms of both cost and latency. At the specification level, W3C has made compatible choices — the Bitstring Status List v1.0 specification deliberately treats revocation status as a neutral model of "resource publishable at any URL" (HTTPS, IPFS, and on-chain anchoring are all acceptable), avoiding binding to specific infrastructure; VC Data Model v2.0 §5.4 is neutral on revocation mechanisms. These design choices are the engineering community's concrete response to "on-chain real-time revocation is not feasible." **Leaving an opening for L2/ZK**: After Layer 2 and ZK rollup significantly reduce finality and write costs, "public chains unsuitable for real-time revocation" will be partially rewritten; Argentina's QuarkID choosing ZKsync is at the frontier of this technological change. The scope of this argument is locked to "current mainstream public chain base layers"; once L2 finality drops below 1 second, the revocation latency argument needs re-examination.
Revocation(VC) ⊥ Immutability(public_chain_L1) ; L2/ZK_advancement ⇒ partial_reconciliation(Revocation, Public_chain_L2) §6 — Empirical (three categories of cases laid out: mainstream + counterexamples + failures)
Three routes each propose modifications to the thesis at three different degrees of strength
whyProvides empirical foundation; with only normative and engineering arguments, the proposition of "public chain positions" lacks cross-national comparative evidence. Laying out three categories of cases — mainstream (PKI + consortium chain) + counterexamples (public chain) + failures — reveals the diversity of paths.
**Mainstream cases** — EU-level EBSI is a consortium chain (Hyperledger Besu or Quorum variant, maintained by member-state nodes); ISO/IEC 18013-5:2021 mDL is PKI + device-local, completely chain-free; AAMVA's US digital driver's license guidelines follow this architecture; Singapore's Singpass uses NRIC + government PKI; India's Aadhaar is a centralized biometric database + API; Brazil's gov.br uses federal PKI; Japan's My Number digital authentication app (launched 2023) still uses PKI as trust root; Taiwan's FidO + citizen digital certificate + Ministry of the Interior certificate management center are all PKI routes. **Failed/stalled cases** — Germany's ID Wallet was withdrawn by the BMI in 2021 due to technical stability and security issues (IDunion system uses a Hyperledger Indy variant); Kenya's Huduma Namba was stalled in 2021 by a High Court ruling of insufficient data protection (centralized database architecture failure, unrelated to on-chain or off-chain); Sovrin Foundation entered restructuring in 2021 (flagship foundation's funding model unable to sustain infrastructure operations). **Public chain counterexamples** — Argentina's Buenos Aires QuarkID (Extrimian + Matter Labs collaboration, deployed on ZKsync L2 in 2024, first phase already open for daily use by Buenos Aires residents); Bhutan's NDI (October 2023 Hyperledger Indy launch → August 2024 migration to Polygon → October 13, 2025 migration to Ethereum mainnet, with full credential on-chain anchoring migration for approximately 800,000 residents expected to complete by Q1 2026; GovTech Secretary Jigme Tenzing publicly explained the selection rationale as Ethereum's "high degree of decentralization making it nearly uninterruptible"); Taiwan's Digital Identity Wallet (OpenID4VCI + SD-JWT specification, trust list recorded on a public chain; inside information points to the Ethereum ecosystem, but the specific chain ID + contract address + DID method have not been fully disclosed publicly). **Tokenized identity opens a separate domain** — Cheqd + Polygon ID + KILT + Atala PRISM + Worldcoin have each run pilots; empirical evidence of governments and large regulated financial institutions directly handing trust roots to tokenized infrastructure is still close to zero. **Taiwan's tiered civil society practice** — Numbers Protocol (image attestation + IPFS + on-chain) and FAB DAO (on-chain voting + NFT fundraising) belong to constructive timestamping functions and civic advocacy DAO governance, and have not assumed identity roots.
Cases = ⟨mainstream(consortium ∨ PKI), counter(QuarkID ∨ NDI ∨ TW_DIW), failure(German_ID ∨ Huduma ∨ Sovrin)⟩ ; mainstream_dominant ∧ ¬structural_inevitability_of_de-chain The pillars are affirmative arguments. Bhutan's NDI evolution from going live on Hyperledger Indy in October 2023 to migrating to Ethereum mainnet in October 2025 provides a specific causal chain of "Indy consortium chain → Polygon L2 → Ethereum mainnet." The first part is an engineering choice necessity (Indy operational cost pressure), while the latter part is a governance choice probabilistic event (DHI + GovTech's policy judgment on Ethereum's "high degree of decentralization"). The purpose of unfolding the chain is to translate the abstract "governance and regulatory conditions function" into a mechanically traceable event sequence.
Five-step causal chain of Bhutan's NDI migration (Indy → Polygon → Ethereum)
⇒ Mechanistically necessary (structural, does not depend on external trigger) ◊⇒ Probabilistic (requires an external trigger to materialize, but probability is non-negligible) Once the position and causal chain are established, counterarguments pose a genuine threat. CNIL 2018's argument on the conflict between GDPR and public chains; eIDAS 2.0 QTSP system's hard requirement for operational responsibility legal entities; FATF Travel Rule's statutory requirement for KYC records; the "no responsible party" counterargument for public chains. Carefully examining the empirical strength of each counterargument reveals that they not only fail to refute the map's position but actually flip to support the layered design of "five viable positions" — that is, the evidential structure of the counterarguments themselves is precisely the second layer of support for the map.
Counterargument 1
CNIL 2018 — Structural conflict between public chains and GDPR Art 17
pivotThe counterargument appeals to CNIL 2018 "Blockchain – Solutions for a Responsible Use," which argues the conflict between public blockchains and GDPR Article 17 (right to erasure) — the "immutability" characteristic is logically incompatible with "the right to delete personal data." EDPB's subsequent multiple opinions continue this position. Empirical strength is high; this is the clear position of the European personal data governance framework.
On closer inspection, the scope of CNIL's and EDPB's argument is "public chains are unsuitable for storing personal data," not "public chains have no position in identity infrastructure." The map adopts this argument and explicitly states the design of "public chains not writing personal data directly but only serving as trust anchor/timestamp/immutable copy" (modeled after W3C Bitstring Status List neutral model + Taiwan DIW trust list anchoring mode). The CNIL counterargument inversely supports the layered design of "five viable positions" — the positions where public chains serve without writing personal data (revocation status hash, trust list anchoring, timestamps) are precisely the range acceptable under the CNIL position.
Counterargument 2
eIDAS 2.0 QTSP system — hard requirement for legal entity operational responsibility
pivotThe counterargument appeals to eIDAS 2.0 Articles 5a + 5b, which require that EUDI Wallet and QEAA issuers be Qualified Trust Service Providers subject to review by member-state-designated supervisory bodies; EUDI ARF v1.4.0 §6 follows the XML Trusted List model; public chains have no position to serve as trust roots in EU statutory identity infrastructure. Empirical strength is high; this is the clear position of EU law.
The eIDAS system's hard requirement is "legal entity operational responsibility," not "public chains cannot be used." The map's position explicitly states that within the eIDAS legal domain, public chains do not serve as trust roots (consortium chains or PKI dominate), but retains "five viable positions" including revocation copies, timestamp anchoring, audit event locks, and experimental space. Taiwan's DIW placing "trust list anchoring on a public chain" is a design where the legal authority for trust roots is still borne by the statutory institution, while the public chain only assumes the limited role of "trust list anchoring" — this corresponds precisely to the viable design of "legal accountability and technical anchoring in separate layers." The eIDAS counterargument inversely supports the necessity of layered design.
Counterargument 3
Bhutan's NDI counterexample cannot be extrapolated — governance context is special
pivotThe counterargument claims that the conditions for Bhutan's NDI migrating to Ethereum mainnet are highly specific — population scale of 800,000, GDPR not applicable, QTSP system not directly constraining, KYC regulatory pressure relatively light, and government willing to take on leading-edge technology risk. Extrapolating this case to the EU or major East Asian economies does not hold. Empirically, the contextual specificity of the Bhutan case is a fact.
Bhutan's special context is not evidence that "the counterexample is invalid" but evidence of the "governance and regulatory conditions function." The map's position from the outset is "public chains have specific viable positions in identity infrastructure, determined by governance and regulatory conditions" — Bhutan's NDI making a public chain trust root choice in its specific context is precisely a concrete instance of this function argument. Taiwan's DIW choosing "trust list anchoring" rather than full trust root under a stricter regulatory context, and QuarkID on ZKsync L2 rather than mainnet — the three counterexamples propose modifications to the thesis at three different degrees of strength. The counterargument inversely supports the core position of the "function argument," highlighting the refinement of "specific position + governance conditions function."
Once counterarguments are absorbed, what remains are design implications. Under what conditions can "public chains assuming a viable position in identity infrastructure" be considered a legitimate policy path? Six conditions translate the abstract five positions into verifiable engineering or institutional obligations, filling in the Public_chain_positions of the core formula.
The legitimacy of any public chain assuming an identity infrastructure position must pass six conditions
valid_position(p) ⇔ V_no_personal_data ∧ V_legal_subject ∧ V_revocation_capable ∧ V_governance_layered ∧ V_finality_acceptable ∧ V_redundancy_principlePublic chains only assume positions that do not write personal data — revocation status hash, trust list anchoring hash, event sequence fingerprints; personal data stored off-chain. Modeled after CNIL 2018 + EDPB position.
V_no_personal_data: ∀ on-chain_data : ¬personal_data(on-chain_data) ∧ off-chain_storage(personal_data) Even if a public chain assumes the trust root, governance and operational responsibility are still borne by a statutory institution or legal entity, modeled after Bhutan's DHI + GovTech model + Taiwan's DIW Ministry of Digital Affairs model.
V_legal_subject: ∀ governance_decision : ∃ legal_subject(decision) ∧ accountable(legal_subject) VC revocation requires real-time, repeatedly rewritable, batch-updatable capabilities; the positions assumed by public chains must be compatible with revocation mechanisms (modeled after W3C Bitstring Status List neutral model + Microsoft ION Sidetree batch anchoring).
V_revocation_capable: ∀ on-chain_position : compatible(position, revocation_requirements) The statutory authorization of trust roots is borne by statutory institutions; public chains only assume specific technical anchoring roles (revocation copies, timestamps, event locks). Modeled after Taiwan's DIW "trust list anchoring" model.
V_governance_layered: ∀ trust_root : legal_authority(trust_root) ⊥ tech_anchor(trust_root) The finality latency of public chain positions must be compatible with the functional requirements of that position — revocation copies can accept Bitcoin's 10-minute block time; government-grade DIDs require L2/ZK to reduce finality to second-level.
V_finality_acceptable: ∀ position p : finality_delay(p) ≤ functional_requirement(p) The public chain's position should use "redundancy" rather than "primary control" as the key design word — immutable copies of revocation status, timestamps for cross-organizational trust lists, and event locks all belong to the redundancy layer; they do not replace the primary control system but provide an independently verifiable alternative path.
V_redundancy_principle: ∀ position p : role(p) = redundancy ∨ verification_alternative ; ¬substitute_for_main_control Bringing together the normative, genetic, specification, pressure, engineering, and empirical layers, what the map ultimately argues is a political-economy achievement (trust root selection is not determined by technical maturity but by governance and regulatory conditions) and an asymmetric principle running through all levels — public chains retain five viable positions in identity infrastructure, but actual adoption is a function of governance and regulatory conditions; the 2024–2026 counterexamples prove that the universal denial of "no position" is invalidated, but the fact that the mainstream market (EU + major East Asian economies + North America) still follows consortium chain/PKI has also not been overturned.
The mainstream trust root moving toward consortium chains and PKI is the result of four overlapping pressures, not structural infeasibility. Three counterexamples from 2024–2026 (QuarkID on ZKsync L2, Bhutan's NDI migrating to Ethereum mainnet, and Taiwan's DIW anchoring its trust list on a public chain) demonstrate that public chains in identity infrastructure are not structurally infeasible — rather, they are a function of governance and regulatory conditions. Trust root selection is not determined by technical maturity but by governance and regulatory conditions.
Public chains retain five viable positions in identity infrastructure — immutable redundant copies of revocation status, timestamp anchoring of cross-organizational trust lists, cross-domain audit event locks, direct trust roots in specific governance contexts, and experimental space for edge-case trial and error. The five positions retain different degrees of viability under the four pressures — these are not marginal concessions but the structural positions at which public chains excel (load-bearing wall analogy).
This article serves as the trust root foundation for main series article 08 (dns-vs-identity-trust-roots) + article 12 (no-phone-home-engineering-economics) + article 07 (passport-rooted-paradox), supplying the primary draft for Ch11.2 of the dissertation. Article 08's historical comparison of DNS vs identity trust roots directly corresponds to "why public chains in identity infrastructure did not replicate DNS's success" in this article; article 12's engineering economics directly corresponds to the engineering argument of "revocation latency vs immutable ledgers" in this article; article 07's passport-rooted paradox directly corresponds to the "multiple common-cause equilibrium of four pressures" in this article. Taiwan's DIW is the local empirical case of the "governance and regulatory conditions function"; QuarkID and Bhutan's NDI are the key evidence of counterexamples across continents.
Final form:
Trust_root_choice(j) ∈ {public_chain, consortium, PKI, no_chain}
Choice(j) = f(governance(j), regulatory(j), tech_readiness(j))
De-chain_path ⇐ ⋀ᵢ Pᵢ where P ∈ {GDPR_17, eIDAS_QTSP, FATF_KYC, operational_legal_subject}
Counter-examples ⊨ ¬structural_inevitability_of_de-chain
Public_chain_positions = ⟨revocation_mirror, timestamp_anchor, audit_event_lock, contextual_trust_root, experimental_space⟩
∀ position p : valid(p) ⇔ V_no_personal_data ∧ V_legal_subject ∧ V_revocation_capable ∧ V_governance_layered ∧ V_finality_acceptable ∧ V_redundancy_principle
Source
===
title: 公共鏈被身分基建請出去了嗎？一條 SSI 的去鏈化路徑
subTitle: DID/VC Public Blockchain Deployments — Argument Map (v2, retrofit R4)
slug: 2026-05-01-did-vc-public-blockchain
author: research-article-pipeline argdown export
model:
removeTagsFromText: true
===
# Central Thesis
[Core Thesis]
+ <Formal Core>
+ [Accepted]
+ <P1>
+ <P2>
+ <P3>
+ <P4>
+ <P5>
+ <Causal Chain>
+ [Deployment Conditions]
+ <Conclusion>
- [Rejected]
- [Accepted]
+ [Accepted]
- [Objection 1]
- <Reply 1>
+ <Reply 1>
- [Objection 2]
- <Reply 2>
+ <Reply 2>
- [Objection 3]
- <Reply 3>
+ <Reply 3>
[Core Thesis]: DID VC 早期有清楚的公共鏈基因，但四道彼此沒對齊的力量（GDPR eIDAS KYC AML 營運責任）疊加推擠後，主流 trust root 走聯盟鏈或 PKI。2024-2026 年陸續浮出三條反例（阿根廷 QuarkID 上 ZKsync L2、不丹 NDI 遷至 Ethereum 主網、台灣數位憑證皮夾把信任清單錨在公共鏈），證明公共鏈在身分基建並非結構不可行，更像治理與法規條件的函數。公共鏈在身分基建仍能站的五個位置 撤銷狀態的不可變冗餘副本、跨組織信任清單的時間戳錨定、跨域審計事件鎖、特定治理脈絡下的直接 trust root、邊角實驗的試錯空間。本文為主系列 article 08（dns-vs-identity-trust-roots） article 12（no-phone-home） article 07（passport-rooted-paradox）的信任根基礎，提供 Ch11.2 主稿。 #thesis
<Formal Core>: Formula Trust root choice(j) public chain, consortium, PKI, no chain De-chain path f(GDPR, eIDAS, KYC AML, operational responsibility) structural inevitability(de-chain) counter-examples QuarkID, NDI Bhutan, TW DIW Public chain positions revocation mirror, timestamp anchor, audit event lock, contextual trust root, experimental space Counter-example(c) governance(c) regulatory(c) tech readiness(c) compatible with public chain Caption 主流 Trust root 走聯盟鏈或 PKI 是四道壓力疊加的結果，並非結構不可行。三條反例證明公共鏈在特定治理與法規脈絡下仍可承擔 trust root 公共鏈在身分基建保有五個可行位置（撤銷副本 時間戳錨定 審計事件鎖 特定 trust root 試錯空間）。 #formal
[Accepted]: 公共鏈在身分基建有特定可行位置，由治理與法規條件決定. 公共鏈在身分基建保有五個可行位置——撤銷狀態的不可變冗餘副本、跨組織信任清單的時間戳錨定、跨域審計事件鎖、特定治理脈絡下的直接 trust root、邊角實驗的試錯空間。五個位置在四道壓力下保有不同強度的可行性，並非邊角讓步而是公共鏈最擅長的結構位（承重牆比喻）。實際採用是治理與法規條件的函數——主流市場（歐盟 東亞主要經濟體 北美）走聯盟鏈 PKI 的事實未被推翻 但「沒位置」的全稱否認也被推翻。 #accepted
[Rejected]: 公共鏈在身分基建沒有位置（全稱否認）. 把公共鏈與身分基建關係化約為「結構不適合」的全稱否認。個資被遺忘權（GDPR Art 17）、撤銷時效（Bitcoin 10 分鐘 block time）、營運責任（QTSP 法人主體）、KYC 監管壓力（FATF Travel Rule）四道結構性障礙使公共鏈在身分基建沒有位置。這個立場在 2022-2024 年曾是合理近似——當時公共鏈在政府級身分計畫的部署實證接近零。但 2024-2026 三條反例（QuarkID 2024 上 ZKsync L2、不丹 NDI 2025-10 遷至 Ethereum 主網、台灣 DIW 把信任清單錨在公共鏈）使全稱否認失效。問題不再是「公共鏈是否有位置」，而是「在什麼治理與法規條件下、承擔什麼具體位置」。 #rejected
<P1>: Title 早期 DID 真的有公共鏈基因 Section 2 — 基因（2015-2018 SSI 規格的公共鏈預設） Role 提供歷史脈絡 若無對 SSI 起源的公共鏈基因認識，「去鏈化」會被誤讀為「公共鏈本來就不適合」。Christopher Allen 2016 早期 method 設計 Sovrin 早期讓步提供歷史路徑的起點。 2015-2018 那一批 SSI 與 DID 文件，公共區塊鏈被當成預設舞台。Christopher Allen 2016 The Path to Self-Sovereign Identity 「Existence」「Control」「Persistence」原則直接把無許可帳本當成 SSI 默認承載體。W3C DID Specification Registries 早期收的 method——did btcr（Allen 等 2017）、did ethr（uPort ConsenSys 2018）、did ion（Microsoft 2019）、did sov（Sovrin Hyperledger Indy）——公共鏈派講話最大聲。但同一條時間軸上妥協已先發生——Sovrin Foundation 2017 Trust Framework 目標寫成「全球公共實用工具」但實作底層挑了 Hyperledger Indy 許可式聯盟鏈，是 SSI 社群在「公共可讀、許可可寫」之間的早期讓步。同期 did web 與 did key 2019 起逐步成形。 Finding 「公共鏈基因」更像一種設計取向的共同預設，並非單一執行模式 早期讓步已預告後續更大幅度的去鏈化。 Formal Genesis(SSI, 2015-2018) public chain default, early compromise(Sovrin Indy 2017) #pillar
<P2>: Title 派系角力在 W3C 留下的工程妥協 Section 3 — 中立化（W3C DID Core 1.0 method 妥協性共識） Role 提供規格層證據 若僅有「DID VC 是中立的」的表面陳述，「為何中立」的政治經濟動機被遮蔽。W3C Director 2022 對 DID 1.0 Formal Objections 的裁決紀錄是「中立化是妥協性共識」的直接證據。 W3C DID Core v1.0 於 2022-07-19 成為 Recommendation。 1 Introduction 寫「This specification does not require any specific blockchain or distributed ledger technology」。Method 設計成可插拔，DID 解析交給各 method 各自負責。但這個中立背後是真實的派系角力——2022-06-30 W3C Director 對 DID 1.0 Formal Objections 裁決紀錄顯示 Mozilla 與 Google 提出反對，質疑在沒有 method 評選機制的情況下就把規格升級為 Recommendation Director 最終批准規格並要求工作組後續處理 method 選型疑慮。把 method 中立化讀成「公共鏈派與無鏈派妥協的結果」屬於溯因推理，是目前可得的最佳解釋之一，不到演繹結論的強度 要再抬高層級需逐條盤點 W3C DID WG GitHub issue 與 mailing list 紀錄。中立化也可能僅僅是「不同 use case 需求不同」的工程務實。 Finding W3C method 中立化是工程務實與政治妥協的疊加產物，留下 method 層的選型自由給後續部署層的法規與營運壓力填上具體選擇。 Formal W3C neutrality pragmatic engineering, factional compromise defer(method selection) deployment layer #pillar
<P3>: Title GDPR eIDAS KYC AML 營運責任 Section 4 — 壓力（四道彼此疊加的去鏈化力量） Role 提供核心因果機制 若無四道壓力的個別與疊加分析，「去鏈化」會被誤讀為單一原因（如 GDPR）的單線推導。每道壓力的反事實檢驗確立多重共因均衡。 第一道 GDPR ——法國 CNIL 2018 Blockchain Solutions for a Responsible Use 明確指出公共區塊鏈與 GDPR 第 17 條被遺忘權的衝突，建議鏈下儲存個資、鏈上只放 hash。EDPB 後續多份意見延續這條立場。「不可變」原本被當成公共鏈優點，在歐洲個資治理框架下成了直接負擔。 第二道 eIDAS ——Regulation (EU) 2024 1183 eIDAS 2.0 Article 5a 5b 規定 EUDI Wallet 與 QEAA issuer 必須是 Qualified Trust Service Provider，由會員國指定監督機構審查。EUDI ARF v1.4.0 6 Trust Model 沿用 eIDAS 1.0 Commission Implementing Decision (EU) 2015 1505 ETSI TS 119 612 XML Trusted List 模型 ARF 是「沿用」而非「拒斥」的論述方式。 第三道 KYC AML ——FATF Recommendation 16 Travel Rule 對 VASP 與發行者的 KYC、紀錄保存要求，加上各國洗錢防制法的舉證鏈，使「可撤銷」「可追究法人」需求高過「演算法保證」。 第四道營運責任 ——政府計畫需要明確的負責機關、預算來源、操作合約、申訴管道，無許可鏈上沒有對應角色，節點承擔不了行政責任。 四道反事實檢驗 ——GDPR 沒有第 17 條的世界裡 eIDAS QTSP 問責仍會逼出 Trusted List 模型 eIDAS 不存在的世界裡 Sovrin 案例顯示營運責任主體本身已把社群推向聯盟鏈 把 FATF Travel Rule 拿掉，QTSP 問責與被遺忘權早已把架構框死 最後一道的反事實最有意思——即使在沒有政府問責的純民間場景，只要服務承擔了一定規模身分發行，運維方仍會被資金來源、SLA、申訴流程逼到去找一個有法人主體的節點集合（Sovrin 紀錄）。 Finding 四道壓力是多重共因均衡，並非哪一道單獨拍板 任何一道力量單獨缺席仍會推動去鏈化，但程度有差。 Formal De-chain path ᵢ Pᵢ where P GDPR 17, eIDAS QTSP, FATF KYC, operational legal subject #pillar
<P4>: Title 撤銷需求與公共鏈基底層的工程不對齊 Section 5 — 工程（撤銷時效 vs 不可變帳本） Role 提供獨立於法規的技術論點 若僅有四道壓力的法規論證，「工程上是否可行」這條獨立軸線會被遺漏。撤銷時效論證確立工程約束，並對 L2 ZK 路線保留開口。 VC 撤銷需要即時、可重複改寫、可批次更新 公共鏈的高 finality 延遲與寫入成本，跟這組需求對不上。Microsoft ION 採 Sidetree 在 Bitcoin 上做 batch anchoring，每筆寫入仍受 Bitcoin block time（自 2009 至今穩定約 10 分鐘）節制。把每張 VC 撤銷狀態都直接上鏈，成本與延遲都不切實際。W3C 規格層做了相容選擇——Bitstring Status List v1.0 規格刻意把撤銷狀態當成「資源可發佈於任何 URL」的中立模型（HTTPS、IPFS、鏈上錨定皆可），避免綁死特定基礎設施 VC Data Model v2.0 5.4 對撤銷機制中立。這些設計選擇是工程社群面對「鏈上即時撤銷不可行」的具體回應。 對 L2 ZK 保留開口 ——Layer 2 與 ZK rollup 把 finality 與寫入成本顯著壓低後，「公共鏈不適合即時撤銷」會被改寫一部分 阿根廷 QuarkID 上 ZKsync 的選擇站在這個技術變遷前緣。本論證範圍鎖在「目前主流公共鏈基底層」，L2 finality 跌破 1 秒之後撤銷時效論點需重新檢驗。 Finding 撤銷時效在主流公共鏈基底層是獨立的工程約束，但 L2 ZK 技術變遷使約束部分鬆動 W3C Bitstring Status List VC Data Model v2.0 的中立性設計已為跨基礎設施部署留下空間。 Formal Revocation(VC) Immutability(public chain L1) L2 ZK advancement partial reconciliation(Revocation, Public chain L2) #pillar
<P5>: Title 三條路線在三個不同強度上對 thesis 提出修正 Section 6 — 實證（主流 反例 失敗三類案例攤平） Role 提供經驗基礎 若僅有規範與工程論證，「公共鏈位置」的命題缺乏跨國比較證據。主流（PKI 聯盟鏈） 反例（公共鏈） 失敗三類案例的攤平揭示路徑的多元性。 主流案例 ——歐盟層級 EBSI 是聯盟鏈（Hyperledger Besu 或 Quorum 變體，由會員國節點維護） ISO IEC 18013-5 2021 mDL 是 PKI 設備本地，完全無鏈 AAMVA 美國駕照數位化指南沿用此架構 新加坡 Singpass 以 NRIC 政府 PKI 印度 Aadhaar 中央化生物特徵資料庫 API 巴西 gov.br 採聯邦 PKI 日本マイナンバー数字認証アプリ 2023 推出仍以 PKI 為信任根 台灣 FidO 自然人憑證 內政部憑證管理中心清一色 PKI 路線。 失敗 受阻案例 ——德國 ID Wallet 2021 上線後因技術穩定性與安全性問題被 BMI 撤回（IDunion 體系採 Hyperledger Indy 變體） 肯亞 Huduma Namba 2021 高等法院裁定資料保護不足部署受阻（中央化資料庫架構失敗，與鏈上鏈下無關） Sovrin Foundation 2021 進入重整（旗艦基金會資金模式無法支撐基礎設施運作）。 公共鏈反例 ——阿根廷 Buenos Aires QuarkID（Extrimian Matter Labs 合作，2024 部署於 ZKsync L2，第一階段已開放給布宜諾斯艾利斯市民日常使用） 不丹 NDI（2023-10 Hyperledger Indy 上線 2024-08 遷至 Polygon 2025-10-13 遷至 Ethereum 主網，預計 2026 Q1 完成 80 萬居民全部 credential 鏈上錨定遷移 GovTech 秘書 Jigme Tenzing 公開選型理由為 Ethereum「高度去中心化使其近乎不可中斷」） 台灣數位憑證皮夾（OpenID4VCI SD-JWT 規格，trust list 記錄於公共鏈，圈內資訊指向 Ethereum 系但具體 chain ID 合約位址 DID method 尚未對外完整揭示）。 代幣化身分另開範疇 ——Cheqd Polygon ID KILT Atala PRISM Worldcoin 各自試點，政府與大型受監管金融機構直接把 trust root 移交給代幣化基礎設施的實證仍接近零。 台灣民間實踐分層 ——Numbers Protocol（影像存證 IPFS 鏈上）與 FAB DAO（鏈上投票 NFT 募款）屬建設性時間戳功能與公民倡議 DAO 治理，未承擔身分根。 Finding 主流仍是 PKI 與聯盟鏈，但公共鏈作為信任錨或 trust root 的反例正在從「個位數零星實驗」變成「跨大洲多國試行」 不丹 trust root 整個搬上公共鏈主網、台灣信任清單錨定在公共鏈、QuarkID 政府級 DID 放在 L2，三條路線在三個不同強度上對 thesis 提出修正但都還沒推翻它。 Formal Cases mainstream(consortium PKI), counter(QuarkID NDI TW DIW), failure(German ID Huduma Sovrin) mainstream dominant structural inevitability of de-chain #pillar
<Causal Chain>: Title 不丹 NDI 五步遷移因果鏈（Indy Polygon Ethereum） T0 (deterministic) 2023-10 — NDI 採 Hyperledger Indy 上線（聯盟鏈選擇，當時主流工程選項） T1 (deterministic) Indy 維運成本與技術可持續性壓力浮現（聯盟鏈節點維運 升級協調的成本結構，規範必然） T2 (deterministic) 2024-08 — 遷至 Polygon（公共 L2，成本與不可中斷性權衡） T3 (probabilistic) 2024-2025 — DHI GovTech 對「人口規模身分系統能否錨在公共網路」的政策判斷成熟（依政權延續性、ETH 生態信任度、技術 readiness 而異） T4 (probabilistic) 2025-10-13 — 正式遷至 Ethereum 主網 GovTech 秘書公開選型理由「高度去中心化使其近乎不可中斷」（外部 trigger，國家治理選擇） T5 (probabilistic) 預計 2026 Q1 完成約 80 萬居民全部 credential 鏈上錨定遷移 中長期跨域互通與後續維運仍待驗證（依個案執行而異） #chain
[Deployment Conditions]: 任何公共鏈承擔身分基建位置的合法性，必須通過六道條件. valid position(p) V no personal data V legal subject V revocation capable V governance layered V finality acceptable V redundancy principle #conditions
<C1>: Title 鏈上不寫個資（V no personal data） 公共鏈僅承擔不寫個資的位置——撤銷狀態 hash、信任清單錨定 hash、事件序列指紋 個資鏈下儲存。仿 CNIL 2018 EDPB 立場。 Formal V no personal data on-chain data personal data(on-chain data) off-chain storage(personal data) #condition
<C2>: Title 法人主體營運責任（V legal subject） 即使公共鏈承擔 trust root，治理與營運責任仍由法定機構或法人主體承擔，仿不丹 DHI GovTech 模式 台灣 DIW 數發部模式。 Formal V legal subject governance decision legal subject(decision) accountable(legal subject) #condition
<C3>: Title 撤銷機制可實作（V revocation capable） VC 撤銷需即時、可重複改寫、可批次更新 公共鏈承擔的位置須與撤銷機制相容（仿 W3C Bitstring Status List 中立模型 Microsoft ION Sidetree batch anchoring）。 Formal V revocation capable on-chain position compatible(position, revocation requirements) #condition
<C4>: Title 治理與技術分層（V governance layered） Trust root 的法定授權由法定機構承擔，公共鏈僅承擔特定技術錨定角色（撤銷副本、時間戳、事件鎖）。仿台灣 DIW「信任清單錨定」模式。 Formal V governance layered trust root legal authority(trust root) tech anchor(trust root) #condition
<C5>: Title Finality 可接受（V finality acceptable） 公共鏈承擔的位置的 finality 延遲須與該位置的功能需求相容——撤銷副本可接受 10 分鐘 Bitcoin block time、政府級 DID 需 L2 ZK 壓低 finality 至秒級。 Formal V finality acceptable position p finality delay(p) functional requirement(p) #condition
<C6>: Title 冗餘原則（V redundancy principle） 公共鏈的位置應以「冗餘」而非「主控」為設計關鍵詞——撤銷狀態不可變副本、跨組織信任清單時間戳、事件鎖均屬冗餘層 不取代主控系統而提供獨立可驗證的替代路徑。 Formal V redundancy principle position p role(p) redundancy verification alternative substitute for main control #condition
<Conclusion>: 主流 trust root 走聯盟鏈與 PKI 是四道壓力疊加的結果，並非結構不可行。 2024-2026 三條反例（QuarkID 上 ZKsync L2、不丹 NDI 遷至 Ethereum 主網、台灣 DIW 把信任清單錨在公共鏈）證明公共鏈在身分基建並非結構不可行，而是治理與法規條件的函數。trust root 的選擇不由技術成熟度決定，而由治理與法規條件決定。 公共鏈在身分基建保有五個可行位置 ——撤銷狀態的不可變冗餘副本、跨組織信任清單的時間戳錨定、跨域審計事件鎖、特定治理脈絡下的直接 trust root、邊角實驗的試錯空間。五個位置在四道壓力下保有不同強度的可行性，並非邊角讓步而是公共鏈最擅長的結構位（承重牆比喻）。 本文為主系列 article 08（dns-vs-identity-trust-roots） article 12（no-phone-home-engineering-economics） article 07（passport-rooted-paradox）的信任根基礎 ，提供博論 Ch11.2 主稿。Article 08 對 DNS vs 身分信任根的歷史比較直接對應本文「為何公共鏈在身分基建未複製 DNS 的成功」 article 12 的工程經濟學直接對應本文「撤銷時效 vs 不可變帳本」的工程論證 article 07 的護照根悖論直接對應本文「四道壓力的多重共因均衡」。台灣 DIW 為「治理與法規條件函數」的本地實證案例，QuarkID 與不丹 NDI 為跨大洲反例的關鍵證據。 Formal Coda Final form Trust root choice(j) public chain, consortium, PKI, no chain Choice(j) f(governance(j), regulatory(j), tech readiness(j)) De-chain path ᵢ Pᵢ where P GDPR 17, eIDAS QTSP, FATF KYC, operational legal subject Counter-examples structural inevitability of de-chain Public chain positions revocation mirror, timestamp anchor, audit event lock, contextual trust root, experimental space position p valid(p) V no personal data V legal subject V revocation capable V governance layered V finality acceptable V redundancy principle #conclusion
# Deployment Conditions
[Deployment Conditions]
+ <C1>
+ <C2>
+ <C3>
+ <C4>
+ <C5>
+ <C6>
# Objections And Replies
[Objection 1]: CNIL 2018 — 公共鏈與 GDPR Art 17 結構性衝突. 反論訴求是 CNIL 2018 Blockchain Solutions for a Responsible Use 論證公共區塊鏈與 GDPR 第 17 條被遺忘權的衝突——「不可變」特性與「個資刪除權」邏輯不相容。EDPB 後續多份意見延續這條立場。實證強度高，是歐洲個資治理框架的明確立場。 #objection
<Reply 1>: Title CNIL 2018 — 公共鏈與 GDPR Art 17 結構性衝突 仔細看，CNIL 與 EDPB 的論證範圍是「公共鏈不適合承載個資」，不是「公共鏈在身分基建無位置」。地圖採此論證並明示「公共鏈不直接寫個資而僅承擔信任錨 時間戳 不可變副本」設計（仿 W3C Bitstring Status List 中立模型 台灣 DIW 信任清單錨定模式）。CNIL 反論反向支撐「五個可行位置」的分層設計——公共鏈承擔不寫個資的位置（撤銷狀態 hash、信任清單錨定、時間戳）正是 CNIL 立場可接受的範圍。 #reply
[Objection 2]: eIDAS 2.0 QTSP 體系 — 法人主體營運責任硬性要求. 反論訴求是 eIDAS 2.0 Article 5a 5b 規定 EUDI Wallet 與 QEAA issuer 必須是 Qualified Trust Service Provider 由會員國指定監督機構審查 EUDI ARF v1.4.0 6 沿用 XML Trusted List 模型，公共鏈在歐盟法定身分基建沒有承擔 trust root 的位置。實證強度高，是歐盟法的明確立場。 #objection
<Reply 2>: Title eIDAS 2.0 QTSP 體系 — 法人主體營運責任硬性要求 eIDAS 體系的硬性要求是「法人主體營運責任」，並非「公共鏈不可用」。地圖立場明示在 eIDAS 法域內公共鏈不承擔 trust root（聯盟鏈或 PKI 主導），但保留「五個可行位置」中的撤銷副本、時間戳錨定、審計事件鎖、邊角試錯空間。台灣 DIW 把「信任清單錨定在公共鏈」是 trust root 治理仍由法定機構承擔、公共鏈僅承擔「信任清單錨定」這個有限角色——這恰好對應「法律問責與技術錨定分層」的可行設計。eIDAS 反論反向支撐分層設計的必要性。 #reply
[Objection 3]: 不丹 NDI 反例不可外推 — 治理脈絡特殊. 反論訴求是不丹 NDI 遷至 Ethereum 主網的條件高度特殊——人口規模 80 萬、GDPR 不適用、QTSP 體系不直接約束、KYC 監管壓力相對輕、政府願意承擔技術前緣風險。把這個案例外推到歐盟或東亞主要經濟體不成立。實證強度上，不丹案例的脈絡特殊性是事實。 #objection
<Reply 3>: Title 不丹 NDI 反例不可外推 — 治理脈絡特殊 不丹的特殊脈絡並非「反例失效」的證據而是「治理與法規條件函數」的證據。地圖立場本來就是「公共鏈在身分基建有特定可行位置，由治理與法規條件決定」——不丹 NDI 在其特殊脈絡下做出公共鏈 trust root 選擇，正是這個函數論的具體實例。台灣 DIW 在更嚴格法規脈絡下選擇「信任清單錨定」而非完整 trust root，QuarkID 在 ZKsync L2 而非主網，三條反例在三個不同強度上對 thesis 提出修正。反論反向支撐「函數論」的核心立場，凸顯「特定位置 治理條件函數」的精細化。 #reply