44 / 736RULES

Konsensuální pravidla

Pravidla, podle kterých každý Full Node samostatně pozná platnou transakci a blok. Díky nim nemusí věřit těžaři ani provozovateli peněženky.

Konsensuální pravidla určují, které transakce a bloky může Bitcoin přijmout. Každý Full Node, tedy program samostatně ověřující síť, je uplatňuje sám. Kontroluje například, že stejné prostředky nejsou utraceny znovu, že jsou splněny podmínky Bitcoin Script, jazyka pro zadání podmínek utracení, a že blok má správný Proof of Work, důkaz splnění těžební úlohy. Hlídá také množství nově vytvořených bitcoinů. Větší výpočetní výkon nedává těžaři právo tato pravidla obejít.

Představte si, že někdo pošle tutéž částku ze stejné předchozí platby nejprve vám a potom obchodníkovi. Obě útraty nemohou patřit do platné historie. Uzel při kontrole sleduje výstupy transakcí: záznamy částek s podmínkami, za kterých je lze utratit. Když uzel dostane blok, nekontroluje, kdo ho doporučil, ale zda odpovídá pravidlům, která uzel používá. Ověřuje například dostupnost utrácených výstupů, podmínky Bitcoin Script včetně požadovaných podpisů, Proof of Work i povolenou odměnu těžaře. Porušení pravidla znamená odmítnutí bloku. Podpora firmy nebo většina hlasů na internetu na výsledku nic nemění. [1]

Těžař vybírá transakce a hledá blok; Full Node jeho výsledek samostatně ověřuje. Vývojáři mohou navrhnout změnu a vydat software, ale tím ještě nezmění pravidla ostatních uzlů. Provozovatel uzlu volí software, který spustí. Jeho volba určuje, co přijme on sám, nikoli co musí přijmout všichni ostatní. [2] [1]

Uzel má také pravidla pro nepotvrzené transakce: co uloží do Mempoolu, svého zásobníku transakcí čekajících na potvrzení, a co předá dalším uzlům. Tato místní pravidla se označují jako policy a mohou být přísnější než konsensus. Odmítnutí transakce z mempoolu proto samo o sobě neznamená, že by byla neplatná v bloku. Při ověřování bloku se relay policy nepoužívá. [3]

Soft Fork zpřísňuje pravidla: bloky platné podle nových pravidel vyhovují i těm starým. Starší uzel však nové podmínky nekontroluje. Hard Fork naopak může připustit blok, který starší uzel odmítne. Způsob aktivace pomáhá změnu koordinovat; nezaručuje souhlas všech a nenahrazuje rozhodnutí provozovatelů, jaký software používat. [4]

Vlastní Full Node vám umožní ověřovat přijaté bloky, místo abyste přebírali údaj z webového průzkumníku bloků. Někdy uzel zná více větví, tedy různá pokračování společné historie. Mezi platnými větvemi vybírá podle chainwork, součtu práce připsané jednotlivým blokům podle jejich těžební obtížnosti. Nejde o měření skutečně spotřebované elektřiny ani o pouhý počet bloků. Více práce nemůže ospravedlnit porušení pravidel. Aby uzly docházely ke shodnému výsledku, musí pravidla vyhodnocovat stejně i v neobvyklých případech. Chyba v programu je může rozdělit v tom, které bloky přijímají. [4] [5]

Transakci s příliš nízkým poplatkem může uzel odmítnout šířit. Pokud ji ale těžař zahrne do bloku a transakce i blok splňují konsensus, uzel blok přijme. Jiná situace nastane, když si těžař připíše více než povolené množství nových bitcoinů, označované jako Block Subsidy, a poplatky z transakcí v bloku: takový blok uzel odmítne i se správným Proof of Work. Rozdíl je v důvodu odmítnutí, ne v pověsti těžaře. [3] [1]

Pro nejúplnější obraz čtěte toto heslo společně s Full Node, Soft Fork, Proof of Work, Bitcoin Core, Bitcoin Script, Mempool. Opačným směrem na něj odkazují také 21 Million, Soft Fork, Hard Fork, BIP (Bitcoin Improvement Proposal).

DOC · 001Bitcoin Core — Block validationPrimární zdroj DOC · 002Bitcoin whitepaperPrimární zdroj DOC · 003Bitcoin Core — Transaction Relay PolicyDokumentace DOC · 004Bitcoin Developer Guide — Consensus Rule ChangesDokumentace DOC · 005Bitcoin Core — Chainwork calculationPrimární zdroj
Revidováno: Primární zdroje · Nejde o investiční doporučení