Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA Thank you to @Thomas, @Vitalik, and @Toni for formulating MATCHA. Enabling multi-transaction concurrency for single shared senders without introducing centralized relayer or verifier whitelists addresses a longstanding architectural bottleneck for privacy pools and smart contract account abstraction.
To help ground community and client team discussion around the mechanics, DoS boundaries, and trade-offs, here is a structured synthesis of how the policy operates and where key considerations lie:
1. The Core Tension: Concurrency vs. Mass Invalidation
Standard mempool policies enforce a strict one-pending-transaction-per-sender cap under Frame Transactions (EIP-8141). While Keyed Nonces (EIP-8250) allow multiple transactions to coexist from a single sender without sequential nonce collisions, lifting the one-tx restriction naively exposes nodes to two acute denial-of-service vectors:
Repeated Mass Invalidation (Rogue App): An attacker submits hundreds of concurrent spends across independent nonce keys that all read a single shared validation state. Flipping that state on-chain invalidates the entire mempool batch simultaneously, imposing heavy client simulation/cleanup cycles at negligible attacker cost.
Width Draining / Griefing (Honest App): An attacker floods an honest shared sender with low-fee transactions, monopolizing the sender’s pending capacity and locking out legitimate users without paying execution fees if the transactions drop or linger.
2. How MATCHA Solves the Problem: The Two-Tier Model
MATCHA addresses this without relying on permissioned paymaster whitelists by coupling a free baseline transaction with an irreversible capacity meter (width):
The Baseline (EIP-8141 Invariant): Every sender receives one baseline pending transaction that costs zero width. This guarantees that even an empty or un-finalized sender can process transactions sequentially.
width Accounting (Finality Gate): Additional concurrent transactions require the sender to spend width. A sender earns width strictly from actual gas consumed in newly finalized canonical blocks (capped locally).
Non-Refundable charge: Admitting, replacing, or revalidating an additional transaction deducts charge(tx). Spent width is never refunded—whether a transaction is included, dropped, expired, or invalidated. This enforces an asymptotic ceiling on repeated mass-invalidation attacks.
Economic Defense via FOCIL (EIP-8369): To deter width-draining griefing attacks, MATCHA pairs with FOCIL. Because inclusion lists mandate builder inclusion of valid transactions, an attacker attempting to jam an honest contract’s capacity faces a high probability that their low-fee spam is included and forced to pay gas on-chain.
3. Key Discussion Points & Trade-offs for the Ecosystem
Local Hard Bounds vs. Consensus Layer Reliance:
It is vital to distinguish between safety and deterrence. MATCHA’s hard safety boundary against node exhaustion is 100% local (width depletion and client-level global limits). FOCIL is an economic layer that penalizes griefers; client safety does not collapse if an inclusion list is contested or absent.
Bootstrapping Latency for New Applications:
Because width is earned strictly through finalized execution gas, newly deployed shared-sender contracts start with zero width. They must operate at the baseline of 1 transaction per block until finality (2 epochs / ~12.8 minutes) credits sufficient capacity. High-volume initial launches will need to account for this initial ramp-up.
Application State Dependencies & Proof Collisions:
Because spent width is non-refundable, an honest user whose transaction is invalidated by a competing spend (e.g., a nullifier collision or state root advance under EIP-8272) consumes the contract’s shared capacity without a refund. Application developers will need tight dependency isolation in their validation frames to protect the collective pool’s width.
Optional Policies: Validity Windows vs. Linear Priority Fees:
Minimum Expiry Windows (EIP-8272): Gives FOCIL enough blocks to force inclusion and penalize spam, representing a low-overhead, effective deterrent.
Linear Priority Fees via load: Escalates fee floors as pending volume rises. While effective against bulk flooding, it also prices out honest users during organic usage spikes, making its status as an optional local policy appropriate.
Next Client Implementation Steps
Validating MATCHA will require client-level benchmarking on:
Revalidation overheads when shared payer balances change (confirming clients avoid full execution replay when validation bytecode and inputs remain static).
Calibration of the safety_factor against complex ZK-proof verification frames.
Empirical simulation of width recovery curves during periods of sustained network congestion.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Bloom Filters And Keyed Nonces | 0 | 8.23 | 08-09-2026 |
| 2 | Public-mempool gas sponsorship needs escrow, a bond, or trust | 0 | 6.46 | 14-09-2026 |
| 3 | Letting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559 | 0 | 6.38 | 10-09-2026 |
| 4 | Scaling Ethereum with recursive STARKs and the Trustless Log Index | 0 | 6.14 | 15-09-2026 |
| 5 | EIP-8411: what segmented payload diffusion is made of | 0 | 8.61 | 17-09-2026 |
| 6 | Designs for EVM gas accounting in EIP-7999 | 0 | 4.9 | 08-09-2026 |
| 7 | Towards Encrypted Mempools from Threshold IBE without Batching | 0 | 11.77 | 20-09-2026 |
| 8 | Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet) | 0 | 12.48 | 19-09-2026 |
| 9 | Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999 | 0 | 13.47 | 22-09-2026 |
| 10 | [Idea/Draft] Protocol-Level Smart Contract Invariant Protection via Pre-Mempool Validation (Security Manifests) | 0 | 10.76 | 22-07-2026 |