Scritto da: Chakra Research

Panoramica

Rispetto alle blockchain complete di Turing come Ethereum, gli script su Bitcoin sono considerati molto limitati 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 impossibili da leggere tramite script, con conseguente grave mancanza di flessibilità e bassa programmabilità. Pertanto, le persone hanno cercato a lungo di trovare modi per rendere introspettivi gli script Bitcoin.

L'introspezione si riferisce alla capacità di consentire agli script Bitcoin di ispezionare e limitare i dati delle transazioni. Ciò consente agli script di controllare l'utilizzo dei fondi in base ai dettagli specifici di una transazione, consentendo funzionalità più complesse. La maggior parte degli attuali codici operativi Bitcoin (Opcode) hanno solo due funzioni: inserire i dati forniti dall'utente nello stack o operare sui dati esistenti nello stack. Il codice operativo di introspezione può inserire i dati della transazione corrente (come timestamp, importo, ID transazione, ecc.) nello stack per fornire un controllo più preciso su come viene speso UTXO.

Attualmente, solo tre codici operativi principali in Bitcoin Script supportano l'introspezione: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY e CHECKSIG ha anche varianti come CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG e CHECKMULTISIGVERIFY;

In poche parole, un contratto è una restrizione su come possono essere trasferiti i token. Gli utenti possono specificare il metodo di distribuzione di UTXO attraverso il contratto. Molti contratti vengono implementati tramite codici operativi di introspezione e l'introspezione è stata ora discussa nelle voci dei contratti in Bitcoin Optech.

Bitcoin ha attualmente due contratti, CSV (CheckSequenceVerify) e CLTV (CheckLockTimeVerify), entrambi contratti a tempo, che sono la base per molti piani di espansione, come il Lightning Network. Da ciò possiamo anche vedere che il piano di espansione di Bitcoin fa molto affidamento sull’introspezione e sui contratti.

Come aggiungere restrizioni al trasferimento di token? Nel mondo della crittografia, il metodo più comunemente utilizzato è l’impegno, che spesso viene implementato tramite l’hash. Per dimostrare che soddisfiamo i requisiti di trasferimento, dobbiamo verificarli attraverso un meccanismo di firma. Pertanto, ci sono molte modifiche agli hash e alle firme nel contratto.

Di seguito descriviamo la proposta di codice operativo contrattuale ampiamente discussa.

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify) è un aggiornamento Bitcoin molto discusso dalla comunità e incluso in BIP-119. CTV consente allo script di output di specificare il modello per l'utilizzo dei fondi nella transazione di spesa, inclusi nVersion, nLockTime, hash scriptSig, conteggio input, hash sequenze, conteggio output, hash output, indice input e altri campi della transazione le restrizioni vengono passate attraverso un hash Per raggiungere questo obiettivo, il futuro script di spesa controllerà che il valore hash del campo specificato nella transazione di spesa corrisponda al valore hash nello script di input. Questi modelli limitano effettivamente il tempo, il metodo, l'importo e altri dettagli della transazione di spesa futura di UTXO.

Vale la pena notare che l'input TXID è escluso dall'hash promise. Questa esclusione è necessaria, sia nelle transazioni Legacy che Segwit, nel tipo di firma SIGHASH_ALL predefinito, il TXID deve essere generato in base al valore di scriptPubKey. Pertanto, includere il TXID causerà un loop nella promessa dell'hash, che non potrà essere creato con successo.

Il modo in cui CTV implementa l'introspezione è ottenere direttamente le informazioni specificate della transazione attraverso un nuovo codice operativo, sottoporlo ad hash e confrontarlo con l'impegno nello stack. Questo metodo di introspezione consuma meno spazio sulla 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 di solito si riferisce alla generazione e alla firma delle transazioni in anticipo ma alla loro non trasmissione alla rete finché non vengono soddisfatte determinate condizioni. In sostanza, CTV implementa una funzione di pre-firma più rigorosa, pubblicando l’impegno pre-firmato direttamente sulla catena, e le transazioni possono essere condotte solo secondo il pre-template.

