Il Santo Graal della rete Layer 2 di Bitcoin: Introspezione e alleanze

cd

Rispetto alle blockchain Turing-complete come Ethereum, il linguaggio di scripting di Bitcoin è considerato notevolmente limitato, in grado di eseguire solo operazioni di base e addirittura privo di funzioni di moltiplicazione e divisione. Inoltre, i dati della blockchain stessa sono quasi inaccessibili agli script, il che comporta gravi limitazioni in termini di flessibilità e programmabilità. Di conseguenza, da tempo si cerca un modo per consentire l’introspezione degli script Bitcoin.

Introspezione si riferisce alla capacità degli Gli script di Bitcoin possono ispezionare e limitare i dati delle transazioni. Ciò consente agli script di controllare l’uso dei fondi in base a specifici dettagli della transazione, consentendo funzionalità più complesse. Attualmente, la maggior parte degli opcode Bitcoin inserisce nello stack i dati forniti dall’utente o manipola i dati già presenti nello stack. Gli opcode di introspezione, tuttavia, possono inserire nello stack i dati delle transazioni correnti (come i timestamp, gli importi e gli ID delle transazioni), consentendo un controllo più granulare sulla spesa UTXO.

Attualmente negli script Bitcoin esistono solo tre codici operativi principali che supportano l’introspezione: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY e CHECKSIG. CHECKSIG ha diverse varianti, tra cui CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG e CHECKMULTISIGVERIFY.

Patti sono restrizioni su come i token possono essere trasferiti. Gli utenti possono specificare il modo in cui gli UTXO vengono distribuiti attraverso i patti, molti dei quali sono implementati utilizzando gli opcode di introspezione. Attualmente, Bitcoin Optech classifica l’introspezione tra le voci di patto.

Attualmente Bitcoin ha due patti: CSV (CheckSequenceVerify) e CLTV (CheckLockTimeVerify), entrambi basati sul tempo e alla base di molte soluzioni di scaling, come la Lightning Network. Ciò indica che le soluzioni di scalatura di Bitcoin si basano fortemente sull’introspezione e sui patti.

Come aggiungere condizioni ai trasferimenti di token

Nel mondo della crittografia, il metodo più comune è il impegni, spesso implementato con gli hash. Per dimostrare che le condizioni di trasferimento sono soddisfatte, si utilizzano meccanismi di firma per la verifica. Pertanto, i patti comportano numerose modifiche agli hash e alle firme.

Le seguenti sono proposte di opcode del patto ampiamente discusse:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), incluso in BIP-119, è un aggiornamento di Bitcoin molto discusso. Il CTV consente agli script di output di specificare modelli per le transazioni di spesa, compresi campi come nVersion, nLockTime, hash di scriptSig, conteggio degli input, hash delle sequenze, conteggio degli output, hash degli output e indice degli input. Queste restrizioni dei modelli sono implementate attraverso un impegno di hash e i futuri script di spesa verificheranno se i valori di hash dei campi specificati nella transazione di spesa corrispondono a quelli dello script di input. Questi modelli definiscono essenzialmente il tempo, il metodo e l’importo delle future transazioni UTXO.

In particolare, il TXID in ingresso è escluso dall’impegno dell’hash. Questa esclusione è necessaria perché, sia nelle transazioni Legacy che in quelle Segwit, il TXID dipende dal valore di scriptPubKey quando si utilizza il tipo di firma predefinito SIGHASH_ALL. L’inclusione del TXID creerebbe una dipendenza circolare, rendendo impossibile la costruzione dell’impegno di hash.

Il CTV ottiene l’introspezione ottenendo direttamente le informazioni sulla transazione specificata tramite un nuovo opcode, effettuando l’hashing e confrontandole con l’impegno sullo stack. Questo metodo consuma meno spazio sulla catena, ma manca di flessibilità.

Il fondamento di soluzioni di secondo livello come Lightning Network è costituito dalle transazioni pre-firmate. Pre-firmare significa di solito generare e firmare le transazioni in anticipo, ma non diffonderle fino a quando non vengono soddisfatte determinate condizioni. In sostanza, il CTV implementa una funzione di pre-firma più rigorosa, pubblicando l’impegno pre-firmato direttamente sulla catena, consentendo transazioni solo in base al modello predefinito.

