# Privacy L2 Analysis Table (PoC)

> This table is meant to answer institutions' questions reagrding privacy L2 solutions, we've indenitfied that it's hard to compare them in terms of throughput, security and censorship-resistance. This document is a Proof-Of-Concept that we want to design with the help of L2 teams.

### 1. ⚙️ Performance & Cost

| Metric | Detail (What is Measured) | Key Consideration (Discrete Metrics) |
| :--- | :--- | :--- |
| **Maximum Throughput (Max TPS)** | *Maximum sustained Transactions Per Second (TPS) supported by the L2.* | **Max theoretical TPS** for [Simple Value Transfer](#Simple-Value-Transfer).<br> **Tested Peak TPS** (must provide link to the benchmark) <br> *If applicable, report both $\text{TPS}_{Public}$ and $\text{TPS}_{Private}$* |
| **Transaction Cost** | *The total cost paid by the user per L2 transaction.* | **Gas Usage:** Report in `L1 gas units` + `L2 gas units` for [Simple Value Transfer](#Simple-Value-Transfer). |
| **Bridging & Exit Costs** | *The total cost of moving assets between L1 <-> L2.* | **L2 → L1 Withdrawal cost:** Gas units for canonical bridging. <br>**Forced Exit to L1:** cost in gas units. |
| **Economic Finality Time** | *The time required for a transaction to be included in a proof and validated on L1.* | `Soft Finality Time` (instant L2 inclusion), `Hard Finality Time` (Time until L1 Commitment + Proof Verification), `Challenge Period Duration` |
| **Transaction Information Retrieval** | *The bandwidth/time for a user to retrieve their incoming funds* | **Sync Mechanism:** `Trial decryption`, `Detection Keys/Tags`, `Server-side filtering`.<br> **Sync Speed:** e.g., "time to sync 10k blocks on client" |

### 2. 🛡️ Privacy & Data Availability (DA)

| Metric | Detail (What is Measured) | Key Consideration (Discrete Metrics) |
| :--- | :--- | :--- |
| **Level of Privacy** | *The scope of information hidden from public view.* | **Visibility:** Who can see what. What: `Balance`, `Sender`/`Receiver` identities, `Amount`, `Code`/`Function execution`, `Contract Bytecode`. Who: `Public`, `Sequencer`, `Prover` |
| **DA Layer*** | *Where the data required to reconstruct the L2 state is posted.* | **DA Destination**: `Ethereum L1 Call Data`, `L1 Data Blobs (EIP-4844)`, or `External DA Committee (DAC)` |
| **Trust Assumption for DA*** | *The set of parties the user must trust to access their data.* | **Trust Level**: `Trustless/Secured by L1` (Ethereum validators), `Trusted DAC` (external parties). |
| **Type of Data Posted to L1*** | *What information is broadcast to L1 for state verification.* | **Transparency**: `Full Transaction Data`, `State Diff` vs. Validity Proof Only |
| **Compliance/Auditing Features** | *Mechanisms for optional selective disclosure of private data for regulatory or auditing purposes.* | **Disclosure Mechanism**: `Incoming Viewing Key`, `Outgoing Viewing Key`, `Full History Viewing Key`. |
| **Privacy Trust Model** | *The fundamental guarantee of privacy* | **Base**: `Cryptographic (Math)`, `Threshold (MPC/FHE - Honest Majority)`. **Collusion Threshold:** How many actors must collude to break privacy? (e.g., "m-of-n") |
| **Network Privacy** | *Protection of metadata at the transport layer* | **RPC privacy**: Is there any way to privately query a RPC node? (e.g., `Tor/I2P support`, `Oblivious HTTP`, `Mixnet`, ...) |

*`*` L2Beat direct match*

### 3. ⚖️ Security & Governance

| Metric | Detail (What is Measured) | Key Consideration (Discrete Metrics) |
| :--- | :--- | :--- |
| **Sequencer Decentralization** | *The degree of decentralization for the entity that orders and submits L2 transactions to L1.* | **Structure**: `Centralized`, `Permissioned Set`, `Decentralized Auction`, `Based (L1 Sequencing)` |
| **Censorship Resistance** | *Mechanism to bypass a censoring sequencer* | **Mechanism**: `Force inclusion` (Sequencer must process), `Escape Hatch` (Direct L1 withdraw), `Council` (Permissioned) <br> **User Burden:** `Smart Wallet (Stateless)`, `Merkle Witness Needed`, `Full State Reconstruction` <br> **Latency**: `Immediate`, `Challenge Period`|
| **Prover Mechanism** | *How the validity proofs are generated and verified.* | **Prover Access**: `Whitelist`, `Permissionless`<br> **Proof System**: `Plonk`, `Stark`, `FHE`, `Groth16`. |
| **Upgrade Process** | *The mechanism for updating the L2 smart contracts on L1.* | **Governance Structure**: `Multisig (m-of-n)`, `Immutable`, `DAO Vote` <br> Timelock: `Timelock Delay in Days/Hours.` |
| **Client-Side Requirements** | *The computational cost placed on the end-user's device for a typical transaction.* | **Proof Generation**: Required on user's client (`Yes`/`No`)?<br> **Proving Features: ** `Mobile Proving`, `Trusted Delegation`, `Blind Delegation`. <br>**Proving benchmark**: `Proof Duration`, `Proof Size`, `Peak Memory`, `preprocessing size` for **ERC-20 transfer proof generation**.
| **Finality Security** | *The underlying cryptographic or economic guarantee of transaction validity.* | **Type**: `Validity (ZK)`, `Optimistic (Fraud Proofs)` |
| **Proof System Setup** | *The initial setup requirement of the cryptographic proof system.* | **Setup Type**: `Trusted Ceremony`, `Transparent` |
| **Programmability** | *Developer environment and experience* | **Language:** `EVM/Solidity`, `DSL`, `WASM (Rust/C++)`<br> **Deployment:** `Permissionless` vs. `Whitelisted apps` |
| **PQ Security** | *Long-term hardness assumptions* | Are the encryption/hashing schemes used to hide data susceptible to HNDL (Harvest-Now, Decrypt-Later) attacks? (`Yes`/`No`) |

---

### Simple Value Transfer

We define a Simple Value Transfer as a protocol-native payment operation in which a sender transfers a specified amount of an ERC-20 (or other value abstraction). 
A token is sent to a single recipient from a single sender, resulting in a valid state transition accepted by the rollup.

**$\boldsymbol{\text{TPS}_{Public}}$ for public transfers:**
- Transfer semantics are publicly observable according to the protocol design
(e.g. sender, recipient, and amount are not hidden).
- Completion **SHOULD** be defined by L2 inclusion and validity.
- No optional features are enabled unless they are protocol-mandatory.

**$\boldsymbol{\text{TPS}_{Private}}$ for private transfers**:
- Transfer semantics **MUST** satisfy the protocol’s full privacy mode
(e.g. hiding sender, recipient, amount, or balance, as applicable).
- Completion **MUST** be defined by L2 inclusion and validity under private execution.
- Optional features (memos, compliance disclosures, multiple outputs, offchain cooperation) are out of scope unless strictly required by the protocol. However, any features that are excluded when reporting TPS **MUST NOT** be implicitly assumed elsewhere in the performance, privacy, or security analysis. In other words, the reported TPS must correspond to a self-consistent protocol configuration: a system should not report throughput for a reduced feature set while claiming properties in other categories that require additional, unaccounted-for overhead.

**Explicit Non-Goals / Assumptions:**
- This definition does not attempt to equalize:
- data availability models,
- finality,
- confirmation UX,
- compliance or audit features,
- or offchain coordination requirements.
- These aspects **SHOULD** intentionally evaluated in separate metrics.
- We acknowledge that some designs **MAY** not map perfectly to this abstraction; in such cases, assumptions will be stated explicitly rather than implicitly optimized.