Create Optimism/Ethereum Side of Local Network

To make everything go e2e, we'll need:

Private ethereum network (Ethereum doesn't have a regtest mode, but there are options like https://docs.prylabs.network/docs/advanced/proof-of-stake-devnet - we will want to config the genesis block to give some four addresses testnet ETH: admin, batcher, proposer, and user)
Building op-geth and optimism (including compiling the optimism smart contracts, which is normally part of "op-bindings" in the build process)
Using different Ethereum keys for the admin, batcher, and proposer roles (these can be hard-coded, no need to generate new ones like we have to do in regular manual e2e on Sepolia)
Deploying the optimism L1 smart contracts to our private Ethereum network (normally ./deploy-opl1contracts.sh) using the admin ETH address
Generating the L2 config based on the L1 smart contract deployments (normally ./generate-l2config.sh)
Running op-geth, op-node, op-batcher, and op-proposer binaries with the appropriate config for the addresses we are using for the batcher and proposer
op-node will connect to our bss container already running in the current e2e environment

Then we can check correct e2e behavior:

op-node correctly creates new L2 blocks which are accepted by op-geth
op-node is sending new L2 keystones to BSS
Use the PoP Miner private key to send
Send a transaction from our user address to the L1 deposit contract, and see the native token balance of the address update in op-geth after waiting 20(?) blocks; this can also be done with an RPC call to op-geth
Send tunneled testnet ETH from our user address to the ETH address corresponding to the public key used by the popminer.
Check that op-node is successfully calculating PoP payouts - which can be seen by running an RPC call against op-geth to get the tHEMI ERC-20 token balance of the address corresponding to the public key of the pop miner. Check balance against token contract 0x4200000000000000000000000000000000000042 after sufficient keystones for a PoP payout (currently 250 but we can reduce this delay in e2e - see below)
Send some tHEMI from the popminer address to the user address (must be done after sending ETH from user to popminer to pay fees)
Calling the various finality endpoints on op-node and making sure they work and return the same information as the corresponding queries ran on BFG directly

And we can expand e2e tests in the future to include:

Deploying our ndApps and interacting with them as user, making calls against op-geth to check the expected state of smart contracts (like putting liquidity in a DEX and trading against it - might require deploying a test ERC-20 contract too).
Deploy contracts that interact with hVM / Bitcoin Kit, and make sure they are getting the expected data cross-referenced against our Bitcoin regtest node (for example address balance, UTXO list, last block header). This can be done with simulated smart contract calls via op-geth RPC calls.
Stopping the batcher and making sure op-node eventually reorgs enpty blocks into the chain once the batcher publication allowance period has elapsed
Untunneling ETH from the network (will require using the optimism-sdk which talks to op-geth)
Deploying an ERC-20 on our Ethereum testnet, and deploying corresponding ERC-20 bridge contract on L2
Tunneling our ERC-20 token from L1 to L2, and then back to L1 (also needs optimism-sdk)

We can tweak some Optimism variables to make the e2e test go faster:

The waiting period before PoP payouts could be reduced to the next keystone, since our PoP transaction is guaranteed to get included in Bitcoin very quickly since we are ticking new blocks quickly there
The L2 block time can be lowered to the L1 block time of our Ethereum testnet, which could be 1 second
The window of time for batcher publications to Ethereum can be much shorter, maybe 10 ETH blocks or less to test re-derivation of empty blocks after batcher fails
The challenge period can be shortened to 10 ETH blocks, so L2->L1 withdrawals can quickly be tested

hemilabs / heminetwork