<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>
If you've been following this weekly digest, you've probably guessed that we've been struggling with this issue for almost a month or even more. 😪
(Even before the multi-threading problem, which will be described later, was raised) We continued to be interested in block sync and made various attempts, but there are no tangible results yet.
As we expected that short-term measures such as parameter corrections would be insufficient, the team was also working on fundamentally structural improvements such as TcpTransport as a long-term plan. We would continue to report the progress on this.
In order to improve block sync and timeout problems, the improved fork structure introduced from v100045 has improved the synchronization speed by at least 3 seconds. It's thanks to the changed structure to store only the necessary parts incrementally, instead of copying the entire chain index.
But there was no free lunch. Some complex code tricks were required to complete this structure, and especially the code to clean up chain indexes which was no longer needed in snapshots. It was more complex and dangerous than those covered in snapshots in general.
As a result, chains created from snapshots were reported not running correctly, and as soon as the replay conditions were checked, the changes were rolled back by stopping the optimization. The discontinued optimization will be re-released after sufficient testing.
(This is probably the topic you are most interested in. 😓)
The issues that were hot in the community since last Friday are multi-threaded miners and 0tx blocks.
First, since last Friday, it was demonstrated by a user that it is possible to accelerate the mining process through multi-threading. In fact, as a development team, multi-thread mining was expected to some extent, but we thought that it was not necessary to work as a team. Only if there weren't any bugs there. 😢 Often, a function is said to be thread-safe, if it returns to its intended result, even in a multi-threaded environment. We expected the mining code to be thread-safe enough, but it wasn't, so we had to patch it up urgently, and unfortunately, this was after a lot of people had adapted the multi-threaded minor code snippet to their miners.
Aside from the mining monopoly caused by the rise of multi-threaded miners(We will inform you about this later, again). An issue that the development team took very seriously is a block that does not contain any transactions, called 0tx. If there are too many of these 0tx blocks, the players' actions are not processed and the game does not work. This 0tx problem, which was originally supposed to be fixed by fixing a multithreaded bug, didn't go away for a while, and many players began to think that some selfish miners were ruining the game just for NCG.
However, such selfish miners can occur In Nine Chronicles , and the problem of preventing them is a very complex and difficult problem , which should be solved by the dev team. The problem is, because of the importance of this matter, we missed the golden time to fix it. In fact, most miners just wanted to experiment with multithreaded mining, and in the process, bug fixes may not have been delivered properly. (Building a Nine Chronicles node is notoriously complicated even within the development team). And if this 0tx was a simple mistake, not because of selfish mining, it should have been possible to prevent it with a simpler rule. ⚖️ So, the simple rule the development team took was to forbid 0tx and only consider blocks containing at least one of any tx as valid. The downside of this strategy is that , if no one in the network initiates a transaction, the block creation stops itself. (Many PoW-based blockchains do not allow this, nor does Nine Chronicles). To prevent stopping, the development team has come up with another shallow trick. Which is, installing a node that periodically generates empty transactions. The node we call tx-repeater generates an empty transaction once every 30 seconds, helping blocks to come out even when there are no other participants.
Of course, this is only the first aid measure, and is not a fundamental countermeasure when a truly selfish miner appears. We recognize these fundamental countermeasures as important issues, and design solutions together.