Open staheri14 opened 1 week ago
@evan-forbes Can you please share the plots demonstrating this behaviour in testground.
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
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: