{"id":88,"date":"2021-11-27T20:54:18","date_gmt":"2021-11-27T20:54:18","guid":{"rendered":"https:\/\/kaspa.org\/?p=88"},"modified":"2022-04-22T21:26:54","modified_gmt":"2022-04-22T21:26:54","slug":"kaspa-what-are-we-actually-doing-here","status":"publish","type":"post","link":"https:\/\/kaspa.org\/kaspa-what-are-we-actually-doing-here\/","title":{"rendered":"Kaspa \u2014 What are We Actually Doing Here?"},"content":{"rendered":"
Shai (Deshe) Wyborski<\/a><\/p>\n It is astonishing to see how fast the Kaspa community is growing. But as Kaspa gains more traction and popularity, it becomes obvious to me that most people don\u2019t know what Kaspa actually is<\/em>. This is by no fault of their own, since we have neglected to explain the core technology Kaspa is based on in an accessible manner. Sure, the information exists in technical papers and conference talks, but these are not written with the common user in mind. My goal in this post is to rectify this.<\/p>\n Kaspa is a broad term which describes a complicated system with many components and aspects. But at its core, Kaspa is an implementation of the GHOSTDAG protocol<\/a>, which was first conceptualized by<\/p>\n and\u00a0<\/span><\/p>\n \u00a0<\/span>in 2016 (I joined the efforts two years later) . The entire following post is dedicated to describing this particular aspect of Kaspa.<\/p>\n <\/p>\n Cryptocurrencies are often very complicated, and a lot of users tend to forgo on fully understanding the promise of one coin or another, which is fine. But I think the true power of GHOSTDAG is in its simplicity<\/em>: GHOSTDAG is a very gentle generalization of Nakamoto consensus, and unlike many coins, I believe that anyone who understands Bitcoin can easily understand GHOSTDAG, what it achieves, and how it achieves it.<\/p>\n Furthermore, I hope I can convince you that GHOSTDAG offers a simple (though very hard to implement) solution to the core scaling issue present in Nakamoto consensus (i.e. in any PoW based blockchain<\/em>), whereby it might have the potential to replace Bitcoin and Ethereum as the layer one framework which could carry a decentralized global scale economy (and with that goal in mind, Kaspa is planned to provide tools which will make it easy to develop layer two applications, but that is a story for another post, probably by another person).<\/p>\n This post assumes basic familiarity with Nakamoto consensus (e.g. with Bitcoin), the uninitiated can fill in the gaps with this wonderful video<\/a>.<\/p>\n Bitcoin, and other blockchains, purport a 51% security. That is, they claim that as long as most of the hashes in the network are created by honest miners, the network is protected from adversaries who wish to revert arbitrarily old transactions. But is this actually true? Only approximately. In this section I will explain why this is only approximately true, and why this issue is at the crux of all blockchain<\/em> scaling issues.<\/p>\n Imagine that you are an adversary who wishes to revert a transaction which took place 10 blocks ago. Lets say that you intended to do so since the block was created, so you started making preparations since.<\/p>\n Bitcoin works on a longest chain rule (well, it actually works on a heaviest chain <\/em>rule, but I am sweeping this detail under the rug for simplicity), which means that in order for you to convince the network to switch to a different chain, where this transaction never happened, you would have to create a longer alternative chain faster than the network. If you have less than the computational power of the rest of the network, the probability that you manage to crank out say 12 blocks before the honest network does is ridiculously small.<\/p>\n But here comes the crux: this only happens if the honest network blocks are always arranged in a chain. However, this is not always the case! Every once in a while two honest miners will create blocks at approximately the same time. These blocks will compete with one another until one of them is discarded. Such discarded blocks are often called orphan blocks<\/a>, and even the most conservative approximations claim that at least one in every 150 Bitcoin blocks is orphaned.<\/p>\n This means that in order to revert a transaction, the attacker only need to create slightly less blocks than the honest network: for every 150 honest blocks, the attacker needs to create more than 149 blocks, for which %49.9 of the global hash rate suffices.<\/p>\n This doesn\u2019t seem like a big deal, and indeed there is little difference between a 50.1% attacker and a 49.9% attacker. The problem is that when you try to upscale the throughput of the network (by either increasing the block rate, or the block size) you unavoidably increase the orphan rate, whereby decreasing the security of the network.<\/p>\n The security of any blockchain relies on the fact that the delay between blocks is larger by orders of magnitude than the time it takes the entire network to learn of a new block<\/strong>. Parallel blocks are orphaned, whereby they decrease the growth rate of the honest chain. Overcoming this throughput\/security tradeoff is the main motivation behind the GHOSTDAG protocol.<\/p>\n The core idea is very simple: instead of having any block point to a single parent block, allow it to point to many parents, thus giving the blocks in the network the structure of a DAG<\/a> rather than a chain.<\/p>\n The first natural question about this approach is: what about double spends? If we allow two parallel blocks to coexist, how do we handle the possibility that they contain contradicting transactions?<\/p>\n Very roughly, the solution we are working towards is to choose some ordering of the blocks. That is, we take the DAG structure and arrange it in a chain somehow. We then traverse the chain and include all transactions which do not contradict previous transactions.<\/p>\n But how do we choose this ordering? Well, this is where things get complicated. Choosing an ordering rule is what can make or break a blockDAG. The GHOSTDAG (and its computationally unfeasible precursor PHANTOM) protocols are basically that \u2014 means to order blocks in a DAG.<\/p>\n Before we go into these protocols, let us list some of the properties we expect of a good ordering:<\/p>\n An ordering with the properties above might pose a solution to the scaling problem of ordinary blockchains, by removing the need for a large block delay. And indeed, the GHOSTDAG protocol is provably secure regardless<\/strong> of the ratio between the block delay and block round trip time. That is the central promise of GHOSTDAG.<\/p>\n For a more detailed account of how orphaned blocks affect Bitcoin security read this post<\/a>.<\/p>\n Before diving into GHOSTDAG, it is instructive to consider a scenario where efficiency is not a concern. That is, we assume that any combinatorial calculations, even NP complete ones<\/a>, are feasible (though we still assume there exists a hash function which is hard to invert, or else the entire PoW paradigm crumbles). In such a world, how would you design a good ordering of the blocks?<\/p>\n The core idea is that the honest network blocks should be well connected<\/em> in some way. Since all honest miners are communicating with each other and are not withholding blocks, their honest work should form a well connected DAG. An attacker working on a side chain would seem very disconnected from the main chain.<\/p>\n(if you are unfamiliar with Kaspa you are still welcome to read the post, or you can first check out our <\/span>website<\/a> and <\/span>Discord server<\/a>)<\/span><\/h1>\n<\/div>\n
The Nakamoto Consensus Scaling Problem<\/h1>\n
So How Can We Allow Parallel Blocks?<\/h1>\n
\n
PHANTOM \u2014 GHOSTDAG In an Ideal World<\/h1>\n