Support the Arbitrum BOLD Challenge Protocol in Nitro

[amsanghi]

Background

This PR includes the Arbitrum BOLD challenge protocol as part of a Nitro node, enabled optionally. The goal is to have Nitro master capable of supporting BOLD challenges on Arbitrum Sepolia once the upgrade occurs and on the existing BOLD testnet.

BOLD, standing for Bounded Liquidity Delay, is a protocol for resolving disputes over execution of the Arbitrum inbox. The BOLD protocol allows for permissionless validation of Arbitrum One and Nova. It also ensures an upper-bound on withdrawal delays from L2 to L1.

To learn more about the basics of BOLD, see the gentle introduction here, or the research paper here. A presentation explaining what the BOLD software does and how it works can be found here

BOLD Software Responsibilities

BOLD is a modular component of Nitro nodes that can do the following tasks:

1. Continuously post assertions about executing the Arbitrum inbox to BOLD rollup contracts on Ethereum
2. Challenge posted assertions that are invalid from the honest validator's perspective
3. Participate in challenge games to completion as an honest validator
4. Confirm assertions that are confirmable by time or by challenge win

All of these responsibilities are performed by the BOLD challenge manager service, which is currently included as a git submodule of Nitro, with its git repository OffchainLabs/bold, with long term plans to port it fully intro Nitro.

Supporting BOLD in Nitro

In order for Nitro to support this BOLD module, Nitro has to provide a dependency to the bold challenge manager that defines the following methods:

We implement these methods in staker/bold_state_provider.go and also add a new RPC method to the validation node called GetMachineHashesWithStepSize that can execute an Arbitrator machine at a start program counter and collect machine hashes in increments of step_size as required by BOLD.

We also implement a new challengecache package which can cache hashes retrieved from the validation node in a filesystem hierarchy for fast access by the Nitro node during BOLD challenges. This cache is required for efficient computation of challenge moves, and is a new addition. It stores hashes as bytes in files nested by challenge level hierarchy.

Switching from Old Protocol to BOLD at Runtime

To change from the old staker to the BOLD staker at runtime, we provide a new service called MultiProtocolStaker, which holds a reference to the old, L1 staker, and the new BOLD staker and can swap to BOLD once it is supported. The way it works is it checks if the rollup contract supports a certain method called ExtraChallengeBlocks. If the method is unsupported, the Nitro validator should be switching to BOLD.

Changelog Summary

Git / Deps

• Includes BOLD as a submodule
• Adds BOLD to go.mod and upgrades go-ethereum version to v1.12.0

Arbitrator

• No changes included to Arbitrator, however, BOLD benefits greatly from @eljobe's work on Merkleization optimizations

Nitro Node

• Adds a BOLD StakeToken address field to the L2 chain info JSON
• Initializes a MultiProtocolStaker instead of a Staker which is aware of BOLD and can switch protocols
• Adds a challengecache package to cache hashes obtained from validation node computation to be used when making moves in BOLD

Validation Node API

• Defines a GetMachineHashesWithStepSize method that can execute Arbitrator machines at specific program counters, step through them in custom step sizes, and collect machine hashes along the way

Multi Protocol Staker Definition

• Adds a multi protocol staker that is aware of BOLD being activated on the parent chain and can switch to it while stopping the old protocol staker

Testing

• Defines a system test called TestChallengeProtocolBOLD which runs a complete challenge, with an L1 node two different L2 nodes disagreeing about the execution of a certain batch posted to the Arbitrum inbox. It uses the BOLD dispute protocol to fully resolve the challenge
• System test called TestChallengeProtocolBOLD_StateProvider which tests the invariants of the bold_state_provider.go implementation needed by the BOLD challenge manager

Missing Features

• Merkleization optimizations from other PRs
• Supporting Redis streams for scaling validation node requests

[tsahee]

ound these were still "pending" sorry

[tsahee]

not clear when previousGlobalState can or cannot be nil.
Really not clear why batchIndex is maxInboxCount - 1 if previousGlobalState is nil, and we have to search for batch number otherwise

[amsanghi]

@rauljordan I am bit fuzzy on this side, can you please help with a bit on clarifying?

[tsahee]

not clear to me what exactly it does
should it be separated to two funcs - onw that always gets previousGlobalState and one that never does?

[amsanghi]

I have reworded the comment to make it a bit more clearer.
I think we had it as separate functions earlier but then we had too many api b/w Bold and nitro.
Though I guess we could revisit this decision again considering the current state.
@rauljordan cc

[tsahee]

@rauljordan do I underand correctly that previousBlockGlobalState = nil only when there is no previous correct assertion? (as seems to be suggestion because fromBatch = 0)?
If so, shouldn't we still be limited by maxNumberOfBlocks?
Or are there two ways to post the same assertion (either from prev. confirmed or from 0)?
This should be clarified, at least in comments.

[rauljordan]

Hey guys, I think this needs to be reworked as it is doing too much. One of the complex parts of this is that we need to:

1. Produce the execution state that follows a previous state, as the prev state determines how many inbox messages the next state should consume
2. Be careful around the max number of blocks limit, and if we reach it, we need to provide a correct assertion for that
   This function was an attempt to push less responsibility onto the caller, but we might want to retrace that for the sake of safety and clarity