{"id":787,"date":"2026-10-14T16:39:13","date_gmt":"2026-10-14T16:39:13","guid":{"rendered":"https:\/\/hoge.gg\/it\/taproot-bitvm-rollup-bitcoin-senza-fork-2026\/"},"modified":"2026-10-14T16:39:13","modified_gmt":"2026-10-14T16:39:13","slug":"taproot-bitvm-rollup-bitcoin-senza-fork-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/taproot-bitvm-rollup-bitcoin-senza-fork-2026\/","title":{"rendered":"Taproot e BitVM: i rollup su Bitcoin senza un nuovo fork"},"content":{"rendered":"

Un campo dimenticato di Taproot torna protagonista<\/h2>

Quando Taproot si \u00e8 attivato nel novembre 2021, al blocco 709.632, venne raccontato soprattutto come un aggiornamento di privacy ed efficienza: firme pi\u00f9 piccole, script pi\u00f9 economici, indirizzi che iniziano con bc1p. Cinque anni dopo, la sua eredit\u00e0 pi\u00f9 importante \u00e8 un’altra. Taproot ha fornito i mattoni crittografici che oggi rendono Bitcoin programmabile senza toccarne le regole di consenso, e quasi nessuno dei Layer 2 nati nel 2026 esisterebbe senza di essi (CoinDesk<\/a>).<\/p>

La prova pi\u00f9 recente \u00e8 arrivata ai primi di ottobre 2026. Robin Linus, l’autore di BitVM, ha aperto la pull request numero 36466<\/a> su Bitcoin Core per rendere standard la propagazione dell’annex di Taproot, un campo riservato dal 2021 e rimasto quasi senza un uso concreto (BTC++ Insider<\/a>). \u00c8 una modifica tecnica e in apparenza marginale, ma racconta una storia pi\u00f9 grande.<\/p>

Nel 2026 i Layer 2 che stanno crescendo su Bitcoin, dal rollup Citrea alle statechain di Spark fino ai contratti con oracolo, poggiano quasi tutti su primitive introdotte da Taproot. E lo fanno mentre il protocollo resta immobile: Taproot \u00e8 l’ultimo soft fork riuscito, e dal 2021 Bitcoin non ne ha approvato un altro. Questo articolo spiega come un aggiornamento venduto per la privacy sia diventato la fondazione della programmabilit\u00e0 di Bitcoin, perch\u00e9 l’annex conti pi\u00f9 di quanto sembri, e dove si fermano davvero questi nuovi livelli.<\/p>

Cosa aveva introdotto Taproot nel 2021<\/h2>

Taproot non \u00e8 stato un singolo cambiamento, ma un pacchetto di tre BIP attivati insieme con il metodo Speedy Trial, dopo oltre il 90% di segnalazione dei miner nel giugno 2021. BIP-340 ha portato le firme Schnorr (autori Pieter Wuille, Jonas Nick e Tim Ruffing), BIP-341 ha introdotto la struttura Taproot e gli alberi di script MAST, BIP-342 ha definito Tapscript, la versione dello scripting usata negli output Taproot.<\/p>

Per i Layer 2 contano soprattutto tre propriet\u00e0. Le firme Schnorr sono lineari, quindi si possono aggregare (con schemi come MuSig2 e FROST) e trasformare in adaptor signature, cio\u00e8 firme condizionate alla rivelazione di un segreto. MAST permette di impegnarsi a un albero di script anche enorme rivelando on-chain solo il ramo effettivamente usato, un dettaglio che diventa decisivo per BitVM. Tapscript, infine, introduce un versioning che lascia spazio a estensioni future senza rompere nulla.<\/p>

L’adozione racconta bene la parabola. Dopo aver superato il 40% delle transazioni all’inizio del 2024, trainata dalla febbre di Ordinals e Runes, la quota di output Taproot si \u00e8 poi normalizzata su livelli pi\u00f9 bassi e pi\u00f9 organici, legati a wallet e protocolli invece che alla speculazione sulle iscrizioni. Il punto non \u00e8 pi\u00f9 quante transazioni usano Taproot, ma cosa ci si pu\u00f2 costruire sopra.<\/p>

Un esempio concreto aiuta a capire la portata del cambiamento. Con le vecchie firme ECDSA, un multisig a tre firme su cinque appariva on-chain come tale, pesante e riconoscibile. Con Schnorr e lo schema MuSig2 le chiavi possono essere aggregate in una sola firma, e una spesa multisig diventa indistinguibile da un pagamento ordinario: pi\u00f9 privacy, meno byte, commissioni pi\u00f9 basse. \u00c8 lo stesso principio che permette a protocolli come Spark di usare FROST, una firma a soglia che distribuisce il controllo tra pi\u00f9 operatori senza mai mostrarlo alla rete. Il multisig, con Taproot, \u00e8 diventato invisibile.<\/p>

Componente (BIP)<\/th>Cosa introduce<\/th>Cosa abilita sui Layer 2<\/th><\/tr><\/thead>
Schnorr (BIP-340)<\/td>Firme lineari e aggregabili<\/td>MuSig2 e FROST (multisig invisibile), adaptor signature per DLC e PTLC<\/td><\/tr>
Taproot e MAST (BIP-341)<\/td>Alberi di script, si rivela solo il ramo speso<\/td>Programmi enormi impegnati in poco spazio: \u00e8 la base di BitVM<\/td><\/tr>
Tapscript (BIP-342)<\/td>Scripting con versioning<\/td>Margine per estensioni future e per script complessi off-chain<\/td><\/tr><\/tbody><\/table><\/figure>

L’annex: il contenitore inutilizzato che ora serve ai Layer 2<\/h2>

L’annex \u00e8 un campo opzionale nella struttura witness di ogni input Taproot. Le regole di consenso lo prevedono dal 2021, ma lo hanno lasciato vuoto e privo di significato, in attesa di un uso futuro. Per anni quell’uso non \u00e8 arrivato, e l’annex \u00e8 rimasto un pezzo di Bitcoin presente ma spento.<\/p>

La pull request 36466 di Robin Linus prova a cambiare le cose. Linus, oltre a BitVM, sviluppa Glass Coins (in precedenza Shielded CSV), un protocollo a validazione client-side: per impedire la doppia spesa deve pubblicare piccoli dati di controllo sulla blockchain, e l’annex \u00e8 il posto naturale dove metterli. Il problema \u00e8 che Bitcoin Core, il client di riferimento, non propaga per impostazione predefinita le transazioni che contengono un annex, quindi oggi quel campo \u00e8 di fatto inutilizzabile sulla rete pubblica.<\/p>

Il dibattito si \u00e8 acceso in fretta. Lo sviluppatore noto come Rearden ha fatto notare che implementazioni alternative del nodo, come LibreRelay e rbitcoin, gi\u00e0 propagano gli annex, quindi l’infrastruttura esiste in parte altrove (BTC++ Insider<\/a>). Standardizzare il comportamento nel client dominante, per\u00f2, \u00e8 un’altra cosa, perch\u00e9 definisce ci\u00f2 che migliaia di nodi considerano una transazione normale.<\/p>

La vicenda \u00e8 istruttiva proprio perch\u00e9 non riguarda il consenso. L’annex \u00e8 gi\u00e0 legale secondo le regole di Bitcoin: qui si discute solo di politica di propagazione, cio\u00e8 di cosa i nodi accettano di inoltrare. \u00c8 l’ennesimo caso in cui Taproot offre spazio di progettazione senza bisogno di un soft fork, perch\u00e9 la capacit\u00e0 c’era gi\u00e0 e bisogna solo decidere di usarla.<\/p>

C’\u00e8 anche una dimensione economica. Ogni byte che finisce on-chain compete per lo spazio di blocco, la stessa risorsa scarsa che i miner vendono al mercato e che determina le commissioni; un uso ordinato dell’annex eviterebbe che gli stessi dati vengano infilati in modi pi\u00f9 dispersivi, come gi\u00e0 accade con alcune iscrizioni. \u00c8 un tema che si intreccia con l’economia della sicurezza di Bitcoin, dove la corsa per lo spazio e per l’energia pesa su chi mina, come abbiamo raccontato analizzando la difficolt\u00e0 di Bitcoin come un’asta per l’energia<\/a>.<\/p>

BitVM: calcolo arbitrario su Bitcoin senza soft fork<\/h2>

BitVM \u00e8 l’idea che ha riaperto la discussione su cosa Bitcoin possa davvero fare. Presentata da Robin Linus, fondatore di ZeroSync, nell’ottobre 2023, propone un modo per verificare computazioni arbitrarie su Bitcoin senza modificare il consenso, sfruttando un modello a prova di frode (whitepaper BitVM<\/a>).<\/p>

Il meccanismo si appoggia direttamente a Taproot. Grazie a MAST, un intero programma pu\u00f2 essere spezzato in centinaia di foglie Tapscript e impegnato in un unico output Taproot; on-chain si rivela soltanto la foglia che serve. Le firme pre-costruite e i timelock incatenano le transazioni in una sequenza prevedibile, mentre gli hashlock legano i vari pezzi tra loro. Senza gli alberi di script di Taproot, un programma del genere non entrerebbe in una transazione Bitcoin.<\/p>

Il modello \u00e8 ottimistico, come i rollup di Ethereum, ma vive dentro i vincoli stretti di Script. Un operatore afferma un risultato e, se mente, chiunque pu\u00f2 pubblicare una prova di frode che esegue on-chain il pezzo di computazione contestato, dimostra l’inganno e gli fa perdere la cauzione. Nel caso normale, quando tutti sono onesti, non accade nulla di costoso: la sola minaccia della prova di frode basta a tenere in riga gli operatori.<\/p>

Da BitVM a BitVM2 e BitVM3<\/h2>

La prima versione di BitVM aveva un limite pratico: richiedeva lunghi giochi interattivi di bisezione tra due parti fissate in anticipo, uno schema poco adatto a un bridge aperto. BitVM2, presentato nell’agosto 2024, ha reso le prove di frode succinte: la verifica di una SNARK viene spezzata su pi\u00f9 foglie Tapscript, chiunque pu\u00f2 fare da sfidante senza bisogno di permessi, e nel caso contestato bastano tre transazioni on-chain per risolvere la disputa (paper BitVM2<\/a>).<\/p>

La ricerca non si \u00e8 fermata. BitVM3, descritto in un paper del 2026, punta a bridge ancora pi\u00f9 efficienti usando i garbled circuit, una tecnica che riduce i dati da pubblicare on-chain. L’obiettivo dichiarato \u00e8 rendere economicamente sostenibile ci\u00f2 che BitVM2 ha reso tecnicamente possibile.<\/p>

Il punto che conta per questa storia \u00e8 uno solo: niente di tutto questo richiede un soft fork. BitVM gira con il Bitcoin di oggi, cos\u00ec com’\u00e8 uscito da Taproot. \u00c8 la ragione per cui i primi Layer 2 trust-minimized del 2026 sono stati costruiti su BitVM invece di aspettare l’attivazione dei covenant, un processo che in Bitcoin pu\u00f2 richiedere anni di dibattito e non \u00e8 affatto garantito.<\/p>

Resta il fatto che BitVM non \u00e8 gratis. Gli operatori di un ponte devono immobilizzare capitale come garanzia, i periodi di contestazione introducono attese prima che un prelievo sia definitivo, e la pubblicazione delle prove di frode, nel caso peggiore, costa spazio di blocco prezioso. Sono compromessi accettabili per muovere valore tra Bitcoin e un secondo livello, ma spiegano perch\u00e9 un covenant nativo, se mai venisse attivato, renderebbe questi ponti molto pi\u00f9 economici. BitVM \u00e8 la prova che si pu\u00f2 fare oggi, non la dimostrazione che sia la soluzione definitiva.<\/p>

Citrea, il primo ZK-rollup in produzione su Bitcoin<\/h2>

Il progetto che ha portato questa teoria in mainnet \u00e8 Citrea, che il 27 gennaio 2026 \u00e8 diventato il primo ZK-rollup in produzione a regolare direttamente su Bitcoin (The Block<\/a>). \u00c8 un rollup di tipo Type 2 zkEVM, quindi compatibile con gli smart contract scritti per Ethereum.<\/p>

Il funzionamento \u00e8 quello di un rollup a conoscenza zero adattato a Bitcoin. Citrea esegue le transazioni EVM fuori dalla catena, raggruppa i risultati e genera prove STARK (tramite RISC Zero) che vengono poi compresse in una SNARK; questa prova, insieme alle differenze di stato, viene pubblicata su Bitcoin in una busta simile a un’iscrizione. Bitcoin funge cos\u00ec sia da livello di disponibilit\u00e0 dei dati sia da livello di regolamento, e lo stato del rollup resta ricostruibile a partire dalla sola blockchain di Bitcoin (documentazione Citrea<\/a>).<\/p>

Per un utente, in pratica, Citrea assomiglia a una catena EVM qualsiasi: si collega un wallet, si usano exchange decentralizzati, si deposita cBTC in protocolli di prestito. La differenza sta sotto il cofano, dove la sicurezza non dipende da un validator set proprio ma dall’ancoraggio a Bitcoin. Il punto debole, comune a quasi tutti i rollup giovani, \u00e8 il sequencer: all’avvio \u00e8 centralizzato, e la decentralizzazione della produzione dei blocchi resta un obiettivo futuro, non una realt\u00e0 del primo giorno.<\/p>

Sul fronte degli asset, il gas nativo \u00e8 cBTC, cio\u00e8 Bitcoin stesso portato sul rollup, mentre la stablecoin ctUSD \u00e8 emessa da MoonPay sull’infrastruttura di M0. Al lancio Citrea contava oltre 30 applicazioni, tra exchange decentralizzati, strumenti di liquidit\u00e0 e protocolli di prestito. Dietro il progetto c’\u00e8 un percorso di finanziamento solido: 2,7 milioni di dollari di seed guidato da Galaxy nel 2023 e 14 milioni di dollari di Series A guidato da Founders Fund nell’ottobre 2024, la prima scommessa del fondo di Peter Thiel sull’ecosistema Bitcoin, con la partecipazione di Delphi, Figment e di angel come Jameson Lopp (CoinDesk<\/a>). L’arrivo di stablecoin native e di custodia programmabile su Bitcoin \u00e8 esattamente il terreno su cui le banche italiane stanno passando dalla difesa all’attacco<\/a>.<\/p>

Il ponte Clementine e il modello 1-di-N<\/h2>

Il punto pi\u00f9 delicato di qualsiasi Layer 2 di Bitcoin \u00e8 il ponte, cio\u00e8 il luogo dove i BTC restano bloccati mentre una loro rappresentazione circola sul secondo livello. Qui si concentra la maggior parte del rischio, come insegna la lunga lista di bridge svuotati negli anni. Citrea affronta il problema con Clementine, un ponte basato su BitVM.<\/p>

Clementine adotta un’assunzione di fiducia descritta come 1-di-N: finch\u00e9 anche un solo verificatore, in un insieme predefinito, si comporta onestamente, nessuno pu\u00f2 rubare i BTC in custodia. Il meccanismo usa Light Client Proof che incorporano le batch proof di Citrea provate in modo ricorsivo, e questo consente una verifica ottimistica delle prove a conoscenza zero direttamente su Bitcoin tramite BitVM (documentazione Citrea<\/a>).<\/p>

\u00c8 un salto netto rispetto ai bridge federati tradizionali, dove bisogna fidarsi di una maggioranza di firmatari, per esempio 8 su 15. Ma 1-di-N non significa fiducia zero: l’insieme dei verificatori \u00e8 fisso, la disponibilit\u00e0 del servizio dipende dagli operatori, e la complessit\u00e0 stessa del codice \u00e8 un rischio. La storia dei Layer 2 insegna che i ponti si rompono pi\u00f9 per bug e per chiavi gestite male che per debolezze del modello teorico.<\/p>

Vale la pena insistere su un punto, perch\u00e9 \u00e8 qui che molti progetti inciampano. Un modello 1-di-N presuppone che almeno un verificatore onesto sia non solo presente, ma anche online e capace di agire entro le finestre temporali previste. Serve dunque qualcuno che vigili, un ruolo simile a quello delle watchtower su Lightning, e serve che il codice del ponte sia stato verificato a fondo. La teoria regge; \u00e8 l’ingegneria, con le sue chiavi, i suoi aggiornamenti e i suoi errori umani, a fare la differenza tra un ponte sicuro e il prossimo titolo di cronaca.<\/p>

Spark e le statechain: self-custody e firme FROST<\/h2>

Non tutti i Layer 2 inseguono gli smart contract. Spark, protocollo open-source lanciato da Lightspark, punta sui pagamenti ad alta velocit\u00e0 e sull’emissione di stablecoin e token, ed \u00e8 costruito sulla tecnologia delle statechain, con elementi di atomic swap, compatibilit\u00e0 con Lightning e idee prese da Ark (NoBSBitcoin<\/a>).<\/p>

Una statechain trasferisce la propriet\u00e0 di una UTXO on-chain senza trasmettere alcuna transazione. Invece di muovere i bitcoin, il protocollo ruota le chiavi tra mittente, destinatario e un coordinatore: la UTXO non si sposta mai, cambia soltanto chi ha la capacit\u00e0 di spenderla. Spark usa un modello a due firme su due, dove una chiave appartiene all’utente e l’altra \u00e8 detenuta collettivamente dagli operatori tramite firma a soglia FROST, costruita sulle firme Schnorr di Taproot. Nessuna delle due parti pu\u00f2 muovere i fondi da sola, e la self-custody resta intatta perch\u00e9 l’utente conserva transazioni di uscita pre-firmate.<\/p>

L’innovazione pratica \u00e8 l’architettura a foglie, che permette di dividere e ricombinare i saldi in un albero fuori catena e quindi di trasferire importi arbitrari, superando un limite storico delle statechain. Anche qui l’assunzione di sicurezza \u00e8 di tipo 1-di-N, ma l’approccio \u00e8 diverso da quello di un rollup: niente macchina virtuale generalista, bens\u00ec massima efficienza sui pagamenti e sui token (Spark<\/a>).<\/p>

Il senso pratico di Spark si vede nei pagamenti e nelle stablecoin. Un wallet pu\u00f2 ricevere e inviare valore in tempo reale a costo quasi nullo, con la possibilit\u00e0 di uscire su Lightning quando serve interoperabilit\u00e0, e gli emittenti possono coniare token e stablecoin direttamente sul protocollo. \u00c8 un posizionamento diverso da quello di Citrea: non la DeFi generalista, ma i trasferimenti di valore ad alta frequenza, un terreno dove Lightning ha aperto la strada e dove la concorrenza tra secondi livelli \u00e8 destinata a crescere.<\/p>

I Discreet Log Contracts: derivati e oracoli nativi<\/h2>

C’\u00e8 poi una categoria che non sposta fiducia su un ponte n\u00e9 su un rollup, ma resta tra due sole parti: i Discreet Log Contracts, o DLC, proposti da Tadge Dryja del MIT nel 2018. Un DLC \u00e8 un contratto condizionale tra due controparti che si regola in base a un dato del mondo reale (un prezzo, l’esito di un evento) senza rivelare on-chain i dettagli del contratto (Bitcoin Optech<\/a>).<\/p>

Il cuore crittografico \u00e8 l’adaptor signature, cio\u00e8 una firma Schnorr incompleta che pu\u00f2 essere completata solo quando viene rivelato un segreto specifico; in un DLC quel segreto deriva dall’attestazione di un oracolo sull’esito. La parte elegante \u00e8 che l’oracolo non sa nemmeno di essere usato: si limita a firmare pubblicamente un risultato, e quella firma sblocca la transazione giusta tra le due parti. Senza le firme Schnorr arrivate con Taproot, questa versione privata ed efficiente dei DLC non esisterebbe (Spark<\/a>).<\/p>

Le applicazioni sono derivati, opzioni e soprattutto mercati predittivi nativi su Bitcoin, un ambito in cui il confine tra previsione e scommessa \u00e8 sottile, come abbiamo visto raccontando i mercati predittivi in cui l’AI prevede come il mercato ma non guadagna<\/a>. A differenza di un rollup, i DLC non introducono un custode collettivo: sono perfetti per contratti bilaterali, meno adatti a una DeFi generalista con tanti partecipanti.<\/p>

I Layer 2 di Bitcoin a confronto<\/h2>

Non esiste un unico Layer 2 di Bitcoin, ma un ventaglio di soluzioni con compromessi diversi su tre assi: quanta fiducia richiedono, se permettono all’utente di uscire da solo e quanto si appoggiano alle primitive di Taproot. La tabella qui sotto riassume le principali famiglie (Spark Research<\/a>).<\/p>

Soluzione<\/th>Modello di fiducia<\/th>Uscita unilaterale<\/th>Uso di Taproot e Schnorr<\/th>Caso d’uso<\/th><\/tr><\/thead>
Lightning<\/td>Trustless (canali 2-di-2)<\/td>S\u00ec<\/td>PTLC con adaptor Schnorr in arrivo<\/td>Pagamenti<\/td><\/tr>
Liquid<\/td>Federazione 11-di-15<\/td>No<\/td>Limitato<\/td>Trading confidenziale<\/td><\/tr>
Ark<\/td>Operatore ASP, trust-minimized<\/td>S\u00ec, via timeout<\/td>S\u00ec (VTXO su Taproot)<\/td>Pagamenti e liquidit\u00e0<\/td><\/tr>
Spark<\/td>1-di-N (statechain)<\/td>S\u00ec, pre-firmata<\/td>S\u00ec (FROST su Schnorr)<\/td>Pagamenti, stablecoin, token<\/td><\/tr>
Citrea (rollup)<\/td>1-di-N (ponte BitVM)<\/td>Tramite prova crittografica<\/td>S\u00ec (BitVM su Tapscript)<\/td>Smart contract e DeFi<\/td><\/tr><\/tbody><\/table><\/figure>

La differenza di fondo sta nel tipo di scalabilit\u00e0. Lightning e Spark scalano i pagamenti, portando la velocit\u00e0 dalle circa sette transazioni al secondo del livello base a trasferimenti quasi istantanei e a costo irrisorio. I rollup come Citrea scalano invece la computazione, spostando fuori catena l’esecuzione di smart contract complessi e lasciando a Bitcoin il ruolo di ancora di sicurezza. I DLC, infine, non scalano nulla: aggiungono espressivit\u00e0 a singoli contratti. Sono approcci complementari, non alternativi.<\/p>

Come si sceglie, allora? La domanda giusta non \u00e8 quale Layer 2 vinca, ma quale compromesso serve. Per i pagamenti quotidiani contano velocit\u00e0 e costo, e qui Lightning e Spark sono avanti. Per smart contract e DeFi serve espressivit\u00e0, terreno dei rollup come Citrea. Per contratti bilaterali con un oracolo bastano i DLC. E in ogni caso la domanda chiave resta sempre la stessa: che cosa succede ai miei fondi se l’operatore sparisce? La risposta, cio\u00e8 la qualit\u00e0 dell’uscita unilaterale, conta pi\u00f9 di qualunque promessa di rendimento.<\/p>

Il nodo dei covenant: CTV, CAT e l’ultimo soft fork<\/h2>

BitVM dimostra che si pu\u00f2 fare molto senza nuovi opcode, ma a un prezzo: i ponti costruiti su BitVM sono complessi, costosi in termini di script e difficili da rendere eleganti. Un covenant, cio\u00e8 un vincolo su come una certa UTXO potr\u00e0 essere spesa in futuro, renderebbe ponti e vault molto pi\u00f9 semplici e sicuri. \u00c8 per questo che nel 2026 la discussione sui covenant \u00e8 tornata al centro del tavolo.<\/p>

Lo stato delle proposte, per\u00f2, resta incerto. OP_CTV (BIP-119, di Jeremy Rubin) \u00e8 la pi\u00f9 vicina al traguardo, con parametri di attivazione concreti per la prima volta, ma la segnalazione dei miner \u00e8 rimasta vicina allo zero. OP_CAT (BIP-347, di Ethan Heilman e Armin Sabouri) ha un numero di BIP ma nessuna road map di attivazione, mentre proposte come OP_CSFS e il pacchetto LNHANCE completano il quadro (BlockEden<\/a>).<\/p>

Proposta (BIP)<\/th>Autore<\/th>Stato a ottobre 2026<\/th>A cosa servirebbe<\/th><\/tr><\/thead>
OP_CTV (BIP-119)<\/td>Jeremy Rubin<\/td>Parametri di attivazione sul tavolo, segnalazione dei miner vicina a zero<\/td>Vault e controllo della congestione<\/td><\/tr>
OP_CAT (BIP-347)<\/td>Ethan Heilman, Armin Sabouri<\/td>Numero di BIP assegnato, nessuna road map<\/td>Covenant ricorsivi e script pi\u00f9 espressivi<\/td><\/tr>
OP_CSFS<\/td>In discussione<\/td>In valutazione<\/td>Verifica di firme su dati arbitrari<\/td><\/tr>
BitVM2<\/td>Robin Linus e altri<\/td>Gi\u00e0 in produzione (ponte di Citrea)<\/td>Ponti e computazione senza soft fork<\/td><\/tr><\/tbody><\/table><\/figure>

Il dibattito ha un peso che va oltre la tecnica. Adam Back, amministratore delegato di Blockstream, il primo ottobre 2026 ha definito gli opcode covenant un possibile \u00ablast soft fork\u00bb, cio\u00e8 un ultimo aggiornamento capace di ridurre la necessit\u00e0 di modifiche future e, unito alla verifica formale, di rendere lo scripting di Bitcoin pi\u00f9 sicuro (CryptoBriefing<\/a>). \u00c8 una posizione che riassume la tensione del momento: aggiungere poco, una volta sola, per non dover pi\u00f9 aggiungere nulla.<\/p>

Ossificazione contro evoluzione: la politica di Bitcoin<\/h2>

La vicenda dell’annex \u00e8 un microcosmo di una frattura pi\u00f9 profonda. Non \u00e8 un cambio di consenso, solo politica di propagazione, eppure divide. Da un lato c’\u00e8 chi teme che ogni aggiunta apra la porta a usi non monetari della catena, un timore gi\u00e0 visto nella guerra sul campo OP_RETURN e attorno al client Knots. Dall’altro c’\u00e8 chi vede nella programmabilit\u00e0 l’unica strada perch\u00e9 Bitcoin resti rilevante accanto a catene pi\u00f9 flessibili.<\/p>

Andrew Poelstra, ricercatore di Blockstream e tra gli autori delle proposte legate a Taproot, in un’intervista a Bitcoin Magazine del 2024 invitava a parlare apertamente con chi vuole congelare il protocollo, gli \u00abossificationists\u00bb, e sosteneva che gli sviluppatori devono \u00abargue passionately and correctly\u00bb, cio\u00e8 argomentare con passione e in modo corretto, a favore dei cambiamenti utili a Bitcoin (Bitcoin Magazine<\/a>). Due anni dopo, quella discussione \u00e8 ancora apertissima.<\/p>

Il paradosso \u00e8 evidente. Taproot \u00e8 stato l’ultimo soft fork riuscito, a novembre 2021, e da allora Bitcoin vive la fase di quiete pi\u00f9 lunga della sua storia sul fronte del consenso, un tema che abbiamo analizzato spiegando perch\u00e9 Taproot resta l’ultimo fork, tra BIP-54 e rischio quantistico<\/a>. Proprio perch\u00e9 cambiare il consenso \u00e8 cos\u00ec difficile, l’innovazione si \u00e8 spostata su ci\u00f2 che si pu\u00f2 fare senza fork: BitVM, rollup e statechain.<\/p>

Eppure anche Taproot potrebbe doversi evolvere. Il 13 ottobre 2026 un gruppo di ricercatori, tra cui Dan Boneh di Stanford e Scott Aaronson, ha pubblicato per conto di Coinbase un documento che chiede di avviare subito la migrazione post-quantistica di Bitcoin, proponendo architetture di output flessibili come P2MR (il BIP-360) o una ipotetica P2TRv2, insieme a costrutti ibridi 1-di-2 che tengano insieme una firma classica e una post-quantistica (The Block<\/a>). La minaccia, scrivono, non \u00e8 imminente ma \u00e8 ormai chiaramente all’orizzonte, e il NIST raccomanda di completare la transizione entro il 2035. L’idea stessa di una Taproot versione due dice molto: l’aggiornamento del 2021 non \u00e8 un punto d’arrivo.<\/p>

Cosa cambia per gli investitori italiani<\/h2>

Un punto va chiarito subito: nessun regolatore approva o blocca questi sviluppi. MiCA, applicata in Italia con Consob per la condotta di mercato e la tutela degli investitori e con Banca d’Italia per gli aspetti prudenziali e sulle stablecoin, regola i fornitori di servizi (CASP) e gli emittenti, non il protocollo Bitcoin, non i soft fork e non gli indirizzi bc1p. Un rollup come Citrea o un ponte come Clementine non ricevono un timbro da nessuna autorit\u00e0.<\/p>

Sul piano degli strumenti, invece, la distinzione conta. I derivati costruiti con i DLC, cos\u00ec come future e perpetui sulle piattaforme, restano strumenti finanziari sotto la MiFID II e la vigilanza di Consob, non sotto MiCA, che copre i soli crypto-asset spot e i relativi servizi. Chi tratta questi prodotti deve guardare al regime dei mercati finanziari, non a quello dei crypto-asset.<\/p>

C’\u00e8 poi il fisco, dove l’Italia resta un caso particolare in Europa. Un dettaglio tecnico ma importante riguarda i trasferimenti: spostare i propri bitcoin tra tipi di indirizzo che si controllano, per esempio da un indirizzo SegWit bc1q a uno Taproot bc1p, oppure verso un Layer 2 self-custodial, non \u00e8 una cessione e non realizza una plusvalenza. L’imposta scatta quando si vende o si converte, non quando si cambia il formato tecnico del proprio portafoglio, un tema che si lega al pi\u00f9 ampio dibattito su l’anomalia italiana dell’aliquota al 33%<\/a>.<\/p>

Sul fronte istituzionale la direzione \u00e8 chiara. Una custodia trust-minimized e stablecoin regolamentate ancorate a Bitcoin abbassano la barriera per banche e gestori che finora guardavano al settore con diffidenza. Non significa che un rollup diventi improvvisamente adatto a un cliente retail prudente: significa che l’infrastruttura su cui gli intermediari possono costruire prodotti \u00e8 pi\u00f9 solida di un anno fa, e che la distanza tra sperimentazione tecnica e offerta di mercato si sta accorciando.<\/p>

Resta infine il contesto di mercato. Al 14 ottobre 2026 Bitcoin vale circa 73.364 euro, in calo del 2,1% nelle ultime 24 ore e dell’1,6% in sette giorni (CoinGecko<\/a>). \u00c8 un prezzo che pesa sulle valutazioni dei progetti Layer 2, spesso legate alla loro token economy, ma che non cambia la sostanza tecnica: la programmabilit\u00e0 di Bitcoin cresce a prescindere dal ciclo di prezzo.<\/p>

Cosa aspettarsi ora<\/h2>

Nel breve periodo la partita si gioca su tre tavoli. Il primo \u00e8 l’annex: la pull request 36466 aprir\u00e0 un confronto sulla politica di propagazione di Bitcoin Core, con LibreRelay e rbitcoin gi\u00e0 a fare da apripista; l’esito dir\u00e0 quanto il client di riferimento sia disposto a lasciar spazio a usi nuovi dei dati.<\/p>

Il secondo tavolo \u00e8 quello dei covenant. Senza una segnalazione dei miner che oggi non si vede, OP_CTV rischia di restare al palo, e in quel caso BitVM continuer\u00e0 a essere la via maestra per costruire ponti senza aspettare un soft fork. Il terzo \u00e8 l’espansione dei rollup: Citrea ha aperto la strada, altri progetti seguiranno, e la variabile critica saranno proprio i ponti, perch\u00e9 un modello 1-di-N non \u00e8 fiducia zero e la liquidit\u00e0, insieme alla centralizzazione dei sequencer, resta un rischio concreto.<\/p>

Sopra tutto aleggia l’orologio quantistico, non imminente ma sempre pi\u00f9 citato, che spinge verso una Taproot evoluta. La morale, a cinque anni dall’attivazione, \u00e8 che l’eredit\u00e0 di Taproot non \u00e8 la privacy che prometteva nel 2021, ma lo spazio di progettazione che ha aperto. Bitcoin non \u00e8 diventato programmabile cambiando le sue regole, bens\u00ec sfruttando fino in fondo quelle che Taproot gli aveva gi\u00e0 dato.<\/p>

Domande frequenti<\/h2>

Che cos’\u00e8 l’annex di Taproot e perch\u00e9 se ne parla ora?<\/h3>

\u00c8 un campo opzionale nella struttura witness di un input Taproot, previsto dal 2021 per contenere dati aggiuntivi ma rimasto senza un uso chiaro. Nell’ottobre 2026 Robin Linus, l’autore di BitVM, ha aperto la pull request 36466 su Bitcoin Core per renderne standard la propagazione, in modo da poterlo usare nei protocolli a validazione client-side come Glass Coins.<\/p>

BitVM richiede un soft fork di Bitcoin?<\/h3>

No. BitVM e la sua versione BitVM2 funzionano con Bitcoin cos\u00ec com’\u00e8, sfruttando gli alberi di script MAST e Tapscript introdotti da Taproot. \u00c8 proprio per questo che i primi Layer 2 trust-minimized del 2026 sono stati costruiti su BitVM invece di attendere l’attivazione dei covenant.<\/p>

Che cos’\u00e8 Citrea e come usa Bitcoin?<\/h3>

Citrea \u00e8 il primo ZK-rollup in produzione che regola direttamente su Bitcoin, attivo in mainnet dal 27 gennaio 2026. Esegue transazioni EVM fuori dalla catena, genera prove a conoscenza zero e le pubblica su Bitcoin, che fa da livello di disponibilit\u00e0 dei dati e di regolamento; il suo ponte Clementine usa BitVM con un’assunzione di fiducia 1-di-N.<\/p>

Spostare i miei bitcoin su un indirizzo Taproot o su un Layer 2 \u00e8 un evento fiscale in Italia?<\/h3>

Trasferire i propri bitcoin tra indirizzi che si controllano, per esempio da un indirizzo SegWit a uno Taproot, o verso un Layer 2 self-custodial, non \u00e8 una cessione e non realizza una plusvalenza. L’imposta scatta quando si vende o si converte in euro o in un altro asset; per la propria posizione specifica conviene comunque verificare con un professionista.<\/p>

Qual \u00e8 la differenza tra un rollup come Citrea e una statechain come Spark?<\/h3>

Un rollup come Citrea esegue smart contract fuori dalla catena e ne pubblica le prove su Bitcoin, puntando alla DeFi generalista; una statechain come Spark trasferisce la propriet\u00e0 delle UTXO ruotando le chiavi tra utente, destinatario e operatori, ed \u00e8 pensata soprattutto per pagamenti, stablecoin e token. Entrambe si appoggiano a un’assunzione di fiducia 1-di-N, ma con architetture molto diverse.<\/p>