FatGorilla

$kas 10BPS testnet update #3 Hello everyone. I am glad to update that the first phase of the 10BPS experiment is concluded. A few days of surprisingly smooth sailing has allowed Rust devs to 1. locate and eliminate noise inducing bugs, and 2. understand what are the most pressing issues that need to be addressed to have a healthier 10BPS network. Addressing these issues will take a few days, during which the network will be shut down. I want to stress that we all feel like the first phase has passed with flying colors: testnet conditions are *much* rougher than mainnet (due to much higher txn load, much less stable hashrates, small number of public nodes etc.), and yet, despite some performance hiccups, nodes were able to run continuously. This is a clear indication that the overall goal has been accomplished, and we are now perfecting an already existing solution. The three main issues that are now the priority are: 1. Refactoring the mempool: the mempool is the component that stores transactions while they are waiting to be included in blocks. Currently the mempool is *monolithic*, which means that whenever one part of the code is accessing the mempool, the other components have to wait, causing lag in some data flows (in particular, it has been observed to sporadically slow down block template creation, needed for mining, by as much as 10 seconds). Refactoring the mempool for better parallelism will naturally be handled by the mempool guy @Tiram_88. Unfortunately Tiram is also our KGI guy, so this mean we'll have to wait a bit longer before seeing pretty pretty animated 10BPS DAGs :( 2. Pruning starvation: as I explained in the previous update, the pruning process is starved by the high load of processing 10BPS. This might simply be resolved "automagically" by tightening other components, but a redesign of pruning priority might also be in order. 3. Better IBD: this issue is not as urgent as the other ones, but is important for a healthy network in the long run. I am pointing it out here mostly because it is a great entry point for developers who want to join the effort. Essentially, when a node syncs it obtains all information from one fixed peer. This creates pressure on public nodes as well as causing slow sync in case the connection with the syncer node is slow for some reason. We want someone to refactor the IBD process to obtain data from several peers simultaneously. Doing so requires considerable knowhow in P2P networks, as well as familiarity with rust. However, this is a project that can be tackled without deep understanding of GHOSTDAG and the consensus layer and is thus ideal for experienced programmers who want to dip into Kaspa. If this strikes you as appealing, do come and introduce yourself in the #development channel on the Discord server!

The @NASA Artemis II crewed mission around the Moon will inspire the next generation of explorers, and show every child – in America, in Canada, and across the world – that if they can dream it, they can be it.