Kaspa where to (Part II)

1. Crypto winters are warm for projects with character.
2. Last month Michal Sutton and I published the DAGKNIGHT protocol (DK), which to the best of our knowledge is the first POW consensus protocol that is responsive to the network’s actual (*adversarial) latency while being resilient to 49% byzantine attackers. DK is the culmination of nearly three years of research, a period in which we weren’t at all sure if the aforementioned property is at all possible to achieve.¹
3. Some work still needs to be done before considering DK for Kaspa:
   
   (i) Completing several missing details in the proof section.
   
   (ii) Preparing the paper for peer-review (depends on conference target).
   
   (iii) Devising efficient algorithms — the current pseudocode is highly inefficient, as it was optimized for ease of reasoning rather than real world implementation.
   
   (iv) Adapting the consensus algorithm to meet additional requirements of an actual cryptocurrency, e.g., the need to regulate minting, control difficulty, and enforce pruning, all of which require a responsive synchronous protocol (rather than DK’s partially synchronous operation mode).
4. Similarly to GHOSTDAG, DK enables high bps (blocks per second), just with much faster confirmation times. Some research needs to be done in order to suggest the optimal bps — increasing the rate indefinitely doesn’t necessarily shorten confirmation times, as it increases the higher relative latency or DAG width. The increase is both due to more blocks created per second and due to these blocks’ headers being larger. Regarding the latter factor, one can envision a scenario where confirmation times improve by reducing the number of block references inside a block (either in consensus or as a default mining rule), but whether or not this is the case is pending further research.
5. DK enables additional features, on which more research is needed.
   
   (i) One example that comes to mind is flexcaps, a proposal to allow miners to create blocks of different sizes and difficulties. While proposed originally for Bitcoin, at high block rates flexcaps require the DK consensus. To see the connection, observe that larger blocks → higher propagation delay of blocks → more blocks created in parallel → wider DAG; and the DK protocol uniquely does not need to bound in advance the width of the DAG, and can cope with it varying even across short timespans. One motivation for flexcap is to support, in times of peak demand, a higher throughput than that which the system can support on average. Indeed, large blocks consume both instantaneous load on the system (CPU, network congestion, etc.) and an accumulating load (larger UTXO → higher RAM and disk I/O for later block processing), which justifies a gap between the maximum limit on resource consumption and the average one.² This gap is enabled through flexcaps (or through the similar elastic block cap proposal).
   
   (ii) Another potential feature is the stealth txns, a construction which utilizes the asynchrony caused by high bps to protect users from MEV (relevant when smart contracts will be developed). More generally, and still in the context of MEV, the fact that many miners can create a block in the “next round”, can be utilized to facilitate richer transaction fee mechanisms, in some resemblance to Flashbots’ recent SUAVE.
6. Similarly to the Rust upgrade, this consensus upgrade will require a new grant request from the community. A suggested scope and raise amount will follow. I hope miners and other Kaspa whales will find this initiative as desirable and long-term profitable as the previous grant. Our community is evergrowing in size and interests, and raising large funds in the future might become harder and harder, at which point we will need to find other structures to maintain development. Hopefully we haven’t reached yet the tipping point.
7. Speaking of community size, a Discord moderator pressed a wrong button this week and accidentally kicked out all inactive users from the server, reducing Kaspa Discord community (~12k) by about 25%. The good news is that we learnt that ~9k members were apparently active in the last 30 days, which speaks volume of the quality of the community.
8. In the spirit of thanksgiving, I am grateful to all 9k of you for turning Kaspa from a sound protocol to a sound money.

[1] More accurately, one of us was positive throughout that a possibility is within a hand’s reach, and the other was skeptic and believed an impossibility result was lurking in the dark. Interestingly, the roles reversed with respect to the question whether Kaspa can take off. We swore not to reveal the corresponding identities of the weak in faith, but the reader can be assured that between the two of us the truth always lies.

[2] In Bitcoin, where there’s no pruning of historical data, the gap is even larger, due to initial blockchain download that full nodes go through by default when onboarding.