chain: Revalidate blocks for new deployments. #2878
Conversation
That is also what I was considering doing at first. However, when working on the implementation, it became apparent that the activation height of newer versions matters when determining which version to say a block was invalidated under. For example, if we are running on software that only knows about an older version, and some blocks are invalidated both before and after a newer version is activated (that the older software doesn't know about), then all of the blocks would still be marked as invalidated under the older version. Then when the new software clears the invalidation flags, it would still need to know the activation height of the newer version if we don't want to blindly revalidate everything marked as invalid under the prior version. For that reason, and also since it simplifies the solution quite a bit, I didn't see much added value in storing it per block. |
020e7e3 to
e0b251c
Compare
There was a problem hiding this comment.
Nice work on this overall. It lines up with what we discussed about making use of the defined deployments and such.
I identified a couple of nits inline, but the logic is sound and I've tested that it works as intended via simnet (along with some minor code modifications needed to define deployments).
e0b251c to
aefa164
Compare
This adds a currentDeploymentVersion helper function, which returns the highest deployment version that is defined in the given network parameters.
This adds a nextDeploymentVersion helper function, which returns the lowest deployment version defined in the given network parameters that is higher than the provided version.
This adds dbPutDeploymentVer and dbFetchDeploymentVer functions to put and fetch the deployment version from the database.
This adds tracking of the current deployment version to the database. During initialization, the deployment version is updated to the current version as necessary.
This adds a newDeploymentsStartTime helper function, which returns the earliest start time of newly detected deployment versions.
This adds functionality to unmark blocks that were previously marked failed if their median time is after the earliest possible start time of newly detected consensus rules. This ensures clients that did not update prior to new rules activating are able to automatically recover under the new rules without having to download the entire chain again.
aefa164 to
c2a5990
Compare
This adds functionality to automatically unmark blocks that were previously marked as failed when new consensus rules are detected. It is split into several commits to ease the review process. An overview of the approach to do this is as follows:
Closes #2766.