A few of chances are you’ll bear in mind an article I revealed years in the past, Understanding Lightning Network Using an Abacus, which I wrote after it turned clear to me that many individuals didn’t absolutely perceive how Lightning works. On the time, my objective wasn’t to elucidate Lightning’s cryptography or implementation particulars, however to demystify the core concept behind fee channels. I used the analogy of the abacus to concentrate on the idea relatively than the mechanics. It labored extraordinarily properly and folks later adopted the abacus analogy to elucidate Lightning to noobs.
These days, I’ve been feeling a robust sense of déjà vu.
When discussing Spark, I discover an analogous sample. Some know to say “statechain”, however for many, that’s the place the understanding ends. And as with Lightning again then, the issue isn’t a scarcity of intelligence or effort, it’s merely that the underlying psychological mannequin isn’t clear. So I’ll attempt the identical strategy once more: clarify how Spark works conceptually, with out stepping into cryptographic terminology.
At its core, Spark permits customers to ship and obtain bitcoin with out broadcasting on-chain transactions. The bitcoin doesn’t transfer on-chain when possession modifications. As a substitute, what modifications is who can collectively authorize their spend. This joint authorization is shared between the person and a gaggle of operators referred to as a Spark Entity (SE).
To elucidate how this works, think about that spending a given set of bitcoin on Spark requires finishing a easy two-piece puzzle:
- One piece of the puzzle is held by the person.
- The opposite piece is held by the SE.
Solely when each matching items come collectively can the bitcoin be spent. A distinct set of bitcoin would require the completion of a distinct puzzle.
Now let’s stroll by means of what occurs when possession modifications.
Initially, Alice holds a puzzle piece that matches the piece held by the SE. She will spend her bitcoins by combining the items and finishing the puzzle. When Alice desires to ship her bitcoins to Bob, she permits Bob to create a brand new puzzle along with the SE. Importantly, the puzzle itself doesn’t change: the outdated and new puzzle have the identical form, however the items that compose it change. The brand new puzzle is designated for Bob: one facet is related to Bob and the opposite with the SE. From that time on, solely Bob’s piece matches the SE’s piece. Alice should retain her outdated puzzle piece, but it surely’s now ineffective. For the reason that SE destroyed its matching piece, Alice’s piece not suits every other piece and can’t be used to spend the bitcoin. Possession has successfully moved to Bob, despite the fact that the bitcoin in query by no means moved on-chain.
Bob can later repeat the identical course of to ship the identical set of bitcoin to Carol and so forth. Every switch works by changing the puzzle items, not by transferring the funds on-chain.
At this level, a query naturally arises: what if the SE merely doesn’t discard its outdated puzzle piece? In that case, the SE might collude with the earlier proprietor, Alice, and spend Bob’s bitcoin. We have to trust the SE that, when possession moved from Alice to Bob, it additionally destroyed its piece of the puzzle. Nevertheless, it’s vital to grasp that an SE will not be a single celebration. It consists of a gaggle of operators, and the SE’s facet of the puzzle isn’t held by one operator alone. Changing the puzzle requires cooperation amongst a number of operators. No single celebration can secretly maintain an outdated puzzle energetic or recreate it later. It’s sufficient for one operator to behave actually throughout a switch to forestall an outdated puzzle from ever being reactivated.
The important thing concept is straightforward: Spark doesn’t transfer bitcoin on-chain between customers. It replaces who holds the legitimate authorization to spend them. The on-chain bitcoin doesn’t transfer. What modifications is which two puzzle items match collectively.
To maintain this clarification targeted, I deliberately didn’t get into Spark’s unilateral exit mechanism. It’s an vital a part of Spark’s safety mannequin, however it could distract from the core concept I wish to convey right here. What issues is that Spark will not be a system the place customers are completely depending on the SE. Whereas on a regular basis transfers depend on joint authorization, Spark additionally offers customers with a technique to spend their funds on-chain with out requiring the cooperation of the SE. That escape hatch exists by design, it’s simply outdoors the scope of this clarification.
