Scritto da: Nickqiao, Faust, Shew Wang, geek web3

Consulente: Gruppo di ricerca Bitlayer

Abstract: Recentemente, Delphi Digital ha pubblicato un rapporto di ricerca tecnica sul secondo strato di Bitcoin intitolato "The Dawn of Bitcoin Programmability: Paving the Way for Rollups", che ha sistematicamente risolto i concetti fondamentali relativi a Bitcoin Rollup, come BitVM Family Bucket, Restrizioni OP_CAT e Covenant, livello DA ecologico Bitcoin, bridge e i quattro principali secondi livelli Bitcoin che utilizzano BitVM, inclusi Bitlayer, Citrea, Yona e Bob.

Sebbene il rapporto di ricerca mostri generalmente il quadro generale della tecnologia di secondo livello di Bitcoin, in genere è relativamente generale e manca di una descrizione dettagliata, rendendolo difficile da comprendere. Geek web3 ha condotto scavi estesi e approfonditi basati sul rapporto di ricerca Delphi, cercando di consentire a più persone di comprendere sistematicamente BitVM e altre tecnologie.

Lanceremo congiuntamente una serie di rubriche chiamate "Approaching BTC" con il team di ricerca Bitlayer e la comunità cinese BitVM per condurre una divulgazione scientifica a lungo termine su argomenti chiave come BitVM, OP_CAT e i ponti a catena incrociata Bitcoin, e ci impegniamo a disincantare Bitcoin per più persone. Le tecnologie relative al Coin Layer 2 aiutano a spianare la strada a più appassionati.

Alcuni mesi fa, Robin Linus, capo di ZeroSync, ha pubblicato un articolo intitolato "BitVM: Compute Anything on Bitcoin", proponendo formalmente il concetto di BitVM e promuovendo il progresso della tecnologia di secondo livello di Bitcoin. Si può dire che questa è una delle innovazioni più rivoluzionarie nell'ecosistema Bitcoin, ha fatto esplodere l'intero ecosistema Bitcoin di secondo livello, ha attirato la partecipazione di progetti stellari come Bitlayer, Citrea, BOB, ecc., e ha portato vitalità. l'intero mercato.

Successivamente, altri ricercatori hanno partecipato al miglioramento di BitVM e successivamente hanno lanciato diverse versioni iterative come BitVM1, BitVM2, BitVMX e BitSNARK. La situazione generale è la seguente:

  1. Il white paper sull'implementazione di BitVM proposto per la prima volta da Robin Linus l'anno scorso è un'implementazione di BitVM basata su circuiti di porte logiche fittizie, chiamate BitVM0;

  2. In diversi discorsi e interviste successivi, Robin Linus ha introdotto in modo informale la soluzione BitVM (chiamata BitVM1) basata su una CPU fittizia, che è simile al sistema antifrode Cannon di Optimism. Può utilizzare script Bitcoin per simulare effetti CPU off-chain di uso generale .

  3. Robin Linus ha anche proposto BitVM2, un protocollo antifrode non interattivo in un unico passaggio e senza autorizzazione.

  4. I membri di Rootstock Labs e Fairgate Labs hanno pubblicato il white paper BitVMX che, simile a BitVM1, spera di emulare gli effetti di una CPU generica (off-chain) attraverso script Bitcoin.

Al momento, la costruzione dell'ecosistema di sviluppatori legato a BitVM sta diventando sempre più chiara e il miglioramento iterativo degli strumenti periferici è visibile anche ad occhio nudo. Rispetto allo scorso anno, l'ecosistema BitVM di oggi è diventato "vagamente visibile" dal "castello" iniziale in the air", che ha attirato sempre più persone. Sempre più sviluppatori e VC si stanno precipitando nell'ecosistema Bitcoin.

Ma per la maggior parte delle persone, non è facile comprendere i termini tecnici relativi a BitVM e Bitcoin Layer 2, perché è necessario avere una comprensione sistematica delle conoscenze di base che lo circondano, in particolare argomenti come gli script Bitcoin e la conoscenza Taproot. I materiali di riferimento attualmente disponibili su Internet sono troppo lunghi e pieni di sciocchezze, oppure le spiegazioni non sono sufficientemente approfondite, facendo sembrare che le persone capiscano ma non capiscano. Ci impegniamo a risolvere i problemi di cui sopra e ci sforziamo di utilizzare il linguaggio più chiaro possibile per aiutare più persone a comprendere la conoscenza circostante del secondo livello di Bitcoin e stabilire una comprensione sistematica del sistema BitVM.

MATT e impegno: l'idea di base di​​BitVM

Innanzitutto, vogliamo sottolineare che l'idea di base di BitVM è MATT, che significa Merkleize All The Things. Si riferisce principalmente all'utilizzo di una struttura di archiviazione dei dati ad albero come Merkle Tree per visualizzare il complesso processo di esecuzione del programma e prova a rendere la verifica di Bitcoin Native a prova di frode.

Sebbene MATT possa esprimere un programma complesso e le sue tracce di elaborazione dati, non pubblicherà direttamente questi dati sulla catena BTC perché la dimensione complessiva di questi dati è molto grande. La soluzione che utilizza MATT memorizza solo i dati nell'albero Merkle fuori catena e pubblica solo il riepilogo principale (Merkle Root) dell'albero Merkle nella catena. Questo albero Merkle contiene principalmente tre contenuti principali:

  • Codice script contratto intelligente

  • Dati richiesti dal contratto

  • Tracce lasciate durante l'esecuzione del contratto (record delle modifiche alla memoria e ai registri della CPU quando i contratti intelligenti vengono eseguiti in macchine virtuali come EVM)

(Un semplice diagramma Merkle Tree. La radice Merkle viene calcolata dagli 8 frammenti di dati nella parte inferiore della figura tramite hashing multistrato)

Secondo lo schema MATT, solo la piccolissima Merkle Root viene archiviata sulla catena e il set di dati completo contenuto nel Merkle Tree viene archiviato fuori catena. Questo utilizza un'idea chiamata "impegno". Ecco una spiegazione di cosa sia “Impegno”.

Una promessa è simile ad un'affermazione concisa, che possiamo intendere come un'"impronta digitale" ottenuta comprimendo una grande quantità di dati. In generale, la persona che emette un "impegno" sulla catena affermerà che alcuni dati archiviati fuori catena sono accurati. Questi dati fuori catena dovrebbero corrispondere a una dichiarazione concisa e questa dichiarazione è l'"impegno".

Ad un certo punto, l'hash dei dati può essere utilizzato come un "impegno" nei confronti dei dati stessi. Altri schemi di impegno includono l'impegno KZG o Merkle Tree. Nel consueto protocollo antifrode di Layer2, l'editore dei dati pubblica il set di dati completo off-chain e si impegna a pubblicare il set di dati on-chain. Se qualcuno scopre dati non validi nel set di dati off-chain, l'impegno dei dati on-chain verrà messo in discussione.

Attraverso il Commitment, il secondo livello può comprimere ed elaborare grandi quantità di dati e pubblicare solo il proprio “commitment” sulla catena Bitcoin. Naturalmente è anche necessario garantire che l’intero set di dati rilasciati off-chain possa essere osservato dal mondo esterno.

Allo stato attuale, diverse importanti soluzioni BitVM, come BitVM0, BitVM1, BitVM2 e BitVMX, adottano fondamentalmente strutture astratte simili:

1. Scomposizione e impegno del programma: innanzitutto scomporre il programma complesso in un gran numero di codici operativi di base (compilazione), quindi registrare le tracce generate da questi codici operativi durante l'esecuzione specifica (per dirla senza mezzi termini, un programma viene eseguito sulla CPU e Quando in memoria, vengono registrati tutti i cambiamenti di stato, chiamati Trace). Successivamente, organizziamo tutti i dati, incluse tracce e codici operativi, in un set di dati e quindi generiamo un impegno per quel set di dati.

Schemi di impegno specifici possono assumere molte forme, ad esempio: alberi Merkle, PIOP (vari algoritmi ZK), funzioni hash

2. Impegno delle risorse e pre-firma: gli editori e i verificatori di dati devono bloccare una certa quantità di risorse sulla catena tramite la pre-firma e ci saranno restrizioni. Queste condizioni verranno attivate specificamente per le situazioni che potrebbero verificarsi in futuro. Se l’editore dei dati fa del male, il verificatore può inviare un certificato per sottrarre le risorse dell’editore dei dati.

3. Pubblicazione di dati e impegni: l'editore dei dati pubblica l'impegno sulla catena, il set di dati completo viene pubblicato fuori dalla catena e il verificatore recupera il set di dati e controlla se ci sono errori. Ogni parte del set di dati off-chain ha una correlazione con un impegno on-chain.

