Zpravodaj tento týden popisuje návrh na urychlení úvodního stahování bloků v Bitcoin Core s ukázkovou implementací demonstrující pětkrát kratší stahování oproti výchozímu nastavení Bitcoin Core. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, oznámeními nových vydání a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● SwiftSync urychlující úvodní stahování bloků: Sebastian Falbesoner zaslal do fóra Delving Bitcoin příspěvek s ukázkou implementace a s výkonnostními výsledky SwiftSync​u, nápadu navrženého Rubenem Somsenem během nedávného setkání vývojářů Bitcoin Core. Později příspěvek zaslal i do emailové skupiny. V době psaní zpravodaje tvrdila většina výsledků ve vlákně 5,28× zrychlení úvodního stahování bloků (IBD) oproti výchozím nastavením Bitcoin Core (používajícím assumevalid bez assumeUTXO). Díky tomu se podařilo snížit čas úvodní synchronizace ze zhruba 41 hodin na osm.

    Před tím, než je možné SwiftSync používat, musí někdo s uzlem synchronizovaným na nějaký nedávný blok vytvořit hints file určující, které výstupy budou součástí množiny UTXO v jeho výšce (tedy které výstupy jsou neutracené). To lze při současné velikosti množiny UTXO efektivně zakódovat do několika set megabajtů. Hints file také určuje, pro který blok byl vygenerovaný, nazvěme ho terminální blok SwiftSyncu (terminal SwiftSync block).

    Uživatel, který chce SwiftSync použít, stáhne tento soubor a pomocí něj zpracuje každý blok až do terminálního bloku. Přitom ukládá do množiny UTXO pouze výstupy obsažené v hints file. Tento způsob masivně snižuje počet položek, které jsou do UTXO databáze během IBD přidány a později z ní odstraněny.

    Aby byla zajištěna správnost hints file, je každý výstup, který do databáze UTXO nemá být uložen, přičten do kryptogafického akumulátoru. Každý utracený výstup je z akumulátoru odečten. Při dosažení terminálního bloku musí být akumulátor prázdný, tedy každý výstup, který byl do něj přidán, z něj byl posléze také odebrán (tj. byl utracen). Pokud tomu tak není, znamená to, že byl hints file nesprávný, a IBD musí být provedeno znovu od začátku a bez SwiftSyncu. Tímto způsobem nemusí uživatelé tvůrcům hints file důvěřovat, neboť škodlivý soubor nemůže vyústit ve správný stav UTXO. Může jen vést k proplýtvaným několika hodinám práce počítače.

    Další možností SwiftSyncu, která ještě nebyla naimplementována, je možnost paralelní validace bloků během IBD. To je možné, jelikož assumevalid nekontroluje skripty starších bloků, položky nejsou z databáze UTXO nikdy odstraňovány (před dosažením terminálního bloku) a akumulátor pouze sleduje součet výstupů přidaných (vytvořené výstupy) a odebraných (utracené výstupy). Díky tomu nejsou do dosažení terminálního bloku žádné závislosti mezi jednotlivými bloky. Z podobných důvodů nabízí paralelní validaci během IBD i Utreexo.

    Diskutující se zabývali několika aspekty návrhu. Falbesonerova původní implementace používala akumulátor MuHash (viz zpravodaj č. 123, angl.), u kterého byla ukázána odolnost vůči generalizovanému narozeninovému útoku. Somsen popsal alternativní přístup, který by mohl být rychlejší. Falbesoner pochyboval, že by byl tento alternativní přístup kryptograficky bezpečný, avšak díky jeho jednoduchosti ho i přesto naimplementoval a zjistil, že SwiftSync urychluje ještě více.

    James O’Beirne se ptal, zda je SwiftSync užitečný, když assumeUTXO nabízí ještě výraznější zrychlení. Somsen odpověděl, že SwiftSync zrychluje u assumeUTXO validaci na pozadí, je tedy i pro uživatele assumeUTXO přínosný. Dále poznamenal, že pokud někdo stahuje potřebná data pro assumeUTXO (databázi UTXO v určité blokové výšce), nemusí zvlášť stahovat ještě hints file (jsou-li oba generované pro stejnou výšku).

    Vojtěch Strnad, 0xB10C a Somsen diskutovali o komprimování dat v hints file, které by mohlo snížit velikost souborů o 75 % s výslednou velikostí pro blok 850 900 kolem 88 MB.

    Diskuze v době psaní nadále probíhala.

Bitcoin Core PR Review Club

V této měsíční rubrice shrnujeme nedávné sezení Bitcoin Core PR Review Club a vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.

