MARF'ed Nakamoto chainstate #4930
Merged
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
… actually higher than the memoized fork, and also, add get_nakamoto_tip_block_id() to SortitionHandle to facilitate querying the canonical Nakamoto tip
… chains coordinator requires querying it from the canonical fork memoized in the sortition DB. The reason I think this is safe here (and only here) is because forks can't happen arbitrarily. The memoized tip at the end of the prepare phase is practically guaranteed to point to the same reward set on all nodes, since the reward set is calculated at the start of the prepare phase.
…m elsewhere), and use malleablized blocks in the 10-sortitions-with-10-blocks-and-extensions test
…ecifically by a block ID must be carried out relative to a designated chain tip. Adds support for MARF'ing all the data for all affected methods, and rewrites all affected methods to use it.
… obtain method for blocks, and rewrite all methods to use the MARF for queries that are not specific to a block ID
… field and change its primary key. A tenure is recorded for a given block with a tenure change.
…t battery in TestPeer
… test, so we can simulate the presence of multiple (!!) nakamoto forks per Bitcoin fork and verify that the node still behaves correctly. Also, add torture tests for MARF'ed methods, to be performed for each processed block.
…rt block in the clarity VM
…hainstate within a particular fork, and deduce when we're ready to process unconfirmed tenures by the absence of confirmed tenure downloaders
|
So, the |
ASuciuX
reviewed
Jul 11, 2024
…hatever was stored first (doing anything else will break malleablized block tests)
kantai
reviewed
Jul 11, 2024
kantai
reviewed
Jul 11, 2024
kantai
reviewed
Jul 11, 2024
…state DBs since a node may be stopped and restarted during genesis sync (and failure to accept DB version 6 would lead to a panic)
kantai
reviewed
Jul 11, 2024
kantai
approved these changes
Jul 11, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This PR addresses #4810 and #4900 by computing the block hash of a Nakamoto block as its signer sighash. That is, Nakamoto blocks no longer commit to signer signatures. This change vastly simplifies the task of the signers to agree on whether or not a block is part of the canonical fork -- they do not need to agree on which of them signed and which did not, and they can compute a valid block signature by obtaining a threshold of any set of signatures independently of the miner.
In addition, this PR addresses block malleability by MARF'ing the Nakamoto chainstate. Now, queries on tenures, tenure-start blocks, and other chainstate data that is not directly keyed to a specific Nakamoto block are carried out relative to a Nakamoto chain tip. The chainstate DB now tracks per-fork data about tenures, instead of naively assuming that there will be one valid history of tenure-changes per Bitcoin fork.
This change makes the Stacks blockchain much more robust in the face of Nakamoto forks, which can arise for unavoidable but benign reasons, such as when a tenure-start block for a short-lived sortition is being processed concurrently with a new sortition (in which case, the orphaned tenure-start block would be accepted into the chainstate even though it conflicts with a Nakamoto block at the same height). Furthermore, should there ever arise multiple Nakamoto forks for any reason (due to a bug, a policy, or a benign cause), the node's chainstate will remain in a consistent and usable state.
In doing so, this change completely separates policy from mechanism regarding fork selection. It places the burden of deciding which Nakamoto forks can be built upon exclusively on the signers (a policy), and makes the Stacks node amenable to handling any such forks regardless of how they arise, without complaint (a mechanism for effecting a fork-choice policy).