Autore: Chakra Compilatore: 0xjs@金财经

Questo articolo è la parte III di una serie di articoli sulla scalabilità di Bitcoin pubblicati da Chakra.

Per la prima parte si rimanda al precedente articolo di Golden Finance “Recensione del piano di espansione nativa di Bitcoin: SegWit e Taproot”,

Per la seconda parte si rimanda al precedente articolo di Golden Finance “Scalabilità Bitcoin: analisi di soluzioni Layer2 e progetti correlati”.

La terza parte è questo articolo, come segue:

Panoramica

Rispetto alle blockchain complete di Turing come Ethereum, gli script Bitcoin sono considerati estremamente restrittivi e possono eseguire solo operazioni di base e non supportano nemmeno la moltiplicazione e la divisione. Ancora più importante, i dati della blockchain stessa sono quasi inaccessibili agli script, con conseguente grave mancanza di flessibilità e programmabilità. Pertanto, ci sono stati sforzi per rendere introspettivi gli script Bitcoin.

L'introspezione si riferisce alla capacità degli script Bitcoin di ispezionare e limitare i dati delle transazioni. Ciò consente agli script di controllare l'utilizzo dei fondi in base a dettagli specifici della transazione, consentendo funzionalità più complesse. Attualmente, la maggior parte dei codici operativi Bitcoin inserisce i dati forniti dall'utente nello stack o manipola i dati esistenti nello stack. Tuttavia, il codice operativo di introspezione può inserire i dati della transazione corrente (come timestamp, importo, txid, ecc.) nello stack, consentendo un controllo più granulare sulla spesa UTXO.

Al momento, solo tre codici operativi principali supportano l'introspezione in Bitcoin Script: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY e CHECKSIG e le loro varianti CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG e CHECKMULTISIGVERIFY.

Il patto (tradotto anche come "restrizioni"), in poche parole, si riferisce alle restrizioni sui metodi di trasferimento di valuta, consentendo agli utenti di specificare il metodo di distribuzione di UTXO. Molti contratti vengono implementati tramite codici operativi di introspezione e la discussione sull'introspezione è stata ora relegata all'argomento Contratti Bitcoin Optech.

Bitcoin ha attualmente due contratti, CSV (CheckSequenceVerify) e CLTV (CheckLockTimeVerify). Entrambi i contratti sono contratti a tempo e sono la base di molte soluzioni di espansione (come Lightning Network). Ciò dimostra che la soluzione di ridimensionamento di Bitcoin si basa fortemente sull’introspezione e sui contratti.

Come aggiungiamo condizioni al trasferimento di token? Nel mondo delle criptovalute, il modo più comune in cui lo facciamo è attraverso le promesse, solitamente tramite hash. Per dimostrare che i requisiti di trasferimento sono soddisfatti, è necessario anche un meccanismo di firma per la verifica. Pertanto, ci sono molte modifiche agli hash e alle firme nel contratto.

Di seguito descriviamo la proposta del codice operativo Covenant ampiamente discussa.

CTV（CheckTemplateVerify）BIP-119

CTV (CheckTemplateVerify) è una proposta di aggiornamento Bitcoin in BIP-119, che ha attirato l'attenzione diffusa da parte della comunità. CTV consente agli script di output di specificare modelli per gli esborsi di fondi nelle transazioni, inclusi nVersion, nLockTime, hash scriptSig, conteggio input, hash sequenza, conteggio output, hash output, indice input e altri campi. Queste restrizioni sul modello vengono implementate tramite promesse di hash e, quando i fondi vengono spesi, lo script controlla se l'hash del campo specificato nella transazione di spesa corrisponde all'hash nello script di input. Ciò limita effettivamente il tempo, il metodo e la quantità di transazioni future per quell'UTXO.

Vale la pena notare che l'input TXID è escluso da questo hash. Questa esclusione è necessaria perché nelle transazioni tradizionali e SegWit, quando si utilizza il tipo di firma SIGHASH_ALL predefinito, il TXID dipende dal valore in scriptPubKey. L'inclusione del TXID provoca una dipendenza circolare nell'hash promise, rendendone impossibile la creazione.

