(This post is part of the Understanding GHOSTDAG series)

Preface

When Kaspa launched almost three years ago, I found myself in an awkward position. It has been almost a year since I left DAGLabs. In particular, I was not involved in the efforts to mature the codebase into a working mainnet. I was left behind, out of the loop, dated. However, two things were clear: I’m one of the select few who understand the theory, and I want to contribute.

So, I took it upon myself to do what I could to communicate Kaspa to the community. This endeavor quickly exceeded the limits of my knowledge and has become a learning experience as well as a teaching. one.

It is hard to overstate just how much I have learned since. I became familiar with many aspects of Kaspa that I had little to do with and learned so much about cryptocurrencies in general. My urge to learn, review, discuss, and sometimes even criticize other projects has taught me important lessons about how cryptocurrency technology is perceived in industry and retail. Engaging directly with the community, other communities, and developers completely changed my perspective on how Kaspa should be explained. Kaspa is hard to understand, and profound observations were still waiting to be made well after launch. Many talking points that are now “common knowledge” (like, say, how high BPS incentivizes small miners, the benefits of a randomized fee market, or why ASIC mining is actually more decentralized) were known to no one at launch, including all contributors. I like to think I played a part in reaching these observations and making them widely known.

During these years, I amassed a huge amount of educational Kaspa content in many forms: Twitter threads, Medium posts, YouTube workshops, interviews on various outlets, live lectures in various venues, etc. Digging through these resources, I can identify many shifts in my positions and pedagogical approach. There are many things I have written before that I would now write differently. There are several statements I made that I now realize are slightly on the presumptuous side, and I have since grown a more nuanced and mature position.

And then, not so long ago, came a realization: I am no longer in this indeterminate phase. My perception of Kaspa and the cryptocurrency industry as a whole has matured and stabilized. It might still evolve, but for now, I do not see it shifting, at least not on any of the ideas and principles that underwrite Kaspa. A second understanding followed: it is time to capitalize on my considerable yet sporadic efforts. I will take all the knowledge I have accumulated and documented and organize it into a single, well-structured, consistent, and coherent package of everything I think anyone seeking to get into the theory behind Kaspa should know. Simply put, I decided to write a book.

And so, here we are in the first of a long sequence of posts that will form the basis for my writing project: Understanding GHOSTDAG. I estimate I will publish about sixty to eighty posts, hopefully around two a week.

I aspire to write somehow a book that is, on the one hand, a professional textbook but, on the other, approachable to many audiences. I haven’t figured out how to do this yet, and I will learn as I go. Cracking this is one of the purposes of making these posts. For now, I can say that some sections will be marked with * to indicate that they are more on the technical/mathematical side but can be skipped.

A computer scientist writing a research paper related to GHOSTDAG will (hopefully) attempt to understand the protocol much better than a day trader would. The goal of this book is somewhere in between, probably leaning a bit more toward the computer scientist. It will not give the day trader a level of understanding akin to a computer scientist (for that, they will have to learn quite a bit of graduate-level math), but it will give the computer scientist ample resources to fill in the blanks and pave the road towards cutting-edge research papers.

There is also an “ulterior” motive to this book: I am trying to drive home the point that math is important. To a cryptographer, the current shape of the crypto industry is terrifying. The brave new world of decentralized consensus is plagued with very fundamental yet very open questions. These gaps in our understanding make it very difficult to chart the risks facing permissionless consensus protocols, and set standards to address them. Yet, new forms of security and trust are constantly deployed into production, onboarding retailers for millions and even billions of dollars, without any security standard to follow. Imagine a world where there are no safety standards for construction. Engineers can build a sky-scraper, a bridge or a road however they like. Occasionally, a building collapses killing everyone inside. But the eeriest thing about this world is that no one really makes a fuss about something as trivial as a skyscraper imploding into a crater. “They should have better chosen a building to stay in,” people say, and suggest that they should have “done their own research.” Crazy, right? Well, that’s how I see projects relying on crazy new trust models and cryptographic hodge-podges deploying their mainnets without nearly enough due diligence. This is sadly an extremely common sight in the industry. Respectable crypto projects constantly get away with a lack of scrutiny that would not be tolerated in any other type of engineering.

The way I see it, the main enabler of this unfortunate reality is the crazy fact that in the crypto industry scientists and engineers sell contenders for planetary scale economy to retail. A customer buying a loaf of bread usually knows what they want and what to look out for in bread. How many crypto investors can even state what a cryptocurrency should satisfy to be suitable for “replacing fiat,” or any other goal in this vein? The answer might as well be zero. My opinion is that measures should be taken to close the gap from both sides. Industry leaders should work towards creating a standard, a “blockchain engineer’s security handbook” that sets a sufficiently high lower bar for scrutinizing a cryptocurrency project. From the retail side, investors should be afforded resources for learning what they should expect and demand from engineers proposing a novel form of permissionless consensus. I hope my book could make a modest contribution to this valiant effort.

Finally, I have reasons to suspect that most of the crowd these posts will attract is not a professional one — it is not implausible that many of you have never read a theory book before — so allow me to give you a word of advice: read these posts slowly. Allow yourself to take breaks to mull things over, make sure you understand a concept before moving on to the next, ask yourself questions to test your understanding, and don’t be afraid to backtrack if you realize you do not understand a concept as well as you thought.

One last thing: I am consistently using the capitalization blockChain instead of blockchain to keep the contrast with blockDAG. I concede that it is a bit of an eye-sore, but you get used to it, and it makes the reading experience a bit easier.

Now, let us see where this will take us.

An Ephemeral Introduction

The format I chose puts me in an awkward position where I have to write an introduction for a text that does not yet exist. Only after I finish a decent portion of the posts will I know what I should have written here. So, for now, I will only write an ephemeral introduction, laying out my tentative plans for future posts to give you something to expect. This section (and actually, the entire post) will be updated as I better understand what I got myself into.

Preliminaries and Expectations

I do not assume the reader has any professional knowledge about consensus theory, but I am not expecting blank slates either. This book is better suited for people somewhat familiar with the topics being discussed, at least on some personal level. Knowing what the UTXO model is or what hash functions and Merkle trees are is not required, but it could not hurt either.

Some parts of this book are more mathematically demanding than others. These parts are marked with * (starred) and can be skipped. Starred sections might depend on each other, but I am doing my best so that non-starred sections will not rely on starred sections.

This book is concentrated on consensus. Yes, the data layer makes some appearances, but it is not the focus here. This series will not teach you the format of coinbase transactions, how the mempool or P2P logic works, or how wallets compute transactions. For all of these, I am planning a parallel project called Implementing BlockDAG and GHOSTDAG. The latter will complement the current project, aiming at developers seeking a deep dive into the mechanics of the rusty Kaspa codebase.