-
Notifications
You must be signed in to change notification settings - Fork 222
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
beacon rpc sometimes returns LightClientFinalityUpdate with sync_committee length < 2/3 #5491
Comments
When new finality is reached without supermajority sync committee support, trigger another event push on beacon-API and libp2p once the new finality gains supermajority support. Without this, if the first `LightClientFinalityUpdate` that advances finality has low participation, light clients monitoring gossip would likely get stuck until the next time when finality advances (1 epoch). Thanks to @DragonDev1906 for reporting this issue to Nimbus: - status-im/nimbus-eth2#5491
|
You can check the next block ( For example, https://prater.beaconcha.in/slot/6709376 contains the Keep in mind that the Goerli network is soon deprecated, Sepolia / Holesky should have better performance in that regard. |
You're right. I wasn't expecting the specs to say that For some reason I expected The spec even says this (apparently I can't read):
Yeah, that's why I'm currently testing on both Goerli and Sepolia. Higher chance to get unexpected or not quite normal situations that still can happen. Footnotes |
With #5602 ( Can also try in browser / curl (but have to wait ~5-10 mins for finality to advance to see something) |
Describe the bug
When requesting a
LightClientFinalityUpdate
via the beacon_chain RPC the endpoints sometimes returns an update with only a few entries in the sync committee (as shown in the screenshots). I'm not sure if this is a bug in Nimbus, but I can't think of anything where such a FinalityUpdate would be useful.According to the consensus specs light clients should:
process_light_client_update
),store.best_valid_update
store.current_max_active_participants
if the update has more participants set (which should never get this low),LightClientOptimisticUpdate
andPlease correct me if I understood something wrong in the consensus specs or if there is another reason why
LightClientFinalityUpdate
with less than 2/3 of the sync committee would be useful. My current best guess is that it isn't useful at all and probably shouldn't be returned by the/eth/v1/beacon/light_client/finality_update
rpc endpoint. I can easily check for the sync committee size to avoid this issue, instead of just checking the finalized blocknumber, which I mainly do to avoid unnecessary communication internally (I don't care about the optimistic updates/blocks/data).I don't know if this also affects the subscription (I'll likely change it to use the subscription at some point, but for now I'm polling the rpc endpoint).
It could of course also be that my script is wrong and doesn't decode the sync committee correctly, hence the question of whether I understood something wrong when reading the consensus-specs.
To Reproduce
Steps to reproduce the behavior:
I additionally gives these updates to a light client if the finalized block number changed. Sometimes this then didn't apply the update, which is how I found this.
Screenshots (logs from my application)
![2023-10-10-192557_623x596_scrot](https://private-user-images.githubusercontent.com/8270201/274011607-8666f944-2f04-45da-a565-3121fcf90af3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjYxMzUwNTAsIm5iZiI6MTcyNjEzNDc1MCwicGF0aCI6Ii84MjcwMjAxLzI3NDAxMTYwNy04NjY2Zjk0NC0yZjA0LTQ1ZGEtYTU2NS0zMTIxZmNmOTBhZjMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTJUMDk1MjMwWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NWIyYTdmZTJjMjA1NzQwN2Y4YThlNDQ4MTY4OTAwZmFlYjE2ZjRhMzFkZTlhZWU1NzA3YzE4NzgwZmRhZmIzZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.7Zc-m_tkik11C7QqeXJC9UdAB5nlZzFzlgdnRGkoAQg)
Log output of an application polling the RPC endpoint every 12 seconds and outputting the sync committee size:
Log output showing the situation I've found: A finality update with <2/3 sync_committee (the first one I received with a new
![2023-10-10-195051_1619x304_scrot](https://private-user-images.githubusercontent.com/8270201/274016648-21aeff5d-2944-4a6c-8e19-9b86d0815409.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjYxMzUwNTAsIm5iZiI6MTcyNjEzNDc1MCwicGF0aCI6Ii84MjcwMjAxLzI3NDAxNjY0OC0yMWFlZmY1ZC0yOTQ0LTRhNmMtOGUxOS05Yjg2ZDA4MTU0MDkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTJUMDk1MjMwWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ODQwOTYyZWY4NTBjNzcxN2I4MjAwMzlkM2E1NjBhZmNhMzNmZjFhMzc3YzY4YTY5MmQzOGRjYTNlYzVjODczNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.XRz01atG7ww8BLdfabb7oLtzXV0nMqoFeVgxqphUsbI)
finalized_header..execution.block_number
), together with debug logs of the light client showing that the sync committee was the reason that the update was not applied.Additional Info
This seems to happen quite regularly, most Epochs give me a FinalityUpdate with less than 2/3 sync committees.
The text was updated successfully, but these errors were encountered: