Autorul acestui articol: Institutul Mi-Yuan Yunwen Liu
Știu că, atunci când se discută acest subiect, puriștii Bitcoin ar putea simți: nu ar fi mai bine ca Bitcoin-ul să rămână un simplu aur digital? De ce trebuie să existe tokeni? De ce neapărat USDT? Totuși, dacă îți pasă de siguranța activelor, trebuie să te gândești, ce se întâmplă dacă Ethereum-ul cedează? Cine va prelua DeFi? De asemenea, planurile de tokeni sunt compatibile cu protocolul Bitcoin și nu vor distruge funcționalitatea originală; dacă nu îți place, poți alege să nu descarci clientul de tokeni, fără a fi afectat semnificativ.
Emiterea de tokeni pe Bitcoin: De ce nu?
Emiterea de tokeni pe Bitcoin, pentru a transfera tranzacțiile activelor din lumea reală pe lanț, această idee a apărut în comunitatea Bitcoin în jurul anului 2010. Discuțiile inițiale din comunitate au presupus mutarea activelor din lumea reală - cum ar fi proprietăți, acțiuni, monedă fiat - pe Bitcoin pentru tranzacții descentralizate. Totuși, din cauza factorilor legali, transportul activelor precum proprietățile și acțiunile nu este atât de simplu. Chiar dacă îți transferi tokenul digital al casei tale unei alte persoane, guvernul s-ar putea să nu recunoască acest lucru sau ar putea schimba automat certificatul de proprietate din lumea reală, iar tu ai putea fi nevoit să plătești diverse taxe. În plus, sub supraveghere, nu poți face tranzacții pe lanț fără restricții.
Astfel, metoda mai atrăgătoare este emiterea de tokeni legați de un stablecoin. Stablecoin-urile sunt diferite de NFT-uri, deoarece rămân tokeni fungibili, doar că sunt diferite de Bitcoin-ul original. Când apar ca tokeni, valoarea lor este determinată de prețul activului din lumea reală pe care îl reprezintă, fără a mai avea prețul original al criptomonedelor (dacă prețul criptomonedelor crește prea mult față de prețul activului, abandonarea activului nu este imposibilă). De aceea, tokenii pe Bitcoin sunt de obicei exprimați în Satoshi.
Transformarea criptomonedelor în tokeni de active necesită rezolvarea a două probleme principale:
Cum să reprezentăm activele din lumea reală folosind Bitcoin;
Cum să stabilim reguli de tranzacționare și contracte complexe în limbajul de scriptare extrem de limitat al Bitcoin-ului.
Conținutul de mai jos se concentrează pe cele două puncte de mai sus, oferind un rezumat al principalelor scheme de emitere a activelor Bitcoin și comparându-le din perspective precum disponibilitatea datelor, transportatorul de active, expresivitatea, scalabilitatea etc.
Primul token pe Bitcoin: monedele colorate
Nu se știe cine a fost primul care a proiectat un protocol de tokeni pe Bitcoin, idee care ar fi putut apărea în discuții pe forumurile sau comunitățile Bitcoin. Proiectul monedelor colorate (Colored Coin) a fost inițiat de Yoni Assia în 2012, când a colaborat cu Vitalik Buterin, Lior Hakim, Meni Rosenfeld și Rotem Lev pentru a scrie (whitepaper-ul monedelor colorate), iar proiectul a început să funcționeze în 2013.
Funcționarea monedelor colorate este de a marca un Satoshi ca o monedă specială, scriind informațiile relevante ale activului în cadrul acestui Satoshi - acest proces se numește colorare. Poți colora un Satoshi în diferite culori, aplicând diferite etichete (tag), dar monedele din aceeași culoare rămân indistincte, de exemplu, un grup de Satoshis colorați în dolari rămân fungibili. Protocolele mai vechi au folosit câmpul nSequence, adăugând o etichetă în nSequence-ul primului UTXO de intrare al tranzacției. Totuși, limita de stocare pentru nSequence este de doar 4 bytes, astfel încât proiectele de tokeni ulterioare au trecut în mare parte la câmpul OP_RETURN, care poate stoca mai multe metadate.
Monedele colorate sunt menționate în principal pentru că sunt primul proiect de token 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 confrunta monedele colorate este că funcționalitatea Bitcoin-ului nu putea susține această idee avansată, iar implementarea și funcționarea eficientă a acesteia a fost foarte dificilă. Acesta ar putea fi și motivul pentru care Vitalik s-a îndreptat spre contrasensul Bitcoin-ului după proiectul monedelor colorate, devenind atât de dedicat contractelor inteligente.
Deoarece monedele colorate există sub formă de Satoshis, validarea lor necesită descărcarea întregului lanț, la fel ca validarea unui UTXO. Această problemă va fi rezolvată ulterior prin validarea pe client (client-side validation).
Emiterea de tokeni prin OP_RETURN: Counterparty & Omni Layer
Spre deosebire de monedele colorate, Counterparty și Omni Layer (protocolul din spatele USDT) nu colorează direct Satoshis, ci stabilesc un UTXO cu o valoare de 0 în tranzacție, stocând metadatele în OP_RETURN-ul acestui UTXO. OP_RETURN poate stoca 80 de bytes, marcând UTXO-ul OP_RETURN ca fiind cheltuit, iar adevăratul token este output-ul i-th înregistrat în OP_RETURN. Această valoare de output este de obicei 0.00000546 BTC — valoarea minimă permisă pentru trimitere, și deoarece valoarea tokenului nu este legată de BTC, nu este necesară emiterea unei valori mai mari decât 0.00000546 BTC.
Validarea acestor proiecte trebuie efectuată pe lanț, iar metadatele sunt stocate pe lanț.
Omni Layer a fost un jucător pe lanțul Ethereum timp de multă vreme, revenind recent în ecosistemul Bitcoin, pregătindu-se să emită BTC-USDT. Counterparty a pus în garanție o parte din Bitcoin, având propriul său token XCP. Din ceea ce am văzut pe Twitter, pare că recent s-au concentrat pe NFT-uri.
Pentru a afla mai multe despre OP_RETURN, consultați:
O analiză a metadatelor Bitcoin OP RETURN
Construirea manuală a OP_RETURN pentru a trimite USDT
Ancorarea Bitcoin-ului prin lanțuri laterale: Rootstock & Liquid Network
Rootstock și Liquid Network au apărut în jurul anului 2017, ambele fiind soluții side-chain - folosind metoda de ancorare bidirecțională (Two-way peg) pentru a înlocui Bitcoin-ul pe lanțul lateral și a utiliza diverse Defi și dApps pe un lanț lateral compatibil cu EVM. Ele au tokeni similari cu WBTC (RSK are RBTC, Liquid are L-BTC), destinat în principal celor care doresc să construiască pe ecosistemul Ethereum cu BTC.
Emiterea de tokeni pe Rootstock este similară cu emiterea pe Ethereum, sau se poate spune că Rootstock, ca lanț lateral, are majoritatea funcțiilor adaptate pentru ecosistemul Ethereum, scriind coduri de contracte inteligente în Solidity. Astfel, tokenii de aici sunt emisi pe baza RBTC, fără a fi legați direct de BTC.
Deoarece acest articol se concentrează în principal pe lanțurile publice, iar Liquid Network este un lanț de tip consorțiu, nu vom discuta în detaliu.
Pentru a afla mai multe despre RSK, consultați
RSK: O lanț lateral Bitcoin cu contracte inteligente stateful (documentul RSK)
Banii RSK
AQs
Implementarea contractelor inteligente pe Bitcoin: RGB
RGB (Really Good for Bitcoin), născut în 2016, a fost inițial conceput ca un competitor al monedelor colorate. Dar, în fața unor provocări similare, s-a orientat spre activarea contractelor inteligente pe Bitcoin. Deși se concentrează mai mult pe rularea contractelor inteligente decât pe emiterea de tokeni, din cauza limitărilor mașinii 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 codurile contractelor inteligente în afara Bitcoin-ului, utilizând rădăcina Merkle pentru a oferi validarea tranzacțiilor și promisiunea emiterii de tokeni (commitment), lanțul Bitcoin efectuează doar validarea promisiunii tranzacției și finalitatea, demonstrând că nu a existat dublă cheltuire.
Un aspect demn de menționat despre RGB este că folosește atât validarea pe client, cât și tehnologia sigiliilor de utilizare unică, astfel încât nu marchează tokenii pe UTXO. Aceste două concepte au fost propuse inițial 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 codurile utilizate în tranzacții să fie păstrate off-chain, fără a fi difuzate public; unele date pot fi schimbate doar între părțile implicate în tranzacție, iar alte persoane care nu sunt legate de tranzacție pot să nu știe nimic. Statutul off-chain este menținut prin Bitcoin, blockchain-ul acționând ca un marcator temporal, demonstrând ordinea stărilor.
Un sigiliu de utilizare unică (single-use seal) - este de asemenea cea mai comună formă de validare pe client - este o versiune digitală a unui sigiliu de utilizare unică. Profitând de faptul că fiecare UTXO poate fi cheltuit o singură dată, informațiile despre starea off-chain sunt scrise în cadrul unui UTXO. Astfel, dacă la un moment dat acest UTXO este cheltuit, știm că starea a fost actualizată, iar informațiile actualizate sunt scrise în noul UTXO generat. Această informație de stare off-chain poate fi proprietatea tokenului USDT sau cantitatea de tokeni dintr-un anumit contract.
De exemplu, dacă Alice vrea să transfere un USDT lui Bob, acest USDT nu există pe lanțul Bitcoin, informațiile sale sunt gestionate off-chain, dar se leagă de un UTXO controlat de Alice. Informațiile sunt stocate în OP_RETURN-ul UTXO-ului cu valoarea zero generat de această tranzacție. Astfel, doar Alice poate cheltui acest USDT, iar Bob poate urmări tranzacția pe lanț pentru a vedea în ce UTXO-uri a fost salvat acest USDT, dacă aceste UTXO-uri sunt valide și dacă tranzacția este legală. Astfel, când Alice inițiază tranzacția mutând informațiile de promisiune ale acestui USDT într-un UTXO controlat de Bob, Bob poate fi sigur că a obținut acest USDT.
RGB poate funcționa și pe Lightning Network, deoarece starea sa este off-chain, fiind suficient să plasezi promisiunea pe lanțul principal sau pe Lightning Network. După actualizarea Taproot, RGB poate încorpora promisiunea într-o tranzacție Taproot, permițând RGB să integreze promisiunea pe lanțul Bitcoin într-un mod mai flexibil.
Pentru a afla mai multe despre RGB, consultați:
RGB Blueprint
Suportă doar tokeni, nu contracte inteligente: active Taproot
Taproot asset 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 tokeni (consultați explicația referitoare la termenul Taproot aici).
Pentru a afla mai multe despre Validarea pe Client-Side, RGB și Taproot, consultați
Validarea pe Client-Side
Tranzacții Off-Chain: Evoluția Protocolului de Active Bitcoin
Counterparty vs RGB vs TARO
Făcând fiecare Satoshi să fie unic: Ordinals & Inscriptions
Casey Rodarmor a lansat protocolul Ordinal la începutul anului 2023. Acest proiect a apărut inițial dintr-o idee: cum să numerotăm fiecare Satoshi pentru a avea un număr de serie unic prin care să fie ordonat. Această idee a fost contemporană cu monedele colorate, dar a fost reluată abia anul trecut. De asemenea, 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, ceea ce permite emiterea directă a NFT-urilor 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 folosit de proiectele anterioare, permițând stocarea de metadate de până la 4MB. Spre deosebire de NFT-urile de pe Ethereum, Inscription este stocată pe lanț, incluzând metadatele și imaginea.
Pentru a afla mai multe despre ordinals, consultați:
Ordinals: Un teren comun pentru maximalistii Ethereum și Bitcoin?
Ghidul Ultimativ pentru Ordinals și Inscriptions pe Bitcoin
Legătura bidirecțională a oricărui lanț UTXO: RGB++ legare izomorfă
RGB++ a apărut inițial ca protocol de legare izomorfă î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 teoretic să fie legate prin acest protocol.
RGB++ a extins ideea de Validare pe Client-Side și Single-Use-Seals. Așa cum s-a menționat anterior, cea mai mare problemă a protocolului RGB este că datele sunt stocate local de utilizator. Dacă un utilizator pierde din neatenție datele, nu există backup și nu pot fi recuperate. De asemenea, deoarece utilizatorul salvează doar datele legate de tokenii săi, verificarea altor date devine mai dificilă. Soluția straturilor izomorfe este nu doar să legăm tokenii de câmpul OP_RETURN al UTXO-ului Bitcoin, ci și să legăm informațiile tranzacției Bitcoin corespunzătoare în tranzacțiile de pe lanțul CKB (prin utilizarea unui script IB-lock-script special în Lock Script-ul CKB Cell). Atunci când se determină dacă tranzacția de pe lanțul CKB este validă, Lock Script-ul folosește 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 token-ului în cauză (ca parte a informației fără semnătură).
Caracteristicile notabile ale RGB++:
Rezolvarea problemelor de disponibilitate a datelor prin legătura bidirecțională:
Promisiunea CKB Cell legată de câmpul OP_RETURN al UTXO
Informațiile UTXO legate de celula de output a tranzacției CKB
Compatibil cu Lightning Network și Fiber Network (Lightning Network bazat pe CKB)
Susține active multiple
Poate fi legat de orice lanț UTXO
Pentru a afla mai multe despre RGB++, consultați:
RGB++ Protocol Light Paper
Ghidul Ultimativ pentru RGB, RGB++ și Validarea pe Client-Side
Pentru a înțelege mai clar avantajele și limitările fiecărui proiect, am comparat proiectele de mai sus în tabelul de mai jos. Indicatorii pe care trebuie să ne concentrăm sunt:
Disponibilitatea datelor (Data availability): lanțurile izomorfe (isomorphic-chain) și lanțurile laterale (side-chain) sunt aproape egale, în timp ce disponibilitatea datelor off-chain este mai slabă decât alte soluții. Ordinea de la puternic la slab este: pe lanț ≥ lanț izomorf ≥ lanț lateral > off-chain;
Transportator de active (Asset carrier): schemele de tokeni asociate direct cu BTC sunt superioare celor care nu sunt asociate direct;
Fungibilitate (Fungibility): aici se referă la faptul că tokenii nativi ai proiectului pot fi interschimbați între ei, nu înseamnă că proiectul nu suportă emiterea de NFT-uri, acesta din urmă putând fi realizat prin adăugarea unui protocol suplimentar;
Expresivitate (Expressiveness): se referă la capacitatea de a gestiona contracte inteligente complexe.
