lambdaclass / lambdaclass/lambda_ethereum_consensus
Block & Blob Downloaders need manage the empty peerbook async
Nobody has claimed this yet.
- Dominant language
- Elixir
- Stars
- 109
- Forks
- 41
- PR merge metrics
- No merged PRs in 30d
Description
Right now we have tech debt in how both block and blob downloaders manage the empty peerbook case.
Before #1314, the node hanged if no we run out peers due to #1308. After #1314 this raise, before it continually sleep making impossible for LibP2P to handle new peers. This needs to instead being delayed asynchronously to allow new peers to be part of the peerbook.
After #1314, this issue is less common due to a better penalization scheme and more time in the begining for peer discovery, but still possible if all initial peers aren't responding, luckily this isn't the case most of the times and it is an issue mostly at the start of the node where we have a small number of peers.
If this proves to be more common than anticipated it need to move from P2 to P1.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect the block and blob downloader entry points and trace how each handles an empty peerbook after peer exhaustion. Verify that the empty-peerbook path waits asynchronously rather than blocking or raising, and confirm that newly discovered peers can be used afterward.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- elixir
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100