EIP-8254 introduces a per-block cap of MAX_DEPOSIT_REQUESTS_PER_BLOCK = 8192 on EIP-6110 deposit requests, enforced by Execution Layer clients during both block validation and block construction. The cap matches the existing Consensus Layer SSZ list bound MAX_DEPOSIT_REQUESTS_PER_PAYLOAD exactly.
The motivation is a reachable liveness failure: at a 193–200M gas limit a block can be filled with more than 8192 deposit requests using a batching contract (~410 deposits per 10M-gas tx). The EL produces the payload, but the CL cannot SSZ-decode it (VariableList of N items exceeds maximum of 8192), the validator receives 400 Bad Request for the block request, and proposal fails. The same SSZ bound applies to every consensus client. Subsequent proposers building on the same execution head hit the same wall until the deposit backlog drains.
The cap must be enforced during block construction (not just validation): an attacker can simultaneously flood the public mempool and trigger external-builder circuit-breakers, forcing fallback to local block production where awareness of the cap is the only defence.
ssz currently has a limitation where you need to know the exact length of each value. So yeah in theory this value could just be raised to maxint-1, but that could also bring in some unpredictable behaviour (especially if the deposit count in a single slot exceeds the processing time of that slot).
Just wanted to raise here, after editorial review realized that this check condition introduces an edge case in FOCIL for builders: if an IL transaction could be included (it fits in block gas-wise, sender has enough funds and correct nonce, see: EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL) for definition), then once included it could violate the max deposits and therefore the builder has to edit the previously added transactions.
There are conditions where the IL transaction is not included, but if it would be included, it would violate the max deposits condition (and thus cannot be included). The builder can fix by just removing txs which deposit until there is room for the tx.
This also adds the implicit maximum deposits per tx set to the max deposit count. If this would not be enforced somehow then adding such transaction to the IL means that such block should be filled enough such that the IL transaction is rejected (otherwise by inclusion the block is also invalid), which might not be possible if there are not enough transactions (or funds) available by the builder.
These are exotic edge cases but maybe good to keep in mind
There are two concerns here: 1) time to verifying new validator deposit signatures and 2) max deposit limit per block.
For 1), thanks to optimization, now clients are handling 8192 deposit signatures. If it still gets reorged, the next block—that contains the same amount of deposits—won’t get reorged because the proposer reorg is a 1-slot reorg. Then the question is whether this attack is cheaper than buying 1 slot and let it missed.
For 2), it seems the current consensus is shipping EIP-7688 as a proper fix, rather than imposing a cap.
If we did ship EIP-7688 before hitting 200M gas limit, deposits in IL transactions don’t bring any additional burden to builders. It can be treated the same as other IL transactions.
