ZKP

Understanding Zero-Knowledge Proofs The Privacy Infrastructure Powering Trust

Community Blog

04 Feb 2026 • 7 min read

On the surface, this was a technical discussion about Zero-Knowledge technology, identity, compliance, and privacy. But that reading misses the real signal. What we just witnessed went beyond a feature conversation, it was an infrastructure conversation.

Regulation, identity frameworks, AI agents, medical data portability, critical infrastructure, and even national security were all touched in a single thread, outlining how and where Zero-Knowledge moves from being a cryptographic concept into becoming a structural layer of the digital world. At the same time, the session exposed the recurring gap between technological substance and how it is articulated. The academic foundation behind the technology is world-class. The strategic domains mentioned are trillion-dollar territories. Fujitsu, the institutional partner on stage is a global systems integrator and still, the narrative often floats at a general level where the magnitude is merely implied rather than asserted.

The real takeaway is as much about what this combination represents as it is about what was said: ZK is moving out of the crypto niche and into identity infrastructure, regulatory architecture, AI ecosystems, and state-level security logic. We are about to enter the phase where Zero-Knowledge stops being “privacy tech” and starts becoming governance-compatible infrastructure and that shift is actually far more significant than the conversation itself managed to express.

1 Opening & Framing

Marco Carerra:
- Zero-knowledge = “huge strength”
- Market challenges linked to lack of understanding of this strength
Peter Marirosans:
- Aligns with framing
- Objective: help others understand the value they already see
Immediate positioning
- Focus = education & clarity
- Barrier = comprehension gap, not technology limitation

2 Introductions & Strategic Framing

Peter Marirosans (CTO, Concordium):
- Opens formal introductions
- Blockchain background (multi-year involvement)
- Past year focused on Concordium chain
- Positions Concordium around:
  - Zero knowledge
  - Identity
  - Broader infrastructure opportunity
- Signals strong belief in project potential
Marco Carerra (Head of Blockchain & Convergence, Fujitsu):
- Leads blockchain & convergence domain
- Focus areas include:
  - Agents
  - Quantum / post-quantum
  - Blockchain integration
- ZK described as one of the best fits for enabling real blockchain utility
- Approximately 10 years across:
  - Startups
  - Institutional environments
- Acknowledges weak market conditions
- Contrasts with:
  - Growing real-world usage
  - Long-term tech trajectory
- Expresses conviction in technology’s forward impact
Mutual close to intro:
- Alignment on opportunity
- Transition into technical discussion phase

3 The Core Challenge: Explaining Zero-Knowledge

Peter Marirosans:
- Key issue = explaining ZK to non-technical people
- Even family-level explanations fail
Core confusion:
- “Proving something without knowing anything”
- Requests analogies to make concept understandable
Marco Carerra:
- Confirms communication challenge with non-digital audiences
- Defines ZK principle:
  - Prove something
  - Without revealing the real data / document
- Emphasizes foundation:
  - Mathematics
  - Cryptography
- Trust model shift:
  - Trust placed in math, not intermediaries

4 Analogies & Trust Model

Peter Marirosans: PIN analogy
- Giving PIN = revealing secret (bad)
- Withdrawing cash in front of you:
  - Proves PIN knowledge
  - Secret never disclosed
- Core idea:
  - Prove possession of secret
  - Without revealing secret itself
Marco Carerra: access control analogy
- Entering a place:
  - No credential shown
  - Outcome proves authorization
Shared framing
Marco adds:
- Supports GDPR & regulatory compliance
- Not new tech
- Now critical because blockchain needs it
- ZK = “perfect fit” for current infrastructure layer

5 Why Now (Timing)

ZK principles date back to ~1980s
Not new technology
What changed
- Massive digitization of information
- Data now structured for:
Population readiness increased:
- Comfortable with digital identity
- Familiar with electronic data storage
- Understands information flow between systems

6 Enterprise Pain (Data Risk & Cost)

Corporate outlook (next 1–3 years):
- Major pain = hacking / data breaches
- Focus on:
Business impact:
- Continuous high spend on data protection
- Security cost = structural burden
ZK positioned as:
- Solution to real enterprise problem
- Security growth area
Societal framing:
- Individuals reduced to “data” / “numbers”
- Digital exposure normalized
Privacy demand:
- Users willing to pay for protection

