Vai notiek OP_CAT? Līguma priekšlikumam tikko tika piešķirts BIP numurs #347. Bet pirms mēs iedziļināsimies, izpētīsim, kas ir derības un kāpēc Bitcoiners tās varētu vēlēties.
Vai Bitcoin ir ideāls digitālās e-naudas stāvoklis, vai arī mēs vēlamies vairāk no mūsu monētām ķēdē?
Virsmas skrāpēšana: Bitcoin skriptu ierobežojumi
Lai saprastu tādus paktu priekšlikumus kā OP_CAT, ir ļoti svarīgi ievērot Bitcoin Script pamata ierobežojumus, kādi tas ir šodien. Zem pārsega Bitcoin ļauj izveidot pamata viedos līgumus, izmantojot kodus, kas nosaka naudas līdzekļu bloķēšanas un atbloķēšanas noteikumus. Tomēr Bitcoin Script kā programmēšanas valoda ir diezgan ierobežota ar pamata loģiku, kas tiek izmantota tikai, pārvietojot monētas jaunā darījumā.
Mūsdienās Bitcoin nav iespējams iepriekš konfigurēt vai diktēt savu monētu darījumu ceļus vai to, cik ātri monētas var pārvietoties brīdī, kad tās tiek bloķētas (izņemot hacky darbplūsmas, izmantojot PSBT, daļēji parakstītus bitcoin darījumus, kas nevar pareizi iekļaut darījumu maksas, pierādīt dzēšanu, ja tas netiek izmantots, vai novērst apraidi vēlāk).
Šī vienkāršība, kaut arī ir Bitcoin drošības modeļa pamatā, ievieš ievērojamus ierobežojumus skriptu valodas spējai atbalstīt pat pamata viedos līgumus.
Lineārais izpildes modelis
Viens no Bitcoin Script ierobežojumiem ir tā darbības modelis, kurā opkodi tiek izpildīti secīgi bez cilpām.
Šajā P2PKH transakcijas piemērā varat redzēt, kā skripts tiek izpildīts lineāri: dublējot publisko atslēgu, jaukšanu uz adresi, pārbaudot jaukšanu pret bloķēšanas skriptu un, visbeidzot, pārbaudot parakstu pret publisko atslēgu.
Cilpas neesamība nozīmē, ka skripti nav Tūringa pabeigti un tiek garantēti, ka tie tiks pārtraukti, novēršot tādas problēmas kā bezgalīgas cilpas, kas potenciāli varētu apturēt vai ievērojami palēnināt tīkla darbību. Lai gan šī dizaina izvēle ļauj statiski ierobežot resursu izmantošanu, tā arī ierobežo skripta spēju pārvaldīt sarežģītas darbplūsmas.
Pamata aritmētikas trūkums
Bitcoin Script ir nedaudz mazāk par 100 netriviāliem opkodiem, un pārsteidzošā kārtā nav iespējams reizināt, dalīt vai apvienot objektus skurstenī. Kā zinās daudzi lietotāji, kuri interesējas par OP_CAT, Satoshi 2010. gadā atspējoja vairākus Bitcoin opkodus, tostarp OP_OR, OP_MUL (reizināt), OP_DIV (dalīt) un OP_CAT (savienot). Atspējotie operācijas kodi tika noņemti, jo to sākotnējām implementācijām bija izmantojamas ievainojamības, kas varētu apdraudēt tīkla drošību. Taču šo opkodu neesamība apgrūtina pamata matemātikas veikšanu, kas varētu būt noderīga vienkāršos gadījumos, piemēram, aprēķinot darījumu maksas līgumā.
Trūkst darījumu datu redzamības
Virspusēji, es domāju, ka lielākā daļa cilvēku pieņem, ka Bitcoin viedie līgumi spēj redzēt vērtību summas un jebkuras citas darījumu datu daļas, jo šī informācija jau ir publiski skatāma blokķēdē. Bet pretēji šim pieņēmumam, līgumi par Bitcoin nevar noteikt tēriņu nosacījumus, pamatojoties uz darījumu datiem, jo Bitcoin Script ir ļoti ierobežota iespēja redzēt darījumu datus.
Ja skriptam būtu iespēja interpretēt vairāk detaļu darījumu datos, mēs varētu izveidot daudz stingrākus līgumus, kas varētu veikt visas jautrās lietas, piemēram, ieviest īpašus tēriņu nosacījumus, izveidot daudzpakāpju darījumus un iespējot uzlabotas drošības funkcijas, piemēram, glabātuves.
Ko mēs ar to darām?
Mēs zinām, ka Bitcoin ir šie ierobežojumi, un gadu gaitā ir apspriesti daudzi dažādi priekšlikumi, lai ieviestu (vai dažos gadījumos atkārtoti) šo funkcionalitāti. Plašāku eksperimentu ar Bitcoin Script, piemēram, Simplicity un citiem, mērķis ir nodrošināt alternatīvu steku ierobežojumiem. Tādu opkodu kā OP_MULTISHA256, OP_LESS un OP_LE32TOLE64 mērķis ir uzlabot Bitcoin aritmētiskās spējas. Tādi priekšlikumi kā OP_CTV un OP_CAT, kas attiecas uz introspekciju opkodiem, tiek grupēti zem termina līgumi.
Tātad, kāda īsti ir atšķirība starp viedajiem līgumiem un jauna termiņa līgumiem?
Viedie līgumi pret līgumiem
Viedie līgumi ir pašizpildes darījumi, kas pārskaita līdzekļus bez starpniekiem. Mūsdienās Bitcoin viedie līgumi aprobežojas ar bitkoīna bloķēšanu un atbloķēšanu, izmantojot Bitcoin Script. Paktu mērķis ir uzlabot Bitcoin viedo līgumu funkcionalitāti, ļaujot lietotājiem kontrolēt, kā viņu līdzekļi tiek tērēti turpmākajos darījumos.
Iespējojot Script interpretēt darījumu datus, mēs efektīvi izveidojam veidu, kā šos datus izmantot līgumu loģikā.
Šie ir tikai daži no interesantākajiem paktu funkcionalitātes introspekcijas opkodiem:
OP_TXHASH: nodrošina darījuma ievades (vai izvades) jaukšanu un dod skriptam iespēju pārbaudīt un izpildīt nosacījumus, pamatojoties uz darījumu datiem.
OP_CSFS + OP_CAT: abi kopā ļauj skriptiem pārbaudīt parakstus pret jebkuriem datiem, ne tikai pašu darījumu. Tas nozīmē, ka skripts var pārbaudīt nosacījumus, pamatojoties uz darījumu datiem vai ārēju informāciju, paplašinot validācijas iespējas Bitcoin skriptos.
Šie divi opkodi ir apzināti plaši, nodrošinot sarežģītus validācijas procesus un pašpārbaudes iespējas. Citas ir šaurākas, un tās ir paredzētas ierobežotākai derību formai.
OP_CHECKTEMPLATEVERIFY (CTV): ļauj darījuma izvadē iegult nākotnes tēriņu darījuma veidni, ļaujot noslēgt līgumus ierobežotākā veidā.
OP_VAULT: iespējo īpašu līguma formu, ko izmanto “velvēm”, kas ļauj lietotājiem norādīt darījuma galamērķi, bet nepārvietot monētas, izņemot gadījumus, kad notiek aizkave.
Tad ir OP_CAT pats par sevi, kas nav tieši introspekcijas opkods…
OP_CAT: ļauj skriptam savienot divus elementus stekā, kas ir noderīgi, lai skriptā apvienotu dažādas informācijas daļas.
Šķiet, ka OP_CAT nav pašpārbaudes spēju, tāpēc kas šeit notiek?
OP_CAT: visu iespēju atšķetināšana
Darījuma pašpārbaude
2021. gadā Endrjū Poelstra emuāra ierakstā rakstīja par OP_CAT pašpārbaudes trikiem. Viņš sniedza konkrētus piemērus, bet domāja, ka lasītājiem bija iepriekšējas zināšanas par līdzīgām metodēm. Šeit es centīšos vienkāršot šo skaidrojumu labākai izpratnei.
Bitcoin skriptā ir tikai trīs primārie operācijas kodi, kas ļauj pārbaudīt darījuma datus: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY un CHECKSIG. Turklāt ir tādi varianti kā CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG un CHECKMULTISIGVERIFY, kas būtībā ir nelielas CHECKSIG variācijas. Pirmie divi tikai ļauj redzēt, vai pārbaude ir pārbaudīta, nodrošinot diezgan šauru funkcionalitāti. CHECKSIG ir līdzīgs, taču šeit atšķirība ir tāda, ka tas ļauj satvert steka parakstu un publisko atslēgu. Interesanti.
Tradicionāli mēs uzskatām, ka savienošana ir funkcija, kas savieno divus vienumus, taču mēs varam to izmantot arī, lai atdalītu vai sadalītu vienumu, šajā gadījumā parakstu (r, s) pārī.
Kā mēs iegūstam OP_SPLIT funkcionalitāti no OP_CAT?
“Ja jums ir kāds liels objekts, varat to sadalīt divās daļās, lūdzot lietotājam pavadīt laiku, lai nodrošinātu abus gabalus. Jūs tos saskatāt kopā un pārbaudāt vienlīdzību būtībā. Jūs vienmēr varat apgriezt katru darbību šādā veidā. Izmantojot CAT, jūs varat izjaukt parakstus. — Endrjū Poelstra, TABConf 2021
Kas te notiek?
Pieprasot lietotājam nodrošināt parakstu, publisko atslēgu un transakciju, varat sadalīt parakstu tā sastāvdaļās, pēc tam katru daļu atsevišķi pārbaudot, salīdzinot ar darījuma datiem. Šo paņēmienu var uzskatīt par sadalīšanas vai apvienošanas veidu, jo tas apstiprina, ka paraksts un publiskā atslēga patiešām ir derīga darījuma sastāvdaļas.
Kā tas viss mums rada pašpārbaudi?
“Taproot, kur mums ir Schnorr paraksti, izmantojot OP_CAT un Schnorr paraksta verifikācijas operācijas kodu, izrādās, ka ir iespējams iegūt nerekursīvas derības formu, kurā jūs burtiski iegūstat darījuma jaucējkodu. Pat ne kā jocīgs sajaukts transakciju jaucējvārds, bet gan burtisks SHA2 jaukums no visiem darījumu datiem uz steku. — Endrjū Poelstra, TABConf 2021
Turpinājumā Poelstra demonstrē, kā var iegūt SHA2 jaucējkodu stekā atstātajām transakciju ievadēm vai izvadēm. Šeit mēs izlaidīsim mēness matemātiku, taču tas nozīmē, ka, izmantojot OP_CAT, mēs varam ierobežot darījuma daļas kā atbloķēšanas skripta prasību. Mēs varam ierobežot šī darījuma nosūtīšanas adresi vai vērtību, kur darījuma jaucējkods kalpo kā atslēga tā atbloķēšanai.
Velves
Izmantojot tos pašus paņēmienus, mēs varam ieskatīties darījumos un ātri iegūt glabātuvju pamata versiju. Ievērojot Poelstra emuārā izklāstīto loģiku, izstrādātājs Rijndael pierādīja, ka mēs to varam izdarīt tikai ar OP_CAT, ieviešot Purrfect Vaults.
"Atkārtoti izveidot TXID kaudzē, lai izpētītu iepriekšējos darījumus, patiesībā bija vieglāk, nekā es gaidīju." — Rijndaels
Izmantojot glabātuves, lietotāji norāda nākamo adresi, uz kuru ir jānonāk saviem līdzekļiem, nodrošinot līdzekļu atgūšanas mehānismus atslēgas kompromisa gadījumā un samazinot privātās atslēgas zādzības stimulu.
Merkles koki scenārijam
Mūsdienās Bitcoin Merkle koki ir datu struktūra, ko izmanto datu pārbaudei, sinhronizēšanai un vairāk vai mazāk blokķēdes darījumu un bloku “savienošanai”. OP_CAT operētājsistēmu kods, kas ļauj savienot divus steka mainīgos, ja to izmanto kopā ar publisko atslēgu SHA256 jaucējkodiem, atvieglo vienkāršu Merkle koka verifikācijas procesu skriptiem. Šī pieeja, ko sākotnēji ierosināja Pieter Wuille 2015. gadā, tika veiksmīgi ieviesta Liquid tīklā.
Iedomājieties koka struktūru, kas ir piepildīta ar dažādiem tērēšanas nosacījumiem, piemēram, jaucējattēli, laika bloķēšana un publiskās atslēgas, kas pazīstamas kā koka paraksti.
Koku paraksti
OP_CAT ļauj izveidot koka parakstus, kas:
“…Nodrošiniet vairāku parakstu skriptu, kura lielums var būt logaritmisks publisko atslēgu skaitā un var kodēt izdevumu nosacījumus, kas pārsniedz n-m. Piemēram, darījums, kura izmērs ir mazāks par 1 KB, varētu atbalstīt koka parakstus ar tūkstoš publiskajām atslēgām. Tas nodrošina arī vispārējus loģiskus izdevumu nosacījumus. — BIP autors Ītans Heilmans, bitcoin-dev adresātu sarakstā
Tas ļautu validēt jebkuru jauktu saturu kokā, saglabājot datu integritāti un uzticamību, nepievienojot blokķēdei nevajadzīgu masīvu vai uzpūšanos.
Kas tajā visā ir interesants?
Rekursīvie līgumi
Ja jums ir iespēja pārbaudīt darījumu un piemērot ierobežojumus noteiktām tā daļām, varat iestatīt nosacījumus, kas tiek pārnesti uz vairākiem darījumiem, efektīvi izveidojot pastāvīgu ierobežojumu ķēdi. Šo koncepciju sauc par rekursīvo derību. OP_CAT ir unikāls piedāvājums, jo tas dod mums tik daudz jaudas tikai 10 jaunām koda rindām. Tam ir iespēja novērst visus trīs sākotnējos ierobežojumus, kurus mēs apskatījām ziņojuma sākumā: darījumu datu redzamību, labāku matemātisko funkcionalitāti un tā lineāro izpildes modeli.
Lai gan sākumā OP_CAT var šķist vienkāršs, tas atklāj ievērojamu potenciālu, ja to radoši izmanto. Tas kalpo kā pamats vēl lielākai funkcionalitātei, kas pārsniedz šīs diskusijas darbības jomu, piemēram, Post-Quantum Lamport Signatures.
Vai tas ir drošs?
Pirms OP_CAT sākotnējās noņemšanas, apvienojot to ar OP_DUP (dublikātu) un atkārtoti izmantojot, lai dublētu sākotnēji 1 baita vērtību stekā, atmiņas lietojumam varēja palielināties. To varēja izmantot kā pakalpojumu atteikuma (DoS) uzbrukumu palielināta atmiņas patēriņa dēļ. Jaunais priekšlikums triviāli novērš šo uzbrukumu, steka elementiem nosakot 520 baitu ierobežojumu.
Vai pastāv risks, ka līgums stāsies spēkā uz visiem laikiem?
Ja ar to mēs domājam, vai OP_CAT maina skripta izpildes modeli, lai nozīmētu, ka tas vairs statiski neierobežo tā resursu izmantošanu (kā skripta lieluma lineāru funkciju)? Nē.
Vai līgumi radītu tirgu citām monētām papildus Bitcoin?
Ja jums ir rekursīvs līgums, jā, varat tehniski izveidot sarežģītas 2. slāņa lietojumprogrammas, tostarp NFT, decentralizētas apmaiņas un kvantu kaķus. Tomēr to darīt nav triviāli. Ir grūti redzēt, ka nopietni tirgi to darītu.
Vai var neatgriezeniski “sabojāt” monētas, izmantojot CAT?
Krāsainu monētu un NFT gadījumā, izlaižot šos līdzekļus, lietotājs faktiski “sadedzina” satoshi, atzīmējot to tādā veidā, kas nozīmē “2. slāņa” īpašuma īpašumtiesības. Šis process ir pazīstams kā monētu “aptraipīšana”. Bet tikai monētas īpašnieks var atzīmēt savu monētu, un Bitcoin maki vairs to neatpazīs (ja vien to autori nepārprotami pievieno kodu, lai to iespējotu). Rezultātā iegūtās monētas netiktu pieņemtas bitkoinu makos. Droši vien tos pieņemtu kriptonauda maki vai kaut kas tamlīdzīgs, taču lielākajai daļai bitcoin lietotāju tas nav būtiski.
Vai tas radītu MEV problēmu Bitcoin?
Galvenais atšķirības punkts starp Bitcoin un Ethereum ir darījumu redzamība. Atšķirībā no Ethereum, ne visi līguma aspekti obligāti ir pārredzami, kas nozīmē, ka Bitcoin kalnračiem nav tādas pašas iespējas redzēt iekšējo līguma stāvokli un tos vadīt.
Galvenās bažas par OP_CAT ekonomiski domājošiem Bitcoiners ir Miner Extractable Value (MEV) potenciāls. Kā plašāk apspriests manā iepriekšējā ierakstā par šo tēmu. Daudzi lietotāji ir nobažījušies, ka, ja mēs padarīsim 2. slāņa līgumus tehniski iespējamus, MEV kļūs neizbēgams. Bet vai tā ir taisnība? Konkrēti, vai Bitcoin 2. slāņa monētu tehniskā iespējamība nozīmē to neizbēgamu izveidi un pieņemšanu?
Varētu iedomāties vienkāršu mijmaiņas līgumu vai salīdzinoši neefektīvu NFT veidošanu, taču kaut ko tik sarežģītu kā DEX izveide kopā ar automātiskajiem tirgus veidotājiem šķiet ārkārtīgi maz ticama, un to mēs nekad neesam redzējuši Liquid, neskatoties uz tā “tehniskajām iespējām”.
Vai OP_CAT tiešām ir ideāls?
Diez vai, tālu no tā. Daži cilvēki labprāt redzētu rekursīvas derības, savukārt citi vienkārši nevēlas redzēt Bitcoin izmaiņas vispār.
Bitcoineru grupa, “ossifikācijas piekritēji”, iestājas par Bitcoin saglabāšanu tā pašreizējā stāvoklī un uz visiem protokola jauninājumiem raugās ar skepsi. Viņi ir īpaši nobažījušies par to, ka būtiskas izmaiņas, piemēram, paktu ieviešana, var apdraudēt tīkla decentralizāciju. Viņu arguments ir atkarīgs no pārliecības, ka vislabāk ir stingri ievērot Bitcoin sākotnējo redzējumu. Ironija, ka OP_CAT sākotnēji bija daļa no Bitcoin, rada pretargumentu. Daži uzskata, ka OP_CAT atgriešana faktiski varētu saskaņot Bitcoin ar Satoshi sākotnējo redzējumu.
Ja vēlaties redzēt dažus drošības līdzekļus, ko varētu nodrošināt rekursīvie līgumi, OP_CAT būtu jauka, taču noteikti ne tik jauka kā pilna Lisp-esque skriptu valoda. Problēma ir tāda, ka tās būtu milzīgas izmaiņas Bitcoin, kas, visticamāk, tuvākajā laikā neatradīs pamatu.
Vai varbūt jūs atrodaties otrā galā un vēlaties izmantot nerekursīvu vienkāršību, piemēram, OP_CTV vai OP_VAULT. Nerekursīvie līgumi ir vienkāršāki un vieglāk pamatoti, neriskējot izveidot nekontrolētu ierobežojumu ķēdi.
Kā būtu, ja kāda rekursīvo derību versija būtu neizbēgama?
Gadu gaitā izstrādātāji ir pamanījuši, ka gandrīz jebkuru darījumu validācijas loģikas paplašinājumu var izmantot, lai atdarinātu OP_CAT funkcionalitāti.
Skriptu visumā ir divas sfēras, kuru pamatā ir kaudzes elementu lielums. Ja steka elementi ir lielāki par 4 baitiem, varat salīdzināt, vai tie ir vienādi, kā atslēgu interpretēt parakstu vai jaukt to. Ja steka elementi ir mazāki vai vienādi ar 4 baitiem, varat tos uzskatīt par objektiem aritmētikas vai sazarošanas veikšanai. Ar RISC-V procesoru, kas darbojas uz BitVM, jūs varat darīt jebko. Jebkas, kas ļauj atdarināt OP_CAT, sadalīt kaudzes elementus vai savienot tos kopā, apvieno šīs divas jomas, lai ar Script jūs varētu “darīt jebko”.
Pētnieki, piemēram, Endrjū Poelstra, sagaida, ka mēs varētu noslēgt rekursīvus līgumus ar gandrīz jebkuru jaunu opkodu. Ja tā ir taisnība, tas būtu attaisnojums, lai strādātu pie tā, lai tās paveiktu labi.
Vai OP_CAT ir iespējamais derību ceļš?
Ja līgumi ir ne tikai interesanti, bet arī neizbēgami, kā mēs nodrošinām to īstenošanu tā, lai vairāk Bitcoin lietotāju sūtītu neuzticamus ziņojumus, kā sākotnēji bija iecerēts Satoši? Lai gan osifikācijas piekritēji joprojām ir sadalīti, OP_CAT joprojām turpina izvirzīties kā spēcīgs sāncensis debatēs par derībām.
OP_CAT nav elegantākais kalts, taču tam ir vislabākā jaudas un sarežģītības attiecība, kas ļautu izstrādātājiem izveidot dažas pārsteidzošas jaunas funkcijas.
Šis ir Kiara Bickers viesa ieraksts. Izteiktie viedokļi ir pilnībā viņu pašu un ne vienmēr atspoguļo BTC Inc vai Bitcoin Magazine viedokļus.
Avots: Bitcoin Magazine
Ziņa OP_CAT: The Purr-fect Solution for Covenants? pirmo reizi parādījās Crypto Breaking News.