Il metodo di introspezione di CTV consiste nell'estrarre direttamente le informazioni sulla transazione specificata, eseguirne l'hashing e quindi confrontarle con le promesse in pila. Questo metodo di introspezione ha requisiti inferiori in termini di spazio di catena, ma manca di una certa flessibilità.

La base delle soluzioni di secondo livello di Bitcoin, come Lightning Network, sono le transazioni prefirmate. La prefirma si riferisce in genere alla generazione e alla firma delle transazioni in anticipo, ma alla loro non trasmissione finché non vengono soddisfatte determinate condizioni. In sostanza, CTV implementa una forma più restrittiva di pre-firma, pubblicando impegni pre-firmati sulla catena e limitandoli a modelli predefiniti.

Il CTV è stato originariamente proposto per alleviare la congestione di Bitcoin, che può anche essere chiamata controllo della congestione. Quando la congestione è grave, CTV può impegnarsi in più transazioni future in un'unica transazione, evitando di trasmettere più transazioni durante le ore di punta e completando la transazione effettiva quando la congestione si attenua. Ciò può essere particolarmente utile durante una corsa di scambio. Inoltre, il modello può essere utilizzato per implementare Vault per proteggersi dagli attacchi degli hacker. Poiché il flusso di fondi è predeterminato, gli hacker non possono utilizzare gli script CTV per indirizzare gli UTXO ai propri indirizzi.

CTV può migliorare significativamente le reti Layer 2. Ad esempio, in Lightning Network, CTV può creare alberi di timeout e channel factory estendendo un singolo UTXO in un albero CTV, consentendo l'apertura di più canali statali con una sola transazione e una sola conferma. Inoltre, CTV supporta le transazioni atomiche nel protocollo Ark tramite ATLC.

APO（SIGHASH_ANYPREVOUT）BIP-118

BIP-118 introduce un nuovo flag hash della firma per tapscript progettato per facilitare una logica di spesa più flessibile, chiamato SIGHASH_ANYPREVOUT. APO e CTV hanno molte somiglianze. L'approccio di APO per risolvere il problema del loop tra scriptPubKeys e TXID consiste nell'escludere le informazioni di input rilevanti e firmare solo l'output, consentendo alle transazioni di essere associate dinamicamente a diversi UTXO.

Logicamente, l'operazione di verifica della firma OP_CHECKSIG (e le sue varianti) svolge tre funzioni:

1. Assemblare le varie parti della transazione di spesa.

2. Tagliateli.

3. Verificare che l'hash sia stato firmato dalla chiave specificata.

C’è molta flessibilità nei dettagli specifici della firma, con il flag SIGHASH che determina quali campi della transazione sono firmati. Secondo la definizione dei codici operativi della firma nel BIP 342, il flag SIGHASH è diviso in SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE e SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY controlla l'input, mentre altri controllano l'output.

SIGHASH_ALL è il flag SIGHASH predefinito, firma tutto l'output; SIGHASH_NONE non firma alcun output SIGHASH_SINGLE firma l'output specifico; SIGHASH_ANYONECANPAY può essere impostato insieme ai primi tre flag SIGHASH. Se SIGHASH_ANYONECANPAY è impostato, solo l'input specificato viene firmato; altrimenti, tutti gli input devono essere firmati.

Ovviamente, questi flag SIGHASH non annullano l'impatto dell'input, nemmeno SIGHASH_ANYONECANPAY, che richiede il commit su un input.

Pertanto, BIP 118 propone SIGHASH_ANYPREVOUT. Le firme APO non richiedono un input speso UTXO (chiamato PREVOUT) per essere impegnate, ma solo un output, fornendo una maggiore flessibilità per il controllo di Bitcoin. Precostruendo la transazione e creando la firma una tantum e la chiave pubblica corrispondenti, le risorse inviate a quell'indirizzo di chiave pubblica devono essere utilizzate attraverso la transazione precostruita, adempiendo così al contratto. La flessibilità dell'APO può essere utilizzata anche per riparare le transazioni; se una transazione è bloccata sulla catena perché la commissione è troppo bassa, è possibile creare facilmente un'altra transazione per aumentare la commissione senza richiedere una nuova firma. Inoltre, per i portafogli multi-firma, non fare affidamento sugli input spesi rende le operazioni più convenienti.

