Bitcoin Core

Pavel přijímá bitcoin za prodané knihy. Zákaznice mu ukáže potvrzení na telefonu, ale Pavel chce vědět, zda platba skutečně dorazila a zda už je v platném bloku. Může se zeptat veřejného průzkumníku, nebo použít peněženku napojenou na svůj vlastní uzel. Bitcoin Core je program, kterým takový uzel provozuje. Uzlem tu myslíme počítač s programem, který samostatně kontroluje pravidla Bitcoinu; blok je dávka transakcí přidaná do společné historie. Data získává od ostatních, jejich správnost však posuzuje sám. Pavel je ilustrativní příklad: smyslem programu je nahradit pouhé spoléhání na cizí hlášení vlastním ověřováním. Stažením aplikace se nestává těžařem, nedostává automaticky BTC a nemůže vracet cizí platby. Projekt zveřejňuje zdrojový kód pod licencí MIT, takže jej lze studovat, upravovat a dále šířit za podmínek licence. [1] [16]

Tyto dvě úlohy se snadno pletou, protože Bitcoin Core může dělat obě. Uzel kontroluje historii a nové bloky; peněženka sleduje příslušné prostředky, vytváří adresy a připravuje transakce. Pokud spravuje soukromé klíče, může s nimi také podepisovat. Soukromý klíč je tajný údaj, s nímž peněženka vytvoří digitální podpis opravňující k utracení příslušných bitcoinů. Samotný klíč přitom neposílá ostatním uzlům. Core ale může běžet úplně bez peněženky. Pavel může pro placení používat jinou kompatibilní aplikaci a svůj uzel jako zdroj ověřených dat; některá propojení potřebují další software. Samotná běžící kopie Core přitom nepřesměruje všechny ostatní peněženky na jeho uzel. Pro orientaci v názvech: bitcoin-qt nabízí grafické ovládání, bitcoind běží na pozadí a bitcoin-cli posílá programu příkazy. [12] [17]

Nový uzel musí nejprve dohnat historii. Tomu se říká Initial Block Download neboli IBD. Při obvyklé synchronizaci stahuje bloky, kontroluje jejich návaznost, práci těžařů a pravidla transakcí. Zpracováním historie si sestavuje chainstate: vlastní přehled dosud neutracených výstupů, označovaných UTXO. Výstup transakce určuje částku a podmínky jejího utracení, například potřebný podpis. Dokud ho další transakce neutratí, zůstává v tomto přehledu. Nejde o seznam jmen a bankovních účtů. Rychlost závisí na počítači, disku i připojení, takže pomalý začátek sám o sobě neznamená závadu. Než Pavel použije uzel k ověřování aktuálních plateb, zkontroluje dokončení synchronizace.

Pro přesnost: nastavení assumevalid může za stanovených podmínek vynechat kontroly skriptů, tedy podmínek utrácení, hluboko v historii; -assumevalid=0 tuto zkratku vypíná. Jiná funkce, AssumeUTXO, umožňuje začít z ověřovaného snímku stavu a starší historii zpracovat na pozadí. Snímek je uložený přehled UTXO k určitému bloku. Program nejprve porovná jeho hash, tedy digitální otisk, s očekávanou hodnotou ve svém kódu; tím ještě není hotové samostatné ověření celé předchozí historie. Tyto postupy mají odlišné předpoklady; nejsou důvodem tvrdit, že každá instalace od první chvíle provedla úplně stejné kontroly. [9] [10] [12] [17]

Po synchronizaci Core dál přijímá data od připojených uzlů, kterým se říká peers. Nepotvrzené transakce, jež přijme, uchovává v Mempoolu, své dočasné čekárně. Záznam v ní ještě není potvrzením v bloku a různé uzly mohou mít odlišný obsah. Když dorazí nový blok, Core jej zkontroluje. Mezi platnými kandidátními řetězci rozhoduje největší nahromaděná práce, nikoli počet hlasujících počítačů nebo prostý počet bloků. Pavel proto rozlišuje „platbu jsem viděl“ a „platba má potvrzení“. Ani vlastní uzel nezaručí okamžité zařazení transakce a neodstraňuje možnost reorganizace, při které se část právě sledované historie nahradí jinou platnou větví. [16]

Představme si, že Pavlův uzel nepřijme určitou nepotvrzenou transakci do Mempoolu. Neznamená to automaticky, že se nikdy nemůže objevit v platném bloku. Konsenzuální pravidla určují, co je pro uzel platný blok a platné utrácení. Místní relay policy navíc stanovuje, které nepotvrzené transakce bude uzel přijímat a přeposílat, například kvůli ochraně jeho prostředků před zahlcením. Policy se na transakce uvnitř přijatého bloku neuplatňuje stejným způsobem: rozhoduje platnost podle konsenzuálních pravidel. Rozdílné nastavení Mempoolu tedy samo o sobě neznamená rozdělení sítě. Tato hranice pomáhá číst debaty o změnách Core bez zaměňování každého nastavení za změnu peněžních pravidel. [13]

