Skip to content
Menej ako minútu min.

Vízie budúcej technológie sú často predvídavé v hrubých obrysoch, ale zlyhávajú v detailoch. Tablety v „2001: Vesmírnej odysei“ naozaj vyzerajú ako iPady, ale nikdy nevidíte astronautov platiť za predplatné alebo tráviť hodiny hrou Candy Crush.

Channel factories (kanálové továrne) sú víziou, ktorá sa objavila už na začiatku histórie Lightning Network, aby riešila niektoré výzvy, ktorým Lightning čelil od začiatku. Napriek tomu, že sa Lightning vyvinul a stal sa najúspešnejším riešením pre škálovanie Bitcoinu na druhej vrstve s okamžitými a lacnými platbami, jeho rozsiahle používanie je obmedzené závislosťou od platobných kanálov. Hoci Lightning presúva väčšinu transakcií mimo reťazec (off-chain), každý platobný kanál stále vyžaduje on-chain transakciu na otvorenie a (zvyčajne) ďalšiu na zatvorenie. S rastúcou adopciou rastie aj tlak na blockchain. Potreba škálovateľnejšieho prístupu k správe kanálov je jasná. Channel factories mali túto potrebu uspokojiť, ale kde sú?

V roku 2025 sa objavujú subnetworky, ktoré oživujú impulz channel factories s novými detailmi, ktoré výrazne zvyšujú ich potenciál. Sú natívne interoperabilné s Lightning a dosahujú väčšiu škálu tým, že umožňujú skupine účastníkov otvoriť zdieľaný multisig UTXO a vytvoriť viacero bilaterálnych kanálov, čo znižuje počet on-chain transakcií a zlepšuje kapitálovú efektívnosť. Ark a Spark, ktoré dosahujú väčšiu škálu znížením zložitosti, vykonávajú rovnakú funkciu ako tradičné channel factories s novými dizajnmi a dodatočnými schopnosťami založenými na zdieľaných UTXO.

Channel Factories 101
Channel factories existujú od začiatku Lightning. Factory je multiparty kontrakt, kde viacerí používatelia (nielen dvaja, ako v Dryja-Poon kanáli) kooperatívne uzamknú prostriedky v jednom multisig UTXO. Môžu otvárať, zatvárať a aktualizovať kanály off-chain bez aktualizácie blockchainu pre každú operáciu. Iba keď účastníci odídu alebo sa factory rozpustí, je potrebná on-chain transakcia.

Channel factories ponúkajú množstvo dôležitých výhod. Tým, že umožňujú vytvoriť viacero off-chain kanálov z jednej on-chain transakcie, dramaticky znižujú záťaž na základnú sieť. Účastníci môžu efektívne presúvať prostriedky medzi sebou bez toho, aby sa museli dotknúť reťazca: Nové kanály môžu byť vytvorené na požiadanie vo vnútri factory bez nákladov presahujúcich to, čo už bolo zaplatené pri vytvorení factory. Schopnosť upraviť pomer kanálov k on-chain transakciám robí z channel factories jeden z najkapitálovo efektívnych prístupov na škálovanie dostupných pre Lightning dnes.

Napriek tomu nie je náhoda, že channel factories do značnej miery zostali na papieri napriek ich prísľubu. Channel factory vo všeobecnosti vyžaduje, aby boli všetci účastníci online a kooperatívni, aby aktualizovali jej stav, pokiaľ neexistujú špeciálne opatrenia alebo protokoly na riešenie asynchrónnosti. Napríklad, poskytovatelia Lightning služieb (LSP) nemôžu používať channel factories na správu downstream kanálov so svojimi používateľmi, pretože všetci rovnocenní partneri musia byť známi v čase vytvorenia factory. Bez spôsobu, ako inkrementálne pridávať partnerov do existujúcej factory, sa model stáva nepraktickým pre uzly, ktorých škálovateľnosť je zabudovaná do ich obchodného modelu, ako je to v prípade LSP. Okrem toho, riešenie odchodov z factory, najmä keď účastníci nereagujú alebo sú zlomyseľní, zahŕňa zložité mechanizmy, ktoré môžu vyžadovať, aby účastníci vopred podpísali rozsiahly strom potenciálnych výstupných transakcií pokrývajúcich každú možnú kombináciu kooperatívneho a nekooperatívneho správania. Predstavte si factory s piatimi osobami, kde jeden partner prejde do offline režimu alebo je nepoctivý – každý zo zostávajúcich partnerov by potreboval vopred dohodnuté, vopred podpísané výstupné cesty pre každú eventualitu. Bez automatizácie alebo covenant podpory sa správa stáva kombinatorickou a prevádzkovou nočnou morou. Tieto technické a UX obmedzenia sťažujú poskytovanie bezproblémovej používateľskej skúsenosti alebo škálovanie takýchto systémov v produkcii.

Od roku 2019 sme videli niekoľko návrhov na optimalizáciu channel factories, s pretrvávajúcim záujmom, ale malým produkčným nasadením – až doteraz.

Stručná história návrhov Channel Factory
Jeden skorý a veľmi komplexný návrh pre channel factories pochádza od Conrada Burcherta, Christiana Deckera a Rogera Wattenhofera v ich štúdii z roku 2017, „Scalable Funding of Bitcoin Micropayment Channel Networks.“ Ich dizajn umožňuje skupine účastníkov uzamknúť prostriedky v jednom multiparty UTXO a otvoriť viacero kanálov off-chain medzi pármi účastníkov. Každý stavový prechod (otvorenie, zatvorenie alebo presun prostriedkov na kanáli) vyžaduje kompletný set predpodpísaných transakcií. Tým sa zabezpečí, že každý účastník má kryptograficky bezpečný spôsob, ako v prípade potreby opustiť factory.

Konštrukcia Burcherta-Deckera-Wattenhofera má však vážne obmedzenie škálovateľnosti: Akákoľvek aktualizácia stavu factory vyžaduje, aby boli všetci účastníci online a schválili zmenu. S rastúcim počtom účastníkov exponenciálne rastie počet požadovaných podpisov a vopred podpísaných výstupných ciest, rovnako ako koordinácia, záťaž na ukladanie dát a problémy.

Snahy o zlepšenie tohto modelu využili novšie funkcie Bitcoinu. Taproot zjednodušuje štruktúru výstupných transakcií tým, že umožňuje zapuzdriť ich podmienky do stromu skriptov (Merkle tree), pričom pri vyplatení sa odhalí iba cesta použitia. To znižuje veľkosť transakcie aj únik súkromia. OP_CHECKTEMPLATEVERIFY (OP_CTV), navrhovaný soft fork, by dramaticky zefektívnil factories tým, že by umožnil vopred potvrdené výstupné cesty bez potreby rozsiahleho predpodpisovania. S OP_CTV by factory mohla potvrdiť set výstupných transakcií v čase vytvorenia. Každý účastník by vedel, že môže jednostranne vystúpiť dobre definovaným spôsobom, čím by sa znížila interaktivita a prevádzková zložitosť.

Napriek takémuto pokroku praktické nasadenie zaostáva. Bariéry pre úplnú interaktivitu účastníkov a komplexné schémy podpisovania, najmä v neprítomnosti OP_CTV, sú jednoducho príliš vysoké.

Ark a Spark: Channel Factories novej generácie
Dva nedávne projekty, Ark a Spark, prehodnocujú channel factory s rôznymi kompromismi. Hoci ani jeden projekt sa explicitne neprezentuje ako „channel factory“, ich architektúry efektívne realizujú mnohé ciele, o ktoré sa snažili skoré návrhy channel factory. Keďže oba sú založené na zdieľanom UTXO a oba sú natívne kompatibilné s Lightning, Spark a Ark predstavujú moderné inkarnácie channel factories, ktoré využívajú dnešné nástroje a predpoklady. Konečne! Oba sa snažia zachovať výhody channel factories (znížené využitie reťazca, škálovateľné prideľovanie likvidity) a zároveň riešiť kľúčové nedostatky týkajúce sa aktivity, interaktivity a komplexnosti výstupu. Najdôležitejšie je, že oba projekty zaujímajú pragmatický prístup k škálovaniu. Fungujú v rámci súčasných pravidiel konsenzu Bitcoinu, čím sa vyhýbajú potrebe soft forkov alebo nových opkódov, aby boli užitočné dnes.

