Titlul original: „The True Potential of RGB” Autor original: A Jian

Acest articol încearcă să ofere o descriere concisă a RGB, un protocol de emitere a activelor pe Bitcoin (de asemenea, poate fi înțeles ca un sistem de contract inteligent în afara lanțului) și subliniază că este foarte diferit de alte protocoale care urmăresc să realizeze același lucru. sau funcții similare Aceste diferențe fac protocolul RGB mult mai scalabil decât ele și lasă un spațiu de programare mai larg. Pe lângă introducerea modelelor complete ale RGB, vom explora și aceste posibilități de programare1.

Ce este protocolul RGB?

Ideea de a emite active pe Bitcoin există de mult timp 2 3 . Dar protocolul Bitcoin are propriile sale caracteristici 4: starea sa este exprimată de și numai Bitcoin UTXO („ieșirea tranzacției necheltuite” un UTXO transportă doar două date: propria sa denumire (valoarea Bitcoin) și O „cheie publică de script” (); numit și „script de blocare”), folosit pentru programarea condițiilor de cheltuire a fondurilor, de exemplu: furnizarea unei semnături a unei anumite chei publice, opcode-ul care permite programarea scriptului de blocare este determinat de regulile de consens Bitcoin; nu pot fi folosite pentru a implementa reguli de securitate arbitrare. Prin urmare, este imposibil să se creeze alte active în interiorul UTXO - scripturile Bitcoin nu pot programa verificări de securitate pentru aceste active. Aceasta înseamnă că toate ideile pentru emiterea de active pe Bitcoin sunt, în esență, utilizări creative ale spațiului bloc Bitcoin. Aceasta înseamnă că trebuie să proiectăm un sistem de contract inteligent în afara lanțului și să cerem informații despre pașii care schimbă starea contractului - de exemplu, contractul A modifică parametrii, iar B transferă o anumită cantitate dintr-un activ către C. Încărcați în blockchain. , astfel încât cel mai recent statut al acestui sistem de contract inteligent să poată fi obținut prin colectarea acestor informații.

O idee brută de design este să încărcați informațiile pașilor care schimbă starea contractului în blockchain-ul Bitcoin intact. Acest lucru poate funcționa cu siguranță, dar se va confrunta cu mai multe probleme: (1) Deoarece sunt încărcate informații complete, este posibil să consume mai mult spațiu de bloc atunci când utilizatorul trebuie să schimbe starea contractului (cum ar fi transferul) În acest moment, veți, de asemenea, trebuie să plătească mai multe taxe de manipulare în lanț. În special, atunci când sperăm că un astfel de sistem de contract în afara lanțului are o programabilitate mai bună decât Bitcoin, creșterea programabilității se poate produce în detrimentul consumului de mai mult spațiu în bloc (2) Aproape orice tranzacție din bloc Informațiile într-un singur loc se pot schimba contracte inteligente în afara lanțului Prin urmare, utilizatorii trebuie să obțină toate numerele de bloc Bitcoin. Conform datelor, putem obține cel mai recent statut al acestui sistem de contract în afara lanțului, adică costul de verificare este mai mare (3) În funcție de designul sistemului de contract inteligent în afara lanțului, este posibil să putem doar să o facem obțineți aceeași confidențialitate ca Bitcoin, sau chiar mai rău, și dacă se poate oferi mai multă confidențialitate, se poate consuma mai mult spațiu.

În trecut, un protocol utilizat pe scară largă numit „Omni” nu încărca informații complete despre tranzacțiile contractuale în afara lanțului, ci doar valoarea hash a tranzacției. Această abordare rezolvă problema 1 de mai sus și decuplează complexitatea tranzacțiilor contractuale în afara lanțului de costurile sale economice, totuși, utilizatorii trebuie să obțină întreaga cantitate de date de bloc Bitcoin pentru a obține, în plus, cel mai recent statut al protocolului Omni; nu Nu există o îmbunătățire specifică a confidențialității.

RGB folosește o nouă paradigmă numită „sigilii de unică folosință”. Utilizarea sa este foarte simplă: RGB necesită ca fiecare stare a fiecărui contract să fie atașată la un anumit Bitcoin UTXO și odată ce doriți să schimbați această stare, trebuie să cheltuiți acest UTXO și să lăsați tranzacția care îl cheltuiește să primească confirmarea blockchain-ului; În plus, tranzacția Bitcoin care o cheltuiește trebuie să ofere și un hash al conținutului tranziției de stat, indicând UTXO atașat stării modificate.

Pentru dezvoltatorii RGB, designul este similar cu un sigiliu din plastic numerotat: este ușor de spus dacă a fost îndepărtat și, odată ce este îndepărtat, nu poate fi reutilizat. Cu toate acestea, o altă perspectivă este să priviți UTXO posedat ca un container în această stare sau o pușculiță ceramică - dacă doriți să scoateți banii din pușculiță, trebuie să spargeți pușculița și apoi să puneți conținutul înăuntru Puneți banii în borcanul nou.

Acest design este în contrast puternic cu protocoalele anterioare care tratau întregul bloc ca pe o tablă mare de scris: utilizarea UTXO ca container înseamnă că tranzacțiile care nu cheltuiesc acest UTXO nu pot avea niciun impact asupra stării contractului în container o anumită stare a unui anumit contract, nu avem nevoie să obținem datele tuturor blocurilor Tot ce avem nevoie este o serie de tranzacții Bitcoin, dovezi că aceste tranzacții Bitcoin există într-un anumit bloc și acești biți RGB promisi de schimbul de monede. Tranziția de stat (pereche unu-la-unu cu tranzacții Bitcoin aferente), asta este. Aceste date, care pot fi conectate într-un lanț, ar trebui să ne permită să urmărim până la starea inițială a acestui contract, permițându-ne să identificăm esența acestei stări.

Pentru cititorii care sunt familiarizați cu sistemele de contracte inteligente în lanț (cum ar fi Ethereum), un lucru care este greu de înțeles despre acest proces este că, dacă nu se bazează pe consensul blockchain-ului (ceea ce înseamnă că starea inițială a contract și fiecare schimbare de stat va fi verificată de fiecare nod), cum este garantată securitatea acestui sistem de contract inteligent? Cum să vă asigurați că activele pe care le primiți sunt cele pe care le doriți și cum să vă asigurați că activele nu au fost emise ilegal?

Răspunsul este, de asemenea, foarte simplu, se numește „validare pe partea clientului” - îl verificați singur. În sistemul de contract în lanț, nodurile verifică fiecare operațiune de tranziție de stat în conformitate cu regulile de tranziție a statului public, resping operațiunile nevalide și apoi calculează cea mai recentă stare pe baza stării inițiale. Cu toate acestea, atâta timp cât regulile de tranziție de stat și starea inițială sunt cunoscute, verificarea prin consens în lanț nu este singura modalitate. Utilizatorii pot verifica dacă fiecare pas al tranziției de stat urmează tranziția de stat definită inițial pe baza informațiilor furnizate de regula plătitorului. În acest fel, partea de verificare (presupusă a fi destinatarul bunului) poate, de asemenea, să detecteze tranziții ilegale de stat și să refuze să le accepte.

În cele din urmă, folosim un exemplu pentru a demonstra caracteristicile protocolului RGB:

Acum, Alice deține UTXO A, care deține X unități de activ Y emise conform protocolului RGB. Ea vrea să transfere Z unități ale lui Bob. Acest lot de active a trecut printr-un total de 5 proprietari anteriori (inclusiv emitentul de active) înainte de a ajunge în mâinile lui Alice. Prin urmare, Alice trebuie să îi furnizeze lui Bob dovezi ale acestor patru tranziții de stare (dintre care primele trei au fost furnizate Alicei de către proprietarul anterior), inclusiv starea inițială a contractului și regulile de tranziție de stat, precum și biții utilizați pentru fiecare transfer. Tranzacțiile Bitcoin, tranzacțiile RGB comise de fiecare schimb Bitcoin și dovezile că aceste tranzacții Bitcoin au fost confirmate de un anumit bloc sunt trimise lui Bob, vor verifica că aceste patru transferuri nu încalcă regulile de tranziție a contractului și apoi decideți dacă îl acceptați. Când Alice construiește o tranzacție RGB, deoarece Z este mai mic decât X, ea își aranjează și o UTXO pentru a primi partea rămasă. În cele din urmă, Alice încorporează valoarea hash a acestei tranzacții RGB într-o tranzacție Bitcoin care costă UTXO A’ pentru a finaliza plata.

În cele din urmă, datorită utilizării containerelor UTXO, cea mai recentă stare a unui contract RGB poate fi reprezentată ca un punct pe un grafic aciclic direcționat care nu are descendenți (fiecare punct reprezintă o stare stocată într-un container UTXO). Mai mult, pentru proprietarul P din figura de mai jos, el va cunoaște doar procesul din starea inițială G a contractului pentru a ajunge la el, adică procesul marcat de cercul roșu, și nu va ști nimic despre punctele gri:

Avantajele RGB

Stare ușoară verificabilă

După cum am menționat mai sus, în comparație cu protocoalele anterioare de emitere a activelor (sisteme contractuale în afara lanțului) care au apărut pe Bitcoin, RGB reduce semnificativ costul verificării (o anumită stare a unui contract). În timpul tranzacției, receptorul nu mai trebuie să străbată toate blocurile pentru a colecta informații despre modificările statutului contractului, ci trebuie doar să obțină o serie de tranzacții Bitcoin, precum și tranzacțiile RGB promise de aceste schimburi, precum și blocurile acestor Bitcoin. tranzacțiile conțin Dovezi (pe baza dovezilor Merkle din antetul blocului), puteți fi sigur că plătitorul deține cu adevărat o anumită sumă dintr-un anumit activ.

Această reducere a costurilor de verificare reduce, de asemenea, foarte mult dependența (încrederea) utilizatorilor față de furnizorii mari de infrastructură. În protocoalele anterioare, din cauza costurilor mari de verificare, utilizatorilor le era dificil să calculeze singuri cel mai recent statut al contractului, astfel încât utilizatorii trebuiau să aibă încredere în anumiți furnizori (cum ar fi furnizorul de statut al contractului utilizat în același timp de portofel); , pentru că și-ar putea permite astfel. Există mai puțini furnizori care să calculeze costurile, ceea ce înseamnă și centralizarea furnizorilor. Dar în RGB, utilizatorii își pot permite singuri folosind pur și simplu clientul Bitcoin light pentru a verifica partea care este tranzacționată cu Bitcoin și protocolul RGB pentru a verifica partea tranzacției RGB.

În comparație cu unele sisteme contractuale în lanț, RGB este și mai ușor. Acest lucru se reflectă în faptul că RGB poate verifica în mod specific o anumită stare a unui contract pe acele sisteme care nu sunt bazate pe UTXO, din cauza lipsei unui mecanism de control al accesului precum UTXO, orice tranzacție poate schimba orice stare, astfel încât; Este aproape imposibil să se verifice în mod specific o anumită stare, dar se poate determina doar o anumită stare în timp ce se calculează toate cele mai recente stări - în acest sens, caracteristicile exprimate ca „stare globală” ar trebui de fapt denumite „stare uniformă”. de stat)”, deși oferă caracteristica accesului încrucișat între contracte, de asemenea, determină că costul verificării acestuia va fi mai mare și va fi mai dificil de obținut neîncredere.

Pe aceste protocoale de contract în lanț, o măsură majoră de optimizare este de a solicita antetului blocului să se angajeze la cea mai recentă stare („rădăcină de stat”), permițând astfel clienților ușoare să verifice o anumită stare a unui contract obținut de la nodul complet pe baza aceste angajamente. Aceasta este o metodă de reutilizare a calculelor care au avut loc deja (calcule care au fost efectuate de către nodul complet) și este, de asemenea, foarte eficientă, așa că dacă nu este luată în considerare încrederea, poate fi considerată mai eficientă decât RGB. Cu toate acestea, înseamnă, până la urmă, că nodurile ușoare se bazează pe noduri complete pentru verificarea de bază a tranzacțiilor și calcularea stării contractului. În portofelul RGB care utilizează clientul Bitcoin light, ipoteza de încredere pe care se bazează este că tranzacția Bitcoin relevantă este o tranzacție validă, iar partea legată de starea contractului a fost verificată personal de către client, deci este mai multă încredere. liber. Dezavantajul este că întârzierea verificării este mai mare și trebuie păstrate mai multe date.

Scalabilitate

Scalabilitatea RGB se reflectă în două aspecte:

Încorporată în tranzacția Bitcoin este doar o valoare hash, ceea ce înseamnă că nu există nicio limită pentru dimensiunea tranzacției RGB (cu excepția regulilor personalizate ale contractului) - chiar dacă împărțiți un activ RGB în 100 de părți (tranzacția RGB în sine va fi foarte mare) și există o singură valoare hash care trebuie încorporată într-o tranzacție Bitcoin. După cum se menționează în Nota 6, există două moduri de a încorpora o astfel de valoare hash: una este de a utiliza ieșirea OP_RETURN, ceea ce înseamnă că va consuma spațiul în lanț al unei valori hash, cealaltă este de a ascunde ieșirea cheii publice de script; Taproot pe arborele de script comis - aceasta nu consumă niciun spațiu pe lanț. Acest lucru înseamnă, de asemenea, că utilizatorii nu trebuie să sacrifice economia pentru programabilitate - luând în considerare doar taxele în lanț.

Cea mai recentă stare a contractului RGB este un punct independent pe un grafic aciclic direcționat fără descendenți - aceasta înseamnă că aceste stări pot fi modificate independent, fără a se afecta reciproc, ceea ce înseamnă că este permisă concurența. Aceasta este de fapt o caracteristică moștenită de la UTXO. Acest lucru înseamnă, de asemenea, că modificările nevalide (tranzacțiile nevalide) care au loc pe o sucursală nu vor afecta alte sucursale, cu atât mai puțin să provoace blocarea întregului contract, deci poate fi considerat și un beneficiu de securitate.

Un punct care a fost criticat pentru scalabilitatea RGB este că fiecare transfer necesită ca destinatarul să verifice toate tranzacțiile implicate de la starea inițială până la starea plătitorului - pe măsură ce numărul de când activul își schimbă mâinile crește, sarcina de verificare asupra destinatarilor ulterioare crește va deveni din ce în ce mai greu. Această critică este adevărată. Optimizarea acesteia înseamnă că trebuie să găsim și o modalitate de a reutiliza operațiunile care au avut loc deja. Tehnologiile sistemelor de probă, cum ar fi SNARK-urile, dețin promisiunea de a oferi o astfel de soluție 7 .

Diferențierea definiției activelor și a mecanismului de custodie

Ultimul beneficiu este încă legat de UTXO și depinde de modul în care înțelegem mecanismul scriptului de blocare al UTXO.

Un script de blocare poate fi folosit pentru a programa condițiile de deblocare pentru un fond și, prin urmare, poate implementa reguli de custodie. De exemplu, dacă un script de blocare conține una și o singură cheie publică, asta înseamnă că numai proprietarul cheii private corespunzătoare o poate controla. Cu toate acestea, astfel de reguli de custodie sunt, de asemenea, baza pentru programarea protocolului de contract Bitcoin8. De exemplu, un UTXO care utilizează un script de blocare cu semnături multiple 2 din 2 ar putea fi un canal Lightning de-a lungul canalului, cele două părți se pot plăti reciproc un număr aproape nelimitat de ori fără nicio modificare a accesului; forma în lanț a fondurilor. Cu alte cuvinte, în acest moment, scriptul de blocare cu semnături multiple 2 din 2 constituie un mecanism de transfer de valoare care permite ambelor părți să transfere valoare fără a schimba forma fondurilor din lanț.

Un astfel de mecanism poate fi folosit pentru valoarea Bitcoin transportată de UTXO. Desigur, poate fi folosit și pentru activele RGB transportate de acesta. Putem emite un activ RGB și îl putem atașa la un UTXO cu semnături multiple 2 din 2, utilizând astfel mecanismul Lightning Channel pentru a plăti acest activ unul altuia de un număr nelimitat de ori de 9. În același mod, activele RGB pot fi introduse și în alte contracte bazate pe scripturi Bitcoin.

Aici, scriptul UTXO și protocolul RGB formează o diferențiere funcțională: primul se angajează să realizeze regulile de custodie și transfer de valoare, în timp ce cel din urmă se concentrează pe definirea activelor; Astfel, custodia bunurilor și definiția bunurilor pot fi separate. Aceasta este o îmbunătățire importantă a securității și ceva pentru care oamenii se străduiesc în alte sisteme contractuale în lanț.

Modele deja realizate de RGB

Proprietățile de mai sus sunt valabile pentru aproape toate protocoalele bazate pe sigilarea unică UTXO și verificarea la nivelul clientului. Dar pe această bază, protocolul RGB a fost proiectat în continuare.

În dezvoltarea actualului protocol RGB, dezvoltatorii sunt preocupați în special de confidențialitatea protocolului, astfel încât RGB întărește confidențialitatea în două aspecte:

UTXO orb. Într-o tranzacție RGB, destinatarul folosește pur și simplu identificatorul UTXO ofuscat pentru a primi activul fără a expune caracteristicile UTXO care a primit efectiv activul. Acest lucru nu afectează cu nimic capacitatea destinatarului de a furniza dovezi următorului proprietar, permițând în același timp destinatarilor ulterioare a activelor să se apere împotriva privirilor indiscrete ale proprietarului anterior al bunului.

Antiglont. Poate fi folosit pentru a ascunde suma specifică din fiecare tranzacție. Cu toate acestea, proprietarii de active ulterioare pot verifica în continuare că nu a mai avut loc nicio emisiune suplimentară înainte.

Spațiu de explorat

În această secțiune, voi discuta spațiul pe care protocolul RGB îl poate explora în continuare, legat în principal de programabilitate.

În prezent, șabloanele de contracte RGB (schema) care au fost propuse se concentrează pe emiterea de active. Cu toate acestea, deoarece RGB folosește o paradigmă de „validare la nivelul clientului”, putem adăuga de fapt orice caracteristică care poate fi asigurată cu validarea la nivelul clientului - limitat doar de structura UTXO.

Restricții

Pe baza UTXO, un concept care poate extinde programabilitatea se numește „covenants” 10. Intenția inițială a unei clauze de restricție este de a limita destinația către care poate fi transferată o sumă de bani. Cu această abilitate, putem programa multe aplicații interesante, cum ar fi:

Fond de fond pentru retrageri non-interactive. Putem pune în comun fondurile multor oameni în același UTXO și putem folosi restricții pentru a ne asigura că oricare dintre ei își poate retrage propriile fonduri fără ajutorul altora. Acest lucru poate avea efectul de a ajuta oamenii să părăsească locurile cu risc ridicat la costuri reduse atunci când cererea de spațiu de bloc este mare.

Contractul seifului. Un fond trebuie mai întâi cheltuit undeva și să treacă printr-o blocare de timp înainte de a putea fi cheltuit liber în perioada de blocare a timpului, proprietarul sigur poate întrerupe procesul cu o cheie de urgență și poate transfera imediat fondurile în alt loc. Acest dispozitiv poate fi de mare ajutor pentru custodia autonomă.

Scriptul Bitcoin actual nu are această capacitate, așa că activarea restricțiilor pentru Scriptul Bitcoin necesită o furcă moale.

Cu toate acestea, atâta timp cât suntem dispuși să sacrificăm unele dintre beneficiile aduse de „diferențierea definiției activelor și a mecanismelor de custodie”, putem experimenta astfel de funcții pe activele RGB. Putem implementa astfel de funcții la nivel de contract RGB - deși se poate doar Nu funcționează pentru activele RGB care îl folosesc (dar nu Bitcoin), dar cu siguranță va deschide un spațiu interesant.

Cercetările existente privind clauzele de restricție arată că poate extinde spațiul de programare al tranzacțiilor bazate pe UTXO și poate oferi multe caracteristici. Dar aceste studii se bazează practic pe Bitcoin, iar pe protocoale precum Bitcoin, vom fi mai conservatori. Pe RGB, putem generaliza cu îndrăzneală capacitățile de bază ale constrângerilor - abilitatea de a citi tranzacțiile care se cheltuiesc la nivel de script - pentru a oferi o programabilitate mai flexibilă: abilitatea de a încrucișa contractele de acces.

acces transversal

Termenii minim restrictivi înseamnă că atunci când un UTXO este cheltuit, scriptul său poate citi rezultatul tranzacției de cheltuieli. Dar restricția complet generală înseamnă că poate citi toate părțile tranzacției care a cheltuit-o. Aceasta înseamnă că poate citi și alte intrări ale tranzacției Dacă nu limităm alte intrări să provină din același contract, înseamnă că poate citi starea altor contracte.

În RGB, implicit că fiecare contract este un univers independent cu propriul său grafic aciclic direcționat. Cu toate acestea, este încă posibil ca un utilizator să dețină statutul a două contracte diferite în același timp. Astfel de capabilități de acces încrucișat ar putea avea cazuri de utilizare dacă tranzacțiile RGB ar permite cheltuirea simultană a activelor din ambele contracte (deși ar putea face verificarea tranzacțiilor mai complexă).

De fapt, există deja sisteme contractuale în lanț bazate pe structuri similare UTXO (de exemplu: Nervos Network), care folosesc acest lucru pentru a obține capabilități de acces încrucișat ale contractelor 11. Acesta este un domeniu foarte nou, care se deschide în zone care au fost rareori atinse de cercetările anterioare Bitcoin și pot exista câteva surprize îngropate acolo.

în concluzie

În acest articol, cititorii vor descoperi că există un concept care este menționat frecvent și care parcurge toate procesele de raționament și fantezie: „UTXO”. Aceasta este exact intentia mea. Dacă nu înțelegeți UTXO, nu puteți înțelege punctul de plecare al designului unui protocol precum RGB, nici nu puteți înțelege avantajele designului protocolului RGB și nici nu vă puteți imagina modul în care oamenii îl folosesc. Identitatea protocolului RGB este în mare măsură modelată de forma sa sigilată, unică, UTXO. În mod corespunzător, cercetările asupra UTXO acumulate în domeniul de cercetare Bitcoin pot fi aplicate și cercetărilor despre RGB.

Acest lucru explică și de ce oamenii care nu înțeleg Bitcoin vor avea dificultăți să înțeleagă RGB. Oamenii cărora le place Bitcoin vor recunoaște designul realizat de RGB.

Deoarece există prea multe comentarii în articol, vă rugăm să consultați linkul sursă de mai jos.