-
Notifications
You must be signed in to change notification settings - Fork 897
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
When on PoS the head can be only be updated by ForkchoiceUpdate #4013
When on PoS the head can be only be updated by ForkchoiceUpdate #4013
Conversation
…sals until we get a forkchoice updated Signed-off-by: garyschulte <garyschulte@gmail.com>
Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com>
Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com>
Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com>
…Block When executing a newPayload or build a new block, we do not need to move the chain head and update the world state, since this will be done by a following forkchoice update call, but we still need to validate the block and doing so we can also prepare everything for the future call, so we do not need to re-execute everything, but only update the pointers, so that the response to the forkchoice update call is quick. Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
… nothing Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
It moves head to the block sent by a previous newPayload, and triggers the advanced head event that will also update the Bonsai world state. Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
…te-without-saving2 # Conflicts: # consensus/merge/src/main/java/org/hyperledger/besu/consensus/merge/blockcreation/MergeCoordinator.java # consensus/merge/src/main/java/org/hyperledger/besu/consensus/merge/blockcreation/MergeMiningCoordinator.java # consensus/merge/src/main/java/org/hyperledger/besu/consensus/merge/blockcreation/TransitionCoordinator.java # gradle.properties
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Karim TAAM <karim.t2am@gmail.com>
Signed-off-by: Karim TAAM <karim.t2am@gmail.com>
Signed-off-by: Karim TAAM <karim.t2am@gmail.com>
…MemoryWorldState Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
ethereum/core/src/main/java/org/hyperledger/besu/ethereum/bonsai/BonsaiPersistedWorldState.java
Fixed
Show fixed
Hide fixed
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: garyschulte <garyschulte@gmail.com>
Signed-off-by: garyschulte <garyschulte@gmail.com>
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 clarifies a lot!
@@ -50,6 +51,7 @@ | |||
import com.google.common.annotations.VisibleForTesting; | |||
import com.google.common.collect.Lists; | |||
import com.google.common.collect.Streams; | |||
import org.jetbrains.annotations.NotNull; |
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.
accidental import?
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.
it isn't clear whether this was here for static analysis during development or if it was intended as a runtime validation. Regardless, the ci/cd pipeline doesn't do anything with intellij static analysis annotations, so I will remove this and we can circle back with @fab-10 to see if he intended to use javax.annotation.* or javax.validation.constraints.*
Signed-off-by: garyschulte <garyschulte@gmail.com>
* When executing a newPayload do not move the chain head or update the world state * When proposing a block, use a lightweight validation, without storing * forwardToBlock moves head to the block and triggers advanced head event * Do not persist prepared blocks Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net> Co-authored-by: garyschulte <garyschulte@gmail.com> Co-authored-by: Jiri Peinlich <jiri.peinlich@gmail.com> Co-authored-by: Karim TAAM <karim.t2am@gmail.com>
49e4fd8 -> worldstate not avail (#4069) 6aa8812 -> stateroot mismatch (#4041) 043191a -> jwt auth on websockets (#4039) 90f891b -> do not move head on exec and propose (#4013) 3baa4da -> upgrade for websockets (#4019) 5024c07 -> sepolia TTD (#4024) 5ee9be8 -> heal step in snap (#3920) 261b1e0 -> remove peer block height requirements (#3911) Signed-off-by: garyschulte <garyschulte@gmail.com>
49e4fd8 -> worldstate not avail (#4069) 6aa8812 -> stateroot mismatch (#4041) 043191a -> jwt auth on websockets (#4039) 90f891b -> do not move head on exec and propose (#4013) b5fa62c -> sync check before processing remote transactions (4035) 3baa4da -> upgrade for websockets (#4019) 5024c07 -> sepolia TTD (#4024) 5ee9be8 -> heal step in snap (#3920) 261b1e0 -> remove peer block height requirements (#3911) Signed-off-by: garyschulte <garyschulte@gmail.com>
…rledger#4013) * When executing a newPayload do not move the chain head or update the world state * When proposing a block, use a lightweight validation, without storing * forwardToBlock moves head to the block and triggers advanced head event * Do not persist prepared blocks Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net> Co-authored-by: garyschulte <garyschulte@gmail.com> Co-authored-by: Jiri Peinlich <jiri.peinlich@gmail.com> Co-authored-by: Karim TAAM <karim.t2am@gmail.com>
PR description
When executing a newPayload or build a new block, we do not need to move
the chain head and update the world state, since this will be done by a
following forkchoice update call, but we still need to validate the block
and doing so we can also prepare everything for the future call, so we do
not need to re-execute everything, but only update the pointers, so that the
response to the forkchoice update call is quick.
Moreover on block proposal do only a validation of the block without storing or remembering nothing, to avoid saving data that could be stale, for example the empty block that is always proposed, is useless if another better block is produced later.
Signed-off-by: Fabio Di Fabio fabio.difabio@consensys.net
Fixed Issue(s)
fixes #3957
Documentation
doc-change-required
label to this PR ifupdates are required.
Changelog