Poiché il ciclo tra scriptPubKeys e input TXID viene eliminato, APO può eseguire l'introspezione aggiungendo dati di output in Witness, sebbene ciò richieda comunque un ulteriore consumo di spazio Witness.

Per i protocolli fuori catena come Lightning Network e Vaults, APO riduce la necessità di salvare lo stato intermedio, riducendo notevolmente i requisiti di archiviazione e la complessità. Il caso d’uso più immediato per APO è Eltoo, che migliora le prestazioni di Lightning Network in molti modi semplificando le channel factory, costruendo torri di guardia leggere ed economiche e consentendo uscite unilaterali senza lasciare stati di errore. L'APO può anche essere utilizzato per emulare la funzionalità CTV, sebbene richieda alle persone di archiviare transazioni firmate e prefirmate, il che è più costoso e meno efficiente di CTV.

La critica principale rivolta all'APO è che richiede una nuova versione della chiave, cosa che non può essere ottenuta attraverso la semplice compatibilità con le versioni precedenti. Inoltre, i nuovi tipi di hash della firma possono introdurre potenziali rischi di doppia spesa. Dopo un'ampia discussione comunitaria, l'APO ha ottenuto il codice BIP-118 aggiungendo firme regolari al meccanismo di firma originale per alleviare i problemi di sicurezza.

OP_VAULT BIP-345

BIP-345 propone l'aggiunta di due nuovi codici operativi, OP_VAULT e OP_VAULT_RECOVER, che, se combinati con CTV, abilitano contratti specializzati che consentono agli utenti di forzare il differimento di una valuta specifica. Durante questo ritardo, le transazioni effettuate in precedenza possono essere "annullate" tramite il percorso di ripristino.

Gli utenti possono creare un Vault creando uno specifico indirizzo Taproot, che deve contenere almeno due script nel suo MAST: uno con l'opcode OP_VAULT per facilitare il processo di prelievo previsto, e un altro con l'opcode OP_VAULT_RECOVER per garantire che i token di ritiro possano essere ripristinati in qualsiasi momento prima del completamento del pagamento.

OP_VAULT Come implementare i prelievi bloccati a tempo interrompibili? OP_VAULT esegue questa operazione sostituendo lo script OP_VAULT utilizzato con lo script specificato, aggiornando di fatto una singola foglia del MAST lasciando invariati i rimanenti nodi foglia Taproot. Questa struttura è simile a TLUV, tranne per il fatto che OP_VAULT non supporta gli aggiornamenti alle chiavi interne.

I pagamenti possono essere limitati introducendo modelli durante gli aggiornamenti degli script. Il parametro del blocco temporale è specificato da OP_VAULT e il modello per il codice operativo CTV limita la serie di output che possono essere utilizzati tramite questo percorso di script.

BIP-345 è progettato specificamente per Vault, sfruttando OP_VAULT e OP_VAULT_RECOVER per fornire agli utenti un metodo di deposito a garanzia sicuro, utilizzando chiavi altamente sicure (come portafogli di carta o firme multiple distribuite) come percorsi di recupero configurando al contempo determinati ritardi per i pagamenti ricorrenti. Il dispositivo dell'utente monitora continuamente la spesa del deposito e, se si verifica un trasferimento imprevisto, l'utente può avviare un ripristino.

L'implementazione di Vault tramite BIP-345 comporta considerazioni sui costi, in particolare per il ripristino delle transazioni. Le possibili soluzioni includono CPFP (il figlio paga per il genitore), ancoraggi temporanei e il nuovo flag hash firmato SIGHASH_GROUP.

TLUV（TapleafUpdateVerify）

La soluzione TLUV è costruita attorno a Taproot e mira a risolvere efficacemente il problema dell'uscita UTXO condivisa. La linea guida è che quando l'output Taproot viene consumato, le chiavi interne e MAST (tapscript trie) possono essere parzialmente aggiornati attraverso trasformazioni crittografiche e la struttura interna dell'indirizzo Taproot, come descritto nello script TLUV. Ciò rende possibile l'implementazione della funzionalità Covenant.

Il concetto dello schema TLUV è quello di creare un nuovo indirizzo Taproot basato sull'attuale input di spesa introducendo il nuovo codice operativo TAPLEAF_UPDATE_VERIFY. Ciò può essere ottenuto effettuando una o più delle seguenti operazioni:

