Unify HistoryCommitmentRequest assertion metadata #697
+1,153
−1,008
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is not a 100% endorsement of these tests correctly testing the correct implementation. It is more a snapshot at which they are once again exercising the current implementation on the branch.
eljobe
force-pushed
the
unify-req-meta
branch
from
0721244
to
0b91f28
Compare
The problem with using the claimed assertion's `AfterState.Batch` is that, in the case of assertions which overflow the maximum number of blocks for an assertion, the `AfterState.Batch` will be lower than the actual upper limit on batches. And, if a history commitment is calculated based on that lower limit, it might not include all of the blocks to which the assertion should commit.
PlasmaPower
commented
Oct 25, 2024
PlasmaPower
commented
Oct 25, 2024
eljobe
reviewed
Oct 28, 2024
The problem with removing it is that the history commitments don't always commit to leaves starting from the first leaf, `FromHeight=0`. When there is a bisection, of a challenge edge, the history commitment of one edge should be `FromHeight=0` `UpToHeight=(parentHeight/2)+1` and the second edge should be `FromHeight=(parentHeight/2)+1` and `UpToHeight=parentHeight`.
This change also updates the documentation to explain why the FromHeight may never have a value other than 0, and it simplifies the code around calculating how many hashes are needed, and at which opcode the machine hash computation should start.
This will keep us from colliding if there are history commitments requeseted starting from different messages in the sequencer inbox in the same batch. This most commonly happens when handling overflow assertions.
This commit makes two minor improvements to logging: 1. When the tracker is unable to submit a one step proof, it now logs at the Error level instead of Trace. 2. When the watcher logs events, it also includes the validator name.
Without this, the tracker would post twice the number of one-step proofs as needed for correct behavior. That would be wasteful of gas.
It turns out that most of the information in the AssociatedAssertionMetadata is needed in various places in the correct implementation of the state provider. So, go ahead and pass it through.
Before this change, there were some flaky tests in the assertion manager package. In part, this was because it was difficult to reason about the responsibilities of each component. Some of the work that the assertion manager was doing by making calls to its logical parent (the challenge maanger) has been moved up to the challenge manager with a very narrow interface remaning between the two. Also, the construction of the challenge manager and its dependencies has been slightly decoupled. Now the challenge manager takes in an almosst completetely constructed assertion manager and registers itself as the RivalHandler for the assertion manager. It also sets the correct address for the assertion manager which is still being fetched from an on-chain contract during the construction of the challenge manager. But, this can also be pulled out in a future commit and passed into both objects (as well as the watcher and tracker objects.) Another small code-quality improvement was pulling out the configuration that affects the timing of various things the assertion manager is responsible for into a separate private `times` struct helps to document the behavior of those timers and also makes it easier to pass consistent values when testing. Next up, I'd really like to pull some of the other types which are currently being constructed during the construction of a challenge manager out and improve on our ability to share the wiring across objects.
These were all good catches. Remmber to check your errors boys and girls.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Unifies a few fields about the Assertion being challenged into a struct that can be used in place of individually passing around the fields.
This PR also cleans up some tests and restricts the expressiveness of HistoryCommitmentRequests to always begin at the first index (0) relative to the challenge level for which the commitment is being requested. The edge tracker component (which is the main place from which history commitments are requested never needs a history commitment that doesn't start at the first machine state hash relative to challenge level.) This also simplifies a couple of utility methods related to calculating machine hash ranges.