Kaspa is the fastest and most scalable instant confirmation transaction layer ever built on a proof-of-work engine. Transactions sent to miners can be immediately included in the ledger, which is structured using the revolutionary blockDAG. Kaspa is based on the GhostDAG/PHANTOIM protocol, which is a scalable generalization of the Satoshi Nakamoto consensus (Bitcoin consensus). Its design is faithful to the principles that Satoshi Nakamoto embedded in Bitcoin - proof-of-work mining, isolation of UTXO formation, deflationary monetary policy, no pre-mining, and no central governance. Kaspa is unique in its ability to support high block rates while maintaining the level of security provided by the most secure proof-of-work environments. Kaspa’s current mainnet runs at one block per second. Following the ongoing rewrite of the Rust language, core developers aim to significantly increase the number of blocks per second and attract smart contract and DeFi development.

Traditional cryptocurrencies face security, scalability and decentralization trade-offs: Decentralized cryptocurrencies must limit their block creation rates to limit "orphans", i.e. potential blocks created while they are propagating on the network off-chain blocks. A high orphan block rate will reduce the effectiveness of the PoW network, thereby reducing its defense capabilities against attacks by malicious actors joining the open network. To address this trade-off, Kaspa’s consensus layer uses GhostDAG, a proof-of-work consensus protocol that summarizes Satoshi’s chain as a directed acyclic graph (blockDAG) of blocks. GhostDAG merges orphan blocks into the chain to form a block DAG, and then uses a novel greedy algorithm to sort the blocks so that well-connected, honest blocks are favored quickly and with high probability. GhostDAG allows Kaspa to rule out Xue District The traditional trade-off of blockchain is to increase the block rate by orders of magnitude while maintaining Bitcoin's theoretical security guarantees. This results in a cryptocurrency backed by 51% security, with a large number of miners/nodes, and a throughput of approximately one per second blocks. This is unlike existing cryptocurrencies which inevitably come at the expense of a small number of validator nodes or lower BFT security from malicious actors (a 33% threshold is required to attack the network).

Kaspa was developed to solve the trilemma in the use of digital assets: security, scalability, and decentralization. Kaspa leverages the revolutionary blockDAG (instead of blockchain) to enable the fastest, scalable, and most secure transactions without sacrificing decentralization. Fastest Transactions Kaspa's blockDAG network generates multiple blocks per second for publishing transactions to the ledger. Combined with fully confirmed transactions within 10 seconds, this makes Kaspa ideal for everyday trading. Instant confirmation Kaspa is designed to be hundreds of times faster than Bitcoin, with each Kaspa transaction visible on the network within a second and each transaction being fully confirmed within an average of 10 seconds. Scalability Kaspa solves the scalability problem with its ability to generate and confirm multiple blocks per second. This does not require a trade-off between security and decentralization, as seen with proof-of-stake networks. Efficient proof-of-work Kaspa utilizes the light-mining-ready kHeavyHash algorithm to achieve consensus and security on the network. This algorithm combined with a high-throughput DAG and no wasted blocks makes it consume less energy than other PoW networks. Secure Kaspa utilizes an ultra-secure blockchain network without compromising decentralization. This is achieved through a combination of pure, stake-free, proof-of-work and the revolutionary GhostDAG consensus mechanism. BlockDAG Kaspa overcomes the problems of blockchain by processing all blocks connecting all sidechains in parallel. This results in a DAG structure that greatly increases the formation of blocks per second, thus creating a blockDAG.

