De Heilige Graal van het Bitcoin Laag 2 Netwerk: Introspectie en convenanten

Vergeleken met Turing-complete blockchains zoals Ethereum, wordt de scripttaal van Bitcoin als zeer beperkt beschouwd. De taal kan alleen basisbewerkingen uitvoeren en heeft zelfs geen functies voor vermenigvuldiging en deling. Nog belangrijker is dat de gegevens van de blockchain zelf bijna ontoegankelijk zijn voor scripts, wat leidt tot ernstige beperkingen in flexibiliteit en programmeerbaarheid. Daarom hebben mensen lang gezocht naar manieren om introspectie voor Bitcoin-scripts mogelijk te maken.

Introspectie verwijst naar het vermogen van Bitcoin om transactiegegevens te inspecteren en in te perken. Hierdoor kunnen scripts het gebruik van fondsen controleren op basis van specifieke transactiedetails, wat complexere functionaliteiten mogelijk maakt. Momenteel zetten de meeste Bitcoin opcodes door de gebruiker geleverde gegevens op de stack of manipuleren gegevens die al op de stack staan. Introspectie-opcodes kunnen echter huidige transactiegegevens (zoals tijdstempels, bedragen en transactie-ID’s) op de stack plaatsen, waardoor meer gedetailleerde controle over UTXO-uitgaven mogelijk is.

Er zijn op dit moment slechts drie opcodes in Bitcoin-scripts die introspectie ondersteunen: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY en CHECKSIG. CHECKSIG heeft verschillende varianten, waaronder CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG en CHECKMULTISIGVERIFY.

Convenanten zijn beperkingen op hoe tokens kunnen worden overgedragen. Gebruikers kunnen specificeren hoe UTXO’s worden verdeeld door middel van convenanten, waarvan er veel worden geïmplementeerd met behulp van introspectie opcodes. Op dit moment categoriseert Bitcoin Optech introspectie onder convenantopcodes.

Bitcoin heeft momenteel twee convenanten: CSV (CheckSequenceVerify) en CLTV (CheckLockTimeVerify). Beide zijn tijdsgebaseerde convenanten en vormen de basis van veel schalingsoplossingen, zoals het Lightning Network. Dit geeft aan dat de Bitcoin-schalingsoplossingen sterk afhankelijk zijn van introspectie en convenanten.

Voorwaarden toevoegen aan tokenoverdrachten

In de cryptowereld is de meest gebruikte methode toezeggingen, vaak geïmplementeerd met hashes. Om te bewijzen dat aan de overdrachtsvoorwaarden is voldaan, worden handtekeningmechanismen gebruikt voor verificatie. Daarom bevatten convenanten talloze aanpassingen aan hashes en handtekeningen.

De volgende zijn veelbesproken convenant opcode voorstellen:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), opgenomen in BIP-119, is een veelbesproken Bitcoin-upgrade. CTV staat uitvoerscripts toe om sjablonen te specificeren voor het uitgeven van transacties, inclusief velden zoals nVersion, nLockTime, scriptSig hash, input count, sequences hash, output count, outputs hash en input index. Deze sjabloonbeperkingen worden geïmplementeerd door middel van een hashverplichting en toekomstige uitgavenscripts zullen controleren of de hashwaarden van gespecificeerde velden in de uitgavenverrichting overeenkomen met die in het invoerscript. Deze sjablonen definiëren in wezen het tijdstip, de methode en het bedrag van toekomstige UTXO transacties.

Met name de input TXID wordt uitgesloten van de hash commitment. Deze uitsluiting is nodig omdat, of het nu in Legacy of Segwit transacties is, de TXID afhankelijk is van de scriptPubKey waarde bij het gebruik van het standaard SIGHASH_ALL handtekeningtype. Het opnemen van de TXID zou een cirkelvormige afhankelijkheid creëren, waardoor de hash commitment onmogelijk te construeren zou zijn.

