Mis on Bitcoin-skriptikeel?

Bitcoin Script on programmeerimiskeel, mis juhib kõiki tehinguid Bitcoini võrgustikus. Tegemist on lihtsa, pinu-põhise keelega, mis määratleb täpsed tingimused, mille alusel bitcoine saab kulutada, ning iga võrgustiku täisnood käivitab seda iga kord, kui tehing kinnitatakse. Ilma selleta oleks Bitcoin lihtsalt numbrite raamatupidamisregister, millel puuduks mehhanism, mis tagaks, kellele miski kuulub.

Enamik kasutajaid ei näe Bitcoini skriptikeelt kunagi otseselt. Nende rahakotid tegelevad sellega nähtamatult. Kuid iga kord, kui saadad või võtad vastu BTC-d, töötavad tuhandetes arvutites samaaegselt kaks väikest programmi, mis kontrollivad, kas kulutamise tingimused on täidetud. Selle toimimise mõistmine selgitab paljuski, miks Bitcoin on just selliselt üles ehitatud ning mida see suudab ja mida mitte võrreldes selliste platvormidega nagu Ethereum.

Käesolevas artiklis käsitletakse Bitcoin Scripti toimimist, tutvustatakse selle abil võimalikke peamisi tehingutüüpe, selgitatakse Taproot-uuendust, millega 2021. aastal moderniseeriti skriptimiskihte, ning antakse ülevaade „covenant“-opkoodi teemalise arutelu hetkeseisust 2026. aasta juunis.

Haldage oma bitcoine turvaliselt isehalduse abil Bitcoin.com rahakoti rakendus.

Peamised järeldused

• Bitcoin Script on Bitcoin-protokolli sisse ehitatud pinu-põhine programmeerimiskeel, mis määratleb tingimused, mille alusel saab mis tahes bitcoini väljundit kulutada.
• Iga Bitcoini tehing sisaldab kahte skripti: saaja poolt määratud lukustamisskripti (ScriptPubKey) ja maksja poolt esitatud avamisskripti (ScriptSig). Tehing on kehtiv vaid juhul, kui mõlemad skriptid täidetakse edukalt.
• Bitcoin Script ei ole tahtlikult Turingi-täielik. Selles puuduvad tsüklid, käivituste vahel ei säilita seisundit ning skripti suurusele on kehtestatud ranged piirangud. Seetõttu lõpetab iga skript kindlasti oma töö, mis on turvaelement, mitte piirang.
• Skriptikeel on arenenud läbi viie peamise formaadi: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) ja Taproot (P2TR), millest igaüks laiendab võimalusi, säilitades samal ajal tagasiühilduvuse.
• Taproot (november 2021) tõi kasutusele Schnorr-allkirjad, privaatsust tagavad MAST-põhised kulutusteed ning Tapscripti – uuendatud skriptikeele, millel on sisseehitatud mehhanism, mis tagab sujuvamad tulevased uuendused.
• Bitcoin Scripti põhjal loodud reaalsed kasutusjuhtumid hõlmavad mitme allkirjaga rahakotte, ajaliselt piiratud tehinguid, Hash Time-Locked Contracts’i (Lightningi alus), tagatisraamatut ja Discreet Log Contracts’i.
• Erinevalt Ethereumi nutilepingutest on Bitcoin Script seisundivaba: iga skript töötab täielikus eraldatuses, ilma et tal oleks teavet ühegi teise tehingu kohta. See on teadlik arhitektuuriline valik.
• 2026. aastal on Bitcoin Scripti arendamise kõige aktiivsem valdkond lepingulised opkoodid, eelkõige OP_CTV (BIP-119) ja OP_CAT (BIP-347), mis võimaldaksid skriptidel määrata, milline peab olema kulutustehing. Kumbki neist pole veel põhivõrgus aktiveeritud.

Mis on Bitcoin Script?

Bitcoin Script on Bitcoin-protokolli sisse ehitatud pinu-põhine, seisundita skriptikeel. Iga Bitcoin-võrgustiku tehingu väljund sisaldab lukustusskripti (nn ScriptPubKey), mis määrab kindlaks rahaliste vahendite kulutamise tingimused. Igaüks, kes soovib neid vahendeid kulutada, peab esitama lukust vabastava skripti (nn ScriptSig või SegWit- ja Taproot-tehingute puhul tunnistajaandmed), mis vastab nendele tingimustele.

Keele struktuur põhineb Forthil, 1960. aastatel välja töötatud minimalistlikul virnapõhisel programmeerimiskeelel. Nagu Forth, loetakse ka Bitcoin Scripti vasakult paremale, see töötab virna nimetatava andmestruktuuriga ning kasutab pöördpoola märkimisviisi (RPN), kus operaatorid järgnevad operandidele, mitte ei eelne neile. See täidab korraga ühte käsku, selles puuduvad tsüklid ning see ei säilita mälu käskude täitmise vahel.

See viimane punkt ongi see, millega enamik inimesi esimesena kokku puutub, kui tutvub Bitcoin Scripti protokollitasandil: keel ei ole tahtlikult Turingi-täielik. Turingi-täielik keel suudab piisava aja ja ressursside olemasolul teostada mis tahes arvutust. Bitcoin Script ei suuda seda oma ülesehituse tõttu teha, ning selle valiku põhjused mõjutavad oluliselt võrgu toimimist.

Kuidas Bitcoin Script töötab: pinu mudel

Et mõista, kuidas Bitcoin Script toimib, pead aru saama, mis on pinu. Pinu on andmestruktuur, mis toimib põhimõttel „viimane sisse, esimene välja“ (LIFO). Kujutage ette taldrikute virna: lisada või eemaldada saab ainult ülevalt. Bitcoin Scriptis lükatakse andmed virna ja operatsioonikoodid (opcodes) töötlevad seda, mis parasjagu virna tipus asub.

Kui Bitcoini sõlm tehingut kinnitab, käivitab ta järjest kaks skripti:

1. Lukustuse avamise skript (ScriptSig või tunnistaja) mida esitab müntide kulutaja. See lisab andmed virna, tavaliselt digitaalallkirja ja avaliku võtme.
2. Lukustamisskript (ScriptPubKey) mis on seotud väljundiga, mida kulutatakse. See sisaldab käskukoode, mis töötlevad virna andmeid ja kontrollivad, kas kulutamise tingimused on täidetud.

Kui skript täidetakse veatult ja jätab lõpus virna nullist erineva väärtuse (TRUE), on tehing kehtiv. Kui skript ebaõnnestub või jätab virna väärtuse FALSE, lükkab sõlm tehingu tagasi ja see ei jõua kunagi plokki.

See täitmine on täielikult seisundivaba. Skriptil puudub igasugune teave varasemate tehingute kohta, ta ei tea praeguseid saldod, ning tal puudub mälu, mis jääks alles pärast skripti täitmise lõppu. Iga skript käivitatakse iga kord nullist ja isoleeritult.

Samm-sammult: tüüpiline P2PKH-tehing

Pay-to-Public-Key-Hash (P2PKH) on Bitcoini algne tehingutüüp, mida kasutatakse alates 2009. aastast. P2PKH-aadressid algavad numbriga „1”. Siin on näide, kuidas ScriptPubKey ja ScriptSig praktikas välja näevad:

Skripti avamise skript (ScriptSig):

<allkiri> <avalik võti>

Lukustamisskript (ScriptPubKey):

OP_DUP OP_HASH160 <avaliku võtme hash> OP_EQUALVERIFY OP_CHECKSIG

Kui sõlm ühendab need kaks kokku ja täidab need üheaegselt, toimuvad virnaoperatsioonid samm-sammult:

• ScriptSig-ist pärit allkiri ja avalik võti lükatakse virna
• OP_DUP kopeerib avalikku võtit virna ülaossa
• OP_HASH160 arvutab duplikaadi hash-väärtuse (SHA-256, millele järgneb RIPEMD-160), mille tulemuseks on 20-baidiline hash-väärtus
• Lukustamisskripti avalik võti hash-väärtus lükatakse virna
• OP_EQUALVERIFY kontrollib, kas need kaks hash-väärtust ühtivad. Kui need ei ühti, peatatakse täitmine ja tehing ebaõnnestub.
• OP_CHECKSIG kontrollib, kas allkiri kehtib selle avaliku võtme puhul

Kui kõik etapid läbivad edukalt, lõpeb järjekord väärtusega TRUE ja rahalised vahendid vabastatakse. Kogu protsess võtab aega millisekundites ja kulgeb võrgu igas sõlmes täpselt samamoodi.

Bitcoin’i opkoodide selgitus

Bitcoini opkoodid on skripti moodustavad üksikud käsud. Iga opkood on ühe baidi pikkune, mistõttu on võimalik kasutada 256 opkoodi pesa. Neist on peavõrgus praegu aktiivsed umbes 80. Ülejäänud on kas reserveeritud, keelatud või määratud Tapscriptiga kasutusele võetud OP_SUCCESS edasiühilduvuse mehhanismile.

Opkoodid jagunevad mitmesse kategooriasse:

• Andmete edastamise käskukoodid lisada virna sellised väärtused nagu avalikud võtmed, allkirjad ja hash-väärtused
• Aritmeetilised käskukoodid teha liitmis-, lahutamis- ja võrdlusoperatsioone. Tuleb märkida, et korrutamine ja jagamine on keelatud.
• Krüptograafilised käskukoodid sealhulgas OP_SHA256, OP_HASH160 ja OP_SHA1 räsimiseks ning OP_CHECKSIG allkirja kontrollimiseks
• Voolu juhtimise opkoodid tingimusloogika lubamine: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Kuhja manipuleerimise käskukoodid nende hulka kuuluvad OP_DUP (kõige ülemise elemendi kopeerimine), OP_DROP (kõige ülemise elemendi eemaldamine) ja OP_SWAP (kahe ülemise elemendi vahetamine)

Satoshi Nakamoto keelas 2010. aastal mitmed opkoodid, kui nende algsetes rakendustes avastati turvaaugud. Nende hulka kuuluvad OP_CAT (kahe pinuelemendi ühendamine), OP_MUL (korrutamine) ja OP_DIV (jagamine). Nende puudumine on avaldanud püsivat mõju sellele, mida Bitcoin Script suudab väljendada, ning mitmed 2026. aastal kõige aktiivselt arutatud Bitcoini uuenduse ettepanekud puudutavad just seda, kas mõned neist tuleks uuesti lubada.

Täieliku opkoodide viite, sealhulgas kuueteistkümnendväärtuste ja kirjeldustega, leiate Bitcoin Wiki skripti lehekülg on usaldusväärne allikas.

Miks Turingi-mittetäielikkus on eelis

Tavaliselt selgitatakse seda nii, et Bitcoin Scripti keeles puuduvad tsüklid, mistõttu skriptid lõpetavad kindlasti töö ja võrk on seega kaitstud lõputu täitmise eest. See on küll õige, kuid ei anna asjast täit pilti.

Sügavam põhjus peitub rünnakupinnas. Turingi-täielik keel suudab väljendada mis tahes arvutusi. See väljendusvõime on samas ka keskkond, kus vead tekivad. Ethereumi Solidity on põhjustanud mõned ajaloo kõige kulukamad tarkvaravigad. 2016. aasta DAO-häkk kasutati ära nutilepingu reentrantsuse viga ja põhjustas tollaste hindade järgi umbes 60 miljoni dollari suuruse kahju, mis viis lõpuks Ethereumi võrgu vastuolulise hard forki tekkeni. Laiemas DeFi ökosüsteemis on mitme aasta jooksul nutilepingute ärakasutamise kaudu kadunud sadu miljoneid dollareid.

Bitcoin-skript muudab sellise rünnaku struktuuriliselt võimatuks. Ei ole võimalik kirjutada Bitcoin-skripti, mis kutsuks välja teisi skripte, teeks tsüklit, kuni tingimus muutub, või salvestaks seisundit tehingute vahel. Iga skript on piiratud, lõpetatav ja kontrollitav programm. Skripti maksimaalne suurus on 10 000 baiti. Skripti kohta on lubatud maksimaalselt 201 mitte-push-tüüpi opkoodi. Validaator saab alati enne skripti käivitamist arvutada halvima stsenaariumi täitmiskulu.

Võrgustiku puhul, mille väärtus ulatub sadadesse miljarditesse dollaritesse, on see ettearvatavus väärtuslikum kui paindlikkus, millest tuleb loobuda. Ethereum lahendab piiramatu arvutusvõimsuse probleemi gaasipiirangutega, nõudes kasutajatelt tasu iga täidetud opkoodi eest ja peatades skriptid, mille eelarve on ammendunud. See toimib, kuid toob kaasa omaette keerukuse ja tõrkevõimalused. Bitcoin hoiab sellest probleemist oma ülesehituse tõttu täielikult kõrvale.

Samas ei tähenda „ei ole Turingi-täielik” seda, et „ei suuda käsitleda keerulist loogikat”. Bitcoin Script toetab mitme osapoole vahelisi kulutamisnõudeid, ajapõhiseid tingimusi, hash-preimage’i avalikustamist ning kõigi nende kombinatsioone. Lightning Network, mis suunab päevas miljoneid makseid, on täielikult ehitatud Bitcoin Scripti primitiivide põhjal.

Skripti tüübid: areng P2PKH-st Taprootini

Bitcoini skriptikiht on alates 2009. aastast märkimisväärselt arenenud, kusjuures iga uuendus on toonud kaasa uue tehinguvormingu, säilitades samas tagasiühilduvuse kõigi varasemate versioonidega.

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

Algne formaat, mida kasutati esimestes Bitcoin-tehingutes, sealhulgas Satoshi makse Hal Finneyle plokis 170. Rahalised vahendid lukustati otse täieliku avalikule võtmele, mitte selle hashile. Tänapäeval kasutatakse seda uutes tehingutes harva, kuna see avalikustab avaliku võtme ahelas enne kulutamist, mida peetakse nõrgemaks turvalahenduseks kui võtme eelnev hash-funktsiooniga töötlemine.

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

Juba üle kümne aasta kasutusel olev standardvorming. P2PKH seob rahalised vahendid avalikule võtmele vastava hash-väärtusega, mitte võtmega endaga, hoides avalikku võtit salajas kuni kulutamise hetkeni, luues lühema, 20-baidise aadressi ning moodustades aluse kõigile aadressidele, mis algavad numbriga „1”. Unchainedi ahelaandmete (aprill 2026) kohaselt hoitakse P2PKH-aadressidel praegu ligikaudu 43% kaevandatud bitcoini varudest.

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

1. aprillil 2012. aastal soft forki kaudu kasutusele võetud P2SH nihutas keeruliste kulutamisskriptide koormuse saatjalt vastuvõtjale. Selle asemel, et lisada väljundisse täielik lukustamisskript, sisaldab P2SH-väljund „lunastamisskripti“ 20-baidilist hash-väärtust. Täielik skript avalikustatakse alles siis, kui mündid kulutatakse. See muutis multisig-lahenduse tavakasutajate jaoks praktiliseks: 2-of-3 multisig-seadistuse puhul ei olnud enam vaja, et kõik kolm avalikku võtit oleksid saatjale makse tegemise ajal nähtavad. P2SH-aadressid algavad numbriga „3“.

P2SH-valideerimise toimimise üksikasjaliku ülevaate saamiseks protokollitasandil, developer.bitcoin.org tehingute juhend selgitab samm-sammult, kuidas toimib skripti „redeem” mehhanism.

P2WPKH ja P2WSH (Native SegWit, 2017, BIP 141)

Segregated Witness, mis aktiveeriti 2017. aasta augustis plokis 481 824, viis allkirjaandmed tehingu põhiosa väljapoole eraldi tunnistaja struktuuri. Tunnistajaandmetele kohaldatakse 75-protsendilist kaaluvähendust, mis muudab SegWit-tehingud märkimisväärselt odavamaks. Tavaline ühe sisendi ja kahe väljundiga P2WPKH-tehing kaalub umbes 141 virtuaalbaiti, võrreldes samaväärse P2PKH-tehingu 226 vbaitiga, vastavalt Sparki analüüs Bitcoini aadressitüüpide kohta alates 2026. aasta märtsist. SegWit kõrvaldas ka tehingute muudetavuse probleemi, mis oli Lightning Networki loomise eeltingimus. SegWit-põhised aadressid algavad tähtedega „bc1q.“

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

Taproot aktiveeriti 2021. aasta novembris plokis 709 632 ning on Bitcoin’i skriptimiskihi kõige olulisem uuendus alates SegWitist. Sellega võeti kasutusele Schnorr-allkirjad, uus väljunditüüp MAST-toega ning uuendatud skriptikeel Tapscript. Taproot-aadressid algavad tähtedega „bc1p.“

Taproot ja Tapscript: kuidas muutus Bitcoini skriptikeel 2021. aastal

Taproot ei ole üksik muudatus. Tegemist on kolme Bitcoin Improvement Proposals’iga, mis on välja töötatud ühiselt ja aktiveeritud samaaegselt.

BIP 340: Schnorri allkirjad

Bitcoin kasutas algselt ECDSA-t (elliptilise kõvera digitaalallkirja algoritm). Satoshi valis selle osaliselt seetõttu, et Schnorr-allkirjad olid tol ajal patendiga kaitstud. See patent kaotas kehtivuse 2008. aastal ning Taproot viis Schnorr-allkirjad lõpuks protokollisse.

Schnorr-allkirjad on väiksemad – 64 baiti võrreldes ECDSA 71–73 baitiga. Veelgi olulisem on see, et need toetavad võtmete koondamist skeemi kaudu, mida nimetatakse MuSig2-ks. Võtmete koondamine võimaldab mitmel allkirjastajal ühendada oma individuaalsed võtmed ja allkirjad üheks koondvõtmeks ja -allkirjaks, mida ahelas ei ole võimalik eristada tavalisest ühe allkirjaga makseest. 2-of-3 multisig-rahakoti kulutamine Taprooti koostöölise võtmetee kaudu näeb plokiahelas välja täpselt nagu tavaline makse. See on tõeline privaatsuse võit kõigile, kes hoiavad bitcoine keerulise hoiustamiskorralduse raames.

BIP 341: Pay-to-Taproot ja MAST

P2TR tutvustab uut väljunditüüpi, millel on kaks kulutuste rada:

• A võtme tee tehingu sooritamine Schnorr-allkirja abil, mida kasutatakse juhul, kui kõik osapooled on sellega nõus ja soovivad kõige lihtsamat ning odavamat lahendust
• A skripti asukoht kasutada MAST-i (Merkelized Abstract Syntax Tree, mis on selle kontseptsiooni Taproot-rakendus)

MAST võimaldab ühel väljundil Merkle’i juure kaudu seostuda mitme kulutamisskripti puuga. Kulutamisel avalikustatakse ahelas ainult see konkreetne tingimus, mida tegelikult kasutatakse. Kõik muud puus leiduvad võimalikud kulutamisteed jäävad püsivalt varjatuks. Kui kasutaja on seadistanud keeruka kulutamispoliitika, näiteks „Võin kulutada tavapäraselt, või kaks kolmest usaldusisikust võivad kulutada kuue kuu pärast, või taastamisvõti võimaldab kulutada kahe aasta pärast“, ilmub plokiahelas alati ainult see tee, mida tegelikult rakendatakse.

2024. aasta seisuga oli Taproot’i osakaal Bitcoini tehingutes kasvanud umbes 42%ni, mis oli Sparki poolt 2026. aasta märtsis tsiteeritud Glassnode’i andmete kohaselt peamiselt tingitud Ordinalsi ja BRC-20-i kirjutustegevusest. Sellest ajast alates on see osakaal turutingimustega koos kõigutanud, kuid infrastruktuur on nüüdseks standardiks kõigis suuremates rahakottides ja börsides. Bitcoin Optechi Taproot-teemaleht jälgib Taprootiga seotud protokolli arendamist.

