Snowbridge - Ethereum Client - Reject finalized updates without a sync committee in next store period #4478
Conversation
This file contains 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
#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>
|
@vgeddes @yrong @alistair-singh please review. |
vgeddes
approved these changes
May 16, 2024
svyatonik
approved these changes
May 16, 2024
| assert_ok!(EthereumBeaconClient::submit(RuntimeOrigin::signed(1), update.clone())); | ||
| let block_root: H256 = update.finalized_header.clone().hash_tree_root().unwrap(); |
There was a problem hiding this comment.
Is it an intended removal? It looks like it should be fine even after the change?
There was a problem hiding this comment.
Good point! Added back in 9fdcef3.
acatangiu
approved these changes
May 16, 2024
bkontur
approved these changes
May 16, 2024
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)
@bkontur I'll do all of the above, yes. I need to update the Ethereum client storage in the runtimes PR too. |
Merged
via the queue into
paritytech:master
with commit May 16, 2024
943eb46
152 of 154 checks passed
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
5 tasks
hitchhooker
pushed a commit
to ibp-network/polkadot-sdk
that referenced
this pull request
Jun 5, 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: Snowfork#145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 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: Snowfork#145 --------- Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com>
This was referenced Aug 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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