-
Notifications
You must be signed in to change notification settings - Fork 742
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
Encode Execution Engine Client Version In Graffiti #5290
Conversation
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.
Looks good! Just had a few 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!
e43db19
to
f85eeda
Compare
} | ||
} | ||
|
||
pub fn start_engine_version_cache_refresh_service<T: BeaconChainTypes>( |
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.
I'm not sure why we need to maintain a service to keep updating the version.
Why not instead do it once on startup, then do it in BeaconChain::prepare_beacon_proposer
. Updating something that doesn't change repeatedly seems quite wasteful to me
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.
We could do it there, but then it would happen right in window between notifying the EL that there's a proposal & actually proposing the block, which is a critical time. The whole reason I wrote it this way to avoid extra calls to the EL within that critical time.
Presumably we could have a service that only caches this result when we detect that we are connected to a validator which will have a proposal within the next epoch, but that code would surely be more complex that this service.
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.
I don't think that making a single call to an EL that returns a pre set value should be very intensive, but your point is fair. Better to not cram more calls than necessary just before a proposal.
} | ||
|
||
// this service should run 3/8 of the way through the epoch | ||
let epoch_delay = (epoch_duration * 3) / 8; |
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.
Why at 3/8?
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.
There are other scheduled tasks that take place at certain times in the epoch so I just picked a time that wouldn't overlap with them
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.
Tested this out with geth and it works as expected.
LGTM.
@mergify queue |
🛑 The pull request has been removed from the queue
|
@mergify requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
🛑 The pull request has been removed from the queue
|
@mergify requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
🛑 The pull request has been removed from the queue
|
# Conflicts: # beacon_node/beacon_chain/Cargo.toml
@mergify queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 4a48d7b |
Issue Addressed
Additional Info
All logic related to the choice of graffiti in the beacon node has been moved into:
beacon_node/beacon_chain/src/graffiti_calculator.rs
The
graffiti
field in theBeaconChain
object has been replaced by an instance ofGraffitiCalculator
. The correct graffiti is obtained by calling the following method onchain.graffiti_calculator
: