Feat: emulate XEN

[bertmiller]

Is your feature request related to a problem? Please describe.
Not a problem, but it'd be great for us to emulate the behavior of XEN because that smart contract is known to cause problems for sequencers

Describe the solution you'd like
I would like a spam scenario that deploys the XEN smart contracts or something similar to it. I believe the important consideration is the sheer number of storage slots touched/destroyed.

I believe this is the smart contract: https://etherscan.io/token/0x06450dee7fd2fb8e39061434babcfc05599a6fb8

[fahimahmedx]

While I got the XENCrypto contract working, I was unable to successfully create the XENTorrent (the real spam culprit) scenario working in time due to bytecode errors.

I have updated my PR #169 with a detailed guide of what I tried so far & how I ended up with my contendor scenario script, and what is currently broken for another to give it a try.

I hope the PR is detailed enough to have helped with the heavy lifting of this task, once the bytecode is fixed so the bulkClaimRank() function can be called, then it's complete! Spamming bulkClaimRank() will be enough to measure the change in state growth, as bulkClaimRank() is what deploys a ton of smart contracts which takes up state. (example tx of 128 smart contracts being deployed).

[fahimahmedx]

As a guide on how XEN spam causes state growth:

there's two components to this:

1. XEN smart contract itself: https://etherscan.io/token/0x06450dee7fd2fb8e39061434babcfc05599a6fb8#code
2. XEN Torrent (by XEN, which enables playing XEN many times in parallel): https://etherscan.io/address/0x0a252663dbcc0b073063d6420a40319e438cfa59#code

At a high level overview, users can play XEN by calling claimRank() in its smart contract with a given term duration (1 to 471 days on Ethereum, 1 to 505 days on Base). After the duration passes, they call the claimMintReward() function afterwards to claim free XEN tokens.

Where does the spam happen? Not with XEN itself, but with XEN Torrent.

XEN Torrent builds on top of the original XEN smart contract to enable XEN to be done multiple times in parallel for a single user (as opposed to only one claimRank() call until its complete).

It does this by deploying hundreds of smart contracts (called VMU’s) in a single transaction (THIS is what consumes state!), which then each call the claimRank() function on the original XEN smart contract and later call the claimMintReward() to claim the free XEN tokens as if it was multiple users.
Example tx of a batch claim rank tx which deploys 128 smart contracts: https://etherscan.io/tx/0x6d6046a57d7fd1971a72a4d6d89ba619cd379c0c89d0bd4dc43c963eecd7f366

After claimMintReward() is called, the selfdestruct() is called on the smart contract.
Note that SELFDESTRUCT opcode no longer deletes the smart contract from the blockchain to reduce state.