Opcode

Anna chce zapłacić Piotrowi. Portfel przygotowuje transakcję i potrzebne podpisy, a węzły sprawdzają, czy mogła wydać wybrane monety. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Węzeł to program, który sprawdza transakcje i bloki oraz wymienia dane z innymi uczestnikami sieci. Bitcoin Script opisuje część tych kontroli. Opcode to jeden krok, na przykład sprawdzenie podpisu. Przy zwykłej płatności Anna nie pisze instrukcji ręcznie. Węzeł nie może jednak zaufać nazwisku właściciela ani etykiecie „podpisano”: musi sprawdzić warunki. Poprawny skrypt to tylko część weryfikacji całej transakcji. [1] [4]

W czytelnym zapisie można zobaczyć OP_DUP lub OP_CHECKSIG. To nazwy dla ludzi; w samym skrypcie odpowiadają im jednobajtowe kody. Bajt jest standardową jednostką ilości danych. Inne fragmenty zawierają dane, na przykład klucz publiczny. Klucz publiczny służy do sprawdzania podpisów i nie musi być tajny. Instrukcje z rodziny OP_PUSHDATA określają, ile kolejnych bajtów wstawić jako dane. Bajty wewnątrz takiej zawartości nie są ponownie wykonywane jako instrukcje. Pomyśl o różnicy między „dodaj sól” w przepisie a składnikiem wkładanym do miski. [1] [2]

Wyobraź sobie stos kartek, z którego bierzesz wierzchnią. Tak działa podstawowy stos roboczy skryptu. OP_DUP kopiuje górny element, a OP_DROP go usuwa. Wykonanie OP_DUP, a następnie OP_DROP na niepustym stosie przywraca jego wcześniejszą zawartość. Nie powieliło monet, tylko dane robocze. Brak potrzebnego elementu może zakończyć sprawdzanie błędem. Liczą się też kolejność i dokładny sposób zapisu. [1]

OP_EQUAL pobiera dwa górne elementy, porównuje ich bajty i zastępuje je wynikiem porównania. OP_EQUALVERIFY przy różnicy od razu zgłasza błąd; przy zgodności kontynuuje bez pozostawiania wyniku na stosie. Żadna z tych operacji sama nie sprawdza podpisu. Każdy może przedstawić dwie identyczne kopie klucza publicznego. Potrzebna jest właściwa weryfikacja podpisu, by wykazać, że ktoś potrafił podpisać wymaganą wiadomość. [1] [4]

OP_CHECKSIG weryfikuje podpis przy użyciu klucza publicznego i wiadomości zbudowanej z transakcji. Klucz prywatny to tajna wartość liczbowa służąca do utworzenia takiego podpisu. Klucz prywatny nie jest ujawniany. Parametr sighash określa, które części obejmuje podpis; nie każdy tryb podpisuje wszystko. Starsze skrypty i SegWit w wersji 0 korzystają z algorytmu podpisu ECDSA. Tapscript, reguły skryptów Taproot, stosuje inny algorytm, Schnorr, dla zwykłych kluczy o długości 32 bajtów. Sama nazwa instrukcji bez tego kontekstu nie wystarcza. [1] [3]

Warunek może zezwalać na zwykłe wydanie albo alternatywną drogę odzyskania dostępu. OP_IF i OP_ELSE wybierają gałąź według wartości ze stosu, a OP_ENDIF zamyka część warunkową. Bitcoin Script nie ma ogólnych pętli programowych, które można dowolnie powtarzać. Nie oznacza to, że wolno zignorować wszystko w niewykonanej gałęzi. Niektóre instrukcje są sprawdzane już podczas odczytu; znaczenie mają ich typ i wersja reguł. [1] [3]

CLTV, instrukcja OP_CHECKLOCKTIMEVERIFY, może narzucić bezwzględny próg, na przykład określoną wysokość bloku, czyli jego pozycję w łańcuchu. CSV, OP_CHECKSEQUENCEVERIFY, wraz z regułami wieku transakcji wymusza względne opóźnienie od potwierdzenia wydawanego wyjścia. Wyjście to wcześniej otrzymana kwota z warunkami wydania. Instrukcje sprawdzają pola transakcji; nie uruchamiają zegara, nie wysyłają pieniędzy ani nie zastępują podpisu. Konkretne zastosowanie wymaga połączenia właściwej blokady czasowej z pozostałymi warunkami. [7] [8] [9]

Przed lekturą przykładu technicznego ustal, czy dotyczy starszych skryptów, SegWit czy Tapscript. Tapscript dodaje OP_CHECKSIGADD do łączenia sprawdzeń podpisów. Z kolei OP_CHECKMULTISIG powoduje błąd przy wykonaniu; w niewykonanej gałęzi te reguły go ignorują. Nazwy nie są sprzeczne, tylko środowiska weryfikacji się różnią. Lista opcodes nie jest uniwersalnym zestawem klocków, które można bez zastanowienia przenosić między formatami. [1] [3] [6]

BIP 342 rezerwuje rodzinę OP_SUCCESSx dla przyszłych rozszerzeń Tapscript. Po przejściu wcześniejszych kontroli napotkanie takiej instrukcji przy dekodowaniu pomija dalsze sprawdzanie skryptu z wynikiem pozytywnym, nawet w niewykonanej gałęzi. Przypadkowo taki sam bajt wewnątrz wstawionych danych się nie liczy. To miejsce na zmianę reguł, a nie już aktywowana ochrona. Warunek oparty na niezdefiniowanym jeszcze znaczeniu może nie zabezpieczać środków tak, jak oczekuje autor. [1] [3]

Full Node samodzielnie sprawdza reguły poprawności, ale może stosować ostrzejsze zasady przyjmowania i rozsyłania niepotwierdzonych transakcji. Bitcoin Core v29.0 domyślnie odmawia na przykład przekazywania transakcji używających instrukcji OP_SUCCESSx w Tapscript, choć konsensus może dopuszczać je w bloku. Czytając przykład, ustal wersję, dane początkowe, zakres podpisu i przyczyny niepowodzenia. Czytelna składnia nie dowodzi bezpieczeństwa portfela; przy zwykłym korzystaniu powierzasz te zadania sprawdzonemu oprogramowaniu. [1] [5]