CTV è stato originariamente proposto per alleviare la congestione di Bitcoin, che può anche essere chiamata controllo della congestione. Quando Bitcoin è relativamente congestionato, CTV può essere utilizzato per impegnare più transazioni future attraverso una singola transazione senza dover trasmettere più transazioni durante la congestione, e quindi completare la transazione effettiva dopo che la congestione dei blocchi si è attenuata. Il controllo della congestione può essere di grande aiuto quando uno scambio subisce una corsa. Inoltre, i modelli possono essere utilizzati anche per implementare depositi per prevenire attacchi di hacker. Poiché la destinazione dei fondi è determinata, l'hacker non può inviare l'UTXO utilizzando lo script CTV al proprio indirizzo.

CTV può apportare enormi miglioramenti alle reti di livello 2. Ad esempio, per l'implementazione di Timeout Trees e channel factory nella Lightning Network, tramite CTV, un singolo UTXO può essere espanso in un albero CTV e più canali di stato vengono aperti contemporaneamente, mentre c'è solo una transazione e una conferma sulla catena. Inoltre, CTV fornisce anche il supporto per le transazioni atomiche ATLC nel protocollo Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 propone un nuovo tipo di flag hash firmato per tapscript per facilitare la scrittura di una logica di spesa più flessibile, chiamata SIGHASH_ANYPREVOUT. APO e CTV sono simili sotto molti aspetti. Di fronte al problema del loop tra scriptPubKeys e TXID, la soluzione di APO è quella di escludere le informazioni relative all'input e firmare solo l'output, in modo che le transazioni possano essere associate dinamicamente a diversi UTXO.

Divisa logicamente, l'operazione di verifica della firma OP_CHECKSIG (e i suoi codici operativi simili) ha tre funzioni:

1. Assemblare le varie parti di una transazione di spesa

2. Fallo.

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

Il contenuto specifico della firma ha molto spazio per la regolazione. Quali campi della transazione sono assemblati per la firma sono determinati dal flag SIGHASH. Secondo la definizione del codice operativo della firma BIP 342, i flag SIGHASH sono divisi in SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, ecc., tra cui SIGHASH_ANYONECANPAY controlla l'input e il resto controlla l'output.

SIGHASH_ALL è il flag SIGHASH predefinito, che firma tutti gli output; SIGHASH_NONE non firma alcun output SIGHASH_SINGLE firma un output specificato; SIGHASH_ANYONECANPAY può essere impostato insieme ai primi tre flag SIGHASH. Se SIGHASH_ANYONECANPAY è impostato, verrà firmato solo l'input specificato, altrimenti tutti gli input dovranno essere firmati.

Ovviamente, nessuno di questi flag SIGHASH può eliminare l'impatto dell'input. Anche SIGHASH_ANYONECANPAY richiede un impegno per un input.

Pertanto, BIP 118 propone SIGHASH_ANYPREVOUT. Le firme APO non richiedono la spesa dell’input UTXO (chiamato PREVOUT), ma solo dell’output, garantendo una maggiore flessibilità per il controllo di Bitcoin. Precostruendo la transazione e costruendo la corrispondente firma monouso e chiave pubblica, le risorse inviate all'indirizzo della chiave pubblica devono essere spese attraverso la transazione precostruita per attuare il contratto. La flessibilità dell'APO può essere utilizzata anche per riparare le transazioni. Se una transazione è bloccata sulla catena a causa di commissioni basse, è possibile crearne facilmente un'altra con commissioni più elevate senza richiedere nuove firme. Inoltre, per i portafogli multi-firma, le firme non si basano sugli input spesi, rendendo l’operazione più semplice.

Poiché il ciclo tra scriptPubKeys e input TXID viene eliminato. L'APO può implementare l'introspezione aggiungendo dati di output nel testimone (Witness). Naturalmente, ciò richiede ancora un ulteriore consumo di spazio per i dati del testimone.

Per i protocolli fuori catena come Lightning Network e Vault, APO riduce lo stato intermedio che deve essere salvato, riducendo notevolmente i requisiti di archiviazione e la complessità. Il caso d'uso più diretto di APO è Eltoo, che semplifica la channel factory, costruisce una torre di guardia leggera ed economica e consente l'uscita unilaterale senza lasciare uno stato di errore, migliorando le prestazioni del Lightning Network sotto tutti gli aspetti. L'APO può anche essere utilizzato per simulare le funzioni di CTV, ma richiede che le persone memorizzino firme e transazioni prefirmate, il che è più costoso e non efficiente come CTV.

La critica principale all'APO è che richiede una nuova versione della chiave, cosa che non può essere ottenuta attraverso la pura compatibilità con le versioni precedenti. Inoltre, i nuovi tipi di hash della firma possono introdurre potenziali rischi di doppia spesa. Dopo un'ampia discussione nella comunità, l'APO ha richiesto l'aggiunta di una firma comune oltre alla firma originale. I problemi di sicurezza sono stati alleviati e all'APO è stato quindi assegnato il numero BIP-118.

OP_VAULT BIP-345

BIP-345 propone di aggiungere due nuovi opcode, OP_VAULT e OP_VAULT_RECOVER, da combinare con CTV per implementare un contratto dedicato che consenta agli utenti di forzare un periodo di ritardo sulla spesa di token specificati. Durante il periodo di ritardo, i dati precedenti possono essere ripristinati attraverso il percorso di recupero Spendi "Annulla".

Gli utenti possono costruire un caveau creando un indirizzo Taproot specifico. Il MAST deve contenere almeno due script, uno script OP_VAULT per facilitare il processo di prelievo previsto e un altro script OP_VAULT_RECOVER per garantire che in qualsiasi momento prima del completamento del prelievo, le monete possano. essere ripristinato.

OP_VAULT Come implementare i prelievi interrompibili a tempo bloccato? In poche parole, il codice operativo OP_VAULT realizza una cosa: sostituisce lo script OP_VAULT speso con lo script specificato, completando effettivamente l'aggiornamento di un singolo nodo foglia di MAST, lasciando invariati i restanti nodi foglia. La struttura è simile a TLUV, tranne per il fatto che OP_VAULT non supporta gli aggiornamenti delle chiavi interne.

L'introduzione di modelli durante il processo di aggiornamento dello script può ottenere l'effetto di limitare i pagamenti. Tra questi, il parametro del blocco temporale è specificato da OP_VAULT e il modello portato dal codice operativo CTV limita l'insieme di output spesi attraverso questo percorso di script.

BIP-345 è nato per i caveau. Con OP_VAULT e OP_VAULT_RECOVER, gli utenti possono avere un metodo di deposito a garanzia sicuro con una chiave altamente sicura (portafoglio di carta, firma multipla distribuita) come percorso di recupero e il resto della configurazione di pagamento giornaliero. Alcune spese sono ritardato. Il dispositivo dell'utente monitora continuamente la spesa del deposito e, se si verifica un trasferimento imprevisto, l'utente può ripristinarlo.

BIP-345 richiede considerazioni sui costi durante l'implementazione dei depositi, in particolare il ripristino delle transazioni. Le possibili soluzioni includono CPFP, ancoraggi temporanei e nuovi flag di hash della firma come SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

La soluzione TLUV è costruita attorno a Taproot e mira a risolvere il problema dell'uscita efficiente di UTXO condivisi. L'idea guida è che quando viene speso un output Taproot, possiamo aggiornare parzialmente la chiave interna e il MAST utilizzando la struttura interna e la trasformazione crittografica dell'indirizzo Taproot secondo i passaggi di aggiornamento descritti nello script TLUV, realizzando così la funzione di contratto. .

L'idea della soluzione TLUV è che attraverso un nuovo opcode TAPLEAF_UPDATE_VERIFY, sia possibile creare un nuovo indirizzo Taproot in base al consumo attuale in ingresso eseguendo una o più delle seguenti operazioni:

• Aggiorna la chiave pubblica interna

• tracciato di ritaglio

• Rimuove il nodo foglia attualmente in esecuzione