Core ukládá bloková data, stav uzlu a případně také peněženky. Pruning šetří disk tím, že po zpracování odstraňuje starší soubory bloků a data potřebná k vracení jejich změn. Uzel dál ověřuje nové bloky; jen nemá celý archiv vždy po ruce. Historické dotazy či znovuprocházení starých plateb pak mohou vyžadovat opětovné stažení dat. Indexy jsou pomocné přehledy pro rychlejší hledání; například txindex není slučitelný s pruningem. Jejich volba má vycházet z toho, co má uzel obsluhovat. Zásadní je jiný rozdíl: veřejné bloky lze stáhnout znovu, ztracené soukromé klíče z nich neobnovíte. Používáte-li peněženku Core, potřebujete její vlastní bezpečnou zálohu. Při běžícím programu k tomu slouží zálohovací funkce, například backupwallet, nikoli nahodilé kopírování právě zapisované databáze. [11] [12]

Pavel začne na oficiálním webu a přečte si pokyny ke konkrétnímu vydání. Kontrolní součet SHA-256 je otisk staženého souboru: odhalí, že se soubor liší od očekávaného. Sám ale neprozradí, kdo zveřejnil očekávaný otisk. Proto se kontrolují i digitální podpisy a totožnost podpisových klíčů. Útočník, který podstrčí program i vlastní kontrolní součet, neprohraje jen tím, že oba souhlasí. Pro pokročilejší ověření projekt používá reprodukovatelné buildy: nezávislí lidé mohou ze stejného zdrojového kódu sestavit shodné soubory a porovnat výsledky. Nástroj Guix pomáhá sjednotit prostředí takového sestavení. To posiluje ověření původu programu, nikoli důkaz, že v jeho kódu nemůže být chyba. [8] [7]

Core nabízí JSON-RPC, rozhraní, přes které jej mohou řídit jiné programy. Hodí se pro dotaz na stav uzlu i propojení služeb, ale podle dostupné peněženky a oprávnění může umožnit také práci s prostředky. Přihlašovací údaje proto nejsou něco, co pošlete údajnému pomocníkovi. Rozhraní samo nešifruje síťový přenos a není určeno k vystavení veřejnému internetu. Běžné spojení s ostatními bitcoinovými uzly je jiná věc než zpřístupnění tohoto ovládání. Pro místní přístup Core používá také dočasné přihlašovací údaje v souboru .cookie. Vzdálenou správu je třeba řešit zabezpečeným spojením a omezeným přístupem, podle dokumentace. Pokud uzel jen zkoušíte, není důvod začínat otevíráním správcovského rozhraní do světa. [14]

Změnu kódu může navrhnout kdokoli. Jiní přispěvatelé ji čtou, testují a připomínkují; správci repozitáře, označovaní jako maintainers, mají oprávnění schválené změny sloučit. Tím však nezískávají dálkové ovládání Pavlova uzlu. Provozovatel rozhoduje, jaký software spustí. Ani tato volba není hlasovací lístek, kterým jeden člověk přepíše pravidla všem ostatním: nekompatibilní změna může jeho uzel od zbytku oddělit. Bitcoin Core je významná implementace pravidel, nikoli firma vlastnící celou síť. Při čtení oznámení proto rozlišujte návrh, přijetí do zdrojového kódu, vydání programu a skutečné používání. Mezi těmito kroky může být dlouhá cesta. [15]

Začít lze provozem uzlu bez ukládání vlastních klíčů. Pavel si nejprve ověří soubor a podpisy, nechá doběhnout IBD a zkontroluje, že peněženka, kterou chce používat, opravdu čerpá data z jeho uzlu. Pak sleduje připojení, postup bloků a volné místo. Před aktualizací čte release notes, tedy přehled změn a případných podmínek přechodu; pokud používá peněženku, ověří její zálohu a obnovu. Při problému pomůže diagnostický soubor debug.log, který ale není vhodné bez rozmyslu zveřejňovat. Nastavení pruning, indexy a RPC mají odpovídat jeho použití, ne cizímu návodu zkopírovanému naslepo. Vlastní uzel má být srozumitelný nástroj kontroly. Není povinností pro první malý nákup, ale dává smysl, když chcete vědět, podle čeho své platby považujete za platné. [12] [14]