Loading Posts...

Cum funcționează Lightning Network (partea a II-a)

În continuare, Gazeta Bitcoin vă explică cum se construieşte întreaga reţea din canalele de plată. Cum se pot trimite criptomonede către cineva, fără a avea un canal deschis cu acea persoană? De ce nu este necesară încrederea într-un terţ? Cum pot nodurile Lightning să găsească rutele din reţea?

Citește și: Cum funcționează Lightning Network (partea I)

Cum am spus şi mai sus, explicaţiile nu sunt unele simple. Însă pas cu pas, Gazeta Bitcoin vă va descrie toate mecanismele acestui concept nou.

Să mai recapitulăm o dată noţiunile esenţiale: Lightning este o reţea de tranzacţii efectuate în afara Blockchain-ului, dar care sunt valide şi legitime. Avantajul constă în faptul că utilizatorul nu trebuie să aştepte ca minerii să îi confirme că a fost plătit, şi poate cel mai important aspect: utilizatorul nu îşi publică tranzacţia în Blockchain, Blockchain-ul fiind multiplicat de fiecare nod din reţea. Cu această arhitectură, Lightning rezolvă unele probleme fundamentale ale reţelei Bitcoin referitoare la scalare şi anonimitate.

Canalele de plată

Unităţile fundamentale ale Lightning Network sunt canalele de plată. Le puteţi imagina ca şi cum aţi edita şi semna în permanenţă un formular pentru o tranzacţie, dar pe care nu îl predaţi niciodată băncii.

În cadrul unui canal de plată, ambele entităţi participante îşi trimit criptomonede, dar nu transmit în reţea tranzacţiile. Întrucât tranzacţia este actualizată la fiecare plată nouă, puteţi efectua oricâte tranzacţii doriţi prin respectivul canal. Într-un final, când tranzacţia este transmisă și publicată în Blockchain, după confirmarea acesteia de către mineri, canalul este închis.

Pentru a realiza un canal de plată, ambele părţi partajează o adresă multisig, care poate fi actualizată doar cu acordul ambelor părţi. Participanţii deschid canalul prin trimiterea unei cantităţi de Bitcoin către adresa multisig. Amândoi trebuie să trimită criptomonede şi, în general, dintr-un canal se pot scoate atâtea monede digitale câte au fost introduse iniţial.

Mai multe contracte smart garantează că părţile nu trebuie să aibă încredere una în cealaltă şi, în plus, este imposibil trişatul. Nu este posibil ca una dintre părţi să îi blocheze banii celeilalte și nici ca o tranzacţie veche să fie publicată în Blockchain – situaţie în care, dacă s-ar fi putut realiza aşa ceva, ar fi condus la anularea unei plăţi ulterioare. Singura condiţie de funcţionare a canalelor de plată este ca ambii parteneri să fie online permanent sau măcar în anumite momente esenţiale.

Modul prin care canalele construiesc o reţea reprezintă chintesenţa Lightning. Si asta deoarece nu există prea multă cerere pentru canale particulare de microplăţi, chiar dacă tehnologia este una uimitoare. Pentru a fi adoptate în mainstream, canalele de plată trebuie reunite într-o reţea. Întrebarea este: cum se poate realiza acest lucru?

Cum construiesc canalele o reţea

Dacă tranzacţiile din reţeaua Bitcoin sunt primite, validate, retransmise de fiecare nod, apoi sunt confirmate de mineri şi într-un final ele sunt stocate, tranzacţiile Lightning circulă doar între expeditor şi destinatar. Aceştia le stochează şi le validează.

Pentru două entităţi, totul ar fi foarte uşor. Să considerăm de exemplu doi utilizatori, pe care îi numim Cristian şi Alin. Ce se întâmplă însă cand apare şi o terţă parte, cum ar fi, de exemplu, Magda? În cadrul exemplului, Cristian are un canal deschis cu Alin, iar acesta are un canal deschis cu Magda. Din acest punct, Cristian îl poate folosi pe Alin în postură de hub pentru a trimite o tranzacţie Magdei. Dar cum este acest lucru posibil?

În principiu, este foarte uşor. Cristian îi trimite 1 BTC lui Alin, sau, mai precis, îi trimite o tranzacţie de 1 BTC lui Alin. Iar Alin îi trimite 1 BTC Magdei.

Cu această schemă, avem topografia de bază a Reţelei Lightning. Plăţile trec prin canale. Dacă mai apar alte entităţi – de exemplu Răzvan, care are un canal deschis cu Magda, se poate ruta tranzacţia de la Cristian la Răzvan, trecând prin Alin şi Magda. Şi aşa mai departe.

