Argon

[Shai (Deshe) Wyborski @DesheShai]

Huge news $kas! I'm so excited that I physically cannot get straight to the point without gushing a little bit, so bear with me (or skip ahead). The tl;dr is that @MichaelSuttonIL revolutionized cryptocurrency (yes, again).

When asked what makes $kas stand out from other projects, my answer is usually "the scientific standard". Building and developing means constantly facing pressure to quickly deliver. A pressure that is obviously in tension against the exact deliberation required to provide high-quality solutions established via rigorous reasoning. (This is essentially why we keep seeing projects launching half-baked ideas, and realizing a bit too late that they are crippled by being committed to a debilitatingly flawed tech).

Kaspa's unprecedented technological achievements are a testament to the huge long-run benefits of adhering to a stringent academic standard. Only patience can allow radical new ideas to grow into landscape changing technologies that are landscape changing, yet understood well enough to be used safely. Even if this patience means taking more than half a decade of development before even launching, or delaying a much anticipated release by a few months.

Kaspa is cavalcade of groundbreaking ideas. Most community members know that, at the core, there is GHOSTDAG, the first trilemma solving consensus protocol. But there is so much more. Kaspa is packed with groundbreaking theory and engineering feats that were required to make it work without compromising its quality. Designing the pruning algorithm required developing the previously unexplored theory of pruning attack in DAGs. Understanding the effective capacity of the network relies on deep game theoretic analysis of how transaction inclusion works in light of parallelism. Implementing GHOSTDAG required tackling, and partially solving, a major open problem in the theory of data structures, and so on.

And today, we present a new solution to another old problem: state bloat.

The problem is, essentially, that each node in the network must carry a list of all positive balances (namely, the UTXO set). As the network sees more usage, and more wallets are created, the storage requirements of each node grows. This grow can be either organic or malicious (via a dust attack).

This problem is deceptively hard and crucial, and previous attempts to tackle it are unsatisfactory for many reasons. All that I know of rely either on using accumulators to delegate maintaining the state to the users, or restricting the storage period of data by charging rate or depreciating the value (demurrage). I will not digress into discussing the disadvantages of these approaches, but they are formidable.

At least this was the landscape, until Michael had this crazy idea: what if we somehow found a way to make wasting storage quadratically expensive? That is, set some policy for pricing transactions (in terms of the block space they consume) such that wasting n times the storage costs n^2 times the blockspace?

For people who are familiar with the matter, the mere suggestion seems absurd, delusional even. I mean, the cost must be computed per transaction so surely, no matter how you price it, it couldn't grow much faster than the number of transactions, right? So no matter your pricing policy, a clever attack should always be able to find some way to only pay linear costs for a storage attack, right?

Wrong! I was wrong, and M was right. He indeed managed to find a formula, and an infuriately simple one at that, with the magic "local-to-global" property we desired: the cost of a transaction only relies on the data within that transaction, yet, an adversary attempts to waste storage will pay a price quadratic in the amount of storage they have wasted, regardless of how they structured their transaction! (Well, at least it seemed to have this property, actually proving it turned out surprisingly difficult, and required several weeks of combined effort).

This insight affords a brand new way to mitigate state bloat. The first one that does not require a complete overhaul of how accounts are managed, and is in fact almost completely transparent to end-users.

I strongly believe this fabulous discovery will have a huge impact on how many projects approach the state size problem.

In KIP9, we present 1. a Kaspa-centric specification of the new anti-bloat technology, 2. a broader, yet still informal, discussion of the theory supporting the specification:
https://t.co/maCJyd43cm
For those who want to participate in professional discourse about the proposal, we have created this thread:
https://t.co/61AjWk5c3P
For a less emotional and more composed statement, more concentrated on the rusty-kaspa perspective, see the Discord announcement:
https://t.co/fKSVzedrnF

All of the theoretic assertions required for the security of this implementation have been rigorously proved. In the following weeks, we will post a research paper presenting the theoretic work as well as discussing the generality of the result (which goes will beyond the UTXO model).

As usual, h/t to @rhubarbmedia for the graphic, adapting the cover of the charming book "Dr. Euler's Fabulous Formula" (which is, btw, a delightful read I encourage you all to pick up).