run contender

[zeroXbrock]

adds contender as a component and runs it with default settings (which run fill-block) once the beacon node reports as healthy

questions

• do we want to support L2 spamming, too?
• should we support multiple contender scenarios, or is the default (fill-block) fine?

usage

add the --contender flag to enable contender. it will spam the EL node on whichever recipe you choose

go run main.go cook opstack --output /tmp/playground --contender

[dmarzzz]

running this on L2 work flow would likely also be good idea! can probs be another PR. fill block scenario is likely fine for now and shouldn't block on anything more fancy, but if we want to test block builders then likely we do want some txns generating MEV, some capturing MEV, and some without MEV to test that sorting and such is working well.

[avalonche]

how is contender funded in the devnet? Also could you have a flag to enable contender, would not want it on by default yet

[zeroXbrock]

how is contender funded in the devnet?

if no private key is specified (with -p) we use the first default anvil/hardhat account (0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266) to fund the spammer accounts.