Snowbridge - Ethereum Client - Reject finalized updates without a sync committee in next store period#4478
Merged
Conversation
#145) * sync committee handover fix * remove comment * Update bridges/snowbridge/pallets/ethereum-client/src/lib.rs Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com> * add extra check * move checks around * remove extra validation * fix compiler error * reject updates in next period without sync committee * fix test * polish * Update bridges/snowbridge/pallets/ethereum-client/src/lib.rs Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com> --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
claravanstaden
marked this pull request as ready for review
May 16, 2024 07:38
Contributor
Author
|
@vgeddes @yrong @alistair-singh please review. |
vgeddes
approved these changes
May 16, 2024
svyatonik
approved these changes
May 16, 2024
svyatonik
left a comment
svyatonik
left a comment
Contributor
There was a problem hiding this comment.
The change itself is pretty clear and the issue is very similar to what we have in K<>P bridge - we've accepted the header without updating the authorities set (sync committee).
| )); | ||
| // check same header in the next period can now be submitted successfully | ||
| assert_ok!(EthereumBeaconClient::submit(RuntimeOrigin::signed(1), update.clone())); | ||
| let block_root: H256 = update.finalized_header.clone().hash_tree_root().unwrap(); |
Contributor
There was a problem hiding this comment.
Is it an intended removal? It looks like it should be fine even after the change?
acatangiu
approved these changes
May 16, 2024
acatangiu
enabled auto-merge
May 16, 2024 13:47
bkontur
approved these changes
May 16, 2024
Contributor
There was a problem hiding this comment.
when merged, we should backport to the all other release branches:
- release-crates-io-v1.7.0 - patch release the fellows BridgeHubs runtimes - @claravanstaden do you want to do it?
- release-crates-io-v1.8.0
- release-crates-io-v1.9.0
- release-crates-io-v1.10.0
- release-crates-io-v1.11.0
- release-crates-io-v1.12.0 (commit soon)
Contributor
Author
@bkontur I'll do all of the above, yes. I need to update the Ethereum client storage in the runtimes PR too. |
claravanstaden
added a commit
to Snowfork/polkadot-sdk
that referenced
this pull request
May 16, 2024
…c committee in next store period (paritytech#4478) While syncing Ethereum consensus updates to the Snowbridge Ethereum light client, the syncing process stalled due to error `InvalidSyncCommitteeUpdate` when importing the next sync committee for period `1087`. This bug manifested specifically because our light client checkpoint is a few weeks old (submitted to governance weeks ago) and had to catchup until a recent block. Since then, we have done thorough testing of the catchup sync process. ### Symptoms - Import next sync committee for period `1086` (essentially period `1087`). Light client store period = `1086`. - Import header in period `1087`. Light client store period = `1087`. The current and next sync committee is not updated, and is now in an outdated state. (current sync committee = `1086` and current sync committee = `1087`, where it should be current sync committee = `1087` and current sync committee = `None`) - Import next sync committee for period `1087` (essentially period `1088`) fails because the expected next sync committee's roots don't match. ### Bug The bug here is that the current and next sync committee's didn't handover when an update in the next period was received. ### Fix There are two possible fixes here: 1. Correctly handover sync committees when a header in the next period is received. 2. Reject updates in the next period until the next sync committee period is known. We opted for solution 2, which is more conservative and requires less changes. ### Polkadot-sdk versions This fix should be backported in polkadot-sdk versions 1.7 and up. Snowfork PR: #145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
claravanstaden
added a commit
to Snowfork/polkadot-sdk
that referenced
this pull request
May 16, 2024
…c committee in next store period (paritytech#4478) While syncing Ethereum consensus updates to the Snowbridge Ethereum light client, the syncing process stalled due to error `InvalidSyncCommitteeUpdate` when importing the next sync committee for period `1087`. This bug manifested specifically because our light client checkpoint is a few weeks old (submitted to governance weeks ago) and had to catchup until a recent block. Since then, we have done thorough testing of the catchup sync process. ### Symptoms - Import next sync committee for period `1086` (essentially period `1087`). Light client store period = `1086`. - Import header in period `1087`. Light client store period = `1087`. The current and next sync committee is not updated, and is now in an outdated state. (current sync committee = `1086` and current sync committee = `1087`, where it should be current sync committee = `1087` and current sync committee = `None`) - Import next sync committee for period `1087` (essentially period `1088`) fails because the expected next sync committee's roots don't match. ### Bug The bug here is that the current and next sync committee's didn't handover when an update in the next period was received. ### Fix There are two possible fixes here: 1. Correctly handover sync committees when a header in the next period is received. 2. Reject updates in the next period until the next sync committee period is known. We opted for solution 2, which is more conservative and requires less changes. ### Polkadot-sdk versions This fix should be backported in polkadot-sdk versions 1.7 and up. Snowfork PR: #145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
claravanstaden
added a commit
to Snowfork/polkadot-sdk
that referenced
this pull request
May 16, 2024
…c committee in next store period (paritytech#4478) While syncing Ethereum consensus updates to the Snowbridge Ethereum light client, the syncing process stalled due to error `InvalidSyncCommitteeUpdate` when importing the next sync committee for period `1087`. This bug manifested specifically because our light client checkpoint is a few weeks old (submitted to governance weeks ago) and had to catchup until a recent block. Since then, we have done thorough testing of the catchup sync process. ### Symptoms - Import next sync committee for period `1086` (essentially period `1087`). Light client store period = `1086`. - Import header in period `1087`. Light client store period = `1087`. The current and next sync committee is not updated, and is now in an outdated state. (current sync committee = `1086` and current sync committee = `1087`, where it should be current sync committee = `1087` and current sync committee = `None`) - Import next sync committee for period `1087` (essentially period `1088`) fails because the expected next sync committee's roots don't match. ### Bug The bug here is that the current and next sync committee's didn't handover when an update in the next period was received. ### Fix There are two possible fixes here: 1. Correctly handover sync committees when a header in the next period is received. 2. Reject updates in the next period until the next sync committee period is known. We opted for solution 2, which is more conservative and requires less changes. ### Polkadot-sdk versions This fix should be backported in polkadot-sdk versions 1.7 and up. Snowfork PR: #145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
claravanstaden
added a commit
to Snowfork/polkadot-sdk
that referenced
this pull request
May 16, 2024
…c committee in next store period (paritytech#4478) While syncing Ethereum consensus updates to the Snowbridge Ethereum light client, the syncing process stalled due to error `InvalidSyncCommitteeUpdate` when importing the next sync committee for period `1087`. This bug manifested specifically because our light client checkpoint is a few weeks old (submitted to governance weeks ago) and had to catchup until a recent block. Since then, we have done thorough testing of the catchup sync process. ### Symptoms - Import next sync committee for period `1086` (essentially period `1087`). Light client store period = `1086`. - Import header in period `1087`. Light client store period = `1087`. The current and next sync committee is not updated, and is now in an outdated state. (current sync committee = `1086` and current sync committee = `1087`, where it should be current sync committee = `1087` and current sync committee = `None`) - Import next sync committee for period `1087` (essentially period `1088`) fails because the expected next sync committee's roots don't match. ### Bug The bug here is that the current and next sync committee's didn't handover when an update in the next period was received. ### Fix There are two possible fixes here: 1. Correctly handover sync committees when a header in the next period is received. 2. Reject updates in the next period until the next sync committee period is known. We opted for solution 2, which is more conservative and requires less changes. ### Polkadot-sdk versions This fix should be backported in polkadot-sdk versions 1.7 and up. Snowfork PR: #145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
claravanstaden
added a commit
to Snowfork/polkadot-sdk
that referenced
this pull request
May 16, 2024
…c committee in next store period (paritytech#4478) While syncing Ethereum consensus updates to the Snowbridge Ethereum light client, the syncing process stalled due to error `InvalidSyncCommitteeUpdate` when importing the next sync committee for period `1087`. This bug manifested specifically because our light client checkpoint is a few weeks old (submitted to governance weeks ago) and had to catchup until a recent block. Since then, we have done thorough testing of the catchup sync process. ### Symptoms - Import next sync committee for period `1086` (essentially period `1087`). Light client store period = `1086`. - Import header in period `1087`. Light client store period = `1087`. The current and next sync committee is not updated, and is now in an outdated state. (current sync committee = `1086` and current sync committee = `1087`, where it should be current sync committee = `1087` and current sync committee = `None`) - Import next sync committee for period `1087` (essentially period `1088`) fails because the expected next sync committee's roots don't match. ### Bug The bug here is that the current and next sync committee's didn't handover when an update in the next period was received. ### Fix There are two possible fixes here: 1. Correctly handover sync committees when a header in the next period is received. 2. Reject updates in the next period until the next sync committee period is known. We opted for solution 2, which is more conservative and requires less changes. ### Polkadot-sdk versions This fix should be backported in polkadot-sdk versions 1.7 and up. Snowfork PR: #145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
This was referenced May 16, 2024
Contributor
Author
5 tasks
This was referenced Aug 21, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While syncing Ethereum consensus updates to the Snowbridge Ethereum light client, the syncing process stalled due to error
InvalidSyncCommitteeUpdatewhen importing the next sync committee for period1087.This bug manifested specifically because our light client checkpoint is a few weeks old (submitted to governance weeks ago) and had to catchup until a recent block. Since then, we have done thorough testing of the catchup sync process.
Symptoms
1086(essentially period1087). Light client store period =1086.1087. Light client store period =1087. The current and next sync committee is not updated, and is now in an outdated state. (current sync committee =1086and current sync committee =1087, where it should be current sync committee =1087and current sync committee =None)1087(essentially period1088) fails because the expected next sync committee's roots don't match.Bug
The bug here is that the current and next sync committee's didn't handover when an update in the next period was received.
Fix
There are two possible fixes here:
We opted for solution 2, which is more conservative and requires less changes.
Polkadot-sdk versions
This fix should be backported in polkadot-sdk versions 1.7 and up.
Snowfork PR: Snowfork#145