Glosario / Referencia para desarrolladores
OP_EQUAL
- ¿Qué es OP_EQUAL?
- OP_EQUAL compara byte a byte los dos elementos de la cima de la pila y apila un resultado verdadero o falso, y es el último opcode (código de operación) de toda salida pay-to-script-hash.
El byte 0x87 hace la única comparación que bitcoin realmente necesita: ¿son idénticas estas dos cadenas de bytes? La comparación se hace sobre bytes en bruto y no sobre números, y por eso el lenguaje incluye un opcode aparte para la igualdad aritmética. Todo pago que usted haya enviado alguna vez a una dirección que empieza por 3 termina su script con esta única instrucción.
Cómo funciona
Se desapilan dos elementos y se apila uno: un solo byte 0x01 cuando coinciden, o un elemento vacío cuando no. Bitcoin trata un elemento vacío como falso, así que cualquier cosa que venga después puede comprobar el resultado.
La comparación de bytes es más estricta de lo que parece. Dos valores que una persona llamaría el mismo número pueden ser cadenas de bytes distintas, y este opcode los considera desiguales. Es el comportamiento correcto para su verdadera función, que es comparar hash y preimágenes, donde cualquier diferencia, por mínima que sea, debe fallar, y es la razón por la que los resultados aritméticos se comparan en cambio con el opcode OP_NUMEQUAL.
La propiedad interesante es lo que no hace: deja un resultado en lugar de actuar sobre él. Un script termina con éxito solo cuando el elemento que queda en la cima es verdadero, así que un script que acaba con este opcode hace una pregunta y deja que el resultado valga como respuesta. La regla cleanstack de Bitcoin Core añade que no puede quedar nada más, lo que en un gasto de hash de script significa exactamente un valor verdadero y nada más.
Ese último detalle tiene más consecuencias de lo que parece. Pay-to-script-hash no es una regla general sobre scripts reducidos a su hash; es una regla sobre un patrón exacto de 23 bytes: un opcode de hash, una inserción de datos de 20 bytes y este opcode al final. Si se escribe la misma lógica con la variante VERIFY combinada, el tratamiento especial no se aplica, el script de canje nunca se extrae ni se ejecuta, y la salida se comporta como un acertijo de hash corriente que puede gastar cualquiera que adivine la preimagen.
Dónde aparece
En un explorador de bloques, todo UTXO de una dirección que empieza por 3 muestra la misma representación en ensamblador (ASM) de tres palabras, que termina aquí. Lo mismo ocurre con todo retiro SegWit anidado que un exchange le haya enviado alguna vez.
También aparece en los contratos con bloqueo por hash. Los scripts de pago de Lightning calculan el hash de un secreto y comparan el resultado con un valor fijo, que es lo que permite que un pago se liquide a lo largo de varios saltos en el momento en que el destinatario revela una preimagen de 32 bytes. Los intercambios atómicos entre cadenas usan la misma estructura.
OP_EQUAL frente a OP_EQUALVERIFY
El opcode OP_EQUALVERIFY es OP_EQUAL con la comprobación incorporada. El byte 0x88 realiza la misma comparación y luego aborta el script de inmediato si la respuesta es falsa, sin dejar nada en la pila cuando tiene éxito. Elegir entre los dos es cuestión de lo que venga después. Use la forma simple cuando la comparación sea la respuesta final del script, como hace pay-to-script-hash. Use la variante VERIFY cuando la comparación sea una condición entre varias y la ejecución deba continuar, como hace la plantilla heredada (legacy) de una sola clave antes de verificar una firma. La variante VERIFY también ahorra un byte frente a escribir la comparación y una instrucción de verificación aparte, algo que importaba mucho más cuando cada byte de un script estaba en la parte de la transacción sin datos de testigo, a cuatro unidades de peso cada uno.