AssumeUTXO

Petr zapíná svůj první Full Node, program, který sám kontroluje pravidla sítě Bitcoin. Blok sdružuje transakce do dávky, která se připojuje ke společné historii. Při běžném spuštění musí uzel nejprve projít dlouhou historii. AssumeUTXO mu umožní začít z připraveného UTXO setu: soupisu dosud neutracených výstupů transakcí, z nichž každý obsahuje částku a podmínky jejího utracení. Takový snapshot zachycuje stav po konkrétním bloku. Není to archiv všech plateb ani důkaz, že Petrův počítač již ověřil celou minulost. [1] [3]

Snapshot nelze jednoduše prohlásit za správný podle jeho názvu. Při načítání přes loadtxoutset kontroluje Bitcoin Core v29.0 jeho formát, základní blok (blok, k němuž se snímek vztahuje) a podporované parametry. Spočítá také hash obsahu UTXO, tedy jeho kryptografický otisk, a ještě před aktivací jej porovná s očekávanou hodnotou. Pozměněný obsah proto nemůže projít jen tím, že soubor dostal důvěryhodně vypadající jméno. [2] [3] [6]

Po přijetí snapshotu uzel naváže na jeho stav, postupně ověří novější bloky a může dohnat současný konec řetězce. Nepřijímá je bez ověření: dál kontroluje například podmínky utrácení a povolenou tvorbu nových bitcoinů. Výhodou je, že tato cesta k dnešnímu provozu nemusí čekat na dokončení starší historie. Neznamená to ale, že stará historie už prošla místní kontrolou. [1] [6]

Současně vzniká druhý stav, který se skládá z historických bloků od začátku až k základu snapshotu. Jde o nezávislý výpočet ze získané historie, ne o další kopii staženého soupisu. Program tedy po určitou dobu udržuje dva stavy s různým postupem. Technický příkaz getchainstates je umí zobrazit; údaj, že aktivní stav došel k posledním blokům, sám nepotvrzuje dokončení této práce na pozadí. [1] [8]

Očekávaný hash i podporovaný základní blok jsou součástí konkrétní verze programu. Než Petrův uzel historii sám dopočítá, spoléhá na správnost tohoto zabudovaného údaje. Porovnání hashů umožňuje zkontrolovat shodu obsahu, ale samo nedokazuje, že k němu vedla platná historie. Kdyby byl očekávaný stav chybný, dřívější používání uzlu by z tohoto chybného předpokladu vycházelo. Právě proto se následné ověření nesmí zaměňovat s kontrolou souboru při načtení. [2] [6]

Soubor může pocházet od jiného provozovatele, ale ten tím nezískává právo určovat obsah přijatého stavu. Rozhoduje shoda s hodnotou podporovanou programem, nikoli jeho slib. Zároveň neplatí, že lze načíst libovolný snapshot z libovolného bloku; podpora závisí na verzi i síti. Kontrola hashe také nezaručí, že dodavatel soubor opravdu doručí nebo že stahování a zpracování nespotřebuje čas, připojení a disk. [2] [4] [7]

Jakmile práce na pozadí dojde ke stejnému základnímu bloku, vypočte se hash takto vytvořeného UTXO setu a porovná s očekávaným hashem snapshotu. Nejde o porovnání dnešního stavu se starou fotografií: srovnává se stejný bod historie. Pokud výsledky nesouhlasí, popsaná implementace uzel zastaví a přestane používat stav odvozený ze snapshotu. Neshodu neskrývá ani ji neoznačí za úspěšné ověření. [1] [6]

AssumeUTXO mění hlavně dobu, za kterou se lze dostat k použitelnému uzlu. Historické stahování a ověřování přesto pokračuje, navíc se dočasně udržují dvě databáze stavu. To zatěžuje procesor i disk. Pruned Node šetří místo mazáním starších, již zpracovaných blokových souborů; kontroly pravidel tím nevynechává. Pruned Node může snapshot také použít, ale úspora místa má vlastní pravidla. Některé navazující indexy musí historii zpracovávat od začátku, takže dřívější dostupnost uzlu neznamená okamžitou připravenost všech připojených aplikací. [5] [7]

UTXO set obsahuje informace o neutracených výstupech, ne soukromé klíče, kterými se povoluje utrácení. Digitální podpis dokládá oprávnění k platbě pomocí soukromého klíče, tajného číselného údaje, aniž by jej odhalil. Samotný UTXO set proto není zálohou peněženky a nevrátí ztracenou Seed Phrase, obnovovací slova peněženky, která tento způsob obnovy používá. Ani staré platby se nemusejí hned ukázat: jejich hledání může potřebovat bloky z období před snapshotem. Záloha klíčů, hledání historie vlastní peněženky a ověřování stavu sítě jsou odlišné úkoly. [1] [7]

Podobné názvy svádějí k záměně. AssumeUTXO začíná z načteného stavu a starší historii dopočítává na pozadí. Naproti tomu assumevalid za určitých podmínek vynechává část historických kontrol skriptů, tedy podmínek utrácení včetně podpisů. Je to samostatná optimalizace, která může ovlivnit i historické ověřování; samotné dokončení AssumeUTXO neříká, že byla vypnutá. Při čtení návodu proto rozlišujte, odkud uzel začne, co skutečně ověřuje a kdy jeho jednotlivé kontroly skončí. [5] [6]