CTV bereikt introspectie door direct gespecificeerde transactie-informatie te verkrijgen via een nieuwe opcode, deze te hashen en te vergelijken met de verplichting op de stack. Deze methode verbruikt minder on-chain ruimte maar mist wat flexibiliteit.

De basis van second-layer oplossingen zoals het Lightning Network zijn vooraf ondertekende transacties. Vooraf ondertekenen betekent meestal het vooraf genereren en ondertekenen van transacties, maar ze pas uitzenden als aan bepaalde voorwaarden is voldaan. In wezen implementeert CTV een striktere functie voor vooraf ondertekenen, waarbij de vooraf ondertekende verbintenis direct op de ketting wordt gepubliceerd en alleen transacties volgens het vooraf gedefinieerde sjabloon worden toegestaan.

CTV werd oorspronkelijk voorgesteld om Bitcoin-congestie te verlichten en kan ook congestiecontrole worden genoemd. Tijdens periodes van hoge congestie kan CTV meerdere toekomstige transacties vastleggen door middel van een enkele transactie, waardoor het niet nodig is om meerdere transacties uit te zenden tijdens de congestie en de daadwerkelijke transacties te voltooien als de congestie afneemt. Dit kan aanzienlijk helpen tijdens uitwisselingsruns. Daarnaast kunnen sjablonen worden gebruikt om kluizen te implementeren, waardoor aanvallen van hackers worden voorkomen omdat de bestemming van het geld vooraf is bepaald, waardoor het onmogelijk is voor hackers om UTXO’s met behulp van het CTV-script naar hun adressen te sturen.

CTV kan netwerken van de tweede laag aanzienlijk verbeteren. In het Lightning Netwerk bijvoorbeeld kan een enkele UTXO door het implementeren van Timeout Trees en Channel Factories met behulp van CTV uitgroeien tot een CTV-boom, waarbij meerdere state channels worden geopend met slechts één on-chain transactie en bevestiging. Bovendien ondersteunt CTV atomaire transacties (ATLC) in het Ark-protocol.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 stelt een nieuwe hashvlag voor handtekeningen voor tapscript voor, genaamd SIGHASH_ANYPREVOUT, om het schrijven van flexibelere bestedingslogica te vergemakkelijken. APO en CTV lijken in veel opzichten op elkaar. Om de circulaire afhankelijkheid tussen scriptPubKeys en TXID’s aan te pakken, is de oplossing van APO om de relevante invoerinformatie uit te sluiten en alleen de uitvoer te ondertekenen, waardoor transacties zich dynamisch aan verschillende UTXO’s kunnen binden.

Logischerwijs heeft de verificatiebewerking OP_CHECKSIG (en de bijbehorende opcodes) drie functies:

1. Onderdelen van de bestedingstransactie samenvoegen.
2. Hash deze onderdelen.
3. Controleer of de hash is ondertekend door de gegeven sleutel.

De specifieke inhoud van de handtekening kan aanzienlijk worden aangepast, en welke transactievelden worden ondertekend wordt bepaald door de SIGHASH vlag. Volgens de definitie van BIP 342 handtekening opcodes, omvatten SIGHASH vlaggen onder andere SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE en SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY controleert de invoer, terwijl de andere de uitvoer controleren.

SIGHASH_ALL is de standaard SIGHASH vlag, die alle uitgangen ondertekent. SIGHASH_NONE ondertekent geen uitgangen en SIGHASH_SINGLE ondertekent alleen een opgegeven uitvoer. SIGHASH_ANYONECANPAY kan samen met de andere drie vlaggen worden ingesteld, en als het is ingesteld, ondertekent het alleen de opgegeven invoer; anders moet alle invoer worden ondertekend.

Geen van deze SIGHASH vlaggen kan de invloed van invoer elimineren. Zelfs SIGHASH_ANYONECANPAY vereist een verbintenis met één invoer.

