A research paper discussing a revolutionary new consensus mechanism that will potentially be introduced in Kaspa. This new DagKnight consensus which is an evolution of the GHOSTDAG protocol will theoretically lay down the groundwork for even faster transaction and confirmation times. You can see the paper here.

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: Approved/Funded

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

You can see the paper here.

A rewrite of Kaspas programming language from Golang to Rust is currently being conducted by developer Michael Sutton. This switch will provide a significant boost in Kaspas overall performance/speed, allowing for unheard of transactions and blocks per second with conservative estimates of around 10bps. This rewrite is an integral part of the foundation to achieve Kaspas future goal of reaching 100bps!

Currently, Kaspa is written in a programming language called GoLang. You can think of this as sort of modeling clay. It serves the purpose of designing the shape and proving the concept, but it’s not really anything you would ever see in a museum. Rust is a high performance programming language which allows for intense race ready concepts to be implemented which fully utilize modern computing hardware.This enables such things as parallelism – the ability to process different blocks on different CPU threads simultaneously. Instead of modeling clay you may think of Rust as artisan grade, glazed and kiln fired ceramic.

A mobile-device wallet is currently being developed. The need for a high-performance mobile wallet option has been expressed by many in our community. This mobile wallet will add to the already existing Kaspa wallet options: web wallet (https://wallet.kaspanet.io/), desktop wallet (https://kdx.app) and Command Line Interface Wallet (https://github.com/kaspanet/kaspad). The expected time frame for development of this wallet is roughly 3-4 months.

We have all heard of blocks in crypto, but what are they – really? Think of a ziplock sandwich bag with a handful of fortune cookie papers inside – but instead of some generalized well-wishing, each one contains a note with an address crediting some coins to another address. Once a miner guesses the answer to the next block, all of those transactions are sealed in the ziplock bag and permanently stapled to the zip lock bag that came before it, forming a chain of bags – I mean blocks.

In Bitcoin and every other coin we are currently aware of, these blocks occur at regular intervals and are only allowed to happen one at a time – forming a chain of blocks in a straight line. When you send some coins – it’s like your transaction is waiting at the bus stop waiting for the next bus to take your transaction away and lock it in – for Bitcoin the bus comes every 10 minutes. For Ethereum, the bus comes every 15 seconds – a lot better.

For Kaspa right now, the bus comes about every second – BUT – we also allow up to 18 blocks to occur at the same time. Once the Kaspa code is completed in Rust high-performance language, we may increase the block time to about 32 blocks per second. All of a sudden, your transaction is no longer waiting for a bus – there are 32 supercars arriving every second to collect passenger transactions and rocket them off.

The transaction and the confirmation happens instantly, there is nothing to wait for anymore when using crypto if you utilize Kaspa.

Thanks to a 24-hour fundraising blitz, development is now underway for you to be able to send & receive your $KAS quickly, securely and easily from the safety of your Ledger.  To safeguard your $KAS holdings on the industry standard hardware wallet platform is just another step towards our goal of creating a common and safe use currency.

Although there are numerous research papers written behind Kaspas technology, an official white paper is being scheduled for release. This white paper will thoroughly combine Kaspas past research and current goals into a cohesive and consumable whole document, designed to inform beginners and onboard developers.

Currently there is no P2P communication for archival nodes that allow them to exchange normally pruned data.  Improvements to archival Nodes will allow for Kaspa to have a more thorough block explorer to revisit past transactions beyond Kaspa’s pruning point. Currently due to Kaspa’s pruning mechanism, transactions on standard nodes can only be visited three days in the past. With Archival Nodes this will no longer be an issue allowing for more historical data sets to be retrieved.

The aim of Kaspa is to become the fastest, most scalable, and secure L1 PoW crypto. And while we feel we have already reached this benchmark, there still exists some fine-tuning for peak performance. However, performance for the sake of performance is not the end goal of Kaspa. The broader goal is to create the ultimate Layer 1 to implement smart contracts, Defi, and Layer 2 applications over it. It’s our hope that a future ecosystem will arise on Kaspa that will be as strong as the foundation and wonderful community that helped birth it.

Latest news – https://kaspa.org/the-kaspa-community-and-the-exploration-of-smart-contracts/