Arhitectura exacta a reţelei conţine posibilităţi infinite. Fiind o reţea descentralizată, fiecare utilizator deţine mai multe canale şi rutează prin miliarde de variante. Pot apărea şi hub-uri puternice, care blochează fonduri importante în mai multe canale. Acestea pot facilita ruta unui utilizator obişnuit. Aceste canale pot câştiga mulţi bani prin observarea obiceiurilor de plată ale unor clienţi sau prin colectarea de comisioane pentru prestarea unor servicii de rutare.

Întrebarea cheie este: cum se poate realiza aşa ceva fără a fi necesară încrederea reciprocă? Dacă Cristian îi trimite o plată lui Alin şi îl roagă să o trimită mai departe Magdei, cum poate fi sigur Cristian că Alin nu îi va fura banii?

Răspunsul nu este simplu, însă vom încerca să clarificăm situaţia.

Contracte cu sigiliu pe hash şi pe timp

Soluţia o reprezintă aşa-numitele contracte cu sigiliu pe hash şi pe timp (Hash Time-Locked Contracts – HTLC). Este un termen greoi, dar are un înţeles: pentru a primi banii de la Cristian, Magda generează o valoare aleatoare. Cum ar fi de exemplu “R”. R este un şir de caractere, cum ar fi o parolă.

Magda creează apoi un hash al lui R. Hash-ul este rezultatul unei operaţii criptografice prin care un string (şir de caractere) este transformat într-un alt string. Hash-ul are două proprietăţi importante: rezultatul operaţiei este mereu acelaşi, iar valoarea iniţială nu se poate calcula prin hash. De aceea este numit şi funcţie cu sens unic.

Mai departe, Magda îi dă acest hash lui Cristian, care îi promite 1 BTC lui Alin dacă acesta îi dă valoarea iniţială a hash-ului. Este ca o ghicitoare: Magda îi spune lui Cristian ghicitoarea, iar Cristian îi promite lui Alin o recompensă pentru răspunsul la ghicitoare. Întrucât nu există încredere între părţi, Cristian nu doar că promite ceva, dar generează şi un tip de tranzacţie. Un aşa-numit contract de hash (hash contract).

Pentru a înţelege mai bine conceptul, să reamintim şi faptul că orice tranzacţie foloseşte un script. O tranzacţie standard spune ceva de genul: “ai voie să mă cheltui dacă semnezi o nouă tranzacţie cu cheia privată care corespunde acestei adrese sau celeilalte adrese”. Un hash contract spune însă altceva: “mă poţi cheltui când îmi dai semnătura corectă și soluţia ghicitorii”.

Cristian îi trimite o astfel de tranzacţie lui Alin. Pentru a cheltui fondurile incluse în tranzacţie, Alin trebuie să o roage pe Magda să îi dea valoarea din care a fost construit hash-ul. Ca şi cum ar fi avut nevoie de o parolă. Magda îi oferă doar lui Alin respectiva valoare doar dacă Alin îi dă 1 BTC. Când Alin primeşte valoarea de la Magda, el poate primi 1 BTC de la Cristian. Și atunci operaţia s-a încheiat cu succes.

Dar cum putem şti cu siguranţă că Alin transmite tranzacţia? El ar putea să se bucure pentru că Bitcoinul lui Cristian este blocat, chiar dacă el nu ar mai primi nimic. În acel moment tranzacţia lui Cristian este în aer, iar Alin poate solicita o plată suplimentară de la Cristian pentru a-i elibera fondurile.

Aici apar contractele cu sigiliu temporal (time-locked contract). O tranzacţie Lightning poate fi răscumpărată prin două metode: prima – menţionată anterior – presupune ca destinatarul să arate valoarea hash-ului şi să semneze tranzacţia cu cheia sa privată. A doua metodă, care este de bază din punct de vedere al siguranţei, presupune ca expeditorul să semneze folosind propria semnatură digitală. Pentru a îl împiedica pe expeditor să trişeze, această opţiune are un sigiliu pe timp; poate fi utilizată doar după ce un anumit interval de timp a trecut. Drept urmare, dacă Alin nu îi transmite Magdei tranzacţia, Cristian o poate anula pe a lui după un timp. În cel mai rău caz, tranzacţia este blocată pe un anumit interval de timp.

Putem extinde acest scenariu şi asupra celui de-al patrulea utilizator, Răzvan. În acest caz expeditorul trimite hash-ul către destinatar, iar destinatarul trimite soluţia ghicitorii pe aceeaşi rută înapoi spre expeditor. Nu este nimic nou, doar că intervalul de timp trebuie stabilit, altfel canalele ar intra în colaps.