Daarom introduceert BIP 118 SIGHASH_ANYPREVOUT. APO-handtekeningen hoeven zich niet vast te leggen op de uitgegeven invoer UTXO (PREVOUT genoemd), maar alleen de uitvoer te ondertekenen, wat meer flexibiliteit biedt in Bitcoin-controle. Door transacties vooraf te construeren en bijbehorende eenmalige handtekeningen en openbare sleutels te maken, moeten activa die naar dat openbare sleuteladres worden verzonden, worden uitgegeven via de vooraf geconstrueerde transactie, waardoor het convenant wordt bereikt.

De flexibiliteit van APO kan ook worden gebruikt om transacties te repareren. Als een transactie vastloopt op de keten vanwege lage vergoedingen, kan eenvoudig een andere transactie worden aangemaakt om de vergoeding te verhogen zonder dat er nieuwe handtekeningen nodig zijn. Voor wallets met meerdere handtekeningen zijn handtekeningen die niet afhankelijk zijn van de uitgegeven input bovendien eenvoudiger.

Door de circulaire afhankelijkheid tussen scriptPubKeys en input TXID’s te elimineren, kan APO introspectie bereiken door outputgegevens in de witness toe te voegen, hoewel dit nog steeds extra dataruimte voor de witness vereist.

Voor off-chain protocollen zoals het Lightning Network en vaults vermindert APO de noodzaak voor tussentijdse toestandsopslag, waardoor de opslagvereisten en complexiteit aanzienlijk afnemen. De meest directe toepassing voor APO is Eltoo, dat kanaalfabrieken vereenvoudigt, lichtgewicht en goedkope wachttorens bouwt en eenzijdige uitgangen toestaat zonder foutieve toestanden achter te laten, waardoor de prestaties van het Lightning Netwerk verbeteren. APO kan de functionaliteit van CTV simuleren, maar vereist persoonlijke opslag van handtekeningen en vooraf ondertekende transacties, waardoor het duurder en minder efficiënt is dan CTV.

Het belangrijkste punt van kritiek van APO is de noodzaak van een nieuwe sleutelversie, waardoor het niet compatibel is met bestaande systemen. Daarnaast zou het nieuwe hash-type van de handtekening potentiële risico’s op dubbele uitgaven kunnen introduceren. Na uitgebreide discussies in de gemeenschap vereist APO nu een gewone handtekening naast de originele, waardoor de zorgen over de veiligheid worden weggenomen en het BIP-118 nummer wordt verdiend.

OP_VAULT BIP-345

BIP-345 stelt twee nieuwe opcodes voor, OP_VAULT en OP_VAULT_RECOVER, om te werken met CTV en een speciale overeenkomst te implementeren die een vertragingsperiode afdwingt voor het uitgeven van gespecificeerde tokens, waarin de uitgave kan worden “herroepen” via een herstelpad.

Gebruikers kunnen een kluis aanmaken door een specifiek Taproot-adres in te stellen en ten minste twee scripts in de MAST op te nemen: een OP_VAULT-script om het verwachte uitnameproces te vergemakkelijken en een OP_VAULT_RECOVER-script om ervoor te zorgen dat munten worden hersteld voordat de uitname is voltooid.

Hoe bereikt OP_VAULT onderbreekbare tijdsgesloten geldopnames?

Eenvoudig gezegd vervangt de OP_VAULT opcode het gebruikte OP_VAULT script door een gespecificeerd script, waarbij een enkel bladknooppunt in de MAST wordt bijgewerkt terwijl de rest ongewijzigd blijft. Dit is vergelijkbaar met TLUV, maar zonder ondersteuning voor interne sleutelupdates.

Het introduceren van een sjabloon tijdens scriptupdates kan betalingseffecten beperken. De parameter tijdslot wordt gespecificeerd door OP_VAULT, terwijl de sjabloon die door de CTV opcode wordt gebracht de reeks uitgangen beperkt die via dat scriptpad worden uitgegeven.

De BIP-345 is ontworpen voor kluizen, zodat gebruikers kunnen beschikken over een zeer veilig herstelpad (papieren portemonnee, gedistribueerde multi-handtekening) en tegelijkertijd een uitgavenvertraging kunnen configureren voor routinematige betalingen. Het apparaat van de gebruiker controleert continu de uitgaven van de kluis, waardoor herstel mogelijk is als er een ongeautoriseerde overdracht plaatsvindt.

Het implementeren van kluizen met BIP-345 vereist het overwegen van vergoedingsproblemen, vooral voor hersteltransacties. Mogelijke oplossingen zijn CPFP (Child Pays for Parent), tijdelijke ankers en nieuwe hashvlaggen voor handtekeningen zoals SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Het TLUV schema is gebouwd rond Taproot en heeft als doel het probleem van het efficiënt verlaten van gedeelde UTXO’s op te lossen. Het leidende principe is dat wanneer een Taproot uitgang wordt uitgegeven, we de interne structuur van het Taproot adres en cryptografische transformaties kunnen gebruiken om de interne sleutel en MAST gedeeltelijk bij te werken volgens de update stappen beschreven door het TLUV script, waardoor contract functionaliteit wordt bereikt.

Het idee van het TLUV schema is om een nieuw Taproot adres aan te maken gebaseerd op de huidige bestedingsinput via een nieuwe opcode TAPLEAF_UPDATE_VERIFY, die één of meer van de volgende operaties kan uitvoeren:

• De interne openbare sleutel bijwerken
• Het Merkle-pad trimmen
• Verwijder het huidige uitvoerende bladknooppunt
• Voeg een nieuw bladknooppunt toe aan het einde van het Merkle-pad

TLUV heeft drie ingangen:

1. Een specificatie over het bijwerken van de interne openbare sleutel
2. Een nieuw bladknooppunt voor het Merkle-pad
3. Een specificatie of het huidige bladknooppunt moet worden verwijderd en/of hoeveel Merkle path bladknooppunten moeten worden verwijderd.

De TLUV opcode berekent de bijgewerkte scriptPubKey en controleert of de uitvoer die overeenstemt met de huidige invoer is uitgegeven aan die scriptPubKey.

De inspiratie voor TLUV zijn coin pools. Vandaag de dag kunnen gemeenschappelijke pools worden gecreëerd met behulp van vooraf ondertekende transacties, maar als je toestemmingsvrije uittredingen wilt bereiken, moet je een exponentieel groeiend aantal handtekeningen creëren. TLUV maakt permissionless exits mogelijk zonder vooraf ondertekende transacties. Bijvoorbeeld, een groep partners gebruikt Taproot om een gedeelde UTXO te bouwen en hun fondsen te bundelen. Ze kunnen fondsen intern verplaatsen met behulp van de Taproot sleutel of gezamenlijk ondertekenen om externe betalingen te doen. Individuen kunnen op elk moment uit de gedeelde pool stappen en hun betalingspad verwijderen, terwijl anderen betalingen kunnen blijven uitvoeren via het oorspronkelijke pad zonder extra informatie over de overblijvende leden bloot te leggen. Deze methode is efficiënter en meer privé in vergelijking met niet-gepoolde transacties.

De TLUV opcode bereikt gedeeltelijke bestedingsbeperkingen door de oorspronkelijke MAST bij te werken. Het bereikt echter geen introspectie van uitvoerbedragen. Daarom is een nieuwe opcode IN_OUT_AMOUNT nodig, die twee gegevens op de stapel duwt: het bedrag van de UTXO van deze invoer en het overeenkomstige uitvoerbedrag. Van degene die TLUV gebruikt wordt dan verwacht dat hij wiskundige operatoren gebruikt om te controleren of de fondsen goed bewaard zijn gebleven in de bijgewerkte scriptPubKey.

Introspectie van outputbedragen voegt nog een complexiteit toe omdat Bitcoinbedragen worden weergegeven in satoshi’s en maximaal 51 bits nodig hebben, maar scripts alleen 32-bits wiskundige bewerkingen toestaan. Dit vereist het upgraden van de operatoren in het script door opcodegedrag opnieuw te definiëren of door SIGHASH_GROUP te gebruiken om IN_OUT_AMOUNT te vervangen.

TLUV zal naar verwachting oplossingen bieden voor gedecentraliseerde Layer 2 coin pools, hoewel de betrouwbaarheid in termen van het aanpassen van Taproot publieke sleutels verder bevestigd moet worden.

MATT

MATT (Merkleize All The Things) wil drie doelen bereiken: Merkleizing state, Merkleizing scripts, en Merkleizing execution, om zo tot algemene smart contracts te komen.

• Merkleizing Staat: Construeer een Merkle Trie waar elke bladknoop een hash van de staat is, en de Merkle Wortel de volledige contractstaat voorstelt.
• Merkleizing Scripts: Een MAST opgebouwd uit Tapscript waarbij elk bladknooppunt een mogelijk staatstransitiepad is.
• Merkleizing Uitvoering: Bereikt door cryptografische toezeggingen en fraude-uitdaagmechanismen. Voor elke berekeningsfunctie kunnen deelnemers off-chain berekeningen uitvoeren en toezeggingen, f(x)=y, publiceren. Als andere deelnemers het resultaat f(x)=z vinden, kunnen ze het aanvechten en wordt arbitrage uitgevoerd via een binaire zoekactie, vergelijkbaar met het Optimistic Rollup principe.

Om MATT te bereiken, moeten Bitcoin-programmeerscripts de volgende functionaliteiten hebben:

1. Een specifiek script afdwingen op een uitvoer (en hun hoeveelheden)
2. Gegevens aan een uitgang koppelen
3. Gegevens lezen van de huidige ingang (of andere ingangen)

Het tweede punt is cruciaal omdat dynamische gegevens toestandsberekening mogelijk maken door middel van invoergegevens die worden geleverd door de spender, waarbij een toestandsmachine wordt gesimuleerd en de volgende toestand en bijgevoegde gegevens worden bepaald. MATT stelt de OP_CHECKCONTRACTVERIFY (OP_CCV) opcode voor, een combinatie van de eerder voorgestelde OP_CHECKOUTPUTCONTRACTVERIFY en OP_CHECKINPUTCONTRACTVERIFY opcodes, met een extra flags parameter om het doel van de operatie te specificeren.

Controle van uitvoerhoeveelheden: De meest directe manier is via directe introspectie. Uitvoerbedragen zijn echter 64-bits getallen die 64-bits bewerkingen vereisen, wat de implementatie van het Bitcoin-script complexer maakt. CCV gebruikt een vertraagde controle, vergelijkbaar met OP_VAULT, waarbij de invoerbedragen voor alle ingangen worden opgeteld tot dezelfde uitvoer met CCV als de ondergrens van die uitvoerbedragen. De controle wordt uitgesteld tot het transactieproces in plaats van tijdens de evaluatie van het invoerscript.

Gezien de algemeenheid van fraudebewijzen zouden sommige varianten van MATT-contracten alle soorten slimme contracten of laag-2-constructies moeten kunnen bereiken, hoewel aanvullende vereisten (zoals kapitaallock-in en challenge-periodevertragingen) nauwkeurig geëvalueerd moeten worden. Verder onderzoek is nodig om te evalueren welke toepassingen aanvaardbare transacties zijn. Bijvoorbeeld het gebruik van cryptografische verbintenissen en frauduleuze uitdagingsmechanismen om OP_ZK_VERIFY-functies te simuleren, waardoor vertrouwensloze Rollups op Bitcoin mogelijk worden.

In de praktijk gebeurt er al het een en ander. Johan Torås Halseth heeft elftrace geïmplementeerd met de OP_CHECKCONTRACTVERIFY opcode uit het MATT soft fork voorstel, waardoor alle programma’s die ondersteund worden door RISC-V compilatie geverifieerd kunnen worden op de Bitcoin-keten, waardoor native Bitcoin verificatiebruggen voor contractprotocollen mogelijk worden.

CSFS (OP_CHECKSIGFROMSTACK)

Uit de introductie van de APO opcode weten we dat OP_CHECKSIG (en gerelateerde operaties) verantwoordelijk is voor het samenstellen van transacties, hashing en handtekeningverificatie. Het bericht dat het verifieert wordt echter afgeleid van de transactieserialisatie met deze opcode, waardoor het niet mogelijk is om andere berichten te specificeren. Eenvoudig gezegd dient OP_CHECKSIG (en gerelateerde operaties) om te verifiëren dat de UTXO als transactie-invoer geautoriseerd is om uitgegeven te worden door de houder van de handtekening, waardoor de veiligheid van Bitcoin beschermd wordt.

CSFS controleert, zoals de naam al aangeeft, handtekeningen van de stack. De CSFS opcode neemt drie parameters van de stack: een handtekening, een bericht en een publieke sleutel en verifieert de geldigheid van de handtekening. Dit betekent dat elk bericht doorgegeven kan worden aan de stack door middel van getuigegegevens en geverifieerd kan worden door CSFS, wat een aantal innovaties op Bitcoin mogelijk maakt.

De flexibiliteit van CSFS maakt het mogelijk om verschillende mechanismen te implementeren, zoals handtekeningen voor betalingen, delegatie van bevoegdheden, orakelcontracten en beschermingsobligaties tegen dubbele uitgaven, en nog belangrijker, introspectie van transacties. Het principe van transactie introspectie met CSFS is erg eenvoudig. Als de door OP_CHECKSIG gebruikte transactie-inhoud via de getuige naar de stack wordt geduwd en dezelfde openbare sleutel en handtekening worden gebruikt om te verifiëren met zowel CSFS als OP_CHECKSIG, en als beide slagen, dan is de inhoud van elk bericht dat aan CSFS wordt doorgegeven hetzelfde als de geserialiseerde uitgaventransactie (en andere gegevens) die impliciet door OP_CHECKSIG worden gebruikt. We verkrijgen dan geverifieerde transactiegegevens op de stack, die gebruikt kunnen worden om beperkingen toe te passen op de bestedingstransactie met andere opcodes.

CSFS verschijnt vaak met OP_CAT omdat OP_CAT verschillende velden van de transactie kan samenvoegen om de serialisatie te voltooien, waardoor transactievelden nauwkeuriger kunnen worden geselecteerd voor introspectie. Zonder OP_CAT kan het script geen hashes hercompileren uit individueel controleerbare gegevens, dus het kan alleen controleren of een hash overeenkomt met een specifieke waarde, wat betekent dat munten alleen kunnen worden uitgegeven via een enkele specifieke transactie.

CSFS kan opcodes bereiken zoals CLTV, CSV, CTV, APO en is een algemene introspectie opcode, waardoor het ook helpt bij Layer 2 schaaloplossingen voor Bitcoin. Het nadeel is dat er een complete kopie van de ondertekende transactie toegevoegd moet worden aan de stack, waardoor transacties die CSFS willen gebruiken voor introspectie aanzienlijk groter kunnen worden. Daarentegen hebben introspectie-opcodes met één doel, zoals CLTV en CSV, de minste overhead, maar het toevoegen van elke nieuwe speciale introspectie-opcode vereist consensuswijzigingen.

TXHASH (OP_TXHASH)

OP_TXHASH is een zeer eenvoudige introspectie opcode waarmee de operator de hash van een veld kan selecteren en naar de stack kan pushen. Specifiek haalt OP_TXHASH een txhash vlag van de stack, berekent een (gemarkeerde) txhash gebaseerd op de vlag en duwt de resulterende hash naar de stack.

Vanwege de gelijkenis tussen TXHASH en CTV is er in de gemeenschap uitgebreid gediscussieerd over de twee.

