Autore dell'articolo: Yunwen Liu 1, Istituto di Ricerca Mysterium
So che quando si parla di questo, i puristi di Bitcoin potrebbero pensare: non è meglio che Bitcoin rimanga semplicemente un oro digitale? Perché è necessario avere token? Perché ci deve essere USDT? Tuttavia, se sei particolarmente preoccupato per la sicurezza degli asset, non puoi fare a meno di chiederti: cosa succede se Ethereum fallisce? Chi può raccogliere DeFi? Inoltre, i progetti di token sono compatibili con il protocollo di Bitcoin e non distruggono la funzionalità originale; se non ti piacciono, puoi non scaricare il client dei token senza subire grandi impatti.
Emettere token su Bitcoin: perché non è possibile?
Emettere token su Bitcoin per trasferire le transazioni di asset del mondo reale sulla catena è un'idea emersa nella comunità di Bitcoin intorno al 2010. Le discussioni iniziali della comunità ipotizzavano di spostare gli asset del mondo reale - come proprietà, azioni, valute legali, su Bitcoin per transazioni decentralizzate. Tuttavia, a causa di fattori legali, non è così facile trasferire asset come proprietà e azioni. Anche se hai pagato il token digitale della tua casa a qualcun altro, il governo potrebbe non riconoscerlo, o potrebbe essere necessario cambiare automaticamente il certificato di proprietà nel mondo reale e pagare varie tasse. Inoltre, non è possibile effettuare transazioni sulla blockchain senza supervisione.
Pertanto, un metodo più attraente è emettere token ancorati a valute fiat, ovvero stablecoin. Le stablecoin sono diverse dagli NFT, sono ancora token fungibili, solo che sono distinti dalla Bitcoin originale. Quando appaiono come token, il loro valore è determinato dal prezzo dell'asset del mondo reale che rappresentano, non dal prezzo della criptovaluta originale (se il prezzo della criptovaluta aumenta molto rispetto al prezzo dell'asset, può anche essere possibile abbandonare l'asset). Ecco perché i token su Bitcoin sono solitamente espressi in satoshi.
Per utilizzare le criptovalute come token di asset, è necessario affrontare due problemi principali:
Come rappresentare gli asset del mondo reale con Bitcoin;
Come impostare regole e contratti di transazione complessi nel linguaggio di script molto limitato di Bitcoin.
Il contenuto sottostante si concentra su questi due aspetti e fornisce un riepilogo delle principali attuali soluzioni di emissione di asset Bitcoin, confrontando aspetti come la disponibilità dei dati, il portatore di asset, l'espressività e la scalabilità.
Il primo token su Bitcoin: colored coins
Non è noto chi abbia progettato per primo un protocollo di token su Bitcoin, l'idea potrebbe essere emersa da discussioni nei forum o comunità di Bitcoin. Il progetto Colored Coins è stato avviato da Yoni Assia nel 2012, quando ha scritto (Colored Coins whitepaper) insieme a Vitalik Buterin, Lior Hakim, Meni Rosenfeld e Rotem Lev, e il progetto è entrato in funzione nel 2013.
Il funzionamento dei colored coins è quello di contrassegnare un satoshi come una moneta speciale, scrivendo le informazioni relative all'asset in quel satoshi - questo processo è chiamato colorazione. Puoi colorare un satoshi in diversi colori, marcandolo con diversi tag, ma i satoshi dello stesso colore non possono essere distinti. Protocolli più antichi utilizzavano il campo nSequence, aggiungendo un'etichetta al nSequence del primo input UTXO della transazione. Tuttavia, il limite di memorizzazione di nSequence è di 4 byte, quindi i successivi design di token sono stati principalmente sostituiti dal campo OP_RETURN, in grado di memorizzare più metadati.
I colored coins sono ancora frequentemente menzionati principalmente perché sono stati il primo progetto di token su Bitcoin. Poiché lo sviluppo del progetto non è stato ideale e non ha avuto un'ampia applicazione, il progetto stesso è stato gradualmente dimenticato. Le sfide che i colored coins hanno affrontato erano dovute al fatto che le funzionalità di Bitcoin non potevano supportare questa idea relativamente avanzata, rendendo difficile la sua attuazione e il funzionamento efficiente. Questo potrebbe spiegare perché Vitalik, dopo il progetto dei colored coins, si sia orientato verso l'opposto di Bitcoin, diventando così appassionato di contratti intelligenti.
Poiché i colored coins esistono sotto forma di satoshi, la loro verifica è simile a quella della validità di un UTXO, richiedendo il download dell'intera catena. Questo problema verrà affrontato in seguito con la validazione lato client (client-side validation).
Inviare token con OP_RETURN: Counterparty & Omni Layer
A differenza dei colored coins, Counterparty e Omni Layer (il protocollo dietro USDT) non colorano direttamente i satoshi, ma impostano un UTXO con valore zero nella transazione, memorizzando i metadati nel campo OP_RETURN di questo UTXO. L'OP_RETURN può contenere 80 byte, indicando che l'UTXO OP_RETURN non può essere speso, mentre il vero token è l'i-th output registrato nell'OP_RETURN. Questo output ha tipicamente un valore di 0.00000546 BTC - il valore minimo consentito dal sistema, e poiché il valore del token non è legato a BTC, non c'è bisogno di emettere più di 0.00000546 BTC.
La validazione di questi progetti deve avvenire on-chain, i metadati sono memorizzati sulla catena.
Omni Layer è stato a lungo un attore sulla blockchain di Ethereum, tornando solo di recente nell'ecosistema di Bitcoin, pronto per emettere BTC-USDT. Counterparty ha messo in staking una parte di Bitcoin e ha il proprio token XCP. Da Twitter, sembra che stiano lavorando su NFT.
Per ulteriori informazioni su OP_RETURN, si veda:
Un'analisi dei metadati OP RETURN di Bitcoin
Costruire manualmente OP_RETURN per inviare USDT 1
Ancorare Bitcoin con sidechain: Rootstock & Liquid Network
I progetti Rootstock e Liquid Network sono apparsi intorno al 2017, entrambi sono soluzioni di sidechain - utilizzando un ancoraggio bidirezionale (Two-way peg) per spostare Bitcoin su una sidechain e utilizzare vari Defi e dApps su una sidechain compatibile con EVM. Hanno token simili a WBTC (RSK ha RBTC, Liquid ha L-BTC), principalmente rivolti a coloro che desiderano costruire nell'ecosistema di Ethereum usando BTC.
Emettere token su Rootstock è come emettere su Ethereum, o si può dire che questa sidechain è progettata per adattarsi all'ecosistema di Ethereum, tranne per il mining che avviene insieme alla blockchain di Bitcoin; ad esempio, il codice dei contratti intelligenti è scritto in Solidity. Pertanto, i token qui sono emessi sulla base di RBTC e non sono direttamente collegati a BTC.
Poiché questo articolo si concentra principalmente sulle blockchain pubbliche e Liquid Network è una blockchain consortile, non verrà approfondito.
Per ulteriori informazioni su RSK, si veda
RSK: una sidechain di Bitcoin con contratti intelligenti stateful (RSK paper)
RSK money
Domande frequenti (FAQs)
Alcuni dei progetti menzionati in precedenza sono scomparsi (come i colored coins), mentre altri vendono l'ecosistema di Ethereum sotto le spoglie di Bitcoin. Questo è principalmente dovuto al fatto che Ethereum, abbracciando il capitale, ha conquistato un vantaggio di mercato assoluto nel DeFi e nelle dApps, rendendo difficile per i progetti DeFi non in collaborazione ottenere vantaggi. I token su Ethereum vengono emessi e scambiati tramite contratti, seguendo standard come l'ERC-20. Anche l'ecosistema di Bitcoin ha iniziato a sbloccare funzionalità contrattuali negli ultimi due anni, come BitVM, e sono emersi standard di token come BRC-20.
Implementare contratti intelligenti su Bitcoin: RGB
RGB (Really Good for Bitcoin), nato nel 2016, è stato originariamente progettato come concorrente dei colored coins. Tuttavia, di fronte a sfide simili, si è orientato verso l'abilitazione di contratti intelligenti su Bitcoin. Anche se si concentra principalmente sull'esecuzione di contratti intelligenti e non sull'emissione di token, a causa delle limitazioni della sua macchina virtuale AluVM, fino al 2024, le funzionalità contrattuali complete rimangono limitate.
L'idea di RGB è di mettere i dati disponibili off-chain e il codice dei contratti intelligenti al di fuori di Bitcoin, utilizzando il Merkle root per fornire la promessa (commitment) della verifica delle transazioni e dell'emissione dei token, mentre la catena di Bitcoin si occupa solo della verifica della promessa di transazione e della finalità, dimostrando che non ci sono stati doppioni.
Un aspetto degno di nota di RGB è l'uso simultaneo della validazione lato client e dei sigilli a uso singolo, in modo che non venga fatto alcun marchio sugli UTXO per indicare i token. Questi due concetti sono stati proposti per la prima volta da Peter Todd nel 2013, e Giacomo Zucco e Maxim Orlovsky hanno progettato il protocollo RGB su questa base.
La validazione lato client (Client-side validation) consente ai dati e al codice utilizzati nelle transazioni di essere memorizzati off-chain, senza essere pubblicamente diffusi; alcune informazioni potrebbero essere scambiate solo tra le due parti della transazione, mentre chi non è coinvolto nella transazione potrebbe non esserne a conoscenza. Lo stato off-chain è mantenuto da Bitcoin, mentre la blockchain funge da timestamp, dimostrando l'ordine temporale degli stati.
Un sigillo a uso singolo (single-use seal) - è anche la forma più comune di validazione client - è una versione digitale di un sigillo monouso. Sfruttando la natura per cui ogni UTXO può essere speso solo una volta, scrive le informazioni sullo stato off-chain in un UTXO. Così, se a un certo punto questo UTXO viene speso, sappiamo che lo stato è stato aggiornato e le informazioni sul nuovo stato vengono scritte in un nuovo UTXO generato. Queste informazioni sullo stato off-chain possono riguardare la proprietà di un token USDT o quanti token ci siano in un certo contratto.
Ad esempio, se Alice vuole inviare un USDT a Bob, questo USDT non esiste sulla blockchain di Bitcoin, le sue informazioni sono mantenute off-chain, ma sarà collegato a un UTXO controllato da Alice. Le sue informazioni sono memorizzate nella transazione che ha generato questo UTXO nel campo OP_RETURN del UTXO il cui valore è zero. In questo modo, solo Alice può spendere questo USDT e Bob può seguire tramite transazioni on-chain dove questo USDT è stato conservato in precedenti UTXO, se questi UTXO sono validi e se la transazione è legittima. Così, quando Alice inizia una transazione trasferendo l'informazione di impegno di questo USDT a un UTXO controllato da Bob, Bob può essere certo di aver ricevuto questo USDT.
RGB può anche funzionare sulla rete Lightning, poiché il suo stato è off-chain, è sufficiente mettere l'impegno on-chain o sulla rete Lightning. Dopo l'aggiornamento di Taproot, RGB può incorporare l'impegno in una transazione Taproot, permettendo a RGB di incorporare l'impegno in modo più flessibile sulla blockchain di Bitcoin.
Per ulteriori informazioni su RGB, si veda:
RGB Blueprint 1
Supporta solo token e non contratti intelligenti: asset Taproot
Il Taproot asset è un progetto sviluppato dal team di Lightning Network Daemon (LND). Il suo principio è simile a RGB, ma non supporta contratti intelligenti complessi, supporta solo token (si veda qui per una spiegazione del termine Taproot).
Per ulteriori informazioni su Client-side validation, RGB e Taproot, si veda
Validazione lato client
Transazioni off-chain: l'evoluzione dei protocolli di asset Bitcoin
Counterparty vs RGB vs TARO
Rendere ogni satoshi unico: Ordinals & Inscriptions
Casey Rodarmor ha pubblicato il protocollo Ordinal all'inizio del 2023. Questo progetto è nato da un'idea: come numerare i satoshi in modo che ognuno abbia un numero di sequenza unico per poter essere ordinato. Questa idea è nata nello stesso periodo dei colored coins, ma è stata ripresa solo lo scorso anno. Inoltre, con l'aggiunta delle funzionalità SegWit e Taproot, la sua realizzazione è diventata meno difficile. Ordinals rende ogni satoshi unico, permettendo così l'emissione di NFT direttamente sulla blockchain di Bitcoin.
Le Inscriptions sono un progetto NFT di questo tipo. I dati NFT sono memorizzati nei dati witness della transazione, piuttosto che nel campo OP_RETURN utilizzato in precedenza dai progetti, permettendo di memorizzare metadati fino a 4MB. A differenza degli NFT su Ethereum, l'Inscriptions è memorizzato on-chain, compresi metadati e immagini.
Per ulteriori informazioni su ordinals, si veda:
Ordinals: un terreno comune per i massimalisti di Ethereum e Bitcoin?
La guida definitiva agli Ordinals e Inscriptions di Bitcoin
Binding bidirezionale di qualsiasi catena UTXO: binding isomorfo RGB++
RGB++ è originariamente emerso come protocollo di binding isomorfo (isomorphic binding protocol) tra BTC e CKB (la base di Nervos Network), ora ha un campo di applicazione molto ampio, non limitato solo a CKB e BTC, ma teoricamente può essere utilizzato per legare insieme qualsiasi due catene UTXO.
RGB++ ha ulteriormente sviluppato le idee di validazione lato client e sigilli a uso singolo. Come accennato, il principale problema del protocollo RGB è che i dati sono memorizzati localmente dall'utente. Se l'utente perde accidentalmente i dati, non c'è backup e non possono essere recuperati. Inoltre, poiché l'utente conserva solo i dati relativi ai propri token, risulta difficile convalidare altri dati. La soluzione del layer di binding isomorfo è non solo legare i token al campo OP_RETURN di un UTXO di Bitcoin, ma anche legare le informazioni di transazione di Bitcoin corrispondenti alla transazione sulla catena CKB (implementata utilizzando uno script di blocco IB-lock-script speciale nel Lock Script della cella CKB). Quando si determina se una transazione sulla CKB è valida, il Lock Script utilizzerà i dati del client leggero BTC sulla CKB per vedere se il corrispondente UTXO è stato speso e se il nuovo UTXO generato è legato alle informazioni di transazione del token attuale (come parte delle informazioni non firmate).
Caratteristiche degne di nota di RGB++:
Risolvere il problema della disponibilità dei dati tramite binding bidirezionale:
La promessa della cella CKB è legata al campo OP_RETURN di UTXO
Le informazioni UTXO sono collegate all'output Cell della transazione CKB
Compatibile con la rete Lightning e Fiber Network (la rete Lightning basata su CKB)
Supporta più asset
Può essere collegato a qualsiasi catena UTXO
Per ulteriori informazioni su RGB++, si veda:
RGB++ Protocol Light Paper
La guida definitiva a RGB, RGB++ e Client-Side Validation
Per comprendere meglio i punti di forza e i limiti dei vari progetti, metteremo i progetti sopra menzionati nella tabella sottostante per un confronto. I principali indicatori a cui prestare attenzione sono:
Disponibilità dei dati (Data availability): le catene isomorfe (isomorphic-chain) e le sidechain sono simili, mentre la disponibilità dei dati off-chain è inferiore rispetto ad altre soluzioni. La classificazione da forte a debole è: on-chain ≥ catena isomorfa ≥ sidechain > off-chain;
Portatore di asset (Asset carrier): i progetti di token direttamente associati a BTC sono superiori a quelli non direttamente associati;
Fungibilità (Fungibility): qui si riferisce alla possibilità di scambiare i token nativi del progetto, non significa che il progetto non supporti l'emissione di NFT, cosa che può essere realizzata tramite protocolli aggiuntivi;
Espressività (Expressiveness): si riferisce alla capacità di gestire contratti intelligenti complessi.
