Kaspa (Black Tuesday)
This post assumes reader context on the crash of the Kaspa network in the course of the last 48 hours, and provides some additional notes and perspective.
(1) To simplify logic and debugging, and since the gamenet concept didn’t really catch air, I removed the random block reward and replaced the average block reward of 500 with a deterministic block reward of 500. Thus, if so far we mined on average 86400x500=43200000 Kaspa per day, we will henceforth mine deterministically 86400x500=43200000 Kaspa per day.
(2) Many ppl expressed their concern about the future rebase that will take place soon. I want to reiterate that the rebase is cosmetic only, it’s a rename, an altering of representation. If you mined so far, say, 10% of the (total or of the circulating) supply of Kaspa, you will posses 10% after the rebase as well.
(3) The deflationary monetary policy HF that I mentioned here (https://discord.com/channels/599153230659846165/909907923084382218/911015904144420895 or https://hashdag.medium.com/kaspa-launch-plan-responding-to-reality-6b4bec449037) will be specified next week, after syncing and mining resume for a few days, the network remains fully operational and confident, and the voluntary Kaspa magicians (Ori, Michael, Elichai) get some sleep and catch up with their own research and ventures.
(4) The community by and large reacted solidly to the crash. Thank you! No-one took it lightheartedly, and at the same time most focus was on providing datadirs and other useful info, getting instructions, funny memes. Let’s hope we won’t need to test ourselves again in similar circumstance.
(5) There was some genuine misunderstanding regarding the approaches we were looking into. Specifically, we were never considering a rollback in the sense of pointing at an early state which we were satisfied with and wanted to revert to, and discarding blocks and transactions appended to it later. Rather, we were searching for the latest state for which we have a certainly-valid UTXO commitment. While many users shared with us up-to-date datadirs, and while we had our own datadirs, we had to spend effort and time to ensure that the UTXO commitment builds correctly. Thus, we (read: aforementioned devs) had to rebuild the state afresh, feed it with such datadirs, and compare the commitments. Fortunately, the UTXO that we built hashed into the same UTXO commitment string embedded in the latest block in the datadir, producing 710f27df423e63aa6cdb72b89ea5a06cffa399d66f167704455b5af59def8e20, which proved that the DAG UTXO algebra was not erroneous, but “merely” a victim of the memory problem. This is not to say the architecture of this module should not be revised and improved — -a more correct architecture would protect it from DB failures.
(6) Kaspa is here to stay, in case you were wondering.
