# Post EIP-7623 adversarial block construction
_Thanks to Toni Wahrstätter for double-checking and feedback._

This document describes a construction that tries to maximize non-compressible EL payload size for EIP-7623.

The [new formula](https://eips.ethereum.org/EIPS/eip-7623#specification) for gas used per transaction is:

tx.gasUsed = (
    21000
    +
    max(
        STANDARD_TOKEN_COST * tokens_in_calldata
        + execution_gas_used
        + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata)),
        TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
    )
)

Say I create a block with a single tx with the following config:
- I use access list (EIP-2930) referring to 9_466 storage slots for a single account.
- I add 749_422 bytes of non-zero calldata.

Replacing in the formula:

tx.gasUsed = 21_000+max(2100+4*4*749_422+1900*9_466, 10*4*749_422) // (**)
           = 21_000+max(2100+11_990_752+17_985_400, 29_976_880)
           = 21_000+max(29_978_252, 29_976_880)
           = 21_000+29_978_252
           = 29_999_252 < 30_000_000 (***)
)

`(**) = max([2100 = addr access list] + [4*(...) = old calldata cost] + [1900*(...) = storage slot access list], [10*(...) = new calldata cost])`
`(***) = using the 30M as gas limit since it's the limit used in the EIP. ofc this should be 36M today`
TL;DR: I'm pushing for as much execution gas with block size impact as possible to leverage old/cheap calldata price, so I can maximize total block size.

The block size will be `~20+9_466*32+749_422=1.05MB`

This means the worst-case reduction isn't 1.79MB to 0.75MB (-1.04MB, -%58) but 1.05MB (-740KB, -41%). Under this "attack" the cost per byte would be ~28.5 instead of the claimed 40.

## Where these numbers come from?
These numbers 9_466 and 749_422 come from doing a [linear programming with the right constraints](https://www.emathhelp.net/calculators/linear-programming/simplex-method-calculator/?z=%2820%2Ba*32%2Bb%29%2F1000%2F1000&max=on&c=1900*a%2B16*b+%3E%3D+4*10*b%2C+a*1900%2Bb*16+%3C%3D+30000000-21000-2100&n=on&m=t).

Trying to find the right TOTAL_COST_FLOOR_PER_TOKEN to keep the mentioned 0.75MB bound (for 30M gas), [that would mean a value of 22](https://www.emathhelp.net/calculators/linear-programming/simplex-method-calculator/?z=%2820%2Ba*32%2Bb%29%2F1000%2F1000&max=on&c=1900*a%2B16*b+%3E%3D+4*22*b%2C+a*1900%2Bb*16+%3C%3D+30000000-21000-2100&n=on&m=t) instead of 10.

Toni pushed this idea can be pushed further by exploiting some snappy ineficiencies, which is the number used in the [updated EIP](https://eips.ethereum.org/EIPS/eip-7623#rationale).

## Anything to do about it?

The answer depends on the EIP goal is to balance:
- Reduce the non-compressible worst-case EL payload size.
- Affecting data-heavy transactions i.e., UX impact.

[This Ethresearch post](https://ethresear.ch/t/analyzing-eip-7623-increase-calldata-cost/19002) provides more insight around how this balance was evaluated.

The conclusion seems to be that the current constants still should be fine.