Il CTV è stato inizialmente proposto per alleviare la congestione di Bitcoin e può anche essere definito controllo della congestione. Durante i periodi di alta congestione, il CTV può impegnare più transazioni future attraverso un’unica transazione, evitando la necessità di trasmettere più transazioni durante la congestione e completando le transazioni effettive dopo che la congestione si è attenuata. Questo potrebbe essere di grande aiuto durante le operazioni di scambio. Inoltre, i modelli possono essere utilizzati per implementare i caveau, prevenendo gli attacchi degli hacker poiché la destinazione dei fondi è predeterminata, rendendo impossibile per gli hacker inviare UTXO utilizzando lo script del CTV ai loro indirizzi.

Il CTV può migliorare significativamente le reti di secondo livello. Ad esempio, nella rete Lightning, l’implementazione degli alberi di timeout e delle fabbriche di canali utilizzando il CTV consente a un singolo UTXO di espandersi in un albero CTV, aprendo più canali di stato con una sola transazione e conferma sulla catena. Inoltre, CTV supporta le transazioni atomiche (ATLC) nel protocollo Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 propone un nuovo flag di hash della firma per tapscript, chiamato SIGHASH_ANYPREVOUT, per facilitare la scrittura di una logica di spesa più flessibile. APO e CTV sono simili per molti aspetti. Per risolvere la dipendenza circolare tra scriptPubKey e TXID, la soluzione di APO consiste nell’escludere le informazioni di input rilevanti e firmare solo l’output, consentendo alle transazioni di legarsi dinamicamente a UTXO diversi.

Logicamente, l’operazione di verifica OP_CHECKSIG (e i relativi codici operativi) ha tre funzioni:

  1. Assemblare le parti della transazione di spesa.
  2. Hash queste parti.
  3. Verifica se l’hash è firmato dalla chiave indicata.

Il contenuto specifico della firma può essere modificato in modo significativo e i campi della transazione che vengono firmati sono determinati dal flag SIGHASH. Secondo la definizione degli opcode di firma del BIP 342, i flag SIGHASH includono, tra gli altri, SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE e SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY controlla l’ingresso, mentre gli altri controllano l’uscita.

SIGHASH_ALL è il flag SIGHASH predefinito, che firma tutte le uscite. SIGHASH_NONE non firma nessuna uscita e SIGHASH_SINGLE firma solo un’uscita specificata. SIGHASH_ANYONECANPAY può essere impostato con gli altri tre flag e, se impostato, firma solo l’ingresso specificato; altrimenti, tutti gli ingressi devono essere firmati.

Nessuno di questi flag SIGHASH può eliminare l’impatto degli ingressi. Anche SIGHASH_ANYONECANPAY richiede un impegno per un solo ingresso.

Pertanto, il BIP 118 introduce SIGHASH_ANYPREVOUT. Le firme APO non devono impegnare l’UTXO di ingresso speso (chiamato PREVOUT), ma solo firmare l’uscita, fornendo una maggiore flessibilità nel controllo di Bitcoin. Pre-costruendo le transazioni e creando le corrispondenti firme e chiavi pubbliche monouso, le risorse inviate all’indirizzo della chiave pubblica devono essere spese attraverso la transazione precostituita, ottenendo il patto.

La flessibilità di APO può essere utilizzata anche per la riparazione delle transazioni. Se una transazione rimane bloccata sulla catena a causa delle basse commissioni, è possibile creare facilmente un’altra transazione per aumentare la commissione senza bisogno di nuove firme. Inoltre, per i portafogli multi-firma, le firme che non dipendono dall’input speso rendono le operazioni più semplici.

Eliminando la dipendenza circolare tra gli scriptPubKey e i TXID di input, APO può ottenere l’introspezione aggiungendo i dati di output nel testimone, anche se ciò richiede uno spazio dati aggiuntivo per il testimone.

Per i protocolli fuori catena come la Lightning Network e i caveau, APO riduce la necessità di memorizzare gli stati intermedi, riducendo in modo significativo i requisiti di memorizzazione e la complessità. Il caso d’uso più diretto di APO è Eltoo, che semplifica le fabbriche di canali, costruisce torri di guardia leggere e poco costose e consente uscite unilaterali senza lasciare stati errati, migliorando le prestazioni della Lightning Network. APO può simulare le funzionalità del CTV, ma richiede la memorizzazione personale delle firme e delle transazioni pre-firmate, il che lo rende più costoso e meno efficiente del CTV.

La critica principale di APO è la necessità di una nuova versione della chiave, che la rende incompatibile con i sistemi esistenti. Inoltre, il nuovo tipo di hash della firma potrebbe introdurre potenziali rischi di doppia spesa. Dopo ampie discussioni con la comunità, APO richiede ora una firma ordinaria in aggiunta a quella originale, alleviando i problemi di sicurezza e guadagnandosi il numero BIP-118.

