From 0a8e58b59a9f853b2363462f3c76f71fa61ef0ce Mon Sep 17 00:00:00 2001 From: Meyanis95 Date: Wed, 3 Dec 2025 14:41:38 -0500 Subject: [PATCH 1/4] feat: updated aztec --- vendors/aztec-l2.md | 44 +++++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/vendors/aztec-l2.md b/vendors/aztec-l2.md index c901325..38a6db5 100644 --- a/vendors/aztec-l2.md +++ b/vendors/aztec-l2.md @@ -1,36 +1,39 @@ --- title: "Vendor: Aztec Rollup" status: draft -maturity: testnet +maturity: production (Ignition Chain) --- # 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. +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. -## Fits with patterns (names only) +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). -- 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) +## 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 -- 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). +- Private EVM equivalent +- Multi-chain atomic settlement (requires bridge infrastructure or zk-SPV for cross-L2 DvP) +- Production-grade institutional custody (testnet maturity, key management standards still evolving) ## 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. +- 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 @@ -47,20 +50,19 @@ It uses zkSNARKs (Plonk/Honk/Ultra) to batch transactions and supports a UTXO-st ## 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. +- 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. -- 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. From 6504be5affd43787828c253d0e55ab0348da41dc Mon Sep 17 00:00:00 2001 From: Meyanis95 Date: Wed, 3 Dec 2025 18:32:35 -0500 Subject: [PATCH 2/4] feat: miden's update --- vendors/aztec-l2.md | 21 ++++++------ vendors/polygon-miden.md | 74 +++++++++++++++++++--------------------- 2 files changed, 46 insertions(+), 49 deletions(-) diff --git a/vendors/aztec-l2.md b/vendors/aztec-l2.md index 38a6db5..ea772f6 100644 --- a/vendors/aztec-l2.md +++ b/vendors/aztec-l2.md @@ -4,7 +4,7 @@ status: draft maturity: production (Ignition Chain) --- -# Aztec - Aztec Rollup (privacy L2 with programmable zk circuits) +# Aztec - Privacy Rollup ## What it is @@ -21,9 +21,8 @@ It uses the **Noir** language to write zk circuits and enables a hybrid executio ## Not a substitute for -- Private EVM equivalent -- Multi-chain atomic settlement (requires bridge infrastructure or zk-SPV for cross-L2 DvP) -- Production-grade institutional custody (testnet maturity, key management standards still evolving) +- Fully private EVM +- High througput but public rollups ## Architecture @@ -43,9 +42,9 @@ It uses the **Noir** language to write zk circuits and enables a hybrid executio ## 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. +- 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 @@ -63,10 +62,10 @@ It uses the **Noir** language to write zk circuits and enables a hybrid executio ## Risks and open questions -- 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. +- Wallet Complexity, wallets must be "smart" enough to track, discover, and consume Notes automatically for a good UX. As well as being powerful enough to perform the proving locally. +- State Synchronization ("Note Discovery"), users cannot just query a balance; they must download and trial-decrypt the chain's note history to find their funds. This creates a significant syncing bottleneck compared to public L2s. +- 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 now. ## Links diff --git a/vendors/polygon-miden.md b/vendors/polygon-miden.md index 95d7c81..b763006 100644 --- a/vendors/polygon-miden.md +++ b/vendors/polygon-miden.md @@ -1,74 +1,72 @@ --- -title: "Vendor/Pattern: Polygon Miden" +title: "Vendor/Pattern: Miden" status: draft maturity: PoC --- -# Polygon Miden – STARK-based VM / Privacy & Prover Infrastructure +# Miden – Privacy Rollup ## 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. +Polygon Miden is a 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. -## Fits with patterns (names only) +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. -- Pattern: ZK Shielded Balances for Derivatives -- Pattern: Private ISO 20022 Messaging & Settlement -- Pattern: zk-SPV (cross-chain atomicity) -- Pattern: Confidential ERC-20 (Private L2s) +## 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 -- 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). +- Fully private EVM +- High througput but public rollups ## 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. +- Execution model: Actor Model (Concurrent). Unlike the EVM (sequential), every Account and Note is an isolated "Actor" that can be processed in parallel. +- 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 state changes**: private notes enable selective hidden state. -- **Programmable confidentiality**: Rust contracts + note abstraction. +- **Programmable confidentiality**: Hybrid model enables both public and private state. - **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. +- 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 -- 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). +- 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"). +- Client-Side Proving: The user _is_ the prover. 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 handles assets by locking funds in an L1 contract and minting a corresponding Note on L2 (and vice versa). +- 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 -- 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. +- 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 -- 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. +- 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. As well as being powerful enough to perform the proving locally. ## Links From 5b44b221ae437a361d7e1f55ad854b7904feee5b Mon Sep 17 00:00:00 2001 From: Meyanis95 Date: Wed, 3 Dec 2025 18:33:09 -0500 Subject: [PATCH 3/4] chore: fixing names --- vendors/{aztec-l2.md => aztec.md} | 0 vendors/{polygon-miden.md => miden.md} | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename vendors/{aztec-l2.md => aztec.md} (100%) rename vendors/{polygon-miden.md => miden.md} (100%) diff --git a/vendors/aztec-l2.md b/vendors/aztec.md similarity index 100% rename from vendors/aztec-l2.md rename to vendors/aztec.md diff --git a/vendors/polygon-miden.md b/vendors/miden.md similarity index 100% rename from vendors/polygon-miden.md rename to vendors/miden.md From bb624a6d998cb9ac87bbd60c2f6c05fd34ee5462 Mon Sep 17 00:00:00 2001 From: Meyanis95 Date: Fri, 5 Dec 2025 12:24:16 +0100 Subject: [PATCH 4/4] feat: sharpening points --- vendors/aztec.md | 6 +++--- vendors/miden.md | 14 +++++++------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/vendors/aztec.md b/vendors/aztec.md index ea772f6..7cca3cb 100644 --- a/vendors/aztec.md +++ b/vendors/aztec.md @@ -62,10 +62,10 @@ It uses the **Noir** language to write zk circuits and enables a hybrid executio ## Risks and open questions -- Wallet Complexity, wallets must be "smart" enough to track, discover, and consume Notes automatically for a good UX. As well as being powerful enough to perform the proving locally. -- State Synchronization ("Note Discovery"), users cannot just query a balance; they must download and trial-decrypt the chain's note history to find their funds. This creates a significant syncing bottleneck compared to public L2s. +- 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 now. +- 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 diff --git a/vendors/miden.md b/vendors/miden.md index b763006..4f6b899 100644 --- a/vendors/miden.md +++ b/vendors/miden.md @@ -8,7 +8,7 @@ maturity: PoC ## What it is -Polygon Miden is a 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. +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. @@ -25,7 +25,7 @@ Unlike Ethereum (where the network executes everything), Miden pushes execution ## Architecture -- Execution model: Actor Model (Concurrent). Unlike the EVM (sequential), every Account and Note is an isolated "Actor" that can be processed in parallel. +- 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. @@ -36,9 +36,9 @@ Unlike Ethereum (where the network executes everything), Miden pushes execution ## Privacy domains -- **Private state changes**: private notes enable selective hidden state. +- **Private transfers**: Default shielding of token amounts, counterparties hidden from public chain. - **Programmable confidentiality**: Hybrid model enables both public and private state. -- **Audit / disclosure**: potential via note keys; regulator access not yet formally defined. +- **Client-side execution**: Users execute transactions locally and submit proofs, keeping transaction details private from public but efficiently provable. ## Enterprise demand and use cases @@ -49,9 +49,9 @@ Unlike Ethereum (where the network executes everything), Miden pushes execution ## 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"). -- Client-Side Proving: The user _is_ the prover. This allows for infinite horizontal scaling because the network does not re-execute complex logic, it only verifies the proof. +- 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 handles assets by locking funds in an L1 contract and minting a corresponding Note on L2 (and vice versa). +- 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. @@ -66,7 +66,7 @@ Unlike Ethereum (where the network executes everything), Miden pushes execution - 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. As well as being powerful enough to perform the proving locally. +- 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