lambdaclass / lambdaclass/lambda_ethereum_consensus

Block & Blob Downloaders need manage the empty peerbook async

Open
#1,317 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug P2
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.