Zdieľanie UTXO
Ark zavádza model zdieľania UTXO postavený na koncepte virtuálnych UTXO (VTXO). Namiesto priraďovania jednotlivých on-chain výstupov používateľom, Ark im umožňuje uskutočňovať transakcie off-chain pomocou zdieľaného fondu likvidity spravovaného serverom Ark. Používatelia uskutočňujú transakcie tak, že žiadajú, aby bolo nové rozdelenie VTXO zahrnuté v ďalšom kole, keď server Ark vytvorí „Ark blok“ agregujúci nedávnu aktivitu používateľov a zverejní nové zdieľané UTXO na blockchain. Takže Ark umožňuje používateľom prenášať VTXO medzi sebou a periodicky vyrovnávať rozdelenie VTXO v zdieľanom UTXO prostredníctvom dávkových kotviacich transakcií na blockchaine.

Používatelia môžu tiež vykonávať mimo-kolové transakcie, ktoré okamžite presúvajú VTXO medzi používateľmi bez čakania na ďalšie kolo kotviacich transakcií. V tomto prípade server Ark spolupodpisuje mimo-kolovú platbu, ktorá môže byť ohrozená, ak sa server Ark a odosielateľ dohodnú na duplicitnom míňaní VTXO. Príjemca sa však môže rozhodnúť, či akceptuje riziko na základe reputácie servera Ark a okamžite vezme prostriedky, alebo počká do ďalšieho kola.

Spark zaujíma odlišný prístup k zdieľaným UTXO, ktorý stavia na koncepte statechains. Fulcrum protokolu zdieľaného podpisovania Sparku sú Spark Operators (SO), ktorí sa spájajú do konzorcia s názvom Spark Entity (SE). Keď sa používateľ pripojí k Sparku, uloží prostriedky do adresy so zdieľaným podpisom, ktorú kontrolujú oni sami a SE. SE a používateľ vopred podpíšu transakciu výberu, čím zabezpečia, že používateľ môže vždy jednostranne vystúpiť. K platbe dôjde vždy, keď sa objaví nová transakcia výberu, ktorá vytvorí nový aktuálny stav. Postupom času má história transakcií stromovú štruktúru, ktorá sa rozvetvuje od pôvodného zdieľaného UTXO a každá koncová transakcia vlastnená používateľom sa nazýva „list“. Prirodzene, po každej zmene musia SO vymazať minulé kľúče použité pre minulého vlastníka (t.j. prerezávanie starých listov) a na to, aby systém fungoval bezpečne, to musí urobiť iba jeden zo SO v SE. To umožňuje Sparku ponúkať off-chain platby s minimalizovanou dôverou a vlastnou úschovou pri zachovaní nezmeneného základného UTXO.

Podobne ako Ark, aj Spark zavádza niektoré nové predpoklady o dôvere. Spark vyžaduje, aby aspoň jeden SO (alebo nejaká vyššia konfigurovateľná hranica) v SE konal čestne a vymazal zastarané transakcie výberu. Výsledkom je model dôvery „v okamihu“, v ktorom sa dôvera vyžaduje iba v čase prenosu: Systém si udržuje dokonalú doprednú bezpečnosť, pokiaľ operátori po prenose vymažú svoje zdieľané kľúče. Keď sú kľúče vymazané, ani kompromitovaný alebo škodlivý operátor nemôže spätne ovplyvniť minulé transakcie alebo ukradnúť prostriedky a vymazanie ktorýmkoľvek SO sa počíta pre všetky SO v SE, čím sa zodpovednosť rozdeľuje medzi viacerých operátorov.

Interoperabilita s Lightning
Na prepojenie s Lightning sa Spark aj Ark spoliehajú na swapy uľahčené LSP. Tieto LSP sa musia zúčastniť danej entity Ark alebo Spark, aby fungovali ako mosty: Vykonávajú platby Lightning v mene používateľov výmenou za aktíva v príslušných systémoch — VTXO v Ark a listy v Sparku. Proces je zabezpečený atomickosťou: LSP dostane VTXO alebo list až vtedy, keď môže dokázať, že platba Lightning bola úspešne dokončená poskytnutím preimage. To umožňuje používateľom uskutočňovať platby Lightning bez toho, aby sami prevádzkovali uzol Lightning, a pevne ukotvuje oba systémy do širšieho ekosystému Lightning.

Ak to chodí ako kačka…
Channel factories zvyšujú škálu využívaním zdieľaných UTXO na zosilnenie škálovateľnosti Lightning. Podľa toho sú Ark a Spark jednoznačne channel factories, aj keď majú najnovšie módne trendy v technológii VTXO a statechain. Vzhľadom na to, čo už modely zdieľaných UTXO, ako sú tieto, dosahujú, môžeme očakávať veľké veci od laboratórií channel-factory v blízkej budúcnosti – najmä ak budú do L1 pridané nové opkódy.

Ark aj Spark sú samy o sebe významné úspechy, ale tiež potvrdzujú Lightning. Bez možnosti interoperability s inými subnetmi — Liquid, Fedimint, Cashu atď. — by tieto prepracované channel factories boli oveľa menej cenné. A je to Lightning, ktorý im umožňuje interoperabilitu prakticky kdekoľvek, kam môže Bitcoin ísť. Vznik Sparku a Arku nie je znakom obmedzení Lightning, ale jeho nevyhnutnosti v dnešnej bitcoinovej ekonomike.

Roy Sheinfeld

Bitcoin Magazine

Vízie budúcej technológie sú často predvídavé v hrubých obrysoch, ale zlyhávajú v detailoch. Tablety v „2001: Vesmírnej odysei“ naozaj vyzerajú ako iPady, ale nikdy nevidíte astronautov platiť za predplatné alebo tráviť hodiny hrou Candy Crush.

Channel factories (kanálové továrne) sú víziou, ktorá sa objavila už na začiatku histórie Lightning Network, aby riešila niektoré výzvy, ktorým Lightning čelil od začiatku. Napriek tomu, že sa Lightning vyvinul a stal sa najúspešnejším riešením pre škálovanie Bitcoinu na druhej vrstve s okamžitými a lacnými platbami, jeho rozsiahle používanie je obmedzené závislosťou od platobných kanálov. Hoci Lightning presúva väčšinu transakcií mimo reťazec (off-chain), každý platobný kanál stále vyžaduje on-chain transakciu na otvorenie a (zvyčajne) ďalšiu na zatvorenie. S rastúcou adopciou rastie aj tlak na blockchain. Potreba škálovateľnejšieho prístupu k správe kanálov je jasná. Channel factories mali túto potrebu uspokojiť, ale kde sú?

V roku 2025 sa objavujú subnetworky, ktoré oživujú impulz channel factories s novými detailmi, ktoré výrazne zvyšujú ich potenciál. Sú natívne interoperabilné s Lightning a dosahujú väčšiu škálu tým, že umožňujú skupine účastníkov otvoriť zdieľaný multisig UTXO a vytvoriť viacero bilaterálnych kanálov, čo znižuje počet on-chain transakcií a zlepšuje kapitálovú efektívnosť. Ark a Spark, ktoré dosahujú väčšiu škálu znížením zložitosti, vykonávajú rovnakú funkciu ako tradičné channel factories s novými dizajnmi a dodatočnými schopnosťami založenými na zdieľaných UTXO.

Channel Factories 101
Channel factories existujú od začiatku Lightning. Factory je multiparty kontrakt, kde viacerí používatelia (nielen dvaja, ako v Dryja-Poon kanáli) kooperatívne uzamknú prostriedky v jednom multisig UTXO. Môžu otvárať, zatvárať a aktualizovať kanály off-chain bez aktualizácie blockchainu pre každú operáciu. Iba keď účastníci odídu alebo sa factory rozpustí, je potrebná on-chain transakcia.

Channel factories ponúkajú množstvo dôležitých výhod. Tým, že umožňujú vytvoriť viacero off-chain kanálov z jednej on-chain transakcie, dramaticky znižujú záťaž na základnú sieť. Účastníci môžu efektívne presúvať prostriedky medzi sebou bez toho, aby sa museli dotknúť reťazca: Nové kanály môžu byť vytvorené na požiadanie vo vnútri factory bez nákladov presahujúcich to, čo už bolo zaplatené pri vytvorení factory. Schopnosť upraviť pomer kanálov k on-chain transakciám robí z channel factories jeden z najkapitálovo efektívnych prístupov na škálovanie dostupných pre Lightning dnes.

Napriek tomu nie je náhoda, že channel factories do značnej miery zostali na papieri napriek ich prísľubu. Channel factory vo všeobecnosti vyžaduje, aby boli všetci účastníci online a kooperatívni, aby aktualizovali jej stav, pokiaľ neexistujú špeciálne opatrenia alebo protokoly na riešenie asynchrónnosti. Napríklad, poskytovatelia Lightning služieb (LSP) nemôžu používať channel factories na správu downstream kanálov so svojimi používateľmi, pretože všetci rovnocenní partneri musia byť známi v čase vytvorenia factory. Bez spôsobu, ako inkrementálne pridávať partnerov do existujúcej factory, sa model stáva nepraktickým pre uzly, ktorých škálovateľnosť je zabudovaná do ich obchodného modelu, ako je to v prípade LSP. Okrem toho, riešenie odchodov z factory, najmä keď účastníci nereagujú alebo sú zlomyseľní, zahŕňa zložité mechanizmy, ktoré môžu vyžadovať, aby účastníci vopred podpísali rozsiahly strom potenciálnych výstupných transakcií pokrývajúcich každú možnú kombináciu kooperatívneho a nekooperatívneho správania. Predstavte si factory s piatimi osobami, kde jeden partner prejde do offline režimu alebo je nepoctivý – každý zo zostávajúcich partnerov by potreboval vopred dohodnuté, vopred podpísané výstupné cesty pre každú eventualitu. Bez automatizácie alebo covenant podpory sa správa stáva kombinatorickou a prevádzkovou nočnou morou. Tieto technické a UX obmedzenia sťažujú poskytovanie bezproblémovej používateľskej skúsenosti alebo škálovanie takýchto systémov v produkcii.

Od roku 2019 sme videli niekoľko návrhov na optimalizáciu channel factories, s pretrvávajúcim záujmom, ale malým produkčným nasadením – až doteraz.

Stručná história návrhov Channel Factory
Jeden skorý a veľmi komplexný návrh pre channel factories pochádza od Conrada Burcherta, Christiana Deckera a Rogera Wattenhofera v ich štúdii z roku 2017, „Scalable Funding of Bitcoin Micropayment Channel Networks.“ Ich dizajn umožňuje skupine účastníkov uzamknúť prostriedky v jednom multiparty UTXO a otvoriť viacero kanálov off-chain medzi pármi účastníkov. Každý stavový prechod (otvorenie, zatvorenie alebo presun prostriedkov na kanáli) vyžaduje kompletný set predpodpísaných transakcií. Tým sa zabezpečí, že každý účastník má kryptograficky bezpečný spôsob, ako v prípade potreby opustiť factory.

Konštrukcia Burcherta-Deckera-Wattenhofera má však vážne obmedzenie škálovateľnosti: Akákoľvek aktualizácia stavu factory vyžaduje, aby boli všetci účastníci online a schválili zmenu. S rastúcim počtom účastníkov exponenciálne rastie počet požadovaných podpisov a vopred podpísaných výstupných ciest, rovnako ako koordinácia, záťaž na ukladanie dát a problémy.

Snahy o zlepšenie tohto modelu využili novšie funkcie Bitcoinu. Taproot zjednodušuje štruktúru výstupných transakcií tým, že umožňuje zapuzdriť ich podmienky do stromu skriptov (Merkle tree), pričom pri vyplatení sa odhalí iba cesta použitia. To znižuje veľkosť transakcie aj únik súkromia. OP_CHECKTEMPLATEVERIFY (OP_CTV), navrhovaný soft fork, by dramaticky zefektívnil factories tým, že by umožnil vopred potvrdené výstupné cesty bez potreby rozsiahleho predpodpisovania. S OP_CTV by factory mohla potvrdiť set výstupných transakcií v čase vytvorenia. Každý účastník by vedel, že môže jednostranne vystúpiť dobre definovaným spôsobom, čím by sa znížila interaktivita a prevádzková zložitosť.

Napriek takémuto pokroku praktické nasadenie zaostáva. Bariéry pre úplnú interaktivitu účastníkov a komplexné schémy podpisovania, najmä v neprítomnosti OP_CTV, sú jednoducho príliš vysoké.

Ark a Spark: Channel Factories novej generácie
Dva nedávne projekty, Ark a Spark, prehodnocujú channel factory s rôznymi kompromismi. Hoci ani jeden projekt sa explicitne neprezentuje ako „channel factory“, ich architektúry efektívne realizujú mnohé ciele, o ktoré sa snažili skoré návrhy channel factory. Keďže oba sú založené na zdieľanom UTXO a oba sú natívne kompatibilné s Lightning, Spark a Ark predstavujú moderné inkarnácie channel factories, ktoré využívajú dnešné nástroje a predpoklady. Konečne! Oba sa snažia zachovať výhody channel factories (znížené využitie reťazca, škálovateľné prideľovanie likvidity) a zároveň riešiť kľúčové nedostatky týkajúce sa aktivity, interaktivity a komplexnosti výstupu. Najdôležitejšie je, že oba projekty zaujímajú pragmatický prístup k škálovaniu. Fungujú v rámci súčasných pravidiel konsenzu Bitcoinu, čím sa vyhýbajú potrebe soft forkov alebo nových opkódov, aby boli užitočné dnes.

Zdieľanie UTXO
Ark zavádza model zdieľania UTXO postavený na koncepte virtuálnych UTXO (VTXO). Namiesto priraďovania jednotlivých on-chain výstupov používateľom, Ark im umožňuje uskutočňovať transakcie off-chain pomocou zdieľaného fondu likvidity spravovaného serverom Ark. Používatelia uskutočňujú transakcie tak, že žiadajú, aby bolo nové rozdelenie VTXO zahrnuté v ďalšom kole, keď server Ark vytvorí „Ark blok“ agregujúci nedávnu aktivitu používateľov a zverejní nové zdieľané UTXO na blockchain. Takže Ark umožňuje používateľom prenášať VTXO medzi sebou a periodicky vyrovnávať rozdelenie VTXO v zdieľanom UTXO prostredníctvom dávkových kotviacich transakcií na blockchaine.

Používatelia môžu tiež vykonávať mimo-kolové transakcie, ktoré okamžite presúvajú VTXO medzi používateľmi bez čakania na ďalšie kolo kotviacich transakcií. V tomto prípade server Ark spolupodpisuje mimo-kolovú platbu, ktorá môže byť ohrozená, ak sa server Ark a odosielateľ dohodnú na duplicitnom míňaní VTXO. Príjemca sa však môže rozhodnúť, či akceptuje riziko na základe reputácie servera Ark a okamžite vezme prostriedky, alebo počká do ďalšieho kola.

Spark zaujíma odlišný prístup k zdieľaným UTXO, ktorý stavia na koncepte statechains. Fulcrum protokolu zdieľaného podpisovania Sparku sú Spark Operators (SO), ktorí sa spájajú do konzorcia s názvom Spark Entity (SE). Keď sa používateľ pripojí k Sparku, uloží prostriedky do adresy so zdieľaným podpisom, ktorú kontrolujú oni sami a SE. SE a používateľ vopred podpíšu transakciu výberu, čím zabezpečia, že používateľ môže vždy jednostranne vystúpiť. K platbe dôjde vždy, keď sa objaví nová transakcia výberu, ktorá vytvorí nový aktuálny stav. Postupom času má história transakcií stromovú štruktúru, ktorá sa rozvetvuje od pôvodného zdieľaného UTXO a každá koncová transakcia vlastnená používateľom sa nazýva „list“. Prirodzene, po každej zmene musia SO vymazať minulé kľúče použité pre minulého vlastníka (t.j. prerezávanie starých listov) a na to, aby systém fungoval bezpečne, to musí urobiť iba jeden zo SO v SE. To umožňuje Sparku ponúkať off-chain platby s minimalizovanou dôverou a vlastnou úschovou pri zachovaní nezmeneného základného UTXO.

Podobne ako Ark, aj Spark zavádza niektoré nové predpoklady o dôvere. Spark vyžaduje, aby aspoň jeden SO (alebo nejaká vyššia konfigurovateľná hranica) v SE konal čestne a vymazal zastarané transakcie výberu. Výsledkom je model dôvery „v okamihu“, v ktorom sa dôvera vyžaduje iba v čase prenosu: Systém si udržuje dokonalú doprednú bezpečnosť, pokiaľ operátori po prenose vymažú svoje zdieľané kľúče. Keď sú kľúče vymazané, ani kompromitovaný alebo škodlivý operátor nemôže spätne ovplyvniť minulé transakcie alebo ukradnúť prostriedky a vymazanie ktorýmkoľvek SO sa počíta pre všetky SO v SE, čím sa zodpovednosť rozdeľuje medzi viacerých operátorov.

Interoperabilita s Lightning
Na prepojenie s Lightning sa Spark aj Ark spoliehajú na swapy uľahčené LSP. Tieto LSP sa musia zúčastniť danej entity Ark alebo Spark, aby fungovali ako mosty: Vykonávajú platby Lightning v mene používateľov výmenou za aktíva v príslušných systémoch — VTXO v Ark a listy v Sparku. Proces je zabezpečený atomickosťou: LSP dostane VTXO alebo list až vtedy, keď môže dokázať, že platba Lightning bola úspešne dokončená poskytnutím preimage. To umožňuje používateľom uskutočňovať platby Lightning bez toho, aby sami prevádzkovali uzol Lightning, a pevne ukotvuje oba systémy do širšieho ekosystému Lightning.

Ak to chodí ako kačka…
Channel factories zvyšujú škálu využívaním zdieľaných UTXO na zosilnenie škálovateľnosti Lightning. Podľa toho sú Ark a Spark jednoznačne channel factories, aj keď majú najnovšie módne trendy v technológii VTXO a statechain. Vzhľadom na to, čo už modely zdieľaných UTXO, ako sú tieto, dosahujú, môžeme očakávať veľké veci od laboratórií channel-factory v blízkej budúcnosti – najmä ak budú do L1 pridané nové opkódy.

Ark aj Spark sú samy o sebe významné úspechy, ale tiež potvrdzujú Lightning. Bez možnosti interoperability s inými subnetmi — Liquid, Fedimint, Cashu atď. — by tieto prepracované channel factories boli oveľa menej cenné. A je to Lightning, ktorý im umožňuje interoperabilitu prakticky kdekoľvek, kam môže Bitcoin ísť. Vznik Sparku a Arku nie je znakom obmedzení Lightning, ale jeho nevyhnutnosti v dnešnej bitcoinovej ekonomike.

Roy Sheinfeld

Translate »