Mi az a Bitcoin Script nyelv?

A Bitcoin Script az a programozási nyelv, amely a Bitcoin-hálózat minden tranzakcióját irányítja. Ez egy egyszerű, veremalapú nyelv, amely pontosan meghatározza azokat a feltételeket, amelyek mellett a bitcoin elkölthető, és a hálózat minden teljes csomópontja futtatja azt minden egyes tranzakció érvényesítésekor. Enélkül a Bitcoin csupán egy számokból álló főkönyv lenne, amelyben nincs olyan mechanizmus, amely biztosítaná, hogy ki mihez jogosult.

A legtöbb felhasználó soha nem találkozik közvetlenül a Bitcoin szkriptnyelvével. A pénztárcáik láthatatlanul kezelik ezt. De minden alkalommal, amikor BTC-t küldesz vagy fogadsz, két kis program fut egyszerre több ezer számítógépen, ellenőrizve, hogy teljesültek-e a kiadási feltételek. Ha megérted, hogyan működik ez, sok mindent megérthetsz arról, hogy miért épül fel a Bitcoin így, és mire képes, illetve mire nem képes az Ethereumhoz hasonló platformokhoz képest.

Ez a cikk bemutatja a Bitcoin Script működését, áttekinti a rendszer által támogatott főbb tranzakciótípusokat, elmagyarázza a Taproot frissítést, amely 2021-ben modernizálta a szkriptréteget, valamint ismerteti, hogy 2026 júniusában hol tart a „covenant” opkóddal kapcsolatos vita.

Kezelje biztonságosan a Bitcoinjait az önkezelés segítségével Bitcoin.com Wallet alkalmazás.

Főbb tanulságok

• A Bitcoin Script egy, a Bitcoin-protokollba beépített, veremalapú programozási nyelv, amely meghatározza azokat a feltételeket, amelyek mellett bármely bitcoin-kimenet felhasználható.
• Minden Bitcoin-tranzakció két szkriptet tartalmaz: egy, a címzett által beállított zároló szkriptet (ScriptPubKey) és egy, a fizető fél által megadott feloldó szkriptet (ScriptSig). Ahhoz, hogy a tranzakció érvényes legyen, mindkettőnek sikeresen le kell futnia.
• A Bitcoin Script szándékosan nem Turing-teljes. Nincsenek benne ciklusok, a futtatások között nincs állandó állapot, és a szkript méretére szigorú korlátozások vonatkoznak. Ez garantálja, hogy minden szkript biztosan befejeződjön, ami biztonsági funkció, nem pedig korlátozás.
• A szkriptnyelv öt fő formátumon keresztül fejlődött: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) és Taproot (P2TR); ezek mindegyike kibővítette a lehetőségeket, miközben visszafelé kompatibilis maradt.
• A Taproot (2021. november) bevezette a Schnorr-aláírásokat, a magánélet védelmét szolgáló MAST-alapú kiadási útvonalakat, valamint a Tapscriptet, egy továbbfejlesztett szkriptnyelvet, amely beépített mechanizmussal rendelkezik a jövőbeli frissítések zökkenőmentesebb végrehajtása érdekében.
• A Bitcoin Scriptre épülő, valós felhasználási példák közé tartoznak a többaláírásos pénztárcák, az időzített tranzakciók, a Hash Time-Locked Contracts (a Lightning alapja), az escrow-szolgáltatások és a Discreet Log Contracts.
• Az Ethereum intelligens szerződéseivel ellentétben a Bitcoin Script állapotmentes: minden szkript teljesen elszigetelten fut, és nincs tudomása más tranzakciókról. Ez egy tudatos architektúrai döntés.
• A Bitcoin Script fejlesztésének legaktívabb területe 2026-ban a covenant opkódok, különösen az OP_CTV (BIP-119) és az OP_CAT (BIP-347), amelyek lehetővé tennék a szkriptek számára, hogy meghatározzák, milyen formában kell megjelenniük a kiadási tranzakcióknak. Egyik sem került még aktiválásra a mainneten.

Mi az a Bitcoin Script?

A Bitcoin Script egy veremalapú, állapotmentes szkriptnyelv, amely a Bitcoin-protokollba van beépítve. A Bitcoin-hálózaton minden tranzakciós kimenet tartalmaz egy zároló szkriptet (ScriptPubKey néven), amely meghatározza a pénzeszközök felhasználásának feltételeit. Aki fel akarja használni ezeket a pénzeszközöket, annak be kell nyújtania egy feloldó szkriptet (ScriptSig néven, illetve SegWit- és Taproot-tranzakciók esetén a tanúadatokat), amely teljesíti ezeket a feltételeket.

A nyelv szerkezetét a Forth-tól veszi át, egy minimalista, veremalapú programozási nyelvtől, amelyet az 1960-as években fejlesztettek ki. A Forth-hoz hasonlóan a Bitcoin Script is balról jobbra olvas, egy veremnek nevezett adatstruktúrán működik, és a fordított lengyel jelölést (RPN) használja, amelyben az operátorok az operandusok után következnek, nem pedig előttük. Egyszerre egy utasítást hajt végre, nincsenek benne ciklusok, és a végrehajtások között nem tárol állandó memóriát.

Ez az utolsó pont az, amellyel a legtöbb ember először találkozik, amikor a Bitcoin Scriptet protokollszinten ismeri meg: a nyelv szándékosan nem Turing-teljes. Egy Turing-teljes nyelv elegendő idő és erőforrás rendelkezésre állása esetén bármilyen számítást elvégezhet. A Bitcoin Script tervezésénél fogva erre nem képes, és ennek a döntésnek az okai nagyban befolyásolják a hálózat működését.

Hogyan működik a Bitcoin Script: a veremmodell

Ahhoz, hogy megértsük, hogyan működik a Bitcoin Script, ismernünk kell a verem működését. A verem egy olyan adatstruktúra, amely a „Last-In, First-Out” (LIFO) elv szerint működik. Képzeljünk el egy tányérhalmot: csak a tetejéről lehet hozzáadni vagy elvenni. A Bitcoin Scriptben az adatokat a veremre tolják, és az opkódok (műveleti kódok) a verem tetején lévő elemet manipulálják.

Amikor egy Bitcoin-csomópont érvényesít egy tranzakciót, egymás után két szkriptet futtat:

1. A feloldó szkript (ScriptSig vagy tanú) amelyet az érméket elköltő személy biztosít. Ez az adatokat – általában egy digitális aláírást és egy nyilvános kulcsot – a veremre helyezi.
2. A zároló szkript (ScriptPubKey) amely a kimenethez kapcsolódik. Ez olyan opkódokat tartalmaz, amelyek a verem adataival dolgoznak, és ellenőrzik, hogy a kiadási feltételek teljesülnek-e.

Ha a szkript hiba nélkül fut le, és a végén nem nulla értéket (TRUE) hagy a veremre, akkor a tranzakció érvényes. Ha hiba történik, vagy FALSE értéket hagy hátra, a csomópont elutasítja a tranzakciót, és az soha nem kerül be egy blokkba sem.

Ez a végrehajtás teljesen állapotmentes. A szkript nem rendelkezik információval a korábbi tranzakciókról, nem ismeri az aktuális egyenlegeket, és a szkript futásának befejezése után semmilyen adat nem marad meg. Minden szkript minden alkalommal a nulláról indul, teljesen elkülönítve.

Lépésről lépésre: egy szabványos P2PKH tranzakció

A Pay-to-Public-Key-Hash (P2PKH) a Bitcoin eredeti tranzakciótípusa, amelyet 2009 óta használnak. A P2PKH-címek „1.”-gyel kezdődnek. Íme, hogyan néznek ki a ScriptPubKey és a ScriptSig a gyakorlatban:

Feloldó szkript (ScriptSig):

<aláírás> <nyilvános kulcs>

Záró szkript (ScriptPubKey):

OP_DUP OP_HASH160 <nyilvános kulcs hash-értéke> OP_EQUALVERIFY OP_CHECKSIG

Amikor a csomópont összefűzi és mindkettőt egyszerre végrehajtja, a veremműveletek lépésről lépésre zajlanak:

• A ScriptSig aláírása és nyilvános kulcsa felkerül a veremre
• OP_DUP a nyilvános kulcsot a verem tetejére másolja
• OP_HASH160 kiszámítja az ismétlődő elem hash-értékét (először SHA-256, majd RIPEMD-160), ami egy 20 bájtos hash-értéket eredményez
• A zároló szkript nyilvános kulcsának hash-értéke felkerül a veremre
• OP_EQUALVERIFY ellenőrzi, hogy a két hash-érték egyezik-e. Ha nem, a végrehajtás leáll, és a tranzakció sikertelen lesz.
• OP_CHECKSIG ellenőrzi, hogy az aláírás érvényes-e a nyilvános kulcsra

Ha minden lépés sikeresen lezajlik, a verem TRUE értékkel zárul, és a pénzeszközöket felszabadítják. Az egész folyamat milliszekundumok alatt lezajlik, és a hálózat minden csomópontján azonos módon fut.

A Bitcoin opkódjainak magyarázata

A Bitcoin opkódok azok az egyedi parancsok, amelyekből egy szkript felépül. Mindegyik egy bájt hosszú, így összesen 256 lehetséges opkód-hely áll rendelkezésre. Ezek közül jelenleg körülbelül 80 aktív a mainneten. A többi vagy fenntartva van, vagy letiltva, vagy a Tapscript bevezetésével megjelenő OP_SUCCESS előrekompatibilitási mechanizmushoz van rendelve.

Az opkódok több kategóriába sorolhatók:

• Adat-push opkódok olyan értékeket, mint a nyilvános kulcsok, az aláírások és a hash-értékek, a veremre helyezni
• Aritmetikai utasításkódok összeadási, kivonási és összehasonlítási műveleteket hajthat végre. Fontos megjegyezni, hogy a szorzás és az osztás nem elérhető.
• Kriptográfiai opkódok ide tartoznak az OP_SHA256, az OP_HASH160 és az OP_SHA1 hash-funkciók, valamint az OP_CHECKSIG az aláírás-ellenőrzéshez
• Áramlásszabályozó opkódok feltételes logika engedélyezése: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Halommanipulációs opkódok ide tartozik az OP_DUP (a legfelső elem másolása), az OP_DROP (a legfelső elem eltávolítása) és az OP_SWAP (a két legfelső elem cseréje)

Satoshi Nakamoto 2010-ben több opkódot is letiltott, miután sebezhetőségeket fedeztek fel azok eredeti megvalósításában. Ezek közé tartozik az OP_CAT (két veremelem összefűzése), az OP_MUL (szorzás) és az OP_DIV (osztás). Ezek hiánya tartós következményekkel járt a Bitcoin Script kifejezőképességére nézve, és a 2026-ban leghevesebben vitatott Bitcoin-frissítési javaslatok közül több is azzal foglalkozik, hogy ezek közül néhányat újra engedélyezzenek-e.

A hexadecimális értékeket és leírásokat is tartalmazó teljes opkód-referencia megtalálható a A Bitcoin Wiki „Script” oldala ez a hiteles forrás.

Miért jelent előnyt a nem-Turing-teljesség?

A szokásos magyarázat szerint a Bitcoin Scriptben nincsenek ciklusok, így a szkriptek végrehajtása garantáltan befejeződik, és ezáltal a hálózat védve van a végtelen végrehajtástól. Ez helytálló, de nem adja vissza a lényeget.

A mélyebb érvelés a támadási felületre vonatkozik. Egy Turing-teljes nyelv tetszőleges számításokat képes kifejezni. Ez a kifejezőképesség egyben az a tér is, ahol a hibák lakoznak. Az Ethereum Solidity nyelve a történelem legdrágább szoftveres sebezhetőségeinek néhányát okozta. A 2016-os DAO-hack egy intelligens szerződés reentrancy hibáját használta ki, és az akkori árakon számolva körülbelül 60 millió dolláros veszteséget okozott, ami végül az Ethereum-hálózat vitatott hard forkjához vezetett. A tágabb DeFi-ökoszisztémában több éven át több száz millió dollár tűnt el az intelligens szerződések kihasználása révén.

A Bitcoin Script szerkezetileg lehetetlenné teszi ezt a típusú támadást. Nem lehet olyan Bitcoin-szkriptet írni, amely más szkripteket hív meg, egy feltétel megváltozásáig ciklusban fut, vagy tranzakciók között állapotot tárol. Minden szkript egy korlátozott, véges, ellenőrizhető program. A szkript maximális mérete 10 000 bájt. A nem „push” típusú opkódok maximális száma szkriptenként 201. A validátor a szkript futtatása előtt mindig kiszámíthatja a legrosszabb esetben várható végrehajtási költséget.

Egy olyan hálózat esetében, amelynek értéke több százmilliárd dollárra rúg, ez a kiszámíthatóság többet ér, mint az a rugalmasság, amiről lemondunk. Az Ethereum a gázlimitek segítségével oldja meg a korlátlan számítási problémát: minden végrehajtott opkódért díjat számol fel a felhasználóknak, és leállítja azokat a szkripteket, amelyeknél elfogy a költségkeret. Ez működik, de saját komplexitást és hibalehetőségeket is magával hoz. A Bitcoin tervezésénél fogva teljesen elkerüli ezt a problémát.

Ugyanakkor a „nem Turing-teljes” kifejezés nem jelenti azt, hogy „nem képes bonyolult logikai műveletekre”. A Bitcoin Script támogatja a több fél részvételét igénylő kifizetési feltételeket, az időalapú feltételeket, a hash-előképek feltárását, valamint ezek kombinációit is. A Lightning Network, amely naponta több millió fizetést bonyolít le, teljes egészében a Bitcoin Script alapelemére épül.

Skripttípusok: A P2PKH-tól a Taproot-ig vezető fejlődés

A Bitcoin szkriptrétege 2009 óta jelentősen fejlődött: minden frissítés új tranzakciós formátumot vezetett be, miközben visszafelé kompatibilis maradt az összes korábbi verzióval.

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

Az eredeti formátum, amelyet az első Bitcoin-tranzakciókban használtak, beleértve Satoshi Hal Finneynek a 170. blokkban teljesített kifizetését is. A pénzeszközöket közvetlenül egy teljes nyilvános kulcshoz kötötték, nem pedig annak hash-értékéhez. Manapság az új tranzakciókban ritkán használják, mivel a költés előtt a nyilvános kulcsot a blokkláncon nyilvánosságra hozza, ami gyengébb biztonsági megoldásnak számít, mint a kulcs előzetes hash-elése.

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

Több mint egy évtizede a szabványos formátum. A P2PKH a pénzeszközöket nem magához a nyilvános kulcshoz, hanem annak hash-értékéhez köti, így a nyilvános kulcsot a kiadás pillanatáig titokban tartja, rövidebb, 20 bájtos címet eredményez, és minden „1”-gyel kezdődő cím alapját képezi. Az Unchained láncon belüli adatai szerint (2026. április) a P2PKH-címek jelenleg a kibányászott bitcoin-készlet mintegy 43%-át tárolják.

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

A 2012. április 1-jén soft fork révén bevezetett P2SH a bonyolult kifizetési szkriptek terhét a feladóról a címzettre hárította át. Ahelyett, hogy a kimenetbe egy teljes zárolási szkriptet ágyazna be, a P2SH kimenete egy „beváltási szkript” 20 bájtos hash-értékére vonatkozó kötelezettségvállalást ad ki. A teljes szkript csak akkor kerül nyilvánosságra, amikor a coinokat elköltenek. Ezzel a multisig a hétköznapi felhasználók számára is praktikus megoldássá vált: egy 2-ből-3-as multisig-konfiguráció esetén már nem volt szükség arra, hogy a fizetéskor mindhárom nyilvános kulcs látható legyen a feladó számára. A P2SH-címek „3.”-mal kezdődnek.

A P2SH-ellenőrzés protokollszintű működésének részletes leírásához, A developer.bitcoin.org tranzakciós útmutatója lépésről lépésre végigvezeti a „redeem script” mechanizmusát.

P2WPKH és P2WSH (natív SegWit, 2017, BIP 141)

A 2017 augusztusában, a 481 824. blokknál aktivált Segregated Witness (SegWit) a aláírási adatokat a tranzakció főtestéből egy különálló tanúsító struktúrába helyezte át. A tanúsító adatokra 75%-os súlycsökkentés vonatkozik, ami jelentősen olcsóbbá teszi a SegWit-tranzakciókat. Egy szabványos, egy bemenetű, két kimenetű P2WPKH tranzakció súlya körülbelül 141 virtuális bájt, míg az azzal egyenértékű P2PKH tranzakcióé 226 vbyte, a A Spark bitcoin-címtípusok elemzése 2026 márciusától. A SegWit megoldotta a tranzakciók alakíthatóságának problémáját is, ami a Lightning Network bevezetésének előfeltétele volt. A natív SegWit-címek „bc1q.”-vel kezdődnek.

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

