OP_CAT Ez egy olyan Bitcoin-opkód, amely a verem két adatát egyesíti egybe, és jelenleg a Bitcoin-fejlesztés egyik leghosszabb ideje tartó vitájának tárgyát képezi. A kód a Bitcoin eredeti kódjának része volt, amelyet Satoshi Nakamoto 2010-ben biztonsági aggályok miatt eltávolított, és az elmúlt néhány évben egy javasolt soft fork (BIP 347) formájában létezett, amely új kategóriájú, intelligens szerződéshez hasonló viselkedést tesz lehetővé a Bitcoinon. 2026 júliusában még nem aktív a Bitcoin főhálózatán, bár már néhány Bitcoin-hoz kapcsolódó hálózaton fut, ahol nyilvánosan, csendben terheléses tesztelés alatt áll.
Az OP_CAT megértését nem csupán a kód teszi érdekessé. Hanem a körülötte forgó szereplők is: a Bitcoin Core fejlesztői, akik arról vitáznak, hogy a változtatás biztonságos-e; egy mémeken alapuló NFT-projekt, amely több tízmillió dollárt gyűjtött össze annak visszaállításáért folytatott lobbizás céljából; valamint egy gyorsan növekvő oldallánc, amely máris bevezette a használatát. Ez az útmutató részletesen bemutatja, hogy mit csinál az OP_CAT, miért lett letiltva, mire nyithat lehetőséget, és pontosan hol tartunk ma a dolgokkal.
Használja a Multichain szolgáltatást Bitcoin.com Wallet alkalmazás, amelyben milliók bíznak, hogy biztonságosan és egyszerűen küldhessék, fogadják, vásárolhassák, eladhassák, cserélhessék, használhassák és kezelhessék a bitcoint és a kriptovalutákat.
Főbb tanulságok
- Az OP_CAT (az „operation concatenate” rövidítése) a Bitcoin veremében található két adatelemet egyetlen elemmé egyesíti. Ez a funkció teljes működése.
- A Bitcoin legkorábbi kódjában még aktív volt, majd 2010-ben Satoshi Nakamoto a szolgáltatásmegtagadási kockázat miatt letiltotta.
- A funkció visszaállítására irányuló javaslatot, a BIP 347-et Ethan Heilman és Armin Sabouri fogalmazták meg, és 2024 áprilisában kapta meg a BIP-számát.
- Az OP_CAT önmagában nem minősül megállapodásnak, de más opkódokkal kombinálva felhasználható megállapodáshoz hasonló kiadási korlátozások létrehozására, beleértve a trezorokat is.
- 2026 közepéig az OP_CAT még nem került aktiválásra a Bitcoin főhálózatán. A Bitcoin következő konszenzusos soft forkjának jelenlegi esélyesei az OP_CTV (BIP 119) és az OP_CHECKSIGFROMSTACK (BIP 348), nem pedig önmagában az OP_CAT.
- Az OP_CAT már működik a Fractal Bitcoinon – egy Bitcoin-alapú oldalláncon –, ahol a CAT20 token-szabványt támogatja, és évek óta fut a Liquid Networkön és a Bitcoin Cashen anélkül, hogy ismert lenne bármilyen biztonsági rés.
- A Taproot Wizards által létrehozott „Quantum Cats” nevű Bitcoin-NFT-projekt az OP_CAT támogatását egy mémkampánnyá alakította, amelynek keretében több mint 37 millió dollárt gyűjtöttek össze az OP_CAT-hez kapcsolódó fejlesztésekre.
Hogyan működik az OP_CAT?
Az OP_CAT megértésének legegyszerűbb módja, ha a Bitcoin szkriptrendszerét egy kis építőelemekből álló veremként képzeljük el. A Bitcoin Script – amely minden Bitcoin-tranzakció mögött álló programozási nyelv – egy veremalapú nyelv. Az adatokat a veremre helyezik, az opkódok a verem tetején lévő elemre hatnak, és az eredmény határozza meg, hogy a tranzakció érvényes-e.
Az OP_CAT az adott verem első két elemét veszi, és összefűzi őket, vagyis végükkel egymáshoz illesztve egyetlen összevont elemmé egyesíti őket, amelyet ezután visszatesz a verem tetejére. Ha a verem a „1” és a „2” értékeket tartalmazza, az OP_CAT végrehajtása mindkettőt eltávolítja, és „12”-re cseréli őket. A hivatalos specifikáció szerint a BIP 347, az OP_CAT az x1 || x2 kifejezést helyezné a veremre, ahol a kettős cső szimbólum a karakterlánc-összefűzést jelöli.
Van azonban egy fontos korlátozás. Az OP_CAT művelet sikertelen lesz, ha a verem tartalma kevesebb, mint két érték, vagy ha azok összevonásával létrejövő érték meghaladná az 520 bájtot, ami a Bitcoin szkriptelemek maximális mérete. Ez a bájtkorlát nagy szerepet játszott ennek az opkódnak a történetében, amire hamarosan visszatérünk.
Önmagában két karakterlánc összekapcsolása nem tűnik valami nagy dolognak. A Bitcoin szkriptnyelvében azonban eddig nem létezett általános célú módszer a veremre helyezett értékek egyesítésére, és ez a hiányosság korlátozta, hogy a fejlesztők mit tudnak közvetlenül a Bitcoin-tranzakciókba beépíteni. Mivel A Bitcoin Optech elmagyarázza, A Bitcoin Tapscriptből hiányzik egy általános célú módszer a verem objektumainak összekapcsolására, ami korlátozza a Tapscript kifejezőképességét, és többek között megakadályozza, hogy Merkle-fákat és egyéb hash-alapú adatstruktúrákat közvetlenül a Tapscriptben lehessen létrehozni és kiértékelni. Az OP_CAT az erre a konkrét hiányosságra javasolt megoldás.
Miért tiltották le az OP_CAT-ot 2010-ben?
Az OP_CAT a Bitcoin legelső kiadásának része volt. Satoshi Nakamoto 2010-ben eltávolította azt, több más opkóddal együtt, például az OP_MUL-lal, az OP_DIV-vel és az OP_OR-ral. A hivatalos indoklás a szolgáltatásmegtagadási kockázatra összpontosított: egy OP_CAT-ot ismétlődően használó szkript elméletileg exponenciálisan növekvő adatmennyiséget generálhatott volna, amely elég nagy ahhoz, hogy lelassítsa vagy összeomlasztassa az érvényesíteni próbáló csomópontokat.
Akkoriban nem volt szigorú korlátozás arra, hogy a Bitcoin veremében egy-egy elem milyen nagy lehet. Ez azt jelentette, hogy egy rosszindulatú szkript addig folytathatta az értékek összefűzését, amíg olyan nagy adatmennyiséget nem hozott létre, amely képes volt megbénítani a hálózatot. Az OP_CAT eltávolítása – a többi letiltott opkóddal együtt – egy konzervatív lépés volt, amely a hálózat stabilitását helyezte előtérbe a fiatal hálózat számára még nem szükséges funkcionalitással szemben.
A helyzet 2021 novemberében változott meg, amikor a Bitcoin aktiválta a Taproot frissítést. A Taproot bevezette a Tapscriptet, egy új, saját szabályrendszerrel rendelkező szkriptelési környezetet, amelynek egyik szabálya az, hogy egyetlen veremelem mérete sem haladhatja meg az 520 bájtot. Ez a bájtkorlát közvetlenül lezárja az eredeti támadási útvonalat. Egy szkript továbbra is meghívhatja az OP_CAT-ot, de soha nem tud olyan nagy értéket létrehozni, amely olyan erőforrás-kimerülési problémát okozna, amilyen miatt Satoshi 2010-ben aggódott. Ez az a technikai részlet, amely újra megnyitotta az utat az OP_CAT visszatérésének, csupán a Tapscriptre korlátozva, ahelyett, hogy a teljes Bitcoin Scriptre vonatkozna.
Az OP_CAT egy Covenant?
Nem, önmagában nem, és ez az egyik leggyakrabban félreértett szempont az OP_CAT-tal kapcsolatban. A „covenant” – a Bitcoin terminológiájában – egy olyan korlátozás, amely meghatározza, hogy egy ki nem költött tranzakciós kimenet (UTXO) a jövőben hogyan költhető el. A hagyományos Bitcoin Script csak azt tudja ellenőrizni, hogy egy kiadás jelenleg engedélyezett-e, általában az aláírás ellenőrzésével. A covenant ennél tovább megy: nem csupán azt ellenőrzi, hogy a kiadás engedélyezett-e, hanem azt is, hogy az ebből származó tranzakció megfelel-e egy meghatározott feltételrendszernek.
Az OP_CAT nem tartalmaz beépített mechanizmust a tranzakciós adatok ellenőrzésére. Az OP_CAT lehetőséget biztosít a veremre helyezett adatelemek összevonására, ami a covenantek számára csak akkor válik hasznossá, ha olyan egyéb opkódokkal párosítják, amelyek az összevont adatok alapján ellenőrzik az aláírásokat. Maga a BIP 347 egyértelműen kimondja, hogy hogy az OP_CAT – bár a Tapscriptben újraaktiválásra javasolták – nem minősül covenantnek. Pontosabb, ha építőelemként írjuk le, amely az aláírás-ellenőrző opkódokkal kombinálva felhasználható a covenant-szerű viselkedés emulálására.
Ez azért fontos, mert az OP_CAT rugalmassága pontosan az, ami egyszerre teszi érdekesé és ellentmondásossá. Bár az OP_CAT önmagában nem minősül covenantnek, a Schnorr-aláírások működésének egy sajátossága miatt képes a covenantek működését utánozni. A CheckSigFromStack (CSFS) nevű opkóddal kombinálva – amely az aláírást nem csupán a tranzakcióval, hanem tetszőleges adatokkal is összehasonlítja – az OP_CAT felhasználható olyan kiadási korlátozások létrehozására, amelyekhez a kifejezetten egyezményekhez tervezett opkódok is szolgálnak.
Mire lehetne használni az OP_CAT-ot?
Mivel az OP_CAT nem szűk hatókörű funkció, hanem általános célú alapelem, a fejlesztők számos alkalmazási lehetőséget javasoltak hozzá. A leggyakrabban emlegetettek a következők:
- Boltozatok. A „vault” egy olyan típusú megállapodás, amely több lépést igényel – gyakran különálló tranzakciók és blokkok keretében –, mielőtt a pénzeszközök átutalásra kerülhetnek. Ez beépített késleltetést eredményez, amely időt biztosít a tulajdonosnak arra, hogy észrevegye és megakadályozza a jogosulatlan kiadásokat, javítva ezzel a hidegtárolási és a megosztott letéti rendszerek működését.
- Egyértelmű szerződések. Ezek szankcionálhatják a fizetési csatornában – például a Lightning Networkben – azt a felet, amely elavult vagy hamis csatornaállapotot próbál közzétenni, ezáltal erősítve a láncon kívüli fizetési rendszerek biztonságát.
- Három aláírás. Az OP_CAT lehetővé teszi olyan kompakt, több aláírással rendelkező szkriptek használatát, amelyek mérete az aláírók számával csupán logaritmikusan növekszik; ez azt jelenti, hogy egy 1 kilobájtnál kisebb tranzakció elméletileg több millió nyilvános kulcsra vonatkozó felhasználási feltételeket is támogatni tud.
- Merkle-fa felépítése és ellenőrzése. Mivel a Merkle-fa felépítése és ellenőrzése alapvetően az értékek összefűzését és hash-elését igényli, az OP_CAT biztosítja a Bitcoin Script számára azt a hiányzó elemet, amely ehhez natív módon szükséges.
- Posztkvantum-jellegzetességek. Az OP_CAT lehetővé teheti a Lamport-aláírások használatát, amely aláírási rendszer a kvantumszámítógépek támadásainak ellenállónak tekinthető, mivel a Lamport-aláírásokhoz csupán a veremre helyezett értékek hash-elésére és összefűzésére van szükség.
- Tokenizált eszközök és láncok közötti hidak. Az OP_CAT azáltal, hogy kifejezőbb szkripteket tesz lehetővé, támogatná a tokenek közvetlen kibocsátását a Bitcoin-kompatibilis láncokon, valamint a Bitcoin és más hálózatok közötti, a bizalomigényt minimalizáló hídokat.
Érdemes itt is egyértelműen megfogalmazni a kompromisszumokat. Ugyanaz a rugalmasság, amely az OP_CAT-ot a fenti esetek mindegyikében hasznossá teszi, az is, ami miatt egyes Bitcoin-fejlesztők óvatosan viszonyulnak hozzá. Mivel az OP_CAT általános célú, és nem egy konkrét célra lett kifejlesztve, megnyitja azt, amit a fejlesztők néha „széles tervezési térnek” neveznek, vagyis nehezebb előre megjósolni, hogy milyen módon kombinálható majd más opkódokkal. Ez a bizonytalanság a jelenlegi vita középpontjában áll, nem pedig egy mellékes kérdés.
OP_CAT és OP_CTV: A két vezető covenant-javaslat összehasonlítása
Az OP_CAT-ról általában az OP_CTV-vel (OP_CheckTemplateVerify) együtt szokták beszélni, amelyet Jeremy Rubin fejlesztő javasolt a BIP 119-ben. Mindkettő célja, hogy a Bitcoin számára valamilyen formában szerződéses funkciókat biztosítson, de tervezési megközelítésük szinte egymás ellentéte.
A gyakorlati különbség a hatályban rejlik. Az OP_CTV lehetővé teszi, hogy egy tranzakció kimenete pontosan egy jövőbeli kiadási tranzakcióhoz legyen kötve, amely magában foglalja a verziót, a locktime-ot, a kimeneteket és a bemenetek számát. Ha a sablonnak megfelel, a kiadás végbemegy. Ha nem felel meg, akkor nem. Ez a szűk körűség szándékos. A CTV nem rekurzív, vagyis az a tranzakció, amelyhez kötődik, maga nem köthető további korlátozásokhoz oly módon, hogy állandó korlátozási láncot hozzon létre. A támogatók ezt a megállapodás biztonságosabb, jobban körülhatárolt formájának tartják.
Az OP_CAT éppen ellenkező filozófiát követ. Ahelyett, hogy egy konkrét problémát oldana meg, rugalmas alapelemet biztosít a fejlesztőknek, és lehetővé teszi számukra, hogy erre építsenek. Míg a CTV egy gondosan körülhatárolt opkód, amelyet egy konkrét felhasználási esetek körének lehetővé tételére terveztek, addig az OP_CAT egy primitív, a veremre vonatkozó karakterlánc-összefűzés, amely már az eredeti Bitcoin szkriptnyelvben is megtalálható volt, mielőtt 2010-ben letiltották volna a szolgáltatásmegtagadásra vonatkozó aggályok miatt – amelyek a Taproot utáni szkriptméret-korlátozások mellett már nem érvényesek. Ugyanez a rugalmasság teszi lehetővé az OP_CAT számára a rekurzív kikötések támogatását, ahol egy korlátozás később egy másik korlátozást eredményezhet – ez egy olyan tulajdonság, amelyet az OP_CTV szándékosan elkerül.
Működik ma az OP_CAT a Bitcoin hálózatán?
Nem a Bitcoin főhálózatán. A BIP 347 specifikációs dokumentumként elérte a „Complete” státuszt, ami azt jelenti, hogy maga a javaslat elkészült és pontosan meghatározott. Ez azonban nem azonos a bevezetéssel, amelyhez szükség lenne arra, hogy a szélesebb Bitcoin-közösség és a csomópont-üzemeltetők egy soft fork révén ténylegesen aktiválják azt.
2026 közepén az OP_CAT már nem a legesélyesebb jelölt a Bitcoin következő konszenzus-változására. Ezt a pozíciót jelenleg az OP_CTV tölti be az OP_CHECKSIGFROMSTACK (BIP 348) mellett, amely egy kapcsolódó opkód, amely lehetővé teszi a szkript számára, hogy az aláírást ne csak a kiadási tranzakcióhoz, hanem tetszőleges adatokhoz is ellenőrizze. Egy A Bitcoin legújabb BIP-referencia-útmutatója, 2026 közepétől a következő konszenzusos soft fork legesélyesebb jelöltjei a BIP 119 (OP_CHECKTEMPLATEVERIFY) és a BIP 348 (OP_CHECKSIGFROMSTACK) szövetségi javaslatok, amelyek új szkriptelési lehetőségeket biztosítanának a trezorok és a csatorna-gyárak számára, valamint hatékonyabb 2. rétegű protokollokat tennének lehetővé, bár az aktiválás időpontját még nem határozták meg, és a közösségi konszenzus még kialakulóban van.
Az OP_CTV az aktiválási folyamatban már előrébb tart, mint az OP_CAT. A fejlesztők közzétették konkrét jelzési paraméterek egy BIP9-típusú soft fork esetében: a jelzés kezdőnapja 2026. március 30., az egyéves időtúllépési időszak 2027. március 30-án zárul, a minimális aktiválási magasság 2027. május körül várható, és a bányászok jelzésének küszöbértéke minden kéthetes nehézségi periódusban 90%. Ezzel a CTV ugyanazt a mechanizmust követi, amely 2021-ben aktiválta a Taprootot, bár a 90%-os küszöb elérése korántsem garantált, tekintve, hogy a covenant-javaslatok továbbra is vitatottak a fejlesztői közösségen belül.
Ez egyáltalán nem jelenti azt, hogy az OP_CATnak vége lenne. Azt jelenti, hogy a 2026-ban esedékes „következő” soft fork körüli vita jelenleg egy másik opkódpárra összpontosul, és az OP_CAT jövője – ha egyáltalán lesz neki – valószínűleg attól függ, hogy előbb hogyan alakul a CTV és a CSFS körüli vita.
Az OP_CAT máshol már működik
Bár az OP_CAT még a Bitcoin főhálózatára vár, nem marad tesztelés nélkül. Évek óta csendben működik termelési környezetben néhány Bitcoin-kapcsolódó hálózaton.
- Liquid Network. A Blockstream szövetségi oldalláncában az OP_CAT már a bevezetése óta engedélyezve van, így a szélesebb értelemben vett Bitcoin-ökoszisztémának már évekkel a BIP 347 megjelenése előtt valós körülmények között működő tesztkörnyezetet biztosított.
- Bitcoin Cash és Bitcoin SV. Mindkét hálózat a protokollfrissítések során újra bevezette az OP_CAT-ot, és azóta is feldolgozza a tranzakciókat ezeken a láncokon anélkül, hogy az opkódhoz közvetlenül kapcsolódó, dokumentált biztonsági rés merült volna fel.
- Fraktál Bitcoin. Ez a jelenleg legaktívabb hálózat. A Fractal egy Bitcoin-kompatibilis oldallánc, amelyet a Bitcoin Core saját szoftverével hoztak létre, és amely merge-mining módszerrel bányászik a Bitcoinnal együtt; a Fractal 2024. szeptember 9-én indította el főhálózatát, az OP_CAT funkciót pedig az első naptól kezdve engedélyezve tartotta.
A Fractal-t érdemes közelebbről is megvizsgálni, mivel ez adja a legegyértelműbb választ arra a kérdésre, hogy „ez valójában hogyan nézne ki a Bitcoin hálózatán”. A Fractal elindítása óta új protokollok használták ki az OP_CAT-ot a Bitcoin-szoftveren alapuló intelligens szerződések létrehozására, ideértve a CAT Protocol-t is, amely jelentős érdeklődést váltott ki a Bitcoin-felhasználók körében, valamint más, kialakulóban lévő szabványokat, amelyek az OP_CAT segítségével bővítik a hálózat funkcionalitását.
A legjellemzőbb példa a CAT20, egy olyan helyettesíthető token-szabvány, amelyet kifejezetten az OP_CAT előnyeinek kihasználására hoztak létre. A A Fractal Bitcoin saját dokumentációja, A CAT20-at a bányászok teljes mértékben validálják, és intelligens szerződések, konkrétan rekurzív megállapodások alapján működik, amelyek végrehajtását teljes egészében a Bitcoin saját szkriptnyelve biztosítja az alapszinten, ami megkülönbözteti azokat a token-szabványoktól, amelyek külső vagy harmadik fél általi validációra támaszkodnak. A gyakorlatban ez azt jelenti, hogy a CAT20-token bevezetése, kibocsátása és átruházása egy sor OP_CAT-műveleten keresztül történik, amelyek egyetlen adatsort alkotnak, amelyet ezután közvetlenül a blokkláncra írnak fel, és a hálózatot biztosító bányászok ellenőrzik, nem pedig egy különálló, láncon kívüli indexelési szolgáltatás.
A Quantum Cats története: Hogyan lendítette előre az OP_CAT-et egy mémkampány
A legtöbb opkód-javaslat a levelezőlistákra és a GitHub-szálakra korlátozódik. Az OP_CAT esetében ez nem így volt, elsősorban a Taproot Wizards nevű Bitcoin Ordinals-projektnek köszönhetően.
2024 januárjában a Taproot Wizards elindította a „Quantum Cats” nevű, 3 333 darabos NFT-stílusú gyűjteményt, amelynek kizárólagos célja az volt, hogy nyilvános támogatást szerezzen az OP_CAT újraaktiválásához. A Quantum Cats azt szerette volna, ha az OP_CAT létrehoz egy engedélyezés nélküli hidat, amelyen keresztül a bitcoin és a bitcoin-alapú eszközök átkerülhetnek a Bitcoin 2. rétegű láncaiba, ahol összetettebb kereskedésben vehetnek részt. Ahhoz, hogy egyáltalán jogosultak legyenek a kibocsátásra, a résztvevőknek meg kellett ismerniük a tényleges technikai javaslatot, és nyilvánosan ki kellett állniuk annak visszaállítása mellett, így egy meglehetősen száraz BIP-vitát valódi tétet hordozó közösségi kampánnyá alakítva.
Maga a gyűjtemény egyben a láncolás működésének szemléltetése is volt. Minden Quantum Cat egyetlen statikus kép helyett több különálló fájlra hivatkozik, és ahogy az új fájlok idővel megjelennek, a macskák is változnak, pontosan tükrözve az OP_CAT működését, amely különálló adatdarabokat fűz össze.
A kampány olyan jól sikerült, hogy komoly finanszírozást eredményezett. A Taproot Wizards 2023-ban 7,5 millió dollárt gyűjtött össze, majd 2025 februárjában egy 30 millió dolláros finanszírozási kör következett; mindkét összeget kifejezetten az OP_CAT ökoszisztéma fejlesztésére szánták. Udi Wertheimer társalapító úgy jellemezte a projektet, hogy az az OP_CAT-ra, mint a Bitcoin jövőjére összpontosít, és a finanszírozás mind a házon belüli fejlesztésre, mind pedig az opkódra építő külső csapatok támogatására fordítódik. A Sotheby’s-nél megrendezett egyetlen Quantum Cat-árverésen a „Genesis Cat” 254 000 dollárért kelt el, ami jól alátámasztja, milyen nagy kulturális jelentőséget nyert a kampány egy négy bájtos opkód körül.
Ez jól szemlélteti, hogy a Bitcoin technikai vitái nem mindig maradnak pusztán technikai jellegűek. A mémek, a művészet és a pénz már többször is eszközzé váltak ahhoz, hogy a protokollról szóló beszélgetéseket szélesebb körben is napirendre tűzzék, és az OP_CAT ennek a tendenciának az egyik legszembetűnőbb közelmúltbeli példája.
Következtetés
Az OP_CAT egy egyszerű feladatot lát el: a Bitcoin veremében található két adatot egyesíti egybe. A jelentőségét az adja, hogy ez az egyetlen funkció számtalan lehetőséget nyithat meg – a biztonságosabb hidegtárolóktól kezdve a posztkvantum aláírásokon át a Bitcoin-natív tokenekig –, amennyiben a Bitcoin-közösség valaha is úgy dönt, hogy újra bevezeti. 2026 júliusában még nem született ilyen megállapodás. A BIP 347 egy kész specifikáció, amely az OP_CTV és az OP_CHECKSIGFROMSTACK mögött sorakozik a Bitcoin következő konszenzusos soft forkjának sorában, miközben az OP_CAT továbbra is csendesen és incidensek nélkül fut a Fractal Bitcoinon, a Liquid-en és más Bitcoin-kapcsolódó hálózatokon. Bármi is történjen ezután, az OP_CAT körül zajló vita máris megmutatta, hogy egy kicsi, egyszerű kódrészlet hogyan képes egyszerre magához vonzani fejlesztőket, művészeket és befektetőket.
