Chyba, která vedla k zastavení uzlů LND a btcd, měla minimální dopad – ale mohlo to být mnohem horší.
Toto je názorový článek Shinobiho, samouka v oblasti Bitcoinu a hostitele podcastu o Bitcoinu zaměřeného na technologie.
Dne 9. října 2022 vytvořil a do hlavní bitcoinové sítě odvysílal transakci Burak ze společnosti Bitmatrix (swapovací nástroj postavený na síti Liquid), který utratil UTXO s multisigem Tapscript s prahem 998 z 999. V tomto případě se jednalo o transakci, která se uskutečnila v síti Bitcoin. Tato transakce měla 998 jednotlivých podpisů v poli svědků a měla velikost téměř 0,1 MB a tak trochu legračně znovu použila úplně stejný veřejný klíč pro každého z 999 účastníků multisig. Tato transakce způsobila masivní narušení sítě Lightning Network tím, že odhalila chybu v LND a btcd (alternativní klient pro síť Bitcoin).
Celým účelem provedení této transakce bylo demonstrovat zlepšenou škálovatelnost multisignátních skriptů, kterou umožnil Taproot. I bez použití protokolů MuSig založených na Schnorrově podpisu může Taproot umožnit mnohem větší sady multisignátních účastníků než předchozí verze Bitcoin Scriptu. Pokud se ponoříte do všech možných způsobů, jakými lze multisig s Bitcoin Scriptem konstruovat, může to být trochu nuancovaná diskuse s ohledem na předchozí omezení velikosti multisigů, takže pro zjednodušení budu jednoduše diskutovat o předchozích omezeních platících pro konstrukce multisigů Pay-to-script-hash (P2SH) a Pay-to-witness-script-hash (P2WSH). Pokud jde o standardní způsob provedení multisig P2SH, je maximální limit velikosti účastníků pouze 15 a v případě standardního multisig P2WSH je maximální velikost 20. Tyto limity jsou dány tím, jak velký smí být skript používající tyto různé operace skriptu, a omezením, kolik operací zpracování smí být provedeno v rámci jednoho skriptu. Porušení některého z těchto limitů způsobí neplatnost transakce.
Při implementaci Taproot byly tyto limity velikosti skriptů zcela odstraněny, což znamená, že jediným omezením velikosti skriptů Taproot je samotný limit velikosti bloku. Zde nastává problém týkající se LND a btcd. Pravidla konsensu implementovaná v btcd správně odstranila tyto limity, pokud jde o velikost skriptů, ale problém je v tom, že kódová základna pro peer-to-peer komunikaci také implementovala kontroly velikosti skriptů, aby přidala dvojitou vrstvu obrany pro provozovatele uzlů. Bloky a transakce by prošly jakýmsi „předkonsensuálním“ ověřováním konsensu ještě předtím, než by se dostaly do jádra konsensuálního kódu, který provádí řádné ověřování, přičemž logika spočívá v tom, že dvojitá kontrola věcí přidává další vrstvy obrany proti neplatným blokům nebo transakcím. Tento kód nebyl řádně aktualizován, aby odstranil limity velikosti skriptů, a nadále prosazoval předchozí limity skriptů pro SegWit proti transakcím Taproot. Takže zatímco samotný kód konsensu by tuto velmi velkou Taproot transakci správně validoval, blok, který ji obsahoval, nebyl nikdy předán z peer-to-peer validace do skutečné logiky validace konsensu, což znamená, že všechny uzly btcd se u tohoto bloku zastavily, včetně Burakovy transakce.
Proč to mělo vliv na LND, vzhledem k tomu, že mnoho lidí provozuje Bitcoin Core pod svou instancí LND? Je to proto, že LND používá k přijímání a zpracování bloků stejný kód jako btcd. Takže i kdyby váš uzel LND běžel nad jádrem bitcoinu, které by příslušný blok správně validovalo a nezastavilo se, vaše instance LND by tento blok odmítla přijmout a zastavila by se, přestože váš hlavní uzel řetězce by pokračoval v řádném postupu.
Tato chyba byla velmi rychle opravena a pokud je mi známo, nebyla aktivně zneužita způsobem, který by vedl k nějaké škodě, ale ponechávala každý LND uzel v Lightning Network otevřený potenciální krádeži prostředků v kanálech, pokud nepoužíval externí hlídací věž. Protože uzel byl v tomto bloku zastaven, neměl přehled o blockchainu v reálném čase a v případě, že by protistrana kanálu odeslala do blockchainu starý stav kanálu, vůbec by o tom nevěděl a nemohl by reagovat příslušnou sankční transakcí, která by zajistila prostředky uživatele. Jednalo se o velmi závažnou chybu, která ohrožovala obrovské procento bitcoinů v síti Lightning Network krádeží, pokud uživatelé sami ručně neopravovali a neaktualizovali své uzly nebo osobně nesledovali své kanály, aby mohli v případě uzavření se zastaralým stavem ručně reagovat. Musím říci, že naprostá většina netechnických provozovatelů uzlů by toho pravděpodobně nebyla schopna.
Tento problém naštěstí nebyl široce zneužit, ale kdyby byl v kódové základně objeven ještě před tím, než byla Burakova transakce posunuta do blockchainu, mohli by toho zlí aktéři záměrně takticky využít. Jednotlivec nebo skupina lidí mohla velmi snadno otevřít velké množství kanálů v síti a vyměnit všechny peníze v těchto kanálech zpět na sebe v řetězci prostřednictvím podmořského swapu, přičemž všechny prostředky v kanálech by zůstaly na druhé straně, a pak by předložila velkou transakci Taproot, jako to udělal Burak, a okamžitě uzavřela své kanály pomocí zastaralého stavu. Oběti by o tom ani nevěděly, a i kdyby věděly, vzhledem k relativně nízké technické kompetenci mnoha provozovatelů uzlů je velmi pravděpodobné, že by většina lidí nebyla schopna včas zareagovat a ručně problém opravit pomocí sankční transakce.
Tato chyba upozorňuje na dva důležité problémy, které je třeba zvážit. Za prvé, více nezávislých implementací uzlů Bitcoinu může být velmi nebezpečných. Naštěstí téměř nikdo neprovozuje btcd jako uzel pro něco vážného, takže dopad, který to mělo na základní síť Bitcoin, byl něčím, co bylo možné zcela ignorovat, s výjimkou velmi malé hrstky jednotlivců, jejichž uzly se jednoduše zastavily. Pokud by těžaři provozovali btcd, mohlo to velmi snadno vést k rozpadu řetězce v síti Bitcoin, který by všechny provozovatele btcd odvedl na minoritní řetězec, jehož náprava by vyžadovala ruční zásah. Druhým problémem je, že v případě druhých vrstev nad hlavní sítí by se implementace kontrol konsensu měla provádět velmi opatrně. Jedná se o ošemetnou záležitost, protože zatímco jakýkoli uzel Lightning běžící nad plným uzlem Bitcoinu by teoreticky mohl jednoduše přenechat 100 % tohoto ověřování tomuto uzlu, ne všechny uzly Lightning skutečně využívají svůj vlastní důvěryhodný plný uzel. To se pravděpodobně nezmění – mnoho uživatelů bude s největší pravděpodobností i nadále provozovat uzly tímto způsobem, takže kontroly některých nebo všech pravidel konsensu Bitcoinu musí být do určité míry podporovány i v implementacích Lightning.
Do budoucna doufám, že je to výzva k tomu, jak důležité je zajistit, aby byly všechny kontroly platnosti konsensu vzájemně synchronizovány napříč softwarem v tomto prostoru, protože bez této synchronizace mezi vším vlastně neexistuje jednotná koherentní síť Bitcoin. Všichni by měli být velmi rádi, že to nevyústilo v masivní zneužití v celé síti, ale lidé by si měli uvědomit, jak vážný tento problém mohl být, kdyby se věci neodehrály tak, jak se odehrály.
Tento příspěvek napsal jako host Shinobi. Vyjádřené názory jsou výhradně jeho vlastní a nemusí nutně odrážet názory společnosti BTC Inc. nebo časopisu Bitcoin Magazine.
