Podíl implementací Lightningu

Pokud chcete provozovat svůj vlastní lightningový uzel, máte aktuálně na výběr ze tří hlavních implementací. V tomto lehce techničtějším článku si je stručně představíme a následně se podíváme na jejich procentuální zastoupení včetně toho, jak lze tato data získat.

Photo by NOAA on Unsplash

Přehled implementací

Lightning Network je platební síť, která komukoliv dovoluje si vytvořit vlastní implementaci uzlu. Abyste byli kompatibilní se zbytkem sítě, stačí dodržet BOLT specifikaci. Jedná se ale o velmi složitý software a tak naprostá majorita uživatelů sáhne po nějakém hotovém řešení.

V dnešní době máme na výběr ze tří hlavních implementací:

• Lightning Network Daemon (zkráceně LND) od Lightning Labs
• Core Lightning (dříve c-lightning) od Blockstream
• Eclair od společnosti ACINQ

LND je rozhodně nejrozšířenější implementací Lightningu, která vyniká svojí jednoduchostí a přívětivým API. LND je také součástí naprosté většiny hotových platforem jako je Umbrel, myNode či Raspiblitz, kde je to často jediná (anebo alespoň výchozí) implementace. Díky tomu pro ní existuje velké množství nástrojů a je vhodná pro začátečníky. Své si zde najdou ale i pokročilí uživatelé nebo provozovatelé větších uzlů. V poslední době však tato implementace obsahovala hned dvě zranitelnosti, které její reputaci lehce poškodily.

Core Lightning je alternativní implementace a pomyslná dvojka, která je známá pro svou stabilitu a modulární architekturu. To znamená, že mimo základních funkcí si můžete doinstalovat spoustu nadstaveb ve formě samostatných pluginů. Díky tomu je vhodná spíše pro lehce pokročilejší uživatele, kteří si ji mohou upravit dle libosti.

Eclair míří spíše na firemní klientelu, tedy na obří uzly o velmi vysokém počtu kanálů a transakcí. Tato implementace umožňuje uzel rozložit přes více serverů, které mezi sebe rozkládají jednotlivé úlohy s využitím loadbalancingu. Oproti předchozím implementacím je zde naprosté minimum jakýchkoliv rozšiřujících nástrojů.

Parametr cltv_delta a gossip protokol

V rámci samotného lightningového protokolu není nikde přenášena informace, o kterou konkrétní implementaci se jedná. Tudíž zjistit procentuální rozložení implementací zcela přesně je nereálné.

Můžeme to ale relativně dobře odhadnout. Jak? Každá implementace má lehce jiné výchozí hodnoty a toho my využijeme. Jednou z těchto hodnot je i cltv_delta. Jedná se o počet bloků, které si uzel vyhrazuje na zpracování HTLC při přeposílání platby. Jinak řečeno — je to časový rozdíl mezi odchozím a příchozím HTLC. Detailněji je to rozebráno v mojí knize.

Čím nižší hodnotu cltv_delta nastavíme, tím více riskujeme, jelikož po přeposlání platby směrem k příjemci (a získání payment_preimage) máme kratší čas na to kontaktovat uzel směrem k odesílateli a vzít si svoje prostředky. To může v případě jeho nedostupnosti skončit i nuceným uzavřením kanálu ve formě on-chain transakce, kde má tento parametr poté zásadní roli.

Naopak velmi vysoká hodnota znamená, že prostředky odesílatele mohou být v případě problémů uzamknuty po delší dobu a tak je tato trasa obvykle méně preferována.

Z textu výše plyne, že neexistuje jedna správná hodnota (i když oficiální specifikace ji částečně definuje) a tak si ji každá implementace zvolila po svém:

• LND má ve výchozím nastavení 40 bloků
• Core Lightning 34 bloků
• Eclair 144 bloků

Hodnota cltv_delta se šíří sítí v rámci gossip protokolu ve zprávě channel_update spolu s informacemi jako jsou poplatky, minimální a maximální velikosti HTLC apod.

Praktická část a zjištění podílu implementací

Budeme potřebovat graf sítě — tedy seznam všech uzlů a kanálů. Tento graf je veřejná informace a udržuje si jej každý uzel. Bohužel neexistuje jeden správný graf. Vzhledem ke způsobu jeho propagace totiž může mít každý uzel svůj graf mírně odlišný od ostatních. Pro tyto výpočty jsem proto použil grafy z vícero uzlů a výsledky zprůměroval. Jednotlivé rozdíly byly u všech parametrů pod 1 %.

Dále využijeme faktu, že většina provozovatelů uzlů parametru cltv_delta nerozumí a tak ho nechává ve výchozím stavu. Pokud jsou tedy hodnoty cltv_delta pro všechny kanály daného uzlu stejné a zároveň tato hodnota odpovídá jedné z výchozích, lze předpokládat, že se jedná o danou implementaci.

Pokud naopak je alespoň jedna hodnota cltv_delta od ostatních odlišná nebo nepatří k těm výchozím, tak provozovatel uzlu tyto parametry očividně upravuje a nelze se na ně tedy spoléhat. Takovéto uzly ze své statistiky vyřadíme. Naštěstí se jedná pouze o necelých 7 %.

Pro maximální zpřesnění výsledků jsem vyřadil ty kanály, které neodeslaly channel_update během posledních 14 dní, tudíž by dle specifikace měly být považovány za neaktuální. Nyní již zbývá pouze vytvořit skript, který nám příslušná data zpracuje.

Jaký je tedy výsledek? Přesně podle očekávání dominuje implementace LND. Jinak řečeno, 91 % uzlů má hodnotu cltv_delta nastaveno na 40 bloků pro všechny své kanály a tak se s největší pravděpodobností jedná o tuto implementaci.

Mimochodem tyto výsledky jsou téměř totožné se studií ze září roku 2020. Zde bylo využito navíc ještě dalších parametrů, konkrétně minimální velikosti HTLC a poplatků. Výsledek byl poté spočítán na základě různých vah pro jednotlivé parametry, kde cltv_delta mělo nejvyšší váhu (75 %). Vzhledem k tomu, že v poslední době vzniklo mnoho nástrojů, které tyto parametry automaticky upravují, jsem je do svých výpočtů nezařadil.

Dále lze z grafu vyčíst i další zajímavé informace, například průměrný počet kanálů pro konkrétní implementaci anebo průměrnou celkovou kapacitu daného uzlu.

Jak je vidět výše, výsledky podporují popis jednotlivých implementací z úvodu článku. LND tvoří naprostou majoritu sítě díky faktu, že je součástí většiny hotových platforem, avšak se jedná primárně o menší uzly. Naopak Eclair je na druhé straně tohoto žebříčku, jelikož pohání například uzel ACINQ, který má aktuálně téměř 3500 veřejných kanálů a další tisíce privátních. A někde uprostřed stojí Blockstream se svojí implementací Core Lightning.

Závěr

Závěrem je nutné podotknout, že výše uvedená čísla jsou pouze odhad, jelikož:

• Kdokoliv si může parametry libovolně změnit a čistě teoreticky se tak vydávat za jinou implementaci, i když takovýchto případů zajisté moc nebude.
• Tato data jsou vytvořena pouze na základě veřejných kanálů a uzlů, takže neobsahují např. informace o mobilních uzlech/peněženkách.
• Existují i další možnosti provozování uzlů, například sestavení své vlastní implementace pomocí Lightning Development Kit (LDK).
• Zároveň jsem používal aktuální výchozí hodnoty — například LND v minulosti (do dubna 2019) používalo pro cltv_delta hodnotu 144 (stejně jako dnes Eclair), která byla následně změněna na hodnotu uvedenou výše. Extrémně staré implementace tedy mohou výsledky mírně znepřesnit, avšak ani zde nečekám, že by se jednalo o nějaký velký vzorek.

Pro další zpřesnění by bylo možné využít ostatních výchozích parametrů anebo výsledky korelovat s “features” v rámci node_update zpráv.

Chcete být informováni ihned jakmile vydám další článek ohledně Bitcoinu, Lightning Network nebo ekonomie? Sledujte mne na Twitteru, navštivte můj web a případně si stáhněte moji nově vydanou knihu o Lightning Network.