search

danyalprout / replayor

12 stars 6 forks source link

[stress test] inject erc-20 txs #13

Open bitwiseguy opened 1 month ago

bitwiseguy commented 1 month ago

Currently the stress test just injects simple eth transfer txs. While the test is able to fill blocks up to the gas target with these txs, it does not provide the same processing strain on the node as other txs that contain different opcodes. As a next step, it would be nice to be able to also inject txs that contain SSTORE/SLOAD opcodes (e.g. ERC-20 token transfers) and compare the results.

Since writing to unique storage slots is suspected to be a driver of processing block time, the inject txs should aim to use many different storage slots instead of the same slots across many txs.

GrapeBaBa commented 1 month ago

Have some questions here.

  1. Is it essential to initially create and deploy contract transactions, and carry out initialization transactions such as depositing funds into multiple addresses?
  2. How can data and test transactions be structured to ensure that each execution of the test conducts with a specific degree of determinism, allowing observation of results across multiple tests?
bitwiseguy commented 1 month ago

  1. There is already some code as part of the stress test to deposit l2 funds into the test addresses here. You should be able to just use that. Probably will need to create at least one contract deployment tx unless there is already a known contract deployed on that network that you want to interact with. One idea from @danyalprout is to create a contract that has assembly and you can pass an arg that causes it to run certain opcodes that many times. Perhaps a more straightforward approach is to deploy an ERC-20 contract and transfer tokens. Those txs will use SSTORE opcodes, but will be less tightly controlled and not sure if they will achieve the test scenario of updating many "unique storage locations"

  2. I tried to achieve determinism by running the replay tests against the same range of blocks on the same node (made easier + more repeatable by op-wheel which helps rewind the safe/unsafe block head to a given point). So all the same txs were replayed each test. However, still saw some pretty big variance in block processing times. I suspect much of the variance is due to memory usage of the op-geth node (i.e. caching, etc) and periodic db compactions but I don't have any data to definitively support that theory

GrapeBaBa commented 1 month ago

@bitwiseguy Are you already working on this?

bitwiseguy commented 1 month ago

@GrapeBaBa - No I am not working on it. Please feel free to assign it to yourself and work on it if you have the time to do it. Would welcome the contribution

GrapeBaBa commented 1 month ago

@bitwiseguy Glad to contribute, however we need to decide which method to select for implementation first.

bitwiseguy commented 1 month ago

@GrapeBaBa - awesome! As a first step I would try deploying a simple ERC-20 contract during the stress test initialization and send token transfers through that as one version of the stress test. So we would have two options for stress testing, ideally configurable through the env vars file by expanding the number of valid options to this variable, or adding a supplementary env var that allows you to select the stress type (and default to the simple eth transfer version if not specified):

  1. replay (already done)
  2. stress, eth transfers (already done)
  3. stress, erc20 transfers (next step)
  4. stress, opcode selector (future improvement)
GrapeBaBa commented 1 month ago

@bitwiseguy If you are ok, we can help to draft a PR for ERC-20 testing. I have talked with @thinkAfCod yesterday, we could start it next week.