Manipulation Resistance Analysis

Istora Mandiri
Research TODO

TODO

This article is a placeholder and is subject to change as research continues.

Abstract

EIP-1559's basefee burning was designed to prevent manipulation through off-chain agreements. Since ECIP-1120 distributes fees to miners instead of burning them, we must verify the ℓ-smoothing mechanism provides equivalent manipulation resistance. This research analyzes attack vectors including spam transactions, empty block mining, and off-chain fee agreements, demonstrating that ECIP-1120's parameters adequately disincentivize these behaviors.

Research Objectives

  1. What manipulation attacks are possible against the ECIP-1120 fee distribution?
  2. Under what conditions do these attacks become profitable?
  3. What minimum ℓ-smoothing window size prevents profitable manipulation?
  4. How do different distribution curves affect attack profitability?
  5. Are there novel attack vectors unique to ECIP-1120's design?

Background

Formal Security Properties

Roughgarden's foundational analysis of EIP-1559 establishes three formal security properties that a transaction fee mechanism (TFM) should satisfy. Understanding these properties is essential for evaluating ECIP-1120's manipulation resistance.

MMIC: Myopic Miner Incentive Compatibility

Definition (Roughgarden, Section 3): A transaction fee mechanism is myopically miner incentive-compatible (MMIC) if a miner maximizing only their current block's revenue cannot benefit from deviating from the "honest" strategy of including the highest-paying transactions up to the block's capacity.

In simpler terms: miners should have no short-term incentive to:

  • Include fake transactions they create themselves
  • Exclude legitimate high-fee transactions
  • Manipulate the ordering of transactions for fee extraction
  • Mine empty blocks when transactions are available

Why MMIC matters: If a mechanism isn't MMIC, miners can extract additional value through strategic behavior, leading to unpredictable fees and degraded user experience.

EIP-1559's MMIC status: Roughgarden proves (Theorem 3) that EIP-1559 with burning is MMIC when blocks are not full. When blocks are consistently full, the priority fee auction resembles a first-price auction, which is not perfectly MMIC.

ECIP-1120's challenge: Since basefees are distributed to miners rather than burned, we must verify that ℓ-smoothing preserves MMIC properties. A miner who could capture manipulated fees immediately would have strong incentives to deviate from honest behavior.

UIC: User Incentive Compatibility

Definition (Roughgarden, Section 4): A transaction fee mechanism is user incentive-compatible (UIC) if users bidding their true maximum willingness to pay is a dominant strategy—that is, truthful bidding is optimal regardless of what other users do.

In simpler terms: users should not need to:

  • Guess what fee to bid based on network congestion
  • Overpay to ensure inclusion
  • Engage in fee-bidding wars with other users
  • Use sophisticated strategies to minimize fees

Why UIC matters: If a mechanism isn't UIC, users face a complex optimization problem every time they transact. This leads to overpayment, failed transactions, and poor user experience—exactly the problems EIP-1559 was designed to solve.

EIP-1559's UIC status: Roughgarden proves (Theorem 6) that EIP-1559 is UIC for users when:

  1. The basefee accurately reflects demand
  2. The user only cares about eventual inclusion (not timing)
  3. Blocks aren't persistently full

The mechanism achieves UIC by separating the "inclusion fee" (basefee, algorithmically determined) from the "priority fee" (tip for faster inclusion).

ECIP-1120's UIC status: Since ECIP-1120 uses the same basefee calculation as EIP-1559, UIC properties are preserved. Users interact with the same transaction format and bidding mechanism.

OCA-Proofness: Resistance to Off-Chain Agreements

Definition (Roughgarden, Section 8): A transaction fee mechanism is OCA-proof if there is no off-chain agreement (OCA) between a user and a miner that makes both parties strictly better off than following the mechanism honestly.

In simpler terms: users and miners should not be able to make a side deal that:

  • Lets users pay less than the basefee
  • Gives miners more than they'd earn honestly
  • Bypasses the fee mechanism entirely

Why OCA-proofness matters: If profitable OCAs exist, rational actors will use them. This undermines the entire fee mechanism—basefees become meaningless, fee predictability disappears, and the mechanism degenerates into an opaque negotiation between users and miners.

The fundamental OCA attack (Roughgarden, Section 8.2):

Without burning, a user wanting to transact could approach a miner directly:

