Starting in July, the Kaspa development team, led by Michael Sutton, has undertaken an effort to rewrite Kaspad in Rust. This codebase rewrite will allow Kaspa to be in a “Space Code” system and reach maximal BPS and TPS through a high-performance well-designed implementation. The rust rewrite will take approximately 4-6 months to be completed and is fully funded by community member donations. To view the codebase foundation, progress on the project, or participate in the code-rewrite, please see our github page and reach out to us on Discord.
Background: In order to reach physical throughput limits and higher block rates, we believe Kaspa needs to be rewritten in a performance-oriented programming language and with a performance-oriented mindset. The current codebase carries on its back years of R&D efforts. Now that we have a proven, stable and working real-world and world-scale network, it is time to put the pieces back together in their purest form. As Kaspa seeks to be a world-leading financial system, the codebase should also transform to the ultimate level of quality and performance.
The main goals of such a rewrite:
1) Higher efficiency and tighter performance. The Rust programming language has the right balance for writing a system like Kaspad, with low-level memory management on the one hand (contrary to the currently used go-lang which is Garbage Collection based), and high expressiveness on the other hand (e.g., async-await etc.), not to mention the large and mature crypto-rust ecosystem.
2) Max BPS and TPS. Given the above some concrete numbers, I believe a goal of 32 BPS is definitely possible, and even 100 BPS is a reasonable target. With our current block-size this would translate to 6400 – 20000 TPS. But block-size can also theoretically be increased to find a sustainable amount of TPS, where the only limiting factor becomes the internet connection itself.
3) Simplified and modularized codebase. Rewriting will make the codebase more approachable for newcomers. My feeling is that the core of the current Kaspad codebase is hard to figure out for newcomers and is a bit obfuscated. Up until now, all code contributions to Kaspad from non-core members are still in the external realms of the codebase, such as the RPC API and related services.
4) Incorporation of pending features. New features and upgrades can be taken into consideration without the overhead of making many changes to an existing codebase. Examples include RPC API redesign; Archival nodes (and possibly P2P support for a subnet of such); Header Pruning; Smart-contract ground laying work, and more.
5) Documentation. Throughout the rewrite process, we can define and follow a standard for high-level documentation of the various sub-protocols and algorithms in the system. This can make it possible to outsource the effort of completing other technical writing to other members of the community, relieving the burden from developers alone.
Trackbacks/Pingbacks