-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix the potentially inconsistent issue. #14700
base: develop
Are you sure you want to change the base?
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.
I think this makes sense. I wonder how it would work when a single beacon node is driving multiple execution layer clients:
- One Prysm instance drives both Geth and Reth. Geth supports get_blobs, but Reth does not
- Prysm connects to Geth first, then connects to Reth
- Prysm will not use get_blobs even though it could
Hi, From the code, it can be seen that after requesting If Reth returns |
Hi @terencechain A more likely scenario is that Geth runs on a version 1.14.12 for a while and then reverts to a version below 1.14.12 . Geth supports |
Please add a CHANGELOG entry if you would like this to merge. Thanks |
I've made the requested changes. Please take a look when you have a moment. Thanks. |
What type of PR is this?
Improvements
What does this PR do? Why is it needed?
If the endpoint parameter of the execution layer specifies a domain name, for example: --execution-endpoint=http://execution-domain:8551, and the execution layer clients corresponding to the domain name include Geth and Reth, then when Reth client is accessed first and the list of capabilities obtained contains
engine_getBlobsV1
. However, when the connection is reconnected to Geth client,engine_getBlobsV1
is not removed fromcapabilityCache
, which may lead to unexpected results.Acknowledgements