Czym jest język skryptowy Bitcoin?

Bitcoin Script to język programowania, który steruje każdą transakcją w sieci Bitcoin. Jest to prosty język oparty na stosie, który określa dokładne warunki, na jakich można wydać bitcoiny, a każdy pełny węzeł w sieci uruchamia go za każdym razem, gdy transakcja jest weryfikowana. Bez niego Bitcoin byłby jedynie rejestrem liczb, pozbawionym mechanizmu pozwalającego ustalić, kto jest właścicielem poszczególnych środków.

Większość użytkowników nigdy nie ma bezpośredniego kontaktu z językiem skryptowym Bitcoina. Ich portfele zajmują się tym w sposób niewidoczny. Jednak za każdym razem, gdy wysyłasz lub odbierasz BTC, na tysiącach komputerów jednocześnie uruchamiają się dwa małe programy, sprawdzające, czy warunki wydatkowania zostały spełnione. Zrozumienie tego mechanizmu pozwala w znacznym stopniu wyjaśnić, dlaczego Bitcoin ma taką strukturę oraz co może, a czego nie może zrobić w porównaniu z platformami takimi jak Ethereum.

W niniejszym artykule omówiono działanie Bitcoin Script, przedstawiono główne rodzaje transakcji, które umożliwia, wyjaśniono aktualizację Taproot, która w 2021 roku zmodernizowała warstwę skryptową, a także przedstawiono aktualny stan debaty na temat kodu operacyjnego „covenant” na czerwiec 2026 roku.

Zarządzaj swoimi bitcoinami w bezpieczny sposób dzięki samodzielnemu przechowywaniu Aplikacja Bitcoin.com Wallet.

Najważniejsze wnioski

• Bitcoin Script to oparty na stosie język programowania wbudowany w protokół Bitcoin, który określa warunki, na jakich można wykorzystać dowolny wyjście bitcoina.
• Każda transakcja Bitcoin zawiera dwa skrypty: skrypt blokujący (ScriptPubKey) ustawiony przez odbiorcę oraz skrypt odblokowujący (ScriptSig) dostarczony przez osobę dokonującą płatności. Aby transakcja była ważna, oba skrypty muszą zostać pomyślnie wykonane.
• Skrypt Bitcoin został celowo zaprojektowany tak, by nie był kompletny w sensie Turinga. Nie zawiera pętli, nie zachowuje stanu między kolejnymi uruchomieniami i ma sztywne ograniczenia dotyczące rozmiaru skryptu. Dzięki temu każdy skrypt z pewnością zostanie zakończony, co stanowi funkcję zabezpieczającą, a nie ograniczenie.
• Język skryptowy ewoluował, przechodząc przez pięć głównych formatów: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) oraz Taproot (P2TR), z których każdy poszerzał zakres możliwości, zachowując jednocześnie kompatybilność wsteczną.
• W aktualizacji Taproot (listopad 2021 r.) wprowadzono podpisy Schnorr, ścieżki wydatkowania oparte na algorytmie MAST zapewniające prywatność oraz Tapscript – zaktualizowany język skryptowy z wbudowanym mechanizmem ułatwiającym przyszłe aktualizacje.
• Przykłady praktycznego zastosowania oparte na Bitcoin Script obejmują portfele z wielokrotnym podpisem, transakcje z blokadą czasową, kontrakty z blokadą czasową oparte na skrócie (podstawa sieci Lightning), usługi escrow oraz kontrakty z dyskretnym dziennikiem.
• W przeciwieństwie do inteligentnych kontraktów w sieci Ethereum, Bitcoin Script jest bezstanowy: każdy skrypt działa w całkowitej izolacji, nie mając wiedzy o żadnej innej transakcji. Jest to świadomy wybór architektoniczny.
• Najbardziej aktywnym obszarem rozwoju skryptów Bitcoin Script w 2026 roku są kody operacyjne typu „covenant”, a zwłaszcza OP_CTV (BIP-119) i OP_CAT (BIP-347), które umożliwiłyby skryptom nakładanie ograniczeń dotyczących tego, jak musi wyglądać transakcja wydatkowa. Żaden z nich nie został jeszcze aktywowany w sieci głównej.

Czym jest Bitcoin Script?

Bitcoin Script to oparty na stosie, bezstanowy język skryptowy wbudowany w protokół Bitcoin. Każdy wyjście transakcji w sieci Bitcoin zawiera skrypt blokujący (zwany ScriptPubKey), który określa warunki wydatkowania środków. Każdy, kto chce wydatkować te środki, musi dostarczyć skrypt odblokowujący (zwany ScriptSig lub, w transakcjach SegWit i Taproot, danymi świadka), który spełnia te warunki.

Język ten czerpie swoją strukturę z języka Forth – minimalistycznego języka programowania opartego na stosie, opracowanego w latach 60. Podobnie jak Forth, Bitcoin Script odczytywany jest od lewej do prawej, operuje na strukturze danych zwanej stosem i wykorzystuje notację polską odwrotną (RPN), w której operatory następują po operandach, a nie poprzedzają je. Wykonuje po jednej instrukcji na raz, nie posiada pętli i nie przechowuje danych w pamięci trwałej między kolejnymi wykonaniami.

Ta ostatnia kwestia jest tym, z czym większość osób styka się jako pierwszą, zapoznając się z językiem Bitcoin Script na poziomie protokołu: język ten celowo nie jest językiem Turinga-kompletnym. Język Turinga-kompletny może wykonać dowolne obliczenia, o ile dysponuje wystarczającą ilością czasu i zasobów. Bitcoin Script nie jest w stanie tego zrobić z założenia, a przyczyny tego wyboru mają ogromne znaczenie dla funkcjonowania sieci.

Jak działa skrypt Bitcoin: model stosu

Aby zrozumieć, jak działa Bitcoin Script, trzeba zrozumieć, czym jest stos. Stos to struktura danych działająca na zasadzie „ostatnie weszło, pierwsze wyszło” (LIFO). Wyobraź sobie stos talerzy: można dodawać lub usuwać elementy tylko z góry. W skryptach Bitcoin dane są umieszczane na stosie, a kody operacyjne (opcodes) manipulują tym, co znajduje się na samym szczycie.

Kiedy węzeł Bitcoin weryfikuje transakcję, uruchamia kolejno dwa skrypty:

1. Skrypt odblokowujący (ScriptSig lub świadek) podane przez osobę wydającą monety. Powoduje to umieszczenie danych na stosie – zazwyczaj są to podpis cyfrowy i klucz publiczny.
2. Skrypt blokujący (ScriptPubKey) związane z wydatkowaniem środków. Zawiera on kody operacyjne, które działają na danych ze stosu i sprawdzają, czy warunki wydatkowania są spełnione.

Jeśli skrypt zostanie wykonany bez błędów i na końcu pozostawi na stosie wartość niezerową (TRUE), transakcja jest ważna. Jeśli zakończy się niepowodzeniem lub pozostawi wartość FALSE, transakcja zostanie odrzucona przez węzeł i nigdy nie trafi do bloku.

To wykonanie jest całkowicie bezstanowe. Skrypt nie posiada żadnych informacji o poprzednich transakcjach, nie zna aktualnych sald i nie zachowuje żadnych danych po zakończeniu działania. Każdy skrypt uruchamia się za każdym razem od nowa, w izolacji.

Krok po kroku: standardowa transakcja P2PKH

Pay-to-Public-Key-Hash (P2PKH) to pierwotny typ transakcji w sieci Bitcoin, stosowany od 2009 roku. Adresy P2PKH zaczynają się od cyfry „1”. Oto jak w praktyce wyglądają pola ScriptPubKey i ScriptSig:

Skrypt odblokowujący (ScriptSig):

<podpis> <klucz publiczny>

Skrypt blokujący (ScriptPubKey):

OP_DUP OP_HASH160 <skrót klucza publicznego> OP_EQUALVERIFY OP_CHECKSIG

Gdy węzeł łączy oba elementy i wykonuje je razem, operacje na stosie przebiegają krok po kroku:

• Podpis i klucz publiczny z obiektu ScriptSig są umieszczane na stosie
• OP_DUP duplikuje klucz publiczny znajdujący się na szczycie stosu
• OP_HASH160 oblicza skrót duplikatu (najpierw SHA-256, a następnie RIPEMD-160), uzyskując 20-bajtowy skrót
• Skrót klucza publicznego ze skryptu blokującego jest umieszczany na stosie
• OP_EQUALVERIFY sprawdza, czy oba skróty są zgodne. Jeśli nie są, wykonanie zostaje wstrzymane, a transakcja kończy się niepowodzeniem.
• OP_CHECKSIG sprawdza, czy podpis jest prawidłowy dla danego klucza publicznego

Jeśli wszystkie etapy zakończą się pomyślnie, stos kończy się wartością TRUE, a środki zostają uwolnione. Cały proces trwa milisekundy i przebiega identycznie na każdym węźle w sieci.

Wyjaśnienie kodów operacyjnych Bitcoina

Kody operacyjne Bitcoina to poszczególne polecenia składające się na skrypt. Każdy z nich zajmuje jeden bajt, co daje 256 możliwych slotów na kody operacyjne. Spośród nich około 80 jest obecnie aktywnych w sieci głównej. Pozostałe są albo zarezerwowane, wyłączone, albo przypisane do mechanizmu zapewniania kompatybilności z przyszłymi wersjami OP_SUCCESS, wprowadzonego wraz z Tapscriptem.

Kody operacyjne dzielą się na kilka kategorii:

• Kody operacyjne przesyłania danych umieścić na stosie takie wartości, jak klucze publiczne, podpisy i skróty
• Kody operacji arytmetycznych wykonywać operacje dodawania, odejmowania i porównywania. Warto zauważyć, że mnożenie i dzielenie są wyłączone.
• Kody operacji kryptograficznych obejmują OP_SHA256, OP_HASH160 i OP_SHA1 do generowania skrótów oraz OP_CHECKSIG do weryfikacji podpisu
• Kody operacyjne sterujące przepływem włącz logikę warunkową: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Kody operacyjne związane z manipulacją stosem w tym OP_DUP (duplikowanie elementu znajdującego się na początku listy), OP_DROP (usunięcie elementu znajdującego się na początku listy) oraz OP_SWAP (zamiana miejscami dwóch pierwszych elementów)

W 2010 roku Satoshi Nakamoto wyłączył kilka kodów operacyjnych po wykryciu luk w ich pierwotnych implementacjach. Należą do nich OP_CAT (łączenie dwóch elementów stosu), OP_MUL (mnożenie) oraz OP_DIV (dzielenie). Ich brak miał długotrwałe konsekwencje dla możliwości ekspresji skryptu Bitcoin, a kilka z najaktywniej dyskutowanych w 2026 r. propozycji ulepszeń Bitcoina dotyczy właśnie tego, czy należy ponownie włączyć niektóre z nich.

Pełny wykaz kodów operacyjnych, zawierający wartości szesnastkowe i opisy, można znaleźć w Strona „Bitcoin Wiki Script” jest wiarygodnym źródłem informacji.

Dlaczego brak pełnej kompletności Turinga jest zaletą

Standardowo wyjaśnia się to tym, że Bitcoin Script nie zawiera pętli, więc skrypty z pewnością się zakończą, a tym samym sieć jest chroniona przed nieskończonym wykonywaniem. Jest to prawda, ale nie oddaje w pełni istoty sprawy.

Głębsza kwestia dotyczy powierzchni ataku. Język kompletny w sensie Turinga pozwala na wyrażenie dowolnych obliczeń. Ta ekspresyjność stanowi jednocześnie przestrzeń, w której kryją się błędy. Język Solidity platformy Ethereum stał się przyczyną jednych z najkosztowniejszych luk w zabezpieczeniach oprogramowania w historii. W 2016 roku podczas ataku na DAO wykorzystano lukę reentrancy w kontrakcie inteligentnym, co spowodowało straty rzędu około 60 milionów dolarów według ówczesnych cen i ostatecznie doprowadziło do kontrowersyjnego hard forka sieci Ethereum. W szerszym ekosystemie DeFi na przestrzeni wielu lat wyciekły setki milionów dolarów w wyniku ataków na kontrakty inteligentne.

Skrypt Bitcoin uniemożliwia tego rodzaju ataki z natury rzeczy. Nie można napisać skryptu Bitcoin, który wywoływałby inne skrypty, wykonywał pętlę do momentu zmiany warunku lub zapisywał stan między transakcjami. Każdy skrypt jest programem o ograniczonym zakresie, zakończonym i podlegającym weryfikacji. Maksymalny rozmiar skryptu wynosi 10 000 bajtów. Maksymalna liczba kodów operacyjnych innych niż „push” w jednym skrypcie wynosi 201. Walidator może zawsze obliczyć koszt wykonania w najgorszym przypadku przed uruchomieniem skryptu.

W przypadku sieci o wartości setek miliardów dolarów ta przewidywalność jest warta więcej niż elastyczność, z której się rezygnuje. Ethereum rozwiązuje problem nieograniczonych obliczeń za pomocą limitów gazu, pobierając opłaty od użytkowników za każdy wykonany kod operacyjny i zatrzymując skrypty, którym wyczerpał się budżet. To działa, ale wprowadza własną złożoność i potencjalne źródła awarii. Bitcoin całkowicie omija ten problem dzięki swojej konstrukcji.

Należy jednak zaznaczyć, że określenie „nie jest Turingowo kompletny” nie oznacza „nie jest zdolny do obsługi złożonej logiki”. Bitcoin Script obsługuje wymagania dotyczące wydatkowania wielostronnego, warunki czasowe, ujawnianie preobrazów skrótów oraz kombinacje wszystkich tych elementów. Sieć Lightning Network, która obsługuje miliony płatności dziennie, opiera się w całości na prymitywach Bitcoin Script.

Rodzaje skryptów: Ewolucja od P2PKH do Taproot

Warstwa skryptowa Bitcoina znacznie ewoluowała od 2009 roku, a każda aktualizacja wprowadzała nowy format transakcji, zachowując jednocześnie kompatybilność wsteczną ze wszystkimi wcześniejszymi wersjami.

P2PK (Pay-to-Public-Key, 2009)

Pierwotny format, stosowany w pierwszych transakcjach Bitcoin, w tym w płatności Satoshiego na rzecz Hala Finneya w bloku 170. Środki były przypisywane bezpośrednio do pełnego klucza publicznego, a nie do jego skrótu. Obecnie rzadko stosowany w nowych transakcjach, ponieważ ujawnia klucz publiczny w łańcuchu bloków przed wydaniem środków, co jest uważane za słabsze zabezpieczenie niż uprzednie zaszyfrowanie klucza.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Standardowy format stosowany od ponad dekady. W systemie P2PKH środki są powiązane z skrótem klucza publicznego, a nie z samym kluczem, co pozwala zachować poufność klucza publicznego aż do momentu wydania środków, generuje krótszy adres o długości 20 bajtów oraz stanowi podstawę wszystkich adresów zaczynających się od cyfry „1”. Według danych z łańcucha bloków dostarczonych przez Unchained (kwiecień 2026 r.) adresy P2PKH przechowują obecnie około 43% wydobytej podaży bitcoinów.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Wprowadzony poprzez soft fork 1 kwietnia 2012 r. protokół P2SH przeniósł ciężar skomplikowanych skryptów wydatkowania z nadawcy na odbiorcę. Zamiast osadzać pełny skrypt blokujący w wyjściu, P2SH generuje wyjście odwołujące się do 20-bajtowego skrótu „skryptu realizacji”. Pełny skrypt jest ujawniany dopiero w momencie wydania środków. Dzięki temu mechanizm multisig stał się praktyczny dla zwykłych użytkowników: konfiguracja multisig typu 2 z 3 nie wymagała już, aby wszystkie trzy klucze publiczne były widoczne dla nadawcy w momencie dokonywania płatności. Adresy P2SH zaczynają się od cyfry „3”.

Aby zapoznać się ze szczegółowym opisem działania weryfikacji P2SH na poziomie protokołu, Przewodnik po transakcjach na stronie developer.bitcoin.org krok po kroku omawia działanie mechanizmu skryptów „redeem”.

P2WPKH i P2WSH (SegWit natywny, 2017, BIP 141)

Funkcja Segregated Witness, uruchomiona w sierpniu 2017 r. w bloku nr 481 824, przeniosła dane podpisu poza główny korpus transakcji do oddzielnej struktury świadka. Dane świadka są objęte 75-procentową zniżką wagi, dzięki czemu transakcje SegWit są znacznie tańsze. Standardowa transakcja P2WPKH z jednym wejściem i dwoma wyjściami waży około 141 wirtualnych bajtów, w porównaniu z 226 vbytes dla równoważnej transakcji P2PKH, zgodnie z Analiza typów adresów Bitcoin przeprowadzona przez Spark od marca 2026 r. SegWit rozwiązał również problem podatności transakcji na modyfikacje, co stanowiło warunek wstępny uruchomienia sieci Lightning Network. Natywne adresy SegWit zaczynają się od „bc1q”.

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot został uruchomiony w listopadzie 2021 roku w bloku nr 709 632 i stanowi najważniejszą aktualizację warstwy skryptowej Bitcoina od czasu wprowadzenia SegWit. Wprowadzono w nim podpisy Schnorr, nowy typ wyjścia z obsługą MAST oraz Tapscript jako zaktualizowany język skryptowy. Adresy Taproot zaczynają się od „bc1p.”

Taproot i Tapscript: Jak zmienił się język skryptowy Bitcoina w 2021 roku

Taproot to nie pojedyncza zmiana. To trzy propozycje ulepszeń Bitcoina (Bitcoin Improvement Proposals), opracowane wspólnie i wdrożone jednocześnie.

BIP 340: Podpisy Schnorra

W początkowym okresie Bitcoin wykorzystywał algorytm ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi wybrał go między innymi dlatego, że podpisy Schnorra były wówczas objęte ochroną patentową. Patent ten wygasł w 2008 roku, a dzięki aktualizacji Taproot podpisy Schnorra zostały w końcu wdrożone do protokołu.

Podpisy Schnorra są mniejsze – mają 64 bajty w porównaniu z 71–73 bajtami w przypadku ECDSA. Co ważniejsze, obsługują one agregację kluczy za pomocą schematu o nazwie MuSig2. Agregacja kluczy pozwala wielu sygnatariuszom połączyć swoje indywidualne klucze i podpisy w jeden zagregowany klucz i podpis, który w łańcuchu bloków jest nie do odróżnienia od zwykłej płatności z jednym podpisem. Transakcja z portfela z podpisem wielokrotnym typu 2 z 3, realizowana za pośrednictwem ścieżki klucza kooperacyjnego Taproot, wygląda identycznie jak standardowa płatność w łańcuchu bloków. Stanowi to rzeczywisty zysk w zakresie prywatności dla każdego, kto przechowuje bitcoiny w ramach złożonej struktury powierniczej.

BIP 341: Pay-to-Taproot i MAST

P2TR wprowadza nowy typ wyjścia z dwiema ścieżkami wydatkowania:

• A ścieżka klucza dokonywać płatności przy użyciu podpisu Schnorra, stosowanego w sytuacji, gdy wszystkie strony wyrażają zgodę i chcą skorzystać z najprostszego i najtańszego rozwiązania
• A ścieżka do skryptu wykorzystywać MAST (Merkelized Abstract Syntax Tree, czyli implementację tej koncepcji w ramach Taproot)

MAST umożliwia przypisanie pojedynczego wyjścia do drzewa zawierającego wiele skryptów wydatkowania za pośrednictwem korzenia Merkle’a. Podczas wydatkowania w łańcuchu bloków ujawniany jest jedynie konkretny warunek, który faktycznie został wykorzystany. Wszystkie pozostałe możliwe ścieżki wydatkowania w drzewie pozostają trwale ukryte. W przypadku użytkownika, który skonfigurował złożoną politykę wydatkowania, np. „Mogę wydawać środki w zwykły sposób, albo dwóch z trzech powierników może dokonać wydatkowania po upływie sześciu miesięcy, albo klucz odzyskiwania może dokonać wydatkowania po upływie dwóch lat”, w łańcuchu bloków pojawia się wyłącznie ta ścieżka, która została faktycznie zrealizowana.

Według danych Glassnode przytoczonych przez Spark w marcu 2026 r., do 2024 r. udział Taproot w transakcjach bitcoinowych wzrósł do około 42%, głównie dzięki aktywności związanej z Ordinals i inskrypcjami BRC-20. Od tego czasu udział ten ulegał wahaniom w zależności od sytuacji rynkowej, ale infrastruktura ta jest obecnie standardem w głównych portfelach i na giełdach. Strona tematyczna poświęcona Taproot w serwisie Bitcoin Optech śledzi bieżące prace nad protokołem Taproot.

BIP 342: Skrypt Tapscript

Tapscript to zaktualizowany język skryptowy wykorzystywany do transakcji typu „script-path” w ramach Taproot. Wykorzystuje on większość kodów operacyjnych znanych ze starszej wersji Bitcoin Script, ale wprowadza kilka istotnych zmian:

• OP_CHECKMULTISIG oraz OP_CHECKMULTISIGVERIFY zostały wycofane. Stary kod operacyjny multisig miał pewną osobliwość, która wymagała umieszczenia na stosie elementu fikcyjnego jako obejścia. Tapscript usuwa go i zastępuje go OP_CHECKSIGADD, który weryfikuje podpisy Schnorra pojedynczo i zlicza ich liczbę. Schematy wielopodpisowe oparte na progu stają się prostsze i tańsze w realizacji.
• Zniesiono ograniczenia dotyczące rozmiaru skryptów dla poszczególnych liści MAST. Poszczególne skrypty w ramach gałęzi Taproot mogą mieć dowolną wielkość.
• Kody operacyjne OP_SUCCESS stanowią najbardziej przyszłościową zmianę. W starszej wersji języka skryptowego napotkanie niezdefiniowanego kodu operacyjnego powoduje niepowodzenie skryptu. W Tapscript kod operacyjny z zakresu OP_SUCCESS powoduje, że skrypt kończy się sukcesem bezwarunkowo. Przyszłe soft forki będą mogły przypisać tym kodom operacyjnym rzeczywiste zachowanie poprzez dodanie ograniczeń dotyczących warunków ich powodzenia, bez konieczności wprowadzania nowej wersji skryptu lub przeprowadzania pełnego cyklu ponownego wdrażania w całym ekosystemie. Nowe możliwości można dodawać do warstwy skryptowej Bitcoina w sposób bardziej przejrzysty niż kiedykolwiek wcześniej w historii protokołu.

Miniscript

Oprócz Tapscriptu coraz większe znaczenie dla programistów zyskuje powiązany projekt o nazwie Miniscript. Miniscript to ustrukturyzowany sposób pisania podzbioru języka Bitcoin Script, który można analizować, łączyć w kompozycje i podpisywać w sposób ogólny. Podczas gdy surowy język Script wymaga ręcznego tworzenia i jest trudny do zweryfikowania, skrypty Miniscript można automatycznie sprawdzać pod kątem poprawności oraz łączyć w większe zasady. Nie rozszerza to możliwości języka Script, ale sprawia, że to, co już potrafi, staje się znacznie bardziej dostępne dla programistów tworzących portfele i narzędzia do przechowywania aktywów.

Możliwości skryptu Bitcoin: praktyczne zastosowania

Obecnie w sieci głównej Bitcoin działają następujące typy transakcji, z których wszystkie opierają się na elementach podstawowych języka Bitcoin Script:

Portfele z wielokrotnym podpisem (multisig) wymagają kluczy prywatnych typu M z N do autoryzacji transakcji. Dział finansowy firmy może wymagać 3 z 5 zatwierdzeń dla każdej wypłaty. Małżeństwo może stosować zasadę 2 z 2 w przypadku wspólnych oszczędności. Dzięki Taproot i agregacji kluczy Schnorr wspólne transakcje z wieloma podpisami są teraz w łańcuchu bloków nie do odróżnienia od standardowych transakcji z jednym podpisem.

Transakcje z blokadą czasową Należy używać OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, w skrócie CLTV) oraz OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, w skrócie CSV), aby uniemożliwić przeniesienie środków przed osiągnięciem określonej wysokości bloku lub upływem określonego czasu. Zastosowania obejmują planowanie spadkowe, harmonogramy nabywania uprawnień do tokenów przez pracowników, mechanizmy wymuszonych oszczędności oraz transakcje karne wykorzystywane w kanałach sieci Lightning Network.

Kontrakty z blokadą czasową oparte na funkcji skrótu (HTLC) połączyć wymóg podania pierwotnej wartości skrótu z blokadą czasową. Warunek wydatkowania działa w następujący sposób: należy ujawnić pierwotną wartość tego skrótu przed osiągnięciem określonej wysokości bloku, w przeciwnym razie środki powrócą do nadawcy. HTLC stanowią podstawowy element sieci Lightning Network, umożliwiając bezufne kierowanie płatnościami w łańcuchach kanałów pomiędzy stronami, które nie pozostają w bezpośredniej relacji.

