OP_CAT jest kodem operacyjnym Bitcoina, który łączy dwa elementy danych ze stosu w jeden, i obecnie stanowi przedmiot jednej z najdłużej trwających debat w środowisku programistów Bitcoina. Był on częścią oryginalnego kodu Bitcoina, został usunięty przez Satoshi Nakamoto w 2010 roku ze względu na obawy dotyczące bezpieczeństwa, a przez ostatnie kilka lat funkcjonował jako propozycja soft forka (BIP 347), który mógłby otworzyć drogę do nowej kategorii zachowań przypominających inteligentne kontrakty w sieci Bitcoin. Od lipca 2026 r. nie jest on aktywny w sieci głównej Bitcoina, choć działa już w kilku sieciach powiązanych z Bitcoinem, gdzie jest po cichu poddawany publicznym testom obciążeniowym.
To, co sprawia, że warto zapoznać się z OP_CAT, to nie tylko sam kod. Chodzi o grono osób z nim związanych: programistów Bitcoin Core debatujących nad tym, czy zmiana ta jest bezpieczna, projekt NFT oparty na memach, który zebrał dziesiątki milionów dolarów na lobbing na rzecz przywrócenia tej funkcji, oraz szybko rozwijający się łańcuch boczny, który już ją wykorzystuje. W tym przewodniku wyjaśniamy, jak działa OP_CAT, dlaczego zostało wyłączone, jakie możliwości mogłoby stworzyć oraz jaki jest aktualny stan rzeczy.
Skorzystaj z funkcji obsługi wielu łańcuchów Aplikacja Bitcoin.com Wallet, któremu miliony użytkowników ufają, jeśli chodzi o bezpieczne i łatwe wysyłanie, odbieranie, kupowanie, sprzedawanie, wymianę, korzystanie z oraz zarządzanie bitcoinami i kryptowalutami.
Najważniejsze wnioski
- OP_CAT (skrót od „operation concatenate”) łączy dwa elementy danych ze stosu Bitcoina w jeden element. Na tym polega cała ta funkcja.
- Funkcja ta była aktywna w najwcześniejszej wersji kodu Bitcoina, a następnie została wyłączona przez Satoshi Nakamoto w 2010 roku ze względu na ryzyko ataku typu „odmowa usługi”.
- Propozycja przywrócenia tej funkcji, BIP 347, została opracowana przez Ethana Heilmana i Armina Sabouri, a numer BIP przyznano jej w kwietniu 2024 roku.
- OP_CAT samo w sobie nie jest porozumieniem, ale w połączeniu z innymi kodami operacyjnymi może służyć do tworzenia ograniczeń wydatków o charakterze podobnym do porozumień, w tym skarbców.
- W połowie 2026 roku funkcja OP_CAT nie została jeszcze aktywowana w głównej sieci Bitcoina. Obecnymi faworytami do kolejnego soft forka konsensusu w sieci Bitcoin są OP_CTV (BIP 119) i OP_CHECKSIGFROMSTACK (BIP 348), a nie sam OP_CAT.
- OP_CAT działa już w sieci Fractal Bitcoin – łańcuchu bocznym opartym na Bitcoinie – gdzie stanowi podstawę standardu tokenów CAT20, a od lat funkcjonuje w sieciach Liquid Network i Bitcoin Cash bez żadnych znanych luk w zabezpieczeniach.
- Projekt NFT oparty na Bitcoinie o nazwie Quantum Cats, stworzony przez Taproot Wizards, przekształcił wsparcie dla OP_CAT w kampanię memową, dzięki której zebrano ponad 37 milionów dolarów na rozwój rozwiązań związanych z OP_CAT.
Jak działa OP_CAT
Najprostszym sposobem na zrozumienie OP_CAT jest wyobrażenie sobie systemu skryptowego Bitcoina jako niewielkiego stosu klocków. Bitcoin Script, język programowania leżący u podstaw każdej transakcji Bitcoin, jest językiem opartym na stosie. Dane są umieszczane na stosie, kody operacyjne działają na element znajdujący się na samym szczycie, a wynik decyduje o tym, czy transakcja jest prawidłowa.
OP_CAT pobiera dwa górne elementy ze stosu i łączy je, co oznacza, że łączy je jeden za drugim w jeden połączony element, który następnie jest umieszczany z powrotem na szczycie stosu. Jeśli stos zawiera wartości „1” i „2”, wykonanie operacji OP_CAT usuwa obie i zastępuje je wartością „12”. Zgodnie z oficjalną specyfikacją zawartą w BIP 347, instrukcja OP_CAT umieściłaby na stosie wyrażenie x1 || x2, gdzie symbol podwójnej rury oznacza konkatenację.
Istnieje jedno istotne ograniczenie. Operacja OP_CAT kończy się niepowodzeniem, jeśli na stosie znajdują się mniej niż dwie wartości lub jeśli ich połączenie dałoby wartość łączną większą niż 520 bajtów – czyli maksymalny rozmiar elementu skryptu w sieci Bitcoin. Ten limit bajtów ma ogromne znaczenie dla historii tego kodu operacyjnego, do czego wkrótce przejdziemy.
Samo połączenie dwóch ciągów danych nie wydaje się zbyt zaawansowane. Jednak język skryptowy Bitcoina nigdy nie dysponował uniwersalnym sposobem łączenia wartości znajdujących się na stosie, a ta luka ograniczała możliwości programistów w zakresie funkcji, które mogli wbudować bezpośrednio w transakcje Bitcoinowe. Jak Bitcoin Optech wyjaśnia, W języku Bitcoin Tapscript brakuje uniwersalnego sposobu łączenia obiektów na stosie, co ogranicza możliwości wyrazowe tego języka i uniemożliwia między innymi tworzenie oraz ocenianie drzew Merkle’a i innych struktur danych opartych na skrótach bezpośrednio w Tapscript. OP_CAT to proponowane rozwiązanie tej konkretnej luki.
Dlaczego w 2010 roku wyłączono OP_CAT?
OP_CAT był częścią pierwszej wersji Bitcoina. W 2010 roku Satoshi Nakamoto usunął go wraz z kilkoma innymi kodami operacyjnymi, takimi jak OP_MUL, OP_DIV i OP_OR. Oficjalnym uzasadnieniem było ryzyko ataku typu „odmowa usługi” (denial-of-service): skrypt wielokrotnie wykorzystujący OP_CAT mógłby teoretycznie wygenerować wykładniczo rosnący fragment danych, na tyle duży, że spowolniłby lub spowodował awarię węzłów próbujących go zweryfikować.
W tamtym czasie nie istniało żadne sztywne ograniczenie dotyczące maksymalnej wielkości pojedynczego elementu w stosie Bitcoina. Oznaczało to, że złośliwy skrypt mógłby nieustannie łączyć wartości, aż do uzyskania ciągu danych na tyle obszernego, by sparaliżować sieć. Usunięcie OP_CAT wraz z innymi wyłączonymi kodami operacyjnymi było konserwatywnym posunięciem, które przedkładało stabilność sieci nad funkcjonalność, której ta młoda sieć jeszcze nie potrzebowała.
Sytuacja uległa zmianie w listopadzie 2021 roku, kiedy Bitcoin wdrożył aktualizację Taproot. Taproot wprowadził Tapscript – nowy kontekst skryptowy z własnymi zasadami, z których jedna ogranicza rozmiar pojedynczego elementu stosu do 520 bajtów. Ten limit bajtów bezpośrednio uniemożliwia wykorzystanie pierwotnej ścieżki ataku. Skrypt nadal może wywoływać OP_CAT, ale nigdy nie jest w stanie wygenerować wartości wystarczająco dużej, aby spowodować problem wyczerpania zasobów, który niepokoił Satoshiego w 2010 roku. To właśnie ten szczegół techniczny ponownie otworzył drzwi do przywrócenia OP_CAT, ograniczając jednak jego zakres wyłącznie do Tapscriptu, a nie do całego Bitcoin Scriptu.
Czy OP_CAT to „Covenant”?
Nie, nie samo w sobie – i jest to jedna z najczęściej błędnie rozumianych kwestii dotyczących OP_CAT. W terminologii Bitcoina „covenant” to ograniczenie dotyczące sposobu, w jaki niewydany wynik transakcji (UTXO) może zostać wykorzystany w przyszłości. Zwykły skrypt Bitcoin może jedynie sprawdzić, czy wydatek jest autoryzowany w danej chwili, zazwyczaj poprzez weryfikację podpisu. Porozumienie idzie o krok dalej, sprawdzając nie tylko, czy wydatek jest autoryzowany, ale także czy wynikowa transakcja spełnia określony zestaw warunków.
OP_CAT nie zawiera żadnego wbudowanego mechanizmu służącego do sprawdzania danych transakcji. Zapewnia on jedynie sposób łączenia fragmentów danych na stosie, co staje się przydatne dla covenants dopiero w połączeniu z innymi kodami operacyjnymi, które weryfikują podpisy w odniesieniu do tych połączonych danych. W samym standardzie BIP 347 wyraźnie stwierdzono, że że OP_CAT, choć zaproponowano jego ponowne uruchomienie w Tapscript, nie jest porozumieniem. Bardziej trafne jest określenie go jako elementu składowego, który w połączeniu z kodami operacyjnymi służącymi do sprawdzania podpisów może służyć do emulowania zachowania podobnego do działania porozumienia.
Ma to znaczenie, ponieważ właśnie elastyczność OP_CAT sprawia, że jest on zarówno interesujący, jak i kontrowersyjny. Chociaż OP_CAT sam w sobie nie jest klauzulą umowną, może ją emulować ze względu na specyfikę działania podpisów Schnorra. W połączeniu z kodem operacyjnym o nazwie CheckSigFromStack (CSFS), który weryfikuje podpis względem dowolnych danych, a nie tylko samej transakcji, OP_CAT może służyć do tworzenia takich samych ograniczeń wydatkowania, do jakich przeznaczone są specjalne kody operacyjne typu „covenant”.
Do czego można wykorzystać OP_CAT?
Ponieważ OP_CAT jest elementem podstawowym o ogólnym przeznaczeniu, a nie funkcją o wąskim zakresie zastosowania, programiści zaproponowali dla niego szeroki wachlarz zastosowań. Do najczęściej omawianych należą:
- Sklepienia. Skarbiec to rodzaj umowy, która wymaga wykonania wielu kroków — często w ramach odrębnych transakcji i bloków — zanim środki będą mogły zostać przekazane. Powoduje to wbudowane opóźnienie, które daje właścicielowi czas na wykrycie i powstrzymanie nieautoryzowanych wydatków, co poprawia bezpieczeństwo rozwiązań w zakresie przechowywania „na zimno” oraz wspólnego nadzoru.
- Umowy o braku dwuznaczności. Mogą one nakładać kary na uczestnika kanału płatniczego, takiego jak Lightning Network, który próbuje rozgłaszać nieaktualny lub fałszywy stan kanału, zwiększając tym samym bezpieczeństwo systemów płatniczych poza łańcuchem bloków.
- Trzy podpisy. OP_CAT umożliwia tworzenie kompaktowych skryptów z wieloma podpisami, których rozmiar rośnie jedynie logarytmicznie wraz z liczbą podpisujących, co oznacza, że transakcja o rozmiarze poniżej 1 kilobajta mogłaby teoretycznie obsługiwać warunki wydatkowania obejmujące miliony kluczy publicznych.
- Tworzenie i weryfikacja drzewa Merkle’a. Ponieważ tworzenie i sprawdzanie drzewa Merkle’a zasadniczo wymaga łączenia i haszowania wartości, OP_CAT dostarcza Bitcoin Script brakujący element niezbędny do realizacji tego zadania w sposób natywny.
- Cechy charakterystyczne dla ery postkwantowej. OP_CAT umożliwia stosowanie podpisów Lamporta – schematu podpisów uznawanego za odporny na ataki komputerów kwantowych, ponieważ podpisy Lamporta wymagają jedynie możliwości generowania skrótów i łączenia wartości na stosie.
- Aktywa tokenizowane i mosty międzyłańcuchowe. Dzięki umożliwieniu tworzenia bardziej elastycznych skryptów OP_CAT mógłby wspierać emisję tokenów bezpośrednio w łańcuchach zgodnych z Bitcoinem oraz tworzenie mostów między Bitcoinem a innymi sieciami, charakteryzujących się mniejszym zapotrzebowaniem na zaufanie.
Warto tu również jasno przedstawić związane z tym kompromisy. Ta sama elastyczność, która sprawia, że OP_CAT jest przydatny we wszystkich powyższych przypadkach, jest również powodem, dla którego niektórzy programiści Bitcoina podchodzą do niego z ostrożnością. Ponieważ OP_CAT jest narzędziem ogólnego przeznaczenia, a nie stworzonym pod konkretny cel, otwiera ono coś, co programiści nazywają czasem „dużą przestrzenią projektową” – oznacza to, że trudniej jest przewidzieć wszystkie możliwe sposoby, w jakie może ono ostatecznie zostać połączone z innymi kodami operacyjnymi. Ta niepewność stanowi sedno trwającej debaty, a nie kwestię drugorzędną.
OP_CAT a OP_CTV: porównanie dwóch wiodących propozycji dotyczących protokołów
OP_CAT jest zazwyczaj omawiane w kontekście OP_CTV (OP_CheckTemplateVerify), zaproponowanego w BIP 119 przez programistę Jeremy’ego Rubina. Oba rozwiązania mają na celu zapewnienie Bitcoinowi pewnej formy możliwości zawierania umów, ale opierają się na niemal przeciwstawnych podejściach projektowych.
Różnica w praktyce sprowadza się do zakresu. OP_CTV pozwala, by wyjście transakcji było powiązane z jedną konkretną przyszłą transakcją wydatkową, obejmując takie szczegóły jak wersja, czas blokady, wyjścia i liczba wejść. Jeśli szablon jest zgodny, wydatek zostaje zrealizowany. Jeśli nie pasuje, transakcja nie zostanie zrealizowana. Ta wąska specyfikacja jest zamierzona. CTV nie jest rekurencyjne, co oznacza, że transakcja, do której się zobowiązuje, nie może sama zobowiązać się do dalszych ograniczeń w sposób tworzący trwały łańcuch ograniczeń. Zwolennicy uważają to za bezpieczniejszą i bardziej ograniczoną formę porozumienia.
OP_CAT opiera się na zupełnie odmiennej filozofii. Zamiast rozwiązywać jeden konkretny problem, dostarcza programistom elastyczny element podstawowy i pozwala im tworzyć na jego podstawie. Podczas gdy CTV jest jednym, starannie ograniczonym kodem operacyjnym zaprojektowanym z myślą o konkretnym zestawie przypadków użycia, OP_CAT jest prymitywem – operacją konkatenacji ciągów znaków na stosie – który istniał już w oryginalnym języku skryptowym Bitcoina, zanim został wyłączony w 2010 roku z powodu obaw o ataki typu denial-of-service, które nie mają już zastosowania w ramach limitów rozmiaru skryptów obowiązujących po wdrożeniu Taproot. To właśnie ta sama elastyczność pozwala OP_CAT obsługiwać rekurencyjne klauzule, w których jedno ograniczenie może powodować kolejne ograniczenie w dalszej części łańcucha – cecha, której OP_CTV celowo unika.
Czy funkcja OP_CAT działa już dzisiaj w sieci Bitcoin?
Nie w głównej sieci Bitcoina. BIP 347 osiągnął status „Complete” jako dokument specyfikacyjny, co oznacza, że sama propozycja jest gotowa i jasno zdefiniowana. Jest to jednak coś innego niż wdrożenie, które wymagałoby od szerszej społeczności Bitcoina i operatorów węzłów faktycznego uruchomienia tej zmiany poprzez soft fork.
W połowie 2026 roku OP_CAT nie jest głównym kandydatem do wprowadzenia kolejnej zmiany w mechanizmie konsensusu Bitcoina. Pozycję tę zajmuje obecnie OP_CTV wraz z OP_CHECKSIGFROMSTACK (BIP 348) – powiązanym kodem operacyjnym, który pozwala skryptowi weryfikować podpis w odniesieniu do dowolnych danych, a nie tylko do samej transakcji wydatkowej. Według najnowszy przewodnik po BIP dotyczący Bitcoina, według stanu na połowę 2026 r. głównymi kandydatami do kolejnego soft forka konsensusu są propozycje porozumień BIP 119 (OP_CHECKTEMPLATEVERIFY) oraz BIP 348 (OP_CHECKSIGFROMSTACK), które umożliwiłyby nowe możliwości skryptowe dla skarbców, fabryk kanałów oraz bardziej wydajnych protokołów warstwy drugiej, choć nie ustalono jeszcze harmonogramu aktywacji, a konsensus społeczności wciąż się kształtuje.
OP_CTV jest na bardziej zaawansowanym etapie procesu aktywacji niż OP_CAT. Programiści opublikowali konkretne parametry sygnalizacji w przypadku soft forka typu BIP9: data rozpoczęcia sygnalizacji wyznaczona na 30 marca 2026 r., roczny okres oczekiwania kończący się 30 marca 2027 r., minimalna wysokość aktywacji przewidziana na maj 2027 r. oraz próg sygnalizacji przez górników wynoszący 90% w każdym dwutygodniowym okresie trudności. Oznacza to, że CTV będzie podlegać temu samemu mechanizmowi, który aktywował Taproot w 2021 r., choć osiągnięcie progu 90% nie jest wcale gwarantowane, biorąc pod uwagę, jak kontrowersyjne pozostają propozycje dotyczące porozumień w społeczności programistów.
Nie oznacza to bynajmniej, że OP_CAT odszedł w zapomnienie. Oznacza to jedynie, że „kolejna” dyskusja na temat soft forka w 2026 roku koncentruje się obecnie na innej parze kodów operacyjnych, a dalsze losy OP_CAT – o ile w ogóle będą miały miejsce – prawdopodobnie zależą od tego, jak najpierw potoczy się debata dotycząca CTV i CSFS.
OP_CAT działa już gdzie indziej
Chociaż OP_CAT wciąż czeka na wprowadzenie do sieci głównej Bitcoina, nie pozostaje bez testów. Od lat działa on po cichu w środowisku produkcyjnym w kilku sieciach powiązanych z Bitcoinem.
- Liquid Network. W federacyjnej łańcuchu bocznym Blockstream funkcja OP_CAT była włączona od samego początku jego uruchomienia, co zapewniło szerszemu ekosystemowi Bitcoina rzeczywiste środowisko testowe na długo przed pojawieniem się BIP 347.
- Bitcoin Cash i Bitcoin SV. Obie sieci ponownie wprowadziły OP_CAT w ramach aktualizacji protokołu, a kod ten przetwarzał transakcje w tych łańcuchach bez odnotowanych przypadków wykorzystania luki związanej z samym kodem operacyjnym.
- Fraktalny Bitcoin. Jest to obecnie najbardziej aktywna sieć. Fractal to łańcuch boczny zgodny z Bitcoinem, zbudowany przy użyciu oprogramowania Bitcoin Core i połączony z siecią Bitcoin w ramach kopania scalającego (merge mining), którego sieć główna została uruchomiona 9 września 2024 r. z włączoną funkcją OP_CAT od samego początku.
Warto przyjrzeć się bliżej projektowi Fractal, ponieważ stanowi on najbardziej przejrzystą odpowiedź na pytanie: „jak to właściwie wyglądałoby w przypadku Bitcoina”. Od momentu uruchomienia Fractala nowe protokoły wykorzystują OP_CAT do tworzenia inteligentnych kontraktów opartych na oprogramowaniu Bitcoina, w tym protokół CAT, który wzbudził znaczne zainteresowanie wśród użytkowników korzystających wyłącznie z Bitcoina, a także inne powstające standardy, które rozszerzają funkcjonalność sieci za pomocą OP_CAT.
Najbardziej znanym przykładem jest CAT20 – standard tokenów zamiennych stworzony specjalnie z myślą o wykorzystaniu funkcji OP_CAT. Zgodnie z Dokumentacja własna Fractal Bitcoin, CAT20 jest w pełni weryfikowany przez górników i działa w oparciu o inteligentne kontrakty, a konkretnie o rekurencyjne klauzule, których egzekwowanie odbywa się wyłącznie za pomocą własnego języka skryptowego Bitcoina na warstwie bazowej, co odróżnia go od standardów tokenów opierających się na weryfikacji zewnętrznej lub przeprowadzanej przez strony trzecie. W praktyce oznacza to, że wdrażanie, emisja i transfer tokenu CAT20 odbywa się poprzez sekwencję operacji OP_CAT, które tworzą pojedynczy ciąg danych, który następnie zostaje zapisany bezpośrednio w łańcuchu bloków i sprawdzony przez tych samych górników zabezpieczających sieć, a nie przez oddzielną usługę indeksowania poza łańcuchem.
Historia Quantum Cats: Jak kampania memowa przyczyniła się do rozwoju OP_CAT
Większość propozycji kodów operacyjnych pozostaje w sferze list mailingowych i wątków na GitHubie. W przypadku OP_CAT było inaczej, głównie dzięki projektowi Bitcoin Ordinals o nazwie Taproot Wizards.
W styczniu 2024 roku firma Taproot Wizards wypuściła kolekcję 3 333 elementów w stylu NFT pod nazwą „Quantum Cats”, stworzoną wyłącznie w celu zdobycia poparcia społecznego dla ponownego uruchomienia OP_CAT. Quantum Cats chciało, aby OP_CAT stworzyło most bez zezwoleń, który umożliwiłby przenoszenie bitcoinów i aktywów opartych na bitcoinie do łańcuchów warstwy 2 sieci Bitcoin, gdzie mogłyby one brać udział w bardziej złożonych transakcjach. Aby w ogóle zakwalifikować się do emisji, uczestnicy musieli zapoznać się z rzeczywistą propozycją techniczną i publicznie opowiadać się za jej przywróceniem, zamieniając dość suchą dyskusję na temat BIP w kampanię społecznościową, z którą wiązały się realne stawki.
Sama kolekcja stanowiła jednocześnie praktyczną demonstrację działania funkcji łączenia. Każdy „Quantum Cat” odwołuje się do kilku oddzielnych plików, a nie do jednego statycznego obrazu, a wraz z pojawianiem się nowych plików z biegiem czasu koty ulegają zmianom, odzwierciedlając dokładnie działanie funkcji OP_CAT, która łączy ze sobą oddzielne fragmenty danych.
Kampania okazała się na tyle skuteczna, że zaowocowała znacznym finansowaniem. W 2023 roku firma Taproot Wizards pozyskała 7,5 mln dolarów, a w lutym 2025 roku przeprowadziła kolejną rundę finansowania o wartości 30 mln dolarów; oba kwoty zostały wyraźnie przeznaczone na rozwój ekosystemu OP_CAT. Współzałożyciel Udi Wertheimer opisał projekt jako skupiony na OP_CAT jako przyszłości Bitcoina, przy czym fundusze są przeznaczane zarówno na rozwój wewnętrzny, jak i na wspieranie zewnętrznych zespołów tworzących rozwiązania oparte na tym kodzie operacyjnym. Pojedyncza aukcja Quantum Cat w domu aukcyjnym Sotheby’s, „Genesis Cat”, zakończyła się wynikiem 254 000 dolarów, co podkreśla, jak wielkie znaczenie kulturowe nabrała ta kampania wokół czterobajtowego kodu operacyjnego.
To przydatne przypomnienie, że debaty techniczne dotyczące Bitcoina nie zawsze ograniczają się do kwestii technicznych. Memy, sztuka i pieniądze wielokrotnie stawały się narzędziami służącymi do poszerzenia zasięgu dyskusji na temat protokołu, a OP_CAT jest jednym z najwyraźniejszych ostatnich przykładów tego zjawiska.
Wnioski
OP_CAT wykonuje jedną prostą czynność: łączy dwa elementy danych ze stosu Bitcoina w jeden. Jego znaczenie wynika z tego, jakie możliwości mogłaby otworzyć ta pojedyncza funkcja – od bezpieczniejszych magazynów typu cold storage, przez podpisy postkwantowe, aż po tokeny natywne dla Bitcoina – gdyby społeczność Bitcoina kiedykolwiek zgodziła się przywrócić tę funkcję. Na dzień lipca 2026 r. do takiego porozumienia nie doszło. BIP 347 to gotowa specyfikacja, która w kolejce do następnego konsensusowego soft forka Bitcoina znajduje się za OP_CTV i OP_CHECKSIGFROMSTACK, nawet jeśli OP_CAT nadal działa cicho i bez żadnych incydentów w sieciach Fractal Bitcoin, Liquid i innych sieciach związanych z Bitcoinem. Niezależnie od tego, co stanie się dalej, debata wokół OP_CAT już pokazała, jak niewielki, prosty fragment kodu może przyciągnąć jednocześnie programistów, artystów i inwestorów.
