Bitcoinin Layer 2 -verkon Graalin malja: Introspection and Covenants

cd

Verrattuna Ethereumin kaltaisiin Turingin täydellisiin lohkoketjuihin Bitcoinin skriptikieli on huomattavasti rajoittunut, sillä se pystyy vain perustoimintoihin, ja siitä puuttuvat jopa kerto- ja jakotoiminnot. Vielä tärkeämpää on se, että lohkoketjun oma data on lähes käsikirjoitusten ulottumattomissa, mikä johtaa vakaviin rajoituksiin joustavuudessa ja ohjelmoitavuudessa. Tämän vuoksi ihmiset ovat jo pitkään etsineet keinoja, joilla Bitcoin-skripteille voitaisiin mahdollistaa itsetutkiskelu.

Itsetutkiskelu viittaa Bitcoin skriptit tarkastaa ja rajoittaa transaktiotietoja. Näin skriptit voivat valvoa varojen käyttöä tiettyjen transaktiotietojen perusteella, mikä mahdollistaa monimutkaisemmat toiminnallisuudet. Tällä hetkellä useimmat Bitcoin-opcodit joko työntävät käyttäjän antamia tietoja pinoon tai manipuloivat pinossa jo olevia tietoja. Introspection-opcodeilla voidaan kuitenkin työntää pinoon nykyisiä transaktiotietoja (kuten aikaleimoja, summia ja transaktiotunnuksia), mikä mahdollistaa UTXO-käytön tarkemman hallinnan.

Bitcoin-skripteissä on tällä hetkellä vain kolme tärkeintä opkoodia, jotka tukevat introspektiota: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY ja CHECKSIG. CHECKSIGillä on useita muunnelmia, kuten CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG ja CHECKMULTISIGVERIFY.

Sopimukset on rajoituksia sen suhteen, miten rahakkeita voidaan siirtää. Käyttäjät voivat määritellä UTXO:iden jakelutavan sopimuksilla, joista monet on toteutettu käyttämällä introspection-opcodeja. Tällä hetkellä Bitcoin Optech luokittelee introspectionin covenant-merkintöjen alle.

Bitcoinilla on tällä hetkellä kaksi kovenanttia: CSV (CheckSequenceVerify) ja CLTV (CheckLockTimeVerify), jotka molemmat ovat aikapohjaisia kovenantteja ja muodostavat perustan monille skaalausratkaisuille, kuten Lightning Networkille. Tämä osoittaa, että Bitcoinin skaalautumisratkaisut tukeutuvat vahvasti itsetarkkailuun ja covenantteihin.

Kuinka lisätä ehtoja Token-siirtoihin

Kryptomaailmassa yleisin menetelmä on sitoumukset, joka toteutetaan usein hashien avulla. Siirtoehtojen täyttymisen todistamiseksi käytetään allekirjoituksia. Tämän vuoksi kovenantteihin liittyy lukuisia hashien ja allekirjoitusten mukautuksia.

Seuraavat ovat laajalti keskusteltuja ehdotuksia liiton opkoodeiksi:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), joka sisältyy BIP-119″>BIP-119, on erittäin kiistelty Bitcoin-päivitys. CTV:n avulla lähtöskriptit voivat määrittää malleja kulutustapahtumille, mukaan lukien kentät, kuten nVersion, nLockTime, scriptSig hash, input count, sequences hash, output count, outputs hash ja input index. Nämä mallirajoitukset toteutetaan hash-sitoumuksen avulla, ja tulevat kulutusskriptit tarkistavat, vastaavatko kulutustapahtuman määritettyjen kenttien hash-arvot syöttöskriptin kenttien arvoja. Nämä mallit määrittelevät lähinnä tulevien UTXO-tapahtumien ajankohdan, menetelmän ja määrän.

Syötetty TXID-tunnus jätetään hash-sitoumuksen ulkopuolelle. Tämä poissulkeminen on tarpeen, koska TXID riippuu scriptPubKey-arvosta sekä Legacy- että Segwit-tapahtumissa, kun käytetään oletusarvoista SIGHASH_ALL-allekirjoitustyyppiä. TXID:n sisällyttäminen aiheuttaisi ympäripyöreän riippuvuuden, jolloin hash-sitoumuksen rakentaminen olisi mahdotonta.

