Skip to content

Conversation

@CPerezz
Copy link
Contributor

@CPerezz CPerezz commented Feb 1, 2026

Summary

  • Fixed units mismatch bug that caused incorrect progress calculation when resuming from on-chain state
  • The contract's nextStorageSlot returns an address index (each address = 2 storage slots = 64 bytes), but the code was treating it as a raw slot number
  • This caused progress to appear ~50% complete when resuming, even when starting fresh

Root Cause

The variable startSlot was semantically incorrect - it was actually tracking address indices, not storage slots. Each "bloat cycle" creates 2 storage slots per address, so the progress calculation was off by a factor of 2.

Changes

  • Renamed startSlotnextAddressIndex for clarity
  • Fixed all progress/GB calculations to account for SlotsPerBloatCycle multiplier
  • Updated log messages to use "address" terminology instead of "slot"
  • Added clarifying comments about the units relationship

@CPerezz
Copy link
Contributor Author

CPerezz commented Feb 1, 2026

@pk910 targetting master as the scenario is in master. But I'd also need to get this commit in the deployed instance of spamoor in Perf-devnet2 🙏

I just caught this after some weird observations in the spamoor instance. I missed testing the resetting part with decent progress.. MB!

The erc20_bloater scenario was losing progress (halving each restart) due to
a semantic mismatch between the Solidity contract and Go code:

- Contract's `nextStorageSlot` stores ADDRESS INDEX (count of addresses bloated)
- Go code was treating this as SLOT COUNT (addresses × 2)

This caused a destructive bug on restart:
1. Read address index X from contract
2. Treat X as slot count (wrong units)
3. Call buildBloatTx(..., X/2, ...) - dividing by SlotsPerBloatCycle
4. Contract sets nextStorageSlot = X/2 - permanently halving progress!

Fix:
- Rename `startSlot` → `nextAddressIndex` for clarity
- Rename `targetSlots` → `targetAddresses`
- Remove the /SlotsPerBloatCycle division when calling buildBloatTx
- Fix progress calculations to properly convert addresses to bytes/GB

Tested with Geth in dev mode: progress now correctly resumes instead of halving.
@CPerezz CPerezz force-pushed the fix/erc20-bloater-progress-reset branch from 9b76c55 to 839b3b2 Compare February 1, 2026 16:10
@pk910 pk910 merged commit 2deffa8 into ethpandaops:master Feb 1, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants