Skip to content
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

Bold fixes #2770

Open
wants to merge 25 commits into
base: bold-review
Choose a base branch
from
Open

Bold fixes #2770

wants to merge 25 commits into from

Conversation

eljobe
Copy link
Member

@eljobe eljobe commented Nov 5, 2024

These changes clean up a few problems with the BoLD implementation and add some test coverage for some missing cases and also the fixes for them.

Specifically, there were two important problems that are now fixed:

  1. There was a off-by-one error when calculating the hashes for history commitments.
  2. There was a problem where if a challenge was created in the virtual leafs of this validators block-level commitment (because the rival was attesting to a larger list of blocks, but agreed with all of the real leaves of this validator's commitment) this validator would be incorrect when trying to produce history commitments and inclusion proofs for non-existing block numbers.

Both have been fixed and we're growing more confident that this is all working.

eljobe and others added 18 commits October 23, 2024 17:17
This is just a commit on a branch to give Lee a picture of where
Pepper was when he stopped trying to get the bold-review branch's
tests passing again.

Essentially, I think there is at least one (but maybe several)
off-by-one issues with the current implementation in the
bold_state_provider.

I would recommend trying to get the
`bold_state_provider_test.go` (specifically,
`TestChallengeProtocolBOLD_StateProvider`) to pass before moving to
the other tests. I think it is attempting to validate more
tightly-scoped behavior than the other tests in this package.

BTW, I'm not actually 100% confident that the whole system is wired
together correctly before calling the state provider. But, I do
believe that errors there are less-likely than in the
implementation. In my heart, I think Raul had these tests passing at
some point in history. We probably just silently broke them and never
noticed.

Thanks for looking into this.
The big problem is still the end-to-end TestChallengeProtocolBOLD
test.
Now that the virtual padding is handled in the BoLD protocol itself
and not in the creation of the hash leaves being fed into the history
committer, the number of hashes read from the cache doesn't need to
equal the number of leaves (including virtual leaves.)
This is the current unify-req-meta branch which fixes a bug in
one-step proof calculation.
This *should* be able to wrap an arbitrator machine and do the special
handling for the BoLD protocol to make it look like there is one more
machine state at the front of processing a machine.
This still doesn't get the test passing, but it's bound to be closer.
The CollectProof and CollectMachineHashes functions were both susceptible to
challenges where it was possible that the rival would have committed to more
messages than this validator. And, in that case, it would attempt to look up a
message number which was greater than the highest messge number it had verified
as part of the batch in which the challenge originated.
Before this change, if there was a block challenge at a height in any block
above the batchLimit, then the validator was not correctly creating inclusion
proofs because it was attempting to fetch execution results for blocks which
didn't really exist.

Now, the code detects that situation and simply returns the hash of an
arbitrator machine in the FINISHED state (since the Virtual leaf hashes) are all
in that state by virtue of their being repeated copies of the end state of a
block.
@cla-bot cla-bot bot added the s Automatically added by the CLA bot if the creator of a PR is registered as having signed the CLA. label Nov 5, 2024
eljobe and others added 7 commits November 6, 2024 15:28
Previously, they couldn't produce correct inclusion proofs for block-level
challenges on blocks in the virtual range. That is to say, if this validaotor
processed n L2Blocks when creating an assertion and a rival processed >= n+1
L2Blocks, this validator would attempt to lookup a block index for which no
real block existed.

Now, the code properly catches this case and the last machine state for the last
real block is used for all virtual L2Blocks.
This is probably not where we ultimately want to be. Too much boilerplate is
escaping from the bold system. Maybe, before introducing a dependency injection
framework, I should just introduce something manual that would instatiate all
the instances that the challenge manager, watcher, assertion manager, etc. need
and then wires them together in the "default" way using the constructors from
each package.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s Automatically added by the CLA bot if the creator of a PR is registered as having signed the CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants