# Spark: platební vrstva nad Bitcoinem

Bitcoin má za sebou více než patnáct let existence, ale jako běžný platební prostředek jej stále používá především relativně úzká skupina bitcoinových nadšenců. Lidé, kteří chodí na bitcoinové meetupy, konference a aktivně se o technologii zajímají, jsou ochotni Bitcoinem platit. Pro většinu běžných uživatelů je ale situace jiná.

Jednou z technologií, které se to snaží změnit, je **Spark** – nová druhá vrstva nad Bitcoinem zaměřená především na platby. Pokouší se nabídnout uživatelskou jednoduchost běžných platebních systémů, aniž by se úplně vzdala self-custody a možnosti jednostranně se vrátit na bitcoinový blockchain.

## Proč lidé Bitcoinem neplatí?

Důvodů je samozřejmě mnoho, ale tři se zdají být zvlášť důležité.

První bychom mohli nazvat **„pizza guy syndromem“**. Příběh Laszla Hanyecze, který v roce 2010 zaplatil 10 000 bitcoinů za dvě pizzy, je dnes součástí bitcoinového folkloru. Současně ale vytváří psychologický problém: kdo očekává další růst ceny Bitcoinu, nechce se stát dalším člověkem, který dnes utratí něco, co může mít za několik let mnohonásobně vyšší hodnotu.

Z bitcoinového pohledu lze samozřejmě namítnout, že člověk může utracené bitcoiny okamžitě znovu nakoupit. Běžní uživatelé ale takto často neuvažují a raději utrácejí fiat měnu.

Druhým problémem je **uživatelská zkušenost**. Platba kartou, telefonem nebo hodinkami je mimořádně jednoduchá: zařízení přiložíme k terminálu a během okamžiku je hotovo. Bitcoinové platby se tomu postupně přibližují, ale především u Lightning Network mohou stále zahrnovat otevření peněženky, skenování QR kódu, čekání na nalezení trasy nebo řešení problémů s likviditou.

Pro technicky orientovaného uživatele to nemusí být významná překážka. Má-li ale nová technologie nahradit technologii zavedenou, nestačí, aby byla stejně pohodlná. Musí uživateli nabídnout dostatečně silný důvod ke změně.

Třetím problémem je **kapitálová efektivita Lightning Network**. Lightning funguje pomocí platebních kanálů a v těch musí být uzamčena likvidita. Pokud by měl každý uživatel například schopnost přijmout ekvivalent sta dolarů, při miliardách uživatelů by šlo o obrovské množství kapitálu uzamčeného pouze kvůli zajištění platební likvidity.

Právě zde Spark nabízí jiný přístup.

# Co Spark nabízí

Spark je platební vrstva nad Bitcoinem. Nepoužívá zabalenou reprezentaci BTC, ale skutečné bitcoinové UTXO, nad nimiž vytváří svou off-chain strukturu.

Z uživatelského pohledu má několik důležitých vlastností.

Transakce jsou rychlé a není nutné zakládat platební kanály ani spravovat jejich likviditu. Uživatel si může nainstalovat peněženku, přijmout prostředky a opět je odeslat, aniž by musel řešit příchozí a odchozí kapacitu podobně jako u Lightning Network.

Velmi důležitou vlastností je **unilateral exit**, tedy možnost jednostranného návratu na první vrstvu Bitcoinu. I kdyby provozovatelé Sparku přestali spolupracovat, uživatel má mít předem podepsané transakce, pomocí nichž dokáže své prostředky dostat na blockchain.

Spark podporuje také **offline příjem**. Příjemce nemusí být v okamžiku platby aktivně připojený podobně jako u klasické on-chain bitcoinové transakce.

Další významnou vlastností je propojení s Lightning Network. Spark není koncipován jako jeho náhrada. Ze sparkové peněženky lze platit Lightning invoice a přes Lightning lze také přijímat.

A konečně Spark počítá s podporou **stablecoinů**. To může být důležité především pro uživatele, kteří chtějí využívat bitcoinovou platební infrastrukturu, ale nechtějí nést cenovou volatilitu BTC.

Z tohoto pohledu se Spark snaží hledat kompromis mezi dvěma extrémy. Na jedné straně jsou velmi pohodlné systémy typu Apple Pay, jejichž používání ovšem vyžaduje značnou důvěru v provozovatele. Na druhé straně může stát vlastní Bitcoin a Lightning infrastruktura, kde lze množství potřebné důvěry silně omezit, ale za cenu podstatně vyšší technické složitosti.

Spark se pokouší najít místo někde mezi nimi.

# Od statechainů ke Sparku

Technický základ Sparku vychází z konceptu **statechainů**.

Pro pochopení principu stačí připomenout jednu vlastnost bitcoinové kryptografie. Máme-li dva privátní klíče \(a\) a \(b\), odpovídají jim veřejné klíče \(A\) a \(B\). Veřejné klíče lze matematicky kombinovat a odpovídajícím způsobem lze kombinovat také příslušné privátní klíče.

Díky Schnorrovým podpisům a souvisejícím protokolům mohou dvě strany společně ovládat prostředky, aniž by si navzájem musely odhalit své privátní klíče.

Ve zjednodušeném statechainu máme například Alici a operátora. Oba přispějí svou částí klíče a vytvoří společný veřejný klíč. Alice na něj odešle bitcoin.

Samotný tento krok by však nestačil. Kdyby operátor později přestal spolupracovat, Alice by se ke svým bitcoinům nemusela dostat. Proto si ještě před publikováním vkladové transakce nechá vytvořit a podepsat transakci, pomocí níž může prostředky v budoucnu jednostranně získat zpět.

Tato transakce obsahuje **timelock**.

Bitcoin rozlišuje absolutní a relativní časové zámky. Absolutní timelock určuje například číslo bloku, od kterého lze transakci použít. Relativní timelock říká, kolik bloků musí uplynout od potvrzení určité předchozí transakce.

## Převod vlastnictví

Předpokládejme, že Alice chce své statechainové prostředky předat Bobovi.

Bob vytvoří vlastní část klíče a rozdíl mezi jeho částí a částí Alice se použije k úpravě – „tweaku“ – klíče operátora. Výsledný společný klíč zůstává matematicky kompatibilní se stejným bitcoinovým výstupem, vlastníkem je však nyní Bob s operátorem.

Současně Bob obdrží novou předem podepsanou exit transakci s kratším timelockem.

Alice stále může mít svou starou transakci, ale Bobova transakce se stane použitelnou dříve. Pokud by Alice chtěla podvádět, Bob ji tedy může předběhnout.

Celý mechanismus ovšem stojí na velmi důležitém předpokladu: **operátor musí původní klíč opravdu smazat**. Pokud si jej ponechá, mohl by později spolupracovat s předchozím vlastníkem a pokusit se vytvořit alternativní historii vlastnictví.

Mazání starých klíčů bude hrát zásadní roli také v trust modelu Sparku.

# Problém klasických statechainů: časová bomba

Původní konstrukce statechainů má nepříjemnou vlastnost.

Při každém převodu vlastnictví se timelock nové exit transakce zkracuje. Alice může mít například transakci s hodnotou 100, Bob s 90, Charlie s 80 atd.

Výsledkem je **časová bomba**. Po dostatečně velkém počtu převodů nebo po uplynutí určité doby už timelock nelze dále rozumně zkracovat a poslední vlastník musí prostředky přesunout na blockchain.

Statechain tedy není místo, kde by bylo možné držet prostředky neomezeně dlouho.

Spark tento mechanismus upravuje.

# Branch transakce a relativní timelock

Spark mezi on-chain vklad a exit transakce vkládá další úroveň – **branch transaction**.

Deposit transaction je bitcoinová transakce skutečně potvrzená na blockchainu. Z ní vede branch transaction, která za normálního provozu potvrzena není. Teprve pod ní se nachází další transakce reprezentující jednotlivé části sparkového stromu.

Klíčovým trikem je použití **relativních timelocků**.

Protože branch transaction zatím není potvrzená, nezačne běžet ani relativní časový zámek transakcí pod ní. Časovač se spustí teprve tehdy, když někdo zahájí on-chain exit a branch transaction publikuje.

Tím zmizí původní problém statechainové „časové bomby“. Prostředky mohou zůstávat ve Sparku dlouhodobě, protože relativní timelock se během běžného off-chain provozu vůbec neodpočítává.

# Strom vlastnictví

Druhým omezením jednoduchých statechainů je nemožnost snadno měnit nominální hodnotu převáděného UTXO.

Když do statechainu vložíme jeden bitcoin, přesouváme dále stále tentýž jeden bitcoin. Pro běžný platební systém je to samozřejmě nepraktické.

Spark proto vytváří **stromovou strukturu**.

Například deset bitcoinů lze rozdělit na části 7 BTC a 3 BTC a ty lze dále dělit. Listy stromu – **leaves** – pak reprezentují množství bitcoinů, které patří konkrétním uživatelům.

Zjednodušeně tedy Spark tvoří:

- jednu potvrzenou deposit transaction na bitcoinovém blockchainu,
- jednu či více branch transactions,
- strom dalších transakcí,
- jednotlivé leaves reprezentující vlastnictví,
- předem připravené exit transactions.

Velká část této struktury se za normálního provozu na bitcoinový blockchain nikdy nedostane.

# Vklad prostředků

Při vložení bitcoinů do Sparku vytvoří uživatel společně s operátorem kombinovaný klíč. Z něj vznikne bitcoinová adresa, na kterou směřuje deposit transaction.

Ještě před jejím zveřejněním se ovšem vytvoří potřebná větev a exit transaction. Uživatel tedy nejprve získá „únikovou cestu“ a teprve poté pošle své prostředky do systému.

Smyslem je, aby nikdy nenastala situace, kdy už bitcoin leží na společném klíči, ale uživatel ještě nemá podepsanou cestu, jak jej bez spolupráce operátora získat zpět.

# Výběr ze Sparku

Ze Sparku lze odejít dvěma způsoby.

První je **kooperativní výběr**. Uživatel požádá provozovatele o převod bitcoinů na svou on-chain adresu a všichni spolupracují. Za normálních okolností jde o nejlevnější a nejjednodušší variantu.

Druhou možností je **unilateral exit**.

Pokud operátoři odmítají spolupracovat nebo Spark přestane fungovat, uživatel publikuje předem podepsané transakce potřebné k dosažení svých leaves. Část sparkového stromu se tím přesune na blockchain.

Nevýhodou je cena. Čím složitější část stromu je třeba publikovat a čím vyšší jsou on-chain poplatky, tím dražší může nucený exit být. U velmi malých částek se proto může stát, že by náklady na exit byly srovnatelné s hodnotou samotných prostředků.

Možnost unilateral exitu tedy neznamená, že bude odchod za všech okolností ekonomicky výhodný. Znamená, že není kryptograficky podmíněn souhlasem provozovatele.

# Platby uvnitř Sparku

Při běžné Spark-to-Spark platbě se bitcoinová transakce na blockchainu nevytváří.

Mění se vlastnictví příslušného leafu. Operátoři upraví své části klíče tak, aby nový kombinovaný klíč odpovídal novému vlastníkovi, vytvoří se nové exit transakce a staré části klíčů musí být bezpečně odstraněny.

Samotná platba je tedy především změnou klíčového materiálu a stavových informací, nikoli on-chain přesunem bitcoinů.

# Propojení s Lightning Network

Součástí ekosystému je **Spark Service Provider (SSP)**.

SSP provozuje Lightning infrastrukturu, kanály a potřebnou likviditu. Uživatel Sparku proto nemusí vlastní Lightning node ani kanály spravovat.

Chce-li uživatel zaplatit Lightning invoice, SSP ji zaplatí prostřednictvím Lightning Network a proti tomu získá odpovídající prostředky ve Sparku. Převod je zkonstruován jako atomická výměna, aby nemohla jedna ze stran získat prostředky bez splnění své části obchodu.

V opačném směru SSP přijme Lightning platbu a odpovídající hodnotu předá uživateli ve Sparku.

Výsledkem je zajímavé rozdělení rolí. Spark nemusí nahrazovat existující Lightning Network. Může ji využívat jako interoperabilní platební síť, zatímco uživatel sám vůbec nemusí řešit Lightning kanály.

# Spark Operator, Spark Entity a SSP

Je důležité rozlišovat několik pojmů.

**Spark Operator (SO)** je provozovatel, který se účastní správy sparkového stavu a práce s klíči.

Operátorů může existovat více a dohromady tvoří **Spark Entity**. Jednotlivé části klíčového materiálu jsou rozděleny mezi více operátorů.

Vedle nich existuje **Spark Service Provider**, který zajišťuje především služby spojené s Lightning Network.

Toto rozdělení souvisí se zásadní otázkou celého Sparku: komu a čemu vlastně musí uživatel důvěřovat?

# Trust model: nejkontroverznější část Sparku

Na první pohled nabízí Spark téměř ideální vlastnosti: rychlé a levné transakce, offline příjem, žádné kanály, interoperabilitu s Lightning Network, stablecoiny a unilateral exit.

Něco za to ale samozřejmě platíme.

Spark používá model, který lze charakterizovat jako **trust-in-time**. Důvěra je potřeba především v okamžiku převodu vlastnictví.

Při převodu leafu na nového vlastníka musí operátoři odstranit starý klíčový materiál. Pokud se tak stane, pozdější napadení operátora už starý klíč neobnoví. Právě proto je skutečné a nenávratné mazání klíčů tak důležité.

K útoku by bylo potřeba, aby se potřebná množina operátorů domluvila, staré klíče nesmazala a spolupracovala s předchozím vlastníkem.

Spark tedy není trustless v přísném slova smyslu.

## Více operátorů a threshold

Aby systém nebyl závislý na jediném provozovateli, může být klíčový materiál rozdělen mezi více Spark Operators prostřednictvím threshold schématu.

Tím vzniká kompromis mezi bezpečností a dostupností.

Kdyby bylo pro každou operaci nutné, aby byli online všichni operátoři, systém by byl z hlediska důvěry robustní, ale výpadek jediného operátora by mohl zastavit celou síť.

Proto lze použít threshold typu například „2 z N“. Přesné parametry jsou otázkou návrhu sítě.

Čím větší počet nezávislých stran musí útočník ovládnout, tím lépe. Současně však musí zůstat dostatečně snadné vytvořit potřebné kvórum pro běžné transakce.

# Důvěra není binární

Při porovnávání druhých vrstev je lákavé dělit systémy na „trustless“ a „trusted“. V praxi je situace složitější.

I u self-custody peněženky například věříme, že binární aplikace v telefonu odpovídá zveřejněnému zdrojovému kódu. Věříme distribučnímu mechanismu aktualizací. Věříme operačnímu systému a hardwaru.

U Lightning peněženek mohou existovat další předpoklady spojené s dostupností zařízení nebo watchtower služeb.

U federovaných systémů je důvěra vložena do federace. U ecash systémů do provozovatele mincovny. U některých variant Arku je zase nutné v určitém časovém intervalu provést refresh nebo tuto povinnost někomu delegovat.

Smysluplnější než hledat absolutní „trustlessness“ je proto přesně popsat, **komu musí uživatel důvěřovat, v jakém okamžiku a co se stane, když daná strana selže nebo začne podvádět**.

V případě Sparku je množství potřebné důvěry větší než u vlastního Lightning node, ale současně je výrazně jednodušší uživatelská zkušenost.

# Stablecoiny a BTKN

Významnou částí plánů Sparku jsou tokeny a stablecoiny.

K tomu slouží protokol **BTKN**, který umožňuje vydávat tokenová aktiva a převádět je v rámci sparkové infrastruktury.

Token má standardní parametry, například jméno a množství. Zajímavou vlastností je možnost při jeho vydání určit, zda bude **freezeable**, tedy zda jej bude vydavatel schopen na konkrétních adresách zmrazit.

Z bitcoinového pohledu není možnost zmrazení příliš atraktivní. Pro regulované stablecoiny typu USDC nebo USDT je ale prakticky nezbytná.

Podstatné je, že tato vlastnost je součástí parametrů tokenu. Pokud je token vytvořen jako nezmrazitelný, vydavatel tuto pravomoc nemá.

## Proč by stablecoiny na Sparku mohly být zajímavé

Používání stablecoinů na řadě existujících blockchainů má jednu nepříjemnou vlastnost: uživatel potřebuje nativní měnu příslušné sítě na poplatky.

Chceme-li poslat USDC na Ethereu, potřebujeme ETH. Použijeme-li Arbitrum, Optimism nebo Base, opět potřebujeme malé množství ETH na dané síti.

Pro zkušeného uživatele je to drobná komplikace. Pro běžného člověka ale jde o překvapivě špatné UX: drží stablecoin, má v něm peníze, ale nemůže jej odeslat, protože mu chybí jiný token potřebný pouze k zaplacení poplatku.

Ve Sparku by bylo možné účtovat poplatky přímo v převáděném stablecoinu.

Uživatel by tedy například poslal USDT a poplatek by byl rovnou odečten v USDT. Nemusel by vědět, jaký další token slouží jako gas.

Další výhodou mohou být **předvídatelné poplatky**. Místo ceny odvozené od momentálního vytížení blockchainu může služba použít jednoduchý fixní poplatek.

Pro běžné platby nebo remitence je předvídatelnost ceny často důležitější než optimalizace posledního centu.

# Poplatky

Spark-to-Spark transakce byly v době přednášky bez poplatku, což souviselo také s ranou fází projektu. Do budoucna se počítalo spíše s jednoduchými fixními poplatky.

Jiná situace je u Lightning operací.

Spark Service Provider musí provozovat Lightning node, udržovat kanály, obstarávat likviditu a platit náklady Lightning Network. Proto si za převod mezi Sparkem a Lightningem může účtovat vlastní poplatek.

Také on-chain vklady a výběry samozřejmě závisejí na bitcoinových transakčních poplatcích. Nejdražším případem může být unilateral exit, při němž je nutné publikovat větší část předem připravené transakční struktury.

# Co se má dále zlepšovat

Spark je stále relativně mladý systém a řada částí protokolu i implementací se dále vyvíjí.

Jednou z plánovaných funkcí jsou **zero-conf deposity**, které by umožnily začít používat vložené prostředky ještě před několika potvrzeními v bitcoinovém blockchainu. To samozřejmě vyžaduje řešit riziko double spendu a představuje samostatný bezpečnostní problém.

Další oblastí jsou **dynamické Spark adresy**. Statická adresa je jednoduchá, ale z hlediska soukromí problematická. Dynamické adresy by měly omezit možnost jednoduše spojovat jednotlivé platby stejného uživatele.

Diskutuje se také lepší ochrana dat před veřejným indexováním v explorerech.

Dalším směrem je **user-side MPC**, tedy rozdělení uživatelského klíče mezi více komponent nebo zařízení.

A samozřejmě se očekává růst počtu Spark Operators a zvyšování výkonu sítě. V době přednášky mohla některá sparková transakce trvat několik sekund – dostatečně krátce pro řadu případů použití, ale stále s prostorem pro výrazné zlepšení.

# Spark jako platforma pro vývojáře

Jednou z velkých předností Sparku je jeho SDK.

Z pohledu vývojáře je velmi snadné postavit jednoduchou aplikaci nebo peněženku, která dokáže přijímat a odesílat Spark platby. Implementace proof-of-conceptu může být řádově jednodušší než vytvoření plnohodnotné self-custodial Lightning peněženky včetně správy kanálů, likvidity a dalších okrajových případů.

To může mít značný význam.

Technologie totiž často nezvítězí pouze díky své teoretické eleganci. Důležitá je také otázka, jak snadno nad ní mohou ostatní vývojáři stavět produkty.

Spark navíc počítá s možností **monetizace aplikací na úrovni protokolu**. Vývojář může k transakcím svého produktu přidat malý transparentně definovaný poplatek a financovat tak vývoj peněženky či služby.

# Enterprise strategie

Za Sparkem stojí Lightspark, tedy firma zaměřená výrazně na spolupráci s fintechovým a enterprise sektorem.

To je zároveň výhoda i nevýhoda.

