From 1deb610a6360acdddc4223ed497f3a6de89c7375 Mon Sep 17 00:00:00 2001 From: Meyanis95 <67648863+Meyanis95@users.noreply.github.com> Date: Wed, 25 Feb 2026 15:18:27 +0100 Subject: [PATCH] Revert "feat(vendors): add EY starlight (#87)" This reverts commit 413df4e028b424e1b7a377af62bebdfd4b26708b. --- CHANGELOG.md | 2 +- approaches/approach-private-broadcasting.md | 2 +- vendors/ey-nightfall.md | 62 +++++++++ vendors/ey.md | 134 -------------------- 4 files changed, 64 insertions(+), 136 deletions(-) create mode 100644 vendors/ey-nightfall.md delete mode 100644 vendors/ey.md diff --git a/CHANGELOG.md b/CHANGELOG.md index 6975733..b84ea4f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,7 +5,7 @@ All notable changes to the IPTF Map are documented here. ## [Unreleased] ### Added -- feat(pattern): [EY: Starlight](vendors/ey.md#starlight) - Solidity transpiler for private on-chain state. Consolidated EY products into a single vendor file. + - feat(pattern): [Network-Level Anonymity](patterns/pattern-network-anonymity.md) - Umbrella pattern for transport-layer sender anonymity (Tor, mixnets, private RPC, TEE-assisted, VPN) - feat(pattern): [TEE-Assisted Network Anonymity](patterns/pattern-tee-network-anonymity.md) - TEE+secret-sharing approach for low-latency sender anonymity (Flashbots Flashnet) - feat(pattern): [Private Shared State](patterns/pattern-private-shared-state.md) - Umbrella pattern for multi-party private state (FHE, MPC+ZK, TEE comparison) diff --git a/approaches/approach-private-broadcasting.md b/approaches/approach-private-broadcasting.md index 9172607..e6a0c77 100644 --- a/approaches/approach-private-broadcasting.md +++ b/approaches/approach-private-broadcasting.md @@ -47,7 +47,7 @@ These problems interact because traditional broadcasting requires public visibil - Hidden state with encrypted mempool - 2 categories: - Shared [Private Rollups](../patterns/pattern-privacy-l2s.md) (Aztec, Fhenix) - - Enterprise Rollups: [ZKsync Prividium](../vendors/zksync-prividium.md), [EY Nightfall](../vendors/ey.md#nightfall-v4) + - Enterprise Rollups: [ZKsync Prividium](../vendors/zksync-prividium.md), [EY Nightfall](../vendors/ey-nightfall.md) ### Recommended Architecture diff --git a/vendors/ey-nightfall.md b/vendors/ey-nightfall.md new file mode 100644 index 0000000..00e5043 --- /dev/null +++ b/vendors/ey-nightfall.md @@ -0,0 +1,62 @@ +--- +title: "Vendor: EY Nightfall" +status: production +--- + +# EY - Nightfall v4 (Enterprise Privacy Rollup) + +## What it is + +A production-ready Zero-Knowledge rollup for private token transfers with enterprise compliance features. Nightfall v4 implements a ZK rollup that provides immediate finality and supports ERC20, ERC721, ERC1155, and ERC3525 tokens with X509 certificate-based access control. + +## Fits with patterns + +- Private Stablecoin Shielded Payments +- Privacy L2s +- Regulatory Disclosure Keys Proofs +- Private ISO20022 + +## Not a substitute for + +- General-purpose privacy L2s (focused on enterprise transfers) +- Public DeFi composability (limited composability by design) +- Low-resource deployment environments (requires significant compute) + +## Architecture + +Client-Proposer model with separate containerized roles. Clients generate UltraPlonk proofs for private transactions and submit to Proposers who create Layer 2 blocks with rollup proofs. X509 certificate validation gates all network access. Uses commitment-nullifier privacy model (UTXO-style) with MongoDB storage for metadata and Merkle tree state. Supports webhook integration for asynchronous processing. + +## Privacy domains (if applicable) + +- Certificate-gated private transfers with immediate ZK rollup finality +- Selective disclosure for regulatory compliance and audit trails +- Enterprise treasury operations with confidential payment flows + +## Enterprise demand and use cases + +Target segments include multinational corporations, financial institutions + +## Technical details + +- UltraPlonk proof system with no per-circuit trusted setup +- supporting ERC20/721/1155/3525 standards +- RESTful APIs for deposit, transfer, withdraw operations with X-Request-ID tracking +- Integration with LocalWallet, AzureWallet, and HSM for enterprise key management +- Sophisticated chain reorganization handling and immediate finality from ZK rollup architecture. + +## Strengths + +- Production-ready with mature ZK technology and enterprise compliance features +- Advanced cryptography using UltraPlonk proofs eliminating trusted setup requirements +- Built-in X509 certificate validation and selective disclosure for regulatory compliance +- Immediate finality from pure ZK rollup architecture (no optimistic challenge periods) + +## Risks and open questions + +- Extremely high compute requirements (144 cores, 750GB RAM) limit proposer decentralization +- Complex infrastructure requirements may limit deployment scenarios +- Limited composability compared to general-purpose privacy L2s + +## Links + +- [Nightfall v4 GitHub](https://github.com/EYBlockchain/nightfall_4_CE) diff --git a/vendors/ey.md b/vendors/ey.md deleted file mode 100644 index a73d4b3..0000000 --- a/vendors/ey.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: "Vendor: EY" -status: production ---- - -# EY (Enterprise Privacy Stack) - -## Nightfall v4 - -### What it is - -A production-ready Zero-Knowledge rollup for private token transfers with enterprise compliance features. Nightfall v4 implements a ZK rollup that provides immediate finality and supports ERC20, ERC721, ERC1155, and ERC3525 tokens with X509 certificate-based access control. - -### Fits with patterns - -- Private Stablecoin Shielded Payments -- Privacy L2s -- Regulatory Disclosure Keys Proofs -- Private ISO20022 - -### Not a substitute for - -- General-purpose privacy L2s (focused on enterprise transfers) -- Public DeFi composability (limited composability by design) -- Low-resource deployment environments (requires significant compute) - -### Architecture - -Client-Proposer model with separate containerized roles. Clients generate UltraPlonk proofs for private transactions and submit to Proposers who create Layer 2 blocks with rollup proofs. X509 certificate validation gates all network access. Uses commitment-nullifier privacy model (UTXO-style) with MongoDB storage for metadata and Merkle tree state. Supports webhook integration for asynchronous processing. - -### Privacy domains - -- Certificate-gated private transfers with immediate ZK rollup finality -- Selective disclosure for regulatory compliance and audit trails -- Enterprise treasury operations with confidential payment flows - -### Enterprise demand and use cases - -Target segments include multinational corporations, financial institutions - -### Technical details - -- UltraPlonk proof system with no per-circuit trusted setup -- supporting ERC20/721/1155/3525 standards -- RESTful APIs for deposit, transfer, withdraw operations with X-Request-ID tracking -- Integration with LocalWallet, AzureWallet, and HSM for enterprise key management -- Sophisticated chain reorganization handling and immediate finality from ZK rollup architecture. - -### Strengths - -- Production-ready with mature ZK technology and enterprise compliance features -- Advanced cryptography using UltraPlonk proofs eliminating trusted setup requirements -- Built-in X509 certificate validation and selective disclosure for regulatory compliance -- Immediate finality from pure ZK rollup architecture (no optimistic challenge periods) - -### Risks and open questions - -- Extremely high compute requirements (144 cores, 750GB RAM) limit proposer decentralization -- Complex infrastructure requirements may limit deployment scenarios -- Limited composability compared to general-purpose privacy L2s - -### Links - -- [Nightfall v4 GitHub](https://github.com/EYBlockchain/nightfall_4_CE) - -## Starlight - -### What it is - -Starlight is an open-source transpiler that converts standard Solidity smart contracts into zero-knowledge applications (zApps). Developers annotate Solidity code with privacy decorators (a superset called "Zolidity"), and the compiler generates ZK circuits, on-chain verifier contracts, and JavaScript orchestration code; enabling private business logic on public Ethereum without requiring deep cryptographic expertise. - -### Fits with patterns - -- [Shielded ERC-20 Transfers](../patterns/pattern-shielding.md): enables building shielding-type circuits from Solidity, not a drop-in shielded pool -- [Private Shared State](../patterns/pattern-private-shared-state.md): two-party shared secret commitments via `sharedSecret` decorator -- [L1 ZK Commitment Pool](../patterns/pattern-l1-zk-commitment-pool.md): generated contracts deploy commitment pools with nullifier tracking on L1 - -### Not a substitute for - -- **Private transaction rollups:** Starlight privatises business logic at the contract level but does not provide network-level transaction privacy or a private execution environment (see [Nightfall v4](#nightfall-v4) or [Aztec](aztec.md)) -- **Production-grade ZK infrastructure:** output zApps use Groth16 with known malleability caveats; no security audit has been completed; a trusted setup is required per circuit -- **Regulatory disclosure infrastructure:** no built-in viewing keys, selective disclosure, or compliance hooks; institutions must layer these separately (see [pattern-regulatory-disclosure-keys-proofs.md](../patterns/pattern-regulatory-disclosure-keys-proofs.md)) -- **Full Solidity feature parity:** not all Solidity syntax transpiles; complex control flow, certain if-statement patterns, and loops may not be supported - -### Architecture - -Developers write `.zol` files (Solidity + decorators: `secret`, `known`/`unknown`, `encrypt`, `sharedSecret`, `re-initialisable`) and run `zappify`. The transpiler parses the decorated AST via `solc`, then generates: - -- **ZoKrates circuits:** (`.zok`) for zero-knowledge proof generation (Groth16) -- **Solidity verifier contracts:** (`.sol`) for on-chain proof verification and commitment management - -Secret state lives on-chain as cryptographic hash commitments; pre-image data stays local with the owner. Nullifiers prevent double-spending; Merkle trees provide membership proofs. - -### Privacy domains - -- **Single-party private state:** secret variables owned by one party; on-chain commitments hide values from all others -- **Two-party shared secrets:** `sharedSecret` decorator enables bilateral state (e.g. atomic swaps) where both parties share a derived key -- **No native selective disclosure:** Starlight does not provide viewing keys or regulator access mechanisms at the compiler level - -### Enterprise demand and use cases - -- **B2B contract management:** multi-party business agreements where logic must be shared but commercial terms remain confidential (procurement, supply-chain) -- **Inventory and payment management:** large-scale asset tracking with privacy from competitors, combined with Nightfall for token transfers -- **Prototyping and education:** lowest-friction path to demonstrating ZK-private business logic for organisations evaluating privacy on Ethereum -- **Target segment:** organisations migrating complex B2B agreements from private EDI systems to public Ethereum; Solidity-proficient teams wanting to explore ZK without circuit expertise - -### Technical details - -- **Proof system**: Groth16 (via ZoKrates); requires per-circuit trusted setup -- **Circuit language**: ZoKrates DSL (generated, not hand-written) -- **State model**: Cryptographic hash commitments; nullifiers for spend tracking; Merkle tree for membership proofs - -### Strengths - -- **Low barrier to entry:** Solidity developers add privacy via decorators without learning circuit DSLs; contrast with Noir/Circom which require new languages -- **End-to-end code generation:** single `zappify` command produces circuits, contracts, and orchestration; reduces manual wiring errors -- **Public domain:** no licensing constraints; enterprises can fork and customise freely - -### Risks and open questions - -- **No security audit:** EY explicitly warns against use for material-value transactions; the project is labelled "experimental prototype still under development" -- **Trusted setup per circuit:** each generated circuit requires a separate Groth16 trusted setup ceremony; business logic changes require new ceremonies and state migration with no documented upgrade path -- **JavaScript integer precision:** uint256 values silently lose precision if not handled with BigInt; for 18-decimal tokens this caps correct handling at ~9,007 tokens -- **Limited Solidity coverage:** not all Solidity syntax transpiles; complex conditionals, loops, and certain patterns are unsupported (see [STATUS.md](https://github.com/EYBlockchain/starlight/blob/master/doc/STATUS.md)) -- **No native regulatory disclosure:** no built-in viewing keys, selective disclosure, or compliance screening hooks; institutions must build or source these separately - -### Links - -- [GitHub Repository](https://github.com/EYBlockchain/starlight) -- [Starlight Gitbook Documentation](https://starlight-3.gitbook.io/starlight) -- [EY Blockchain Technology Overview](https://blockchain.ey.com/technology) -- [EY Press Release: Starlight Beta (Feb 2023)](https://www.prnewswire.com/news-releases/ey-contributes-the-beta-version-of-zero-knowledge-proof-compiler-starlight-to-the-public-domain-to-enable-secure-private-business-logic-on-ethereum-301745741.html) -- [ETHGlobal Talk: Intro to Starlight](https://ethglobal.com/talks/ey-intro-to-starlight-siv8b) -- [Technical Writeup (WRITEUP.md)](https://github.com/EYBlockchain/starlight/blob/master/doc/WRITEUP.md)