7 Privacy “Full Circle” (Loss of Boundaries → Need for ZK)

Society previously:
- Cautious with personal data
- Would not share:
Shift occurred:
- Data given away unconsciously
- Physical privacy barriers disappeared
Analogy:
- Merchant at football club = contextual, acceptable
- Merchant following you home = invasive tracking
Digital environment:
- Constant visibility
- Continuous behavioral tracking
- Normalized consent to surveillance
Societal shift:
- Awareness increasing
- Desire to reclaim control
ZK positioned as:
- Tool to restore privacy boundaries
- Protection for:

8 Identity as the Anchor Use Case

Recognition:
- Data concentrated in central hubs
- Desire to regain control over personal data
Identity = primary domain:
- Control should sit with user, not intermediaries
- Concordium identity layer positioned as solution
ZK-enabled claims:
- Prove age
- Prove jurisdiction
- Prove identity validity
- Without sharing passports / licenses / raw documents
Enterprise angle (Marco):
- Large firms working on digital identity frameworks
- Concern: protecting digital identity / “digital passport”
Compliance tension:
- Audits require data exposure
- Risk:
Current reality:
- Repeated identity checks normalized
- Scans + selfies sent everywhere
- Multiple copies of identity stored across systems

9 Medical Data Portability & Selective Disclosure

Use case introduced: medical data (incl. or perhaps exclusively for children) when traveling internationally
Current limitation:
- No practical way to share needed medical data
- Without exposing full sensitive records
ZK + blockchain enable:
- Partial data disclosure
- Only medically required information shown
- Remaining data stays protected
Consent model:
- Digital / eConsent mechanism
- Temporary access for doctor
- Access can be revoked afterward
Framing:
- Example of capability people don’t realize exists

10 ZK as Invisible Infrastructure

Gap acknowledged:
- Experts enjoy deep technical discussion
- General population does not
Technology maturity stage:
- Should be used without being seen
Encryption analogy:
- Users see “your chat is encrypted”
- Do not understand mechanics
- Still trust the system
Projection:
- Blockchain + ZK will move to same layer
- Fades into background
- Trusted, not examined
Use-case layer sits above:
- Example: medical access abroad
- Identity verification + consent
- No physical records carried

11 Usability, Simplicity & Delivery Model

Product principle:
- Simplicity > cryptographic sophistication
- Applications should look like traditional apps
- No visible blockchain/crypto layer
Team requirement:
- Not only cryptographers
- Mixed skill sets needed
- UX-first development
Adoption logic:
- Especially critical for non-digital / senior users
- Interaction model = “send data → done”
Concordium positioning:
- Identity embedded in chain infrastructure
- Users don’t need to understand mechanics
- Trust derived from:
Merchant flow example:
- Identity app scan
- Consent prompt
- Age verification completed
- No seed phrases / blockchain handling
Real-world example:
- “Digital passport” use case
- Farmers / non-digital users
- Photo + send flow
- Regulatory compliance in background
Conceptual shift:
- Encryption → protects communication
- ZK → protects privacy

12 Regulation, Compliance & Auditability

Regulation discussion introduced:
- Need to balance:
  - Protection
  - Monitoring
  - Avoid over-intrusion
Regulated sectors highlighted:
- Pharma
- Health
- Finance
- Insurance
Core compliance need:
- GDPR alignment
- Data protection
- Financial transparency requirements
ZK positioning:
- Privacy by design
- Data protection embedded in architecture
Forward-looking view (Marco):
- Future MiCA evolution may include / recommend ZK
- Institutions require privacy-preserving infrastructure
- ZK seen as enabler for institutional adoption
Identity/privacy frameworks:
- ZK technologies linked to improved privacy standards
Concordium stance (Peter):
- Active regulator dialogue
- System includes:
- Merchant compliance benefit:

13 Anchoring Strategy, Scaling & Regulatory Balance

Client question:
- “Do we need to anchor every data?” → No!
Design principle:
- Anchor evidence / commitments only
- Not raw or full datasets
Benefits:
- Reduced energy use
- Lower computational load
- Necessary for scalability
Public-chain consideration:
- Over-anchoring increases profiling risk
- Even protected data patterns can be analyzed
Implementation flexibility:
- Anchoring frequency depends on use case
- Options:
Regulatory dimension:
- ZK allows monitoring without data exposure
- Merchant age-check example:
Governance boundary:
- Ongoing debate:
Disclosure framework:
- Extreme legal cases may allow identification
- Controlled, exceptional mechanism

