Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Heyo Gitcoiners! With an entire city of hackers, coders and blockchain innovators relocated on our platform, the atmosphere is just buzzing with crea…
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
Presently, only attestations that are included in blocks are included in fork choice.
They were not implemented in the fork-choice refactor (#398), instead we deferred them for later implementation.
## Steps to resolve
Attestations provided to the [`process_attestation`](https://github.com/sigp/lighthouse/blob/8afe8b3569085d05eba78a0cb11399485320405b/beacon_node/beacon_chain/src/beacon_chain.rs#L469-L502) function should be validated and provided to the [`ForkChoice`](https://github.com/sigp/lighthouse/blob/8afe8b3569085d05eba78a0cb11399485320405b/beacon_node/beacon_chain/src/fork_choice.rs) struct.
- Only valid, signed attestations should be added to the fork choice.
- It does not suffice to only add attestations to the fork choice if they are accepted into the operations pool. The op-pool is only interested in attestations that can be included in future blocks, whilst fork choice is potentially interested in any attestation.
- Attestations should not be added to fork choice if they target unknown/unprocessed blocks.
- It may be optimal to check if the attestation is a latest message for any validator prior to verifying the signature. If the attestation is not a latest message, we don't need it and verifying the signature would be a waste of time.
- A naive implementation would read the `BeaconState` from disk for each attestation. A better implementation would attempt to use the present, canonical state prior to loading from disk. I imagine the majority of attestations would be current and could be validated against the present state, it would be good to optimize for this scenario.