Aquest és el cinquè article de sèrie El busseig profund en propostes de pacte individuals que han arribat a un punt de maduresa mereixent un desglossament en profunditat.
OP_CAT, Presentat per a la reactivació a Tapscript per Ethan Heilman i Armin Sabouri a BIP 347, no és un pacte. Es tractava d’un codi d’opció que es va incloure originalment a la primera publicació de Bitcoin per manipular elements de dades a la pila. Es va desactivar el 2010 amb el llançament de Bitcoin 0.3.10 juntament amb altres opcodes OPCodes a causa de les preocupacions dels atacs de denegació de serveis que podrien xocar amb nodes. També es va afegir un límit màxim global de 520 bytes per a qualsevol element individual de la pila mentre executés un script.
Ja heu de comprendre com funciona l’avaluació de scripts a la pila i les peces bàsiques d’una transacció de bitcoin, de manera que no hi ha gaire requisit que expliqui necessari per a OP_CAT.
Si bé OP_CAT pot no ser un pacte per si mateix, pot imitar els pactes a causa d’una peculiaritat en el funcionament de les signatures de Schnorr. Aquest és un tema molt profund, explicat aquí per Andrew Poelstra de Blockstream, així que només em quedaré amb una vista d’alt nivell. Cada corba el·líptica té un punt de generador, que és essencialment “0”, que s’utilitza en les matemàtiques de la corba el·líptica per a la generació i la signatura de claus. Amb Schnorr, podeu signar mitjançant el punt del generador com a clau i donar o agafar uns quants bytes que heu de signar repetidament per sortir bé, la signatura resultant és en realitat el mateix hash de la transacció que heu signat.
Deixeu de banda la mecànica de com funciona matemàticament per ara i recordeu per més endavant que aquestes signatures “estranyes” us permeten obtenir les transaccions actuals TXID a la pila.
Com funciona op_cat
OP_CAT agafa els dos primers elements de dades de la pila i els concatena. De manera que si els dos primers elements de la pila són “1” i “2”, op_cat els elimina i els posa “12” a la part superior de la pila. Això és tot.
Per a què és útil op_cat
D’acord, doncs, què és el gran problema? Per què tothom es desprèn de OP_CAT, tot i que és tan senzilla l’explicació de com funciona ni tan sols va prendre un paràgraf complet per escriure?
Dues raons, tot i que tenint en compte la naturalesa de OP_CAT No puc donar cap garantia, aquestes són les dues úniques raons. OP_CAT permet la construcció i la verificació dels arbres de Merkle directament a la pila, cosa que obre la porta a algun comportament i funcionalitat interessants. També permet l’emulació de pactes que permeten una introspecció granular completa a causa de les “estranyes” signatures de Schnorr esmentades anteriorment.
La verificació de la prova de Merkle és un component clau de Taproot, però la manera com s’implementa la verificació de l’arbre de Merkle només es produeix en el context de verificar que una ruta de despesa Tapscript es compromet a la clau pública de Root Schnorr en el script de sortida de la moneda que s’està gastant. Taproot no admet la verificació genèrica de proves de merkle.
OP_CAT ho permet de manera totalment genèrica. Simplement proporcionar el hash (ES) de les fulles i els nodes de hash interior en l’ordre adequat i trucar a OP_cat successivament us permetrà reconstruir un hash d’arrel de Merkle i comparar-lo amb un hash predefinit del guió. Podríeu fer -ho per proporcionar rutes de retirada unilateral per a UTXOs compartits com a CATVM, podríeu fer que les transaccions depenguin d’altres transaccions que s’han inclòs en un bloc amb un treball vàlid, podeu fer una transacció depenent de qualsevol condició que es pugui verificar amb una prova de Merkle.
Ara, per a l’emulació del pacte que permet la introspecció completa. El que intenteu és assegurar que una transacció hagi de tenir certes característiques per ser vàlides. Recordeu ara que la signatura “estranya” obté el hash de la transacció a la pila. Una signatura de transaccions no es fa realment durant la transacció en brut, sinó que es fa a través del seu hash. Això ens permet fer alguna cosa interessant.
Podeu construir scripts molt complicats i convolucionats mitjançant op_cat per agafar les peces crues individuals de la transacció com a part del testimoni i ajuntar -les lentament a la pila amb op_cat. Al llarg del camí, es poden comprovar les peces individuals de la transacció contra els hashes predefinits, només calen -los i utilitzant op_equal. Al final del guió, teniu la transacció completa a la pròpia pila i podeu afegir -hi les dades necessàries i, a continuació, heu de comparar -la, comparant -la una vegada més amb op_equal, aquesta vegada amb la signatura “estranya”. Si aquesta comprovació passa, es pot executar un Checksig normal i sempre que es faci la signatura “estranya” amb la transacció que es va gastar, tot s’executa com a vàlida.
Les comprovacions OP_EQUAL de peces individuals de la transacció al llarg del camí garanteixen que aquestes peces de la transacció són exactament les que haurien de ser. Si algun d’ells no fa verificació, la transacció no és vàlida. Això fa complir els pactes emulats. Al final, si el hash de transacció construït amb op_cat i el “estrany” coincidència, aleshores el Checksig final garanteix que la transacció construïda amb OP_CAT i es comprova contra el pacte emulat coincideix amb la transacció real que es dedica a l’època.
Pensaments de tancament
OP_CAT bufa obre les portes de la introspecció i les dades cap endavant que es transmeten completament. La introspecció es pot realitzar fins a qualsevol grau granular desitjat, amb cada camp individual de la transacció que es pot comprometre de manera independent. Permet totes les mateixes capacitats introspectives que TXHASH fa, i després algunes.
La capacitat de verificar les proves genèriques de Merkle és també una potent funcionalitat, però es posa en dubte com s’utilitzarà aquesta capacitat i quin tipus d’incentius podrien crear. Es podrien construir scripts de Bitcoin que requereixen alguna transacció en sistemes de blockchain externs, sempre que utilitzin arbres Merkle construïts amb les funcions de hash disponibles en el script de Bitcoin.
Si bé OP_CAT no és en si mateix un pacte, permet una emulació completa dels pactes amb una empremta blockchain molt menys eficient (i potencial per als desenvolupadors per equivocar -se i cremar diners). És una proposta que, tot i ser increïblement simple, s’hauria d’apropar amb prudència, donat el massiu espai de disseny que obre.
Aquest post Bitcoin Covenants: OP_CAT (BIP 347) va aparèixer per primera vegada a la revista Bitcoin i està escrit per Shinobi.