Core technology Kaspa is a revolutionary technological advancement based on years of academic and theoretical research. Satoshi Consensus Engine Satoshi Consensus, named after Satoshi Nakamoto, was the first consensus engine based on the proof-of-work mechanism and still protects the Bitcoin network today as well as many other proof-of-work cryptocurrencies, including but not limited to Limited to well-known cryptocurrencies such as Litecoin, Bitcoin Cash, and ZCash. The security properties of the Satoshi Consensus have been mathematically proven, considered theoretically sound, and have been practically tried and tested in Bitcoin and its variants over the past 14 years without any major incidents. event. Manipulating the boundaries of a blockchain is simple and verifiable; any participant who wants to take advantage of a blockchain must control more than 50% of the computing power (i.e., computing power) on the network. As the web grew, this was seen as becoming increasingly unfeasible. This simple concept is one of the main factors behind maintaining a high level of trust in Bitcoin and has been a catalyst for the adoption of Bitcoin as a store of value and payment system by many mainstream institutions around the world. In contrast, many new forms of consensus have strayed away from the original Satoshi consensus vision, adopting proof-of-stake approaches that aim to achieve scale and speed at the expense of decentralization. Block DAG The term "DAG" stands for Directed Acyclic Graph, which is the mathematical concept of a directed graph without directed cycles. It consists of vertices and edges, with each edge pointing from one vertex to another. In the context of a distributed ledger, a BlockDag is a DAG whose vertices are blocks and edges are references from the block to its predecessor. blockDAG seeks to solve the problems of linear blockchains and Satoshi consensus. These issues include lack of scalability, selfish mining, and orphan blocks. Unlike traditional blockchains, a blockDAG can reference multiple predecessors instead of a single predecessor, and blocks reference all the tips of the graph instead of just the tip of the longest chain. By referencing all tips of the graph, blockDAG merges blocks from different branches rather than just referencing the longest chain. Therefore, in BlockDAG, no block is wasted or orphaned, all blocks are published to the ledger, and no mining power is wasted. Due to this structure, blocks are allowed to be generated more frequently, thus facilitating more transactions and leading to almost instant confirmations. How is all this possible? Deviating from the longest chain consensus method and utilizing Kaspa’s novel GhostDAG (Phantom 2.0) consensus mechanism. BlockDAG is superior to single or parallel blockchains due to the maximum reveal principle. When you mine a block and share all the hints you know about the block, you maximize the information you send. Ghost DAG GhostDAG is the consensus mechanism currently used by Kaspa, which is improved on the basis of PHANTOM consensus. PHANTOM needs to solve NP-hard problems and is not suitable for practical applications. Instead, we exploit the intuition behind PHANTOM to design a greedy algorithm GHOSTDAG, which can be implemented more efficiently. We formally prove that GHOSTDAG is secure because its block order becomes difficult to reverse over time. The main achievements of GHOSTDAG can be summarized as follows: given two transactions txtx2 published at a certain point in time and embedded in blockDAG, the probability that the order of GHOSTDAG changes over time between tx1 and tx2 decreases exponentially with time, Even assuming that most of the computing power is held by honest nodes, this results in a non-negligibly high block creation rate relative to the network propagation delay. Similar to PHANTOM, the GHOSTDAG protocol selects a k cluster, which colors blocks blue (blocks within the selected cluster) and red (blocks outside the cluster). However, instead of searching for the largest k clusters, GHOSTDAG uses a greedy algorithm to find k clusters. The algorithm constructs the blue set of the DAG by first inheriting the blue set of the best tip Bmax (i.e. the tip with the largest blue set in the past), and then adding to the Bmax past blue set chunks in a way that retains the blue set chunks beyond the Bmax past. middle. k cluster attributes. Observe that this greedy inheritance rule produces a chain: the last block in the chain is the selected tip of G, Bmax; the next block in the chain is the selected tip of the past DAG (Bmax); and so on all the way to the origin. We use Chn(G) = (genesis =Chn0(G), Chn1(G), ..., Chnh(G)) to represent this chain. In GHOSTDAG, the final order of all blocks follows a similar path to the shading process: we order the blockDAG by first inheriting the order of Bmax on the past blocks (Bmax), then adding Bmax itself to the order, and finally adding the blocks according to some Topological sorting, beyond the past (Bmax). So essentially, the ordering on the blocks becomes robust with the shading process. Pruning Pruning is a method used in Kaspa to reduce the size of blockDAG. This prevents nodes from having to keep a large amount of blockDAG data registered. Due to the pruning mechanism, Kaspa nodes only require each decentralized machine to store approximately 3 days of previous history. This allows the creation of many nodes for our network without requiring large amounts of storage. The pruning mechanism used by Kaspa is unique to our blockDAG and GhostDAG consensus methods. The goal is to design a pruning algorithm that is resistant to pruning attacks by 49% attackers. Our design approach employs the devices of finality and invalidation rules. 1.) Finality is the practice of not allowing reorganization below a certain fixed depth, and blocks that are not finalized may not be pruned. On the other hand, finalized blocks are typically not pruned since the data they contain may be needed to compute the UTXO set of the incoming block. 2.) Invalidity Rules: First rule: If a block is invalid, any blocks pointing to it are also invalid. Since we discarded these blocks, we cannot trust the blocks pointing to them because the data is not available. Second rule: If there is a block D in B.Past that is in a BPAnticone, and there is no kosherizing block, block B is invalid. Rule 3: Bounded merging, or limiting the size of the merged block set such that the merged set of block B is defined as the set of blocks in B.Past that are neither B.SelectedParent nor B.SelectedParent.Past subject to the fixed parameter L constraints.