Cointelegraph Research publicó la quinta parte de su serie sobre covenants de Bitcoin, detallando un nuevo marco llamado MATT (Merkleize All The Things) y la opcode OP_CHECKCONTRACTVERIFY (OP_CCV). La propuesta busca dotar a Bitcoin de la capacidad de transportar un estado mutable de contrato a través de múltiples transacciones, una funcionalidad que los scripts estándar de Bitcoin no poseen porque cada transacción se evalúa de forma aislada.

BTC / USD
Fuente: CoinGecko. Precios orientativos.

Cómo MATT incrusta el estado en claves Taproot

MATT se basa en el mecanismo de ajuste existente de Taproot, donde la clave pública de salida Q se deriva como Q = P + t·G, con P como la clave interna y t un hash etiquetado de los datos a comprometer. En lugar de comprometer solo la raíz Merkle de un árbol de scripts, MATT propone también incrustar el estado del contrato en el ajuste. El estado se hash y se incluye en el ajuste, permitiendo que la siguiente salida transporte un nuevo estado que se recalcula al momento del gasto.

OP_CHECKCONTRACTVERIFY impone transiciones de estado

La primitiva central de MATT es OP_CHECKCONTRACTVERIFY. Según el informe, OP_CCV permite a un script verificar que una clave de entrada o salida Taproot ha sido ajustada con un dato de estado concreto. El formato de pila de la opcode es <data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY, con tres modos operativos: default (el valor total de la entrada se traslada a la salida designada), deduct (solo se traslada el monto de la salida, dejando el resto para otras salidas) e ignore (verificación sin restricciones de monto). Estos modos preservan el valor mientras permiten entradas de tarifa separadas, evitando los problemas de quema de fondos observados en diseños de covenants anteriores como OP_CTV o SIGHASH_ANYPREVOUT.

Ampliando la expresividad con OP_CAT

Cuando OP_CHECKCONTRACTVERIFY se combina con OP_CAT, el marco puede construir y verificar pruebas Merkle on‑chain. Dos árboles Merkle se asocian a una salida Taproot: el árbol de scripts estándar y un árbol de estado separado que almacena pasos intermedios de cálculo. OP_CAT concatena cadenas de bytes, permitiendo al script reconstruir una prueba Merkle del estado actual, calcular la nueva raíz tras una transición y luego usar OP_CCV para obligar a la siguiente salida a comprometerse con esa nueva raíz. Este diseño soporta sistemas de prueba de fraude similares a los rollups optimistas, donde la mayor parte del cálculo ocurre fuera de la cadena y solo los pasos disputados se publican on‑chain para verificación.

Qué observar a continuación

Los próximos pasos para MATT implicarán propuestas formales de BIP y pruebas comunitarias de implementaciones de OP_CHECKCONTRACTVERIFY en