CTV:n avulla saavutetaan sisäinen tarkastelu hankkimalla suoraan määritetyt tapahtumatiedot uuden operaatiokoodin avulla, muuttamalla ne hakkeroimalla ja vertaamalla niitä pinossa olevaan sitoumukseen. Tämä menetelmä kuluttaa vähemmän ketjussa olevaa tilaa, mutta ei ole kovin joustava.

Lightning Networkin kaltaisten toisen tason ratkaisujen perustana ovat ennalta allekirjoitetut transaktiot. Esiallekirjoitus tarkoittaa yleensä transaktioiden luomista ja allekirjoittamista etukäteen, mutta niiden lähettämistä vasta tiettyjen ehtojen täyttyessä. CTV:ssä toteutetaan periaatteessa tiukempi esisignaustoiminto, joka julkaisee esisignoidun sitoumuksen suoraan ketjussa ja sallii transaktiot vain ennalta määritellyn mallin mukaisesti.

CTV:tä ehdotettiin alun perin Bitcoin-verkon ruuhkautumisen lieventämiseksi, ja sitä voidaan kutsua myös ruuhkanhallinnaksi. Korkean ruuhkautumisen aikana CTV voi sitoa useita tulevia transaktioita yhdellä transaktiolla, jolloin vältytään useiden transaktioiden lähettämiseltä ruuhkautumisen aikana ja varsinaisten transaktioiden suorittamiselta ruuhkautumisen hellitettyä. Tämä voisi auttaa merkittävästi vaihtoaikojen aikana. Lisäksi malleja voidaan käyttää holvien toteuttamiseen, mikä estää hakkerihyökkäykset, koska varojen määränpää on ennalta määrätty, jolloin hakkerit eivät voi lähettää UTXO-operaatioita CTV-skriptin avulla omiin osoitteisiinsa.

CTV voi parantaa merkittävästi toisen kerroksen verkkoja. Esimerkiksi Lightning-verkossa aikakatkaisupuiden ja kanavatehtaiden toteuttaminen CTV:n avulla mahdollistaa sen, että yksi UTXO voi laajentua CTV-puuksi ja avata useita tilakanavia vain yhdellä ketjussa tapahtuvalla transaktiolla ja vahvistuksella. Lisäksi CTV tukee atomitransaktioita (ATLC) Ark-protokollassa.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 ehdottaa tapscriptille uutta allekirjoituksen hash-lippua nimeltä SIGHASH_ANYPREVOUT, jolla helpotetaan joustavamman menologiikan kirjoittamista. APO ja CTV ovat monin tavoin samankaltaisia. APO:n ratkaisu scriptPubKeys- ja TXID-tunnusten väliseen ympyrämäiseen riippuvuuteen on jättää asiaankuuluvat syöttötiedot pois ja allekirjoittaa vain ulostulo, jolloin transaktiot voivat dynaamisesti sitoutua eri UTXO-tunnuksiin.

Loogisesti tarkastustoiminnolla OP_CHECKSIG (ja siihen liittyvillä op-koodeilla) on kolme tehtävää:

  1. Kootkaa menotapahtuman osat.
  2. Hash nämä osat.
  3. Tarkistaa, onko hash allekirjoitettu annetulla avaimella.

Allekirjoituksen sisältöä voidaan mukauttaa huomattavasti, ja SIGHASH-lippulause määrittää, mitkä tapahtumakentät allekirjoitetaan. BIP 342:n allekirjoituksen opkoodien määritelmän mukaan SIGHASH-lippuja ovat muun muassa SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE ja SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY ohjaa tuloa, kun taas muut ohjaavat lähtöä.

SIGHASH_ALL on oletusarvoinen SIGHASH-lippu, joka allekirjoittaa kaikki lähdöt. SIGHASH_NONE ei allekirjoita mitään ulostuloja, ja SIGHASH_SINGLE allekirjoittaa vain tietyn ulostulon. SIGHASH_ANYONECANPAY voidaan asettaa yhdessä kolmen muun lipun kanssa, ja jos se on asetettu, se allekirjoittaa vain määritetyn tulon; muutoin kaikki tulot on allekirjoitettava.

Mikään näistä SIGHASH-lipuista ei voi poistaa syötteiden vaikutusta. Jopa SIGHASH_ANYONECANPAY edellyttää sitoutumista yhteen panokseen.

Sen vuoksi BIP 118:ssa otetaan käyttöön SIGHASH_ANYPREVOUT. APO-allekirjoitusten ei tarvitse sitoutua käytettyyn tulo-UTXO:hon (nimeltään PREVOUT), vaan ainoastaan ulostulon allekirjoittamiseen, mikä tarjoaa enemmän joustavuutta Bitcoinin valvonnassa. Kun transaktiot rakennetaan etukäteen ja luodaan vastaavat kertakäyttöiset allekirjoitukset ja julkiset avaimet, kyseiseen julkisen avaimen osoitteeseen lähetetyt varat on käytettävä etukäteen rakennetun transaktion kautta, jolloin saavutetaan liitto.

APO:n joustavuutta voidaan käyttää myös tapahtumien korjaamiseen. Jos transaktio juuttuu ketjuun alhaisen maksun vuoksi, voidaan helposti luoda uusi transaktio maksun korottamiseksi ilman uusia allekirjoituksia. Lisäksi usean allekirjoituksen lompakoissa allekirjoitukset, jotka eivät ole riippuvaisia käytetystä panoksesta, yksinkertaistavat toimintaa.

Poistamalla scriptPubKeys- ja syöttö TXID-tunnisteiden välisen ympyrämäisen riippuvuuden APO voi toteuttaa sisäisen tarkastelun lisäämällä todistajassa olevia lähtötietoja, vaikka tämä vaatii edelleen lisää todistajan tietovarantoa.

APO vähentää Lightning Networkin ja holvien kaltaisten ketjun ulkopuolisten protokollien osalta välitilojen tallennustarvetta, mikä vähentää merkittävästi varastointivaatimuksia ja monimutkaisuutta. APO:n suorin käyttötapaus on Eltoo, joka yksinkertaistaa kanavatehtaita, rakentaa kevyitä ja edullisia vartiotorneja ja mahdollistaa yksipuoliset poistumiset jättämättä virheellisiä tiloja, mikä parantaa Lightning Networkin suorituskykyä. APO voi simuloida CTV:n toiminnallisuutta, vaikka se edellyttää allekirjoitusten ja esisignoitujen transaktioiden henkilökohtaista tallennusta, mikä tekee siitä kalliimman ja tehottomamman kuin CTV.

APO:n tärkein kritiikki on se, että se tarvitsee uuden avainversion, minkä vuoksi se ei ole yhteensopiva nykyisten järjestelmien kanssa. Lisäksi uusi allekirjoituksen hash-tyyppi saattaa aiheuttaa mahdollisia kaksinkertaisen kuluttamisen riskejä. Yhteisön laajojen keskustelujen jälkeen APO vaatii nyt alkuperäisen allekirjoituksen lisäksi tavallisen allekirjoituksen, mikä lieventää turvallisuusongelmia ja ansaitsee BIP-118-numeronsa.

OP_VAULT BIP-345

BIP-345 ehdottaa kahta uutta opkoodia, OP_VAULT ja OP_VAULT_RECOVER, jotka toimivat CTV:n kanssa ja toteuttavat erityisen sopimuksen, joka pakottaa tietyn viiveen tiettyjen merkkien käyttämiseen, jonka aikana käyttö voidaan ”peruuttaa” palautuspolun kautta.

Käyttäjät voivat luoda holvin määrittämällä tietyn Taproot-osoitteen ja sisällyttämällä MASTiin vähintään kaksi skriptiä: OP_VAULT-skripti helpottamaan odotettua nostoprosessia ja OP_VAULT_RECOVER-skripti varmistamaan kolikoiden palauttamisen ennen nostojen päättymistä.

Miten OP_VAULT toteuttaa keskeytyksettömät, aikarajoitetut nostot?

Yksinkertaisesti sanottuna OP_VAULT-toimintokoodi korvaa käytetyn OP_VAULT-skriptin määritetyllä skriptillä, jolloin MASTin yksi lehtisolmu päivittyy ja muut solmut säilyvät ennallaan. Tämä on samanlainen kuin TLUV, mutta ei tue sisäisten avainten päivityksiä.

Mallin käyttöönotto komentosarjapäivitysten aikana voi rajoittaa maksujen vaikutuksia. Aikasulkuparametri määritetään OP_VAULT-parametrilla, kun taas CTV-op-koodin tuoma malli rajoittaa kyseisen komentosarjapolun kautta käytettyjä ulostuloja.

BIP-345 on suunniteltu holveja varten, jotta käyttäjät voivat käyttää erittäin turvallista palautusreittiä (paperilompakko, hajautettu moninkertainen allekirjoitus) ja samalla määrittää viiveen rutiinimaksuille. Käyttäjän laite valvoo jatkuvasti holvin rahankäyttöä, mikä mahdollistaa palautuksen, jos luvaton siirto tapahtuu.

Holvien käyttöönotto BIP-345:n avulla edellyttää maksukysymysten tarkastelua erityisesti perintätoimien osalta. Mahdollisia ratkaisuja ovat CPFP (Child Pays for Parent), väliaikaiset ankkurit ja uudet allekirjoituksen hash-liput, kuten SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

TLUV-järjestelmä perustuu Taproot-järjestelmään, ja sen tarkoituksena on ratkaista ongelma, joka liittyy tehokkaaseen poistumiseen jaetuista UTXO-yksiköistä. Pääperiaatteena on, että kun Taproot-ulostulo on käytetty, voimme käyttää Taproot-osoitteen sisäistä rakennetta ja kryptografisia muunnoksia sisäisen avaimen ja MASTin osittaiseen päivittämiseen TLUV-skriptissä kuvattujen päivitysvaiheiden mukaisesti, jolloin saavutetaan sopimustoiminnallisuus.

TLUV-järjestelmän ideana on luoda uusi Taproot-osoite nykyisten menojen syötteen perusteella uuden opkoodin TAPLEAF_UPDATE_VERIFY avulla, joka voi suorittaa yhden tai useamman seuraavista toiminnoista:

TLUV ottaa vastaan kolme syötettä:

  1. Määrittely siitä, miten sisäinen julkinen avain päivitetään.
  2. Merkle-polun uusi lehtisolmu.
  3. Määritelmä siitä, poistetaanko nykyinen lehtisolmu ja/tai kuinka monta Merkle-polun lehtisolmua poistetaan.

TLUV-toimintokoodi laskee päivitetyn scriptPubKey-avaimen ja tarkistaa, käytetäänkö nykyistä syötettä vastaava tuloste kyseiseen scriptPubKey-avaimeen.

TLUV:n inspiraationa ovat kolikkopelit. Nykyään yhteisiä pooleja voidaan luoda käyttämällä ennalta allekirjoitettuja transaktioita, mutta jos halutaan saavuttaa luvattomat poistumiset, on luotava eksponentiaalisesti kasvava määrä allekirjoituksia. TLUV mahdollistaa luvattomat poistumiset ilman ennalta allekirjoitettuja transaktioita. Esimerkiksi joukko kumppaneita käyttää Taprootia rakentaakseen yhteisen UTXO:n ja yhdistääkseen varansa. He voivat siirtää varoja sisäisesti Taproot-avaimella tai tehdä ulkoisia maksuja yhteisellä allekirjoituksella. Yksittäiset henkilöt voivat poistua jaetusta poolista milloin tahansa, jolloin heidän maksupolkunsa poistuu, kun taas muut voivat jatkaa maksujen suorittamista alkuperäistä polkua pitkin ilman, että jäljelle jäävistä jäsenistä paljastuu lisätietoja. Tämä menetelmä on tehokkaampi ja yksityisempi kuin maksutapahtumat, joita ei ole yhdistetty.

TLUV-toimintokoodilla saavutetaan osittaiset menorajoitukset päivittämällä alkuperäinen MAST. Sillä ei kuitenkaan saavuteta lähdemäärien sisäistä tarkastelua. Siksi tarvitaan uusi opkoodi IN_OUT_AMOUNT, joka työntää pinoon kaksi tietoa: tämän tulon UTXO:n määrän ja vastaavan lähtömäärän. TLUV:tä käyttävän henkilön odotetaan tämän jälkeen käyttävän matemaattisia operaattoreita sen tarkistamiseksi, että varat on säilytetty asianmukaisesti päivitetyssä scriptPubKey:ssä.

Lähtömäärien tarkastelu lisää monimutkaisuutta, koska Bitcoin-määrät esitetään satosheina ja vaativat jopa 51 bittiä, mutta skriptit sallivat vain 32-bittiset matemaattiset operaatiot. Tämä edellyttää skriptin operaattoreiden päivittämistä määrittelemällä opkoodien käyttäytyminen uudelleen tai käyttämällä SIGHASH_GROUPia IN_OUT_AMOUNTin korvaamiseksi.

TLUV:n odotetaan tarjoavan ratkaisuja hajautettuihin Layer 2 -kolikkopooleihin, vaikka luotettavuus Taprootin julkisten avainten virittämisen osalta vaatii vielä vahvistusta.

MATT

MATT (Merkleize All The Things) pyrkii saavuttamaan kolme tavoitetta: Merkleizing state, Merkleizing scripts ja Merkleizing execution, jolloin saavutetaan yleiset älykkäät sopimukset.

MATT:n saavuttamiseksi Bitcoin-ohjelmointiskripteillä on oltava seuraavat toiminnot:

  1. Tiettyjen käsikirjoitusten pakottaminen tuotokseen (ja niiden määrät)
  2. Tietojen liittäminen lähtöön
  3. Tietojen lukeminen nykyisestä tulosta (tai muista tuloista).

Toinen kohta on ratkaisevan tärkeä, sillä dynaamiset tiedot mahdollistavat tilan laskennan lähettäjän antamien syöttötietojen avulla, simuloivat tilakonetta ja päättävät seuraavasta tilasta ja siihen liitetyistä tiedoista. MATT ehdottaa OP_CHECKCONTRACTVERIFY (OP_CCV) op-koodia, joka on yhdistelmä aiemmin ehdotetuista OP_CHECKOUTPUTCONTRACTVERIFY- ja OP_CHECKINPUTCONTRACTVERIFY-op-koodeista, ja siinä on lisäksi lippuparametri, jolla määritetään operaation kohde.

Tuotantomäärien valvonta: Suorin tapa on suora itsetutkiskelu. Lähtömäärät ovat kuitenkin 64-bittisiä lukuja, jotka vaativat 64-bittisiä operaatioita, mikä lisää monimutkaisuutta Bitcoin-skriptin toteutukseen. CCV ottaa käyttöön OP_VAULTin kaltaisen viivästetyn tarkistuksen, jossa kaikkien tulojen tulomäärät lasketaan yhteen samaan lähtöön, jossa CCV on kyseisen lähtömäärän alaraja. Tarkastus viivästetään transaktioprosessiin sen sijaan, että se tehtäisiin syöttöskriptin arvioinnin aikana.

Petostodisteiden yleisyys huomioon ottaen joillakin MATT-sopimusten muunnelmilla pitäisi saavuttaa kaikenlaiset älykkäät sopimukset tai Layer 2 -rakenteet, vaikka lisävaatimukset (kuten pääoman lukittuminen ja haastejakson viiveet) edellyttävät tarkkaa arviointia. Lisätutkimusta tarvitaan sen arvioimiseksi, mitkä sovellukset ovat hyväksyttäviä transaktioita. Esimerkiksi kryptografisten sitoumusten ja petosten haastemekanismien käyttäminen OP_ZK_VERIFY-toimintojen simuloimiseksi, jolloin saavutetaan luotettavat Rollupit Bitcoinissa.

Käytännössä asiat ovat jo tapahtumassa. Johan Torås Halseth toteutti elftracen käyttämällä MATT soft fork -ehdotuksen OP_CHECKCONTRACTVERIFY-opkoodia, jonka avulla kaikki RISC-V-kääntämisen tukemat ohjelmat voidaan tarkistaa Bitcoin-ketjussa, mikä mahdollistaa natiivit Bitcoin-verifikaatiosillat sopimusprotokollien osalta.

CSFS (OP_CHECKSIGFROMSTACK)

