Opcode

Anna chce zaplatit Petrovi. Peněženka připraví transakci a potřebné podpisy; uzly pak ověřují, zda směla použít zvolené mince. Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. Uzel je program, který ověřuje transakce a bloky a komunikuje s dalšími účastníky sítě. Bitcoin Script je jazyk části těchto kontrol. Opcode je jeden jeho pokyn, například zkontrolovat podpis. Anna při běžné platbě instrukce ručně nepíše. Uzel ale nemůže věřit pouhému jménu majitele nebo nápisu „podepsáno“: musí vyhodnotit příslušné podmínky. Platný skript je přitom jen součástí ověření celé transakce. [1] [4]

V čitelném výpisu se může objevit OP_DUP nebo OP_CHECKSIG. To jsou lidská jména instrukcí; v samotném skriptu je označují kódy o velikosti bajtu. Bajt je běžná jednotka množství dat. Jiné části zápisu obsahují data, například veřejný klíč. Veřejný klíč slouží k ověřování podpisů a nemusí se držet v tajnosti. Pokyny rodiny OP_PUSHDATA určují, kolik následujících bajtů se má vložit jako údaj. Bajty uvnitř takto vložených dat se znovu nespouštějí jako instrukce. Podobně text receptu „přidej sůl“ není totéž co surovina vložená do mísy. [1] [2]

Představte si hromádku lístků, ze které berete vrchní položku. Tak funguje základní pracovní zásobník skriptu. OP_DUP udělá kopii vrchního údaje, OP_DROP vrchní údaj odstraní. Pokud nejprve provedete OP_DUP a potom OP_DROP na neprázdném zásobníku, vrátíte se k jeho původnímu obsahu. Nezkopírovali jste tím mince, pouze pracovní data. Chybí-li potřebná položka, vyhodnocení může selhat. Záleží také na pořadí a přesném zápisu údajů. [1]

OP_EQUAL vezme horní dvě položky, porovná jejich bajty a místo nich vloží výsledek shody. OP_EQUALVERIFY při neshodě rovnou ukončí vyhodnocení chybou; při shodě pokračuje bez tohoto výsledku na zásobníku. Ani jedna operace sama neověřuje podpis. Dvě stejné kopie veřejného klíče může předložit kdokoli. Teprve odpovídající podpisová kontrola může doložit, že někdo uměl podepsat potřebnou zprávu. [1] [4]

OP_CHECKSIG ověřuje podpis vůči veřejnému klíči a zprávě sestavené z transakce. Soukromý klíč je tajný číselný údaj, kterým se takový podpis vytváří. Soukromý klíč se při tom nezveřejňuje. Parametr sighash určuje, které části transakce podpis pokrývá; není to automaticky slib podepsání všeho ve všech režimech. Starší skripty a SegWit verze 0 používají ECDSA, jeden podpisový algoritmus. Tapscript, skriptová pravidla Taprootu, používá u běžných klíčů délky 32 bajtů Schnorr, jiný podpisový algoritmus. Při čtení stejné instrukce proto záleží na tom, podle které verze pravidel se ověřuje. [1] [3]

Podmínka může umožnit běžné utracení, nebo alternativní cestu pro obnovu. OP_IF a OP_ELSE pomáhají vybrat větev podle hodnoty ze zásobníku; OP_ENDIF podmíněnou část uzavírá. Bitcoin Script nemá obecné programové smyčky, které by se libovolně opakovaly. Z toho ale neplyne, že lze ignorovat cokoli v neprovedené větvi. Některé instrukce se kontrolují už při čtení skriptu; rozhoduje jejich druh i verze pravidel. [1] [3]

CLTV, instrukce OP_CHECKLOCKTIMEVERIFY, umí vynutit absolutní mez, například požadovanou výšku bloku, tedy jeho pořadové číslo v řetězci. CSV, instrukce OP_CHECKSEQUENCEVERIFY, spolu s pravidly stáří transakce vynucuje relativní čekání od potvrzení utráceného výstupu. Výstup je dříve přijatá částka s podmínkami utracení. Tyto instrukce kontrolují příslušná pole transakce; nezačnou samy odpočítávat, neodešlou peníze a nenahradí podpis. Pro konkrétní použití je nutné spojit správný časový zámek s ostatními podmínkami. [7] [8] [9]

Při čtení technické ukázky nejprve určete, zda patří ke staršímu skriptu, SegWitu nebo Tapscriptu. Tapscript přidává OP_CHECKSIGADD pro skládání podpisových kontrol. Naopak OP_CHECKMULTISIG při provedení odmítá; v neprovedené větvi se podle jeho pravidel ignoruje. Nejde o rozpor v názvech, ale o různá ověřovací prostředí. Seznam opcodes tedy není univerzální stavebnice, jejíž díly lze bez dalšího přenášet mezi formáty. [1] [3] [6]

BIP 342 vyhrazuje skupinu OP_SUCCESSx pro budoucí rozšíření Tapscriptu. Po splnění předchozích kontrol stačí takovou instrukci potkat při dekódování a navazující skriptové kontroly se přeskočí s úspěchem, i když leží v neprovedené větvi. Neplatí to pro náhodně stejný bajt uvnitř vložených dat. Je to prostor pro změnu pravidel, nikoli už aktivovaná nová ochrana. Podmínka postavená na dosud nedefinovaném významu nemusí peníze chránit tak, jak autor očekává. [1] [3]

Full Node samostatně kontroluje pravidla platnosti, ale může mít přísnější pravidla pro přijímání a šíření nepotvrzených transakcí. Bitcoin Core v29.0 například ve výchozím nastavení odmítá přeposílat transakce používající instrukci OP_SUCCESSx v Tapscriptu, i když je konsenzus může připustit v bloku. Pro čtenáře z toho plyne jednoduchý postup: u ukázky zjišťujte verzi, vstupní data, co podpis pokrývá a kdy kontrola selže. Samotná čitelná syntaxe není důkaz bezpečné peněženky; při běžném používání tuto práci svěřujete ověřenému softwaru. [1] [5]