Cointelegraph Research a publié la cinquième partie de sa série sur les covenants Bitcoin, présentant un nouveau cadre appelé MATT (Merkleize All The Things) et l’opcode OP_CHECKCONTRACTVERIFY (OP_CCV). La proposition vise à donner à Bitcoin la capacité de transporter un état de contrat mutable sur plusieurs transactions, une fonctionnalité qui manque aux scripts Bitcoin classiques, chaque transaction étant évaluée isolément.

BTC / USD
Source : CoinGecko. Prix indicatifs.

Comment MATT intègre l’état dans les clés Taproot

MATT s’appuie sur le mécanisme de tweak déjà présent dans Taproot, où la clé publique d’une sortie Taproot Q est dérivée comme Q = P + t·G, P étant la clé interne et t un hash balisé des données à engager. Au lieu de n’engager que la racine Merkle d’un arbre de scripts, MATT propose d’insérer également l’état du contrat dans le tweak. L’état est hashé et inclus dans le tweak, ce qui permet à la sortie suivante de porter un nouvel état recompté au moment de la dépense.

OP_CHECKCONTRACTVERIFY impose les transitions d’état

La primitive centrale de MATT est OP_CHECKCONTRACTVERIFY. Selon le rapport, OP_CCV permet à un script de vérifier qu’une clé d’entrée ou de sortie Taproot a été tweaked avec une donnée d’état précise. Le format de pile de l’opcode est <data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY, avec trois modes opérationnels : défaut (la valeur totale d’entrée est transférée vers la sortie désignée), déduction (seul le montant de la sortie est transféré, le reste restant disponible pour d’autres sorties) et ignorer (vérification sans contrainte de montant). Ces modes conservent la valeur tout en autorisant des entrées de frais séparées, évitant les problèmes de brûlage de fonds observés dans les conceptions antérieures de covenants comme OP_CTV ou SIGHASH_ANYPREVOUT.

Étendre l’expression avec OP_CAT

Lorsque OP_CHECKCONTRACTVERIFY est combiné avec OP_CAT, le cadre peut construire et vérifier des preuves Merkle on‑chain. Deux arbres Merkle sont associés à une sortie Taproot : l’arbre de scripts standard et un arbre d’état séparé qui stocke les étapes intermédiaires de calcul. OP_CAT concatène des chaînes d’octets, permettant au script de reconstituer une preuve Merkle pour l’état actuel, de calculer la nouvelle racine après une transition, puis d’utiliser OP_CCV pour contraindre la prochaine sortie à s’engager sur cette nouvelle racine. Cette conception supporte des systèmes anti‑fraude similaires aux rollups optimistes, où la plupart du calcul se fait hors chaîne et seules les étapes contestées sont publiées on‑chain pour vérification.

Ce qu’il faut surveiller ensuite