lambdaclass / lambdaclass/lambda_ethereum_consensus
[Research] Check if node can handle spam correctly
Nobody has claimed this yet.
- Dominant language
- Elixir
- Stars
- 109
- Forks
- 41
- PR merge metrics
- No merged PRs in 30d
Description
Other implementations (lighthouse and prysm, at least) use different types of queues (i.e. FIFO, LIFO) for inter-"process" communication. This enables them to prioritize, for example, newer attestations and older slashing. Since the BEAM handles all of the message passing, we should check (in the future) if its queues (and maybe also libp2p's):
- drop messages when full (and if the how it's configurable)
- fill quicker than we process messages
- the order in which the messages are received (FIFO or LIFO), and if it's configurable
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
Start by examining the BEAM's message-passing queues and the libp2p queue behavior, then compare their handling with the Lighthouse and Prysm approaches. Determine whether queues drop messages when full, can fill faster than processing, and preserve FIFO or LIFO order, including whether these behaviors are configurable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- elixir
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100