TXHASH kan worden gezien als een algemene upgrade van CTV en biedt een geavanceerder transactiesjabloon waarmee gebruikers delen van de uitgaventransactie kunnen specificeren, waardoor veel problemen met betrekking tot transactiekosten worden opgelost. In tegenstelling tot andere contract opcodes, hoeft TXHASH geen kopie van de benodigde gegevens in de getuige te leveren, waardoor de opslagbehoefte verder afneemt. In tegenstelling tot CTV is TXHASH niet compatibel met NOP en kan alleen worden geïmplementeerd in tapscript. De combinatie van TXHASH en CSFS kan worden beschouwd als een alternatief voor CTV en APO.

In termen van het construeren van contracten is TXHASH eenvoudiger om “additieve contracten” te maken door alle delen van de transactiegegevens die je wilt fixeren naar de stack te pushen, ze samen te hashen en te verifiëren of het resultaat overeenkomt met een vaste waarde. CTV is eenvoudiger om “subtractieve contracten” te bereiken door alle delen van de transactiegegevens die je vrij wilt houden naar de stack te pushen. Dan, met behulp van voortschrijdende OP_SHA256, startend vanaf een vaste tussenstatus, committeert die tussenstatus de hash-gegevens van de transactie prefix. De vrije delen worden in die tussentoestand gehasht.

Het veld TxFieldSelector dat is gedefinieerd in de TXHASH-specificatie zal naar verwachting worden uitgebreid naar andere opcodes, zoals OP_TX.

De BIP met betrekking tot TXHASH heeft momenteel de ontwerpstatus op Github en heeft nog geen nummer gekregen.

OP_CAT

OP_CAT is een ietwat mysterieuze opcode die door Satoshi Nakamoto werd gedepreciseerd vanwege veiligheidszorgen. Het heeft echter onlangs tot uitgebreide discussies geleid onder Bitcoin core-ontwikkelaars en is zelfs een meme geworden in de online community. Uiteindelijk werd OP_CAT goedgekeurd als BIP-347 en velen noemen het het meest waarschijnlijke BIP-voorstel dat in de nabije toekomst zal worden aangenomen.

In werkelijkheid is het gedrag van OP_CAT heel eenvoudig: het voegt twee elementen op de stack samen tot één. Maar hoe maakt dit contractfunctionaliteit mogelijk?

De functie van het aaneenschakelen van twee elementen komt overeen met een krachtige cryptografische datastructuur die bekend staat als een Merkle Trie. Voor de constructie van een Merkle Trie zijn alleen aaneenschakelingen en hashingbewerkingen nodig, die beide beschikbaar zijn in Bitcoinscripts. Daarom kunnen we met OP_CAT theoretisch Merkle Proofs verifiëren in Bitcoin-scripts, wat de meest gebruikte lichtgewicht verificatiemethode in blockchains is.

Zoals eerder vermeld, kan CSFS OP_CAT gebruiken om een algemeen contractschema te maken. Zelfs zonder CSFS stelt de structuur van Schnorr-handtekeningen OP_CAT in staat om introspectie van transacties te bereiken.

In een Schnorr-handtekening bestaat het te ondertekenen bericht uit de volgende velden:

• Versie
• Vergrendeltijd
• Aantal invoeren
• Aantal uitgangen
• Lijst met ingangen (elk met hash van vorige transactie, index, scriptlengte, script, sequentie)
• Lijst met uitgangen (elk met waarde, scriptlengte, script)

Deze velden bevatten de belangrijkste elementen van een transactie. Door ze in scriptPubKey of witness te plaatsen en OP_CAT en OP_SHA256 te gebruiken, kunnen we een Schnorr handtekening maken en deze verifiëren met OP_CHECKSIG. Als de verificatie slaagt, bewaart de stack de geverifieerde transactiegegevens, waardoor introspectie van de transactie mogelijk wordt. Hierdoor kunnen we verschillende delen van de transactie extraheren en “inspecteren”, zoals de ingangen, uitgangen, bestemmingsadressen of betrokken Bitcoin-bedragen.

