Tento týden popisujeme studii o důkazech validity s nulovou znalostí v bitcoinu a souvisejících protokolech a přinášíme další příspěvek v naší krátké týdenní sérii o pravidlech mempoolu. Též nechybí naše pravidelné rubriky popisující aktualizace klientů a služeb, nová vydání a změny v populárních bitcoinových páteřních projektech.

Novinky

  • ● Komprese stavu pomocí důkazů validity s nulovou znalostí: Robin Linus zaslal do emailové skupiny Bitcoin-Dev příspěvek o studii, jejíž je autorem spolu s Lukasem Georgem. Studie pojednává o použití důkazů validity k redukci velikosti stavu, který klient musí stáhnout, aby mohl bez požadavku na důvěru ověřovat budoucí operace. Tento systém prvně aplikují na bitcoin. Oznámili existenci prototypu, který umí podat důkaz o kumulativním objemu důkazu práce v řetězci hlaviček bloků a který umožňuje klientovi ověřit, zda je konkrétní hlavička bloku součástí tohoto řetězce. To umožňuje klientovi, který obdrží několik důkazů, určit, který z nich představuje nejvíce práce.

    Též mají (prozatím neoptimální) prototyp dokazující, že všechny změny stavu transakcí blockchainu respektovaly pravidla měny (např. kolik bitcoinů může být novým blokem vytvořeno, že každá necoinbasová transakce nesmí vytvořit UTXO s větší hodnotou, než kolik utrácí, a že si těžař může nárokovat rozdíl mezi UTXO utrácenými a vytvářenými). Klient může pomocí tohoto důkazu a kopie aktuální množiny UTXO ověřit, že množina je přesná a kompletní. Nazývají tento důkaz assumevalid, stejně jako volitelnou funkci v Bitcoin Core, která přeskakuje verifikaci skriptů starších bloků, na jejichž validitě se shodne množství přispěvatelů.

    Pro minimalizaci složitosti důkazu používají verzi utreexo s hashovací funkcí optimalizovanou pro tento systém. Navrhují, že kombinace jejich důkazu a utreexo klienta umožní začít provozovat plný uzel téměř okamžitě po stažení velmi malého množství dat.

    Co se týče použitelnosti prototypu, píší, že „implementovali prototyp důkazu řetězce hlaviček a důkazu assumevalid stavu. Ten první je již použitelný, druhý ještě vyžaduje vylepšení výkonnosti dokazování objemnějších bloků.” Též pracují na validaci kompletních bloků včetně skriptů, ale podle jejich slov musí dosáhnout minimálně 40násobného zrychlení.

    Vedle komprese stavu bitcoinového blockchainu též popisují protokol, který může být použit pro tokenové protokoly s validací na straně klienta, který používají například Taproot Assets od Lightning Labs (viz zpravodaj č. 195, angl.) nebo RGB (č. 247). Když Alice pošle Bobovi určité množství tokenů, musí Bob ověřit historii každého předchozího transferu těchto konkrétních tokenů až zpět k jejich vytvoření. V ideálním případě roste historie lineárně s množstvím transferů. Ale chce-li Bob zaplatit Carol množstvím větším, než kolik obdržel od Alice, bude muset zkombinovat některé z tokenů, které obdržel od Alice, s jinými, které obdržel v jiných transakcích. Carol potom bude muset ověřit obě historie. Toto se nazývá sloučení („merge”). Objevují-li se sloučení často, dosahuje velikost historie, která se musí ověřit, velikosti historie každého transferu tokenů mezi kterýmikoliv uživateli. V bitcoinu, pro porovnání, ověřuje každý plný uzel každou transakci každého uživatele. To není v tokenových protokolech s validací na straně klienta nezbytnou nutností, ale jsou-li sloučení běžná, v podstatě se tak děje.

    Znamená to, že protokol přinášející kompresi bitcoinového stavu může být upraven ke komprimování stavu historie tokenů, včetně těch s častými sloučeními. Autoři popisují, jak by toho bylo možné dosáhnout. Jejich cílem je vytvořit důkaz, že každý předchozí transfer tokenu se řídil pravidly tokenu a že každý předchozí transfer byl řádně ukotven v bitcoinovém blockchainu. Alice by potom mohla poslat Bobovi tokeny a poskytnout mu malý důkaz validity. Bob by potom ověřením důkazu potvrdil, že transfer proběhl v určité blokové výšce a že byl adresátem transferu.

    Ačkoliv je ve studii často zmiňována nutnost dodatečného výzkumu a vývoje, přináší nám nadějný postup směrem ke CoinWitness, funkci, po které bitcoinoví vývojáři touží již více než deset let.

Čekání na potvrzení 2: incentivy

Krátká týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji.