Přidej správce prediktorů poplatků je PR od vývojáře ismaelsadeeq, které zlepšuje logiku předpovídání transakčních poplatků (též nazývaného odhadování). Přináší novou třídu ForecasterManager, která umožňuje registraci více Forecasterů. Stávající CBlockPolicyEstimator (který bere do úvahy pouze potvrzené transakce) je refaktorován do jednoho z takových prediktorů a je přidán nový MemPoolForecaster. Ten pro výpočet používá nepotvrzené transakce v mempoolu, a proto umí na změny poplatků reagovat rychleji.

  • Proč se tento nový systém nazývá „prediktor” (forecaster) a „správce prediktorů” (forecaster manager) a ne „odhadce” (estimator) a „správce odhadování poplatků” (fee estimation manager)?

    Systém předpovídá (predikuje) budoucí dopad na základě současných a minulých dat. Na rozdíl od odhadce, který aproximuje aktuální podmínky s určitou dávkou náhodnosti, prediktor předpovídá budoucí události, což je v souladu s prediktivní povahou tohoto systému. ➚

  • Proč nebyla do CBlockPolicyEstimator přidána reference na mempool, podobně jako v PR #12966? Jaký je aktuální přístup a proč je lepší než držet referenci na mempool? (Tip: podívejte se na PR #28368)

    CBlockPolicyEstimator dědí z CValidationInterface a implementuje jeho virtuální metody TransactionAddedToMempool, TransactionRemovedFromMempool a MempoolTransactionsRemovedForBlock. To poskytuje CBlockPolicyEstimator všechna data o mempoolu, aniž by s ním musel být úzce provázán přes referenci. ➚

  • Jaké jsou kompromisy mezi novou architekturou a přímou změnou CBlockPolicyEstimatoru?

    Nová architektura s třídou FeeRateForecasterManager, do které se může registrovat více prediktorů (Forecaster), je modulárnějším přístupem, který umožňuje lepší testování a vynucuje lepší dělení zodpovědností. Umožňuje později snadno přidat nové strategie předpovídání. Daní za to je větší množství kódu, který se musí udržovat, a možná i zmatení uživatelů, kteří si musí vybrat konkrétní metodu. ➚

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.

  • ● Core Lightning 25.02.1 je údržbovým vydáním současné hlavní verze tohoto oblíbeného LN uzlu přinášejícím několik oprav.

  • ● Core Lightning 24.11.2 je údržbovým vydáním předchozí hlavní verze tohoto populárního LN uzlu. Obsahuje opravy několik chyb, některé z nich jsou stejné jako ve vydání 25.02.1.

  • ● BTCPay Server 2.1.0 je hlavním vydáním tohoto platebního procesoru s vlastním hostováním. Obsahuje nekompatibilní změny pro uživatele některých altcoinů, vylepšení navyšování poplatků pomocí RBF i CPFP a lepší proces vícenásobného podepisování v případech, kdy všichni podepisující používají BTCPay Server.

  • ● Bitcoin Core 29.0rc3 je kandidátem na vydání příští hlavní verze tohoto převládajícího plného uzlu. Prosíme, přečtěte si průvodce testováním verze 29.

  • ● LND 0.19.0-beta.rc2 je kandidátem na vydání tohoto oblíbeného LN uzlu. Jedním významným vylepšením, které by si zasloužilo důkladné testování, je nové schéma RBF navyšování poplatků během kooperativního zavření kanálu.

Významné změny kódu a dokumentace

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), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition a repozitáři BINANA.

  • ● LDK #2256 a LDK #3709 vylepšují informace o původci selhání (viz zpravodaj č. 224, angl.) dle specifikace v BOLTs #1044. Přidává novou strukturu AttributionData a do stávající struktury UpdateFailHTLC přidává volitelné pole attribution_data. Dle tohoto protokolu připojí každý přeposílající uzel do chybové zprávy příznak hop_payload, dobu, po kterou uzel HTLC držel, a HMAC na odpovídající pozici v cestě. Pokud nějaký uzel chybovou hlášku pozmění, nesoulad v HMAC může identifikovat, mezi kterými dvěma uzly se tak stalo.

  • ● LND #9669 mění jednoduché taprootové kanály, aby vždy používaly zastaralý druh kooperativního zavření, i když je nastavený nový druh s RBF (viz zpravodaj č. 347). Dříve uzel s aktivovanými oběma funkcemi nenastartoval.

  • ● Rust Bitcoin #4302 přidává do builder API skriptu novou metodu push_relative_lock_time(), které se předává jako argument relativní časový zámek. Zároveň změna zastarává metodu push_sequence(), jejímž argumentem bylo prosté číslo sekvence. Tato změna odstraňuje potenciální zmatení vývojářů, kteří neúmyslně přidali do skriptů prosté číslo sekvence namísto relativního časového zámku, který je zkontrolován oproti číslu sekvence vstupu pomocí CHECKSEQUENCEVERIFY.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 15. 4. v 15:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.