Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fork choice: checking FFG source/target #1636

Closed
paulhauner opened this issue Mar 4, 2020 · 1 comment · Fixed by #1742
Closed

Fork choice: checking FFG source/target #1636

paulhauner opened this issue Mar 4, 2020 · 1 comment · Fixed by #1742

Comments

@paulhauner
Copy link
Contributor

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

Say we have 3 chains:

   2    4    8     <- slot 36 (epoch 1)
   |    |    |
   .    .    .
   .    .    .
   .    .    .
   |    |    |
   1    3    5     <- slot 32 (epoch 1)
    \   |   /
        |
        .
        .
        .

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.

@mkalinin
Copy link
Contributor

mkalinin commented Mar 4, 2020

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants