[DOCS] Verify --l1-eth-rpc challenger config

[bradleycamacho]

Summary: In our Challenger configuration doc section we mention that --l1-eth-rpc can be a full node. We need to verify the safety of this and share any risks and mitigation.

Original request:
Hey friends, we noticed in the Configure Challenger docs that it is fine to use a full node for the L1 ETH RPC. We just wanted to check if there's any potential risks in doing so. e.g. If a dispute game wasn't created for an L2 block for quite some time, and was then suddenly created for a very old block.

Acceptance criteria:

• Confirmed that a full node can be used
• Researched risks of using a full node and included them in the configuration doc
• Mitigation or risk assessment of any risks added to config doc
• Reach out to Bradley or Soyboy to share this info with original requester

Additional context:

Adrian's response to the original request:

Short version - yes a full node for L1 is fine, but make sure it doesn't prune receipt data too aggressively (most clients keep back to when the validator deposit contract was deployed since beacon nodes read those receipts but Nethermind in particular can be a bit aggressive about pruning). We use full L1 nodes in our systems.
You need an op-geth archive node with safe head enabled and using the hash scheme for L2.
In detail:
Historic world state is not required for L1 - the DisputeGameFactory and FaultDisputeGame contracts store all the required info in their latest state.
To execute cannon it may need older receipt data (normally available for full nodes but some clients don't store the full history of receipts) and may need older blobs.
From the L2 you need older world state data, blocks, receipts and safe head db (the --safedb.path option should be enabled on op-node prior to syncing).
For what "older" means in all of that, it depends on how recent the anchor state is. Each time a game resolves as valid it bumps up the anchor state so if you're proposing regularly and games are resolving normally typically the anchor state is ~3.5 days old, but obviously if there's a problem proposing or you're using a game type that isn't used as often it could be much older.
The the derivation process may read data from L1 up to about 12 hours prior to the L1 origin of that L2 block. So normally you need L1 receipts back about 4 days.
The same period applies to L2 data for running cannon but currently retrieving the output root requires reading from world state at that block, so for dispute-mon and challenger to monitor games they need L2 world state going back further - by default they monitor the last 28 days of games (by which time they will have resolved and had bonds repaid etc). So you need that much L2 world state history. This means you can use "partial" archive L2 nodes by snap syncing a node then running it with gcmode=archive for 30 days and it will then be able to handle all requests. It's fairly high touch but you can rotate nodes in an out of service to wipe and re-snap sync them to reduce the database size. I'd still recommend keeping one full archive node around just in case your rotation goes wrong somehow.