Conversation
Codecov Report
@@ Coverage Diff @@
## master #3840 +/- ##
==========================================
+ Coverage 66.89% 66.93% +0.04%
==========================================
Files 219 219
Lines 18470 18478 +8
==========================================
+ Hits 12355 12369 +14
+ Misses 5194 5189 -5
+ Partials 921 920 -1
|
melekes
left a comment
There was a problem hiding this comment.
Great write-up 👍
Should we expand on eclipse attacks, which are only mentioned briefly in "Fantom validators" section. Are there any other types of attacks?
| Note that detecting this behavior require application knowledge. Detecting this behavior can probably be done by | ||
| referring to the block before the one in which height happen. | ||
|
|
||
| Q: can we say that in this case a validator ignore to check if proposed value is valid before voting for it? |
There was a problem hiding this comment.
I think so, yes and we should punish for it
There was a problem hiding this comment.
Yep, voting on a block that can't be derived correctly from the previous one needs to be punishable: #3244 (comment)
There was a problem hiding this comment.
Agreed, I wonder if this is complex if combined with differing rounds, it seems like we might need some sort of challenge-response where a validator which signed a state that didn't end up being part of the canonical chain must submit the sequence of transactions which led to it in order to avoid being slashed.
ebuchman
left a comment
There was a problem hiding this comment.
Great write up. But we should link to the google doc somewhere up front as having detailed spec
| Note that we can have fantom validators based attacks as a follow up of equivocation or amnesia based attack where | ||
| forked state contains validators that are not part of the validator set at the main chain. In this case they keep | ||
| signing messages contributed to a forked chain although they are not part of the validator set on the main chain. | ||
| This attack can also be used to attack full node during a period of time he is eclipsed. |
There was a problem hiding this comment.
Doesn't someone have to commit at least equivocation or amnesia to convince a full node? Ie. just fantom isn't enough
There was a problem hiding this comment.
That is / was my understanding as well.
There was a problem hiding this comment.
Yes, I think this is what is meant by "as follow up of equivocation or amnesia", that is, until the fork is detected we can have phantom validators creating blocks. However, if we have a fork with different blocks with different next validator sets for the same height, the question is whether, from a technical viewpoint, it makes a difference whether one is a (faulty) phantom validator or whether one is correct. At the end, we will need social consensus to resolve which block to maintain, or where to roll-back to?
| Example scenario: a lite client has a trust in a header for height h (and the corresponding validator set VS1). | ||
| As part of bisection header verification it verifies header at height h+k with new validator set VS2. | ||
| Some of the validators from VS2 signed the header at height h+k that is different from the corresponding header | ||
| at the main chain. Detecting these kind of attacks is easy as it just requires verifying if processes are signing messages in heights in which they are not part of the validator set. |
There was a problem hiding this comment.
Description should be clarified to make clear that validators in VS2 are no longer in the val set at h+k (ie. use VS2 and VS'2, like the description in #3244 (comment)
Also note the attack still works even if the validators are still bonded, but just <1/3, so detecting fantom validators isn't enough: #3244 (comment)
| Note that detecting this behavior require application knowledge. Detecting this behavior can probably be done by | ||
| referring to the block before the one in which height happen. | ||
|
|
||
| Q: can we say that in this case a validator ignore to check if proposed value is valid before voting for it? |
There was a problem hiding this comment.
Yep, voting on a block that can't be derived correctly from the previous one needs to be punishable: #3244 (comment)
|
|
||
| 4. Fantom validators: faulty validators vote (sign prevote and precommit messages) in heights in which they are not part of the validator sets (at the main chain). | ||
|
|
||
| 5. Lunatic validator: faulty validator that sign vote messages to support arbitrary application state. |
There was a problem hiding this comment.
Specifically, we mean application states other than those which resulted from valid state transitions, right?
| all transactions so it can verify if computed application state diverge from the proposed state. Therefore, | ||
| full node can be tricked to follow forked chain by committing different set of transactions to a blockchain. | ||
|
|
||
| In case of lite clients, attack surface is bigger as lite client only verified headers without executing transactions. |
There was a problem hiding this comment.
| In case of lite clients, attack surface is bigger as lite client only verified headers without executing transactions. | |
| In case of lite clients, the attack surface is bigger as a lite client only verifies headers without executing transactions. |
| Note that we can have fantom validators based attacks as a follow up of equivocation or amnesia based attack where | ||
| forked state contains validators that are not part of the validator set at the main chain. In this case they keep | ||
| signing messages contributed to a forked chain although they are not part of the validator set on the main chain. | ||
| This attack can also be used to attack full node during a period of time he is eclipsed. |
There was a problem hiding this comment.
That is / was my understanding as well.
| Note that detecting this behavior require application knowledge. Detecting this behavior can probably be done by | ||
| referring to the block before the one in which height happen. | ||
|
|
||
| Q: can we say that in this case a validator ignore to check if proposed value is valid before voting for it? |
There was a problem hiding this comment.
Agreed, I wonder if this is complex if combined with differing rounds, it seems like we might need some sort of challenge-response where a validator which signed a state that didn't end up being part of the canonical chain must submit the sequence of transactions which led to it in order to avoid being slashed.
…mint into zm_fork-accountability
Co-Authored-By: Anton Kaliaev <anton.kalyaev@gmail.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.