lambda_ethereum_consensus
lambda_ethereum_consensus copied to clipboard
[Research] Check if node can handle spam correctly
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