Výhodou je rychlost vývoje. Firma může mít desítky placených vývojářů, produktové týmy, backend, frontend i obchodní oddělení a projekt systematicky posouvat.

Komunitní open-source projekty někdy fungují jinak: klíčoví vývojáři na nich pracují ve volném čase, priority se mění a odchod několika lidí může vývoj výrazně zpomalit.

Na druhé straně enterprise přístup znamená, že směřování protokolu výrazně určuje jedna firma. Projekt proto není komunitně řízený stejným způsobem jako některé jiné bitcoinové technologie.

Oba modely mají své výhody a nevýhody.

Z hlediska adopce má však Lightspark jednu silnou kartu: pokud se Spark podaří integrovat do již existujících fintechových aplikací s miliony uživatelů, většina z nich ani nebude potřebovat vědět, že Spark používá.

Uživatel jednoduše uvidí, že převod funguje rychle a levně.

# Network effect stablecoinů

Velmi důležitou roli mohou hrát stablecoiny.

Stablecoinové sítě mají výrazný network effect: uživatelé používají síť především proto, že ji používají všichni ostatní. I technicky horší nebo dražší řešení se proto může dlouho udržet jednoduše díky existující likviditě, burzám, peněženkám a uživatelské základně.

Spark se snaží motivovat také samotné vydavatele stablecoinů.

Jednou z navrhovaných možností je sdílet část transakčních poplatků s issuerem příslušného stablecoinu. Při velmi velkém objemu stablecoinových převodů může i malý podíl představovat zajímavý nový zdroj příjmů.

Pokud by se tím podařilo motivovat velké issuery k přímé podpoře Sparku, šlo by o významnou konkurenční výhodu.

# Peněženky a praktické použití

Spark již není pouze teoretický protokol. Existují peněženky a SDK, na nichž si jej lze prakticky vyzkoušet.

Podpora se postupně objevuje v různých bitcoinových aplikacích a peněženkách a vznikají také SDK zaměřená na vývojáře. Ekosystém se však rychle mění a jednotlivé implementace mají různou úroveň vyspělosti.

Pro experimentování je proto rozumné používat malé částky.

Hlavním zdrojem technických informací je dokumentace projektu na **docs.spark.money**. Některé části protokolu ovšem byly v době přednášky stále poměrně stručně zdokumentované a u několika detailů nebylo z dokumentace snadné zjistit přesné chování implementace.

# Spark, Ark a Lightning

Spark je zajímavé porovnávat s Lightning Network a Arkem.

Nejde ale o jednoduchou soutěž, v níž musí jedna technologie zvítězit a ostatní zmizet. Jednotlivé systémy volí odlišné kompromisy.

Vlastní Lightning node umožňuje velmi silně minimalizovat důvěru ve třetí strany. Cenou je složitější správa kanálů, likvidity, záloh a dostupnosti.

Ark se snaží některé z těchto problémů řešit jiným způsobem a používá svůj vlastní model periodicky obnovovaných virtuálních UTXO.

Spark jde dále směrem k pohodlí. Nemá kanály, umožňuje offline příjem, poskytuje jednoduché SDK a integruje Lightning jako službu. Cenou je výraznější důvěra v Spark Operators, zejména v okamžiku převodu vlastnictví a bezpečného odstranění starého klíčového materiálu.

Neexistuje tedy jediná osa „lepší–horší“. Spíše existuje prostor mezi dvěma požadavky: **minimalizovat důvěru** a **maximalizovat uživatelskou jednoduchost**.

Lightning se nachází blíže prvnímu pólu, Spark blíže druhému a Ark hledá vlastní kompromis mezi nimi.

A právě existence několika paralelních přístupů může být pro Bitcoin pozitivní. Nemusíme předem rozhodnout, který protokol je správný. Mohou vznikat současně, získávat uživatele a teprve reálné používání ukáže, které kompromisy lidé skutečně preferují.

Spark je v tomto směru jeden z nejzajímavějších současných experimentů: pokouší se přenést vlastnosti self-custody Bitcoinu do prostředí, jehož uživatelská zkušenost se mnohem více blíží běžným platebním aplikacím.