Acum, după ce am lămurit cum poate funcţiona Reţeaua Lightning fără a fi necesară încrederea între părţi, trebuie să aflăm şi modul în care un utilizator poate şti ruta pe care o va urma tranzacţia sa pentru a ajunge la destinaţie.

Sfinxul, Semnalizatorul şi Onion Routing

Pentru a iniţia o tranzacţie Lightning, teoretic este nevoie doar de o valoare hash. Magda vrea bani, deci ea păstrează hash-ul la îndemână, iar când Alin vrea să o platească, el trimite banii la schimb cu hash-ul. Cel puţin aşa ar fi ideal.

Însă nodurilor Lightning trebuie să li se spună pe ce rută va merge fiecare tranzacţie. Cum se poate concepe aceasta fără un nod central? Pentru a complica şi mai mult lucrurile, trebuie să ţinem cont şi de faptul ca intermediarii nu sunt identici. Fiecare poate transmite mai departe doar cantitatea de Bitcoin pe care o deţine în canalul propriu. Când Cristian îi trimite 1 BTC Magdei, dacă Alin are doar 0.5 BTC în canalul propriu, trebuie aleasă o altă rută.

Unii consideră că problema rutării este adevărata provocare şi că ar fi imposibil de rezolvat fără un nod central – aspect care nu ar mai permite anonimitatea. Alţii ar putea spune că o rutare descentralizată nu doar că este perfect posibilă, dar a fost şi implementată deja.

Unele dintre cele mai competente autorităţi în domeniu sunt developerii Lightning. Rusty Russell, reprezentant al Blockstream (compania care a realizat Lightning Network), scria în anul 2016 pe blog:

“Rutarea pe internet este ceva uşor. Arunci un pachet care are adresa scrisă pe el, iar acesta va găsi cum să ajungă la destinaţie. În general, funcţionează pur şi simplu. Dar dacă vrei anonimitate, schema aceasta nu se aplică”.

Întrucât anonimitatea este un aspect foarte important pentru compania Blockstream, Rusty a spus că au fost nevoiţi să caute o soluţie. Şi au găsit-o în aşa-numita schemă a Sfinxului, care a fost publicată anterior şi care fusese deja implementată de Christian Decker şi Olaoluwa Osuntokun.

Sfinxul este un protocol dezvoltat de George Danezis şi Ian Goldberg. Conform white paper-ului, el este “un format de mesaje criptografice care acţionează ca un releu, el retransmiţând mesaje anonime într-o reţea mixtă. Este mult mai compact decât orice altă schemă cu care l-am compara şi suportă un ansamblu complet de caracteristici legate de securitate: replici imperceptibile, mascarea lungimii rutei şi a poziţiei releului, garantarea că nu poate face nimeni vreo legătură între punctele pe care le parcurge mesajul în timp ce circulă în reţea”.

Implementarea protocolului Sfinx în reţeaua Lightning are ca rezultat, continuă Rusty, faptul că “niciun nod nu poate spune câte hopuri au trecut deja sau câte mai rămân; fiecare nod cunoaşte doar nodul anterior şi pe cel următor”. Nu a fost uşor de realizat o asemenea robusteţe a reţelei, însă dezvoltatorii au reuşit.

O alternativă la Sfinx este protocolul Flare (Semnalizator), care a fost conceput de compania BitFury. Wite paper-ul acestuia a fost făcut public în vara lui 2016. Protocolul Flare a fost testat de către start-up-ul francez ACINQ, companie care a construit primul prototip al Reţelei Lightning. Conform declaraţiilor companiei BitFury, ACINQ a reuşit să găsească în mod rapid o rută între 2500 de noduri. Aceasta îi conferă protocolului Flare un potenţial uriaş de a deveni un algoritm de rutare care să ajute la o scalare şi mai mare:

“Scopul design-ului algoritmului este de a garanta că rutele pot fi găsite atât de repede cât permite Lightning Network, iar în acelaşi timp să diminueze la minim datele stocate în sistem şi să menţină descentralizarea. Toate acestea se pot realiza cu ajutorul nodurilor, care colectează în mod proactiv informaţii despre topologia Reţelei Lightning şi care totodată colectează în mod reactiv informaţii despre topologia necesară solicitărilor de tranzacţii”.

Aşadar, se pare că provocarea Onion Routing (tehnica de anonimizare folosită de TOR) nu este rezolvată în întregime. Dar cu siguranţă, developerii vor reuşi într-un final.

Cum vi s-a părut acest articol? Gazeta Bitcoin vă invită să ne scrieţi un comentariu pe iBitcoin.ro!

4
HeartHeart
2
WowWow
0
HahaHaha
0
SadSad
0
AngryAngry
Voted Thanks!

Gazeta Bitcoin

Redacția de știri.

Leave a Reply

Loading Posts...