Skip to content

Latest commit

 

History

History
82 lines (72 loc) · 4.1 KB

kip-0001.md

File metadata and controls

82 lines (72 loc) · 4.1 KB
Raw
  KIP: 1
  Layer: Core
  Title: Rewriting the Kaspa Full-Node in the Rust Programming Language
  Author: Michael Sutton <msutton@cs.huji.ac.il>
          Ori Newman <orinewman1@gmail.com>
  Status: under development

The following KIP was posted on Kaspa's discord server at 07/06/2022 (message link), is under active development (rusty-kaspa), and is brought here for completeness.

Motivations

  • Refactored and extensible codebase. The current codebase has evolved through years of R&D and uncertainty and has a decent amount of technical debt. Some components are fragile and are hard to maintain and extend. A reform of the codebase is crucial for making it accessible to new developers and for making it possible to implement new major features (e.g., smart contract support; consensus ordering algorithm upgrade)
  • Efficiency and performance. In order to reach maximal efficiency and higher block and transaction rates, we suggest that the system needs to be rewritten in a performance-oriented programming language and with a performance oriented mindset. Using Rust for the rewrite will open many opportunities in this aspect, while still providing many high-level constructs which are essential for realizing a complex system like Kaspa.

Goals

  • Implementing the Kaspa full-node in Rust
  • Reaching higher efficiency and improved performance with current net params
  • Benchmarking various network params through devnets and testnets, analyzing the trade-offs, and settling for some BPS, TPS configuration for the long-run.
  • Simplified and modularized codebase
  • Incorporation of pending features
  • Documentation (including flows and sub-protocols)
  • Comprehensive benchmarking suite

Milestones

  1. A node partially implemented in Rust. Namely, all core logic and core algorithms from consensus level and below should be implemented correctly in Rust. There are two possible ways to test such a partial system. The exact method is to be determined by relevant time and effort estimations. The two options are:

    1. Hybrid go-rust full-node which can connect to current mainnet and testnet and function properly. External components including the P2P and RPC layers will remain in Go. Both system parts will be attached through a cross-language interop API.
    2. A test level consensus API in Rust which can be validated extensively through existing and new integration tests.

  2. The above partial node with specific performance targets. There are two types of possible performance gain:

    1. Single-core performance improvement: we expect a natural gain from the usage of Rust alone and the lack of a GC. Additionally, DB optimizations such as binary serialization and Block Header compression can affect the runtime as well (initial target: 5x)
    2. Multi-core scaling: Implementation of parallelism within consensus. This includes organizing consensus block and transaction processing in a way that allows parallelism of independent tasks (initial target: strong scaling; might require high BPS for being meaningful)

  3. New features on consensus level:

    1. Header pruning. The outcome of this should be a node running for long periods with nearly fixed DB size (this is currently achieved by resyncing).

  4. A full-node implemented completely in Rust. This includes P2P, RPC, IBD, Mempool, Mining manager and all remaining components. RPC should be redesigned to allow a complete API change (if so desired), though backward compatibility might be a requirement.

  5. New features on node/network level:

    1. Archival nodes P2P
    2. Header compression on P2P level

  6. Testnet performance targets:

    1. 1000 TPS (using 1-5 BPS)
    2. 10 BPS
    3. 32 BPS
    4. 100 BPS (or max possible, since there is a trade-off of increased header size when more blocks are mined in parallel)

  7. (Mainnet BPS and TPS targets are subject to many system-wide aspects and tradeoffs. The goal of this rewrite is not to end with mainnet running with 100 BPS, but rather to allow exploring this parameter space and making the right decisions)