A few of it’s possible you’ll bear in mind an article I revealed years in the past, Understanding Lightning Network Using an Abacus, which I wrote after it grew to become clear to me that many individuals didn’t totally perceive how Lightning works. On the time, my aim wasn’t to clarify Lightning’s cryptography or implementation particulars, however to demystify the core concept behind fee channels. I used the analogy of the abacus to deal with the idea fairly than the mechanics. It labored extraordinarily properly and other people later adopted the abacus analogy to clarify Lightning to noobs.
Currently, I’ve been feeling a powerful 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 an absence of intelligence or effort, it’s merely that the underlying psychological mannequin isn’t clear. So I’ll strive the identical method 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 adjustments. As a substitute, what adjustments is who can collectively authorize their spend. This joint authorization is shared between the consumer and a gaggle of operators referred to as a Spark Entity (SE).
To clarify 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 consumer.
- The opposite piece is held by the SE.
Solely when each matching items come collectively can the bitcoin be spent. A unique set of bitcoin would require the completion of a unique puzzle.
Now let’s stroll by what occurs when possession adjustments.
Initially, Alice holds a puzzle piece that matches the piece held by the SE. She will be able to spend her bitcoins by combining the items and finishing the puzzle. When Alice needs 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 aspect 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 still retain her outdated puzzle piece, but it surely’s now ineffective. For the reason that SE destroyed its matching piece, Alice’s piece not matches every other piece and can’t be used to spend the bitcoin. Possession has successfully moved to Bob, regardless 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 may 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. Nonetheless, it’s essential to grasp that an SE shouldn’t be a single social gathering. It consists of a gaggle of operators, and the SE’s aspect of the puzzle isn’t held by one operator alone. Changing the puzzle requires cooperation amongst a number of operators. No single social gathering can secretly preserve an outdated puzzle lively 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 easy: 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 adjustments is which two puzzle items match collectively.
To maintain this rationalization targeted, I deliberately didn’t get into Spark’s unilateral exit mechanism. It’s an essential a part of Spark’s safety mannequin, however it might distract from the core concept I need to convey right here. What issues is that Spark shouldn’t be a system the place customers are completely depending on the SE. Whereas on a regular basis transfers depend on joint authorization, Spark additionally gives customers with a strategy to spend their funds on-chain with out requiring the cooperation of the SE. That escape hatch exists by design, it’s simply exterior the scope of this rationalization.
