Skip to content

Latest commit

 

History

History
30 lines (26 loc) · 2 KB

kip-0002.md

File metadata and controls

30 lines (26 loc) · 2 KB
Raw
  KIP: 2
  Layer: Consensus (hard fork), API/RPC
  Title: Upgrade consensus to follow the DAGKNIGHT protocol
  Author: Yonatan Sompolinsky
          Michael Sutton <msutton@cs.huji.ac.il>
  Status: proposed

Motivation

DAGKNIGHT (DK) is a new consensus protocol, written by the authors of this KIP, that achieves responsiveness whilst being 50%-byzantine tolerant. It is therefore faster and more secure than GHOSTDAG (GD), which governes the current Kaspa network. In DK there’s no a priori hardcoded parameter k, and consequently it can adapt to the “real” k in the network. Concretely, in DK, clients or their wallets should incorporate k into their local confirmation policy of transactions (similarly to some clients requiring 6 confirmations in Bitcoin, and some 30 confirmations).

Goals

  • Complete the R&D work necessary to implement DK for Kaspa.
  • Implement DK on Kaspa as a consensus upgrade.
  • Add support and API for wallets' transaction acceptance policy, to correspond to DK's confirmation speed.

Deliverables

  • Applied research:
    • Adapt the consensus algorithm to enforce a global maximum bound on network latency (can be taken with a huge safety margin; does not affect confirmation times), which is necessary for difficulty and minting regulation, pruning, and more.
    • Devise efficient algorithms to implement the DK procedures — the current pseudocode is highly inefficient. The implementation will partially utilize the existing optimized GHOSTDAG codebase, as the latter is a subprocedure of DK.
    • Research the optimal bps in terms of confirmation times, and provide a recommendation. (optional)
  • Implementation:
    • Implement DK on the Kaspa rust codebase as a consensus upgrade.
    • Design a transaction confirmation policy API and implement the supporting functionality in the node.
    • Documentation of consensus changes and API additions.

Backwards compatibility

  • Breaks consensus rules, requires hardfork
  • Adds (and potentially breaks) RPC API