121 / 736IBD

Initial Block Download

První synchronizace uzlu

Nový bitcoinový uzel nezná minulost sítě. Než se může spolehnout na vlastní pohled na platby, musí ji dohnat a zpracovat. Initial Block Download vysvětluje, proč při prvním spuštění nestačí jen rychlé připojení.

Initial Block Download, zkráceně IBD, je počáteční synchronizace bitcoinového uzlu. Při běžném postupu získává starší bloky, ověřuje je podle pravidel svého softwaru a vytváří aktuální přehled dosud neutracených prostředků.

Spustíte doma Full Node, tedy program, který samostatně kontroluje bitcoinové bloky a transakce. Blok sdružuje transakce do dávky, která se připojuje ke společné historii. Ostatní účastníci sítě už mají za sebou dlouhou historii, váš nový uzel však začíná bez ní. Nejprve získává hlavičky: stručné údaje propojující jednotlivé bloky. Obsahují také Proof of Work, důkaz výpočetní práce. Těžaři jej hledají opakovanými výpočty; ostatní mohou nalezený výsledek rychle zkontrolovat. Seznam hlaviček se podobá obsahu knihy: pomůže s orientací, ale neznamená to, že jste přečetli a ověřili všechny její stránky. [1] [7]

Když sousedé nabídnou různé větve historie, uzel se neřídí počtem hlasů. Hlavičky mu umožní porovnat nahromaděnou výpočetní práci a vybrat nadějného kandidáta k dalšímu ověření. Více bloků samo o sobě nemusí znamenat více práce. A ani velké množství práce nedává neplatným transakcím výjimku z pravidel; obsah vybrané větve ještě potřebuje zkontrolovat. [1] [2] [6]

Samotné bloky může uzel získávat od více sousedů najednou, takže není odkázán na rychlost jediného odesílatele. Při jejich zapojování do ověřené historie ale potřebuje znát předchozí stav. Platba se svými vstupy odkazuje na dřívější částky, které chce utratit. Uzel musí zjistit, zda opravdu existují a nebyly už utraceny. Stažený pozdější blok proto může čekat na zpracování dřívějšího. To je jeden z důvodů, proč stažení dat není totéž co dokončená synchronizace. [1] [2]

Uzel porovnává obsah bloku s otiskem transakcí v hlavičce, který vytváří Merkle Tree. Kontroluje také například návaznost utrácení a to, zda odměna těžaře nepřekračuje povolenou částku. Pravidla uplatňuje podle toho, která v daném místě historie platila. Digitální podpis dokládá oprávnění k platbě pomocí soukromého klíče, tajného číselného údaje, aniž by jej odhalil. Kontroly podpisů a dalších podmínek utracení mají u staré historie zvláštní nastavení assumevalid, vysvětlené níže. Hlavičky ani soubor stažený od důvěryhodně působícího souseda tyto kontroly jako celek nenahrazují. [2] [3]

Při každém zpracovaném bloku uzel odebírá utracené výstupy a přidává nové. Výstup je konkrétní částka s podmínkami, za kterých ji lze později použít. Pokud dosud utracena nebyla, říká se jí UTXO. Jejich soubor umožní ověřit další platbu, aniž by software pokaždé procházel celou historii od začátku. Nejde o seznam bankovních účtů ani o kopii všech někdejších transakcí. [2] [3]

Bitcoin Core může za určitých podmínek přeskočit staré kontroly skriptů, tedy podpisů a dalších podmínek utracení. Nastavení assumevalid odkazuje na známý blok s externě ověřenou historií; záleží také na jeho návaznosti, dostatečné práci a hloubce. Ostatní potřebné kontroly tím nemizí, ale část výsledku ověření se předpokládá. Chybně zvolený předpoklad proto není bez rizika. assumevalid=0 tuto optimalizaci vypíná za cenu většího množství práce pro váš počítač. [2]

Pruned Node po zpracování odstraňuje staré blokové soubory, ale ponechává aktuální UTXO a potřebné další údaje. Při běžném IBD tedy historii stále získá a zpracuje; pouze ji celou trvale neskladuje. Tím ušetří místo na disku, nikoli automaticky objem prvního stahování. Pozdější úloha vyžadující už smazané bloky může vyžadovat jejich opětovné získání. [2] [7]

Bitcoin Core v29.0 posuzuje mimo jiné stáří nejnovějšího přijatého bloku, minimální nahromaděnou práci a stav načítání. Když tento provozní příznak jednou přepne na false (tedy že počáteční synchronizace skončila), během stejného běhu jej už nevrátí na true (tedy že ještě probíhá). Je to pomůcka pro chování programu, ne důkaz, že nikde na světě neexistuje novější blok. Ani pozdější ztráta připojení z něj neudělá spolehlivý ukazatel aktuálnosti. [2] [5]

Rychlé připojení pomůže, ale počítač musí také počítat a zapisovat na disk. Délku ovlivňuje procesor, paměť, úložiště i dostupnost sousedů. V technickém výpisu getblockchaininfo je verificationprogress odhad průběhu ověřování; není to slib zbývajících minut ani jen podíl stažených bajtů. Při řádném ukončení a dalším spuštění lze navázat na uložený postup, místo aby se vše pokaždé začínalo od nuly. [5] [7]

AssumeUTXO dovoluje použít podporovaný snímek UTXO, tedy uložený stav k určitému bloku. Software jeho obsah porovná s očekávaným otiskem a může z něj dříve dojít k současnosti, zatímco historii zpracovává na pozadí. Následně porovná i stav získaný tímto historickým ověřováním. Není to libovolná databáze od cizího člověka ani způsob, jak minulost nikdy neověřit. Dřívější použitelnost a dokončené ověření celé historie jsou dvě různá dosažená stadia. [4] [8]

Pro nejúplnější obraz čtěte toto heslo společně s Pruned Node, AssumeUTXO, Block Propagation, Compact Blocks, Bitcoin, Bitcoin Core. Opačným směrem na něj odkazují také Block Propagation, Compact Blocks, Pruned Node, AssumeUTXO.

DOC · 001Bitcoin Developer Guide — Initial Block DownloadDokumentace DOC · 002Bitcoin Core — validationDokumentace DOC · 003Bitcoin Core — chainstateDokumentace DOC · 004Bitcoin Core — AssumeUTXO designDokumentace DOC · 005Bitcoin Core — getblockchaininfoDokumentace DOC · 006Satoshi Nakamoto — Bitcoin whitepaperPrimární zdroj DOC · 007Bitcoin.org — Running a Full NodeDokumentace DOC · 008Bitcoin Core v29.0 — AssumeUTXO usageDokumentace
Revidováno: Primární zdroje · Nejde o investiční doporučení