(feat) Introduce contract-deployment bloating scenario

[CPerezz]

🏭 Contract Deployment State Bloat

This scenario deploys contracts that are exactly 24kB in size (EIP-170 limit) to maximize state growth while minimizing gas cost.

How it Works

1. Generates a contract with exactly 24,576 bytes of runtime code
2. Deploys the contract using CREATE with a salt that makes the bytecode unique
3. Uses batch-based deployment:
   • Calculates how many contracts fit in one block based on gas limits
   • Sends a batch of transactions that fit within the block gas limit
   • Waits for a new block to be mined
   • Repeats the process ("bombards" the RPC after each block)
4. Each deployment adds:
   • 24,576 bytes of runtime code
   • Account trie node
   • Total state growth: ~24.7kB per deployment

⛽ Gas Cost Breakdown

• 32,000 gas for CREATE
• 20,000 gas for new account
• 200 gas per byte for code deposit (24,576 bytes)
• Total: 4,967,200 gas per deployment

Batch Strategy

The scenario automatically calculates how many contracts can fit in one block:

• Default block gas limit: 30,000,000 gas
• Gas per contract: 4,967,200 gas
• Contracts per batch: ~6 contracts per block

This ensures optimal utilization of block space while maintaining predictable transaction inclusion patterns.

🚀 Usage

Build

go build -o bin/spamoor cmd/spamoor/main.go

Run

./bin/spamoor --privkey <PRIVATE_KEY> --rpchost http://localhost:8545 contract-deploy [flags]

Key Flags

• --max-transactions - Total number of contracts to deploy (0 = infinite, default: 0)
• --max-wallets - Max child wallets to use (0 = root wallet only, default: 0)
• --basefee - Base fee per gas in gwei (default: 10)
• --tipfee - Tip fee per gas in gwei (default: 2)

Example with Anvil node

./bin/spamoor --privkey ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  --rpchost http://localhost:8545 contract-deploy \
  --max-transactions 0

[pk910]

Heya @CPerezz,
Thanks for your contributions :)

I've reviewed the document, and it looks like most of the cheap state growth scenarios are already supported by the existing spamoor scenarios:

1. contract deployments with deploytx scenario (supply bytecode as --bytecodes / --bytecodes-file)
2. add delegates via setcodetx scenario
3. eoatx scenario with --random-target
4. should be possible with a slight extension of setcodetx
5. that one would be new :)

The Reversible state bloat attack vectors sound like they can be fully achieved with the gasburnertx / geastx scenarios.
But needs some custom evm asm code to do the actual bloat technique

[CPerezz]

Hey @pk910 apologies for the late reply.

Mainly the deployment contract scenario was quite different from what I need. Yes, we both deploy contracts but I needed those to be the same ABI but different bytecode by using a random salt on deploymet such that the bytecode storage for clients gets bloated too (identical bytecodes aren't duplicated ofc).

Also, this scenario grants quite some logging utilities needed later to use the wallets to bloat the KV stores with new addresses getting tokens.

I'm completelly OK if you prefer to not merge this as is super similar.
Nevertheless, I'll leave all the scenarios here and you can tell me if you want me to upstream any of them!

[CPerezz]

Seems I screwed up a bit when splitting into multiple PRs. With these two commits the scenario should now be ready.

[pk910]

this is basically what the TxPool logic does and shouldn't be duplicated.
you can get the receipts for each deployment in the SubmitTransactionOptions.OnConfirm callback and do the statistics summary there,
or subscribe to block updates via txPool.SubscribeToBlockUpdates, which will give you a per block event with all transactions / receipts that are relevant for the current scenario.

[pk910]

the ChainId is cached and can be accessed via s.walletPool.GetChainId()

[pk910]

this duplicates the transaction tracking logic and shouldn't be necessary.
You'll get the receipt in the SendTransactionOptions.OnConfirm callback, so you should just call s.recordDeployedContract from there.

[pk910]

This feels like a memory leak, as the deployedContracts slice can grow over hours and cause OOM kills at some point.
Consider adding those entries in a append-style file.
maybe as yaml array, so you can easily append lines without reading & re-writing the whole file:

- {"ContractAddress": "0x...", "PrivateKey": "0x..."}
- {"ContractAddress": "0x...", "PrivateKey": "0x..."}
...

[pk910]

shouldn't be necessary, subscribe to block notifications as mentioned above if you want per block stats.

[pk910]

this duplicates the scenario.RunTransactionScenario helper, that is shared across almost all scenarios to avoid duplicating the core transaction count / throughput & pending limitations.

it should be something like this:

err := scenario.RunTransactionScenario(ctx, scenario.TransactionScenarioOptions{
		TotalCount: s.options.MaxTransactions,
		Throughput: maxTxsPerBlock,
		MaxPending: maxPending,
		Timeout:    timeout,
		WalletPool: s.walletPool,
		Logger:     s.logger,
		ProcessNextTxFn: func(ctx context.Context, txIdx uint64, onComplete func()) (func(), error) {
		     tx, err := s.sendTransaction(ctx, txIdxCounter, onComplete) // ensure onComplete gets called when the tx completes (either an error before/on submission or confirmation)
		     return func() {
				if err != nil {
					logger.Warnf("could not send transaction: %v", err)
				} else if s.options.LogTxs {
					logger.Infof("sent tx #%6d: %v", txIdx+1, tx.Hash().String())
				} else {
					logger.Debugf("sent tx #%6d: %v", txIdx+1, tx.Hash().String())
				}
			}, err
		},
})

[pk910]

this gas increasing retry loop shouldn't be necessary. Send transactions with a static base fee. You might get a empty block if the base fee is too high, but that's fine, as otherwise the base fee grows exponentially and you can't afford the fee over long term even with nearly unlimited funds.

[pk910]

the block base fee is tracked in the TxPool and can be requested via TxPool.GetCurrentBaseFee / TxPool.GetCurrentBaseFeeWithInit

[pk910]

nonce tracking needs to be done within the local wallet, otherwise you'll get duplicate transactions as previous transactions are still being gossiped or otherwise processed.
the spamoor.Wallet provides appropriate methods to build transactions with a thread safe tracked nonce:

feeCap, tipCap, err := s.walletPool.GetTxPool().GetSuggestedFees(client, s.options.BaseFee, s.options.TipFee)
if err != nil {
		return nil, client, err
}

// Generate random salt for unique contract
salt := make([]byte, 32)
_, err = rand.Read(salt)
if err != nil {
  return fmt.Errorf("failed to generate salt: %w", err)
}
saltInt := new(big.Int).SetBytes(salt)

tx, err := wallet.BuildBoundTx(ctx, &txbuilder.TxMetadata{
		GasFeeCap: uint256.MustFromBig(feeCap),
		GasTipCap: uint256.MustFromBig(tipCap),
		Gas:       2000000,
		Value:     uint256.NewInt(0),
}, func(transactOpts *bind.TransactOpts) (*types.Transaction, error) {
		_, deployTx, _, err := contract.DeployContract(transactOpts, client.GetEthClient(), saltInt)
		return deployTx, err
})

[pk910]

please exclude the .abi & .bin from the repository and copy/amend the compile.sh from another scenario.
that way all contracts are built the same way, which is way easier to maintain.

[pk910]

Heya @CPerezz,
I've taken another look at the PR. There is still a lot of code duplicated in a less optimal way, which makes it hard to maintain this scenario.
Could you take a look at those review comments? :)
It's basically what I already tried to fix in #72, but as of your feedback that refactored version doesn't work properly?