• Aggiorna la chiave pubblica interna

• Taglia i percorsi Merkle

• Elimina lo script attualmente in esecuzione

• Aggiungi un nuovo passaggio alla fine del percorso Merkle

Nello specifico, TLUV accetta tre input:

• Specifica come aggiornare la chiave pubblica interna.

• Un modo per specificare un nuovo passaggio per un percorso Merkle.

• Specifica se eliminare lo script corrente e/o quanti passi del percorso Merkle tagliare.

Il codice operativo TLUV calcola lo scriptPubKey aggiornato e verifica se l'output corrispondente all'input corrente viene speso su questo scriptPubKey.

TLUV si ispira al concetto di CoinPool. Oggi, i pool federati possono essere creati solo con transazioni prefirmate, ma se si vogliono ottenere uscite senza autorizzazione, sarà necessario creare un numero esponenzialmente maggiore di firme. TLUV, d'altra parte, consente l'uscita senza autorizzazione senza alcuna pre-firma. Ad esempio, un gruppo di partner può mettere insieme i propri fondi utilizzando Taproot per creare UTXO condivisi. Possono utilizzare le chiavi Taproot per spostare fondi internamente o co-firmare per avviare pagamenti esternamente. Gli individui possono ritirarsi dal pool di fondi condivisi in qualsiasi momento, rimuovendo il proprio percorso di pagamento, mentre gli altri possono comunque completare i pagamenti attraverso il percorso originale e il ritiro dell'individuo non espone altre informazioni sugli altri all'interno. Questo modello è più efficiente e privato rispetto alle transazioni non raggruppate.

Il codice operativo TLUV implementa restrizioni di spesa parziali aggiornando il Taproot Trie originale, ma non implementa l'introspezione degli importi di output. Pertanto è richiesto anche un nuovo codice operativo IN_OUT_AMOUNT. Questo codice operativo inserisce due elementi nello stack: l'importo UTXO di questo input e l'importo dell'output corrispondente, quindi la persona che utilizza TLUV deve utilizzare operatori matematici per verificare che i fondi siano correttamente conservati nello scriptPubKey aggiornato.

L'introspezione degli importi in uscita aggiunge complessità, poiché gli importi in satoshi richiedono fino a 51 bit per essere rappresentati, ma lo script consente solo operazioni matematiche a 32 bit. Ciò richiede la ridefinizione del comportamento del codice operativo per aggiornare l'operatore nello script o la sostituzione di IN_OUT_AMOUNT con SIGHASH_GROUP.

TLUV ha il potenziale per essere una soluzione per pool decentralizzati di livello 2, ma la sua affidabilità nell'adattare il Taproot Trie deve ancora essere confermata.

OPACO

MATT (Merkleize All The Things) mira a raggiungere tre obiettivi: Merkleizing the state, Merkleizing the script e Merkleizing the performance, realizzando così contratti intelligenti universali.

• Merkleizzazione dello stato: ciò comporta la costruzione di un Merkle Trie, in cui ogni nodo foglia rappresenta un hash dello stato e la Merkle Root incarna lo stato complessivo del contratto.

• Merkleizzazione dello script: si riferisce all'utilizzo di Tapscript per formare un MAST, in cui ciascun nodo foglia rappresenta un possibile percorso di transizione di stato.

• Merkleizzazione della performance: Merkleizzazione della performance attraverso impegno crittografico e meccanismi di sfida alle frodi. Per qualsiasi funzione computazionale, i partecipanti possono calcolarla fuori catena e quindi emettere un impegno f(x)=y. Se altri partecipanti scoprono il risultato errato f(x)=z, possono avviare una sfida. L'arbitrato viene eseguito tramite ricerca binaria, simile al principio dell'ottimistico rollup.

Implementazione della Merkel

Per implementare MATT, il linguaggio di scripting Bitcoin deve avere le seguenti funzionalità:

• Forza l'output ad avere script specifici (e il loro numero)

• Aggiunge un dato all'output

• Leggere i dati dall'ingresso corrente (o da un altro ingresso)

