Une proposition actuellement ouverte dans le dépôt Bitcoin Core offrirait aux scripts du réseau quelque chose qu'ils n'ont jamais eu : une mémoire. Le framework qui la sous-tend, connu sous le nom de MATT (Merkleize All The Things), permet des contrats à état et des preuves de fraude évolutives sur la couche de base de Bitcoin, et son implémentation la plus directe passe par l'opcode OP_CCV défini dans la pull request #32080 de Bitcoin Core. Ce développement a été rapporté par COINOTAG le 11 novembre 2026.

Ce que MATT est conçu pour faire

Le langage de script existant de Bitcoin évalue chaque entrée de transaction de manière indépendante, sans mécanisme intégré permettant à un script de dictere comment ces pièces pourront être dépensées ensuite. MATT, décrit pour la première fois par le développeur Salvatore Ingala sur la liste de diffusion Bitcoin-Dev fin 2022, cible précisément cette lacune : son objectif est de permettre aux scripts Bitcoin de conserver un état entre les transactions — donnant en pratique une mémoire aux contrats — avec seulement un ajout minimal au langage de script. Les constructions de ce type, communément appelées covenants, restreignent la manière dont une pièce peut être dépensée lors de transactions futures et permettent des conceptions telles que les coffres-forts (vaults) et d'autres règles de dépense auto-exécutoires, dans lesquelles les conditions de récupération et de dépense sont attachées directement aux pièces elles-mêmes.

Les propositions de type covenant circulent dans la communauté Bitcoin depuis des années, et MATT rejoint des efforts similaires tels que l'OP_CHECKTEMPLATEVERIFY (OP_CTV), proposé par le développeur Jeremy Rubin, dans la recherche d'extension des capacités expressives de la couche de base.

Preuves de fraude et vérification sur la couche de base

Un second objectif du framework est les preuves de fraude évolutives : des schémas de vérification dans lesquels un calcul hors chaîne n'est vérifié sur la chaîne que lorsqu'une contestation est soulevée, plutôt que d'être réexécuté intégralement — un modèle utilisé, par exemple, dans les conceptions de rollups optimistes sur d'autres plateformes, où le calcul s'effectue hors chaîne et où seuls les résultats contestés exigent un examen sur la couche de base. Comme l'effort de vérification est lié aux contestations plutôt qu'à la taille du calcul lui-même, ces schémas sont qualifiés d'évolutifs. Dans la conception MATT, cette vérification est destinée à s'exécuter directement sur la couche de base de Bitcoin, l'opcode OP_CCV (abréviation de OP_CHECKCONTRACTVERIFY) servant d'opcode central pour l'application de la logique des contrats.

Revue, pas activation

Les modifications affectant le consensus de Bitcoin avancent via des pull requests publiques dans le dépôt GitHub de Bitcoin Core, où la revue technique et les tests s'étendent généralement sur de longues périodes. Étant donné que les règles de consensus de Bitcoin sont finalement appliquées par les opérateurs de nœuds complets à travers le réseau, une revue de code favorable n'est qu'une étape ; c'est l'adoption large par l'ensemble de l'écosystème qui transforme une modification proposée en règle réseau active. La plus récente mise à niveau du consensus de Bitcoin, Taproot, a été activée en novembre 2021 après un processus de plusieurs années, une trajectoire qui illustre la durée que peuvent prendre de tels efforts. La pull request #32080, comme toutes les propositions de ce type, nécessiterait une revue approfondie et un large accord communautaire avant qu'une activation puisse être envisagée ; le rapport source n'indique aucun calendrier. Son fil de revue public sur GitHub, où s'accumulent les commentaires techniques et les révisions des contributeurs, offre un moyen direct de suivre l'avancement de la proposition.

Ce contenu a d'abord été publié sur COINOTAG : https://en.coinotag.com/matt-op-ccv-bitcoin-covenant-pull-request-32080