A Taproot 2021 novemberében, a 709 632. blokknál lépett életbe, és a SegWit óta a Bitcoin szkriptrétegének legjelentősebb frissítése. Bevezette a Schnorr-aláírásokat, egy új, MAST-t támogató kimeneti típust, valamint a Tapscript nevű továbbfejlesztett szkriptnyelvet. A Taproot-címek „bc1p.”-vel kezdődnek.

Taproot és Tapscript: Hogyan változott a Bitcoin szkriptnyelv 2021-ben

A Taproot nem egyetlen változtatás. Három, egymással összehangoltan kidolgozott és egyidejűleg életbe léptetett Bitcoin-fejlesztési javaslatról van szó.

BIP 340: Schnorr-aláírások

A Bitcoin eredetileg az ECDSA-t (Elliptic Curve Digital Signature Algorithm) használta. Satoshi részben azért választotta ezt, mert a Schnorr-aláírások akkoriban szabadalmi védelem alatt álltak. Ez a szabadalom 2008-ban lejárt, és a Taproot végül bevezette a Schnorr-aláírásokat a protokollba.

A Schnorr-aláírások mérete 64 bájt, míg az ECDSA-é 71–73 bájt. Ennél is fontosabb, hogy támogatják a kulcs-összevonást egy MuSig2 nevű rendszer segítségével. A kulcs-összevonás lehetővé teszi, hogy több aláíró egyesítse egyedi kulcsait és aláírásait egyetlen összevont kulcsba és aláírásba, amely a blokkláncon belül megkülönböztethetetlen egy szokásos, egyetlen aláírással rendelkező fizetéstől. Egy 2-ből-3-as multisig pénztárca, amely a Taproot kooperatív kulcsútvonalán keresztül hajt végre kifizetést, a blokkláncon teljesen ugyanúgy néz ki, mint egy szokásos fizetés. Ez valódi adatvédelmi előnyt jelent mindenki számára, aki bonyolult letéti megállapodás keretében tartja a bitcoinjait.

BIP 341: Pay-to-Taproot és MAST

A P2TR bevezet egy új kimeneti típust, amely két kifizetési útvonalat tartalmaz:

• A kulcsútvonal a tranzakciót Schnorr-aláírással bonyolítják le, amelyet akkor alkalmaznak, ha minden fél egyetért, és a legegyszerűbb, legolcsóbb megoldást választja
• A a szkript elérési útja a MAST (Merkelized Abstract Syntax Tree, amely a koncepció Taproot-megvalósítása) használatával történő kiadás

A MAST lehetővé teszi, hogy egy adott kimenet egy Merkle-gyökön keresztül több kiadási szkriptekből álló fához kapcsolódjon. Kiadáskor a láncon csak az a konkrét feltétel kerül nyilvánosságra, amelyet ténylegesen alkalmaztak. A fa összes többi lehetséges kiadási útvonala véglegesen rejtve marad. Egy olyan felhasználó esetében, aki összetett kiadási szabályzatot állított be – például: „Normál módon költhetek, vagy három megbízott közül kettő hat hónap elteltével költhet, vagy egy helyreállítási kulcs két év elteltével költhet” –, a blokkláncon mindig csak az a útvonal jelenik meg, amely ténylegesen végrehajtásra kerül.

A Spark által 2026 márciusában idézett Glassnode-adatok szerint 2024-re a Taproot részesedése a bitcoin-tranzakciókban körülbelül 42%-ra nőtt, ami elsősorban az Ordinals és a BRC-20-as bejegyzéseknek köszönhető. Azóta ez az arány a piaci körülmények függvényében ingadozott, de az infrastruktúra mára a főbb pénztárcákban és tőzsdéken egyaránt szabványosnak számít. A Bitcoin Optech Taproot témájú oldala nyomon követi a Taproot kapcsán folyó protokollfejlesztést.

BIP 342: Tapscript

