Spark expliqué comme si vous aviez cinq ans

Certains d’entre vous se souviennent peut-être d’un article que j’ai publié il y a des années, Comprendre le réseau Lightning à l’aide d’un boulier, que j’ai écrit après qu’il m’est apparu clairement que de nombreuses personnes ne comprenaient pas complètement le fonctionnement de Lightning. À l’époque, mon objectif n’était pas d’expliquer la cryptographie ou les détails de mise en œuvre de Lightning, mais de démystifier l’idée centrale des canaux de paiement. J’ai utilisé l’analogie du boulier pour me concentrer sur le concept plutôt que sur la mécanique. Cela a extrêmement bien fonctionné et les gens ont ensuite adopté l’analogie du boulier pour expliquer Lightning aux noobs.

Ces derniers temps, j’ai ressenti une forte impression de déjà-vu.

En parlant de Spark, je remarque un schéma similaire. Certains savent dire « statechain », mais pour la plupart, c’est là que s’arrête la compréhension. Et comme avec Lightning à l’époque, le problème n’est pas un manque d’intelligence ou d’effort, c’est simplement que le modèle mental sous-jacent n’est pas clair. Je vais donc réessayer la même approche : expliquer comment Spark fonctionne conceptuellement, sans entrer dans la terminologie cryptographique.

À la base, Spark permet aux utilisateurs d’envoyer et de recevoir des bitcoins sans diffuser de transactions en chaîne. Le bitcoin ne bouge pas sur la chaîne lorsque la propriété change. Au lieu de cela, ce qui change, c’est qui peut autoriser conjointement ses dépenses. Cette autorisation conjointe est partagée entre l’utilisateur et un groupe d’opérateurs appelé Spark Entity (SE).

Pour expliquer comment cela fonctionne, imaginez que dépenser un ensemble donné de bitcoins sur Spark nécessite de résoudre un simple puzzle en deux pièces :

• Une pièce du puzzle est détenue par l’utilisateur.
• L’autre pièce est détenue par le SE.

Ce n’est que lorsque les deux pièces correspondantes sont réunies que le bitcoin peut être dépensé. Un ensemble différent de bitcoins nécessitera la réalisation d’un puzzle différent.

Voyons maintenant ce qui se passe en cas de changement de propriétaire.

Initialement, Alice tient une pièce de puzzle qui correspond à la pièce détenue par le SE. Elle peut dépenser ses bitcoins en combinant les pièces et en complétant le puzzle. Lorsqu’Alice souhaite envoyer ses bitcoins à Bob, elle permet à Bob de créer un nouveau puzzle avec le SE. Surtout, le puzzle lui-même ne change pas : l’ancien et le nouveau puzzle ont la même forme, mais les pièces qui le composent changent. Le nouveau puzzle est destiné à Bob : un côté est associé à Bob et l’autre au SE. À partir de ce moment, seule la pièce de Bob correspond à la pièce du SE. Alice conserve peut-être encore son ancienne pièce de puzzle, mais elle est désormais inutile. Depuis que le SE a détruit sa pièce correspondante, la pièce d’Alice ne correspond plus à aucune autre pièce et ne peut pas être utilisée pour dépenser le bitcoin. La propriété a effectivement été transférée à Bob, même si le bitcoin en question n’a jamais été mis en chaîne.

Bob peut ensuite répéter le même processus pour envoyer le même ensemble de bitcoins à Carol et ainsi de suite. Chaque transfert fonctionne en remplaçant les pièces du puzzle, et non en déplaçant les fonds en chaîne.

À ce stade, une question se pose naturellement : que se passerait-il si la SE ne se débarrassait tout simplement pas de son ancienne pièce du puzzle ? Dans ce cas, la SE pourrait s’entendre avec l’ancien propriétaire, Alice, et dépenser le bitcoin de Bob. Nous devons faire confiance à la SE : lorsque la propriété est passée d’Alice à Bob, elle a également détruit sa pièce du puzzle. Il est toutefois important de comprendre qu’une SE n’est pas un parti unique. Il se compose d’un groupe d’opérateurs et la partie SE du puzzle n’est jamais détenue par un seul opérateur. Le remplacement du puzzle nécessite la coopération de plusieurs opérateurs. Aucune partie ne peut secrètement garder actif un vieux puzzle ou le recréer plus tard. Il suffit qu’un opérateur agisse honnêtement lors d’un transfert pour éviter qu’un vieux puzzle ne soit réactivé.

L’idée clé est simple : Spark ne déplace pas de bitcoin en chaîne entre les utilisateurs. Il remplace celui qui détient l’autorisation valide pour les dépenser. Le bitcoin en chaîne ne bouge pas. Ce qui change, c’est les deux pièces du puzzle qui s’emboîtent.

Pour que cette explication reste ciblée, je n’ai intentionnellement pas abordé le mécanisme de sortie unilatérale de Spark. Il s’agit d’une partie importante du modèle de sécurité de Spark, mais cela détournerait l’attention de l’idée principale que je souhaite transmettre ici. Ce qui compte, c’est que Spark n’est pas un système où les utilisateurs dépendent en permanence du SE. Alors que les transferts quotidiens reposent sur une autorisation conjointe, Spark offre également aux utilisateurs un moyen de dépenser leurs fonds en chaîne sans nécessiter la coopération de la SE. Cette trappe de secours existe par conception, elle sort juste du cadre de cette explication.