APO-toimintokoodin esittelystä tiedämme, että OP_CHECKSIG (ja siihen liittyvät operaatiot) vastaa transaktioiden kokoamisesta, hajauttamisesta ja allekirjoituksen tarkistamisesta. Sen varmentama viesti johdetaan kuitenkin transaktion sarjallistamisesta tätä op-koodia käyttäen, eikä muita viestejä voida määrittää. Yksinkertaisesti sanottuna OP_CHECKSIG (ja siihen liittyvät operaatiot) palvelee sen todentamista, että UTXO transaktion syötteenä on valtuutettu käyttämään allekirjoituksen haltija, mikä suojaa Bitcoinin turvallisuutta.

CSFS tarkistaa nimensä mukaisesti allekirjoitukset pinosta. CSFS-operaatiokoodi ottaa pinosta kolme parametria: allekirjoituksen, viestin ja julkisen avaimen, ja tarkistaa allekirjoituksen pätevyyden. Tämä tarkoittaa, että mikä tahansa viesti voidaan välittää pinoon todistajatietojen kautta ja CSFS voi tarkistaa sen, mikä mahdollistaa joitakin Bitcoiniin liittyviä innovaatioita.

CSFS:n joustavuus mahdollistaa erilaisten mekanismien, kuten maksujen allekirjoitusten, valtuuksien delegoinnin, oraakkelisopimusten ja kaksoiskulujen suojausjoukkovelkakirjojen, ja mikä tärkeintä, tapahtumien sisäisen tarkastelun, toteuttamisen. CSFS:ää käyttävän transaktioiden sisäisen tarkastelun periaate on hyvin yksinkertainen. Jos OP_CHECKSIG:n käyttämä tapahtumasisältö työnnetään pinoon todistajan kautta ja samaa julkista avainta ja allekirjoitusta käytetään sekä CSFS:n että OP_CHECKSIG:n varmentamiseen, ja jos molemmat läpäisevät sen, minkä tahansa CSFS:lle välitettävän viestin sisältö on sama kuin OP_CHECKSIG:n epäsuorasti käyttämä sarjallistettu kulutustapahtuma (ja muut tiedot). Tämän jälkeen saamme pinossa olevat tarkistetut tapahtumatiedot, joita voidaan käyttää rajoitusten soveltamiseen kulutustapahtumaan muilla op-koodeilla.

CSFS esiintyy usein yhdessä OP_CATin kanssa, koska OP_CAT voi ketjuttaa tapahtuman eri kenttiä sarjallistamisen loppuunsaattamiseksi, mikä mahdollistaa tapahtuman kenttien tarkemman valinnan sisäistä tarkastelua varten. Ilman OP_CAT:ia skripti ei voi laskea hasheja uudelleen erikseen tarkistettavista tiedoista, joten se voi tarkistaa vain, vastaako hash tiettyä arvoa, eli kolikoita voidaan käyttää vain yhden tietyn transaktion kautta.

CSFS:llä voidaan toteuttaa opkoodeja, kuten CLTV, CSV, CTV, APO, ja se on yleinen introspection-opkoodi, mikä auttaa myös Bitcoinin Layer 2 -skaalausratkaisuja. Sen haittapuolena on se, että se edellyttää allekirjoitetun transaktion täydellisen kopion lisäämistä pinoon, mikä voi kasvattaa merkittävästi niiden transaktioiden kokoa, jotka haluavat käyttää CSFS:ää introspektioon. Sen sijaan CLTV:n ja CSV:n kaltaisilla yhden käyttötarkoituksen introspection-opcodeilla on vähiten yleiskustannuksia, mutta jokaisen uuden erityisen introspection-opcoden lisääminen vaatii konsensuksen muuttamista.

TXHASH (OP_TXHASH)

OP_TXHASH on hyvin suoraviivainen introspection-optiokoodi, jonka avulla operaattori voi valita kentän hashin ja työntää sen pinoon. Tarkemmin sanottuna OP_TXHASH nostaa pinosta txhash-lipun, laskee (merkitty) txhashin lipun perusteella ja työntää tuloksena saadun hashin pinoon.

TXHASHin ja CTV:n samankaltaisuuden vuoksi yhteisössä on käyty laajaa keskustelua näistä kahdesta.