• Aggiungi un nuovo nodo foglia alla fine del percorso Merkle

Nello specifico, TLUV riceve tre input:

• Uno specifica come aggiornare la chiave pubblica interna

• Uno specifica un nuovo nodo foglia per il percorso Merkle

• Uno specifica se rimuovere il nodo foglia corrente e/o quanti nodi foglia del percorso Merkle rimuovere

Il codice operativo TLUV calcola lo scriptPubKey aggiornato e verifica che l'output corrispondente all'input corrente utilizzi quello scriptPubKey.

Lo scenario ispiratore di TLUV è CoinPool. Oggi è possibile creare un pool federato utilizzando solo transazioni pre-firmate, ma se si desidera ottenere un’uscita senza autorizzazione è necessario creare un numero esponenzialmente maggiore di firme, mentre TLUV consente un’uscita senza autorizzazione senza alcuna pre-firma. Ad esempio, un gruppo di partner ha utilizzato Taproot per creare un UTXO condiviso che mettesse in comune i reciproci fondi. Possono utilizzare le chiavi Taproot per spostare fondi internamente e possono anche cofirmare per avviare pagamenti esternamente. Gli individui possono ritirarsi dal pool di fondi condivisi in qualsiasi momento ed eliminare il proprio percorso di pagamento. Gli altri possono comunque completare i pagamenti tramite il percorso originale. Allo stesso tempo, il ritiro dell'individuo non esporrà informazioni aggiuntive su altre persone all'interno. Rispetto alle transazioni non raggruppate, questo metodo è più efficiente e privato.

Il codice operativo TLUV implementa restrizioni di spesa parziali aggiornando il MAST originale, ma non implementa l'introspezione dell'importo di output. Quindi è necessario includere anche un nuovo codice operativo IN_OUT_AMOUNT, che inserisce due dati nello stack: l'importo di questo input UTXO e l'importo dell'output corrispondente, e quindi si aspetta che la persona che utilizza TLUV utilizzi operatori matematici per verificare che i fondi sono adeguatamente riservati nello scriptPubKey aggiornato.

L'introspezione dell'importo di output aggiunge un altro livello di complessità, poiché l'importo di Bitcoin richiede fino a 51 bit per essere rappresentato in satoshi, ma lo script consente solo operazioni matematiche a 32 bit e deve essere aggiornato nello script ridefinendo l'operatore di comportamento del codice operativo oppure utilizza SIGHASH_GROUP invece di IN_OUT_AMOUNT.

Si prevede che TLUV fornisca una soluzione per i pool di fondi decentralizzati di livello 2. Naturalmente, l'affidabilità delle modifiche alla chiave pubblica di Taproot deve ancora essere confermata.

OPACO

MATT (Merkleize All The Things) tenta di raggiungere tre obiettivi: stato basato su Merkle, script basati su Merkle ed esecuzione basata su Merkle, per poi realizzare contratti intelligenti universali.

Stato Merkle: costruisci un Merkle Trie, in cui ogni nodo foglia è il valore hash dello stato e la radice Merkle rappresenta lo stato dell'intero contratto.

Merkle script: ovvero MAST composto da Tapscript Ogni nodo foglia è un possibile percorso di transizione di stato.

Esecuzione Merkle: l'esecuzione Merkle viene ottenuta tramite meccanismi di impegno crittografato e di sfida alle frodi. Per qualsiasi funzione di calcolo, i partecipanti possono calcolare fuori catena e quindi rilasciare un impegno, f(x)=y, e gli altri partecipanti scoprono che il risultato del calcolo è sbagliato f. (x)= z, puoi contestare e arbitrare attraverso il metodo della dicotomia, che è lo stesso principio dell'Optimistic Rollup.

Sfide antifrode consentite da Merkle

Per implementare MATT, gli script di programmazione Bitcoin devono avere le seguenti funzionalità:

1. Forza un output ad avere script specifici (e i loro importi)

2. Aggiunge un pezzo di dati a un output

3. Leggere i dati dall'input corrente (o da un altro input)