Il secondo punto è cruciale: dati dinamici significa che lo stato può essere calcolato dai dati di input forniti dal consumatore, in quanto ciò consente di simulare una macchina a stati, in grado di determinare lo stato successivo e dati aggiuntivi. Lo schema MATT raggiunge questo obiettivo tramite il codice operativo OP_CHECKCONTRACTVERIFY (OP_CCV), che è una fusione dei codici operativi OP_CHECKOUTPUTCONTRACTVERIFY e OP_CHECKINPUTCONTRATVERIFY precedentemente proposti, utilizzando un parametro flag aggiuntivo per specificare la destinazione dell'operazione.

Controllo della quantità di output: il metodo più semplice è eseguire l'introspezione diretta, tuttavia, la quantità di output è un numero a 64 bit e richiede un'aritmetica a 64 bit, il che introduce molta complessità negli script Bitcoin. OP_CCV utilizza un metodo di controllo ritardato come OP_VAULT, in cui gli importi di input di tutti gli input per lo stesso output in CCV vengono sommati come limite inferiore per l'importo di tale output. Il ritardo è dovuto al fatto che questo controllo avviene durante la transazione, non durante la valutazione dell'input da parte dello script.

Data l’ubiquità delle prove di frode, alcune varianti del contratto MATT dovrebbero essere in grado di implementare tutti i tipi di contratti intelligenti o costrutti di livello 2, sebbene ulteriori requisiti (come il blocco dei fondi e i ritardi nel periodo di sfida) debbano essere valutati accuratamente; necessario per valutare quali applicazioni il programma può accettare transazioni. Ad esempio, utilizza meccanismi di impegno crittografico e di sfida alle frodi per emulare la funzione OP_ZK_VERIFY per implementare rollup trustless su Bitcoin.

In pratica questo è già successo. Johan Torås Halseth ha implementato elftrace utilizzando il codice operativo OP_CHECKCONTRACTVERIFY nella proposta del soft fork MATT, che consente di verificare qualsiasi programma compilato con il supporto RISC-V sulla blockchain di Bitcoin, consentendo a una delle parti nell'accordo contrattuale di superare la verifica del contratto per accedere ai fondi, colmare la verifica nativa di Bitcoin.

CSFS（OP_CHECKSIGFROMSTACK）

Dall'introduzione del codice operativo APO, abbiamo appreso che OP_CHECKSIG (e le operazioni correlate) è responsabile dell'assemblaggio delle transazioni, dei calcoli dell'hash e della verifica delle firme. Tuttavia, i messaggi verificati da queste operazioni vengono serializzati tramite la transazione opcode e non consentono di specificare altri messaggi. In poche parole, il ruolo di OP_CHECKSIG (e le sue operazioni correlate) è quello di utilizzare il meccanismo di firma per verificare se l'UTXO speso come input della transazione è autorizzato a essere utilizzato dal titolare della firma, proteggendo così la sicurezza di Bitcoin.

CSFS, come suggerisce il nome, controlla la firma dallo stack. Il codice operativo CSFS riceve tre parametri dallo stack: firma, messaggio e chiave pubblica e verifica la validità della firma. Ciò significa che le persone possono passare qualsiasi messaggio allo stack tramite testimoni e verificarlo tramite CSFS, consentendo così alcune delle innovazioni di Bitcoin.

La flessibilità di CSFS gli consente di implementare meccanismi come firme di pagamento, delega, contratti oracolo, garanzie di protezione dalla doppia spesa e, soprattutto, introspezione delle transazioni. Il principio dell'introspezione delle transazioni utilizzando CSFS è molto semplice: se il contenuto della transazione utilizzato da OP_CHECKSIG viene inserito nello stack tramite il testimone e sia OP_CSFS che OP_CHECKSIG vengono verificati utilizzando la stessa chiave pubblica e firma e se entrambe le verifiche passano con successo, allora Il contenuto di qualsiasi messaggio a OP_CSFS è lo stesso della transazione di spesa serializzata (e altri dati) utilizzata implicitamente da OP_CHECKSIG. Otteniamo quindi dati di transazione verificati nello stack che possono essere utilizzati per porre limiti alle transazioni di spesa utilizzando altri codici operativi.

CSFS viene spesso visto insieme a OP_CAT perché OP_CAT può concatenare diversi campi di una transazione per completare la serializzazione, consentendo una selezione più precisa dei campi della transazione richiesti per l'introspezione. Senza OP_CAT, lo script non può ricalcolare gli hash dai dati che possono essere controllati individualmente, quindi tutto ciò che può realmente fare è verificare se l'hash corrisponde a un valore specifico, il che significa che il token può essere speso solo attraverso un'unica transazione specifica.