TXHASH voidaan nähdä yleisenä parannuksena CTV:hen, sillä se tarjoaa kehittyneemmän tapahtumamallin, jonka avulla käyttäjät voivat määritellä kulutustapahtuman osia, mikä ratkaisee monia tapahtumamaksuihin liittyviä ongelmia. Toisin kuin muut sopimuskoodit, TXHASH ei edellytä, että todistajalla on kopio tarvittavista tiedoista, mikä vähentää tallennustarvetta entisestään. Toisin kuin CTV, TXHASH ei ole NOP-yhteensopiva, ja se voidaan toteuttaa vain tapscriptillä. TXHASHin ja CSFS:n yhdistelmää voidaan pitää vaihtoehtona CTV:lle ja APO:lle.

TXHASH on sopimusten rakentamisen kannalta helpompi toteuttaa ”additiivisia sopimuksia” työntämällä kaikki transaktiotietojen osat, jotka haluat korjata, pinoon, hassata ne yhteen ja tarkistaa, että tulos vastaa kiinteää arvoa. CTV:llä on helpompi saavuttaa ”vähennysvaikutteiset sopimukset” työntämällä pinoon kaikki ne transaktiodatan osat, jotka halutaan pitää vapaina. Sen jälkeen, käyttämällä liikkuvaa OP_SHA256:ta, alkaen kiinteästä välitilasta, tämä välitila sitouttaa transaktion hash-datan etuliitteen. Vapaat osat hashataan tuohon välitilaan.

TXHASH-määrityksessä määritellyn TxFieldSelector-kentän odotetaan laajentuvan muihin op-koodeihin, kuten OP_TX.

TXHASHiin liittyvä BIP on tällä hetkellä luonnosvaiheessa Githubissa, eikä sille ole vielä annettu numeroa.

OP_CAT

OP_CAT on hieman mystinen op-koodi, jonka Satoshi Nakamoto poisti käytöstä tietoturvaongelmien vuoksi. Se on kuitenkin viime aikoina herättänyt laajaa keskustelua Bitcoin-ytimen kehittäjien keskuudessa, ja siitä on tullut jopa meemi verkkoyhteisössä. Lopulta OP_CAT hyväksyttiin BIP-347:ksi, ja monet kutsuivat sitä todennäköisimmäksi BIP-ehdotukseksi, joka hyväksytään lähitulevaisuudessa.

Todellisuudessa OP_CATin toiminta on hyvin yksinkertaista: se yhdistää kaksi pinossa olevaa elementtiä yhdeksi. Mutta miten tämä mahdollistaa sopimustoiminnallisuuden?

Kahden elementin yhdistäminen vastaa tehokasta kryptografista tietorakennetta, joka tunnetaan nimellä Merkle Trie. Merkle Trie:n rakentaminen vaatii vain ketjutus- ja hashing-operaatioita, jotka molemmat ovat käytettävissä Bitcoin-skripteissä. Siksi OP_CATin avulla voimme teoreettisesti todentaa Merkle-todistuksia Bitcoin-skripteissä, mikä on yleisin kevyt todentamismenetelmä lohkoketjuissa.

Kuten aiemmin mainittiin, CSFS voi käyttää OP_CAT:ia yleisen sopimusjärjestelmän toteuttamiseen. Itse asiassa jopa ilman CSFS:ää Schnorr-allekirjoitusten rakenne mahdollistaa sen, että OP_CAT voi itse toteuttaa transaktioiden sisäisen tarkastelun.

Schnorr-allekirjoituksessa allekirjoitettava viesti koostuu seuraavista kentistä:

Nämä kentät sisältävät tapahtuman tärkeimmät osat. Sijoittamalla ne scriptPubKey- tai witness-kenttään ja käyttämällä OP_CAT- ja OP_SHA256-ohjelmia voimme rakentaa Schnorr-allekirjoituksen ja varmentaa sen OP_CHECKSIG-ohjelmalla. Jos todentaminen onnistuu, pino säilyttää todennetut transaktiotiedot, mikä mahdollistaa transaktion tarkastelun. Näin voimme poimia ja ”tarkastaa” transaktion eri osia, kuten sen syötteet, lähdöt, kohdeosoitteet tai mukana olevat Bitcoin-määrät.

Yksityiskohtaisempia salausperiaatteita on Andrew Poelstran artikkelissa ”CAT and Schnorr Tricks”.