OP_VAULT BIP-345

Il BIP-345 propone due nuovi opcode, OP_VAULT e OP_VAULT_RECOVER, per lavorare con il CTV e implementare un patto dedicato che impone un periodo di ritardo nella spesa di determinati token, durante il quale la spesa può essere “revocata” tramite un percorso di recupero.

Gli utenti possono creare un caveau impostando un indirizzo Taproot specifico, includendo almeno due script nel MAST: uno script OP_VAULT per facilitare il processo di prelievo previsto e uno script OP_VAULT_RECOVER per garantire il recupero delle monete prima del completamento del prelievo.

Come fa OP_VAULT a ottenere prelievi temporizzati interrompibili?

In parole povere, l’opcode OP_VAULT sostituisce lo script OP_VAULT speso con uno script specificato, aggiornando un singolo nodo foglia del MAST e mantenendo invariato il resto. È simile a TLUV, ma non supporta gli aggiornamenti delle chiavi interne.

L’introduzione di un modello durante gli aggiornamenti degli script può limitare gli effetti di pagamento. Il parametro di blocco temporale è specificato da OP_VAULT, mentre il modello portato dall’opcode CTV limita l’insieme delle uscite passate attraverso quel percorso di script.

BIP-345 è stato progettato per i caveau, consentendo agli utenti di disporre di un percorso di recupero altamente sicuro (portafoglio cartaceo, multi-firma distribuita), configurando al contempo un ritardo di spesa per i pagamenti di routine. Il dispositivo dell’utente monitora costantemente la spesa del caveau, consentendo il recupero in caso di trasferimento non autorizzato.

L’implementazione dei caveau con BIP-345 richiede di considerare le questioni relative alle commissioni, soprattutto per le transazioni di recupero. Le possibili soluzioni includono CPFP (Child Pays for Parent), ancore temporanee e nuovi flag di hash della firma come SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Lo schema TLUV è costruito intorno a Taproot e mira a risolvere il problema dell’uscita efficiente dagli UTXO condivisi. Il principio guida è che quando un’uscita Taproot viene spesa, possiamo utilizzare la struttura interna dell’indirizzo Taproot e le trasformazioni crittografiche per aggiornare parzialmente la chiave interna e il MAST secondo le fasi di aggiornamento descritte dallo script TLUV, ottenendo così la funzionalità del contratto.

L’idea dello schema TLUV è quella di creare un nuovo indirizzo Taproot in base all’input di spesa corrente attraverso un nuovo opcode TAPLEAF_UPDATE_VERIFY, che può eseguire una o più delle seguenti operazioni:

In particolare, TLUV riceve tre input:

  1. Una specifica su come aggiornare la chiave pubblica interna
  2. Un nuovo nodo foglia per il percorso Merkle
  3. Specifica se rimuovere il nodo foglia corrente e/o quanti nodi foglia del percorso Merkle rimuovere.

L’opcode TLUV calcola la scriptPubKey aggiornata e verifica se l’output corrispondente all’input corrente è speso per quella scriptPubKey.

L’ispirazione per TLUV sono i coin pool. Oggi i coin pool possono essere creati utilizzando transazioni pre-firmate, ma se si vuole ottenere un’uscita senza permesso, è necessario creare un numero di firme in crescita esponenziale. TLUV consente uscite senza autorizzazione senza transazioni pre-firmate. Ad esempio, un gruppo di partner utilizza Taproot per creare un UTXO condiviso, mettendo in comune i propri fondi. Possono spostare i fondi internamente utilizzando la chiave Taproot o firmare congiuntamente per effettuare pagamenti esterni. I singoli possono uscire dal pool condiviso in qualsiasi momento, rimuovendo il loro percorso di pagamento, mentre gli altri possono continuare a completare i pagamenti attraverso il percorso originale senza esporre ulteriori informazioni sui membri rimanenti. Questo metodo è più efficiente e privato rispetto alle transazioni non in pool.

L’opcode TLUV consente di ottenere restrizioni di spesa parziali aggiornando il MAST originale. Tuttavia, non consente l’introspezione degli importi in uscita. Pertanto, è necessario un nuovo opcode IN_OUT_AMOUNT, che inserisce due dati nello stack: l’importo dell’UTXO di questo ingresso e l’importo corrispondente dell’uscita. La persona che utilizza TLUV deve quindi utilizzare gli operatori matematici per verificare se i fondi sono conservati correttamente nella scriptPubKey aggiornata.

L’introspezione degli importi in uscita aggiunge un’ulteriore complessità perché gli importi Bitcoin sono rappresentati in satoshi e richiedono fino a 51 bit, ma gli script consentono solo operazioni matematiche a 32 bit. Ciò richiede l’aggiornamento degli operatori nello script ridefinendo il comportamento degli opcode o utilizzando SIGHASH_GROUP per sostituire IN_OUT_AMOUNT.

Si prevede che TLUV fornisca soluzioni per i coin pool decentralizzati Layer 2, anche se l’affidabilità in termini di modifica delle chiavi pubbliche Taproot necessita di ulteriori conferme.

MATT

MATT (Merkleize All The Things) mira a raggiungere tre obiettivi: Merlettizzare lo stato, Merlettizzare gli script e Merlettizzare l’esecuzione, ottenendo così contratti intelligenti generali.

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

  1. Applicare uno script specifico a un’uscita (e i relativi importi)
  2. Collegare i dati a un’uscita
  3. Leggere i dati dall’ingresso corrente (o da altri ingressi)

Il secondo punto è fondamentale, in quanto i dati dinamici consentono di calcolare lo stato attraverso i dati di input forniti dallo spender, simulando una macchina a stati e decidendo lo stato successivo e i dati allegati. MATT propone l’opcode OP_CHECKCONTRACTVERIFY (OP_CCV), una combinazione degli opcode OP_CHECKOUTPUTCONTRACTVERIFY e OP_CHECKINPUTCONTRACTVERIFY proposti in precedenza, con l’aggiunta di un parametro flags per specificare il target dell’operazione.

Controllo degli importi in uscita: Il modo più diretto è l’introspezione diretta. Tuttavia, gli importi di uscita sono numeri a 64 bit che richiedono operazioni a 64 bit, il che aggiunge complessità all’implementazione dello script Bitcoin. CCV adotta un controllo ritardato simile a OP_VAULT, sommando gli importi di ingresso per tutti gli ingressi alla stessa uscita con CCV come limite inferiore di tale importo di uscita. Il controllo è ritardato al processo di transazione invece che durante la valutazione dello script di input.

Data la generalità delle prove di frode, alcune varianti dei contratti MATT dovrebbero raggiungere tutti i tipi di smart contract o costruzioni Layer 2, anche se ulteriori requisiti (come il lock-in del capitale e i ritardi nel periodo di sfida) necessitano di una valutazione accurata. Sono necessarie ulteriori ricerche per valutare quali applicazioni siano transazioni accettabili. Ad esempio, l’utilizzo di impegni crittografici e meccanismi di sfida alle frodi per simulare le funzioni OP_ZK_VERIFY, realizzando Rollup senza fiducia su Bitcoin.

In pratica, le cose stanno già accadendo. Johan Torås Halseth ha implementato elftrace utilizzando l’opcode OP_CHECKCONTRACTVERIFY della proposta di soft fork MATT, consentendo a tutti i programmi supportati dalla compilazione RISC-V di essere verificati sulla catena Bitcoin, abilitando i ponti di verifica Bitcoin nativi per i protocolli contrattuali.

CSFS (OP_CHECKSIGFROMSTACK)

Dall’introduzione dell’opcode APO, sappiamo che OP_CHECKSIG (e le operazioni correlate) è responsabile dell’assemblaggio delle transazioni, dell’hashing e della verifica della firma. Tuttavia, il messaggio che verifica è derivato dalla serializzazione della transazione utilizzando questo opcode, che non consente di specificare altri messaggi. In parole povere, OP_CHECKSIG (e le operazioni correlate) serve a verificare che l’UTXO in ingresso alla transazione sia autorizzato a essere speso dal titolare della firma, proteggendo così la sicurezza di Bitcoin.

CSFS, come suggerisce il nome, verifica le firme dallo stack. L’opcode CSFS prende tre parametri dallo stack: una firma, un messaggio e una chiave pubblica, e verifica la validità della firma. Ciò significa che qualsiasi messaggio può essere passato allo stack attraverso i dati dei testimoni e verificato da CSFS, consentendo alcune innovazioni su Bitcoin.