Minulý příspěvek představil mempool jako mezipaměť nepotvrzených transakcí, která uživatelům poskytuje decentralizovaný způsob posílání transakcí těžařům. Avšak těžaři nejsou povinni tyto transakce potvrdit, blok obsahující pouze coinbasovou transakci je podle pravidel konsenzu zcela validní. Uživatelé mohou těžařům poskytnout podnět k začlenění transakcí navýšením celkové hodnoty vstupů bez navýšení celkové hodnoty výstupů. Tento rozdíl si mohou těžaři vzít jako poplatek za transakci.

I když jsou v tradičním finančním světě transakční poplatky běžné, noví bitcoinoví uživatelé jsou často překvapeni, že poplatky za umístění v blockchainu nejsou úměrné hodnotě transakce, ale její váze. Namísto likvidity je omezujícím faktorem blokový prostor. Jednotkový poplatek se obvykle uvádí v jednotkách satoshi za virtuální byte.

Pravidla konsenzu v každém bloku omezují celkový prostor využitý transakcemi. Díky tomuto omezení jsou časy propagace bloků nízké v porovnání s intervalem produkce bloků a riziko zahození bloků je tak nižší. Též napomáhá k omezení nárůstu blockchainu a množiny UTXO, tedy vlastností, které přímo přispívají k nákladům na udržování plného uzlu.

Mempooly díky své roli mezipaměti nepotvrzených transakcí též zprostředkovávají veřejnou dražbu neelastického blokového prostoru. Pracuje-li správně, funguje tato dražba na principu volného trhu, tedy priorita je stanovena čistě jen na poplatcích a ne na vztazích s těžaři.

Maximalizace poplatků při výběru transakcí do bloku (který je limitován celkovou váhou a počtem operací podepisování) je NP-těžký problém. Tento problém dále ztěžují vztahy mezi transakcemi. Těžba transakce s vysokým jednotkovým poplatkem může být podmíněna těžbou jeho rodiče s nízkým poplatkem. Nebo, vzato z jiného úhlu, výběr transakce s nízkým jednotkovým poplatkem může otevřít příležitost k těžbě potomka s vysokým jednotkovým poplatkem.

Mempool v Bitcoin Core počítá jednotkový poplatek pro každou položku a jeho předky (tzv. jednotkový poplatek předků, „ancestor feerate”), ukládá tento výsledek do mezipaměti a sestrojuje šablony bloků pomocí hladového algoritmu. Seřazuje mempool v pořadí dle hodnocení předků („ancestor score”; jedná se o minimum z jednotkového poplatku předků a vlastního jednotkového poplatku), vybírá balíčky předků v tomto pořadí a za chodu upravuje informace o poplatcích a váhách předků zbývajících transakcí. Tento algoritmus nabízí rovnováhu mezi výkonností a ziskovostí, avšak nemusí poskytnout optimální výsledky. Jeho účinnost může být zvýšena omezením velikosti transakcí a balíčků předků; Bitcoin Core stanovuje tyto limity na 400 000, resp. 404 000 váhových jednotek.

Podobně se počítá i hodnocení potomků („descendant score”), které se používá při výběru balíčků, které mají být z mempoolu vyhozeny. Bylo by nevýhodné vyhodit transakce s nízkým poplatkem, které mají potomky s vysokým poplatkem.

Validace mempoolu též používá poplatky a jednotkové poplatky při nakládání s transakcemi, které utrácejí shodné vstupy. Těmto případům se též říká dvojí utrácení nebo konfliktní transakce. Uzly neakceptují vždy jen první transakci, kterou spatří, ale aplikují soubor pravidel, aby určily, které transakce je výhodnější ponechat. Toto chování je známé jako nahrazení poplatkem („replace by fee”).

Je zřejmé, že těžaři chtějí maximalizovat poplatky, avšak proč by měly netěžící uzly též implementovat tato pravidla? Jak bylo zmíněno v minulém příspěvku, užitečnost mempoolů netěžících uzlů je přímo navázána na jejich podobnost s mempooly těžařů. I když se provozovatelé uzlů nechystají produkovat bloky z obsahu svých mempolů, držení nejvýhodnějších transakcí je i v jejich zájmu.

I když neexistují žádná pravidla konsenzu vyžadující platbu poplatků, hrají poplatky a jednotkové poplatky v bitcoinové síti důležitou roli ve „spravedlivém” způsobu řešení soutěže o blokový prostor. Těžaři využívají jednotkové poplatky k posuzování přijímání, vyhazování a řešení konfliktů a netěžící uzly se drží tohoto chování, aby maximalizovaly užitečnost svých mempoolů.

Vzácnost blokového prostoru tlačí velikost transakcí směrem dolů a ponouká vývojáře k lepší efektivitě konstrukce transakcí. Příští týden prozkoumáme praktické strategie a techniky minimalizace transakčních poplatků.

Změny ve službách a klientech

