Bitcoin Script

Wprowadzenie

Bitcoin Script to prosty, nienadający się do pełnej Turinga (Turing-incomplete) język skryptowy, który stanowi fundamentalną część protokołu Bitcoina. Służy do definiowania warunków, jakie muszą zostać spełnione, aby środki mogły zostać wydane z danego adresu. Każda transakcja Bitcoin, oprócz podstawowych danych o nadawcy i odbiorcy, zawiera również skrypt weryfikujący poprawność operacji, zapewniając bezpieczeństwo i integralność sieci. Jego kluczową cechą jest stosowanie modelu UTXO (Unspent Transaction Output) oraz architektury opartej na stosie (stack-based), co pozwala na wykonywanie operacji kryptograficznych i logicznych bez wprowadzania złożonych stanów czy pętli. Dzięki temu Bitcoin Script jest wysoce przewidywalny i bezpieczny, choć jego funkcjonalność jest celowo ograniczona.

Jak działają skrypty Bitcoin Script?

Bitcoin Script działa na zasadzie weryfikacji warunków dostarczonych w dwóch głównych częściach transakcji: `scriptPubKey` (czasami nazywanym też output script lub locking script) oraz `scriptSig` (input script lub unlocking script). `scriptPubKey` jest dołączany do każdego wyjścia transakcji i definiuje warunki, które muszą zostać spełnione, aby te środki mogły zostać wydane. `scriptSig` jest dostarczany w wejściu kolejnej transakcji, która próbuje wydać te środki, i zawiera dane (np. podpisy cyfrowe, klucze publiczne) mające na celu spełnienie warunków z `scriptPubKey`. Proces weryfikacji polega na konkatenacji `scriptSig` i `scriptPubKey`, a następnie wykonaniu powstałego skryptu od lewej do prawej. Bitcoin Script to język oparty na stosie, co oznacza, że operacje (tzw. opcodes) pobierają argumenty ze stosu, wykonują na nich działania, a następnie umieszczają wyniki z powrotem na stosie. Na przykład, operacja `OP_DUP` duplikuje element ze szczytu stosu, `OP_HASH160` hashuje element, a `OP_EQUALVERIFY` porównuje dwa elementy i w przypadku nierówności zatrzymuje skrypt z błędem. Kluczowym elementem weryfikacji jest użycie kryptografii klucza publicznego. Zazwyczaj `scriptPubKey` wymaga przedstawienia poprawnego podpisu cyfrowego wygenerowanego prywatnym kluczem odpowiadającym podanemu kluczowi publicznemu (często w formie hasza). `scriptSig` zawiera wtedy podpis i klucz publiczny. Skrypt sprawdza, czy klucz publiczny odpowiada hashowi w `scriptPubKey` i czy podpis jest ważny dla transakcji oraz tego klucza publicznego. Jeśli ostateczny wynik wykonania skryptu pozostawi na stosie pojedynczą wartość TRUE (lub cokolwiek innego niż FALSE, pusty stos, czy błąd), transakcja jest uznawana za ważną. Ta prosta, ale potężna logika pozwala na realizację nie tylko standardowych transakcji "pay-to-public-key-hash" (P2PKH), ale również bardziej złożonych scenariuszy, takich jak multisig (wielopodpisowe), czy też skrypty P2SH (Pay-to-Script-Hash) i P2WSH (Pay-to-Witness-Script-Hash).

Główne zalety i charakterystyka

Główną zaletą Bitcoin Script jest jego przewidywalność i bezpieczeństwo, wynikające z celowo ograniczonej funkcjonalności. Brak pętli i rekurencji eliminuje ryzyko nieskończonych obliczeń i zapobiega błędom programistycznym, które mogłyby doprowadzić do utraty środków lub zakleszczenia sieci. Jego prostota i determinizm sprawiają, że weryfikacja transakcji jest szybka i efektywna dla węzłów sieci. Bitcoin Script umożliwia tworzenie elastycznych warunków wydawania środków, wykraczających poza prostą wysyłkę. Pozwala na implementację zaawansowanych zabezpieczeń, takich jak portfele wielopodpisowe (multisig), które wymagają kilku niezależnych podpisów do autoryzacji transakcji, zwiększając bezpieczeństwo. Wspiera również adaptacje takie jak SegWit (Segregated Witness), które optymalizują rozmiar transakcji i zwiększają przepustowość sieci, jednocześnie zachowując kompatybilność wsteczną.

Zastosowania w praktyce