La flessibilità di CSFS gli consente di implementare diversi meccanismi, come le firme di pagamento, la delega dell’autorità, i contratti oracolo, i vincoli di protezione contro il doppio spreco e, soprattutto, l’introspezione delle transazioni. Il principio dell’introspezione delle transazioni con CSFS è molto semplice. Se il contenuto della transazione utilizzato da OP_CHECKSIG viene inserito nello stack attraverso il testimone e la stessa chiave pubblica e la stessa firma vengono utilizzate per la verifica sia con CSFS che con OP_CHECKSIG, se entrambe passano, allora il contenuto di qualsiasi messaggio passato a CSFS è lo stesso della transazione di spesa serializzata (e di altri dati) utilizzata implicitamente da OP_CHECKSIG. Si ottengono quindi i dati verificati della transazione sullo stack, che possono essere utilizzati per applicare restrizioni alla transazione di spesa con altri opcode.

CSFS appare spesso con OP_CAT perché OP_CAT può concatenare diversi campi della transazione per completare la serializzazione, consentendo una selezione più precisa dei campi della transazione per l’introspezione. Senza OP_CAT, lo script non può ricompilare gli hash da dati verificabili singolarmente, quindi può solo verificare se un hash corrisponde a un valore specifico, il che significa che le monete possono essere spese solo attraverso una singola transazione specifica.

CSFS può raggiungere opcode come CLTV, CSV, CTV, APO, ed è un opcode di introspezione generale, quindi aiuta anche le soluzioni di scaling Layer 2 per Bitcoin. Il suo svantaggio è che richiede l’aggiunta di una copia completa della transazione firmata allo stack, il che può aumentare significativamente le dimensioni delle transazioni che vogliono utilizzare CSFS per l’introspezione. Al contrario, gli opcode di introspezione a scopo singolo, come CLTV e CSV, presentano il minor overhead, ma l’aggiunta di ogni nuovo opcode di introspezione speciale richiede modifiche al consenso.

TXHASH (OP_TXHASH)

OP_TXHASH è un opcode di introspezione molto semplice che consente all’operatore di selezionare l’hash di un campo e spingerlo sullo stack. In particolare, OP_TXHASH estrae un flag di txhash dallo stack, calcola un txhash (contrassegnato) in base al flag e spinge l’hash risultante sullo stack.

Data la somiglianza tra TXHASH e CTV, la comunità ha discusso a lungo su entrambi.

TXHASH può essere visto come un aggiornamento generale del CTV, in quanto fornisce un modello di transazione più avanzato che consente agli utenti di specificare parti della transazione di spesa, risolvendo molti problemi relativi alle commissioni di transazione. A differenza di altri opcode di contratto, TXHASH non richiede di fornire una copia dei dati necessari nel testimone, riducendo ulteriormente le esigenze di memorizzazione. A differenza di CTV, TXHASH non è compatibile con NOP e può essere implementato solo in tapscript. La combinazione di TXHASH e CSFS può essere considerata un’alternativa a CTV e APO.

In termini di costruzione di contratti, TXHASH è più facile da ottenere “contratti additivi”, spingendo tutte le parti dei dati della transazione che si desidera fissare nello stack, facendo l’hashing insieme e verificando se il risultato corrisponde a un valore fisso. Con il CTV è più facile ottenere “contratti sottrattivi” spingendo nello stack tutte le parti dei dati della transazione che si desidera mantenere libere. Quindi, utilizzando il rolling OP_SHA256, partendo da uno stato intermedio fisso, tale stato intermedio esegue il commit del prefisso dei dati hash della transazione. Le parti libere vengono inserite in quello stato intermedio.

Il campo TxFieldSelector definito nella specifica TXHASH dovrebbe espandersi ad altri codici opzionali, come OP_TX.

Il BIP relativo a TXHASH è attualmente in stato di bozza su Github e non è ancora stato assegnato un numero.

OP_CAT

OP_CAT è un opcode un po’ misterioso che è stato deprecato da Satoshi Nakamoto per problemi di sicurezza. Tuttavia, di recente ha suscitato ampie discussioni tra gli sviluppatori di Bitcoin core, diventando persino un meme nella comunità online. Alla fine, OP_CAT è stato approvato come BIP-347 e molti lo considerano la proposta BIP più probabile da approvare nel prossimo futuro.

In realtà, il comportamento di OP_CAT è molto semplice: concatena due elementi dello stack in uno solo. Ma come si fa a realizzare la funzionalità del contratto?

La funzione di concatenazione di due elementi corrisponde a una potente struttura di dati crittografici nota come Merkle Trie. La costruzione di un Merkle Trie richiede solo operazioni di concatenazione e hashing, entrambe disponibili negli script Bitcoin. Pertanto, con OP_CAT, possiamo teoricamente verificare le Merkle Proof negli script Bitcoin, che è il metodo di verifica leggero più comune nelle blockchain.

