Skip to content
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

accept any new sidechain block from authorized enclave for shard #236

Merged
merged 1 commit into from
Dec 22, 2023

Conversation

brenzi
Copy link
Contributor

@brenzi brenzi commented Dec 22, 2023

closes #235

the previous logic where validateers had to announce their next block to be expected was too brittle and had no effective security benefit. All we need is:

  • only authorized enclaves may finalize
  • block numbers must increase monotonically
  • avoid forks

avoiding forks is still the naive solution: just finalize blocks from the first validateer appearing in the ShardStatus, which usually is the primary validateer who created the shard

Copy link
Contributor

@clangenb clangenb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I see the point of avoiding forks by choosing which validateer is authorized to have its blocks finalized, and we can already say that having a round robing scheme for this authorization, we kind of ensure quick finality, if we don't have many validateers.

Might have been overengineered before.

@brenzi brenzi merged commit 5a4f418 into master Dec 22, 2023
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

how to recover from ReceivedUnexpectedSidechainBlock
2 participants