[Core Protocol] <One quick question about Challenger-node config set-up>

[AaronLee22]

Did you check the documentation and specs?

• Yes

Was there anything unclear or missing?

environment: OP_CHALLENGER_L1_ETH_RPC: http://l1:8545 # Note: this will need to be updated to point to a L1 consensus node when there is one in the devnet OP_CHALLENGER_L1_BEACON: 'unset' OP_CHALLENGER_ROLLUP_RPC: http://op-node:8545 OP_CHALLENGER_TRACE_TYPE: cannon,fast OP_CHALLENGER_GAME_FACTORY_ADDRESS: ${DGF_ADDRESS} # The devnet can't set the absolute prestate output root because the contracts are deployed in L1 genesis # before the L2 genesis is known. OP_CHALLENGER_UNSAFE_ALLOW_INVALID_PRESTATE: 'true' OP_CHALLENGER_DATADIR: /db OP_CHALLENGER_CANNON_ROLLUP_CONFIG: ./.devnet/rollup.json OP_CHALLENGER_CANNON_L2_GENESIS: ./.devnet/genesis-l2.json OP_CHALLENGER_CANNON_BIN: ./cannon/bin/cannon OP_CHALLENGER_CANNON_SERVER: /op-program/op-program OP_CHALLENGER_CANNON_PRESTATE: /op-program/prestate.json OP_CHALLENGER_L2_ETH_RPC: http://l2:8545 OP_CHALLENGER_MNEMONIC: test test test test test test test test test test test junk OP_CHALLENGER_HD_PATH: "m/44'/60'/0'/0/4" OP_CHALLENGER_NUM_CONFIRMATIONS: 1

In the provided Devnet setup for the challenger node, the OP_CHALLENGER_UNSAFE_ALLOW_INVALID_PRESTATE: 'true' configuration essentially bypasses the verification of the prestat.. If we use the same setup in the mainnet, could it cause any issues? From what I can see, if this check is disabled, the next proposed output root seems to directly become the anchor state. If the proposer submits a valid output root, there shouldn't be any issues. However, is there any reason I might be overlooking?

Did you check for duplicate questions?

• Yes

Similar Questions or Issues Found

No response

Please select the type of request

• Bug Report
• Feature Request

Steps to Reproduce

No response

Expected vs. Actual Behaviour

No response

Software Versions

No response

Operating System

No response

Hardware Resources

No response

Configuration Files, Startup Flags & Environment Variables

No response

Error Messages / Logs

No response

Feature Description

No response

Purpose and Benefits

No response

Relevant Context or Examples

No response

[sbvegan]

If we use the same setup in the mainnet, could it cause any issues? From what I can see, if this check is disabled, the next proposed output root seems to directly become the anchor state.

You need to be using a valid absolute prestate for production networks i.e. Sepolia Testnets and Ethereum Mainnet

If the proposer submits a valid output root, there shouldn't be any issues. However, is there any reason I might be overlooking?

The issue is in a permissionless system, anyone can submit an output root. If an invalid root is posted and accepted; an attacker could drain the whole bridge.

[AaronLee22]

Got it! Thank you for a clear answer!