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

Figure out the situation with forced GrandPa authorities changes #515

Open
tomaka opened this issue Feb 15, 2021 · 1 comment
Open

Figure out the situation with forced GrandPa authorities changes #515

tomaka opened this issue Feb 15, 2021 · 1 comment

Comments

@tomaka
Copy link
Contributor

tomaka commented Feb 15, 2021

A forced GrandPa authorities change consists in forcing a change in the GrandPa authorities.

There are two problems that need to be solved:

  • When a force change occurs, it doesn't get signed by the current authorities. GrandPa warp sync is unfortunately based upon the assumption that each set finalizes the change to the next set. We would have to include more information in the GrandPa warp sync payload, notably the headers of the blocks that lead to the forced change.

  • Light clients only verify block headers and not block bodies, meaning that we don't have any indication that a forced change is actually legitimate. A malicious validator could emit an invalid block, and light clients can't detect that it's invalid with only the header. We would have to execute this block in particular, but the storage of the parent might no longer be available on the network.

@tomaka
Copy link
Contributor Author

tomaka commented Feb 15, 2021

The pragmatic solution at the moment is to generate a checkpoint (i.e. a snapshot of the chain) from a full node after the forced change and update the chain specs.

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

No branches or pull requests

1 participant