Una proposta ora aperta nel repository Bitcoin Core darebbe agli script della rete qualcosa che non hanno mai avuto: una memoria. Il framework alla base, noto come MATT (Merkleize All The Things), abilita contratti con stato e fraud proof scalabili sul layer di base di Bitcoin, e la sua implementazione più diretta passa attraverso l'opcode OP_CCV definito nella pull request #32080 di Bitcoin Core. Lo sviluppo è stato riportato da COINOTAG l'11 novembre 2026.

A cosa è destinato MATT

Il linguaggio di scripting esistente di Bitcoin valuta ogni input di transazione in modo indipendente, senza alcun meccanismo integrato che consenta a uno script di determinare come quelle monete potranno essere spese in seguito. MATT, descritto per la prima volta dallo sviluppatore Salvatore Ingala sulla mailing list Bitcoin-Dev alla fine del 2022, punta esattamente a colmare questo vuoto: il suo obiettivo è permettere agli script di Bitcoin di mantenere lo stato tra le transazioni — in sostanza, dare una memoria ai contratti — con solo un'aggiunta minima al linguaggio di scripting. Costruzioni di questo tipo, comunemente chiamate covenant, limitano come una moneta possa essere spesa in transazioni future e abilitano progetti come vault e altre regole di spesa auto-applicative, in cui le condizioni di recupero e spesa sono applicate direttamente alle monete stesse.

Proposte in stile covenant circolano nella community di Bitcoin da anni, e MATT si affianca a sforzi correlati come l'OP_CHECKTEMPLATEVERIFY (OP_CTV), proposto dallo sviluppatore Jeremy Rubin, nel cercare di estendere ciò che il layer di base può esprimere.

Fraud proof e verifica sul layer di base

Un secondo obiettivo del framework sono i fraud proof scalabili: schemi di verifica in cui un calcolo off-chain viene controllato on-chain solo quando viene sollevata una contestazione, anziché essere rieseguito integralmente — un modello utilizzato, ad esempio, nei design di optimistic rollup su altre piattaforme, dove il calcolo avviene off-chain e solo i risultati contestati richiedono un esame sul layer di base. Poiché lo sforzo di verifica è legato alle contestazioni piuttosto che alla dimensione del calcolo stesso, tali schemi vengono descritti come scalabili. Nel design di MATT, questa verifica è destinata a girare direttamente sul layer di base di Bitcoin, con OP_CCV (sigla di OP_CHECKCONTRACTVERIFY) che funge da opcode centrale per l'applicazione della logica dei contratti.

Riesame, non attivazione

Le modifiche a Bitcoin che incidono sul consenso avanzano tramite pull request pubbliche nel repository GitHub di Bitcoin Core, dove il riesame tecnico e i test si protraggono tipicamente per periodi prolungati. Poiché le regole di consenso di Bitcoin sono applicate in ultima analisi dagli operatori di full node della rete, un esito favorevole del riesame del codice è solo un passaggio; è l'ampia adozione da parte dell'ecosistema più ampio a trasformare una modifica proposta in una regola attiva della rete. L'aggiornamento del consenso più recente di Bitcoin, Taproot, è stato attivato a novembre 2021 dopo un processo pluriennale, una traiettoria che illustra quanto a lungo questi sforzi possano protrarsi. La pull request #32080, come tutte le proposte di questo tipo, richiederebbe un riesame approfondito e un ampio accordo della community prima che qualsiasi attivazione possa essere presa in considerazione; il rapporto della fonte non indica una tempistica. Il suo thread di riesame pubblico su GitHub, dove si accumulano i commenti tecnici e le revisioni dei contributori, offre un modo diretto per seguire se la proposta avanza.

Questo contenuto è stato pubblicato per la prima volta su COINOTAG: https://en.coinotag.com/matt-op-ccv-bitcoin-covenant-pull-request-32080