14 Mixers vs ZK & “Proof of Evidence”

Reference event:
- Tornado Cash situation (USA)
- Seen as overreach / mistake
Regulatory confusion:
- Mixers ≠ ZK
- Privacy tools being grouped incorrectly
Distinction:
- Mixers → transaction obfuscation
- ZK → data protection + validation
Core reframing:
- ZK = “proof of evidence”
- Not hiding activity
- Proving correctness without revealing data

15 Mindset Shift: Data → Proofs

System design shift:
- Do not handle raw data
- Work with "proof of evidence”
Old model:
- Reveal information
- Institution says “trust me, I’ll protect it”
ZK model:
- Do not reveal
- Provide proof instead
- Safety on both sides
Developer / enterprise implication:
- Requires different architecture thinking
- Data transformed into proof objects
Early business traction:
- Insurance sector
  - Use cases:
  - Margin improvement potential highlighted
Adoption driver:
- Must connect ZK to concrete pain points
- Requires organizational mindset change
Regulatory pressure example:
- Age verification mandates
- ZK allows:
Market barrier:
- Corporations struggling due to wrong technology choices
- Need education + correct stack
Transparency vs privacy:
- Can coexist via proof systems
- ZK = mechanism enabling both
Governance balance:
- Too private = unsafe
- Too exposed = unsafe
- Midpoint required
Global digital reality:
- Behavior visible worldwide
- Need protection of behavioral data

16 AI Agents & Emerging Privacy Risks

Trend:
- Agents interacting with other agents
- Autonomous data exchange increasing
Risk identified:
- Agents sharing:
- Lack of visibility into:
Anticipated evolution:
- Emergence of ZK-enabled agents (“CK agents”)
- Agents that protect data during interaction
Broader environment:
- Convergence of:
Reaffirmed principle:
- Core need = privacy + protection
- Technology maturity now enables self-protection mechanisms

17 Architecture & Scalability Principles

Client concern:
- Transaction load / system stress
- Question framed as capacity problem
Clarification:
- Not a volume limitation issue
- Technology must be used selectively
Core design rule:
- Do not index all data
- Anchor only specific commitments
Outcome:
- Full-chain traceability preserved
- Privacy maintained
- Compliance requirements met
Key conclusion:
- Scaling depends on architecture design, not chain limits

18 Practical ZK Verification Flow (Concordium Example)

Purpose:
- Concrete explanation to improve understanding
- Adoption expected to follow comprehension
Flow
- Step 1 — Identity verification
- Step 2 — Commitment anchoring
- Step 3 — Verification request
- Step 4 — Proof validation
Stakeholder outcomes
- User:
- Merchant:
- Regulator:
Adoption logic
- Understanding → trust → merchant adoption → user adoption

19 Industry Adoption Outlook

Question raised: which industries adopt ZK next?
- Healthcare:
  - Identity + sensitive data use cases
- Insurance:
  - Already aligned with fraud / risk logic
- Adult industry:
  - Immediate age-verification need
- Social media:
  - User validation without data harvesting
- Dating platforms:
  - Identity assurance without exposure
- Gaming:
  - Age segmentation
  - Adult vs child interaction controls
- Offline/physical layer:
  - Bar entry
  - Events / concerts
  - Ticket ownership validation
Use-case pattern:
- Prove entitlement
- Without revealing identity

20 Military & Critical Infrastructure

Marco introduces new domain:
- Military use
- Critical infrastructure
Context:
- Significant investment in Europe & UK
- Government-level priority area
Infrastructure types mentioned:
- Weather systems
- Water
- Electrical systems
ZK value proposition:
- Protection of critical systems
- Addresses major security “pains”
Adoption requirement:
- Must be explained in simple terms to governments
- Positioning = stronger protection via technology
Peter response:
- Defense historically core driver of tech
- Aligns with ZK as next phase application
Close:
- Confirmed mutual interest in collaboration

21 Closing & Collaboration Outlook

Peter signals session wrap-up
- Emphasizes value of idea exchange
- Suggests continued dialogue
- Reaffirms ongoing collaboration
Marco:
- Thanks for invitation
- Expresses enthusiasm
- Highlights “huge opportunity”
Mutual close:
- Alignment on future cooperation