You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In fork choice attestation processing, the attestation.data.target and attestation.data.source fields are not checked to ensure they are ancestors/descendants of each other and attestation.data.beacon_block_root.
What does this mean?
1. Faulty actors influence fork choice
An attestation where the source/target/beacon_block_root are on different chains is produced by a faulty validator.
I would expect that good practice would be to drop any message that is provably invalid and ban the peer.
2. You can pick-and-choose your shuffling/validator registry
Consider that I want to set attestation.data.beacon_block_root to block 4. I am able to choose whether to set attestation.data.target to blocks 1, 3 or 5.
The honest choice is 3, but perhaps in that state I am scheduled to vote at slot 63 and instead I want to vote earlier. Now I can pick between the other two states to find the earliest assignment and have my vote included in fork choice earlier than naturally intended.
The text was updated successfully, but these errors were encountered:
When there is no partitions in the network it doesn't matter whether vote was dropped or not. As fork choice will not be abused unless there is a 51% attacker. However, it could be exploited if adversary were able to partition the network to eclipse one of those parts with invalid votes.
A discrepancy between on-chain and fork choice checks has been discussed in #1408 and #1456. I and I believe @ericsson49 are on the same page with @paulhauner regarding that:
I would expect that good practice would be to drop any message that is provably invalid and ban the peer.
In addition we advocate for making on-chain checks explicitly run by the fork choice and get rid of dependency from validation on the network layer. Is that what you implied @paulhauner ?
In fork choice attestation processing, the
attestation.data.target
andattestation.data.source
fields are not checked to ensure they are ancestors/descendants of each other andattestation.data.beacon_block_root
.What does this mean?
1. Faulty actors influence fork choice
An attestation where the source/target/beacon_block_root are on different chains is produced by a faulty validator.
I would expect that good practice would be to drop any message that is provably invalid and ban the peer.
2. You can pick-and-choose your shuffling/validator registry
Say we have 3 chains:
Consider that I want to set
attestation.data.beacon_block_root
to block 4. I am able to choose whether to setattestation.data.target
to blocks 1, 3 or 5.The honest choice is 3, but perhaps in that state I am scheduled to vote at slot 63 and instead I want to vote earlier. Now I can pick between the other two states to find the earliest assignment and have my vote included in fork choice earlier than naturally intended.
The text was updated successfully, but these errors were encountered: