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