Esta es la parte 5 de la serie de artículos técnicos de Cointelegraph Research sobre los covenants de Bitcoin. Para leer el artículo anterior, haz clic aquí.
MATT (Merkleize All The Things) es un marco de contratos inteligentes para Bitcoin que permite crear contratos con estado y pruebas de fraude escalables. Un contrato con estado conserva información entre varias transacciones y puede actualizarla a medida que evoluciona. Los scripts estándar de Bitcoin no ofrecen esta capacidad, porque cada transacción se evalúa de forma independiente y no conserva memoria de las ejecuciones anteriores.
Toda propuesta de covenant permite hasta cierto punto UTXO que transportan estado, como ilustran lenguajes de scripting como Sapio, que se basa en OP_CTV. Esto funciona usando direcciones para representar un autómata de estados finitos, donde las transacciones actúan como transiciones de estado. Sin embargo, no hay una forma elegante de implementar lógica numérica en este paradigma; MATT cubre esa carencia, en particular mediante su implementación propuesta a través de OP_CCV. Como MATT permite calcular los datos comprometidos en el momento de gastar y volver a incluirlos en la siguiente salida, cada gasto puede derivar dinámicamente un nuevo estado, en lugar de elegirlo de un conjunto predeterminado de estados.
Cómo OP_CCV compromete el estado en una clave Taproot
Para comprender la propuesta MATT, conviene repasar primero cómo Taproot compromete datos mediante claves públicas. Cada salida Taproot contiene una clave pública base, llamada clave interna, que puede modificarse criptográficamente o «ajustarse» (tweaked) para comprometer información adicional. Formalmente, la clave pública ajustada es Q = P + t·G, donde P es la clave interna, G es el generador de la curva elíptica secp256k1 y t es un hash etiquetado de P y de los datos comprometidos.
En una salida Taproot normal, este compromiso suele codificar la raíz de Merkle de un árbol taptree, que contiene rutas de gasto ocultas. MATT se basa en este mecanismo para incluir también el estado del contrato en la clave. En lugar de incluir lógica compleja directamente en el lenguaje de scripting de Bitcoin, MATT codifica el cálculo como una secuencia de compromisos de estado, y la cadena solo verifica que cada transición de estado sea válida.
MATT puede implementarse mediante distintas combinaciones de opcodes. La implementación más directa y mejor especificada se basa en OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV proporciona la primitiva que permite tener UTXO que transportan estado dentro de Taproot. OP_CCV permite que un script verifique que la clave de entrada o salida Taproot se haya ajustado para comprometer un dato de estado específico. Primero se ajusta la clave interna con un hash del estado actual del contrato y, después, se aplica encima el ajuste estándar del árbol taptree de Taproot. Por tanto, la clave de salida resultante compromete tanto el tapscript (el conjunto de condiciones de gasto) como el estado actual del contrato.
OP_CCV puede entonces imponer qué estado se transfiere a la siguiente salida. Permite que el script inspeccione los datos de estado proporcionados en la pila witness, realice cálculos con ellos y exija que el estado actualizado resultante se vuelva a comprometer correctamente en una salida especificada. Así es como se imponen las transiciones de estado en la cadena. El formato de la pila es:
<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY
El opcode admite tres modos para comprobar una salida, además de un modo independiente para entradas. En el modo predeterminado, todo el valor en BTC del UTXO de entrada se asigna a la salida especificada; en el modo de deducción, solo se asigna una cantidad igual al importe de la salida, y el resto queda disponible para otras salidas; y en el modo de ignorar, se verifican el script y el compromiso de datos sin imponer restricciones sobre el importe. Como los modos predeterminado y de deducción están diseñados para conservar el valor entre las salidas comprobadas, las comisiones de transacción deben pagarse mediante entradas independientes destinadas a cubrirlas. Se pueden añadir a la transacción una entrada específica para las comisiones y una salida de cambio sin entrar en conflicto con las restricciones del covenant. Esto evita la quema accidental de fondos que puede producirse con implementaciones de covenant más primitivas, como OP_CTV o SIGHASH_ANYPREVOUT. También aborda una limitación importante de los covenants basados en transacciones prefirmadas, que suelen fijar los importes de antemano y, por tanto, no pueden admitir ajustes dinámicos de comisiones ni desprecintados parciales.
OP_CCV + OP_CAT: pruebas de Merkle y pruebas de fraude
Al combinar OP_CCV con OP_CAT, el marco MATT completo se vuelve aún más expresivo. OP_CAT permite concatenar bytes en Script, lo que hace posible construir y verificar pruebas de Merkle directamente en la cadena. En esta configuración, una salida Taproot está asociada a dos árboles de Merkle distintos. El primero es el conocido árbol de scripts de Taproot (el taptree), cuyas hojas son los scripts de gasto del contrato. El segundo es un árbol de estado independiente, cuyas hojas son los datos del contrato, como los pasos intermedios de un cálculo. El script OP_CCV + OP_CAT puede verificar una prueba de Merkle respecto a la raíz del árbol de estado actual, calcular la raíz actualizada tras una transición y usar OP_CCV para obligar a que la siguiente salida se comprometa con ella.
Esta construcción permite crear sistemas de pruebas de fraude con una condición de penalización en los que un cálculo largo se compromete fuera de la cadena, y solo es necesario revelar y verificar en la cadena el paso específico en disputa (junto con su ruta en el árbol binario). Existen sistemas similares en forma de rollups optimistas en otras cadenas de bloques: el cálculo completo se ejecuta fuera de la cadena y el contrato en la cadena solo interviene cuando alguien presenta una impugnación. Las pruebas de fraude requieren que el cálculo se compile en un circuito binario o en una representación equivalente, paso a paso, que pueda incluirse en un árbol de Merkle. OP_CCV + OP_CAT evitaría la necesidad de las firmas de un solo uso de Lamport y los grafos de transacciones prefirmadas en los que se basa BitVM para imponer la coherencia del estado.
Además de las pruebas de fraude, la combinación de OP_CCV y OP_CAT también tiene implicaciones para las bóvedas. OP_CCV por sí solo puede implementar bóvedas, pero al combinarlo con OP_CAT se obtienen bóvedas con todas las funcionalidades, esencialmente equivalentes a las que propone OP_VAULT. Como ha señalado James O’Beirne, autor de OP_VAULT, OP_CCV representa un diseño más general y robusto que, en la práctica, sustituye su propuesta anterior.
En el próximo artículo de esta serie, pasaremos de las propuestas generales de covenant a revisar opcodes específicos para aplicaciones, como OP_VAULT, OP_UNVAULT y OP_EVICT. Cada uno de estos opcodes está diseñado para resolver un problema específico, en lugar de ofrecer una programabilidad amplia.
Revista: Los titulares de Bitcoin han recibido eCash: ¿qué pueden hacer con él?