V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.

  • ● Vydán firmware verze 2.1.1 pro Passport: Nejnovější firmware pro hardwarové podpisové zařízení Passport podporuje posílání na taprootové adresy, BIP85 funkce a zlepšuje nakládání s PSBT a vícenásobnými podpisy.

  • ● Vydána MuSig peněženka Munstr: Beta software Munstr používá protokol Nostr pro komunikaci potřebnou pro podepisování MuSig transakcí s vícenásobnými podpisy.

  • ● Vydán Coffee, správce pluginů pro CLN: Coffee je správce pluginů pro CLN, který vylepšuje instalaci, konfiguraci, správu závislostí a upgradování CLN pluginů.

  • ● Vydáno Electrum 4.4.3: Nejnovější vydání Electra obsahuje vylepšení výběru mincí, nástroj pro analýzu soukromí UTXO, podporu krátkých identifikátorů kanálů („Short Channel Identifiers,” SCID) a další opravy a vylepšení.

  • ● Trezor Suite přidává podporu coinjoinů: Trezor Suite oznámil podporu coinjoinů za pomocí koordinátora zkSNACKs.

  • ● Lightning Loop používá MuSig2 ve výchozím nastavení: Lightning Loop nyní používá MuSig2 jako výchozí protokol pro swap, což přinese nižší poplatky a větší soukromí.

  • ● Mutinynet oznámil nový signet pro testování: Mutinynet je signet s 30sekundovými bloky, který poskytuje testovací infrastrukturu včetně prohlížeče bloků, zdroje testovacích bitcoinů a testovacích LN uzlů a LSP.

  • ● Nunchuk přidává výběr mincí a podporu BIP329: Nejnovější androidová a iOS verze Nunchuku přidává výběr mincí a export štítků peněženky podle BIP329.

  • ● MyCitadel Wallet přidává vylepšenou podporu miniscriptu: Vydání v1.3.0 přidává pokročilejší možnosti miniscriptu včetně časových zámků.

  • ● Oznámen Edge Firmware pro Coldcard: Coinkite oznámil experimentální firmware pro podpisové zařízení Coldcard, který umožňuje vývojářům peněženek a pokročilým uživatelům experimentovat s novými funkcemi. Prvotní vydání 6.0.0X přináší taprootové keypath platby, tapscriptové multisig platby a podporu BIP129.

Vydání nových verzí

Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, zvažte upgrade či pomoc s testováním.

Významné změny v kódu a dokumentaci

Významné změny z tohoto týdne v Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs) a Lightning BOLTs.

  • ● Bitcoin Core #27021 přidává rozhraní pro kalkulaci tzv. schodku poplatku („fee deficit”), který udává, kolik by stálo zarovnat výstupy nepotvrzených rodičovských transakcí na daný jednotkový poplatek. Když algoritmy výběru mincí uvažují nad konkrétním výstupem s určitým jednotkovým poplatkem, spočítají schodek poplatku jeho rodičů a výsledek odečtou od jeho efektivní hodnoty. To zabraňuje, aby peněženka volila výstupy s příliš velkým schodkem, jsou-li k dispozici vhodnější výstupy. V následném PR bude toto rozhraní použito také k umožnění plateb s navýšeným poplatkem („bump fees”), mají-li tak jako tak být zvoleny výstupy se schodkem. Zaručí to, že nová transakce bude platit efektivní jednotkový poplatek vyžádaný uživatelem.

    Algoritmus je schopný vyhodnotit navyšování poplatků ve všech případech díky posuzování kompletního souboru nepotvrzených transakcí spojených s tímto nepotvrzeným UTXO a neuvažováním transakcí, které by byly s cíleným jednotkovým poplatkem začleněny do bloku. Druhá metoda poskytuje agregované navýšení poplatku napříč několika nepotvrzenými výstupy pro korigování potenciálního překrývání předků.

  • ● LND #7668 přidává možnost připojit ke kanálu během otevírání soukromou poznámku obsahující až 500 znaků. Tato poznámka může operátorovi připomenout důvod otevření kanálu.

  • ● LDK #2204 přidává možnost nastavit uživatelský feature bit. Ten bude použit při oznamování vlastním spojením nebo během zpracování oznámení od spojení.

  • ● LDK #1841 implementuje verzi bezpečnostních doporučení přidaných do LN specifikace (viz zpravodaj č. 128, angl.), podle které by se uzel používající anchor výstupy neměl pokoušet vytvářet transakce se vstupy několika stran, je-li vyžadováno rychlé potvrzení této transakce. To zabrání ostatním stranám konfirmaci pozdržet.

  • ● BIPs #1412 přidává do BIP329 (export štítků peněženky) pole pro ukládání informací o původu klíče. Dále specifikace nově doporučuje, aby štítky nepřesáhly 255 znaků.