Add information form epoch header chain in epoch SNARK messages #1158
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
kobigurk
reviewed
Sep 11, 2020
|
@kobigurk Question related to this PR. It seems that care is taken to make the epoch index |
|
Here are the changes to |
nategraf
requested review from
kevjue,
tkporter and
trianglesphere
as code owners
added 4 commits
September 24, 2020 16:00
…tor/epoch-snark-data-change
…tor/epoch-snark-data-change
|
Superseded by #1231 |
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.
Description
In the current implementation of the epoch SNARK messages, which are the data used to create proofs for the SNARKs within the Plumo system, it is possible to predict far in advance what these messages will be. As a result, there exists a scenario in which, if an attacker is able to compromise a number of validators, and those validators form a quorum at any future block, the attacker may create a valid proof branching the chain to a validator set of their choice. Key to this scenario is that the attacker need not have control of the validators (or more specifically their signing oracles) at the point they branch from, and instead can use the predictability of the messages to sign constructed epoch messages for blocks far in the future. As a result, the attack is feasible for an attacker who had access to the each validator in the quorum at any point in the past.
In order to address this scenario, this PR adds the epoch block hash, and previous epoch block hash to the epoch SNARK data. Because the block hash summarizes the state root, and therefore all on-chain state including the on-chain randomness values, the block hash is considered unpredictable*. This unpredictability makes the the generation of a epoch SNARK messages to fork from a future block infeasible.
Tested
WIP
Backwards compatibility
Enacting this change will require a hard-fork in the validator consensus algorithm. (WIP)