Come accennato in precedenza, CSFS può utilizzare OP_CAT per ottenere uno schema contrattuale generale. In realtà, anche senza CSFS, la struttura delle firme di Schnorr permette a OP_CAT stesso di ottenere l’introspezione delle transazioni.

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

Questi campi contengono gli elementi principali di una transazione. Inserendoli in scriptPubKey o witness e utilizzando OP_CAT e OP_SHA256, è possibile costruire una firma Schnorr e verificarla con OP_CHECKSIG. Se la verifica viene superata, lo stack conserva i dati della transazione verificata, consentendo l’introspezione della transazione. Questo ci permette di estrarre e “ispezionare” varie parti della transazione, come gli input, gli output, gli indirizzi di destinazione o gli importi Bitcoin coinvolti.

Per principi crittografici più dettagliati, consultare l’articolo di Andrew Poelstra “CAT e trucchi di Schnorr”.

In sintesi, la flessibilità di OP_CAT lo rende in grado di imitare quasi tutti gli opcode contrattuali e molti opcode contrattuali dipendono dalla sua funzionalità. Questo fa avanzare significativamente la sua posizione nella lista di fusione. In teoria, con il solo OP_CAT e gli opcode Bitcoin esistenti, potremmo costruire un Rollup ZK BTC minimizzato dal punto di vista della fiducia. Starknet, Chakra e altri partner dell’ecosistema stanno lavorando attivamente affinché ciò avvenga.

Conclusione

Mentre esploriamo varie strategie per espandere Bitcoin e migliorarne la programmabilità, diventa evidente che la strada da percorrere comporta una combinazione di miglioramenti nativi, calcoli fuori catena e funzionalità di script complesse.

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

La scalabilità del calcolo off-chain è il futuro, ma la programmabilità di Bitcoin deve essere superata per supportare meglio la scalabilità e diventare una vera valuta mondiale.

Tuttavia, la computazione di Bitcoin differisce fondamentalmente da quella di Ethereum. Bitcoin supporta solo la “verifica” come forma di calcolo, mentre Ethereum è fondamentalmente computazionale, con la verifica come sottoprodotto. Questa differenza è evidente nel fatto che Ethereum addebita le spese di gas per le transazioni fallite, mentre Bitcoin non lo fa.

I contratti rappresentano una forma di smart contract basata sulla verifica piuttosto che sul calcolo. Per quanto riguarda i contratti, a parte alcuni rigidi fondamentalisti di Satoshi, la maggior parte delle persone ritiene che i contratti siano una buona scelta per migliorare il Bitcoin. Tuttavia, la comunità discute costantemente su quale schema utilizzare per implementare i contratti.

APO, OP_VAULT e TLUV si orientano verso le applicazioni dirette. Scegliendoli si possono implementare applicazioni specifiche in modo più economico ed efficiente. Gli appassionati della Lightning Network preferiscono APO perché realizza la simmetria LN; se si vuole creare un caveau, è meglio usare OP_VAULT; per costruire un CoinPool, TLUV è più privato ed efficiente. OP_CAT e TXHASH sono più generali, con meno vulnerabilità di sicurezza, e possono raggiungere più casi d’uso attraverso combinazioni con altri opcode, anche se potenzialmente al costo della complessità dello script. CTV e CSFS hanno modificato l’approccio all’elaborazione della blockchain: CTV implementa uscite ritardate e CSFS implementa firme ritardate. MATT è relativamente unico, utilizza l’esecuzione ottimistica e le prove di frode e si basa sulla struttura Merkle Trie per ottenere contratti intelligenti generali, anche se richiede nuovi opcode per fornire capacità di introspezione.

Vediamo che la comunità Bitcoin sta già discutendo intensamente sulla possibilità di introdurre contratti attraverso un soft fork. Starknet ha annunciato ufficialmente il suo ingresso nell’ecosistema Bitcoin, pianificando di implementare il regolamento sulla rete Bitcoin entro sei mesi dalla fusione OP_CAT. Chakra continuerà a monitorare gli ultimi sviluppi dell’ecosistema Bitcoin, a promuovere la fusione del soft fork OP_CAT e a utilizzare la programmabilità offerta dall’introspezione e dai contratti per costruire un livello di regolamento Bitcoin più sicuro ed efficiente.

Related Articles
↑
Exit mobile version