Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
sharding attestation policing across validators/nodes
For the network to be well-policed wrt attestation slashings, we need to actively be checking for slashable attestations within the "weak subjectivity period". The weak subjectivity period is variable in eth2 due to the validator queuing mechanism, but it is on the order of ~8 months when 10M eth (300k validators) are participating.
This brings up the non-trivial challenge of efficiently storing attestations and related data, and searching through this space on demand when new (and potentially historic) attestations come in.
After some consideration on the load of Attestations and search data that needs to be stored, it seems prudent to default shard this responsibility across nodes/validators rather than have each validator attempt to store and search the entire space. It is also assumed that large data consumers (block explorers, API providers, etc) will store and search the entire space.
This issue discusses both the efficient search algorithms, along with a discussion on to splitting up the search space.
There are two types of slashable attestations -- "double vote" and "surround vote". Double votes are relatively simple to find, whereas surround takes a little more consideration.
The strategies discussed here attempt minimize database reads for attestations when searching and instead rely upon relevant bitfields and epochs related to each validator. If a slashing is detected, then a more intensive find for the particular attestation from the DB is warranted.
Detecting a double vote is relatively simple and requires storing only
This is a constant time search and constant time update per validator so linear in the number of validators in an attestation.
Detecting a surround vote is a bit more complex and requires more data. An algorithm developed by @vbuterin requires
The algorithm requires storing
Although these algorithms are very efficient in search time, the data requirement for maintaining these lists can actually become quite large in addition to the already large data requirement of storing historic attestations through the weak subjectivity period, thus the need to shard responsibility of the attestation slashing search spec across validators.
We recommend strong client defaults in this matter to (1) provide sufficient policing of the network in the case that the 2/3 honesty assumption fails wrt safety while at the same time (2) do not place excessive resource requirements on any one validator to do so.
In addition to consumer node policing, we fully expect large data users to execute policing of the full dataset as they already will be storing it for other purposes. Fortunately, policing of attestations works if a minimum of one honest user sufficiently monitors the entire weak subjectivity period worth of attestations.
There are multiple options for strong user defaults, the most appealing of which scales as the number of validators working off of a node, but as most BN vs VC architecture does not persistently store which validators are connected to a BN, this might require additional tracking that is not currently in place. To this end, a BN could catalogue for which pubkeys validator attestation creation requests have been made and scale responsibility that way. If the user default goes in this direction, it likely makes sense to not broadcast slashable attestations immediately when found and instead to package them into blocks eventually for the one of the associated pubkeys connected to the BN and for the profitability of the validator.
An alternative is to have a slightly higher per-node default epoch range that a node is responsible for and disregard which validators might be connected. In this case, it likely makes sense to instead immediately broadcast slashable messages to be picked up by any validator to be put into a block. Due to the node not persistently knowing if validators are connected to it, a slashable message might be kept around locally for an indefinite period of time and not serve value to the network.
You can actually construct a much less data intensive no-surround checker that has the potential of false positives. Essentially, use the mechanism proposed by vitalik, but instead of doing it per validator, just do it for all attestations. When a historic attestation comes in, check it against this mechanism. If you find a surround, do a deeper search in the database to find if the surrounded attestation has a collision in participating validators. If so, found slashable surround. If not, false positive.
This operates under two assumptions
Thus a valid, historic attestation that surrounds anything is already a red flag.
A note on the data requirements of the non-false-positive surround checker in the original post
For 8 months of epochs, this is ~1MB per validator (54k epochs * 2 * 8-bytes-per-epoch) which is something like 300GB of surround meta-data if 300k validators. Can actually truncate the 8-bytes-per-epoch to just
See https://github.com/protolambda/eth2-surround for more options/ideas to implement surround matching with.
@shayzluf yes, that is the minimal requirement for eventual use. But 99% of the time, you likely don't use it. So ideally you put the old attestations into cheap (and possibly distributed/decentralized) storage, and only deal with the data that enables detecting the slashable events (the 2-3GB mentioned earlier) as efficiently as possible. (And this may be with some error rate, it's more than fine to look up an underlying attestation some small X% of the time, if detection is not 100% strict).
@protolambda While we were implementing the recommended double vote detection method using a bitlist, we faced an issue where aggregated attestations with overlapping indices triggered a false positive for a slashable offense. A single bit per validator doesn't seem like enough to prevent this false positive. Do you have any suggestions on preventing the false positives for this case from occurring?
For example: Say we have a setup with 2 nodes, and 3 validator sets A, B, C. If we receive one aggregated attestation of set A + B, and then receive an aggregated attestation for the same data but of B + C, the bitlist per validator method would report the second attestation as a slashable offense for all validators in set B.
So what we want to do is cheaply decide if it is worth it to do a more expensive DB lookup. In such a case, we can tolerate some false positives (if they aren't cheap to construct), but don't want any false negatives.
Unfortunately even without the above aggregation exploit, you could just send a full duplicate attestation (A in database, and A comes in on the wire sometime in the future) and it would trigger the false positive. This is true as long as we don't keep any data easily accessible about the attestation. Add the set of 32-byte hashes associated with the various
At the end of the day, this and similar methods don't fully solve the problem. There is a DoS issue prior to this check. Step 1 is to figure out which attesters are even a part of the attestation and if the signature is valid. If an historic attestation comes in from the wire, the only way to find out this information is to pull up the historic
This becomes a major DoS vector as an attacker can even send invalid attestations to a policing node for free (not slashable) causing the node to do expensive historic lookups.
Still more thought to be done on this :/
Personal notes that might be useful
New progress on surround vote matching: https://github.com/protolambda/eth2-surround#min-max-surround