Kaspa where to (Part I)

This is a concrete version of a longer post which I started writing but had too much spare time so didn’t complete yet.

Context: One of Kaspa’s core devs, Michael Sutton, suggested a plan to order-of-magnitude enhance Kaspad full-node performance by refactoring the codebase and rewriting it in Rustlang. (https://discord.com/channels/599153230659846165/844142778232864809/993245032670842991)

My twosats on the matter:

1. Kaspa was initialized as a live proof of an idea, a demonstration of a novel (and very cool, but that’s beside the point) paradigm for permissionless consensus. In bootstrapping Kaspa, I was fully aware that we do not have the resources — or the manpower — or the organization machinery — required to unlock even 5% of Kaspa’s potential, and that some external strategic move will need to happen for that aspiration to come true (think Project Serum and Solana https://defirate.com/ftx-serum-solana/).
2. For these reasons, as Kaspa OG’s recall, I considered launching Kaspa in testnet mode, then opted for a novel (aka failed) mode, which I coined “gamenet”, and which can be thought of as “testnet with incentives”. While this attempt was apparently naïve and, in retrospect, flawed I am mentioning it to recollect the mindset with which Kaspa was released. (For the same aforementioned reasons I kept myself uninvolved with the exchange listing efforts of Kaspa; I fully appreciate their value to the community, and at the same time I preferred erring on the side of caution).
3. I agree with concerns voiced by some community members that, in principle, to bring real value efforts should be focused on integration, adoption, marketing, etc. In particular, at this stage, high bps and high tps are imho not a meaningful step towards building a non-hypothetical financial system.
4. However, our community is still far from the scale and organization necessary to reach actual adoption, if not merely for its still modest treasury size (which is contribution-based, and managed by a few volunteer OG’s). With that in mind, I believe the most correct usage of the funds donated by miners is to continue the path of demonstrating live the original DAG vision, by improving the base layer node and later on perhaps upgrade its consensus; which is precisely the proposal put forward.
5. The current Kaspad codebase is an adaptation of the Bitcoin client btcd, written in Golang. It enjoys a fine amount of technical debt and great code complexity, which make it difficult for new folks to contribute. The proposed refactoring explicitly aims at writing the codebase in a modular and legible manner, which is arguably even more important than performance enhancement.
6. For full disclosure, I am working tightly with Sutton for a few years now, and am highly biased in favour of any R&D task or project to which he dedicates his rare talent (cf. Proverbs 27:14). Him availing a few months’ of his full capacity to Kaspa is exceptional, and I hope the community (and esp. miners) will match this generosity. I believe a ballpark of 1% of the circulating supply would be very reasonable.