This document references this paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4036000
The paper claims that there are a large number of slashings going undetected on the beacon chain. However, myself and others have not been able to verify these claims.
To assist the authors, I will attempt to debunk one slashable offense in this document.
The paper claims on page 31 that validator 5942 included an attestation in block 1267818 and then another conflicting attestation in 1267822.
To investigate, I will obtain the beacon block and beacon state for both blocks from a synced Lighthouse node I am running locally:
Now, I will build a branch of Lighthouse with a custom tool for this specific job:
This will install the lcli
tool into my path. It contains the attestation-indexer
tool that turns an Attestation
object into an IndexedAttestation
. The difference between these two types is that IndexedAttestation
has the aggregation_bits
resolved to a list of attesting_indices
(e.g., the validator indexes of the validators in the attestation).
I will get all the indexed attestations for block at slot 1267818:
This has produced the file indexed_0x6658.json
containing all indexed attestations from the block at slot 1267818.
I will get all the indexed attestations for block at slot 1267822:
This has produced the file indexed_0x541f.json
containing all indexed attestations from the block at slot 1267822.
Searching the block at 1267818 shows that there is an attestation from validator 5942:
However, searching the block at 1267822 shows no attestations for that validator:
My findings conflict with beaconcha.in, which shows an attestation for 5942 in block 1267822 in attestation #85.
However, we should note that our indexed_0x541f.json
only shows 48 attestations. Also, beaconcha.in claims "Showing 48 Attestations" but then goes on to display 128.
So, the following is clear:
From my findings, I believe that there is a bug in beaconcha.in and that validator 5942 did not create the claimed slashable attestation.
Anecodatally, we have pulled some attestations from the beaconcha.in API and found them to have invalid signatures. This leads me to believe that these slashable attestations are invalid "phantom" attestations.
I have great respect for the beaconcha.in team. They have done a lot of work to further the Beacon Chain. I use their site frequently and I will continue to do so. However, it's important to be aware that indexing the beacon chain is hard and it's still fairly early days of the beacon chain. It is not enough to rely on just beaconcha.in (or any lone source) when analysing the beacon chain in an academic manner.