Il secondo punto è molto importante, i dati dinamici significano che lo stato può essere calcolato dai dati di input forniti dal consumatore, perché ciò fornisce una simulazione della macchina a stati e può determinare lo stato successivo con dati aggiuntivi. La soluzione MATT viene implementata proponendo il codice operativo OP_CHECKCONTRACTVERIFY (OP_CCV), che è una fusione dei codici operativi OP_CHECKOUTPUTCONTRACTVERIFY e OP_CHECKINPUTCONTRATVERIFY originariamente proposti e utilizza un parametro flag aggiuntivo per specificare l'oggetto dell'operazione.

Controllo della quantità di output: il modo più diretto è attraverso l'introspezione diretta. Tuttavia, la quantità di output è un numero a 64 bit e richiede operazioni a 64 bit, il che è molto complesso nell'implementazione degli script Bitcoin. CCV adotta un metodo di controllo ritardato, simile a OP_VAULT. Tutti gli input con CCV sullo stesso output hanno i loro importi di input sommati come limite inferiore dell'importo di output. Il ritardo è dovuto al fatto che il controllo viene effettuato durante la transazione e non durante la valutazione dello script immesso.

Data la generalità dell’impermeabilità alle frodi, alcune varianti del contratto MATT dovrebbero consentire tutti i tipi di contratti intelligenti o build di secondo livello, sebbene requisiti aggiuntivi (come il blocco del capitale e i ritardi nel periodo di sfida) debbano essere valutati accuratamente; per valutare quale Applicazione è una transazione accettabile. Ad esempio, il meccanismo di impegno crittografico e di sfida alle frodi viene utilizzato per simulare la funzione OP_ZK_VERIFY per implementare il rollup trustless su Bitcoin.

In effetti, sta già accadendo. Johan Torås Halseth ha implementato elftrace utilizzando il codice operativo OP_CHECKCONTRACTVERIFY nella proposta del soft fork MATT, che può verificare tutti i programmi che supportano la compilazione RISC-V sulla catena Bitcoin, consentendo a una delle parti nell'accordo contrattuale di ricevere fondi attraverso il contratto, ottenendo un ponte alla 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, dell'hashing e della verifica delle firme. Tuttavia, il messaggio verificato viene ottenuto serializzando la transazione utilizzando questo codice operativo e non è consentito specificare altri messaggi. In poche parole, OP_CHECKSIG (e le sue operazioni correlate) funzionano attraverso il meccanismo di firma per verificare se l'UTXO utilizzato come input della transazione è autorizzato a essere speso dal titolare della firma, proteggendo così la sicurezza di Bitcoin.

CSFS, come suggerisce il nome, controlla le firme dallo stack. Il codice operativo CSFS riceve tre parametri dallo stack: una firma, un messaggio e una chiave pubblica e verifica la validità della firma. Ciò significa che è possibile passare messaggi arbitrari allo stack attraverso i dati testimone e verificarli da CSFS. che fa la punta Alcune innovazioni sulla moneta sono possibili.

Le caratteristiche flessibili di CSFS gli consentono di implementare molteplici meccanismi come firme di pagamento, delega di autorità, contratti oracolo, obbligazioni di protezione a doppia spesa, ecc. e, cosa più importante, può realizzare l'introspezione delle transazioni. Il principio dell'utilizzo di CSFS per l'introspezione delle transazioni è molto semplice. Se il contenuto della transazione utilizzato da OP_CHECKSIG viene inserito nello stack tramite il testimone, vengono utilizzate la stessa chiave pubblica e la stessa firma per verificare il contenuto sia con CSFS che con OP_CHECKSIG , il contenuto di qualsiasi messaggio passato a CSFS è lo stesso della transazione di spesa serializzata (e di altri dati) utilizzata implicitamente per OP_CHECKSIG Abbiamo verificato i dati della transazione sullo stack e possiamo applicare altri codici operativi al limite della transazione di spesa.

