Some of you may remember the article I published a few years ago, “Using an Abacus to Understand the Lightning Network.” I wrote this article after it became clear that many people don't fully understand how Lightning works. My goal at the time was not to explain Lightning's encryption or implementation details, but to demystify the core ideas behind the payment channel. I used the analogy of an abacus to focus on the concept rather than the mechanism. It worked so well that people later adopted the abacus analogy to explain lightning to beginners.
Lately, I've been feeling a strong sense of déjà vu.
While discussing Spark, I noticed a similar pattern. Some people know the term “state chain,” but for most people, the understanding stops there. And like Lightning back then, the problem isn't a lack of intelligence or effort, it's simply that the underlying mental model is not clear. So let's try the same approach again. Without getting into cryptographic terminology, I'll explain how Spark works conceptually.
At its core, Spark allows users to send and receive Bitcoin without broadcasting on-chain transactions. Bitcoins do not move on the chain when ownership changes. Instead, what changes is who can jointly approve spending. This joint authorization is shared between users and a group of operators called Spark Entities (SEs).
To illustrate how this works, imagine that in order to spend a particular set of Bitcoins in Spark, you need to complete a simple two-piece puzzle.
- One piece of the puzzle is held by the user.
- The other part is held by SE.
You can only spend your Bitcoin if you have both matching pieces. Different Bitcoin sets require different puzzles to be completed.
Now let's see what happens when ownership changes.
First, Alice has a puzzle piece that matches the piece SE has. She can spend Bitcoin by combining pieces to complete puzzles. When Alice wants to send her Bitcoin to Bob, she allows Bob to create a new puzzle with SE. Importantly, the puzzle itself remains the same. The old and new puzzles have the same shape, but the pieces that make up them change. A new puzzle is designated for Bob. One face is associated with Bob and the other face is associated with SE. From that point on, only the Bob part matches the SE part. Alice may still have the old puzzle pieces, but they are no longer useful. Because SE destroyed the matching part, Alice's part no longer fits into any other part and cannot be used to spend Bitcoin. Even though the Bitcoin in question never moved on-chain, ownership effectively passed to Bob.
Bob can repeat the same process later and send the same set of Bitcoins to Carol, etc. Each transfer works by displacing a piece of the puzzle rather than moving funds up the chain.
At this point, questions naturally arise. What if SE simply doesn't throw away the old puzzle piece? In that case, SE could collude with its previous owner Alice to use Bob's Bitcoin. We have to trust SE that when ownership passed from Alice to Bob, they also destroyed the puzzle piece. However, it is important to understand that SE is not a single party. It is made up of a group of operators, so the SE side of the puzzle is never held by just one operator. Swapping puzzles requires the cooperation of multiple operators. Neither party can secretly keep old puzzles active or recreate them later. It is enough for one operator to act honestly during the transfer to prevent the old puzzle from being activated again.
The key idea is simple. Spark does not move Bitcoin on-chain between users. This replaces anyone who holds valid permissions to use them. On-chain Bitcoin does not move. What changes is which two puzzle pieces fit together.
To keep this discussion focused, I intentionally left out Spark's unilateral termination mechanism. This is an important part of Spark's security model, but it distracts from the central idea I want to convey here. Importantly, Spark is not a system where users are permanently dependent on SE. Although daily transfers rely on co-authorization, Spark also provides users with a way to spend funds on-chain without requiring SE cooperation. This escape hatch is present by design and is beyond the scope of this discussion.
This post “Spark Explained Like You're Five” first appeared in Bitcoin Magazine and was written by Roy Sheinfeld.
