Feat(devnet): Run devnet with testnet/mainnet data via re-genesis

[dloghin]

There are cases when we want to benchmark or profile XLayer with more data in the database. In these cases, we want to run XLayer devnet with XLayer testnet or mainnet data.

This PR proposes the following way:

• Download testnet/mainnet snapshot or set a local rpc using xlayer-toolkit and sync the latest blocks.

• Create a big genesis file based on the testnet/mainnet data. For this, we created a tool named gen-genesis under xlayer-reth repository that creates a big genesis file starting from a template genesis and an existing op-reth data directory. The template genesis is created during the xlayer-toolkit devnet setup process (./3-op-init.sh) and the gen-genesis tool is run under the same script after this genesis is created.

• Start devnet using the standard way (./0-all.sh) just by modifying a few .env variables.

[Vui-Chee]

Review of PR #111

Issues Found

1. Changed FORK_BLOCK breaks default devnet flow (example.env)

The FORK_BLOCK changed from 8593920 to 18696115 (XLayer testnet value), along with corresponding PARENT_HASH and NEW_BLOCK_HASH. With MERGE_RETH_GENESIS=false (the default), the devnet uses these testnet fork parameters on a fresh local L1 chain, creating inconsistent state.

This causes the "Bad block with existing invalid ancestor" error on op-reth-rpc:

WARN Bad block with existing invalid ancestor
  hash=0x52d1970...
  invalid_ancestor=BlockWithParent { parent: 0xba1cfd0..., block: NumHash { number: 18696151, hash: 0x3a11c45... } }

The PARENT_HASH is injected into genesis.json but doesn't correspond to any real block on the fresh local L1, so rollup derivation breaks. The original values should be kept as defaults and testnet values only used when MERGE_RETH_GENESIS=true.

2. Hardcoded NEW_BLOCK_HASH in example.env is misleading

NEW_BLOCK_HASH is dynamically generated during 3-op-init.sh:199 and written back to .env. The hardcoded testnet value will be overwritten anyway. Consider setting it to empty or adding a comment that it's auto-populated.

3. 4-op-start-service.sh wait loop could be more robust (lines 65-91)

• docker logs re-reads the full log each iteration — this gets slow as logs grow. Consider docker logs --since=30s or docker logs --tail=50.
• The grep string "X Layer genesis block" is tightly coupled to reth's log output. If the message changes, this silently breaks (proceeds after 5 min timeout with a warning).

4. Relative bind mount path in 3-op-init.sh:44

docker run --rm -v "./config-op:/config-op" ...

Relative paths in -v don't work on all Docker versions. Use $(pwd)/config-op for consistency with the rest of the script.

5. 3-op-init.sh indentation issue (lines 151-178)

The body of the new if [ "$CONDUCTOR_ENABLED" = "true" ] || [ "$SEQ_TYPE" = "geth" ] block is not indented, making it hard to read.

Minor / Positive

• Removing --flashblocks.disable-async-calculate-state-root — fine if the flag was removed from the reth binary.
• Removing Chinese characters from docker-compose.yml — good cleanup.
• Conditional geth init (skip when SEQ_TYPE=reth and CONDUCTOR_ENABLED=false) — correct optimization.
• The wait-for-reth-before-starting-op-node pattern in 4-op-start-service.sh is a good idea, just needs the robustness improvements noted above.