diff --git a/CHANGELOG.md b/CHANGELOG.md index 5260a2e..c09d8f0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,7 +6,8 @@ All notable changes to the EthSystems Map are documented here. - docs: add Espalier preprint reference to [ZK Proof Systems](patterns/pattern-zk-proof-systems.md), [Post-Quantum Threats](domains/post-quantum.md), and [Safe Proof Delegation](patterns/pattern-safe-proof-delegation.md) `## See also` sections - feat(jurisdiction): [EU / EUDR (Deforestation Regulation)](jurisdictions/eu-EUDR.md) -- Article 9 plot-level geolocation and the DDS reference-number model, ahead of the 30 December 2026 application date ([#181](https://github.com/ethsystems/map/pull/181)) -- fix(vendor): [Zama](vendors/zama.md) — mainnet maturity, symbolic-execution architecture, TFHE-rs, ERC-7984; sync fhEVM status and docs link in [Private Shared State (FHE)](patterns/pattern-private-shared-state-fhe.md) ([#180](https://github.com/ethsystems/map/pull/180)) +- fix(vendor): [Zama](vendors/zama.md) -- mainnet maturity, symbolic-execution architecture, TFHE-rs, ERC-7984; sync fhEVM status and docs link in [Private Shared State (FHE)](patterns/pattern-private-shared-state-fhe.md) ([#180](https://github.com/ethsystems/map/pull/180)) +- chore: fix 18 terminology inconsistencies across 11 files -- ZK proof, zk-SNARK, Data Availability, FHE encryption, ERC-3643 ([#67](https://github.com/ethsystems/map/issues/67)) ## [0.4.0] - 2026-07-02 diff --git a/patterns/pattern-relay-mediated-proving.md b/patterns/pattern-relay-mediated-proving.md index a1c999d..59509e2 100644 --- a/patterns/pattern-relay-mediated-proving.md +++ b/patterns/pattern-relay-mediated-proving.md @@ -57,7 +57,7 @@ open_source_implementations: ## Intent -Split a typical ZK proof flow into two roles. The client signs a portable signed message offline. A relay generates the SNARK over that message and submits it on-chain. To prevent a front-runner from lifting the proof off the mempool and re-submitting it from their own address, the proof binds to the relay's submitter address as a public input that the application contract checks against `msg.sender`. +Split a typical zero-knowledge proof flow into two roles. The client signs a portable signed message offline. A relay generates the SNARK over that message and submits it on-chain. To prevent a front-runner from lifting the proof off the mempool and re-submitting it from their own address, the proof binds to the relay's submitter address as a public input that the application contract checks against `msg.sender`. The pattern is distinct from `pattern-safe-proof-delegation.md`, which addresses intent-based delegation in a wallet UX context (the client *could* prove locally but chooses to delegate). Relay-mediated proving is for clients that cannot prove locally at all. diff --git a/use-cases/private-registry.md b/use-cases/private-registry.md index af36fdd..6a8cec8 100644 --- a/use-cases/private-registry.md +++ b/use-cases/private-registry.md @@ -79,7 +79,7 @@ Approach TBD. Key architectural considerations: - How do privacy-preserving registries interact with existing registry legal frameworks (e.g., eWpG crypto-registry requirements)? - What is the minimum viable cross-border registry query protocol that satisfies both privacy and sovereignty requirements? - How to handle registry corrections (errors, court orders) in an append-only privacy-preserving system? -- What trust assumptions must registered entities make about the registry operator (liveness, censorship resistance, data availability, honest state transitions), and how can these be minimized or made verifiable? +- What trust assumptions must registered entities make about the registry operator (liveness, censorship resistance, Data Availability, honest state transitions), and how can these be minimized or made verifiable? ## 7) Notes And Links diff --git a/use-cases/resilient-identity-continuity.md b/use-cases/resilient-identity-continuity.md index 00d9ec3..e4e91d2 100644 --- a/use-cases/resilient-identity-continuity.md +++ b/use-cases/resilient-identity-continuity.md @@ -67,7 +67,7 @@ Key loss in issuer-independent systems is permanent unless recovery mechanisms e ### Problem 4: Universal Verification Without Registry or Issuer Contact -Verification in existing private identity systems often requires contacting a registry operator or issuer for revocation checks or credential status. In an issuer-hostile setting, verification must work with the on-chain trust anchor and a ZK proof, without external service calls. +Verification in existing private identity systems often requires contacting a registry operator or issuer for revocation checks or credential status. In an issuer-hostile setting, verification must work with the on-chain trust anchor and a zero-knowledge proof, without external service calls. **Requirements:** @@ -83,7 +83,7 @@ Verification in existing private identity systems often requires contacting a re | Credential anchoring | On-chain commitment via distributed enrollment | No issuer dependency after enrollment | | Sybil resistance | Layered (cryptographic + economic + social) | Degrades gracefully when credential sources are compromised | | Recovery | Threshold (Shamir) + social (guardian-based) | No issuer participation required | -| Verification | Universal (on-chain trust anchor + ZK proof) | Any verifier, no registry contact | +| Verification | Universal (on-chain trust anchor + zero-knowledge proof) | Any verifier, no registry contact | See the [**Issuer-Independent Enrollment approach**](../approaches/approach-private-identity.md#issuer-independent-enrollment-via-distributed-oprf) for detailed architecture and trade-offs. diff --git a/vendors/fairblock.md b/vendors/fairblock.md index 4d2f3a6..6c2de95 100644 --- a/vendors/fairblock.md +++ b/vendors/fairblock.md @@ -10,11 +10,11 @@ maturity: testnet Fairblock provides confidential balances and transfers for assets (e.g., stablecoins) that remain issued and liquid on an originating chain (e.g., EVM networks), while confidentiality logic executes on **FairyRing**, a purpose-built confidentiality execution layer. -The core idea is a cross-chain confidential layer: users lock tokens into a minimal smart contract on the originating chain, receive an encrypted balance maintained by FairyRing, and execute confidential transfers backed by ZK proofs and homomorphic balance updates, then optionally withdraw back to the originating chain. +The core idea is a cross-chain confidential layer: users lock tokens into a minimal smart contract on the originating chain, receive an encrypted balance maintained by FairyRing, and execute confidential transfers backed by zero-knowledge proofs and homomorphic balance updates, then optionally withdraw back to the originating chain. ## Fits with patterns -- [Selective disclosure (viewing keys + ZK proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md): scoped disclosure for audit and compliance workflows +- [Selective disclosure (viewing keys + zero-knowledge proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md): scoped disclosure for audit and compliance workflows ## Not a substitute for @@ -31,7 +31,7 @@ High-level components: - User-facing interface for deposit/transfer/withdraw flows 2. FairyRing: confidentiality execution layer - CosmWasm contracts maintain an encrypted chain - - Verifies ZK proofs for valid encrypted state transitions + - Verifies zero-knowledge proofs for valid encrypted state transitions - Performs lightweight homomorphic add/subtract for balance updates 3. Cross-chain messaging (IBC-style) - Relays packets between the origin chain and FairyRing @@ -61,7 +61,7 @@ FairyRing supports selective disclosure for audits and investigations via scoped ## Technical details - Cross-chain design connecting an origin chain locking contract with FairyRing as confidentiality layer -- Encrypted layer and ZK proof verification for valid state transitions +- Encrypted layer and zero-knowledge proof verification for valid state transitions - Lightweight homomorphic operations for balance updates - Threshold IBE for scoped selective disclosure diff --git a/vendors/fhenix.md b/vendors/fhenix.md index 2a502df..8593dc4 100644 --- a/vendors/fhenix.md +++ b/vendors/fhenix.md @@ -15,7 +15,7 @@ Fhenix builds a CoProcessor that brings Fully Homomorphic Encryption (FHE) to EV - [Private Stablecoin Shielded Payments](https://github.com/ethsystems/map/blob/master/patterns/pattern-private-stablecoin-shielded-payments.md) - FHE enables encrypted balances and amounts, supporting fully confidential stablecoin transfers. - [Private Intent-Based Vaults](https://github.com/ethsystems/map/blob/master/patterns/pattern-private-vaults.md) - FHE-powered execution allows vault strategies to run privately while preserving on-chain auditability of assets. - [Shielded ERC-20 Transfers](https://github.com/ethsystems/map/blob/master/patterns/pattern-shielding.md) - Native FHE support provides encrypted ERC-20 transfer flows for end-to-end confidentiality. -- [Confidential ERC3643](https://github.com/ethsystems/map/blob/master/patterns/pattern-erc3643-rwa.md) - FHE makes it possible to extend ERC3643 into a confidential standard with private, enforceable compliance logic. +- [Confidential ERC-3643](https://github.com/ethsystems/map/blob/master/patterns/pattern-erc3643-rwa.md) - FHE makes it possible to extend ERC-3643 into a confidential standard with private, enforceable compliance logic. - [Private L2s](https://github.com/ethsystems/map/blob/master/patterns/pattern-privacy-l2s.md) - Fhenix’s CoFHE serves as an FHE coprocessor enabling privacy-preserving rollups and encrypted execution environments. ## Not a substitute for @@ -29,7 +29,7 @@ CoFHE, Fhenix’s encrypted-computation coprocessor, enables smart contracts to ## Privacy domains -- FHE encryption at the contract and variable level. +- Fully Homomorphic Encryption at the contract and variable level. - Supports hybrid models (FHE + ZK for verification). ## Enterprise demand and use cases diff --git a/vendors/miden.md b/vendors/miden.md index dc0beaf..08cbe25 100644 --- a/vendors/miden.md +++ b/vendors/miden.md @@ -10,7 +10,7 @@ maturity: PoC Polygon Miden is a privacy focused Ethereum rollup (zk-zk-rollup) that prioritizes throughput and privacy over full EVM compatibility. It uses the Miden VM, a STARK-based virtual machine designed for client-side proving. -Unlike Ethereum (where the network executes everything), Miden pushes execution to the user (the "Edge"). Users execute their own transactions locally, generate a ZK proof, and the network simply verifies the proof and updates the state. +Unlike Ethereum (where the network executes everything), Miden pushes execution to the user (the "Edge"). Users execute their own transactions locally, generate a zero-knowledge proof, and the network simply verifies the proof and updates the state. ## Fits with patterns diff --git a/vendors/paladin.md b/vendors/paladin.md index 5b5f06a..384a947 100644 --- a/vendors/paladin.md +++ b/vendors/paladin.md @@ -40,12 +40,12 @@ A strong design principle of the project is that existing privacy preserving tok - UTXO-based privacy preserving tokens - FHE based confidential tokens (future plans) - Private EVM contracts in privacy groups -- Key management integrates with enterprise HSM/SSM; supports native Ethereum signing, EIP-712 endorsements, ZKP proof generation, as well as FHE wallet-side cryptography in future plans. +- Key management integrates with enterprise HSM/SSM; supports native Ethereum signing, EIP-712 endorsements, zero-knowledge proof generation, as well as FHE wallet-side cryptography in future plans. - Programming model includes plug points for: - Wallet functions (coin/state indexing and selection for submission) - Endorsement coordination and signature collection with flexible endorsement policies - Distributed sequencer for transaction coordination - - Proof generation (ZK proofs, notary certificates, and others) + - Proof generation (zero-knowledge proofs, notary certificates, and others) - High-performance code modules in Java and WebAssembly Privacy domains are implementations of a plug-point for the on-chain logic (pure on-chain EVM), and the app-layer logic (proof systems, merkle tree management, private EVM execution, endorsement/attestation coordination), that are the common components of every privacy-preserving smart contract in the EVM ecosystem. @@ -56,7 +56,7 @@ Hardened reference implementations are provided out of the box as follows: - Zeto (ZK UTXO tokens) - Onchain commitments hide ownership/amounts/history of the UTXOs. - - Enforces mass conservation and other spending policies (KYC, auditability, etc.) via ZK proofs. + - Enforces mass conservation and other spending policies (KYC, auditability, etc.) via zero-knowledge proofs. - Currently implemented with zkSNARKs in Circom based circuits, using groth16 by default. - Paladin runtime includes a token indexer, UTXO selector, and proof generator. - Optional ERC20 bridge via deposit/withdraw. @@ -85,7 +85,7 @@ Hardened reference implementations are provided out of the box as follows: - Transport principles: asynchronous message transfer, idempotent requests with retries, end-to-end encryption even via hubs/buses. - Approval-based atomic transactions (DvP/PvP) - Pre-approval/setup: parties reach a private state root; prepare token transfers. - - Approval/prepare: swap contract deployed; each domain pre-approves (privacy group endorsement, notary approval, ZK proof). + - Approval/prepare: swap contract deployed; each domain pre-approves (privacy group endorsement, notary approval, zero-knowledge proof). - Execution/commit: call execute() on the swap contract; all sub-transactions commit or revert atomically. - Post-execution: domains remain independent; provenance is hidden except to entitled parties. diff --git a/vendors/railgun.md b/vendors/railgun.md index b9535a9..88eb4ba 100644 --- a/vendors/railgun.md +++ b/vendors/railgun.md @@ -9,7 +9,7 @@ maturity: production ## What it is Railgun is a set of smart contracts providing **shielded transfers and private DeFi interactions** on Ethereum and other EVM-compatible chains. -It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers) that allows users to send, receive, and interact with DeFi protocols while hiding wallet balances and transaction details. +It uses zk-SNARKs to maintain a UTXO-like note system (commitments and nullifiers) that allows users to send, receive, and interact with DeFi protocols while hiding wallet balances and transaction details. ## Fits with patterns @@ -27,7 +27,7 @@ It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers ## Architecture - **Execution model**: UTXO-style commitments (`note commitments`, `nullifiers`) stored in smart contracts. -- **Proof system**: zkSNARKs (Groth16) validate note creation and spending. +- **Proof system**: zk-SNARKs (Groth16) validate note creation and spending. - **Settlement**: ERC-20/ERC-721/ERC-1155 tokens are deposited into Railgun contracts, converted to private notes, then spent/withdrawn. - **Integration**: Railgun “Adapt Modules” allow private interactions with existing DeFi protocols by wrapping function calls. - **Data availability**: all commitments stored publicly on-chain; privacy relies on zk proofs, not off-chain DA. @@ -46,7 +46,7 @@ It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers ## Technical details -- zkSNARK proving via Groth16, circuit for note validity and nullifier uniqueness. +- zk-SNARK proving via Groth16, circuit for note validity and nullifier uniqueness. - Smart contract architecture deployed on Ethereum mainnet, BNB Chain, Polygon, and others. - UTXO model: each note represents a claim on deposited tokens; nullifiers prevent double spends. - Adapt Modules: special contracts that wrap DeFi calls (e.g. swaps, lending) to preserve privacy of user identity. @@ -63,7 +63,7 @@ It uses zkSNARKs to maintain a UTXO-like note system (commitments and nullifiers - **No regulator-oriented audit path**: may limit institutional adoption. - **Prover costs & UX**: Groth16 proofs are relatively heavy for end-users, requiring wallet integration, high gas operations (~2m). - **On-chain DA**: all commitments are public; long-term scalability may be constrained. -- **Trust assumptions**: requires careful ceremony setup for zkSNARK parameters (trusted setup). +- **Trust assumptions**: requires careful ceremony setup for zk-SNARK parameters (trusted setup). ## Links diff --git a/vendors/renegade.md b/vendors/renegade.md index 50eea99..f659b6f 100644 --- a/vendors/renegade.md +++ b/vendors/renegade.md @@ -9,7 +9,7 @@ maturity: production ## What it is Renegade is a decentralized dark pool protocol for trading digital assets. -It combines **maliciously-secure MPC** (for private order matching) with **zkSNARK proofs** (for verifiable settlement), ensuring balances, orders, and trade history remain confidential while still settling on-chain. +It combines **maliciously-secure MPC** (for private order matching) with **zk-SNARK proofs** (for verifiable settlement), ensuring balances, orders, and trade history remain confidential while still settling on-chain. ## Fits with patterns @@ -28,7 +28,7 @@ It combines **maliciously-secure MPC** (for private order matching) with **zkSNA - **Wallet model**: Each trader has a private wallet committed on-chain (`C(W) = H(B||O||F||K||r)`), with balances and orders hidden. - **Key hierarchy**: Separate keys for root control, order matching, settlement, and viewing. Enables delegation without loss of custody. - **Order matching**: Performed in MPC clusters (SPDZ-style protocols), ensuring neither relayers nor counterparties learn each other’s hidden state. -- **Settlement**: MPC outputs are wrapped in a collaborative zkSNARK that proves correct matching. Settlement notes are encrypted under counterparties’ keys and appended to the global commitment tree. +- **Settlement**: MPC outputs are wrapped in a collaborative zk-SNARK that proves correct matching. Settlement notes are encrypted under counterparties’ keys and appended to the global commitment tree. - **Relayers**: Traders typically delegate matching to relayer clusters; relayers coordinate MPC handshakes but never see balances or order flow. ## Privacy domains @@ -47,7 +47,7 @@ It combines **maliciously-secure MPC** (for private order matching) with **zkSNA ## Technical details -- Proof system: zkSNARKs (Groth16-style collaborative proofs). +- Proof system: zk-SNARKs (Groth16-style collaborative proofs). - MPC protocols: maliciously-secure SPDZ variants for order matching. - Commitment scheme: Merkle trees for wallets and nullifiers. - Encrypted settlement notes bound to on-chain commitments. @@ -57,7 +57,7 @@ It combines **maliciously-secure MPC** (for private order matching) with **zkSNA - Eliminates MEV: no pre-trade or post-trade transparency. - Fully private balances and orders, unlike lit AMMs. -- On-chain verifiability via zkSNARK proofs. +- On-chain verifiability via zk-SNARK proofs. - Delegation model allows separation of custody, matching, and settlement. ## Risks and open questions diff --git a/vendors/space-and-time.md b/vendors/space-and-time.md index 89a4077..e14b39f 100644 --- a/vendors/space-and-time.md +++ b/vendors/space-and-time.md @@ -21,7 +21,7 @@ The proof can be verified by an EVM-compatible verifier contract, enabling downs ## Not a substitute for - Price-feed oracle networks (e.g., curated feeds + aggregation + publisher diversity) -- A general-purpose data availability layer (it proves query correctness; DA is a separate concern) +- A general-purpose Data Availability layer (it proves query correctness; DA is a separate concern) - Full identity/compliance policy engine (you can query compliance tables, but policy definition/enforcement is up to the app) - Not a programmable privacy rollup or App-chain (functions only as contracts on existing L1/L2) @@ -29,7 +29,7 @@ The proof can be verified by an EVM-compatible verifier contract, enabling downs ## Architecture - **Decentralized validator set holding tamperproof tables:** Indexed blockchain data (events, txns, balances, etc with block hashes as attestation source) as well as signed user/enterprise-loaded datasets are held by a global validator network that collectively updates commitments on each table (with BFT consensus and threshold signatures) as batches of new data are added. -- **Prover nodes:** When a contract or API issues a query, a prover executes the SQL and generates a ZK proof, then relays both to a relayer contract for verification and data callback to the client contract. This pipeline enables proofs for aggregate queries over tables with 1M+ rows in under one second. +- **Prover nodes:** When a contract or API issues a query, a prover executes the SQL and generates a zero-knowledge proof, then relays both to a relayer contract for verification and data callback to the client contract. This pipeline enables proofs for aggregate queries over tables with 1M+ rows in under one second. 1. **AST:** SQL is parsed into an AST and relational plan 2. **Witnesses:** The plan is executed to produce witness data 3. **Commitments:** Witnesses are committed using standard polynomial commitment schemes @@ -66,7 +66,7 @@ The proof can be verified by an EVM-compatible verifier contract, enabling downs ## Strengths - **Performance:** The protocol is designed to execute and prove analytical SQL queries over large datasets, including aggregate queries over 1M+ rows, in under one second (see [benchmarks](https://github.com/spaceandtimefdn/sxt-proof-of-sql#benchmarks)). It can aggregate over millions of rows of indexed data within Ethereum block time on a single NVIDIA T4 GPU. -- **Cryptographic integrity at scale:** Proof of SQL scales to return ZK proofs for queries against tables with hundreds of millions of rows of indexed events/transactions without consensus-style re-execution. +- **Cryptographic integrity at scale:** Proof of SQL scales to return zero-knowledge proofs for queries against tables with hundreds of millions of rows of indexed events/transactions without consensus-style re-execution. - **SQL-native developer experience:** Leverage a mature query model (joins, filters, aggregates) instead of bespoke onchain indexing logic. - **Composable with EVM apps: **Verified results can directly gate contract execution via onchain verifier + callback pattern. - **Works for both crypto-native and enterprise data:** Supports “join onchain + offchain” workflows (including pulling from attested sources like institutional portfolios).