Voor meer gedetailleerde cryptografische principes, zie het artikel “CAT and Schnorr Tricks” van Andrew Poelstra.

Samengevat maakt de flexibiliteit van OP_CAT het mogelijk om bijna elke contract opcode na te bootsen, en veel contract opcodes zijn afhankelijk van de functionaliteit ervan. Dit bevordert zijn positie op de samenvoeglijst aanzienlijk. Theoretisch zouden we met alleen OP_CAT en bestaande Bitcoin opcodes een vertrouwen geminimaliseerde BTC ZK Rollup kunnen bouwen. Starknet, Chakra en andere partners in het ecosysteem werken er actief aan om dit mogelijk te maken.

Conclusie

Terwijl we verschillende strategieën onderzoeken om Bitcoin uit te breiden en de programmeerbaarheid ervan te verbeteren, wordt het duidelijk dat de weg vooruit een combinatie is van native verbeteringen, off-chain berekeningen en complexe scriptfunctionaliteiten.

Zonder een flexibele basislaag is het onmogelijk om een flexibelere tweede laag op te bouwen.

Off-chain schaalbaarheid van berekeningen is de toekomst, maar de programmeerbaarheid van Bitcoin moet doorbreken om schaalbaarheid beter te ondersteunen en een echte wereldvaluta te worden.

Bitcoin-berekening verschilt echter fundamenteel van Ethereum-berekening. Bitcoin ondersteunt alleen “verificatie” als een vorm van rekenkracht, terwijl Ethereum fundamenteel rekenkrachtig is, met verificatie als een bijproduct. Dit verschil komt duidelijk naar voren in het feit dat Ethereum gaskosten in rekening brengt voor mislukte transacties, terwijl Bitcoin dat niet doet.

Contracten bereiken een vorm van slimme contracten gebaseerd op verificatie in plaats van berekening. Afgezien van een paar strenge Satoshi fundamentalisten geloven de meeste mensen dat contracten een goede keuze zijn om Bitcoin te verbeteren. De gemeenschap debatteert echter voortdurend over welk schema moet worden gebruikt om contracten te implementeren.

APO, OP_VAULT en TLUV neigen naar directe toepassingen. Door ze te kiezen kunnen specifieke toepassingen goedkoper en efficiënter worden geïmplementeerd. Lightning Network-enthousiastelingen geven de voorkeur aan APO omdat het LN-symmetrie bereikt; als je een kluis wilt maken, kun je het beste OP_VAULT gebruiken; om een CoinPool te bouwen, is TLUV meer privé en efficiënter. OP_CAT en TXHASH zijn algemener, met minder veiligheidslekken, en kunnen meer gebruikssituaties bereiken door combinaties met andere opcodes, zij het mogelijk ten koste van de complexiteit van het script. CTV en CSFS hebben de aanpak voor blockchainverwerking aangepast: CTV implementeert vertraagde uitgangen en CSFS implementeert vertraagde handtekeningen. MATT is relatief uniek, maakt gebruik van optimistische uitvoering en fraudebewijzen, en vertrouwt op de Merkle Trie-structuur om algemene slimme contracten te bereiken, hoewel het nog steeds nieuwe opcodes vereist om introspectiemogelijkheden te bieden.

We zien dat de Bitcoin-gemeenschap al druk aan het discussiëren is over de mogelijkheid om contracten in te voeren door middel van een soft fork. Starknet heeft officieel zijn toetreding tot het Bitcoin-ecosysteem aangekondigd en is van plan om binnen zes maanden na de samenvoeging van OP_CAT verrekeningen te implementeren op het Bitcoin-netwerk. Chakra zal de laatste ontwikkelingen in het Bitcoin-ecosysteem blijven volgen, de OP_CAT soft fork merge promoten en de programmeerbaarheid die introspectie en contracten met zich meebrengen gebruiken om een veiligere en efficiëntere Bitcoin settlementlaag te bouwen.