Some of you may remember an article I published years ago, Understanding Lightning Network Using an Abacus, which I wrote after it became clear to me that many people didn’t fully understand how Lightning works. At the time, my goal was not to explain the cryptography or implementation details of Lightning, but to demystify the core idea behind payment channels. I used the analogy of the abacus to focus on the concept rather than the mechanics. It worked extremely well and people later adopted the abacus analogy to explain Lightning to noobs.
Lately I’ve been having a strong feeling of déjà vu.
When I talk about Spark, I notice a similar pattern. Some people know how to say “state chain,” but for most the concept ends there. And as with Lightning back then, the problem is not a lack of intelligence or effort, but simply that the underlying mental model is not clear. So I’ll try the same approach again: explain how Spark works conceptually, without getting into cryptographic terminology.
At its core, Spark allows users to send and receive bitcoin without broadcasting on-chain transactions. Bitcoin does not move in the chain when ownership changes. What changes instead is who can jointly authorize their spending. This joint authorization is shared between the user and a group of operators called a Spark Entity (SE).
To explain how this works, imagine that spending a certain set of bitcoin on Spark requires a simple two-piece puzzle:
- One piece of the puzzle is held by the user.
- The other piece is owned by the SE.
Only when both matching pieces come together can the bitcoin be spent. Another set of bitcoin requires the completion of another puzzle.
Now let’s see what happens when ownership changes.
Initially, Alice holds a puzzle piece that matches the piece the SE is holding. She can spend her bitcoins by combining the pieces and completing the puzzle. When Alice wants to send her bitcoins to Bob, she has Bob create a new puzzle together with the SE. It is important that the puzzle itself does not change: the old and the new puzzle have the same shape, but the pieces that make up the puzzle change. The new puzzle is intended for Bob: one side is associated with Bob and the other with the SE. From then on, only Bob’s piece matches the SE’s piece. Alice may still keep her old puzzle piece, but it’s useless now. Because the SE has destroyed its matching piece, Alice’s piece no longer fits on any other piece and cannot be used to spend the bitcoin. Ownership has effectively moved to Bob, even though the bitcoin in question has never been moved on-chain.
Bob can later repeat the same process to send the same set of bitcoin to Carol, and so on. Each transfer works by replacing the puzzle pieces, not by moving the money up the chain.
At this point the question naturally arises: what if the SE doesn’t simply throw away its old puzzle piece? In that case, the SE could collude with the previous owner, Alice, and issue Bob’s bitcoin. We have to trust that when ownership moved from Alice to Bob, the SE also destroyed his piece of the puzzle. However, it is important to understand that an SE is not one party. It consists of a group of operators, and the SE side of the puzzle is never in the hands of one operator alone. Replacing the puzzle requires cooperation between multiple operators. No party can secretly keep an old puzzle active or recreate it later. It is enough that one operator acts fairly during a transfer to prevent an old puzzle from ever being reactivated.
The key idea is simple: Spark doesn’t move bitcoin between users. It replaces who has the valid permission to issue them. The on-chain bitcoin does not move. What changes is which two puzzle pieces fit together.
To keep this explanation clear, I deliberately did not end up in Spark’s one-sided exit mechanism. It’s an important part of Spark’s security model, but it would distract from the core idea I want to convey here. The point is that Spark is not a system where users are permanently dependent on the SE. While daily transfers rely on joint authorization, Spark also gives users a way to spend their funds on-chain without requiring the SE’s cooperation. That escape hatch exists by design, it’s just beyond the scope of this explanation.
This post Spark Explained Like You’re Five first appeared on Bitcoin Magazine and was written by Roy Sheinfeld.