statebloat scenarios

[pk910]

refactoring & merging:

• (feat) Introduce contract-deployment bloating scenario #41
• feat(eao-delegation): Create eoa-delegation scenario oriented to state-bloating #68
• feat(rand_sstore_bloater): add SSTOREStorageBloater contract and scenario #69
• feat: Introduce erc20_max_transfers scenario for bloating #70

[CPerezz]

Hey @pk910! Thanks for this! But I hink we should be good with the PRs I made (splited the original one as we agreed upon).

If we merge in order I think we should be fine. LMK if there's any issue

[pk910]

Heya @CPerezz,
There are unfortunately various issues with the PRs :/
It's still based on a very old master state, so merging will not work due to changed Types.
It's also not following some important patterns of spamoor:

1. you're using the root wallet way too much. This seems simple on first glance, but it breaks spamoor when using it with multiple concurrently executed scenarios, as the root wallet is shared across all of them and may not have nonce gaps or too many pending transactions.
   You also have limits on the number of pending transactions from various clients. Exceeding that limit will lead to dropped txs and therefore nonce gaps. That's why we have that whole logic to send thousands of transactions via multiple sender wallets - so the pending tx count per wallet never exceeds the limit.

2. There are various issues arising by switching to the go-ethereum contract binding system midway through.
   This won't work as the nonces that are internally used by the binding subsystem are not tracked by spamoor, which leads to reusing them again in different situations. This especially gets worse as you're also using the root wallet directly for this.

I'm currently going through the code and trying to clean it up a bit. But at the end I'm still not sure about what it is needed for? :D

It seems like these state growth scenarios are all way slower than the existing complementary scenarios as you have that split funding / bloating & analyze phases looped through.
I kinda get it for the eoa-delegation scenario, as there is a small logical difference compared to the setcodetx scenario by funding the delegators with 1wei each.
(Btw, why is this needed? And is it strictly necessary as a pre-step before doing the delegation?)

But I don't really get the diff for rand_sstore vs storagespam and erc20-max-transfers vs erctx?
Is it just because you need to generate the summary at the end?

The erc20 scenario also misses the contracts to deploy, which makes the scenario quite hard to use as you need the prerequisites (deployments file, and the contracts to deploy) from somewhere?

[CPerezz]

It's still based on a very old master state, so merging will not work due to changed Types.

I didn't realize. Will update that myself. No worries.

you're using the root wallet way too much. This seems simple on first glance, but it breaks spamoor when using it with multiple concurrently executed scenarios, as the root wallet is shared across all of them and may not have nonce gaps or too many pending transactions.
Yes, and one of my assumptions was always why isn't the nonce behind a Mutex or something similar. Though now that you mention it, I agree that if there are multiple instances running in different contexts. Then this breaks even with Mutex.

I can definitely change that no worries!

You also have limits on the number of pending transactions from various clients. Exceeding that limit will lead to dropped txs and therefore nonce gaps. That's why we have that whole logic to send thousands of transactions via multiple sender wallets - so the pending tx count per wallet never exceeds the limit.

I ignored this. That's good to know. And perfectly explains why we should avoid the RootWallet usage. (Most of my scenarios are rate-limited anyways) but agree with you we should change it.

There are various issues arising by switching to the go-ethereum contract binding system midway through.
This won't work as the nonces that are internally used by the binding subsystem are not tracked by spamoor, which leads to reusing them again in different situations. This especially gets worse as you're also using the root wallet directly for this.

I see. Any particular suggestions on how to proceed otherwise?

I kinda get it for the eoa-delegation scenario, as there is a small logical difference compared to the setcodetx scenario by funding the delegators with 1wei each.
(Btw, why is this needed? And is it strictly necessary as a pre-step before doing the delegation?)

This is needed because the cost of setting authorizations to already existing accounts is lower (saving 25kgas/account). We want to write as much code as possible in as many accounts as possible. So I need to be sure all of them are funded prior to set the authorization tuple for them. This is the reason why this scenario works in this way. I think README explains it. But I might need to clarify.

But I don't really get the diff for rand_sstore vs storagespam and erc20-max-transfers vs erctx?
Is it just because you need to generate the summary at the end?

So for rand_sstore and erc20-max-transfers I tried to avoid what happened with eoatx. Which is that I need extra logic because some scenarios are related/depend on eachother. See, when measuring performance, you rarely care about existing state. But when you want to exploit big state, you do. Hence, some of my scenarios bloat contract deployment while others use such contracts to perform bloating inside of them in a combination.
For example:

• rand_sstore has a "deterministic" storage bloating. Meaning, storing few info I can replicate the whole chain of slots that contain data. This is important because then I can implement scenarios that leaverage this and do Non-0-slot -> Non-zero-slot allowing me to write a lot more data at a cheaper price making the node suffer. Also rand_sload(under construction) reuses the storage slot position acess via deterministic seed to trigger attacks forcing the node to read as many random positions in as many contracts as possible. I can't implement all this logic in your scenario as it will be a lot more complex.
• erc20-max-transfers is kinda similar. I re-use here the fact that the whole supply of the token is under a single wallet (the root) and I abuse this in order to fund as many new accounts as possible (making the balances mapping grow as much as possible). With that, I can then get reports and know the state size of each contract creating assymetries and bloating some of them way more than others. Allowing me to test more scenarios.

I hope this explains my rationale on why I proceeded this way.

[pk910]

Heya @CPerezz,

Thanks for clarifying :) The explanations for the scenario helped me understanding the background better.
So, I've included all your statebloat scenario PRs into this PR, and made several adjustments to make the code more streamlined with the rest of the codebase to keep it maintainable.
There were a few issues, like the excessive root wallet usage which should now be fixed too.

Can you have another quick look across the functionality?
I've tried to retain all features, so the scenarios should work the same way.