diff --git a/vendors/aztec-l2.md b/vendors/aztec-l2.md deleted file mode 100644 index c901325..0000000 --- a/vendors/aztec-l2.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Vendor: Aztec Rollup" -status: draft -maturity: testnet ---- - -# Aztec - Aztec Rollup (privacy L2 with programmable zk circuits) - -## What it is - -Aztec is a zero-knowledge rollup on Ethereum that enables private transactions and programmable privacy. -It uses zkSNARKs (Plonk/Honk/Ultra) to batch transactions and supports a UTXO-style model with note commitments, enabling shielded transfers and private DeFi logic. - -## Fits with patterns (names only) - -- Pattern: Private ISO 20022 Messaging & Settlement -- Pattern: Shielded-Pool Atomic Swap (ZK-HTLC) -- Pattern: ZK Shielded Balances for Derivatives -- Pattern: Confidential ERC-20 (L2; ERC-7573) - -## Not a substitute for - -- Not a settlement rail across multiple L1s (atomic cross-chain DvP still requires zk-SPV or bridges). -- Does not provide field-level ISO message commitments (off-chain parsing still required). -- Not a compliance/audit orchestration layer (requires scoped keys or external disclosure service). - -## Architecture - -- **Execution model**: Hybrid account/UTXO system; user balances are represented as encrypted notes. -- **Proof system**: UltraPlonk-based zkSNARKs aggregate rollup state transitions. -- **DA model**: Rollup posts data to Ethereum L1 (currently calldata, migrating to EIP-4844 blobs). -- **Settlement**: ERC-20 tokens are wrapped into shielded Aztec assets. -- **Interoperability**: Contracts can enforce conditional transfers (similar to ERC-7573 semantics) while keeping values private. - -## Privacy domains - -- **Private transfers**: Default shielding of token amounts, counterparties hidden from public chain. -- **Selective disclosure**: Users can export viewing keys for auditors/regulators. -- **Programmable privacy**: Circuits allow private execution of DeFi-like logic (DEX, lending) within Aztec. - -## Enterprise demand and use cases - -- **Financial institutions**: private stablecoin transfers and settlement. -- **Asset managers**: confidential DeFi strategies and portfolio movements. -- **Corporate treasuries**: cross-border payments with regulatory audit but hidden competitive data. - -## Technical details - -- zkSNARKs: Plonkish proving system with efficient verifier contracts. -- UTXO commitments: notes with nullifiers prevent double spends. -- Supports account abstraction and smart contract programmability. -- Relayers (Aztec Connect) allow batching of private calls into existing Ethereum DeFi protocols. - -## Strengths - -- Strong privacy guarantees for transfers and balances. -- Native rollup scalability with Ethereum settlement finality. -- Programmable privacy circuits extend beyond simple shielded transfers. -- Mature research team with open-source infrastructure and audits. - -## Risks and open questions - -- Still not production ready; testnet only. -- No native cross-chain atomicity; needs zk-SPV or trusted bridges for multi-domain DvP. -- Block finality; still not compliant for high frequency operations. -- Key management and regulator disclosure processes not standardized. -- DA model (L1 blobs vs validium) impacts trust assumptions and compliance. - -## Links - -- [Aztec Docs](https://docs.aztec.network/) -- [Aztec GitHub](https://github.com/AztecProtocol) - - [Zk Backend](https://github.com/AztecProtocol/aztec-packages) -- [Aztec Medium: Rollup Architecture](https://medium.com/aztec-protocol) -- [Aztec Connect Overview](https://aztec.network/connect) diff --git a/vendors/aztec.md b/vendors/aztec.md new file mode 100644 index 0000000..7cca3cb --- /dev/null +++ b/vendors/aztec.md @@ -0,0 +1,76 @@ +--- +title: "Vendor: Aztec Rollup" +status: draft +maturity: production (Ignition Chain) +--- + +# Aztec - Privacy Rollup + +## What it is + +Aztec is a privacy focused rollup (or zk-zk-rollup) on Ethereum that enables private transactions and programmable privacy. Unlike its predecessor, it is a fully programmable network where applications can access both private and public state. + +It uses the **Noir** language to write zk circuits and enables a hybrid execution model: private functions execute client-side (for privacy), while public functions execute on the network (for transparency/auditability). + +## Fits with patterns + +- [pattern-noir-private-contracts.md](../patterns/pattern-noir-private-contracts.md) - Noir private smart contracts +- [pattern-privacy-l2s.md](../patterns/pattern-privacy-l2s.md) - Privacy-native rollup execution +- [pattern-zk-shielded-balances.md](../patterns/pattern-zk-shielded-balances.md) - Confidential balances for derivatives +- [pattern-shielding.md](../patterns/pattern-shielding.md) - Confidential ERC-20 transfers + +## Not a substitute for + +- Fully private EVM +- High througput but public rollups + +## Architecture + +- Hybrid State Model + - Private state (UTXO-based) is managed by the PXE (Private Execution Environment) on the user's device. + - Public state (Account-based) is managed by the AVM (Aztec Virtual Machine) on nodes. +- Smart contracts are written in [Noir](../patterns/pattern-noir-private-contracts.md). +- Proof system: Honk (UltraHonk) and UltraPlonk. Honk allows for fast recursion and removes the need for a trusted setup. +- DA model: Rollup posts data to Ethereum L1 using EIP-4844 Blobs. +- Settlement: Decentralized sequencer; L2 validity proofs are verified on Ethereum L1. + +## Privacy domains + +- **Private transfers**: Default shielding of token amounts, counterparties hidden from public chain. +- **Selective disclosure**: Users can export viewing keys for auditors/regulators. +- **Programmable privacy**: Circuits allow private execution of DeFi-like logic (DEX, lending) within Aztec. + +## Enterprise demand and use cases + +- Financial institutions: private stablecoin transfers and settlement. +- Asset managers: confidential DeFi strategies and portfolio movements. +- Corporate treasuries: cross-border payments with regulatory audit but hidden competitive data. + +## Technical details + +- zkSNARKs: Plonkish proving system with efficient verifier contracts. +- UTXO note commitments with nullifiers to prevent double spends. +- L1/L2 communication relies on "Portals". These are pairs of contracts (one on Ethereum L1, one on Aztec L2) that pass messages asynchronously via the rollup contract, enabling token bridges and cross-chain governance without trusted 3rd parties. +- Native account abstraction at the protocol level; all accounts are smart contracts. +- Decentralized sequencer (Fernet), block production uses a randomized leader election (VRF-based) to select sequencers, ensuring fair participation. It includes a Based Fallback mechanism, allowing users to submit transactions directly to L1 if the L2 sequencers attempt to censor them. + +## Strengths + +- Strong privacy guarantees for transfers and balances. +- Programmable privacy circuits extend beyond simple shielded transfers. +- Mature research team with open-source infrastructure and audits. + +## Risks and open questions + +- State Synchronization, users must download and trial-decrypt note history to discover their funds (cannot simply query a balance). Wallets must actively track, discover, and consume Notes, creating sync bottlenecks compared to public L2s. +- Client-Side Proving, private execution requires local proof generation (via PXE), demanding significant compute resources for end users. +- Compliance vs. Permissionlessness, While "Selective Disclosure" exists, it is unclear if regulators will accept retroactive auditing over proactive censorship (e.g., OFAC lists at the sequencer level). +- Performances, this system requires a lot of engineering at the cost of a lower throughput, raising the question of use cases that it could tackle. + +## Links + +- [Aztec Docs](https://docs.aztec.network/) +- [Aztec GitHub](https://github.com/AztecProtocol) + - [Zk Backend](https://github.com/AztecProtocol/aztec-packages) +- [Aztec Medium: Rollup Architecture](https://medium.com/aztec-protocol) +- [Aztec Connect Overview](https://aztec.network/connect) diff --git a/vendors/miden.md b/vendors/miden.md new file mode 100644 index 0000000..4f6b899 --- /dev/null +++ b/vendors/miden.md @@ -0,0 +1,80 @@ +--- +title: "Vendor/Pattern: Miden" +status: draft +maturity: PoC +--- + +# Miden – Privacy Rollup + +## What it is + +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. + +## Fits with patterns + +- [pattern-zk-shielded-balances.md](../patterns/pattern-zk-shielded-balances.md) - Confidential balances for derivatives +- [pattern-private-iso20022.md](../patterns/pattern-private-iso20022.md) - Private messaging & settlement +- [pattern-privacy-l2s.md](../patterns/pattern-privacy-l2s.md) - Privacy-native rollup execution + +## Not a substitute for + +- Fully private EVM +- High througput but public rollups + +## Architecture + +- Execution model: Actor Model (Concurrent). Unlike the EVM (sequential global state), every `Account` and `Note` is an isolated "Actor" with a local state. Transactions between independent accounts can be executed and proven in parallel, as they don't require locking shared global state. +- Hybrid State Model + - Accounts hold persistent state (like a wallet or DeFi pool). + - Notes (UTXOs) carry assets and scripts between accounts. +- Smart contracts are written in Rust (compiling to Miden Assembly/MASM). +- Proof system: zk-STARKs (via Winterfell). Quantum-secure, transparent (no trusted setup), and optimized for recursion. +- DA model: Rollup posts data to Ethereum L1 (utilizing EIP-4844 blobs). +- Settlement: L2 validity proofs are verified on Ethereum L1. + +## Privacy domains + +- **Private transfers**: Default shielding of token amounts, counterparties hidden from public chain. +- **Programmable confidentiality**: Hybrid model enables both public and private state. +- **Client-side execution**: Users execute transactions locally and submit proofs, keeping transaction details private from public but efficiently provable. + +## Enterprise demand and use cases + +- Financial institutions: private stablecoin transfers and settlement. +- Asset managers: confidential DeFi strategies and portfolio movements. +- Corporate treasuries: cross-border payments with regulatory audit but hidden competitive data. + +## Technical details + +- A "transfer" is creating a Note. The recipient must execute a transaction to "consume" the Note. Notes carry their own scripts (e.g., "Only consumable if Oracle X says price > $100"). +- The user _is_ the prover, from its own client or through delegated proving. This allows for infinite horizontal scaling because the network does not re-execute complex logic, it only verifies the proof. +- A high-performance STARK prover (Winterfell) used to generate proofs for the Miden VM. +- L1/L2 communication bridging still to be defined. +- Native account abstraction at the protocol level; accounts are smart contracts with updatable code. +- Because users generate the proofs, the Sequencer is lightweight—it only aggregates proofs and builds blocks, preventing the "bottleneck" seen in EVM rollups. + +## Strengths + +- Massive Concurrency: Parallel transaction processing prevents "gas wars" between unrelated apps, resulting in privacy with high throughput. +- Privacy by Design: Local execution naturally hides user data without complex "add-on" privacy mixers. +- Quantum Security: Relies on hash-based STARKs. + +## Risks and open questions + +- Audit/Disclosure, path for regulators still unclear. +- Developer Friction, high learning curve (Rust/MASM + Actor model vs. Solidity/EVM). +- Data Availability, if a user loses their private local state (and didn't back it up), they may lose access to their Private Account. +- Wallet Complexity, Wallets must be "smart" enough to track, discover, and consume Notes automatically for a good UX. Client-side proving requires either local compute resources or delegation to a proving service. + +## Links + +- [Polygon Miden Docs](https://docs.polygon.technology/miden/) +- [Miden Book (alt docs hub)](https://0xMiden.github.io/miden-docs/) +- [Polygon Miden GitHub org](https://github.com/0xMiden) +- [miden-base (core components)](https://github.com/0xMiden/miden-base) +- [crypto (hashes & primitives)](https://github.com/0xMiden/crypto) +- [Note Types (public/private/encrypted)](https://docs.polygon.technology/learn/miden/note_types/) +- [Polygon Miden Alpha Testnet v6 blog](https://blog.polygon.technology/polygon-miden-alpha-testnet-v6-is-live/) +- [Awesome Miden (community resources)](https://github.com/phklive/awesome-miden) diff --git a/vendors/polygon-miden.md b/vendors/polygon-miden.md deleted file mode 100644 index 95d7c81..0000000 --- a/vendors/polygon-miden.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Vendor/Pattern: Polygon Miden" -status: draft -maturity: PoC ---- - -# Polygon Miden – STARK-based VM / Privacy & Prover Infrastructure - -## What it is - -Polygon Miden is a zero-knowledge-focused virtual machine / blockchain stack that supports provable state transitions, private notes, and Rust-based contracts compiled to run in a STARK-friendly VM. -It aims to scale privacy and programmability together, allowing verifiable computation in a trust-minimal, scalable way. - -## Fits with patterns (names only) - -- Pattern: ZK Shielded Balances for Derivatives -- Pattern: Private ISO 20022 Messaging & Settlement -- Pattern: zk-SPV (cross-chain atomicity) -- Pattern: Confidential ERC-20 (Private L2s) - -## Not a substitute for - -- Not a shielded-pool rail _per se_ (unless privacy note infrastructure is used for value shielding). -- Not a ready drop-in private stablecoin or ERC-20 token privacy layer (needs token/shielded note support). -- Not a full cross-chain DvP on its own (bridging + finality proofs still needed). - -## Architecture - -- **VM model**: STARK-based VM with a “transaction kernel” model, Rust compiler output, private notes as part of the state. -- **Prover system**: Uses STARKs & efficient hash functions tuned for their VM (see “XHash,” “Polygon Miden VM / Asset Model”). -- **Privacy features**: - - - Private notes (assets/state hidden from public view). - - Multi-sig and custom logic supported in Rust contracts. - - Amount hiding and account privacy depend on how notes are used. - -- **Infrastructure**: Testnet live (Alpha v6); roadmap includes private note UX, multi-sig, and extended proving infra. - -## Privacy domains - -- **Private state changes**: private notes enable selective hidden state. -- **Programmable confidentiality**: Rust contracts + note abstraction. -- **Audit / disclosure**: potential via note keys; regulator access not yet formally defined. - -## Enterprise demand and use cases - -- Developers building privacy-aware smart contracts with STARK performance. -- Confidential asset flows, private transaction kernels, financial logic requiring hidden state. -- Candidate for institutional settlement rails if token models + governance are aligned. - -## Technical details - -- Supports private/public/encrypted note types. -- STARK-friendly primitives (e.g. XHash). -- Rust → Miden assembler compilation pipeline. -- Data availability: follows Polygon L2 DA design (Ethereum DA for rollup, alt DA for validium/volition). - -## Strengths - -- Strong STARK foundation: scalable, transparent setup. -- Flexible VM with Rust programmability. -- Private notes for asset/state confidentiality. -- Actively developed, testnet live with growing dev resources. - -## Risks and open questions - -- Token privacy not yet standardized (how ERC-20s map to notes). -- Audit/disclosure path for regulators still unclear. -- Wallet UX for note discovery/spending immature. -- Cross-chain atomicity still requires bridging (zk-SPV or similar). -- Prover costs/latency in production TBD. - -## Links - -- [Polygon Miden Docs](https://docs.polygon.technology/miden/) -- [Miden Book (alt docs hub)](https://0xMiden.github.io/miden-docs/) -- [Polygon Miden GitHub org](https://github.com/0xMiden) -- [miden-base (core components)](https://github.com/0xMiden/miden-base) -- [crypto (hashes & primitives)](https://github.com/0xMiden/crypto) -- [Note Types (public/private/encrypted)](https://docs.polygon.technology/learn/miden/note_types/) -- [Polygon Miden Alpha Testnet v6 blog](https://blog.polygon.technology/polygon-miden-alpha-testnet-v6-is-live/) -- [Awesome Miden (community resources)](https://github.com/phklive/awesome-miden)