CSFS di solito appare insieme a OP_CAT, perché OP_CAT può connettere diversi campi della transazione per completare la serializzazione e può selezionare in modo più accurato i campi della transazione che devono essere analizzati. Senza OP_CAT, lo script non può ricalcolare l'hash dai dati che possono essere controllati individualmente, quindi tutto ciò che può fare è verificare se l'hash è uguale a un valore specifico, il che significa che la moneta può essere spesa solo attraverso una singola transazione specifica.

CSFS può implementare CLTV, CSV, CTV, APO e altri codici operativi. È un codice operativo di introspezione generale, quindi può anche aiutare il piano di espansione di Bitcoin Layer 2. Lo svantaggio è che è necessario aggiungere allo stack una copia completa della transazione firmata, il che potrebbe aumentare in modo significativo la dimensione delle transazioni che si desidera analizzare con CSFS. In confronto, i codici operativi di introspezione monouso come CLTV e CSV utilizzano un sovraccarico minimo, ma l’aggiunta di ogni nuovo codice operativo di introspezione speciale richiede una modifica consensuale.

TXHASH (OP_TXHASH)

OP_TXHASH è un codice operativo di introspezione molto semplice che consente all'operatore di selezionare un hash di un campo da inserire nello stack. Nello specifico, OP_TXHASH estrarrà un flag txhash dallo stack, calcolerà un txhash (con tag) basato su quel flag e inserirà 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 a CTV, fornendo un modello di transazione più avanzato che consente agli utenti di spendere esplicitamente una parte di una transazione, risolvendo molti problemi relativi alle commissioni di transazione. Rispetto ad altri opcode contrattuali, TXHASH non necessita di fornire una copia dei dati richiesti nel testimone, riducendo ulteriormente la necessità di archiviazione a differenza di CTV, TXHASH non è compatibile con NOP e può essere implementato solo in tapscript; CSFS può essere considerato un'alternativa a CTV e APO.

Dal punto di vista del modo in cui è costruito il contratto, TXHASH rende più semplice l'implementazione di un "contratto additivo" inserendo tutte le parti dei dati della transazione che si desidera correggere nello stack, sottoponendoli ad hashing tutti insieme e verificando che l'hash risultante corrisponde al valore fisso; CTV È più semplice implementare "contratti sottrattivi", inserendo nello stack tutte le parti dei dati della transazione che si desidera mantenere libere. Quindi utilizzare il rolling OP_SHA256 per iniziare da uno stato intermedio fisso che impegna il 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 di bozza su Github e non è stato ancora numerato.

OP_CAT

OP_CAT è un codice operativo piuttosto misterioso. È stato abbandonato da Satoshi Nakamoto a causa di problemi di sicurezza. Recentemente ha causato un gran numero di discussioni tra gli sviluppatori principali di Bitcoin e ha persino innescato una cultura meme su Internet. Alla fine, OP_CAT è stato approvato BIP-347 ed era Molte persone la chiamano la proposta BIP che molto probabilmente verrà approvata nel prossimo futuro.

Infatti, OP_CAT si comporta in modo molto semplice, concatenando due elementi dello stack in uno solo. Come implementare la funzione contrattuale?

Infatti, la funzione di splicing di due elementi corrisponde ad una potente struttura dati crittografica, la Merkle Trie. Il processo di costruzione di Merkle Trie richiede solo due operazioni: splicing e hashing e negli script Bitcoin sono disponibili funzioni di hash. Pertanto, con OP_CAT, possiamo teoricamente verificare Merkle Proof nello script Bitcoin, che è il metodo di verifica leggero più comunemente utilizzato nella blockchain.

Come accennato in precedenza, CSFS, con l'aiuto di OP_CAT, è in grado di implementare uno schema contrattuale comune. Infatti, lo stesso OP_CAT può implementare l'introspezione delle transazioni senza CSFS, sfruttando la struttura delle firme Schnorr.

Nella firma Schnorr, il messaggio da firmare è composto dai seguenti campi:

