Autorul acestui articol: Yunwen Liu 1, Institutul Mysterium
Știu că, atunci când se discută acest subiect, puriștii bitcoin ar putea crede: nu ar fi mai bine ca bitcoinul să fie simplu un aur digital? De ce trebuie să existe tokenuri? De ce neapărat USDT? Totuși, dacă ești foarte preocupat de siguranța activelor, trebuie să te gândești, ce se întâmplă dacă Ethereum dă faliment? Cine va prelua DeFi? În plus, schemele de tokenuri sunt compatibile cu protocolul bitcoin și nu vor distruge funcționalitatea originală, iar dacă nu îți place, poți să nu descarci clientul de tokenuri și nu vei fi afectat semnificativ.
De ce nu se pot emite tokenuri pe bitcoin?
Emiterea de tokenuri pe bitcoin pentru a transfera tranzacțiile activelor din lumea reală pe lanț a fost o idee apărută în comunitatea bitcoin în jurul anului 2010. Discuțiile inițiale din comunitate au sugerat mutarea activelor din lumea reală - cum ar fi: proprietăți, acțiuni, monede fiat - pe bitcoin pentru tranzacții descentralizate. Totuși, datorită factorilor legali, transferul activelor precum proprietățile și acțiunile nu este atât de ușor. Chiar dacă îți plătești tokenul digital al casei tale altcuiva, guvernul s-ar putea să nu recunoască acest lucru, sau ar putea să nu schimbe automat certificatul de proprietate al casei, iar tu ai putea fi nevoit să plătești diverse taxe. În plus, nu poți tranzacționa liber pe lanț sub reglementare.
Prin urmare, o abordare mai atractivă este emiterea de tokenuri legate de o monedă stabilă, adică stablecoins. Stablecoins sunt diferite de NFT-uri, fiind în continuare tokenuri fungibile (fungible), doar că sunt distinse de bitcoinul original. Atunci când apar ca tokenuri, valoarea lor este determinată de prețul activelor din lumea reală pe care le reprezintă, neavând prețul original al monedei digitale (dacă prețul monedei digitale crește prea mult față de prețul activului, abandonarea activului nu este imposibilă). De aceea, tokenurile de pe bitcoin sunt de obicei exprimate în satoshi (Satoshi).
Transformarea monedelor digitale în tokenuri de active necesită rezolvarea a două probleme principale:
Cum să reprezentăm active din lumea reală folosind bitcoin;
Cum să stabilim reguli complexe de tranzacționare și contracte în limbajul de scripturi foarte limitat al bitcoin.
Conținutul de mai jos se concentrează pe cele două puncte de mai sus, oferind o sinteză a principalelor scheme de emitere de active bitcoin existente, comparându-le din perspective precum disponibilitatea datelor, transportul activelor, expresivitatea, scalabilitatea și altele.
Primul token pe bitcoin: monedele colorate
Cine a proiectat pentru prima dată un protocol de tokenuri pe bitcoin nu se mai știe, însă ideea a putut apărea în discuțiile de pe forumurile sau comunitățile bitcoin. Proiectul monedelor colorate (Colored Coin) a fost inițiat de Yoni Assia în 2012, când el a colaborat cu Vitalik Buterin, Lior Hakim, Meni Rosenfeld, Rotem Lev pentru a scrie (whitepaper-ul monedelor colorate), iar proiectul a început să funcționeze în 2013.
Funcționarea monedelor colorate implică marcarea unui satoshi ca o monedă specială, scriind informațiile legate de activ pe acest satoshi - acest proces se numește colorare. Poți colora un satoshi în diferite culori, aplicând diferite mărci (tag-uri), însă monedele din aceeași culoare nu pot fi diferențiate, de exemplu, un grup de satoshi colorați în dolari rămân fungibili. Protocoalele mai vechi foloseau câmpul nSequence, adăugând o marcă în nSequence-ul primului UTXO din tranzacție. Totuși, limita de stocare a nSequence-ului este de doar 4 octeți, astfel încât majoritatea designurilor de tokenuri ulterioare s-au mutat pe câmpul OP_RETURN, care poate stoca mai multe metadate.
Monedele colorate sunt menționate în principal pentru că sunt primul proiect de tokenuri pe bitcoin. Deoarece dezvoltarea proiectului nu a fost ideală și nu a fost adoptat pe scară largă, proiectul a fost treptat uitat. Problema cu care se confruntau monedele colorate era că funcționalitatea bitcoinului nu susținea această idee avansată, iar implementarea acesteia era foarte dificilă pentru a funcționa eficient și stabil. Aceasta ar putea fi și motivul pentru care Vitalik a evoluat către contrapartida bitcoinului, devenind atât de dedicat contractelor inteligente.
Deoarece monedele colorate există sub formă de satoshi, validarea acestora este similară cu validarea unei UTXO, necesitând descărcarea întregului lanț. Această problemă va fi rezolvată ulterior prin validarea pe client (client-side validation).
Emiterea de tokenuri prin OP_RETURN: Counterparty & Omni Layer
Spre deosebire de monedele colorate, Counterparty și Omni Layer (protocolul din spatele USDT) nu colorează direct satoshi, ci setează un UTXO cu valoare 0 în tranzacție, stocând metadatele în OP_RETURN-ul acestui UTXO. OP_RETURN poate stoca 80 de octeți, marcând UTXO-ul OP_RETURN ca fiind imposibil de cheltuit, iar adevăratul token este output-ul i-th înregistrat în OP_RETURN. Această output are de obicei valoarea de 0.00000546 BTC - valoarea minimă permisă de sistem, iar deoarece valoarea tokenului nu este legată de BTC, nu este necesar să se emită o valoare mai mare de 0.00000546 BTC.
Validarea acestor proiecte trebuie să fie efectuată pe lanț, iar metadatele sunt stocate pe lanț.
Omni Layer a fost pentru o perioadă lungă de timp un jucător pe lanțul Ethereum, revenind abia recent în ecosistemul bitcoin pentru a emite BTC-USDT. Counterparty a blocat o parte din bitcoin, având propriul token XCP. Din ceea ce se vede pe Twitter, pare că recent lucrează la NFT-uri.
Pentru a înțelege mai bine OP_RETURN, consultați:
O analiză a metadatelor OP RETURN din bitcoin
Construirea manuală a OP_RETURN pentru a trimite USDT 1
Ancorarea bitcoinului prin lanțuri laterale: Rootstock & Liquid Network
Proiectele Rootstock și Liquid Network au apărut în jurul anului 2017, ambele fiind soluții de lanț lateral - folosind ancorarea bidirecțională (Two-way peg) pentru a transfera bitcoin pe un lanț lateral și a utiliza diverse Defi și dApps pe un lanț lateral compatibil EVM. Acestea au tokenuri similare cu WBTC (RSK are RBTC, Liquid are L-BTC), fiind în principal destinate celor care doresc să construiască folosind BTC în ecosistemul Ethereum.
Emiterea de tokenuri pe Rootstock este similară cu emiterea pe Ethereum, sau se poate spune că acest lanț lateral, în afară de minerit, este adaptat pentru ecosistemul Ethereum, de exemplu, codul contractelor inteligente este scris în Solidity. Așadar, tokenurile de aici sunt emise pe baza RBTC și nu au legătură directă cu BTC.
Deoarece acest articol se concentrează în principal pe lanțuri publice, iar Liquid Network este un lanț de consorțiu, nu vom discuta în detaliu.
Pentru a înțelege mai bine RSK, consultați
RSK: O rețea laterală bitcoin cu contracte inteligente stateful (documentul RSK)
Banii RSK
Întrebări frecvente (FAQs)
Proiectele menționate anterior au avut soarta diferită (unele au dispărut, cum ar fi monedele colorate), în timp ce altele au vândut sub umbrela bitcoin, dar au fost bazate pe ecosistemul Ethereum. Aceasta se datorează în principal faptului că Ethereum, după ce a îmbrățișat capitalul, a obținut o supremație absolută pe piața DeFi și dApps, astfel că proiectele DeFi care nu colaborează cu acesta au avut dificultăți în a câștiga avantaje. Tokenurile de pe Ethereum sunt emise și tranzacționate prin contracte, respectând standarde precum ERC-20. Ecosistemul bitcoin a început, de asemenea, să deblocheze funcționalitatea contractelor în ultimii doi ani, cum ar fi BitVM, iar standardul de tokenuri BRC-20 a început să apară.
Implementarea contractelor inteligente pe bitcoin: RGB
RGB (Really Good for Bitcoin), născut în 2016, a fost inițial proiectat ca un competitor pentru monedele colorate. Dar, în fața provocărilor similare, s-a îndreptat spre activarea contractelor inteligente pe bitcoin. Deși se concentrează pe rularea contractelor inteligente, nu pe emiterea de tokenuri, din cauza limitărilor mașinii sale virtuale AluVM, funcționalitatea completă a contractelor rămâne limitată până în 2024.
Ideea RGB este de a plasa datele disponibile off-chain și codul contractelor inteligente în afara bitcoin, folosind rădăcina Merkle pentru a oferi o promisiune (commitment) de validare a tranzacțiilor și emitere de tokenuri, lanțul bitcoin fiind responsabil doar pentru validarea promisiunilor tranzacțiilor și finalitatea acestora, demonstrând că nu au apărut cheltuieli duble.
Un aspect de menționat despre RGB este utilizarea simultană a validării pe client și a sigiliilor de utilizare unică, astfel încât nu marchează UTXO pentru a indica tokenurile. Aceste două concepte au fost introduse pentru prima dată de Peter Todd în 2013, iar Giacomo Zucco și Maxim Orlovsky au proiectat protocolul RGB pe această bază.
Validarea pe client (Client-side validation) permite ca datele și codul utilizate în tranzacții să fie păstrate off-chain, fără a fi difuzate public, unele date fiind schimbate doar între părțile tranzacției, iar altele, care nu sunt legate de tranzacție, putând să nu fie conștiente de acestea. Starea off-chain este întreținută de bitcoin, blockchainul având rolul de marcaj temporal, demonstrând ordinea temporară a stării.
Și sigiliul de utilizare unică (single-use seal) - care este și cel mai frecvent întâlnit în validarea pe client - este o versiune digitală a unui sigiliu de utilizare unică. Acesta profită de natura fiecărui UTXO care poate fi cheltuit o singură dată, scriind informațiile stării off-chain într-un UTXO. Astfel, dacă la un moment dat acest UTXO este cheltuit, știm că starea a fost actualizată, iar informațiile stării actualizate sunt scrise în noul UTXO generat. Aceste informații de stare off-chain pot fi proprietatea unui token USDT sau câte tokenuri sunt în cadrul unui anumit contract.
De exemplu, dacă Alice dorește să-i transfere lui Bob un USDT, acest USDT nu există pe lanțul bitcoin, informațiile sale fiind întreținute off-chain, dar acesta va fi legat de un UTXO controlat de Alice. Informațiile sale sunt păstrate în tranzacția care a generat acest UTXO, în câmpul OP_RETURN al UTXO-ului cu valoare zero. Astfel, doar Alice poate cheltui acest USDT, iar Bob poate urmări prin tranzacțiile de pe lanț unde a fost păstrat acest USDT în tranzacțiile anterioare, dacă aceste UTXO sunt valide și dacă tranzacția este legală. Astfel, când Alice inițiază o tranzacție, mutând informația promisiunii acestui USDT într-un UTXO controlat de Bob, acesta poate fi sigur că a obținut acest USDT.
RGB poate rula și pe rețeaua Lightning, deoarece starea sa este off-chain, fiind necesar doar să plaseze promisiunea pe lanț sau pe rețeaua Lightning. După actualizarea Taproot, RGB poate încorpora promisiunea într-o tranzacție Taproot, ceea ce îi permite să integreze promisiunea într-un mod mai flexibil pe lanțul bitcoin.
Pentru a înțelege mai bine RGB, consultați:
RGB Blueprint 1
Suportă doar tokenuri, nu contracte inteligente: Active Taproot
Asset-ul Taproot este un proiect dezvoltat de echipa Lightning Network Daemon (LND). Principiul său este similar cu RGB, dar nu suportă contracte inteligente complexe, ci doar tokenuri (consultați explicația termenului Taproot aici).
Pentru a înțelege mai bine validarea pe client, RGB și Taproot, consultați
Validarea pe client
Tranzacții off-chain: Evoluția protocoalelor de active bitcoin
Counterparty vs RGB vs TARO
Fiecare satoshi devine unic: Ordinals & Inscriptions
Casey Rodarmor a lansat protocolul Ordinal la începutul anului 2023. Acest proiect a venit inițial dintr-o idee: cum să numerotezi satoshi, astfel încât fiecare satoshi să aibă un număr de serie unic pentru a fi ordonat. Această idee a apărut în același timp cu monedele colorate, fiind reintrodusă abia anul trecut. Datorită adăugării funcționalităților SegWit și Taproot, implementarea sa a devenit mai puțin dificilă. Ordinal face ca fiecare satoshi să fie diferit, permițând astfel NFT-urile să fie emise direct pe lanțul bitcoin.
Inscriptions este un astfel de proiect NFT. Datele NFT-ului sunt stocate în datele martorului tranzacției, nu în câmpul OP_RETURN utilizat anterior de proiecte, permițând astfel stocarea metadatelor de până la 4MB. Spre deosebire de NFT-urile de pe Ethereum, Inscriptions sunt stocate pe lanț, incluzând metadatele și imaginile.
Pentru a înțelege mai bine ordinals, consultați:
Ordinals: Un punct comun pentru maximalistii Ethereum și Bitcoin?
Ghidul suprem pentru Ordinals și Inscriptions pe bitcoin
Legarea bidirecțională a oricărui lanț UTXO: legarea izomorfă RGB++
RGB++ a fost inițial creat ca un protocol de legare izomorfă (isomorphic binding protocol) între BTC și CKB (baza Nervos Network), iar acum domeniul său de aplicare este foarte larg, nefiind limitat doar la CKB și BTC, orice două lanțuri UTXO pot fi teoretic legate între ele folosind acest protocol.
RGB++ a extins ideea de validare pe client și de sigilii de utilizare unică. Așa cum am menționat anterior, problema principală a protocolului RGB este că datele sunt păstrate local de utilizatori. Dacă utilizatorul pierde accidental datele, nu există backup și nu pot fi recuperate. Mai mult, deoarece utilizatorul păstrează doar datele legate de tokenurile sale, verificarea altor date devine mai dificilă. Soluția de legare izomorfă nu leagă doar tokenurile de câmpul OP_RETURN al UTXO-ului bitcoin, ci leagă, de asemenea, informațiile tranzacției bitcoin corespunzătoare în tranzacția de pe lanțul CKB (prin utilizarea unui script IB-lock-script special în Lock Script-ul CKB Cell). Când se judecă legalitatea tranzacției de pe lanțul CKB, Lock Script va utiliza datele clientului light BTC de pe CKB pentru a verifica dacă UTXO-ul corespunzător a fost cheltuit și dacă UTXO-ul nou generat este legat de informațiile tranzacției tokenurilor.
Caracteristicile notabile ale RGB++:
Rezolvarea problemei disponibilității datelor prin legătura bidirecțională:
Angajamentul CKB Cell legat de câmpul OP_RETURN al UTXO
Informațiile UTXO legate de output Cell-ul tranzacției CKB
Compatibil cu rețeaua Lightning și Fiber Network (rețeaua Lightning bazată pe CKB)
Suportă multiple active
Poate fi legat de orice lanț UTXO
Pentru a înțelege mai bine RGB++, consultați:
RGB++ Protocol Light Paper
Ghidul suprem pentru RGB, RGB++ și validarea pe client
Pentru a înțelege mai clar avantajele și limitările fiecărui proiect, am comparat proiectele menționate mai sus în tabelul de mai jos. Indicatorii de care trebuie să ne concentrăm sunt:
Disponibilitatea datelor (Data availability): lanțurile izomorfe (isomorphic-chain) și lanțurile laterale au o diferență neglijabilă, în timp ce disponibilitatea datelor off-chain este mai slabă decât alte soluții. Clasificarea de la cele mai puternice la cele mai slabe este: on-chain ≥ lanț izomorf ≥ lanț lateral > off-chain;
Transportul activelor (Asset carrier): schemele de tokenuri direct asociate cu BTC sunt superioare celor non-direct asociate;
Fungibilitatea (Fungibility): aici se referă la faptul dacă tokenul nativ al proiectului este interschimbabil, nu înseamnă că proiectul nu suportă emiterea de NFT-uri, care pot fi realizate prin adăugarea de protocoale suplimentare;
Expresivitatea (Expressiveness): se referă la capacitatea de a gestiona contracte inteligente complexe.
