5 posts tagged with "xen"

I got one sentence wrong in the post I published earlier today. I wrote that a CoinTool XEN refund did not make its block cheaper because EIP-7778 already kept block gas accounting before refunds. EIP-7778 is scheduled for Glamsterdam, but it is not active on mainnet. Under today's rules, a refund lowers both the user's receipt gas and the gas counted in the block.

Adding the refund back changes the block story quite a lot. In the same 14 complete UTC days, at least 2,405 of 100,388 canonical blocks carried more gas before refunds than their historical gas limit. The worst reached a lower-bound 72.94 million gas against a 60 million limit.

EIP-3298 came back from Stagnant and became Draft on August 19. It removes the storage-clear refund and the current 20% transaction refund cap after EIPs 8037 and 8038, while keeping same-transaction write reversals. I expected the current cap to catch a broad mix of refund-heavy Ethereum calls.

Instead, 895 calls into two XEN batch-minter contracts made 90.9% of the gap between the peak refund counter and the refund that actually reached transaction receipts.

Correction, 24 August 2026: I wrote below that EIP-7778 already kept block gas accounting before refunds and that one CoinTool call did not make its block cheaper. EIP-7778 is scheduled for Glamsterdam, not active on mainnet. Under current rules, refunds lower both receipt gas and the gas counted in the block. The correction and block-level backcast found at least 2,405 recent blocks above their historical gas limits before refunds. The XEN concentration result in this post survives.

Ethereum added just under two million net storage slots on August 16. XEN Crypto was responsible for 1,464,993 of them.

That came from 5,747 transactions, only 0.31% of the day's transaction count. They used 26.3% of execution gas and left behind 73.7% of the net slot growth. Under the constants in EIP-8037, the XEN storage writes alone backcast to 149.25 billion state gas, or 69.2% of that day's 50% state-gas target at the observed block limits.

Correction, 2026-07-20: The 55-day counts and the XEN spike in this post are wrong. I counted the full history of int_storage_slot_reactivation_12m, then used updated_date_time (the model task's write time) as if it were block time. Restricting canonical execution blocks to Dec 18-Feb 11 gives 3,833,522 reactivation rows, not 97,466,839; XEN accounts for 2,142,144, not 48,302,239. The Dec 20-22 XEN count is 225,421, not 41,816,729. I retract the 7.5% and 47% extrapolations, the 570x spike, the 41-million-witness scenario, the maturity-convergence mechanism, and the 195x threshold claim. The threshold direction survives, but at 13.0x: full correction.

State expiry has been one of Ethereum's most discussed, least implemented scaling ideas. The core promise: stop nodes from having to hold 1.3 billion dormant storage slots that haven't been touched in over a year. Just expire them. Make clients store a proof if they ever need to resurrect one.

The problem is nobody had measured how often "dead" state actually comes back to life.

I tracked every storage slot reactivation on mainnet — slots that had been dormant for at least 12 months before being accessed again — across a 55-day window from December 18, 2025 to February 11, 2026. The results are stranger than expected.

Correction, 2026-07-04: the dormant-storage-slot analysis in this post still stands, but the headline byte count was wrong for the sentence I wrote. I used mainnet.fct_execution_state_size_daily.total_bytes as "total state," then described storage-trie bytes as part of that total. The same Feb 26 row's exposed byte components sum to 430.9 GB, not 295.9 GB. I wrote up the correction here: The state-size total I used was not the total.

Every full Ethereum node is currently lugging around 430.9 GB of exposed state-size components. Every account, every contract, every storage slot, and the trie nodes wrapped around them. Sync a fresh node and you're downloading all of it. Run a node continuously and you're holding all of it in your database, forever.

The uncomfortable truth: the vast majority of that state is dead. It hasn't moved in over a year. The addresses are abandoned, the contracts are deprecated, the protocols are gone. The data just... sits there. In every node on the network.