Questi campi contengono gli elementi principali della transazione Inserendoli in uno scriptPubKey o in un testimone, utilizzando OP_CAT e OP_SHA256, possiamo costruire una firma Schnorr e controllarla utilizzando OP_CHECKSIG. Se la verifica passa, i dati della transazione verificata vengono conservati nello stack, consentendo l'introspezione della transazione, con la possibilità di estrarre ed "esaminare" varie parti della transazione, come i suoi input, output, indirizzo di destinazione o l'importo di Bitcoin coinvolto.

Per i principi specifici della crittografia, fare riferimento all'articolo CAT e Schnorr Tricks pubblicato da Andrew Poelstra.

In sintesi, la flessibilità di OP_CAT gli consente di emulare quasi tutti i codici operativi di contratto e un gran numero di codici operativi di contratto si basano sulla funzionalità di OP_CAT, il che lo pone significativamente in vantaggio nell'elenco delle fusioni. In teoria, basandoci esclusivamente su OP_CAT e sui codici operativi Bitcoin esistenti, possiamo sperare di costruire un BTC ZK Rollup con fiducia ridotta al minimo, e Starknet, Chakra e altri partner ecologici lo stanno promuovendo attivamente.

Conclusione

Mentre esploriamo molteplici strategie per scalare Bitcoin e aumentarne la programmabilità, è chiaro che il percorso da seguire implica una combinazione di miglioramenti nativi, calcolo off-chain e sofisticate capacità di scripting.

Senza uno strato di base flessibile, non è possibile creare un secondo strato più flessibile.

L’espansione dell’informatica fuori catena è il futuro, ma è necessario un passo avanti nella programmabilità di Bitcoin per supportare meglio l’espansione e diventare una valuta mondiale reale.

Tuttavia, i calcoli di Bitcoin ed Ethereum sono in realtà fondamentalmente diversi. 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 da un punto: Ethereum addebita una commissione sotto forma di Gas per le transazioni fallite, mentre Bitcoin no.

Il contratto implementa una forma di contratto intelligente basato sulla verifica anziché sul calcolo. Per quanto riguarda i contratti, tutti, tranne una manciata di fondamentalisti Satoshi, sembrano pensare che siano una buona opzione per migliorare Bitcoin. Tuttavia, la comunità continua a dibattere su quale metodo utilizzare per attuare il contratto.

APO, OP_VAULT e TLUV sono più orientati verso le applicazioni dirette e scegliendoli è possibile implementare applicazioni specifiche in modo più economico ed efficiente. Gli appassionati di Lightning Network preferiranno APO perché può implementare LN-Symmetry; se desideri implementare un vault, è meglio utilizzare OP_VAULT per creare CoinPool, utilizzare TLUV per maggiore privacy ed efficienza; OP_CAT e TXHASH sono più versatili e hanno meno probabilità di presentare vulnerabilità di sicurezza. Combinandoli con altri codici operativi, è possibile ottenere più casi d'uso, anche se ovviamente potrebbe essere necessario pagare per la complessità dello script. CTV e CSFS hanno apportato modifiche al processo di elaborazione della blockchain. CTV ha implementato l'output ritardato e CSFS ha implementato le firme ritardate. MATT è relativamente unico, utilizza le idee di esecuzione ottimistica e prova delle frodi e utilizza la struttura di Merkle Trie per implementare contratti intelligenti universali, ma ha ancora bisogno di nuovi codici operativi per portare funzioni di introspezione.

Abbiamo visto che la comunità Bitcoin sta già discutendo intensamente della possibilità di consentire a Bitcoin di ottenere contratti tramite soft fork. Starknet ha annunciato ufficialmente il suo ingresso nell'ecosistema Bitcoin e prevede di implementare l'insediamento sulla rete Bitcoin entro sei mesi dalla fusione di OP_CAT. Chakra continuerà a prestare attenzione alle ultime tendenze nell'ecosistema Bitcoin, a promuovere la fusione dei soft fork OP_CAT e a utilizzare la programmabilità portata dall'introspezione e dai contratti per costruire uno strato di regolamento Bitcoin più sicuro ed efficiente.

Grazie a Jeffrey, Ben, Mutourend e Lynndell per la loro recensione e i suggerimenti su questo articolo