"Instead of paying the 100 gwei basefee on-chain, I'll pay you 50 gwei directly. You include my transaction with a fake 0 gwei fee. We both save money."

If the miner receives the basefee anyway (as in naive "pay miners instead of burn" schemes), this attack is devastating:

  • User saves: 50 gwei (pays 50 instead of 100)
  • Miner gains: 50 gwei extra (gets 100 basefee + 50 OCA payment vs just 100)
  • Result: Both parties profit, mechanism breaks down

Why burning provides OCA-proofness (Roughgarden, Theorem 15):

When basefees are burned, OCAs cannot benefit both parties:

If the miner includes a fake 0-fee transaction, the basefee is still burned—the miner receives nothing from the basefee. Any side payment from the user comes purely from the user's pocket, not from "savings" on the basefee.

The user cannot offer the miner more than the basefee (they'd pay more total), and the miner won't accept less than the basefee (they'd earn less). No mutually beneficial OCA exists.

The ECIP-1120 Challenge

Since ECIP-1120 distributes basefees to miners instead of burning them, we cannot rely on burning for OCA-proofness. Roughgarden addresses this directly in Section 8.3:

"Is there an alternative to burning the base fee that still disincentivizes off-chain agreements?"

The answer is ℓ-smoothing (Section 8.3.1): distributing fees not to the current block's miner, but across the miners of multiple blocks.

ℓ-Smoothing: Achieving OCA-Proofness Without Burning

Definition (Roughgarden, Section 8.3.1): In an ℓ-smoothing mechanism, the basefee collected in block i is distributed equally among the miners of blocks i+1, i+2, ..., i+ℓ.

Why ℓ-smoothing provides OCA-proofness:

Consider a miner controlling hashrate fraction h (e.g., 10% of network hashrate). Under ℓ-smoothing:

  1. If the miner includes an honest transaction paying basefee b:

    • The basefee b is distributed across the next ℓ blocks
    • The miner expects to mine h fraction of those blocks
    • Miner's expected revenue from basefee: b × h / ℓ

  2. If the miner accepts an OCA to include a fake 0-fee transaction:

    • No basefee is collected (transaction shows 0 fee)
    • Miner receives only the direct OCA payment
    • Miner's revenue: OCA payment only

For the OCA to benefit the miner:

OCA_payment > b × h / ℓ

For the OCA to benefit the user:

OCA_payment < b

Combining these constraints:

b × h / ℓ < OCA_payment < b

This inequality can only be satisfied when h / ℓ is close to 1. For any reasonable ℓ value and honest majority (h < 0.5), no mutually beneficial OCA exists.

Example: With ℓ = 100 and a miner controlling 10% hashrate:

  • Miner's expected basefee capture: b × 0.10 / 100 = 0.001 × b (0.1%)
  • For OCA to benefit miner: payment > 0.1% of basefee
  • For OCA to benefit user: payment < 100% of basefee
  • Gap is huge: The miner would accept almost any payment, but the user saves almost nothing by paying the miner directly vs. paying the basefee on-chain.

As Roughgarden notes: "The larger ℓ is, the less a block producer benefits from a deviation, and thus the easier it is to make the mechanism OCA-proof."

Backward-Looking ℓ-Smoothing in ECIP-1120

ECIP-1120 implements a backward-looking variant of ℓ-smoothing: instead of distributing fees to future blocks, the miner of block N receives a portion of fees from the previous ℓ ancestor blocks.

This achieves the same OCA-proofness guarantees because:

  1. Dilution still applies: A miner manipulating fees in block N only captures 1/ℓ of those fees (in block N+ℓ), weighted by their probability of mining that future block.

  2. Stateless calculation: The backward-looking approach can be computed from block headers alone, simplifying implementation and reorg handling.

  3. Equivalent game theory: From the miner's perspective, the incentive structure is identical—manipulation yields only h/ℓ fraction of the manipulated amount in expectation.

Summary: Security Properties Under ECIP-1120

Property EIP-1559 (Burning) ECIP-1120 (ℓ-Smoothing) Notes
MMIC ✓ (when not full) ✓ (with sufficient ℓ) ℓ-smoothing dilutes manipulation incentives
UIC ✓ ✓ Same basefee mechanism, same user experience
OCA-proof ✓ (via burning) ✓ (via ℓ-smoothing) Requires ℓ large enough that h/ℓ is small

Known Attack Vectors

Attack Description EIP-1559 Defense ECIP-1120 Defense
Spam Flood with transactions to raise basefee Attackers pay basefee (burned) Attackers pay basefee (distributed)
Empty blocks Mine empty blocks to lower basefee Forfeit all fee revenue Receive smoothed fees from ancestors
OCAs Off-chain agreements to bypass basefee Burned basefee not recoverable Diluted by ℓ-smoothing
Time-bandit Reorg to capture high-fee blocks Standard reorg resistance Enhanced by fee smoothing

Methodology

Approach

  1. Theoretical Analysis: Formalize attack profitability conditions
  2. Game-Theoretic Modeling: Identify Nash equilibria under various parameters
  3. Simulation: Model attacks under realistic network conditions
  4. Empirical Validation: Test against historical ETC data

Attack Profitability Framework

For each attack vector, calculate:

  • Attack cost: Resources required (hashrate, capital, fees)
  • Expected return: Revenue if attack succeeds
  • Success probability: Likelihood of successful execution
  • Risk factors: Detection, retaliation, reputation damage

Modeling Assumptions

  • Rational, profit-maximizing attackers
  • Network conditions similar to current ETC mainnet
  • No collusion beyond specified attack scenario
  • Standard 51% security threshold for honest majority

Research Plan

Phase 1: Spam Attack Analysis

  • Model basefee manipulation via spam transactions
  • Calculate cost to raise basefee by X% for N blocks
  • Calculate miner return from elevated basefee under ℓ-smoothing
  • Determine break-even hashrate for profitable spam
  • Identify minimum L to make spam unprofitable at any hashrate < 50%

Phase 2: Empty Block Analysis

  • Model empty block mining strategy
  • Calculate revenue from ℓ-smoothing during empty block periods
  • Compare to revenue from including available transactions
  • Identify conditions where empty blocks are rational
  • Verify ℓ-smoothing prevents "death spiral" incentives

Phase 3: Off-Chain Agreement Analysis

  • Model OCA mechanism (user pays miner directly)
  • Calculate miner benefit from accepting OCA vs honest mining
  • Model user benefit from OCA vs paying basefee
  • Determine L threshold where OCAs become unprofitable
  • Analyze multi-miner collusion scenarios

Phase 4: Time-Bandit Attack Analysis

  • Model reorg incentives under fee smoothing
  • Calculate profitability of reorging to capture high-fee blocks
  • Compare to standard (non-smoothed) reorg incentives
  • Verify smoothing reduces time-bandit profitability

Phase 5: Novel Vector Discovery

  • Brainstorm ECIP-1120-specific attack vectors
  • Analyze miner collusion scenarios
  • Consider cross-block MEV extraction strategies
  • Test assumptions against adversarial edge cases
  • Document any discovered vulnerabilities

Phase 6: Parameter Recommendations

  • Synthesize findings into parameter constraints
  • Recommend minimum safe L value
  • Recommend distribution curve (uniform vs decay)
  • Document remaining attack surface (if any)
  • Coordinate with Distribution Curve Design

Expected Outcomes

  1. Attack Profitability Report: For each vector, conditions under which attack pays
  2. Parameter Bounds: Minimum L and curve shape for adequate resistance
  3. Security Proofs: Mathematical demonstrations of manipulation resistance
  4. Residual Risk Assessment: Any attacks that remain possible and their likelihood
  5. Comparison to EIP-1559: How ECIP-1120 resistance compares to burning

Success Criteria

  • All analyzed attacks require > 50% hashrate to be profitable
  • ℓ-smoothing demonstrably dilutes manipulation incentives
  • No novel attack vectors discovered that break security assumptions
  • Recommended parameters achieve resistance comparable to EIP-1559 burning
  • Analysis reviewed and validated by external security researchers

Dependencies

Current Status

Status: TODO

Progress Log

  • 2025-11-28: Initial research plan drafted
  • Pending: Begin Phase 1 spam attack analysis

Appendix: Formal Definitions

The following definitions are adapted from Roughgarden's "Transaction Fee Mechanism Design for the Ethereum Blockchain".

Transaction Fee Mechanism (TFM)

A transaction fee mechanism (TFM) specifies:

  1. A message space for users (bids, transaction data)
  2. An allocation rule determining which transactions are included
  3. A payment rule determining fees paid
  4. A miner revenue rule determining miner compensation

EIP-1559 and ECIP-1120 are both TFMs with specific rules for each component.

MMIC: Formal Definition

Definition 1 (Roughgarden, Definition 1): A TFM is myopically miner incentive-compatible (MMIC) if, for every block producer and every set of pending transactions, the block producer's expected revenue is maximized by following the prescribed allocation and payment rules.

Formally, let:

  • M = set of pending transactions in mempool
  • B = block produced by miner
  • R(B) = miner's revenue from block B

A TFM is MMIC if for all valid blocks B':

R(B_honest) ≥ R(B')

where B_honest is the block produced by following the protocol honestly.

UIC: Formal Definition

Definition 2 (Roughgarden, Definition 4): A TFM is user incentive-compatible (UIC) if, for every user with value v for transaction inclusion, bidding v as their maximum fee is a dominant strategy.

Formally, let:

  • v = user's true value for inclusion
  • b = user's bid (maxFeePerGas)
  • p(b) = expected payment given bid b
  • Pr(b) = probability of inclusion given bid b

A TFM is UIC if for all v and alternative bids b' ≠ v:

v × Pr(v) - p(v) ≥ v × Pr(b') - p(b')

OCA-Proofness: Formal Definition

Definition 3 (Roughgarden, Section 8.1): A TFM is c-OCA-proof if no off-chain agreement between a user and miner can improve both parties' utilities by more than a factor of c compared to honest behavior.

A TFM is OCA-proof if it is 1-OCA-proof (no beneficial OCAs exist).

Theorem (Roughgarden, Theorem 15): EIP-1559 with basefee burning is OCA-proof.

Theorem (Roughgarden, Section 8.3.1): EIP-1559 with ℓ-smoothing is approximately OCA-proof, with the approximation improving as ℓ increases.

ℓ-Smoothing Dilution Factor

For a miner with hashrate fraction h under ℓ-smoothing:

expected_capture = h / ℓ

The miner's expected share of any manipulated fees is diluted by factor ℓ.

Example calculations:

Hashrate (h) ℓ Expected Capture Notes
10% 10 1% Minimal dilution
10% 100 0.1% Strong dilution
10% 1000 0.01% Very strong dilution
30% 100 0.3% Large miner, still diluted
50% 100 0.5% Majority miner, still < 1%

OCA Profitability Constraints

For an OCA to benefit both parties:

Miner constraint (must earn more than honest mining):

OCA_payment > basefee × h / ℓ

User constraint (must pay less than on-chain):

OCA_payment < basefee

Combined constraint:

basefee × h / ℓ < OCA_payment < basefee

This range is non-empty only when h/ℓ < 1, which is always true. However, the size of the range shrinks as ℓ increases:

range_size = basefee × (1 - h/ℓ) ≈ basefee  (for large ℓ)

While the range is technically non-empty, the miner's minimum acceptable payment approaches zero as ℓ increases. The user has no incentive to enter an OCA when they could pay nearly the same amount on-chain with the benefits of public transaction inclusion.

Attack Profitability Condition

An attack is profitable when:

E[attack_revenue] - attack_cost > E[honest_revenue]

Where:

  • E[attack_revenue] = Expected revenue from attacking
  • attack_cost = Direct costs of executing attack (hashrate, capital, fees)
  • E[honest_revenue] = Expected revenue from honest mining

For ℓ-smoothing to prevent attacks, we need:

E[honest_revenue] > E[attack_revenue] - attack_cost

This is achieved when the attack's expected revenue is diluted by factor h/ℓ.

Relationship to Mechanism Design Theory

ECIP-1120's ℓ-smoothing can be understood through the lens of classical mechanism design:

  1. Incentive Compatibility: ℓ-smoothing transforms the fee distribution from a "winner-take-all" auction (where the block producer captures all fees) into a "smoothed allocation" mechanism where benefits are distributed.

  2. Budget Balance: Unlike burning (which is not budget-balanced—value is destroyed), ℓ-smoothing is perfectly budget-balanced. All collected fees are eventually distributed to miners.

  3. Individual Rationality: Miners always earn non-negative revenue from participating honestly, satisfying the individual rationality constraint.

References

Primary Source

EIP Specifications

ECIP-1120 Resources

More Articles