A Tapscript a Taproot rendszeren belüli script-path tranzakciókhoz használt, továbbfejlesztett szkriptnyelv. A legtöbb opkódját megosztja a hagyományos Bitcoin Script-tel, de számos lényeges változtatást tartalmaz:

• OP_CHECKMULTISIG és OP_CHECKMULTISIGVERIFY elavultak. A régi multisig opkódnak volt egy olyan sajátossága, amely miatt megoldásként egy álelemet kellett a veremre helyezni. A Tapscript ezt eltávolítja, és helyette a következőt használja: OP_CHECKSIGADD, amely a Schnorr-aláírásokat egyenként ellenőrzi, és számlálja azok számát. A küszöbérték-alapú többaláírásos rendszerek így egyszerűbbé válnak, és végrehajtásuk is olcsóbbá válik.
• A MAST-levelenkénti szkriptméret-korlátozásokat eltávolítottuk. A Taproot-ágon belüli egyes szkriptek mérete tetszőleges lehet.
• OP_SUCCESS opkódok ezek jelentik a leginkább jövőbe mutató változást. A hagyományos Scriptben egy meg nem határozott opkód találkozása a szkript meghiúsulását eredményezi. A Tapscriptben az OP_SUCCESS tartományba tartozó opkódok feltétel nélkül a szkript sikerét eredményezik. A jövőbeli soft forkok valódi viselkedést rendelhetnek ezekhez az opkódokhoz azáltal, hogy korlátozásokat vezetnek be a sikerességük feltételeire vonatkozóan, anélkül, hogy új szkriptverzióra vagy az ökoszisztéma egészére kiterjedő teljes újratelepítési ciklusra lenne szükség. A Bitcoin szkriptrétegéhez új képességek adhatók hozzá tisztább módon, mint a protokoll történetének bármely korábbi szakaszában.

Miniscript

A Tapscript mellett egy Miniscript nevű, ahhoz kapcsolódó projekt is egyre nagyobb jelentőségre tett szert a fejlesztők körében. A Miniscript a Bitcoin Script egy részhalmazának strukturált írási módja, amely általánosan elemzhető, összetett és aláírható. Míg a nyers Script kézi összeállítást igényel és nehezen ellenőrizhető, a Miniscript szkriptek helyességét automatikusan ellenőrizni lehet, és azokat nagyobb szabályzatokba is össze lehet vonni. Ez nem bővíti a Script képességeit, de a már meglévő funkciókat jelentősen hozzáférhetőbbé teszi azoknak a fejlesztőknek, akik pénztárcákat és letéti eszközöket készítenek.

A Bitcoin Script lehetőségei: valós felhasználási példák

A Bitcoin főhálózatán jelenleg a következő tranzakciótípusok aktívak, amelyek mind a Bitcoin Script alapelemekre épülnek:

Több aláírásos (multisig) pénztárcák a kifizetés jóváhagyásához M az N-ből magánkulcsra van szükség. Egy vállalat pénzügyi osztálya például 3 az 5-ből jóváhagyást követelhet meg bármely kifizetéshez. Egy házaspár pedig 2 az 2-ből rendszert alkalmazhat a közös megtakarítások kezelésére. A Taproot és a Schnorr-kulcs-összevonásnak köszönhetően a kooperatív többaláírásos kifizetések a blokkláncon már nem különböztethetők meg a szokásos, egyetlen aláírással végrehajtott tranzakcióktól.

Időzített tranzakciók Az OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, röviden CLTV) és az OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, röviden CSV) használatával megakadályozható, hogy a pénzeszközöket egy bizonyos blokkmagasság elérése vagy egy bizonyos idő eltelte előtt átutalják. Az alkalmazási területek közé tartoznak az öröklési tervezés, a munkavállalói tokenek megszerzésének ütemezése, a kényszerű megtakarítási mechanizmusok, valamint a Lightning Network csatornákon belül használt büntető tranzakciók.

Hash-alapú időzárt szerződések (HTLC-k) összekapcsolják a hash-előképre vonatkozó követelményt egy időzárt feltétellel. A kifizetési feltétel a következőképpen működik: ha a hash-előképet nem fedik fel a blokk magassága előtt, az összeg visszakerül a feladónak. A HTLC-k a Lightning Network alapvető elemei, amelyek bizalommentes fizetési útvonalakat tesznek lehetővé csatornaláncokon keresztül olyan felek között, akik között nincs közvetlen kapcsolat.