CSFS può implementare codici operativi come CLTV, CSV, CTV, APO, ecc., rendendolo un codice operativo di introspezione versatile. Pertanto, contribuisce anche alle soluzioni di scalabilità di livello 2 di Bitcoin. Lo svantaggio è che richiede l'aggiunta di una copia completa della transazione firmata sullo stack, il che può aumentare significativamente la dimensione delle transazioni utilizzando l'introspezione CSFS. I codici operativi di introspezione monouso come CLTV e CSV hanno poco sovraccarico in confronto, ma l'aggiunta di ogni nuovo codice operativo di introspezione speciale richiede modifiche consensuali.

TXHASH (OP_TXHASH)

OP_TXHASH è un semplice codice operativo di introspezione che consente all'operatore di selezionare un hash di un campo specifico e inserirlo nello stack. Nello specifico, OP_TXHASH estrae un flag txhash dallo stack, calcola un txhash (con tag) basato su quel flag e quindi reinserisce l'hash risultante nello stack.

A causa della somiglianza tra TXHASH e CTV, ci sono state molte discussioni sui due nella comunità.

TXHASH può essere visto come un aggiornamento generale di CTV, che fornisce modelli di transazione più avanzati e consente agli utenti di specificare esplicitamente varie parti della transazione di spesa, risolvendo molti problemi relativi alle commissioni di transazione. A differenza di altri opcode Covenant, TXHASH non richiede una copia dei dati necessari nel testimone, riducendo ulteriormente i requisiti di archiviazione, a differenza di CTV, TXHASH non è compatibile con NOP e può essere implementato solo in tapscript; come alternative CTV e APO.

Dal punto di vista della costruzione del contratto, TXHASH è più favorevole alla creazione di "contratti aggiuntivi" in cui tutte le parti dei dati della transazione che desideri correggere vengono inserite nello stack, sottoposte ad hashing e verificate che l'hash risultante corrisponda a un valore fisso Match;CTV è più adatto per creare "contratti sottrattivi" in cui tutte le parti dei dati della transazione che desideri mantenere libere vengono inserite nello stack. Quindi, utilizzando i codici operativi SHA256 in sequenza, l'elaborazione dell'hash inizia da uno stato intermedio fisso che è vincolato al prefisso dei dati hash della transazione. La parte libera viene sottoposta ad hashing in questo stato intermedio.

Si prevede che il campo TxFieldSelector definito nella specifica TXHASH verrà esteso ad altri codici operativi come OP_TX.

Il BIP relativo a TXHASH è attualmente in stato Draft su GitHub e non gli è stato ancora assegnato un numero.

OP_CAT

OP_CAT è un misterioso codice operativo che è stato inizialmente abbandonato da Satoshi Nakamoto per motivi di sicurezza, ma recentemente ha scatenato accese discussioni tra gli sviluppatori di Bitcoin Core e ha persino scatenato una cultura dei meme su Internet. Alla fine, OP_CAT è stato approvato con BIP-347 ed è stato citato come la proposta BIP che con maggiori probabilità verrà approvata nel prossimo futuro.

In effetti, il comportamento di OP_CAT è molto semplice: concatena due elementi dello stack. Come implementa la funzionalità Covenant?

Infatti, la capacità di connettere due elementi corrisponde ad una potente struttura dati crittografica: il Merkle Trie. Per creare un Merkle Trie, sono necessari solo la concatenazione e l'hashing e la funzione di hashing è fornita in Bitcoin Script. Pertanto, utilizzando OP_CAT, possiamo teoricamente verificare le prove Merkle nello script Bitcoin, che è uno dei metodi di verifica leggeri più comuni nella tecnologia blockchain.

Come accennato in precedenza, CSFS può implementare una soluzione generale del Patto con l'aiuto di OP_CAT. Infatti, lo stesso OP_CAT può abilitare l'introspezione delle transazioni anche senza CSFS, sfruttando la struttura delle firme Schnorr.

Nelle firme Schnorr, il messaggio che deve essere firmato è composto dai seguenti campi:

Questi campi contengono gli elementi principali della transazione. Inserendoli in uno scriptPubKey o Witness e utilizzando OP_CAT insieme a OP_SHA256, possiamo costruire una firma Schnorr e verificarla utilizzando OP_CHECKSIG. Se la verifica ha esito positivo, lo stack conserva i dati della transazione verificata, consentendo l'introspezione della transazione. Ciò ci consente di estrarre ed “esaminare” varie parti di una transazione, come i suoi input, output, indirizzo di destinazione o la quantità di Bitcoin coinvolta.

Per principi di crittografia specifici, è possibile fare riferimento all'articolo di Andrew Poelstra "CAT and Schnorr Tricks".

Tutto sommato, la versatilità di OP_CAT gli consente di simulare quasi tutti i codici operativi Covenant. Molti codici operativi Covenant si basano sulla funzionalità di OP_CAT, che ne migliora notevolmente la posizione nell'elenco delle unioni. In teoria, basandoci esclusivamente su OP_CAT e sui codici operativi Bitcoin esistenti, potremmo sperare di costruire un BTC ZK Rollup con fiducia ridotta al minimo. Starknet, Chakra e altri partner dell'ecosistema stanno promuovendo attivamente questo obiettivo.

Insomma

Mentre esploriamo varie strategie per scalare Bitcoin e migliorarne la programmabilità, è chiaro che il percorso da seguire prevede una miscela di miglioramenti nativi, elaborazione off-chain e sofisticate capacità di scripting.

Senza uno strato di base flessibile, è impossibile costruire un secondo strato più flessibile.

La scalabilità del calcolo fuori catena è il futuro, ma la programmabilità di Bitcoin ha bisogno di una svolta per supportare meglio questa scalabilità e diventare una valuta veramente globale.

Tuttavia, la natura del calcolo su Bitcoin è fondamentalmente diversa dalla natura del calcolo su Ethereum. Bitcoin supporta solo la "verifica" come forma di calcolo e non può eseguire calcoli generali, mentre Ethereum è di natura computazionale e la verifica è un sottoprodotto del calcolo. Questa differenza può essere vista in un punto: Ethereum addebita una commissione sul gas per le transazioni che non possono essere eseguite, mentre Bitcoin non ne addebita alcuna.

Un contratto è una forma di contratto intelligente basato sulla verifica anziché sul calcolo. Ad eccezione di una manciata di fondamentalisti Satoshi, tutti sembrano concordare sul fatto che i contratti siano una buona opzione per migliorare Bitcoin. Tuttavia, la comunità sta ancora discutendo ferocemente su quale metodo utilizzare per attuare il contratto.

APO, OP_VAULT e TLUV preferiscono l'applicazione diretta La scelta di questi tre metodi può realizzare applicazioni specifiche in modo più economico ed efficiente. Gli appassionati di Lightning Network sceglieranno APO per implementare LN-Symmetry; gli utenti che desiderano implementare Vault dovrebbero utilizzare OP_VAULT e per creare CoinPool, TLUV può fornire migliore privacy ed efficienza; OP_CAT e TXHASH sono più ricchi di funzionalità, hanno meno probabilità di presentare vulnerabilità di sicurezza e possono essere combinati con altri codici operativi per ottenere più casi d'uso, ma il costo potrebbe essere una maggiore complessità degli script. CTV e CSFS adattano il metodo di elaborazione della blockchain, CTV implementa l'output ritardato e CSFS implementa la firma ritardata. MATT si distingue per la sua esecuzione ottimistica e le strategie a prova di frode, sfruttando la struttura Merkle Trie per implementare contratti intelligenti di carattere generale, ma la funzione di introspezione richiede ancora nuovi codici operativi.

Vediamo che la comunità Bitcoin sta discutendo attivamente la possibilità di acquisire Covenants tramite un soft fork. Starknet ha annunciato ufficialmente che entrerà a far parte dell'ecosistema Bitcoin e prevede di implementare l'accordo sulla rete Bitcoin entro sei mesi dalla fusione OP_CAT. Chakra continuerà a prestare attenzione agli ultimi sviluppi nell'ecosistema Bitcoin, a promuovere la fusione del soft fork OP_CAT e a utilizzare la programmabilità portata da Covenants per costruire uno strato di regolamento Bitcoin più sicuro ed efficiente.