Bitcoin Script je programski jezik, ki nadzira vsako transakcijo v omrežju Bitcoin. Gre za preprost jezik, ki temelji na skladu in opredeljuje natančne pogoje, pod katerimi je mogoče porabiti bitcoine, vsako polno vozlišče v omrežju pa ga izvaja ob vsakem potrjevanju transakcije. Brez njega bi bil Bitcoin le knjiga številk brez mehanizma, ki bi zagotavljal, komu kaj pripada.
Večina uporabnikov skriptnega jezika Bitcoina nikoli ne vidi neposredno. Njihove denarnice to opravljajo nevidno. Vendar pa se vsakič, ko pošljete ali prejmete BTC, na tisočih računalnikih hkrati izvajata dva majhna programa, ki preverjata, ali so izpolnjeni pogoji za porabo. Razumevanje tega delovanja v veliki meri pojasni, zakaj je Bitcoin zasnovan tako, kot je, ter kaj lahko in česa ne more v primerjavi s platformami, kot je Ethereum.
Ta članek obravnava delovanje Bitcoin Script, predstavlja glavne vrste transakcij, ki jih omogoča, pojasnjuje nadgradnjo Taproot, s katero je bila leta 2021 posodobljena skriptna plast, ter opisuje trenutno stanje razprave o opkodu »covenant« v juniju 2026.
Varno upravljajte s svojimi bitcoini z lastnim hranjenjem Aplikacija Bitcoin.com Wallet.
Ključne ugotovitve
- Bitcoin Script je na skladu temelječ programski jezik, vgrajen v protokol Bitcoin, ki določa pogoje, pod katerimi je mogoče porabiti kateri koli bitcoin izhod.
- Vsaka transakcija v omrežju Bitcoin vključuje dva skripta: skript za zaklepanje (ScriptPubKey), ki ga določi prejemnik, in skript za odklepanje (ScriptSig), ki ga zagotovi pošiljatelj. Da je transakcija veljavna, se morata oba skripta uspešno izvesti.
- Bitcoin Script namerno ni Turingovo popoln. Nima zank, nima trajnega stanja med izvedbami in ima stroge omejitve glede velikosti skripta. Zaradi tega se vsak skript zagotovo zaključi, kar je varnostna lastnost, ne pa omejitev.
- Skriptni jezik se je razvil skozi pet glavnih formatov: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) in Taproot (P2TR), od katerih je vsak razširil možnosti, hkrati pa ohranil združljivost z prejšnjimi različicami.
- Taproot (november 2021) je uvedel Schnorr-ove podpise, poti porabe na podlagi MAST za zaščito zasebnosti ter Tapscript kot posodobljen skriptni jezik z vgrajenim mehanizmom za bolj gladke prihodnje nadgradnje.
- Praktični primeri uporabe, ki temeljijo na Bitcoin Scriptu, vključujejo denarnice z več podpisov, transakcije z časovno zaklenitvijo, pogodbe z zaklenjenim časom na podlagi hash-vrednosti (osnova za Lightning), skrbništvo in pogodbe z diskretnim dnevnikom.
- Za razliko od pametnih pogodb v omrežju Ethereum je Bitcoin Script brezstanen: vsak skript teče popolnoma ločeno, brez kakršnega koli vpogleda v druge transakcije. To je namerna arhitekturna odločitev.
- Najbolj aktivno področje razvoja Bitcoin Script v letu 2026 so opkodi za pogodbe, zlasti OP_CTV (BIP-119) in OP_CAT (BIP-347), ki bi skriptom omogočili, da določijo, kako mora izgledati transakcija porabe. Noben od njiju še ni bil aktiviran v glavnem omrežju.
Kaj je Bitcoin Script?
Bitcoin Script je skriptni jezik, ki temelji na skladu in nima stanja ter je vgrajen v protokol Bitcoin. Vsak izhod transakcije v omrežju Bitcoin vsebuje skript za zaklepanje (imenovan ScriptPubKey), ki določa pogoje za porabo sredstev. Vsak, ki želi porabiti ta sredstva, mora predložiti skript za odklepanje (imenovan ScriptSig ali, v transakcijah SegWit in Taproot, podatke priče), ki izpolnjuje te pogoje.
Jezik je po strukturi podoben jeziku Forth, minimalističnemu programskemu jeziku, ki temelji na skladu in je bil razvit v 60. letih prejšnjega stoletja. Tako kot Forth se tudi Bitcoin Script bere od leve proti desni, deluje na podatkovni strukturi, imenovani sklad, in uporablja obratno poljsko notacijo (RPN), pri kateri operaterji sledijo operandom, namesto da bi jim predhodili. Izvaja po eno navodilo naenkrat, nima zank in med izvajanji ne ohranja trajnega pomnilnika.
Prav ta zadnja točka je tista, s katero se večina ljudi najprej sreča, ko se seznanijo z Bitcoin Scriptom na ravni protokola: jezik namreč namerno ni Turingovo popoln. Turingovo popoln jezik lahko izvede katerokoli računsko operacijo, če ima na voljo dovolj časa in virov. Bitcoin Script tega po svoji zasnovi ne more, razlogi za to odločitev pa imajo velik vpliv na delovanje omrežja.
Kako deluje Bitcoin Script: model sklada
Da bi razumeli, kako deluje Bitcoin Script, morate razumeti delovanje sklada. Sklad je podatkovna struktura, ki deluje po načelu »zadnji noter, prvi ven« (LIFO). Predstavljajte si kup krožnikov: dodajati ali odvzemati lahko le z vrha. V Bitcoin Scriptu se podatki potisnejo na sklad, operacijske kode (opcode) pa manipulirajo s tistim, kar se nahaja na vrhu.
Ko vozlišče Bitcoin potrdi transakcijo, zaporedoma izvede dva skripta:
- Skript za odklepanje (ScriptSig ali priča) ki jih zagotovi oseba, ki porablja kovance. S tem se podatki shranijo na sklad, običajno gre za digitalni podpis in javni ključ.
- Skript za zaklepanje (ScriptPubKey) povezano z izvršitvijo izhoda. To vsebuje operacijske kode, ki delujejo na podatkih v skladu in preverjajo, ali so pogoji za izvršitev izpolnjeni.
Če se skript izvede brez napak in na koncu na skladu pusti vrednost, ki ni nič (TRUE), je transakcija veljavna. Če se skript ne izvede ali pusti vrednost FALSE, vozlišče transakcijo zavrne in ta nikoli ne pride v blok.
To izvajanje je popolnoma brezstanje. Skript nima nobenih podatkov o prejšnjih transakcijah, ne pozna trenutnih stanj in nima pomnilnika, ki bi se ohranil po koncu izvajanja skripta. Vsak skript se vsakič izvaja od začetka, v izoliranem okolju.
Korak za korakom: standardna transakcija P2PKH
Pay-to-Public-Key-Hash (P2PKH) je prvotna vrsta bitcoin transakcije, ki se uporablja od leta 2009. Naslovi P2PKH se začnejo s »1.« Tako v praksi izgledata ScriptPubKey in ScriptSig:
Skript za odklepanje (ScriptSig):
<podpis> <javni ključ>
Skript za zaklepanje (ScriptPubKey):
OP_DUP OP_HASH160 <hash javnega ključa> OP_EQUALVERIFY OP_CHECKSIG
Ko vozlišče združi in izvede obe operaciji hkrati, se operacije na skladu odvijajo korak za korakom:
- Podpis in javni ključ iz ScriptSig se dodata na sklad
OP_DUPkopira javni ključ na vrh skladaOP_HASH160izračuna hash podvojenega zapisa (SHA-256, ki mu sledi RIPEMD-160), pri čemer se dobi 20-bajtni hash- Hash javnega ključa iz skripta za zaklepanje se shrani na sklad
OP_EQUALVERIFYpreveri, ali se oba hash-a ujemata. Če se ne ujemata, se izvajanje ustavi in transakcija ni uspešna.OP_CHECKSIGpreveri, ali je podpis veljaven za javni ključ
Če so vsi koraki uspešni, se niz konča z vrednostjo TRUE in sredstva se sprostijo. Celoten postopek traja nekaj milisekund in poteka enako na vsakem vozlišču v omrežju.
Razlaga bitcoinovih opkodov
Bitcoinovi opkodi so posamezni ukazi, iz katerih je sestavljen skript. Vsak opkod obsega en bajt, kar omogoča 256 možnih mest za opkode. Od teh je trenutno v glavnem omrežju aktivnih približno 80. Preostali so bodisi rezervirani, onemogočeni ali dodeljeni mehanizmu za združljivost z bodočimi različicami OP_SUCCESS, ki je bil uveden s Tapscriptom.
Operacijske kode se razvrščajo v več kategorij:
- Operacijske kode za pošiljanje podatkov vstaviti vrednosti, kot so javni ključi, podpisi in hash vrednosti, na sklad
- Aritmetični opkodi izvajati seštevanje, odštevanje in primerjanje. Pomembno je, da sta množenje in deljenje onemogočena.
- Kriptografski opkodi vključujejo OP_SHA256, OP_HASH160 in OP_SHA1 za izračun hash-vrednosti ter OP_CHECKSIG za preverjanje podpisa
- Operacijske kode za nadzor pretoka omogoči pogojno logiko: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
- Operacijski kodi za manipulacijo z nizi mednje spadajo OP_DUP (podvojitev prvega elementa), OP_DROP (odstranitev prvega elementa) in OP_SWAP (zamenjava prvih dveh elementov)
Satoshi Nakamoto je leta 2010 onemogočil več opkodov, potem ko so bile v njihovih prvotnih izvedbah odkrite ranljivosti. Mednje spadajo OP_CAT (združitev dveh elementov na skladu), OP_MUL (množenje) in OP_DIV (deljenje). Njihova odsotnost je imela trajne posledice za zmožnosti Bitcoin Script, zato se več najbolj razpravljanih predlogov za nadgradnjo Bitcoina v letu 2026 nanaša na to, ali naj se nekatere od njih ponovno omogoči.
Za popoln pregled opkodov, vključno s šestnajstiškimi vrednostmi in opisi, si oglejte Stran »Bitcoin Wiki Script« je verodostojni vir.
Zakaj je neturingova popolnost prednost
Običajna razlaga je, da Bitcoin Script ne vsebuje zank, zato je zagotovljeno, da se skripti zaključijo, kar omogoča zaščito omrežja pred neskončnim izvajanjem. To je res, vendar pa ta razlaga ne zajame celotne slike.
Globlja razprava se nanaša na površino napada. Turingovsko popoln jezik lahko izrazi poljubno računanje. Prav ta izraznost je tudi prostor, kjer se skrivajo napake. Jezik Solidity v omrežju Ethereum je povzročil nekatere najdražje ranljivosti programske opreme v zgodovini. Pri hekerskem napadu na DAO leta 2016 je bil izkoriščen napaka ponovnega vstopa v pametni pogodbi, kar je povzročilo izgube v višini okoli 60 milijonov dolarjev po takratnih cenah in na koncu pripeljalo do sporne trde razceplitve omrežja Ethereum. V širšem ekosistemu DeFi so bili v več letih prek izkoriščanja ranljivosti pametnih pogodb izgubljeni stotine milijonov dolarjev.
Bitcoin Script takšne vrste napadov strukturno onemogoča. Ni mogoče napisati Bitcoin skripta, ki bi kliče druge skripte, se ponavljal, dokler se pogoj ne spremeni, ali shranjeval stanje med transakcijami. Vsak skript je omejen, zaključen in pregledljiv program. Največja velikost skripta je 10.000 bajtov. Največje število opkodov, ki niso »push«, na skript je 201. Validator lahko vedno izračuna strošek izvedbe v najslabšem primeru, še preden skript zažene.
Za omrežje, katerega vrednost znaša več sto milijard dolarjev, je ta predvidljivost vredna več kot prožnost, ki jo pri tem žrtvuješ. Ethereum rešuje problem neomejenega računanja z omejitvami porabe plina (gas limits), pri čemer uporabnikom zaračunava vsak izveden opcode in ustavi skripte, ki izčrpajo proračun. To deluje, vendar prinaša lastno zapletenost in možnosti za napake. Bitcoin se temu problemu v celoti izogne že s svojo zasnovo.
Vendar pa »ni Turingovo popoln« ne pomeni »ni sposoben za zapleteno logiko«. Bitcoin Script podpira zahteve za porabo s sodelovanjem več strani, časovno pogojene zahteve, razkritje predobrazca hash-a ter kombinacije vseh naštetih. Omrežje Lightning Network, ki dnevno usmerja milijone plačil, je v celoti zgrajeno na osnovnih elementih Bitcoin Script.
Vrste skriptov: Razvoj od P2PKH do Taproot
Skriptni sloj bitcoina se je od leta 2009 znatno razvil, pri čemer je vsaka nadgradnja uvedla nov format transakcij, hkrati pa je ohranila združljivost z vsemi prejšnjimi različicami.
P2PK (Pay-to-Public-Key, 2009)
Izvirna oblika, ki se je uporabljala pri prvih transakcijah z bitcoini, vključno s Satoshijevim plačilom Halu Finneyju v bloku 170. Sredstva so bila vezana neposredno na celoten javni ključ, ne pa na njegov hash. Danes se v novih transakcijah redko uporablja, saj javni ključ razkrije v verigi še pred porabo, kar velja za šibkejšo varnostno prakso v primerjavi s predhodnim hashiranjem ključa.
P2PKH (Pay-to-Public-Key-Hash, 2009)
Standardni format, ki se uporablja že več kot desetletje. P2PKH sredstva veže na hash javnega ključa namesto na sam ključ, s čimer javni ključ ostane skrit do trenutka porabe, kar omogoča krajši 20-bajtni naslov in predstavlja osnovo za vse naslove, ki se začnejo s »1«. Glede na podatke iz verige, ki jih je objavilo podjetje Unchained (april 2026), naslovi P2PKH trenutno hranijo približno 43 % izkopanih bitcoinov.
P2SH (Pay-to-Script-Hash, 2012, BIP 16)
P2SH, ki je bil uveden s soft forkom 1. aprila 2012, je breme zapletenih skriptov za porabo prenesel s pošiljatelja na prejemnika. Namesto vgradnje celotnega skripta za zaklepanje v izhod, izhodi P2SH vsebujejo le 20-bajtni hash »skripta za unovčenje«. Celoten skript se razkrije šele ob porabi kovancev. S tem je postala večkratna podpisna potrditev (multisig) praktična za navadne uporabnike: pri nastavitvi večkratne podpisne potrditve 2 od 3 ni bilo več potrebno, da so bili vsi trije javni ključi vidni pošiljatelju ob plačilu. Naslovi P2SH se začnejo s »3«.
Za podrobno razlago delovanja preverjanja P2SH na ravni protokola, Vodnik po transakcijah na spletnem mestu developer.bitcoin.org korak za korakom pojasnjuje delovanje mehanizma »Redeem Script«.
P2WPKH in P2WSH (nativni SegWit, 2017, BIP 141)
Segregated Witness, ki je bil aktiviran avgusta 2017 pri bloku 481.824, je podatke o podpisu prenesel iz glavnega dela transakcije v ločeno strukturo »witness«. Podatki »witness« imajo 75-odstotno znižanje teže, zaradi česar so transakcije SegWit znatno cenejše. Standardna transakcija P2WPKH z enim vhodom in dvema izhodoma tehta približno 141 virtualnih bajtov, v primerjavi z 226 vbajti za enakovredno transakcijo P2PKH, v skladu z Sparkova analiza vrst naslovov Bitcoin od marca 2026. SegWit je odpravil tudi problem spremenljivosti transakcij, kar je bil pogoj za vzpostavitev omrežja Lightning Network. Izvirni naslovi SegWit se začnejo z »bc1q.«
P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)
Taproot je bil aktiviran novembra 2021 pri bloku 709.632 in predstavlja najpomembnejšo nadgradnjo skriptnega sloja Bitcoina od uvedbe SegWita. Uvedel je Schnorr-ove podpise, nov tip izhoda s podporo za MAST ter Tapscript kot posodobljen skriptni jezik. Naslovi Taproot se začnejo z »bc1p.«
Taproot in Tapscript: Kako se je skriptni jezik bitcoina spremenil v letu 2021
Taproot ni ena sama sprememba. Gre za tri predloge za izboljšanje Bitcoina (Bitcoin Improvement Proposals), ki so bili zasnovani skupaj in aktivirani hkrati.
BIP 340: Schnorrjevi podpisi
Bitcoin je prvotno uporabljal algoritem ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi se je zanj odločil deloma zato, ker so bili Schnorrovi podpisi takrat zaščiteni s patentom. Ta patent je potekel leta 2008, Taproot pa je končno vpeljal Schnorrove podpise v protokol.
Schnorrjevi podpisi so manjši – merijo 64 bajtov, medtem ko ECDSA-podpisi merijo 71–73 bajtov. Še pomembneje pa je, da podpirajo agregacijo ključev prek sheme, imenovane MuSig2. Agregacija ključev omogoča več podpisnikom, da združijo svoje posamezne ključe in podpise v en sam agregatni ključ in podpis, ki je v verigi neprepoznaven od običajnega plačila z enim samim podpisom. Poraba iz denarnice z večkratnim podpisom 2 od 3 prek kooperativne poti ključev Taproot izgleda enako kot standardno plačilo v verigi blokov. To je resnična pridobitev na področju zasebnosti za vsakogar, ki hrani bitcoine v okviru zapletene ureditve hrambe.
BIP 341: Pay-to-Taproot in MAST
P2TR uvaja nov tip izhoda z dvema potema porabe:
- A ključna pot poraba s pomočjo Schnorrjevega podpisa, ki se uporabi, kadar se vse stranke strinjajo in želijo najpreprostejšo ter najcenejšo rešitev
- A pot do skripta poraba z uporabo MAST (Merkelized Abstract Syntax Tree, kar je Taprootova implementacija tega koncepta)
MAST omogoča, da se en izhod prek Merklejevega korena veže na drevo več scenarijev porabe. Ob porabi se v verigi razkrije le tisti pogoj, ki se dejansko uporabi. Vse druge možne poti porabe v drevesu ostanejo trajno skrite. Za uporabnika, ki je nastavil zapleteno politiko porabe, na primer: »Lahko porabim sredstva običajno, ali pa lahko po šestih mesecih porabita dva od treh skrbnikov, ali pa lahko po dveh letih porabi obnovitveni ključ«, se v verigi blokov vedno prikaže le tista pot, ki se dejansko izvede.
Po podatkih Glassnode, ki jih je marca 2026 navedel Spark, se je do leta 2024 delež transakcij Taproot v omrežju Bitcoin povečal na približno 42 %, kar je v veliki meri posledica dejavnosti v zvezi z Ordinals in vpisov BRC-20. Od takrat se je ta delež spreminjal glede na razmere na trgu, vendar je infrastruktura zdaj standardna v vseh večjih denarnicah in na borzah. Stran o temi Taproot na spletnem mestu Bitcoin Optech spremlja tekoči razvoj protokola v zvezi s Taprootom.
BIP 342: Tapscript
Tapscript je posodobljen skriptni jezik, ki se uporablja za transakcije po skriptni poti v okviru Taproot. Večino opkodov ima skupnih s starejšim Bitcoin Scriptom, vendar vključuje nekaj pomembnih sprememb:
OP_CHECKMULTISIGinOP_CHECKMULTISIGVERIFYso zastareli. Stari opcode za večkratni podpis je imel napako, zaradi katere je bilo treba kot začasno rešitev na sklad dodati lažni element. Tapscript ga odstrani in nadomesti zOP_CHECKSIGADD, ki preverja Schnorr-ove podpise po enega in beleži število. Izvajanje večpodpisnih shem s pragom postane preprostejše in cenejše.- Omejitve velikosti skriptov za posamezne liste MAST so odpravljene. Posamezni skripti znotraj veje Taproot lahko dosegajo poljubno velikost.
- Opkodi OP_SUCCESS so najbolj napredna sprememba. V klasičnem skriptnem jeziku (Legacy Script) nedoločena opkoda povzroči neuspeh skripta. V Tapscriptu pa opkode iz območja OP_SUCCESS povzročijo, da skript brezpogojno uspe. Prihodnji mehki razcepi lahko tem opkodom dodelijo dejansko delovanje z uvedbo omejitev glede pogojev za uspešno izvedbo, ne da bi bila potrebna nova različica skripta ali celoten cikel ponovne uvedbe v celotnem ekosistemu. Nove zmogljivosti je mogoče dodati v skriptni sloj Bitcoina na bolj preprost način kot kdajkoli prej v zgodovini protokola.
Miniscript
Poleg Tapscripta je za razvijalce vse pomembnejši tudi soroden projekt z imenom Miniscript. Miniscript je strukturiran način pisanja podsklopa Bitcoin Script, ki ga je mogoče analizirati, sestavljati in splošno podpisovati. Medtem ko surovi Script zahteva ročno sestavljanje in je težko pregledati, je mogoče pravilnost skriptov Miniscript samodejno preveriti in jih združiti v obsežnejše politike. Ne razširja zmogljivosti Script, temveč tisto, kar že omogoča, naredi bistveno dostopnejše za razvijalce, ki razvijajo denarnice in orodja za hrambo.
Kaj omogoča Bitcoin Script: primeri uporabe v praksi
Danes so v glavnem omrežju Bitcoina aktivne naslednje vrste transakcij, ki so vse zasnovane na osnovnih elementih Bitcoin Script:
Denarnice z več podpisov (multisig) za odobritev izplačila je potrebnih M od N zasebnih ključev. Finančna služba podjetja lahko za vsak dvig zahteva 3 od 5 odobritev. Zakonski par lahko za skupne prihranke uporabi 2 od 2. Z agregacijo ključev Taproot in Schnorr so skupinske transakcije z več podpisov v verigi zdaj neprepoznavne od standardnih transakcij z enim podpisom.
Transakcije z časovno omejitvijo Uporabite OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify ali CLTV) in OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify ali CSV), da preprečite prenos sredstev pred doseganjem določene višine bloka ali pretekom določenega časa. Med uporabne primere spadajo načrtovanje dedovanja, časovni razporedi za pridobitev pravic do žetonov za zaposlene, mehanizmi prisilnega varčevanja ter transakcije s kaznimi, ki se uporabljajo znotraj kanalov omrežja Lightning Network.
Pogodbe s časovno zaklenjenim hash-om (HTLC) združijo zahtevo po predobliki hash-a s časovno ključavnico. Pogoj za porabo deluje takole: predobliko tega hash-a je treba razkriti pred doseženo višino bloka, sicer se sredstva vrnejo pošiljatelju. HTLC-ji so osrednji element omrežja Lightning Network, ki omogočajo zaupanja vredno usmerjanje plačil prek verig kanalov med strankami, ki med seboj nimajo neposrednega odnosa.
Escrow Ti mehanizmi sredstva zaklenejo v skriptu P2SH ali Taproot, pri čemer je za njihovo sprostitev potrebno soglasje več strani, običajno pa ključ za odločilni glas ima neodvisni tretji arbitražni organ.
Pogodbe o diskretnem beleženju (DLC) uporabljajo podpise adapterja Schnorr, ki temeljijo na oraklju, da omogočijo poravnavo finančnih pogodb na podlagi podatkov iz realnega sveta, kot so cenovni viri ali izidi dogodkov, ne da bi bilo potrebno, da orakel prevzame skrbništvo nad kakršnimi koli sredstvi. DLC-ji so že v uporabi v glavnem omrežju Bitcoina in se uporabljajo za opcijske in terminske produkte, poravnane v bitcoinih.
Bitcoin Script v primerjavi s pametnimi pogodbami Ethereuma
Tako Bitcoin Script kot Solidity v Ethereumu opredeljujeta pogoje, pod katerimi se lahko sredstva prenašajo, vendar gre za temeljito različne arhitekturne odločitve. Primerjavo je vredno opraviti neposredno, saj te razlike veliko pojasnjujejo o kompromisih, ki jih je sprejelo vsako omrežje.
| Značilnost | Bitcoin skript | Pametne pogodbe v omrežju Ethereum |
|---|---|---|
| Model izvedbe | Na podlagi sklada, brez stanja, omejen | Na podlagi sklada (EVM), s stanjem, z merjenjem porabe plina |
| Turingovo popolno? | Ne. Brez zank, zagotovljeno je, da se program zaključi. | Da. Poljubno računanje. |
| Ohranjanje stanja | Nič. Vsak skript se izvaja ločeno. | Pogodbe shranjujejo in spreminjajo stanje v verigi. |
| Glavni namen | Pogojna poraba UTXO-jev | Programirljive aplikacije splošnega namena |
| Zaščita pred napadi DoS | Strukturno: brez zank, stroge omejitve velikosti | Omejitve porabe plina pri stroških izvedbe |
| Zasebnost pri spodnjem sloju | Izboljšano s Taprootom in MAST-om | Vse so privzeto javne |
| Zgodovina varnostnih dosežkov | V zadnjih 16 letih ni bilo nobenih zlorab na ravni konsenza | Znaten obseg zlorab na ravni pogodb, izgube v višini milijard |
| Orodja za razvijalce | Opkodi nizke ravni; Miniscript; Tapscript | Solidity (visoko ravni), preveden v bajtni kod EVM |
Osnovna ločnica je stanje. Pogodbe v omrežju Ethereum shranjujejo in spreminjajo podatke, ki se ohranjajo med posameznimi transakcijami, kar omogoča delovanje protokolov za posojanje, decentraliziranih borz, upravljanja znotraj verige in standardov za tokene. Bitcoin Script nima ničesar podobnega. Vsak skript teče v izoliranem okolju, brez kakršnega koli vpogleda v druge transakcije.
To je namerna arhitekturna odločitev, ne pa vrzel, ki čaka na zapolnitev. Skriptni sloj bitcoina je bil zasnovan za eno konkretno nalogo: predvidljivo in varno uveljavljanje pogojev za porabo bitcoinov v velikem obsegu. Za to nalogo je odsotnost stanja prednost. Površina za napade je manjša, izvajanje je deterministično med milijoni neodvisnih validatorjev, na ravni protokola pa ni mogoče izkoriščati pametnih pogodb, saj na tej ravni ni pogodb s stanjem.
Projekti, ki želijo več programabilnosti poleg Bitcoina, jo gradijo v plasteh. Omrežje Lightning Network skrbi za plačila. Protokoli DLC obravnavajo finančne pogodbe, ki se sklicujejo na zunanje podatke. Sistemi druge plasti, kot sta Ark in Liquid Network, obravnavajo različne profile skalabilnosti. Za nič od tega ni potrebna sprememba modela skriptiranja osnovne plasti.
Razprava o sporazumu: Kaj bi se lahko spremenilo v skriptu bitcoina
Razvoj skripta Bitcoin je bil vedno počasen in konzervativen. Trenutno najbolj aktivno področje razvoja so opkodi »covenant«, ki predstavljajo predloge, ki bi skriptu omogočili, da ne omeji le tega, kdo lahko porabi izhod, ampak tudi to, kako mora izgledati končna transakcija. To pomeni pomembno razširitev izraznih zmožnosti skripta.
Najpomembnejši predlogi v juniju 2026 so:
- OP_CTV (BIP-119, CheckTemplateVerify), katerega avtor je Jeremy Rubin, dodaja en sam opcode, ki UTXO dodeli določeni, vnaprej določeni predlogi porabe, vključno z različico transakcije, časom zaklepa, številom vhodov, zaporedji, številom izhodov in izhodi. Po zasnovi je nerekurziven, velja za najbolj konzervativen večji predlog in je namenjen predvsem trezorjem, nadzoru prezasedenosti ter nekaterim izboljšavam omrežja Lightning. Od aprila 2026 so za OP_CTV na mizi konkretni parametri uvedbe, ki določajo signalno okno »Speedy Trial«, vendar še ni bil dosežen širok konsenz skupnosti, potreben za aktivacijo, v skladu z Analiza pogodbenih obveznosti podjetja BlockEden za april 2026.
- OP_CAT (BIP-347), ki sta ga predlagala Ethan Heilman in Armin Sabouri, bi ponovno omogočil operacijski kod, ki ga je Satoshi onemogočil leta 2010. OP_CAT združi dva elementa v skladu, kar je po opisu preprosto, vendar ima široke posledice. V kombinaciji s Schnorrjevimi podpisi omogoča introspekcijo transakcij, podobno kot pri »covenantih«. Na testnem omrežju Bitcoin Signet je OP_CAT po podatkih analize verige sCrypt iz konca leta 2024 ustvaril znatno več transakcij razvijalcev kot APO ali CTV. OP_CAT je že aktiven v omrežjih Liquid Network in Fractal Bitcoin, pri čemer mu ni pripisan noben zlorabni napad. BIP-347 ima uradno številko predloga in za njim stojijo aktivne raziskave, vendar aktivacija v glavnem omrežju zahteva soglasje skupnosti, ki še ne obstaja.
- LNHANCE združuje OP_CTV z OP_CHECKSIGFROMSTACK (CSFS) in OP_INTERNALKEY, s čimer si prizadeva za konkretne izboljšave pri vzpostavljanju kanalov v omrežju Lightning Network, vključno z neinteraktivnim odpiranjem kanalov in učinkovitejšim upravljanjem večstranskih kanalov.
Do junija 2026 se nobena od teh rešitev ni aktivirala v glavnem omrežju Bitcoina. Tehnična nesoglasja med njimi so v veliki meri rešljiva. Težji problem je mehanizem aktivacije. Postopek »soft forka« Bitcoina zahteva široko soglasje, razprava o sporazumu pa nosi s seboj preostalo napetost iz prejšnjih spornih nadgradenj. Iz razprave je jasno, da ima skriptni sloj Bitcoina znaten prostor za rast znotraj svojega konzervativnega okvira. Vprašanje, ki se rešuje, je zaporedje ukrepov in soglasje skupnosti, ne pa to, ali ima skriptni jezik prihodnost.
Zaključek
Bitcoin Script je nevidna infrastruktura, na kateri temelji vsaka transakcija v omrežju. Večina uporabnikov se z njim nikoli ne sreča neposredno. Denarnice sestavljajo veljavne skripte, jih podpisujejo in oddajajo, ne da bi kdaj koli razkrile njihovo delovanje. Vendar vsako plačilo, vsak Lightning kanal, vsak časovno zaklenjen načrt in vsak trezor z večkratnim podpisom poteka prek istega skriptnega jezika Bitcoin, ki temelji na skladu in je bil vključen v protokol leta 2009.
Skriptna plast se je od takrat znatno razvila: P2SH je omogočil praktično izvajanje zapletenih transakcij, SegWit je zmanjšal provizije in omogočil delovanje omrežja Lightning, Taproot pa je prinesel Schnorr-ove podpise, zasebnost na podlagi MAST ter naprej združljivo zasnovo operacijskih kod v Tapscriptu. Predlogi sporazumov, o katerih trenutno poteka živahna razprava, predstavljajo naslednje potencialno poglavje. Ali se bo kateri od njih aktiviral in v kakšnem časovnem okviru, je sredi leta 2026 še vedno povsem odprto vprašanje.
Za razumevanje skripta ni treba biti razvijalec. Je pa treba spoznati, da konzervativnost Bitcoina, namerne omejitve, počasen ritem nadgradenj in neturingova popolnost niso pomanjkljivosti. Lastnosti, zaradi katerih je Bitcoin Script predvidljiv, so iste lastnosti, ki so že šestnajst let ohranjale konsenzusni sloj čist.






