Update database and block replayer to handle payload envelopes#8886
Open
michaelsproul wants to merge 6 commits intosigp:unstablefrom
Open
Update database and block replayer to handle payload envelopes#8886michaelsproul wants to merge 6 commits intosigp:unstablefrom
michaelsproul wants to merge 6 commits intosigp:unstablefrom
Conversation
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Issue Addressed
Closes:
Proposed Changes
BlockReplayerto support replay of execution payload envelopes.HotColdDBto load payload envelopes and feed them to theBlockReplayerfor both hot + cold states.StatePayloadStatusto allow callers to specify whether they want a state with a payload applied, or not.Additional Info
Still need to thread
StatePayloadStatusthrough some of theget_statemethods. Will look at this tomorrow and try to minimise the number of APIs changed.We need to decide how to handle the last payload when replaying. For intermediate payloads we are leaning hard on
is_parent_block_full, but for the last block in the chain we do not know its child to determine if it is full. We probably need the caller of the block replayer to specify whether they want/expect to replay the payload for the last block in the chain.Testing this PR is a little tricky, because block production in the test harness isn't implemented yet (see #8844). It's slightly circular, where we can't test until we have the feature implemented, but we would also ideally like to test the feature before merging it. I think it might be OK to merge this PR first untested, then layer on a second PR (possibly #8844) for the test harness updates. Some of those updates were also made in: #8878.