Yhteenvetona voidaan todeta, että OP_CATin joustavuuden ansiosta se pystyy jäljittelemään lähes mitä tahansa sopimuksen op-koodia, ja monet sopimuksen op-koodit ovat riippuvaisia sen toiminnallisuudesta. Tämä parantaa merkittävästi sen asemaa yhdistämisluettelossa. Teoriassa voisimme vain OP_CATin ja olemassa olevien Bitcoin-opcodien avulla rakentaa luottamusta minimoivan BTC ZK Rollupin. Starknet, Chakra ja muut ekosysteemikumppanit työskentelevät aktiivisesti tämän toteuttamiseksi.

Päätelmä

Kun tutkimme erilaisia strategioita Bitcoinin laajentamiseksi ja sen ohjelmoitavuuden parantamiseksi, käy selväksi, että etenemistapaan kuuluu natiivien parannusten, ketjun ulkopuolisen laskennan ja monimutkaisten skriptitoimintojen yhdistelmä.

Ilman joustavaa pohjakerrosta on mahdotonta rakentaa joustavampaa toista kerrosta.

Ketjun ulkopuolisen laskennan skaalautuvuus on tulevaisuutta, mutta Bitcoinin ohjelmoitavuuden on murtauduttava läpi, jotta se tukisi paremmin skaalautumista ja siitä tulisi todellinen maailmanvaluutta.

Bitcoin-laskenta eroaa kuitenkin olennaisesti Ethereum-laskennasta. Bitcoin tukee vain ”todentamista” laskennan muotona, kun taas Ethereum on pohjimmiltaan laskennallinen, ja todentaminen on sen sivutuote. Tämä ero näkyy siinä, että Ethereum veloittaa kaasumaksuja epäonnistuneista transaktioista, kun taas Bitcoin ei veloita.

Sopimuksilla saavutetaan eräänlainen älykkäiden sopimusten muoto, joka perustuu verifiointiin eikä laskentaan. Sopimuksista voidaan todeta, että muutamaa tiukkaa Satoshi-fundamentalistia lukuun ottamatta suurin osa ihmisistä uskoo, että sopimukset ovat hyvä valinta Bitcoinin parantamiseksi. Yhteisö kuitenkin keskustelee jatkuvasti siitä, mitä järjestelmää sopimusten toteuttamiseen tulisi käyttää.

APO, OP_VAULT ja TLUV suuntautuvat suoriin sovelluksiin. Valitsemalla ne voidaan toteuttaa tietyt sovellukset edullisemmin ja tehokkaammin. Lightning Networkin harrastajat suosivat APO:ta, koska sillä saavutetaan LN-symmetria; jos haluat luoda holvin, on parasta käyttää OP_VAULTia; CoinPoolin rakentamiseen TLUV on yksityisempi ja tehokkaampi. OP_CAT ja TXHASH ovat yleisempiä, niissä on vähemmän tietoturva-aukkoja, ja niillä voidaan saavuttaa enemmän käyttötapauksia yhdistelemällä niitä muiden op-koodien kanssa, vaikkakin mahdollisesti skriptin monimutkaisuuden kustannuksella. CTV ja CSFS ovat mukauttaneet lohkoketjujen käsittelyä koskevaa lähestymistapaa: CTV toteuttaa viivästetyt ulostulot ja CSFS viivästetyt allekirjoitukset. MATT on suhteellisen ainutlaatuinen, sillä se käyttää optimistista suoritusta ja petostodistuksia ja luottaa Merkle Trie -rakenteeseen yleisten älykkäiden sopimusten aikaansaamiseksi, vaikka se vaatii edelleen uusia opkoodeja introspektio-ominaisuuksien tarjoamiseksi.

Bitcoin-yhteisö keskustelee jo kiivaasti mahdollisuudesta ottaa käyttöön sopimuksia soft forkin avulla. Starknet on ilmoittanut virallisesti liittymisestään Bitcoin-ekosysteemiin ja aikoo toteuttaa selvityksen Bitcoin-verkossa kuuden kuukauden kuluessa OP_CAT-fuusion jälkeen. Chakra jatkaa Bitcoin-ekosysteemin viimeisimmän kehityksen seuraamista, edistää OP_CAT soft fork -yhdistymistä ja käyttää introspektion ja sopimusten tuomaa ohjelmoitavuutta turvallisemman ja tehokkaamman Bitcoin-selvityskerroksen rakentamiseen.

Related Articles
↑
Exit mobile version