4. Sfide e sanzioni: una volta che il verificatore scopre che c'è un errore nei dati forniti dall'editore dei dati, porterà questa parte dei dati nella catena per la verifica diretta (questa parte dei dati deve prima essere tagliata molto finemente ). Questa è la logica della prova della frode. Se i risultati della verifica mostrano che l'editore dei dati ha effettivamente fornito dati non validi fuori catena, le sue risorse verranno portate via dal validatore che lo contesta.

Per riassumere, l’editore dei dati Alice divulga tutte le tracce generate durante l’esecuzione della transazione di secondo livello fuori catena e pubblica i corrispondenti impegni verso la catena. Se vuoi dimostrare che una certa parte dei dati è sbagliata, prova prima al nodo Bitcoin che questa parte dei dati è legata all'impegno sulla catena, cioè prova che i dati sono divulgati dalla stessa Alice, e quindi lascia che il nodo Bitcoin confermi che questa parte dei dati è sbagliata.

Ora comprendiamo a grandi linee l'idea generale di BitVM e tutte le varianti di BitVM sono sostanzialmente inseparabili dal paradigma di cui sopra. Quindi, iniziamo ora ad apprendere e comprendere alcune delle importanti tecnologie utilizzate nel processo di cui sopra, a partire dagli script Bitcoin più basilari, Taproot e pre-firma.

Cos'è BitcoinScript?

La conoscenza relativa a Bitcoin è più difficile da comprendere rispetto a Ethereum. Anche il comportamento di trasferimento più elementare coinvolge una serie di concetti, tra cui UTXO (output della transazione non spesa), script di blocco (noto anche come ScriptPubKey) e script di sblocco (noto anche come ScriptSig). Spieghiamo innanzitutto questi concetti principali.

(Un esempio di codice script Bitcoin costituito da codici operativi di livello inferiore rispetto a un linguaggio di alto livello)

Il modo in cui le risorse sono espresse in Ethereum è più simile ad Alipay o WeChat. Ogni trasferimento semplicemente aggiunge e sottrae i saldi di diversi conti. Questo metodo è incentrato sull'account e il saldo delle risorse è solo un numero sotto il nome del conto L'espressione è più simile all'oro. Ogni pezzo d'oro (UTXO) verrà contrassegnato con il suo proprietario. Il trasferimento distrugge effettivamente il vecchio UTXO e genera un nuovo UTXO (il proprietario cambierà).

Bitcoin UTXO contiene due campi chiave:

  • Importo, in "satoshi" (cento milioni di satoshi equivalgono a un BTC);

  • Lo script di blocco, noto anche come "ScriptPubKey", definisce le condizioni di sblocco di UTXO.

Va notato che la proprietà di Bitcoin UTXO è espressa tramite uno script di blocco. Se desideri trasferire il tuo UTXO a Sam, puoi avviare una transazione per distruggere uno dei tuoi UTXO e scrivere le condizioni di sblocco dell'UTXO appena generato come ". Solo Sam può sbloccarlo."

Successivamente, se Sam vuole utilizzare questi Bitcoin, deve inviare uno script di sblocco (ScriptSig). In questo script di sblocco, Sam deve presentare la sua firma digitale per dimostrare di essere lui stesso. Se lo script di sblocco corrisponde allo script di blocco sopra menzionato, Sam può sbloccare e trasferire i bitcoin ad altri.

(Lo script di sblocco deve corrispondere allo script di blocco)

Dal punto di vista dell'espressione, ogni transazione sulla catena Bitcoin corrisponde a più input e output. Ciascun input deve dichiarare un determinato UTXO che desidera sbloccare e inviare uno script di sblocco per sbloccare e distruggere l'output UTXO verrà visualizzato e il contenuto dello script di blocco verrà divulgato al mondo esterno.

Ad esempio, nell'input di una transazione, dimostri di essere Sam, sblocchi più UTXO che ti sono stati forniti da altri, li distruggi in modo uniforme, generi più nuovi UTXO e dichiari che xxx verrà sbloccato in futuro.

