Opcode

El Script de Bitcoin tiene un vocabulario fijo de 256 valores de byte posibles, repartidos entre opcodes que apilan datos literales y opcodes que actúan sobre los datos ya apilados. Un script heredado (legacy) puede ejecutar como máximo 201 opcodes operativos y no puede superar los 10.000 bytes. Para quien compra bitcoin, ese vocabulario reducido es la razón de que una billetera pueda indicar la comisión antes de difundir la transacción, y de que bitcoin no ofrezca superficie para errores de contrato descontrolados.

Cómo funciona

Un nodo validador lee un script byte a byte y busca cada byte en una tabla fija. Los valores de 0x01 a 0x4b no son instrucciones en absoluto: cada uno indica que los N bytes siguientes son datos literales y van a la pila, y por eso una clave pública comprimida de 33 bytes aparece en un script como 0x21 seguido de la propia clave. Otros tres códigos de inserción de datos, OP_PUSHDATA1, OP_PUSHDATA2 y OP_PUSHDATA4, cubren los elementos más largos, y los valores de 0x51 a 0x60 apilan los enteros pequeños del 1 al 16 que aparecen en los recuentos de quórum.

Todos los valores por encima de 0x60 realizan operaciones en lugar de transportar datos, y son los que bitcoin cuenta. Un script anterior a Taproot puede contener como máximo 201 de ellos, no puede tener ningún elemento de la pila de más de 520 bytes, no puede mantener más de 1.000 elementos en sus pilas y no puede superar los 10.000 bytes en total. Las cuatro cifras salen del archivo script.h de Bitcoin Core, y las cuatro son reglas de consenso, no preferencias que el operador de un nodo pueda relajar.

Quince opcodes figuran en la tabla, pero están muertos. OP_CAT, OP_MUL, OP_LSHIFT y otros doce se desactivaron en 2010 tras un error que provocaba caídas, y un script que simplemente contenga uno de ellos falla, incluso dentro de una rama que nunca se ejecuta. Ninguno se ha reactivado nunca. Esa sola decisión es la principal razón de que los scripts de bitcoin sean más limitados de lo que la palabra "programable" lleva a esperar.

Tapscript reescribió la contabilidad de los gastos Taproot. El BIP-342, en vigor desde el bloque 709.632 en noviembre de 2021, eliminó tanto el techo de 201 instrucciones como el tope de tamaño de 10.000 bytes, y los reemplazó por un presupuesto de firmas: la transacción debe aportar 50 unidades de peso por cada firma que verifique el script. También convirtió un rango de valores de byte no definidos en códigos OP_SUCCESS, de modo que un script que contenga uno es válido sin llegar a ejecutarse siquiera. Es un espacio que se dejó a propósito para futuras actualizaciones.

Por qué importa cuando compra bitcoin

Los opcodes deciden cuánto cuesta su retiro. Una salida heredada escribe cuatro instrucciones operativas en torno a un hash de 20 bytes en 25 bytes; el equivalente SegWit nativo es un byte de versión y una inserción de datos, 22 bytes; una salida Taproot ocupa 34. Como SegWit trasladó la parte de desbloqueo al testigo, con una cuarta parte del peso, gastar una salida bech32 ocupa aproximadamente 68 bytes virtuales frente a aproximadamente 148 en la versión heredada del mismo pago. Elegir bech32 o bech32m al retirar, siempre que el exchange lo ofrezca, es casi la decisión más barata de este glosario.

Los opcodes también deciden qué puede gestionar realmente su dispositivo de firma. Una billetera de hardware que solo reconoce las plantillas estándar de una sola clave no puede cofirmar una bóveda con bloqueo temporal (timelock) ni una política poco habitual, así que, si la planificación sucesoria de bitcoin o el multisig entran de algún modo en sus planes, compruebe la compatibilidad con scripts en las reseñas antes de comprar el dispositivo y no cuando las monedas ya estén en él.

Ese alcance limitado es una propiedad de seguridad, no una carencia. No hay bucles, ni forma de leer otra transacción, ni estado que persista entre gastos, así que el modo de fallo que ha drenado miles de millones de dólares de las cadenas programables, un contrato que se comporta correctamente con valores de entrada que su autor nunca consideró, no tiene dónde producirse. Las pérdidas de bitcoin proceden de los exchanges, el phishing y los respaldos perdidos, no de fallos del motor de scripts.

Ejemplo práctico: el día en que OP_NOP2 empezó a morder

OP_NOP2 era el byte 0xb1 y no hacía absolutamente nada: era uno de los diez opcodes NOP numerados que quedaban en la tabla para un uso posterior. El BIP-65 le dio una tarea: comprobar que el locktime de la transacción ya ha pasado y hacer fallar el script si no es así. La entrada en vigor llegó en el bloque 388.381, el 14 de diciembre de 2015, y desde entonces el opcode se llama OP_CHECKLOCKTIMEVERIFY.

El truco es que el software antiguo seguía viendo un byte que no hace nada, así que seguía aceptando las nuevas transacciones como válidas. Solo los nodos actualizados hacían cumplir el bloqueo temporal. Esa asimetría es lo que hace blanda a una bifurcación blanda (soft fork), y por la misma ruta OP_NOP3 se convirtió en OP_CHECKSEQUENCEVERIFY en el bloque 419.328, en julio de 2016. Quedan ocho posiciones reservadas de opcodes NOP, que son la mayor parte del espacio de actualización que le queda a bitcoin con las reglas anteriores a Taproot y buena parte de la razón por la que tanta atención de diseño se ha desplazado a los valores OP_SUCCESS que creó tapscript.

Opcode frente a Script de Bitcoin

El Script de Bitcoin es el lenguaje y un opcode es una palabra de su vocabulario. La distinción importa cuando se leen afirmaciones sobre lo que bitcoin puede o no puede hacer, porque casi todas las propuestas serias de la última década han sido propuestas para definir un opcode nuevo, no para cambiar el lenguaje que lo rodea. OP_CHECKTEMPLATEVERIFY, OP_CAT y OP_CHECKSIGADD son cada uno un solo byte con una sola función, y los debates públicos sobre covenants (restricciones sobre cómo se puede gastar una moneda) o bóvedas son debates sobre si a un byte concreto se le debe permitir significar algo. La pila, los límites y la ausencia de bucles siguen exactamente igual cuando llega un opcode nuevo.