celestiaorg / celestia-app

PoS application for the consensus portion of the Celestia network. Built using celestia-core (fork of CometBFT) and the cosmos-sdk
https://celestia.org
Apache License 2.0
328 stars 261 forks source link

Analyze Block Part Distribution in Knuu for Block Proposer and Immediate Connections #3605

Open staheri14 opened 1 week ago

staheri14 commented 1 week ago

Problem

Based on the traced data obtained from Testground experiments, it has been observed that some of the immediate connections of a block proposer do not receive block parts of the proposal first from the proposer. Instead, they obtain it from another peer. This occurs despite those direct connections of the proposer not having fully utilized their received rate. Hence, in theory, they are expected to receive all the block parts from the proposer, not from an intermediary.

There is a hypothesis that this issue might be unique to Testground. To verify this, we need to analyze the same scenario in Knuu. This issue aims to capture all aspects related to this analysis:

The analysis is based on the consensus_block_parts table.

We need to determine:

staheri14 commented 1 week ago

@evan-forbes Can you please share the plots demonstrating this behaviour in testground.

evan-forbes commented 4 days ago

sending and reacting quickly, distributing slowly

Here's a plot for a single height where the proposer is quickly queueing all of the block parts, but they are unable to be sent despite not all bandwidth being used.

to reproduce, first run the script that matches all sends and receives, then combine that data with the bandwidth data. How this exact process is done is a bit arbitrary, but the matching can be found https://github.com/celestiaorg/big-blocks-research/blob/evan/trace-3/match_parts.py. I believe I sent some other scripts to you as well that create this plot, but let me know if its still needed