Nello specifico, nei dati di input della transazione, devi dichiarare quali UTXO vuoi sbloccare e indicare il “percorso di archiviazione” di questi dati UTXO. Va notato qui che Bitcoin ed Ethereum sono completamente diversi. Ethereum fornisce due conti, conti contrattuali e conti EOA, per archiviare i dati. Il saldo patrimoniale viene registrato come un numero sotto il nome del conto contrattuale o del conto EOA e viene inserito in modo unificato Nel database dello "Stato mondiale", durante il trasferimento di denaro, conti specifici possono essere modificati direttamente dallo "Stato mondiale" per facilitare l'individuazione del luogo di archiviazione dei dati;

Bitcoin non ha una struttura di stato mondiale e i dati sugli asset sono sparsi e archiviati in blocchi passati (ovvero, i dati UTXO sbloccati vengono archiviati separatamente nell'OutPut di ciascuna transazione).

Se vuoi sbloccare un UTXO, devi indicare quale output della transazione le informazioni UTXO esistono in passato, mostrare l'ID della transazione (che è il suo hash) e lasciare che il nodo Bitcoin lo cerchi nei record della cronologia. Se vuoi interrogare il saldo Bitcoin di un determinato indirizzo, devi attraversare tutti i blocchi dall'inizio e trovare l'UTXO sbloccato associato all'indirizzo xx.

Quando di solito utilizzi un portafoglio Bitcoin, puoi controllare rapidamente il saldo Bitcoin posseduto da un determinato indirizzo. Ciò è spesso dovuto al fatto che il servizio portafoglio stesso indicizza tutti gli indirizzi scansionando i blocchi, rendendoci più semplice interrogarli rapidamente.

(Quando generi un estratto conto della transazione per fornire il tuo UTXO ad altri, devi contrassegnare la posizione dell'UTXO nella cronologia Bitcoin in base all'hash/ID della transazione a cui appartengono questi UTXO)

È interessante notare che i risultati delle transazioni Bitcoin vengono calcolati fuori catena. Quando gli utenti generano transazioni sui propri dispositivi locali, devono creare direttamente sia l'input che l'output, il che equivale a calcolare i risultati di output della transazione. Le transazioni vengono trasmesse alla rete Bitcoin e verificate dai nodi prima di essere inserite nella catena. Questo modello di "calcolo fuori catena-verifica sulla catena" è completamente diverso da Ethereum, su Ethereum devi solo fornire i parametri di input della transazione e i risultati della transazione vengono calcolati e restituiti dal nodo Ethereum.

Inoltre, lo script di blocco UTXO (Locking Script) può essere personalizzato. È possibile impostare l'UTXO in modo che sia "sbloccabile dal proprietario di un determinato indirizzo Bitcoin". ). Nel tipo di transazione Pay-to-Script-Hash (P2SH), puoi aggiungere uno Script Hash nello script di blocco UTXO Chi può inviare l'immagine originale dello script corrispondente a questo Hash e soddisfare le condizioni preimpostate nell'immagine originale dello script? puoi sbloccare UTXO. Lo script Taproot su cui si basa BitVM utilizza funzionalità simili a P2SH.

Come attivare lo script Bitcoin

Qui utilizziamo innanzitutto P2PKH come esempio per introdurre il metodo di attivazione dello script Bitcoin. Solo comprendendone il metodo di attivazione possiamo comprendere i più complessi Taproot e BitVM. Il nome completo di P2PKH è "Pay to Public Key Hash". In questo schema, verrà impostato un hash di chiave pubblica nello script di blocco UTXO e la chiave pubblica corrispondente all'hash dovrà essere inviata durante lo sblocco stesso dell’idea convenzionale di trasferimento Bitcoin.

In questo momento, il nodo Bitcoin deve confermare che la chiave pubblica nello script di sblocco corrisponde all'hash della chiave pubblica specificato nello script di blocco. In altre parole, deve confermare che la "chiave" inviata dallo sbloccatore e il "blocco" siano preimpostati di UTXO corrispondono tra loro.

Inoltre, secondo lo schema P2PKH, dopo aver ricevuto la transazione, il nodo Bitcoin unirà lo script di sblocco ScriptSig fornito dall'utente con lo script di blocco ScriptPubkey dell'UTXO da sbloccare e li eseguirà nell'ambiente di esecuzione dello script BTC. La figura seguente mostra i risultati della giunzione prima dell'esecuzione:

Forse i lettori non conoscono l’ambiente di esecuzione degli script di BTC, quindi qui lo presenteremo brevemente. Innanzitutto, lo script BTC contiene due elementi:

dati e codici operativi. Questi dati e codici operativi verranno inseriti nello stack in ordine da sinistra a destra ed eseguiti secondo la logica specificata per ottenere il risultato finale (i dettagli di cosa sia uno stack non verranno elaborati qui, i lettori possono chattare da soli).

Prendendo come esempio l'immagine sopra, il lato sinistro è lo script di sblocco ScriptSig caricato da qualcuno, inclusa la sua firma digitale e la chiave pubblica, mentre lo script di blocco ScriptPubkey sul lato destro contiene un codice operativo e un set di dati dal creatore di UTXO durante la generazione del UTXO (Non è necessario comprendere il significato di ciascun codice operativo qui, solo una comprensione approssimativa).

DUP, HASH160, EQUALVERIFY e altri codici operativi nello script di blocco a destra nella figura sopra sono responsabili dell'hashing della chiave pubblica trasportata nello script di sblocco a sinistra e del confronto con l'hash della chiave pubblica preimpostato nello script di blocco. Se i due sono uguali, significa che la chiave pubblica caricata nello script di sblocco corrisponde all'hash della chiave pubblica preimpostato nello script di blocco e la prima verifica è superata.

Tuttavia, c'è un problema. Il contenuto dello script di blocco UTXO è effettivamente pubblico sulla catena Chiunque può osservare l'hash della chiave pubblica in esso contenuto Chiunque può caricare la chiave pubblica corrispondente e affermare falsamente di essere lui. nominato dall'imperatore". " persona. Pertanto, dopo aver verificato la chiave pubblica e l'hash della chiave pubblica, è necessario verificare anche se l'iniziatore della transazione è effettivamente l'effettivo titolare della chiave pubblica, cosa che richiede la verifica della firma digitale. Il codice operativo CHECKSIG nello script di blocco è responsabile della verifica della firma digitale.

Per riassumere, secondo lo schema P2PKH, lo script di sblocco inviato dall'iniziatore della transazione contiene la chiave pubblica e la firma digitale. La chiave pubblica deve corrispondere all'hash della chiave pubblica specificato nello script di blocco e solo la firma digitale della transazione quando queste condizioni sono soddisfatte, l'UTXO può essere sbloccato senza problemi.

(Questa immagine è dinamica: diagramma schematico dello script di sblocco Bitcoin secondo lo schema P2PKH

Fonte: https://learnmeabitcoin.com/technical/script)

Naturalmente, la rete Bitcoin supporta più tipi di transazioni, non solo Pay to public key/public key hash, ma anche P2SH (Pay to Script hash), ecc. Tutto dipende da come viene impostato lo script di blocco personalizzato quando viene creato l'UTXO. .

Va notato qui che secondo lo schema P2SH, uno Script Hash può essere preimpostato nello script di blocco e lo script di sblocco deve inviare il contenuto completo dello script corrispondente allo Script Hash. I nodi Bitcoin possono eseguire questo script Se la logica della verifica multi-firma è definita in questo script, l'effetto di un portafoglio multi-firma può essere ottenuto sulla catena Bitcoin.

Naturalmente, secondo lo schema P2SH, il creatore dell'UTXO deve consentire alla persona che sbloccherà l'UTXO in futuro di conoscere in anticipo il contenuto dello script corrispondente allo Script Hash. Finché entrambe le parti conoscono il contenuto di questo script, allora possiamo implementarlo logica aziendale più complessa rispetto alla firma multipla.

Va notato qui che la catena (blocco) Bitcoin non registra direttamente quali UTXO sono associati a quali indirizzi Registra solo quale hash di chiave pubblica/quale hash di script può essere sbloccato dall'UTXO, ma utilizziamo l'hash/script di chiave pubblica. per sbloccarlo, Hash può calcolare rapidamente l'indirizzo corrispondente (la sezione visualizzata sull'interfaccia del portafoglio appare con caratteri confusi).

Il motivo per cui possiamo vedere una quantità xx di Bitcoin sotto l'indirizzo xx nell'interfaccia di Block Explorer e Wallet è perché Block Explorer e il progetto Wallet ti aiutano ad analizzare i dati, scansionare tutti i blocchi e bloccare lo script in base all'hash della chiave pubblica/hash dello script dichiarato in, calcola l'"indirizzo" corrispondente e quindi visualizza quanti Bitcoin ci sono sotto il nome dell'indirizzo xx.

Testimone e Testimone Segregato

Dopo aver compreso l'idea di P2SH, siamo un passo avanti verso Taproot, da cui dipende BitVM. Ma prima dobbiamo comprendere un concetto importante: Testimone e Testimone Segregato.

Esaminando lo script di sblocco e lo script di blocco menzionati in precedenza, nonché il processo di sblocco UTXO, troverai un problema: la firma digitale della transazione è inclusa nello script di sblocco e lo script di sblocco non può essere sovrascritto durante la generazione della firma (il i parametri utilizzati per generare la firma non possono essere inclusi nella firma stessa), quindi la firma digitale può coprire solo parti diverse dallo script di sblocco, ovvero può essere associata solo alla parte principale dei dati della transazione e non può coprire completamente la transazione dati.

In questo modo, anche se lo script di sblocco della transazione viene leggermente manipolato dall'intermediario, ciò non influirà sul risultato della verifica della firma. Ad esempio, i nodi Bitcoin o i pool minerari possono inserire altri dati nello script di sblocco della transazione, causando lievi modifiche nei dati della transazione senza influenzare la verifica della firma e i risultati della transazione. Anche l'hash/ID della transazione calcolato finale cambierà. Questo è noto come problema della malleabilità delle transazioni.

Lo svantaggio di ciò è che se si prevede di avviare più transazioni in successione e sono presenti dipendenze sequenziali (ad esempio, la transazione 3 si riferisce all'output della transazione 2 e la transazione 2 si riferisce all'output della transazione 1), allora il successivo transazioni È necessario citare l'ID (hash) della transazione precedente Qualsiasi intermediario come un pool minerario o un nodo Bitcoin può mettere a punto il contenuto dello script di sblocco in modo che l'hash dopo il caricamento della transazione non sia coerente con ciò che è stato caricato. ti aspettavi. Quindi le transazioni multiple che hai creato in anticipo avranno transazioni correlate in sequenza diventeranno non valide.

Infatti, nelle soluzioni DLC bridge e BitVM2, le transazioni con correlazione sequenziale verranno costruite in batch, quindi lo scenario sopra menzionato non è raro.

In poche parole, il problema della scalabilità della transazione è perché l'ID/hash della transazione includerà i dati dello script di sblocco durante il calcolo e gli intermediari come i nodi Bitcoin possono ottimizzare il contenuto dello script di sblocco, facendo sì che l'ID della transazione sia diverso da quello che l'utente si aspettava incompatibile. In realtà, questo è il bagaglio storico lasciato dalla scarsa considerazione di Bitcoin nella sua progettazione iniziale.

Il successivo aggiornamento Segregated Witness/SegWit disaccoppia completamente l'ID della transazione e lo script di sblocco. Non è necessario includere i dati dello script di sblocco durante il calcolo dell'hash della transazione. Lo script di blocco UTXO che segue l'aggiornamento di SegWit imposterà in primo luogo un codice operativo chiamato "OP_0" per impostazione predefinita, che funge da contrassegno e lo script di sblocco corrispondente è stato rinominato da SigScript a Witness;

Dopo aver seguito le regole SegWit, il problema della scalabilità delle transazioni verrà risolto correttamente e non dovrai preoccuparti della messa a punto dei dati delle transazioni inviati al nodo Bitcoin. Naturalmente non è necessario pensare in modo troppo complicato. Le funzioni di P2WSH non sono sostanzialmente diverse da quelle di P2SH menzionate in precedenza. È possibile preimpostare un hash dello script nello script di blocco UTXO e attendere che il mittente dello script di sblocco invii il file contenuto dello script corrispondente all'hash sulla catena ed eseguito.

Ma se il contenuto dello script che vuoi implementare è particolarmente grande e contiene molto codice, lo script completo non può essere inviato alla catena Bitcoin attraverso i metodi convenzionali (ogni blocco ha un limite di dimensione). Cosa fare? Ciò richiede l'uso di Taproot per semplificare il contenuto dello script sulla catena e BitVM è una soluzione complessa basata su Taproot.

Nel prossimo articolo di "Approccio a BTC", condurremo una divulgazione dettagliata di Taproot, pre-firma e altre tecnologie più complesse relative a BitVM, quindi rimanete sintonizzati!