-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the Arbitrum BOLD Challenge Protocol in Nitro #2362
base: master
Are you sure you want to change the base?
Conversation
… into sepolia-tooling-merge
… into sepolia-tooling-merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ound these were still "pending" sorry
} | ||
return nil, err | ||
} | ||
if previousGlobalState != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rauljordan I am bit fuzzy on this side, can you please help with a bit on clarifying?
// Produces the L2 execution state to assert to after the previous assertion state. | ||
// Returns either the state at the batch count maxInboxCount or the state maxNumberOfBlocks after previousBlockHash, | ||
// whichever is an earlier state. If previousBlockHash is zero, this function simply returns the state at maxInboxCount. | ||
// TODO: Check the block validator has validated the execution state we are proposing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- Produce the execution state that follows a previous state, as the prev state determines how many inbox messages the next state should consume
- 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
… blocks are valid
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:
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 calledGetMachineHashesWithStepSize
that can execute an Arbitrator machine at a start program counter and collect machine hashes in increments ofstep_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 calledExtraChallengeBlocks
. If the method is unsupported, the Nitro validator should be switching to BOLD.Changelog Summary
Git / Deps
Arbitrator
Nitro Node
StakeToken
address field to the L2 chain info JSONMultiProtocolStaker
instead of aStaker
which is aware of BOLD and can switch protocolschallengecache
package to cache hashes obtained from validation node computation to be used when making moves in BOLDValidation Node API
GetMachineHashesWithStepSize
method that can execute Arbitrator machines at specific program counters, step through them in custom step sizes, and collect machine hashes along the wayMulti Protocol Staker Definition
Testing
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 challengeTestChallengeProtocolBOLD_StateProvider
which tests the invariants of thebold_state_provider.go
implementation needed by the BOLD challenge managerMissing Features