Note: This is intended as a side discussion rather than a core concern for Solidity development.
As Ethereum accelerates its scaling roadmap, the network also needs proportionate safeguards to ensure it does not become unstable under significantly higher block limits. The Glamsterdam upgrade is expected to raise the block gas limit from the current 60M to 200M—an increase of more than 3.3×. This represents the largest increase so far, both in absolute terms and in relative magnitude.
For comparison, the previous increase introduced in the Fusaka upgrade raised the block limit from 36M to 60M—an absolute increase of 24M, or 1.67×, compared to Glamsterdam’s 140M increase and 3.3× multiplier.
This substantial increase is made possible by two major improvements in the execution client layer: Block Access Lists (BALs) and gas repricing. Both ultimately affect the gas users pay, but their impact occurs on different timelines. Among the proposals currently scheduled for Glamsterdam, the gas repricing changes have an immediate effect, whereas BALs are expected to influence transaction fees beginning with Hegota.
This article focuses exclusively on proposals that affect calldata costs. Other areas—such as state access, state creation, and computational operations—are intentionally left out of the discussion.
Glamsterdam currently includes two EIPs that modify the cost of transaction data transmission:
-
EIP-7976 increases the calldata floor cost from 10/40 (introduced by EIP-7623) to 64/64. This is expected to have the greatest impact on the current ABI encoding model, which relies heavily on zero-byte padding, as it removes the long-standing cost distinction between zero and non-zero bytes.
-
EIP-7981 increases the cost of access lists defined in EIP-2930. Its practical impact is expected to be limited, since EIP-2930 access lists have largely been superseded by EIP-7928 and are no longer encouraged. ABI encoding itself is unaffected because calldata is unrelated to access lists.
Although Ethereum core developers currently consider the impact of these proposals to be “minimal,” that assumption is becoming increasingly difficult to maintain as additional data repricing proposals continue to be scheduled for Hegota. From my perspective, this next round of repricing is likely to become noticeable to users if application behavior remains unchanged.
-
EIP-8131 introduces a per-byte floor cost for the authorization tuple defined by EIP-7702. While it has no direct effect on ABI encoding, it significantly increases the cost of updating authorizations. Although updating an authorization remains cheaper than creating a completely new one, much of the previous calldata floor amortization is effectively lost.
-
EIP-8279 applies BAL pricing to state access operations. Again, ABI encoding is unaffected directly, but the proposal reduces the ability of state access costs—often a substantial portion of a transaction—to absorb increasing calldata floor costs.
-
EIP-8311 (which is also expected to be included in Hegota) proposes increasing the calldata floor from 64/64 under EIP-7976 to 96/96, pushing the current ABI encoding model even closer to what could be considered a “breaking point,” where the minimum cost of transmitting calldata exceeds the execution cost of the transaction itself.
Historically, calldata costs have rarely been a major concern because execution costs dominated overall transaction fees, effectively masking increases in the calldata floor. However, EIP-8279 changes that dynamic by introducing its own floor pricing for state access. As a result, execution costs can no longer reliably offset higher calldata costs, making further calldata repricing increasingly visible in the total transaction fee.
That said, I still consider this a secondary issue. Prioritizing it today risks diverting attention from more important objectives within the Solidity core roadmap. Furthermore, the ABI specification is already mature and widely adopted, meaning that any modification would introduce backward compatibility challenges. Nevertheless, this is unlikely to remain an ignorable issue for much longer as the network on which Solidity operates continues tightening its resource pricing model.
Although I am not a professional Solidity developer, I believe there are several practical approaches that could reduce calldata overhead while preserving the existing ABI model.
Using Assembly
Developers could expose only a minimal interface—for example, foo(bytes calldata data)—and then decode a compressed payload manually using inline assembly. This approach increases implementation and auditing complexity, but much of that complexity could be mitigated through well-tested assembly-only utility libraries, similar to Solady.
Introducing New Compression-Friendly Data Types
Instead of modifying existing ABI types, Solidity could introduce new data types designed specifically for more efficient encoding while preserving backward compatibility. This would inevitably increase compiler complexity and could delay higher-priority compiler initiatives. However, it would provide a native language-level solution and address the gas inefficiencies of today’s ABI encoding far more fundamentally than application-level workarounds.