Standardowe transakcje P2PKH (Pay-to-Public-Key-Hash), gdzie środki są wysyłane na adres Bitcoin reprezentujący hash klucza publicznego.
Portfele wielopodpisowe (multisig), wymagające kilku podpisów od różnych stron do autoryzacji transakcji, co zwiększa bezpieczeństwo.
Transakcje Pay-to-Script-Hash (P2SH) i Pay-to-Witness-Script-Hash (P2WSH), pozwalające na użycie złożonych skryptów bez ujawniania ich złożoności w adresie, co obniża opłaty i zwiększa prywatność.
Time locks (blokady czasowe), które pozwalają na wydanie środków dopiero po upływie określonego czasu lub osiągnięciu konkretnego numeru bloku (np. za pomocą `OP_CHECKLOCKTIMEVERIFY` i `OP_CHECKSEQUENCEVERIFY`).
Kanały płatności w Lightning Network, gdzie Bitcoin Script jest wykorzystywany do tworzenia warunków rozliczeń, zabezpieczając środki poza głównym łańcuchem.
Proste smart kontrakty (hash-time locked contracts - HTLCs) do wymiany aktywów pomiędzy różnymi łańcuchami (atomic swaps) lub do budowy bardziej złożonych protokołów.

Porównanie z innymi strukturami danych

Bitcoin Script jest często porównywany z językami inteligentnych kontraktów, takimi jak Solidity na platformie Ethereum. Kluczową różnicą jest to, że Bitcoin Script jest językiem Turing-niekompletnym, co oznacza, że nie obsługuje pętli ani złożonych stanów. Jego cel to głównie weryfikacja warunków transakcji, a nie tworzenie złożonych, ogólnego przeznaczenia aplikacji zdecentralizowanych (dApps). Solidity natomiast jest językiem Turing-kompletnym, co pozwala na tworzenie znacznie bardziej skomplikowanych i elastycznych inteligentnych kontraktów, które mogą utrzymywać stan i wykonywać dowolne obliczenia, ale wiąże się to z większym ryzykiem błędów i luk bezpieczeństwa. Inną różnicą jest model wykonania. Bitcoin Script działa na stosie i jest wykonywany raz w celu weryfikacji. Inteligentne kontrakty na Ethereum działają w maszynie wirtualnej (EVM), która przetwarza transakcje zmieniające stan globalny i może być wywoływana wielokrotnie. Ograniczenia Bitcoin Script zapewniają jego prostotę, przewidywalność i bezpieczeństwo, czyniąc go idealnym do podstawowych zabezpieczeń finansowych, podczas gdy platformy takie jak Ethereum celują w szeroki zakres zastosowań programowalnych.

Najlepsze praktyki (2026)

Wykorzystywanie standardowych wzorców skryptów (P2PKH, P2SH, P2WSH) w celu zapewnienia kompatybilności i bezpieczeństwa, zamiast tworzenia niestandardowych, potencjalnie problematycznych rozwiązań.
Stosowanie Segregated Witness (SegWit) lub Taproot, aby obniżyć opłaty transakcyjne, zwiększyć prywatność i umożliwić bardziej złożone scenariusze skryptowe w przyszłości.
Dokładne testowanie i audytowanie niestandardowych skryptów przed wdrożeniem, ponieważ błędy mogą prowadzić do trwałej utraty środków.
Używanie portfeli i bibliotek, które automatycznie generują zoptymalizowane i bezpieczne skrypty, minimalizując ryzyko ręcznych błędów.
Rozważenie wykorzystania możliwości Taproot (P2TR), które pozwalają na ukrywanie złożoności skryptu w Merkle Tree, zwiększając prywatność i efektywność.

Typowe błędy i pułapki

Niewystarczające testowanie niestandardowych skryptów, co może prowadzić do nieprzewidzianych zachowań lub niemożności wydania środków.
Tworzenie skryptów zbyt skomplikowanych, co zwiększa ich rozmiar, opłaty transakcyjne i utrudnia debugowanie.
Błędne zarządzanie kluczami prywatnymi lub udostępnianie ich, co niezależnie od złożoności skryptu, naraża środki na kradzież.
Brak świadomości ograniczeń Bitcoin Script, takich jak brak pętli czy zmiennych stanu, co prowadzi do prób implementacji niemożliwych lub nieefektywnych rozwiązań.
Niewłaściwe użycie opcode'ów, zwłaszcza tych wrażliwych na bezpieczeństwo, co może prowadzić do luk, które pozwolą innym na wydanie środków.