Full Node

Představ si, že peněženka ukazuje přijatou platbu. Odkud ví, že transakce skutečně patří do bitcoinové historie a splňuje pravidla? Může se ptát cizího serveru, nebo čerpat z tvého vlastního uzlu. Full Node dává druhé možnosti obsah: podle přijatých dat sám kontroluje, co je platné. Neptá se většiny připojených počítačů, jak má rozhodnout. Pokud mu někdo pošle blok porušující pravidla, odmítne jej. Počet připojených počítačů proto nenahrazuje kontrolu pravidel. Vlastní uzel ti umožňuje ověřovat data, na kterých stavíš své platby. [1] [3]

Uzel kontroluje návaznost bloků, jejich hlavičky a Proof of Work, tedy výpočetní důkaz požadovaný pro blok. U transakcí mimo jiné ověřuje, zda odkazují na existující prostředky, zda se neutrácejí podruhé a zda jsou splněny podmínky pro jejich použití. Tyto podmínky se zapisují do skriptů, drobných programových pravidel. Hlídá také množství nově vytvořených bitcoinů. Průběžným výsledkem je UTXO set, soubor dosud neutracených výstupů transakcí: přehled konkrétních prostředků, které ještě lze použít. Větší kumulovaná práce může rozhodnout mezi dvěma platnými větvemi, ale neudělá platný blok z neplatného. [1]

Ne. Full Node ověřuje bloky a transakce; za samotné běžné ověřování nedostává blokovou odměnu. Těžař naproti tomu sestavuje návrh nového bloku a opakuje výpočty, dokud nenajde vyhovující výsledek. Jeho výpočet používá hash, digitální otisk hlavičky bloku. Obě role mohou být propojené: těžař potřebuje vědět, na jakou historii navazuje a které transakce smí zahrnout. Z toho ale neplyne, že každý uzel musí těžit. Ověřování a soutěž o nalezení dalšího bloku jsou odlišné činnosti. [5] [1]

Nový uzel nejprve potřebuje dohnat historii sítě. Stahuje bloky a zpracovává jejich data; tomu se říká úvodní synchronizace. U pokročilých nastavení je důležité rozlišovat dva způsoby urychlení. Bitcoin Core může s assumevalid za stanovených podmínek vynechat staré kontroly skriptů; nastavení assumevalid=0 tuto optimalizaci vypíná. AssumeUTXO zase umožňuje načíst snapshot, uložený stav neutracených prostředků pro určitý blok, jehož otisk program porovná s hodnotou obsaženou ve zdrojovém kódu. Starší historii pak ověřuje na pozadí. To, že už lze pracovat s aktuálním stavem, tedy samo neznamená dokončenou kontrolu historie. [1] [2]

Full Node nemusí navždy uchovávat všechny soubory starých bloků. Režim Pruning po zpracování část těchto souborů odstraňuje, ale ponechává aktuální UTXO set a potřebná novější data. Uzel dál ověřuje nové bloky. Archivní uzel si staré bloky ponechává, takže je může poskytovat ostatním nebo je znovu prohledávat. Úspora disku tedy není totéž jako lehký klient SPV, tedy klient se zjednodušeným ověřováním plateb: ten používá jednodušší postup a nekontroluje všechny transakce ani jejich stav stejně jako Full Node. Rozdíl je v tom, co ověřuješ, nejen v množství uložených souborů. [3]

Při běžné synchronizaci pruned uzel historické bloky stáhne a zpracuje, teprve potom je může průběžně odstraňovat. Pruning proto není přepínač pro přeskočení ověření starých bloků. Jeho úkolem je šetřit úložiště. Oddělenou otázkou zůstávají optimalizace popsané výše: assumevalid může za určitých podmínek vynechat staré kontroly skriptů a AssumeUTXO dovoluje nejprve použít snapshot, zatímco kontrola historie ještě běží. Při posuzování připravenosti svého uzlu proto sleduj jak způsob synchronizace, tak její skutečný stav, nikoli jen velikost dat na disku. [3] [2]

Peněženka potřebuje informace o transakcích a potvrzeních. Když je získává od cizího serveru, posílá mu dotazy, ze kterých může server odvozovat něco o jejích platbách. Připojení k vlastnímu Full Node umožňuje čerpat data ověřená tvým uzlem a vyhnout se těmto dotazům na cizí server. Jenže samotná instalace a spuštění uzlu peněženku automaticky nepřepojí. Záleží na tom, jaký zdroj dat má skutečně nastavený a podporovaný. Vlastní uzel také není automatická anonymita: ochrana soukromí zahrnuje i další síťová data a způsob používání peněženky. [3] [4]

Uzel může fungovat bez tvých soukromých klíčů. Klíče umožňují podepisovat platby; uzel kontroluje, zda transakce a bloky splňují pravidla. Tyto úlohy nemusí mít na starosti stejné zařízení. Proto si u peněženky ověř nejen to, že někde běží tvůj uzel, ale odkud čte údaje a kudy své transakce vysílá. Vlastní ověřování nenahradí bezpečnou zálohu klíčů ani samo neodstraní údaje, které může prozradit síťová komunikace. Pomáhá v konkrétní části celého postupu: kontrolovat bitcoinová data samostatně. [3] [4]

Uzel má dvě různá rozhraní. Přes P2P spojení komunikuje s dalšími uzly a přenáší bloky a transakce. RPC je rozhraní, kterým mu aplikace zadávají příkazy a mohou případně ovládat i jeho peněženku. Otevřít příchozí P2P port pro výměnu dat proto není totéž jako vystavit RPC cizím lidem. Bitcoin Core doporučuje RPC nepřipojovat přímo k veřejnému internetu. Pro místní přístup standardně používá přihlašovací údaje v souboru .cookie, které dokládají oprávnění aplikace. Nejde o sledovací cookie webového prohlížeče. [4]

Příkazy uzlu umožňují zkontrolovat víc než zelenou ikonu. Ve výstupu getblockchaininfo sleduj správnou síť, počet zpracovaných bloků blocks, počet známých hlaviček headers a údaj initialblockdownload o úvodní synchronizaci. Při použití snapshotu pomůže getchainstates rozlišit aktuální stav od ověřování historie na pozadí. Samotný počet připojení úplné ověření nedokazuje. Nakonec zkontroluj, že uzel nezůstal na zastaralém vrcholu řetězce a že právě z něj tvoje peněženka skutečně čerpá data. Teprve potom se jeho vlastní ověřování promítá do tvého používání peněženky. [2] [1]