BIP 342: Tapscript

Tapscript on Taprootis skriptide teekonna tehingute jaoks kasutatav uuendatud skriptikeel. Selles on enamik operatsioonikoode samad, mis vanas Bitcoin Scriptis, kuid selles on tehtud mitu olulist muudatust:

• OP_CHECKMULTISIG ja OP_CHECKMULTISIGVERIFY on vananenud. Vanas multisig-operatsioonikoodis oli üks veidrus, mille ületamiseks tuli lahendusena virna lisada näivelement. Tapscript eemaldab selle ja asendab selle OP_CHECKSIGADD, mis kontrollib Schnorr-allkirju ükshaaval ja kogub loendit. Künnisega mitme allkirja skeemid muutuvad selgemaks ja nende rakendamine odavamaks.
• MAST-lehe kohta kehtivad skriptide suuruse piirangud on tühistatud. Taproot-haru raames võivad üksikud skriptid olla suvaliselt suured.
• OP_SUCCESS-opkoodid on kõige tulevikku suunatum muudatus. Vanemas skriptikeeles põhjustab määratlemata opkoodi leidmine skripti ebaõnnestumise. Tapscriptis tagavad OP_SUCCESS-vahemikku kuuluvad opkoodid skripti tingimusteta õnnestumise. Tulevased soft-forkid võivad neile opkoodidele määrata tegeliku käitumise, lisades piiranguid nende õnnestumise tingimustele, ilma et see nõuaks uut skriptiversiooni või täielikku uuesti kasutuselevõtu tsüklit kogu ökosüsteemis. Bitcoini skriptimiskihile saab lisada uusi võimalusi puhtamalt kui kunagi varem protokolli ajaloos.

Miniscript

Lisaks Tapscriptile on arendajate jaoks üha olulisemaks muutunud sellega seotud projekt nimega Miniscript. Miniscript on struktureeritud viis kirjutada Bitcoin Scripti alamhulka, mida on võimalik analüüsida, kombineerida ja üldiselt allkirjastada. Kui toores Script nõuab käsitsi koostamist ja on raske auditeerida, siis Miniscripti skripte saab õigsuse suhtes automaatselt kontrollida ja kombineerida suuremate reeglistikeks. See ei laienda Scripti võimalusi, kuid muudab selle olemasolevad võimalused oluliselt kättesaadavamaks arendajatele, kes loovad rahakotte ja hoiustamisvahendeid.

Mida Bitcoin Script võimaldab: praktilised kasutusjuhtumid

Täna on Bitcoini põhivõrgus aktiivsed järgmised tehingutüübid, mis kõik põhinevad Bitcoin Scripti primitiividel:

Mitme allkirjaga (multisig) rahakotid nõuab kulutuse kinnitamiseks M-of-N eravõtmeid. Ettevõtte rahandusosakond võib nõuda iga väljamakse tegemiseks 3-of-5 heakskiitu. Abielupaar võib ühiste säästude puhul kasutada 2-of-2 süsteemi. Tänu Taprootile ja Schnorr-võtmete koondamisele on koostööl põhinevad multisig-kulutused nüüd ahelas eristamatud tavapärastest ühe allkirjaga tehingutest.

Ajalise piiranguga tehingud Kasutage OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify ehk CLTV) ja OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify ehk CSV) funktsioone, et takistada rahaliste vahendite liikumist enne teatud ploki kõrgust või aja möödumist. Rakenduste hulka kuuluvad päranduse planeerimine, töötajate tokenite omandamise ajakavad, sundsäästmise mehhanismid ja Lightning Networki kanalites kasutatavad trahvitehingud.

Hash-põhised ajapiiranguga lepingud (HTLC-d) ühendada hash-väärtuse algkuju nõue ajalukuga. Väljamaksetingimus toimib järgmiselt: avalikusta selle hash-väärtuse algkuju enne selle ploki kõrgust, vastasel juhul lähevad rahalised vahendid tagasi saatjale. HTLC-d on Lightning Networki põhiline primitiiv, mis võimaldab usaldusvaba maksete suunamist kanalite ahelate kaudu osapoolte vahel, kellel puudub otsene suhe.

Escrow Sellised lahendused lukustavad rahalised vahendid P2SH- või Taproot-skriptis, mille vabastamiseks on vaja mitme osapoole nõusolekut, kusjuures otsustav hääl on tavaliselt kolmandal osapoolel, kes omab otsustavat võtit.

Diskreetse logi lepingud (DLC-d) kasutada Oracle’il põhinevaid Schnorr-adapteri allkirju, et võimaldada finantslepingute arveldamist reaalmaailma andmete, näiteks hinnavoogude või sündmuste tulemuste alusel, ilma et Oracle peaks vahendeid hoiule võtma. DLC-d on kasutusel Bitcoini põhivõrgus ning neid kasutatakse Bitcoini alusel arveldatavate optsioonide ja futuuride puhul.

Bitcoini skript vs. Ethereumi nutilepingud

Nii Bitcoini skript kui ka Ethereumi Solidity määratlevad tingimused, mille alusel raha saab liikuda, kuid need esindavad põhimõtteliselt erinevaid arhitektuurilisi valikuid. Neid tasub otse võrrelda, sest erinevused selgitavad paljuski, milliseid kompromisse on iga võrk teinud.

Põhiline eristav tegur on riistvaraline seisund. Ethereumi lepingud salvestavad ja muudavad andmeid, mis säilivad tehingute vahel, võimaldades seeläbi laenuprotokolle, detsentraliseeritud börse, ahelasisest juhtimist ja tokenite standardeid. Bitcoin Scriptil puudub sellele vastav funktsioon. Iga skript töötab eraldatult, ilma et tal oleks teavet ühegi teise tehingu kohta.

Tegemist on teadliku arhitektuurilise valikuga, mitte lüngaga, mida tuleks täita. Bitcoini skriptimiskihk on loodud ühe konkreetse ülesande jaoks: tagada bitcoini kulutamise tingimuste täitmine ettearvatavalt, turvaliselt ja suuremahuliselt. Selle ülesande puhul on seisundivabadus eeliseks. Rünnakupind on väiksem, täitmine on miljonite sõltumatute validaatorite puhul deterministlik ning protokollitasandil puudub nutilepingute ärakasutamise võimalus, kuna protokollitasandil ei ole seisundiga lepinguid.

Projektid, mis soovivad Bitcoini peale lisada suuremat programmeeritavust, ehitavad selle üles kihtidena. Lightning Network haldab makseid. DLC-protokollid haldavad välistele andmetele viitavaid finantslepinguid. 2. kihi süsteemid, nagu Ark ja Liquid Network, on suunatud erinevatele skaleeritavuse profiilidele. Ükski neist ei nõua põhikihi skriptimismudeli muutmist.

Arutelu „Covenant“ üle: mis võiks Bitcoini skriptis muutuda

Bitcoin Scripti areng on alati olnud aeglane ja konservatiivne. Hetkel on kõige aktiivsem arendusvaldkond nn covenant-opkoodid – need on ettepanekud, mis võimaldaksid skriptil piirata mitte ainult seda, kes võib väljundit kulutada, vaid ka seda, milline peab olema sellest tulenev tehing. See on Scripti väljendusvõime oluline laiendus.

2026. aasta juuni seisuga on peamised ettepanekud järgmised:

• OP_CTV (BIP-119, CheckTemplateVerify), mille autoriks on Jeremy Rubin, lisab ühe operatsioonikoodi, mis seob UTXO kindla, eelnevalt määratud kulutamismalliga, mis hõlmab tehingu versiooni, lukustusaega, sisendite arvu, järjestusi, väljundite arvu ja väljundeid. See on oma ülesehituselt mitterekursiivne, peetakse kõige konservatiivsemaks suuremaks ettepanekuks ning on suunatud peamiselt hoiukambritele, ülekoormuse kontrollile ja teatud Lightning-võrgu täiustustele. Alates 2026. aasta aprillist on OP_CTV-le esitatud konkreetsed kasutuselevõtu parameetrid, mis määravad kindlaks „Speedy Trial“ signaalimisakna, kuid selle aktiveerimiseks vajalikku laiaulatuslikku kogukonna konsensust ei ole veel saavutatud, vastavalt BlockEdeni 2026. aasta aprilli lepingutingimuste analüüs.
• OP_CAT (BIP-347), mille pakkusid välja Ethan Heilman ja Armin Sabouri, taastaks operatsioonikoodi, mille Satoshi 2010. aastal keelustas. OP_CAT ühendab kaks pinu elementi, mis on kirjelduselt lihtne, kuid millel on laiaulatuslikud tagajärjed. Koos Schnorr-allkirjadega võimaldab see lepingulaadset tehingute analüüsi. Bitcoini Signet-testvõrgus oli OP_CAT sCrypti 2024. aasta lõpu ahelaanalüüsi kohaselt tekitanud märkimisväärselt rohkem arendajate tehinguid kui APO või CTV. OP_CAT on juba aktiivne Liquid Networkis ja Fractal Bitcoinis, ilma et sellega seotud kuritarvitusi oleks täheldatud. BIP-347-l on ametlik ettepaneku number ja selle taga aktiivne uurimistöö, kuid selle aktiveerimine põhivõrgus nõuab kogukonna konsensust, mida veel ei ole.
• LNHANCE ühendab OP_CTV OP_CHECKSIGFROMSTACK-iga (CSFS) ja OP_INTERNALKEY-ga, eesmärgiga teha konkreetseid parandusi Lightning Networki kanalite loomisel, sealhulgas mitteinteraktiivsete kanalite avamine ja tõhusam mitmepoolne kanalite haldamine.

2026. aasta juuni seisuga pole ükski neist Bitcoin’i põhivõrgus aktiveeritud. Nende vahelised tehnilised erimeelsused on suures osas lahendatavad. Raskem probleem on aktiveerimise mehhanism. Bitcoini soft forki protsess nõuab laialdast konsensust ning kokkuleppe üle peetav arutelu kannab endas endiselt pingeid varasematest vaidlusi tekitanud uuendustest. Arutelust selgub, et Bitcoini skriptimiskihil on selle konservatiivse raamistiku piires märkimisväärne arenguruum. Käsitletav küsimus puudutab järjekorda ja kogukonna kokkulepet, mitte seda, kas skriptimiskeelel on tulevikku.

Kokkuvõte

Bitcoin Script on võrgu iga tehingu taga peituv nähtamatu infrastruktuur. Enamik kasutajaid ei puutu sellega kunagi otseselt kokku. Rahakotid koostavad kehtivaid skripte, allkirjastavad need ja edastavad need, ilma et nende toimimismehhanism kunagi avalikuks tuleks. Kuid iga makse, iga Lightning-kanal, iga ajaliselt lukustatud plaan ja iga mitme allkirjaga hoiulaegas töötab sama pinu-põhise Bitcoin-skriptikeele abil, mis lisati protokollile 2009. aastal.

Sellest ajast alates on skriptimiskihk märkimisväärselt laienenud: P2SH on muutnud keerukad tehingud praktiliselt teostatavaks, SegWit on vähendanud tehingutasusid ja võimaldanud Lightning-võrgu kasutuselevõttu ning Taproot on toonud kaasa Schnorr-allkirjad, MAST-põhise privaatsuse ja Tapscripti tulevikuga ühilduva opkoodi disaini. Praegu aktiivselt arutatavad lepingueelnõud kujutavad endast järgmist potentsiaalset peatükki. Kas mõni neist rakendub ja millise ajakava järgi, on 2026. aasta keskpaigaks veel täiesti lahtine.

Scripti mõistmiseks ei pea olema arendaja. Selleks tuleb aga mõista, et Bitcoini konservatiivsus, tahtlikud piirangud, aeglane uuenduste tempo ja Turingi täielikkuse puudumine ei ole puudused. Omadused, mis muudavad Bitcoin Scripti ettearvatavaks, on samad omadused, mis on hoidnud konsensuse kihi puhtana juba kuusteist aastat.