BOLT 12 je návrh na nástupce protokolu BOLT 11, což je navrhovaný upgrade Lightningu, nejpopulárnějšího protokolu 2. vrstvy Bitcoinu.
Jedná se o názorový editorial Shinobiho, samouka v oblasti Bitcoinu a hostitele technicky zaměřeného Bitcoin podcastu.
BOLT 12 je návrh Rustyho Russela ze společnosti Blockstream, který má optimalizovat způsob provádění plateb přes Lightning a nakonec se stát nástupcem BOLT 11. Přestože existuje mnoho různých funkcí zabalených dohromady tak, aby tvořily BOLT, tento článek se zaměří především na kompromisy a problémy týkající se jedné z nich. Nejprve zde v rychlosti shrnu některé klíčové vlastnosti návrhu BOLT:
BOLT: (základ technologie Lightning; blesková obdoba specifikací návrhu na vylepšení bitcoinu [BIP])
Slepé cesty: Používá se jak pro platební faktury, tak pro cibulové zprávy. Předdefinuje a zašifruje několik posledních hopů v okruhu platební nebo cibulové zprávy, takže odesílatel neví, kam něco posílá, a zároveň umožňuje, aby to dorazilo k zamýšlenému příjemci.
Schnorrovy podpisy: Umožňuje, aby všechna různá místa, kde se podpisy používají při koordinaci bleskové platby nebo při komunikaci s uzly, mohla v budoucnu využívat výhod Schnorrova multisignu.
Důkazy plátce: Uzly nyní vytvářejí speciální klíč, když žádají o faktury, což jim umožňuje prostřednictvím podpisu prokázat, že platbu provedly. Tím je také zaručeno, že v případě vrácení peněz si je může nárokovat pouze skutečný plátce.
Merkleovy stromy faktur: faktury jsou nyní kódovány jako merkleovy stromy vázané na jednotlivá pole. Pokud tedy někdy budete potřebovat prokázat, že jste provedli platbu nebo obdrželi fakturu, můžete si selektivně vybrat, které části odhalíte, místo abyste museli někomu ukazovat celou fakturu.“
Všechny tyto věci dohromady vytvářejí „bleskovou nabídku“ To vám umožní zveřejnit jediný statický QR kód s informacemi pro ping uzlu přes cibulové zprávy a obdržet fakturu Lightning za konkrétní platbu přes samotnou síť Lightning. V současné době jsou faktury BOLT 11 dobré pouze pro jednu platbu, pro kterou jsou vygenerovány, a ačkoli keysend platby umožňují provádět platby bez faktury, neumožňují získat podrobnosti o platbě ve faktuře podepsané přijímajícím uzlem a uchovat je pro budoucí záznamy. BOLT 12 umožňuje všechny výhody obojího: umožňuje pomocí jediného statického údaje usnadnit platby přijímacímu uzlu a zároveň přijímat faktury s podrobnostmi o každé jednotlivé provedené platbě. Jako rychlou poznámku na okraj to také umožňuje rychlou a snadnou koordinaci streamovaných plateb, plateb předplatného atd. které nenechávají příjemce možnost účtovat peníze, pokud odesílatel transakci neschválí, při zachování zjednodušeného uživatelského prostředí.
Díky použití zaslepených cest také masivně zlepšuje jeden z největších nedostatků Lightning Network v oblasti ochrany soukromí: příjemci plateb doxxují odesílateli v procesu přijímání platby mnoho soukromých údajů, jako jsou UTXO na řetězci spojené s jejich kanálem a také jejich místo v grafu Lightning Network (tj. ke kterému uzlu jsou připojeni a přes který přijímají platbu). Slepé cesty se používají jak při přijímání plateb, tak při přijímání zpráv ping cibule, které mají odeslat fakturu zpět odesílateli.
BOLT 12 je spousta pohyblivých částí, které se spojují, aby usnadnily tento nový způsob koordinace plateb v síti Lightning Network. Jednou z největších kritik, které byly proti návrhu vzneseny, bylo zahrnutí zpráv typu onion pro obecné účely a obavy, že se tím otevřou nové vektory útoků typu DoS (denial of service). Myslím, že tato logika je zcela nesprávná, a uvedu proč.
Jedním z největších problémů DoS (a problémů se soukromím) u protokolu Lightning je sondování. Každý kanál může mít v daném okamžiku otevřeno 483 HTLC (hash time-lock contracts), které představují čekající platby, a to kvůli omezení velikosti transakce v protokolu Bitcoin. To má zajistit, aby se transakce při uzavření kanálu mohla skutečně vypořádat v řetězci a nebyla odmítnuta mempoolem pro příliš velkou velikost. Sondování je akt spamování plateb prostřednictvím kanálů, kanálů, které jsou záměrně navrženy tak, aby selhaly, s cílem shromáždit informace o tom, jak jsou prostředky v kanálu Lightning vyváženy. To spotřebovává šířku pásma, prostor, který by mohl být využit ke zpracování skutečných plateb, a celkově plýtvá zdroji v síti a také dochází k úniku informací, které by mohly být použity k deanonymizaci plateb.
Se sondovacími transakcemi je to tak, že je lze použít k předávání libovolných zpráv, aniž by za ně bylo třeba zaplatit jediný sat. Můžete přes síť nasměrovat platbu, která byla navržena tak, aby nikdy neuspěla a obsahovala libovolné údaje pro příjemce, a pak jednoduše nechat platbu propadnout. Tím se zneužívá platební protokol v síti Lightning Network k bezplatnému přenosu libovolných informací a neexistuje žádný způsob, jak lidem v tomto počínání zabránit už nyní. Neměli byste žádnou možnost zjistit, zda je platba, kterou směrujete, pravá, nebo jen zneužívá váš uzel k předávání dat; když platba selže, nemůžete vědět, zda selhala jen organicky, nebo byla od začátku navržena tak, aby selhala. Takto vlastně funguje Sphinxchat, s tím rozdílem, že samozřejmě posílá platby a nezneužívá síť zdarma
V konečném důsledku toto použití protokolu Lightning saturovalo vzácnou propustnost v podobě slotů HTLC, které by mohly být použity pro „skutečné“ ekonomické platby (skutečné v uvozovkách, protože kdo má samozřejmě posuzovat, co je „skutečná“ ekonomická aktivita) k předávání libovolných dat, a v současné době mohou být zneužity způsobem, kdy za to vlastně nikdo neplatí. Jedná se o velmi reálné a již přítomné riziko DoS, které v síti Lightning Network existuje.
Existuje několik navrhovaných řešení problému sondování a problému DoS, který z něj vyplývá, z nichž hlavní je myšlenka placení poplatků za platbu předtím, než se ji skutečně podaří uskutečnit. Jedná se o poměrně sporný návrh, protože by to znamenalo, že odesílatel nakonec zaplatí poplatky za platbu bez ohledu na to, zda je úspěšně dokončena. Podstata všech navrhovaných řešení tohoto problému je mimo rámec tohoto článku, ale jde o to, že existují návrhy řešení a žádné z nich není v současné době realizováno. Klíčový bod: nejsou implementována.
Podle mého názoru je tedy argument, že obecné cibulové zprávy „otevírají nový vektor DoS útoku“ pro Lightning, zcela mylný a nepravdivý. Tento vektor útoku existuje již nyní. Ve skutečnosti je ještě horší než obecné cibulové zprávy, protože plýtvá vzácným zdrojem nezbytným pro směrování plateb – sloty HTLC. To obecné cibulové zprávy nedělají.
Cibulové zprávy jsou funkcí, kterou lze vypnout, takže uzel se může jejich předávání zcela vzdát, a také něčím, co lze omezit rychlostí. Mám tím na mysli, že váš uzel může mít snadno nastaveno, že předá pouze „x“ zpráv za sekundu nebo „y“ množství dat za sekundu nebo jakýkoli jiný libovolný časový údaj, a odmítne předávat cokoli, co tyto limity překročí. Tímto způsobem může váš uzel snadno řídit množství prostředků, které nechá spotřebovat při předávání obecných zpráv.
Jinými slovy, BOLT 12 neotevírá žádný nový vektor útoku DoS; jednoduše bere stávající vektor, který ovlivňuje schopnost sítě zpracovávat platby, a přesouvá ho někam, kde neovlivňuje předávání plateb ani nespotřebovává žádné sloty HTLC. Má také způsob, jak zmírnit spotřebu prostředků bez dalšího omezení toku plateb. Nejhorší, co by se mohlo stát, je masivní spamová událost v síti – nasycení kapacity cibulových zpráv, které by zhoršilo schopnost využívat nabídky BOLT 12 nebo získávání faktur přes síť.
To by nemělo vliv na předávání plateb; nezabránilo by to možnosti přijímat a platit faktury BOLT 11; znamenalo by to pouze, že pokusy o získání faktur pomocí BOLT 12 by selhaly, dokud by síť byla zahlcena zprávami cibule. Nezapomeňte také, že jednotlivé uzly, které se nechtějí potýkat s mírným nárůstem využití šířky pásma, by se mohly odhlásit a nepřeposílat cibulové zprávy. Vše, jak to funguje nyní, by fungovalo i nadále a stávající vektor DoS útoku by měl jakýsi úlevový ventil, kde by lidé, kteří chtějí předávat libovolné zprávy, mohli tak činit způsobem, který by neplýtval HTLC sloty a nebránil zpracování plateb, a každý, kdo by se chtěl z nové funkce odhlásit, by tak mohl učinit
Stručně řečeno, myslím, že argument „vektor DoS“ proti BOLT 12 je nesmysl. Pokud lidé chtějí nabídnout argumenty o složitosti všech pracovních částí, o době vývoje nutné k implementaci nebo o jiných aspektech návrhu, myslím, že to jsou všechno platné argumenty. Argument proti cibulovým zprávám a novým vektorům DoS však neobstojí.“
Tento příspěvek napsal host Shinobi. Vyjádřené názory jsou výhradně jeho vlastní a nemusí nutně odrážet názory společnosti BTC Inc. nebo Bitcoin Magazine.
