Скриптовият език

Скриптовият език на биткойн е малък език за програмиране, който работи със стек. Всеки изход носи заключващ скрипт (scriptPubKey), който задава условията за харченето му. Харченето подава отключващ скрипт (scriptSig), който отговаря на тези условия. Нодът изпълнява двата заедно и приема харченето само ако скриптът завърши с истинска стойност най-отгоре в стека.

Скриптът няма цикли, затова всеки скрипт свършва след ограничен брой стъпки. Тази секция обяснява как работи езикът, опкодите, които ще срещнете в hex записа, и видовете скриптове, изградени върху него.

Как работи заключващият скрипт?

Всеки изход има заключващ скрипт, който казва какво е нужно, за да се похарчат монетите. Записва се, когато изходът се създава.

За да похарчи изход, по-късна трансакция поставя отключващ скрипт във входа си. Старите типове използват scriptSig, а типовете SegWit и Taproot използват witness. Нодът съчетава двата и ги изпълнява като една програма.

Какво е стекът?

Стекът (stack) е списък, в който се пазят данните, докато скриптът работи. Данните се слагат отгоре, а опкодовете взимат елементи от върха. Опкодът може да работи с елементите, които е взел, и да върне резултат обратно в стека.

Скриптът е валиден, когато най-горният му елемент е истина, тоест всяка стойност, различна от нула. Обичайната истинска стойност е OP_1. Празният стек или невярният елемент отгоре правят скрипта невалиден.

Нодовете искат в стека да остане точно един елемент, затова допълнителните елементи правят харченето нестандартно. Старите правила за консенсус допускат допълнителни елементи, така че такова харчене може да влезе в блок, но нодовете не го препращат. Скриптовете SegWit и Taproot трябва да оставят точно един истински елемент, както изискват BIP 141 и BIP 342.

Кои опкодове се срещат най-често?

Опкодът е един байт от скрипта, а всеки има име и hex стойност. Данните стигат до стека чрез опкодовете за push. OP_PUSHBYTES_X (01 до 4b) поставя в стека следващите X байта. OP_PUSHDATA1 (4c), OP_PUSHDATA2 (4d) и OP_PUSHDATA4 (4e) поставят по-дълги елементи, с поле за дължина от 1, 2 или 4 байта. Числата от 0 до 16 имат собствени опкодове: OP_0 е 00, а OP_1 до OP_16 са 51 до 60.

Нодовете очакват и най-краткия възможен push. Трансакция, която използва по-дълъг опкод, отколкото е нужно, нодовете не препращат. Това е правилото в BIP 62.

Опкод	Hex	Какво прави
OP_0	00	слага в стека празен елемент, числото нула
OP_1 до OP_16	51 до 60	слагат в стека числата от 1 до 16
OP_IF	63	изпълнява следващата част само ако най-горният елемент е истина
OP_ELSE	67	започва другата част на OP_IF
OP_ENDIF	68	затваря частта на OP_IF
OP_VERIFY	69	прекратява скрипта, ако най-горният елемент е невярен
OP_RETURN	6a	прекратява скрипта веднага, ползва се за изходи с данни
OP_DROP	75	премахва най-горния елемент
OP_DUP	76	копира най-горния елемент
OP_SWAP	7c	разменя двата най-горни елемента
OP_SIZE	82	слага в стека байтовата дължина на най-горния елемент
OP_EQUAL	87	слага истина, ако двата най-горни елемента са равни
OP_EQUALVERIFY	88	OP_EQUAL, после OP_VERIFY
OP_ADD	93	събира двете най-горни числа
OP_RIPEMD160	a6	RIPEMD-160 хеш на най-горния елемент
OP_SHA256	a8	SHA-256 хеш на най-горния елемент
OP_HASH160	a9	SHA-256, после RIPEMD-160
OP_HASH256	aa	SHA-256, приложен два пъти
OP_CHECKSIG	ac	проверява подпис спрямо публичен ключ
OP_CHECKSIGVERIFY	ad	OP_CHECKSIG, после OP_VERIFY
OP_CHECKMULTISIG	ae	проверява m подписа спрямо n публични ключа
OP_CHECKMULTISIGVERIFY	af	OP_CHECKMULTISIG, после OP_VERIFY
OP_CHECKLOCKTIMEVERIFY	b1	прекратява скрипта, освен ако locktime вече е изтекъл
OP_CHECKSEQUENCEVERIFY	b2	прекратява скрипта, освен ако относителното времево заключване е изтекло
OP_CHECKSIGADD	ba	добавя 1 към брояч, когато Taproot подписът е валиден

Как работят двата скрипта заедно?

Отключващият скрипт винаги се изпълнява първи, макар че заключващият скрипт е бил записан с изхода, когато изходът е бил създаден. Двата скрипта споделят един стек. При харчене по SegWit witness-ът заема мястото на scriptSig.

Какви ограничения има скриптът?

Тези ограничения важат, когато скриптът се изпълнява. Заключващ скрипт, който ги нарушава, все пак може да бъде създаден, но никой не може да го похарчи. Валидните граници са тези:

Ограничение	Стойност
Размер на един скрипт	10,000 байта
Опкодове, които не са push	201
Размер на един елемент в стека	520 байта
Елементи в стека едновременно	1,000

Нодовете също не препращат отключващ скрипт (scriptSig), по-дълъг от 1,650 байта. Майнър пак може да включи такова харчене, но е по-трудно то да влезе в блок. Числата са от script.h и policy.h в Bitcoin Core.

Кои типове скриптове има?

Повечето изходи ползват един от десет шаблона. Всеки е фиксиран модел със собствени данни за отключване. Нодовете препращат само изходи и харчения, които минават стандартните проверки. Други скриптове са валидни, но нод може да откаже да ги препрати, защото някои непроверени скриптове може да отнемат много време за проверка. Страниците на тази секция са подредени по ред на четене. Най-простият тип е първи.

1. P2PK: най-старата форма, заключена към суров публичен ключ.
2. P2PKH: заключен към хеша на публичен ключ, класическият адрес, който започва с 1.
3. P2MS: гол мултисиг, при който m от n ключа трябва да подпишат.
4. P2SH: заключен към хеша на скрипт, така че самият заключващ скрипт може да чака до момента на харченето.
5. P2WPKH: P2PKH, преместен в witness, с bech32 адреси, които започват с bc1q.
6. P2WSH: P2SH за SegWit скриптове.
7. P2SH-P2WPKH: P2WPKH, увит в P2SH, за портфейли, които не могат да изпращат към bech32 адреси.
8. P2SH-P2WSH: P2WSH, увит в P2SH.
9. P2TR: Taproot, най-новият тип, с един ключ и незадължителни скриптови пътища.
10. OP_RETURN: изход с данни, който никога не може да се похарчи.

Преди SegWit да влезе в сила през август 2017 г., при блок 481,824, стандартните скриптове са били P2PK, P2PKH, P2MS, P2SH и OP_RETURN. Типовете SegWit и Taproot са дошли по-късно, а много нови плащания ги използват.

Къде да продължите?

Започнете със страницата за P2PK, после прочетете страницата за P2PKH, която ще срещнете най-често. За да видите истински скриптови данни, отворете трансакция в нашия explorer. Трансакцията f4184fc5... от блок 170 плаща два P2PK изхода, а explorer-ът ги показва без адрес.