-
Notifications
You must be signed in to change notification settings - Fork 497
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
Consensus pushes finality data to Execution. Execution sets finalized block in blockchain #2936
Conversation
f57d7be
to
cbc3407
Compare
As a suggestion from Tsahi, I will include the behavior implemented in #2927 in this PR |
2adbc2c
to
c5f1cf8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally seems good. A few small comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments for separate PR
type FinalityData struct { | ||
FinalizedMsgCount MessageIndex | ||
SafeMsgCount MessageIndex | ||
ValidatedMsgCount *MessageIndex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
separate PR: we should also have block-hashes for all of these, to make sure weird race conditions don't make us finalize a reorged-out block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This possible inconsistency is more likely to happen with safe blocks than finalized.
It seems that geth doesn't update safe and finalized blocks in case of reorgs BTW.
ConsensusExecutionSyncer will periodically push finality data to execution, so this inconsistency will eventually disappear.
But it makes sense to add those hashes that you mentioned, considering that SetSafe and SetFinalizes will be called holding ExecutionEngine.createBlocksMutex.
I will create a linear task to handle those issues.
16a53fc
…id inconsistencies
16a53fc
to
b6ef1a4
Compare
@@ -263,6 +263,7 @@ type NodeBuilder struct { | |||
withProdConfirmPeriodBlocks bool | |||
wasmCacheTag uint32 | |||
delayBufferThreshold uint64 | |||
useFreezer bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
separate PR: is there actually a good reason to ever set that to false? If not, can remove the config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TestDatabaseConversion fails when freezer is used.
Created a linear task to handle that.
Resolves NIT-2627 and NIT-2585.
Today execution polls finality data from consensus.
With this PR consensus pushes finality data to execution, which avoids a circular dependency between consensus and simple execution (execution without sequencer behavior, for example).
Also, with this PR Execution starts setting the finalized block into the blockchain.
This enables go-ethereum to move blocks from the fast database to the ancients only if they are finalized, or if they are older than
HEAD-params.FullImmutabilityThreshold
.params.FullImmutabilityThreshold
is set to 90000 by go-ethereum today.Pulls OffchainLabs/go-ethereum#411