feat: misc privacy rollups

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)

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)