Letéti számla Ezek a megoldások a pénzeszközöket egy P2SH- vagy Taproot-szkriptben zárolják, amelynek felszabadításához több fél beleegyezése szükséges; általában egy harmadik félként eljáró döntőbíró rendelkezik a döntő kulccsal.

Diszkrét napló-szerződések (DLC-k) Oracle-alapú Schnorr-adapter aláírások használatával lehetővé válik olyan pénzügyi szerződések lebonyolítása, amelyek elszámolása valós adatokon – például árfolyam-adatokon vagy események kimenetelén – alapul, anélkül, hogy az oracle-nek bármilyen pénzeszközt őriznie kellene. A DLC-k már működnek a Bitcoin főhálózatán, és Bitcoin-alapú opciós és határidős termékekhez használják őket.

Bitcoin-szkript kontra Ethereum-okosszerződések

A Bitcoin Script és az Ethereum Solidity egyaránt meghatározza azokat a feltételeket, amelyek mellett a pénzeszközök mozgása lehetséges, de alapvetően eltérő architektúrai megoldásokat képviselnek. Érdemes közvetlenül összehasonlítani őket, mivel a különbségek sokat elárulnak azokról a kompromisszumokról, amelyeket az egyes hálózatok vállaltak.

Az alapvető különbséget az állapottartás jelenti. Az Ethereum-szerződések olyan adatokat tárolnak és módosítanak, amelyek a tranzakciók között is megmaradnak, így lehetővé téve a hitelezési protokollok, a decentralizált tőzsdék, a láncon belüli irányítás és a token-szabványok működését. A Bitcoin Scriptben nincs ehhez hasonló megoldás. Minden szkript elszigetelten fut, és nincs tudomása más tranzakciókról.

Ez egy tudatos architektúrai döntés, nem pedig egy kitöltésre váró hiányosság. A Bitcoin szkriptrétegét egy konkrét feladatra tervezték: a bitcoin elköltésének feltételeinek előírására, kiszámíthatóan, biztonságosan és nagy léptékben. Ehhez a feladathoz az állapotmentesség előnyt jelent. A támadási felület kisebb, a végrehajtás több millió független validátor esetében is determinisztikus, és a protokollszinten nem létezik olyan kategória, amelyben a smart contractokat kihasználhatnák, mivel a protokollszinten nincsenek állapotfüggő szerződések.

Azok a projektek, amelyek a Bitcoinra építve nagyobb programozhatóságot kívánnak elérni, réteges felépítést alkalmaznak. A Lightning Network kezeli a fizetéseket. A DLC-protokollok a külső adatokra hivatkozó pénzügyi szerződéseket kezelik. Az Ark és a Liquid Networkhez hasonló 2. rétegű rendszerek különböző skálázhatósági igényeket elégítenek ki. Mindehhez nincs szükség az alapréteg szkriptelési modelljének módosítására.

A „Covenant” körüli vita: Mi változhat a Bitcoin Scriptben?

A Bitcoin Script fejlődése mindig is lassú és óvatos volt. Jelenleg a legaktívabb fejlesztési terület a „covenant” opkódok területe; ezek olyan javaslatok, amelyek lehetővé tennék a szkript számára, hogy ne csak azt korlátozza, ki költheti el egy kimenetet, hanem azt is, hogy az ebből származó tranzakciónak hogyan kell kinéznie. Ez a Script kifejezőképességének jelentős bővítését jelenti.

2026. június állapot szerint a legfontosabb javaslatok a következők:

• OP_CTV (BIP-119, CheckTemplateVerify), amelynek szerzője Jeremy Rubin, egyetlen opkódot vezet be, amely egy UTXO-t egy konkrét, előre meghatározott kiadási sablonhoz rendel, amely magában foglalja a tranzakció verziószámát, a locktime-ot, a bemenetek számát, a szekvenciákat, a kimenetek számát és a kimeneteket. A javaslat tervezésénél fogva nem rekurzív, a legkonzervatívabb jelentős javaslatnak számít, és elsősorban a vaultokat, a torlódásszabályozást, valamint bizonyos Lightning-fejlesztéseket célozza meg. 2026 áprilisától az OP_CTV-re vonatkozóan konkrét bevezetési paraméterek kerültek terítékre, amelyek meghatározzák a „Speedy Trial” jelzési ablakot, de az aktiváláshoz szükséges széles körű közösségi konszenzust még nem sikerült elérni, a A BlockEden 2026. áprilisi szerződéses feltételek elemzése.
• OP_CAT (BIP-347), amelyet Ethan Heilman és Armin Sabouri javasolt, újra engedélyezne egy olyan opkódot, amelyet Satoshi 2010-ben letiltott. Az OP_CAT két veremelemet fűz össze, ami leírásában egyszerű, de következményei széles körűek. A Schnorr-aláírásokkal kombinálva lehetővé teszi a „covenant”-hez hasonló tranzakciós introspekciót. A Bitcoin Signet teszt hálózaton az OP_CAT jelentősen több fejlesztői tranzakciót generált, mint az APO vagy a CTV, az sCrypt 2024 végéről származó láncon belüli elemzése szerint. Az OP_CAT már aktív a Liquid Network-en és a Fractal Bitcoin-on, és eddig nem társítottak hozzá semmilyen kihasználást. A BIP-347 hivatalos javaslat-számmal rendelkezik, és aktív kutatások állnak mögötte, de a mainnet-en való aktiváláshoz közösségi konszenzusra van szükség, amely egyelőre még nem áll fenn.
• LNHANCE az OP_CTV-t az OP_CHECKSIGFROMSTACK (CSFS) és az OP_INTERNALKEY parancsokkal együtt tartalmazza, és a Lightning Network csatornák kialakításának konkrét fejlesztéseit célozza meg, ideértve a nem interaktív csatornanyitásokat és a több fél részvételével zajló csatornakezelés hatékonyabbá tételét.

2026 júniusáig ezek közül egyik sem lépett életbe a Bitcoin főhálózatán. A köztük fennálló technikai nézeteltérések nagyrészt megoldhatók. A nehezebb probléma az aktiválás mechanizmusa. A Bitcoin soft fork folyamata széles körű konszenzust igényel, és a megállapodással kapcsolatos vita magában hordozza a korábbi vitatott frissítésekből származó feszültségeket. A vitából egyértelműen kiderül, hogy a Bitcoin szkriptrétegének jelentős fejlődési lehetőségei vannak a konzervatív keretrendszerén belül. A jelenleg megvitatott kérdés a lépések sorrendje és a közösségi egyetértés, nem pedig az, hogy van-e jövője a szkriptnyelvnek.

Következtetés

A Bitcoin Script a hálózat minden tranzakciója mögött meghúzódó láthatatlan infrastruktúra. A legtöbb felhasználó soha nem találkozik vele közvetlenül. A pénztárcák érvényes szkripteket állítanak össze, aláírják és továbbítják azokat anélkül, hogy a működési mechanizmust valaha is felfednék. De minden fizetés, minden Lightning-csatorna, minden időzített terv és minden többaláírásos tárhely ugyanazon a veremalapú Bitcoin szkriptnyelven fut, amely 2009-ben a protokollal együtt jelent meg.

A szkriptréteg azóta jelentősen bővült: a P2SH lehetővé tette a bonyolult tranzakciók gyakorlati megvalósítását, a SegWit csökkentette a tranzakciós díjakat és előkészítette a Lightning hálózatot, míg a Taproot bevezette a Schnorr-aláírásokat, a MAST-alapú adatvédelmet és a Tapscript előre kompatibilis opkód-tervezését. A jelenleg aktív viták tárgyát képező covenant-javaslatok a következő lehetséges fejezetet jelentik. Hogy ezek közül bármelyik is életbe lép-e, és ha igen, milyen ütemterv szerint, az 2026 közepén még teljesen nyitott kérdés.

A Script megértéséhez nem kell fejlesztőnek lenni. Ahhoz viszont el kell fogadni, hogy a Bitcoin konzervativizmusa, a szándékos korlátozások, a lassú frissítési ütem és a Turing-teljesség hiánya nem jelent hiányosságot. Azok a tulajdonságok, amelyek a Bitcoin Scriptet kiszámíthatóvá teszik, pontosan azok, amelyek tizenhat éve tisztán tartják a konszenzusréteget.