Rękojmia Rozwiązania te blokują środki w skrypcie P2SH lub Taproot, co wymaga zgody wielu stron przed ich uwolnieniem; zazwyczaj klucz decydujący o wyniku w przypadku remisu znajduje się w posiadaniu niezależnego arbitra.

Umowy dotyczące dyskretnych dzienników (DLC) wykorzystują podpisy adaptera Schnorr oparte na oracle, aby umożliwić rozliczanie kontraktów finansowych na podstawie danych z rzeczywistego świata, takich jak notowania cenowe czy wyniki zdarzeń, bez konieczności powierzenia oracle jakichkolwiek środków. Kontrakty DLC działają w sieci głównej Bitcoin i są wykorzystywane w przypadku opcji oraz kontraktów terminowych rozliczanych w Bitcoinie.

Skrypty Bitcoin a inteligentne kontrakty Ethereum

Zarówno Bitcoin Script, jak i Solidity w sieci Ethereum określają warunki, na jakich mogą odbywać się transfery środków, ale reprezentują one zasadniczo odmienne rozwiązania architektoniczne. Warto dokonać bezpośredniego porównania, ponieważ różnice te w znacznym stopniu wyjaśniają kompromisy, na które zgodziła się każda z tych sieci.

Podstawową różnicą jest stanowość. Kontrakty Ethereum przechowują i modyfikują dane, które są zachowywane między transakcjami, co umożliwia funkcjonowanie protokołów pożyczkowych, zdecentralizowanych giełd, zarządzania w łańcuchu bloków oraz standardów tokenów. Bitcoin Script nie posiada odpowiednika tej funkcji. Każdy skrypt działa w izolacji, nie mając wiedzy o żadnej innej transakcji.

Jest to świadomy wybór architektoniczny, a nie luka czekająca na wypełnienie. Warstwa skryptowa Bitcoina została zaprojektowana z myślą o jednym konkretnym zadaniu: egzekwowaniu warunków wydawania bitcoinów w sposób przewidywalny i bezpieczny, na dużą skalę. W tym przypadku brak stanu stanowi zaletę. Powierzchnia ataku jest mniejsza, wykonanie jest deterministyczne w odniesieniu do milionów niezależnych walidatorów, a na poziomie protokołu nie ma możliwości wykorzystania luk w inteligentnych kontraktach, ponieważ na tym poziomie nie istnieją kontrakty stanowe.

Projekty, które dążą do zwiększenia możliwości programowania w ramach sieci Bitcoin, budują je warstwowo. Sieć Lightning Network obsługuje płatności. Protokoły DLC obsługują umowy finansowe powiązane z danymi zewnętrznymi. Systemy warstwy drugiej, takie jak Ark i Liquid Network, odpowiadają na różne potrzeby w zakresie skalowalności. Żadne z tych rozwiązań nie wymaga modyfikacji modelu skryptowego warstwy bazowej.

Debata na temat „Covenant”: Co może się zmienić w skrypcie Bitcoina

Ewolucja języka skryptowego Bitcoin Script zawsze przebiegała powoli i w sposób konserwatywny. Najbardziej aktywnym obecnie obszarem rozwoju są kody operacyjne typu „covenant” – propozycje, które pozwoliłyby skryptowi określać nie tylko, kto może wykorzystać wyjście, ale także, jak musi wyglądać wynikowa transakcja. Stanowi to znaczące poszerzenie możliwości ekspresyjnych języka skryptowego.

Najważniejsze propozycje na czerwiec 2026 r. to:

• OP_CTV (BIP-119, CheckTemplateVerify), autorstwa Jeremy’ego Rubina, dodaje pojedynczy kod operacyjny, który przypisuje UTXO do konkretnego, z góry określonego szablonu wydatkowania, obejmującego wersję transakcji, czas blokady, liczbę wejść, sekwencje, liczbę wyjść oraz same wyjścia. Została zaprojektowana jako nierekurencyjna, jest uważana za najbardziej konserwatywną spośród głównych propozycji i dotyczy przede wszystkim skarbców, kontroli przeciążenia oraz pewnych ulepszeń sieci Lightning. Od kwietnia 2026 r. OP_CTV ma na stole konkretne parametry wdrożeniowe określające okno sygnalizacyjne „Speedy Trial”, ale nie osiągnęła jeszcze szerokiego konsensusu społeczności wymaganego do aktywacji, zgodnie z Analiza warunków umowy BlockEden z kwietnia 2026 r..
• OP_CAT (BIP-347), zaproponowany przez Ethana Heilmana i Armina Sabouri, przywróciłby kod operacyjny, który Satoshi wyłączył w 2010 roku. OP_CAT łączy dwa elementy stosu, co w teorii wydaje się proste, ale ma daleko idące konsekwencje. W połączeniu z podpisami Schnorra umożliwia to introspekcję transakcji na wzór „covenant”. Według analizy łańcucha bloków przeprowadzonej przez sCrypt pod koniec 2024 roku, w sieci testowej Bitcoin Signet kod operacyjny OP_CAT wygenerował znacznie więcej transakcji deweloperskich niż APO lub CTV. OP_CAT jest już aktywny w sieciach Liquid Network i Fractal Bitcoin i nie odnotowano żadnych ataków związanych z jego wykorzystaniem. BIP-347 posiada oficjalny numer propozycji i jest poparty aktywnymi badaniami, jednak aktywacja w sieci głównej wymaga konsensusu społeczności, który na razie nie istnieje.
• LNHANCE łączy OP_CTV z OP_CHECKSIGFROMSTACK (CSFS) i OP_INTERNALKEY, mając na celu konkretne usprawnienia w tworzeniu kanałów w sieci Lightning Network, w tym nieinteraktywne otwieranie kanałów oraz bardziej wydajne zarządzanie kanałami wielostronnymi.

Żadna z tych zmian nie została wdrożona w sieci głównej Bitcoina na dzień czerwca 2026 roku. Różnice techniczne między nimi są w dużej mierze możliwe do rozwiązania. Trudniejszym problemem są mechanizmy aktywacji. Proces soft forka Bitcoina wymaga szerokiego konsensusu, a debata dotycząca porozumienia niesie ze sobą pozostałe napięcia wynikające z poprzednich kontrowersyjnych aktualizacji. Z debaty jasno wynika, że warstwa skryptowa Bitcoina ma znaczną przestrzeń do rozwoju w ramach swoich konserwatywnych ram. Kwestią, nad którą się obecnie pracuje, jest kolejność działań i porozumienie społeczności, a nie to, czy język skryptowy ma przyszłość.

Wnioski

Skrypt Bitcoin to niewidoczna infrastruktura leżąca u podstaw każdej transakcji w sieci. Większość użytkowników nigdy nie ma z nim bezpośredniego kontaktu. Portfele tworzą poprawne skrypty, podpisują je i rozsyłają, nie ujawniając przy tym mechanizmów działania. Jednak każda płatność, każdy kanał Lightning, każdy plan z blokadą czasową i każdy sejf z podpisem wielokrotnym opiera się na tym samym, opartym na stosie języku skryptowym Bitcoin, który został wprowadzony wraz z protokołem w 2009 roku.

Od tamtego czasu warstwa skryptowa znacznie się rozwinęła: technologia P2SH umożliwiła praktyczne realizowanie złożonych transakcji, SegWit obniżył opłaty i umożliwił działanie sieci Lightning, a Taproot wprowadził podpisy Schnorra, ochronę prywatności opartą na MAST oraz kompatybilną z przyszłymi wersjami strukturę kodów operacyjnych Tapscript. Propozycje dotyczące protokołów typu „covenant”, które są obecnie przedmiotem ożywionej dyskusji, stanowią potencjalny kolejny rozdział. To, czy którekolwiek z nich zostaną wdrożone i w jakim terminie, pozostaje w połowie 2026 roku kwestią całkowicie otwartą.

Zrozumienie języka Script nie wymaga bycia programistą. Wymaga natomiast uznania, że konserwatyzm Bitcoina, celowe ograniczenia, powolne tempo aktualizacji oraz brak pełności Turinga nie stanowią wad. Cechy, które sprawiają, że język Bitcoin Script jest przewidywalny, to te same cechy, które od szesnastu lat zapewniają czystość warstwy konsensusu.