Esta es la Parte 5 de la serie de artículos técnicos sobre los acuerdos relacionados con Bitcoin, elaborada por Cointelegraph Research. Para leer los artículos anteriores, haga clic aquí: , .
MATT (Merkleize All The Things) es un marco de contratos inteligentes para Bitcoin que permite la creación de contratos con estado y pruebas de fraude escalables. Un contrato con estado transmite información a través de múltiples transacciones y puede actualizar dicha información a medida que el contrato evoluciona. Los scripts estándar de Bitcoin no ofrecen esta capacidad, ya que cada transacción se evalúa de manera independiente, sin guardar memoria de ejecuciones anteriores.
Cada propuesta de acuerdo permite, en cierta medida, que los UTXO (Unspent Transaction Outputs) contengan información de estado, como ilustran lenguajes de programación como Sapio, que se basan en OP_CTV. Esto se logra utilizando direcciones para representar un autómata de estado finito, donde las transacciones funcionan como transiciones de estado. Sin embargo, no existe una forma elegante de implementar lógica numérica en este paradigma; esta brecha es cubierta por MATT, y en particular por su implementación propuesta a través de OP_CCV. Dado que MATT permite que los datos se computen en el momento del gasto y se vuelvan a incorporar en el siguiente resultado de la transacción, cada gasto puede generar un nuevo estado de manera dinámica, en lugar de elegir entre un conjunto predefinido de estados.
Para comprender la propuesta MATT, es útil revisar primero cómo Taproot guarda los datos mediante claves públicas. Cada resultado generado por Taproot contiene una clave pública base, llamada clave interna, que puede ser modificada criptográficamente para almacenar información adicional.Formalmente, la clave pública modificada 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 de P y de los datos comprometidos. En una salida regular de Taproot, este “compromiso” codifica normalmente la raíz Merkle de un árbol de datos (taptree), que contiene rutas de gasto ocultas. MATT aprovecha este mecanismo para incorporar también el estado del contrato en la clave. En lugar de insertar lógica compleja directamente en el lenguaje de scripting de Bitcoin, MATT codifica los cálculos 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 diferentes combinaciones de instrucciones de comando (opcodes); la implementación más directa y bien especificada utiliza OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV proporciona la funcionalidad necesaria para que los objetos de salida (UTXOs) que contienen información de estado sean posibles dentro de Taproot. Permite a un script verificar si una clave de entrada o salida de Taproot ha sido modificada para comprometerse con un dato de estado específico. La clave interna se modifica primero con el hash del estado actual del contrato, y luego se aplica la modificación estándar de Taproot. La clave de salida resultante se compromete tanto con las condiciones de gasto (tapscript) como con el estado actual del contrato. De esta manera, se asegura que el estado transferido a la siguiente salida sea el correcto.El formato de la pila es:
El opcode soporta tres modos para verificar una salida, así como un modo de entrada separado. En el modo por defecto, el valor total en BTC de la entrada UTXO se asigna a la salida especificada; en el modo de deducción, solo se asigna una parte equivalente al monto de la salida, dejando el resto disponible para otras salidas; y en el modo de ignorar, la comprobación de la script y los datos se realiza sin restringir el monto. Dado que los modos por defecto y de deducción están diseñados para preservar el valor de las salidas verificadas, las tarifas de transacción deben pagarse a través de entradas dedicadas a este fin. Se puede agregar una entrada dedicada a los costos y una salida para los cambios dentro de la transacción sin que esto viole las restricciones del contrato. Esto evita la destrucción accidental de fondos, algo que puede ocurrir en implementaciones más primitivas de contratos, como OP_CTV o SIGHASH_ANYPREVOUT. También soluciona una limitación importante de los contratos de tipo “transacción prefirmada”, que suelen definir los montos de antemano y, por lo tanto, no permiten ajustes dinámicos de las tarifas ni liberaciones parciales de fondos.
OP_CCV + OP_CAT: Pruebas Merkle y Pruebas contra Fraudes (Merkle Proofs and Fraud Proofs)
Cuando OP_CCV se combina con OP_CAT, el conjunto de herramientas MATT (Merkle, Authentication, and Transaction) se vuelve aún más potente. OP_CAT permite la concatenación de bytes en las scripts, lo que hace posible construir y verificar pruebas Merkle directamente en la cadena. En este arreglo, dos árboles Merkle distintos están asociados a una salida de tipo Taproot: el primero es el árbol de scripts correspondiente a Taproot (taptree), cuyas hojas contienen las scripts de gasto del contrato.El segundo elemento es un árbol de estados independiente, cuyas “hojas” representan los datos del contrato, como los pasos intermedios de un cálculo. La secuencia de comandos OP_CCV + OP_CAT puede verificar una prueba de tipo Merkle en relación con la raíz del árbol de estados actual, calcular la raíz actualizada después de una transición y utilizar OP_CCV para asegurar que la salida resultante sea almacenada de manera fiable en el blockchain. Esta arquitectura permite sistemas a prueba de fraude, ya que los cálculos complejos se realizan fuera del blockchain, y solo el paso específico en disputa (junto con su correspondiente ruta en el árbol binario) necesita ser revelado y verificado dentro del blockchain. Sistemas similares existen en otras cadenas de bloques; en estos casos, el cálculo completo se lleva a cabo fuera del blockchain, y el contrato del blockchain interviene únicamente cuando surge una duda. Las pruebas de fraude requieren que el cálculo se reduzca a una representación binaria o a un proceso paso a paso que pueda ser almacenado en un árbol de Merkle. La combinación de OP_CCV y OP_CAT evita la necesidad de utilizar firmas únicas (de tipo Lamport) o gráficos de transacciones prefirmados, que BitVM utiliza para garantizar la consistencia de los estados del blockchain. Además, esta combinación también tiene implicaciones significativas para los sistemas de almacenamiento de datos seguros („vaults“): OP_CCV por sí solo puede ser utilizado para crear tales sistemas, pero en combinación con OP_CAT se pueden diseñar soluciones más avanzadas, equivalentes en funcionalidad a las propuestas por 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 supera efectivamente las propuestas anteriores. En el próximo artículo de esta serie, pasaremos a analizar códigos de comando específicos para aplicaciones, como OP_VAULT, OP_UNVAULT y OP_EVICT.Cada uno de los códigos de operación (opcodes) está diseñado para resolver un problema específico, en lugar de proporcionar una amplia capacidad de programación.
Revista: Los poseedores de Bitcoin han recibido eCash: ¿qué puedes hacer con él?
