<aside> 🛠This section is about the issues tackled by the development team for this week, and that the changes which won't be included in the next release right away.
</aside>
We are dealing with a variety of problems that we face as our users grow. One of the more difficult among these various problems is the block and Tx synchronization issues. In public blockchain networks where anyone can submit blocks, this propagation problem sometimes goes unnoticed and turns into another problem. One of them is what our team calls the 51st block problem.
The chart above lists the block times created during the unit period according to the index of the previous block. As shown in the figure, it can be seen that the block times of blocks 50 and 51 are incredibly long.
When you first look at these results, what you might expect is the processing speed and performance of the auth miners. If the auth miner cannot compute the next state quickly enough to create a new block, the 50th block may be delayed. But why block 51?
Let's take a moment to look at the configuration of block time here. Block time can be defined as the difference in timestamps of consecutive blocks. The following factors can be considered in composing this block time.
2, 3, 4 are all easily imaginable kinds of things. But what we need to pay attention to here is 1. 1 isn't revealed at the actual block time unless there is a special case where the previous block cannot be directly mined. The situation where the miner cannot directly take the previous block is the 51st block that has the 50th block we are looking at as the previous block since it must be mined by an auth-miner.
That said, it may be appropriate to take this as a sign that the block isn't propagating enough on the network, rather than a flaw in the auth-miner itself. In a situation where 1 is large enough, miners are supposed to continue mining their previous blocks instead of waiting for the previous block in the network, which is why there are many consecutive blocks mined by one miner from 0-49.
In order to analyze this problem in more detail, the team is currently testing it by creating a network model that can be easily modified and modifying various strategies.
.png)
Another notable anomaly in the recent block explorer is the block with too little tx.
As some of you may remember, some of Libplanet's non-thread-safe code was patched due to problems in the multi-threaded miner. However, even after the release of the patch version, there were still miners who created blocks without tx, and there was no way to prevent this, so we wrote a strict policy to create a policy to ban 0tx.
This was not a fundamental solution. Still, many miners are mining blocks that contain only a very small number of tx (but not zero), and tx not included in this block is waiting for processing and triggering a 26 timeout.
There are two main causes of this "low tx" problem.
Basically, the development team was investigating and revising, focusing on number 2 for reasons such as block synchronization. However, as the situation went on for a long time and there was no visible solution to the synchronization issue, we made a recommendation to refrain from using multi-threading and decided to keep an eye on the situation. at the same time, we are investigating the log with cooperation from multi-thread miners, and we are closely examining how it affects the incorporation of Tx while actually testing the code internally.
We expected this patch to speed up node responsiveness, leading to smooth block synchronization. However, even after this patch, blocks that appear too late are still occasionally found. To solve this problem, we are also considering introducing a TCP proxy.