By Bitcoin Revista - acum 6 luni - Timp de citire: 5 minute
Împărțirea și schimbarea plăților: îmbunătățirea confidențialității și succesul plăților simultan
Una dintre limitările fundamentale ale protocolului Lightning este modul în care este gestionată și realizată rutarea plăților. Este în întregime direcționat la sursă, adică expeditorul unei plăți este cel care construiește întregul traseu de la ei înșiși la destinatar pentru a facilita plata. Aceasta prezintă o problemă când vine vorba de schimbarea soldurilor canalelor în timp, deoarece acestea direcționează plăți între numeroși utilizatori diferiți în rețea, odată ce un expeditor „se blochează” și decide asupra unei anumite rute, acea rută nu poate fi schimbată până la un eșec. mesajul ajunge înapoi la expeditor, permițându-le să construiască o rută complet nouă, în jurul punctului în care încercarea inițială a eșuat.
Acest lucru necesită fie să se confrunte cu un UX greoi și enervant, fie să folosească testele de plată, elaborând în mod intenționat plăți pe care le veți eșua intenționat doar pentru a vedea dacă ruta pe care doriți să o utilizați va funcționa înainte de a încerca din nou plata efectivă. Prima este doar o experiență proastă pentru utilizator și nu ceea ce doriți atunci când încercați să creați ceva pentru a fi o soluție de plată viabilă pentru oameni la scară, iar cea de-a doua pune o povară nejustificată asupra rețelei în ansamblu, deoarece nodurile de rutare trebuie să se ocupe de rețea. complicații de trafic și lichiditate ale plăților constante efectuate fără intenția de a finaliza doar pentru a testa viabilitatea unei rute.
Cauza finală a acestor probleme este incapacitatea unei rute de a modifica plata intermediară fără implicarea expeditorului. Deoarece întreaga rută de plată este criptată ceapă, acest lucru nu este cu adevărat posibil. Fiecare hop este conștient doar de hop-ul dinaintea lui, iar hop-ul de după acesta, nu au cunoștințe despre destinația finală pentru a le permite să construiască o rută alternativă de la ei la receptor.
Acum, deși acest lucru prezintă o barieră uriașă în calea renunțării la rutarea bazată pe sursă, nu o împiedică în totalitate. Ca nod intermediar, deși nu puteți reconstrui complet o rută nouă de la dvs. la destinație, puteți redirecționa plata de la dvs. la următorul hop definit în calea aleasă de expeditor. Deci, dacă Bob primește o plată pe care ar trebui să o direcționeze către Carol, iar canalul prin care ar trebui să o direcționeze nu are capacitatea necesară pentru ao redirecționa, el poate trimite tot ce poate prin acel canal și să direcționeze restul suma de plată prin alte rute pe care o poate găsi de la el însuși la Carol.
Luna trecută, Gijs van Dam a scris un plugin-ul de dovadă a conceptului pentru CLN (disponibil aici) care face exact asta, construind pe plăți cu mai multe căi care permit unei plăți să se împartă și să ia mai multe rute către destinatar. Dacă Bob și Carol rulează amândoi pluginul, în situațiile corespunzătoare, se pot comunica unul altuia că o plată redirecționată de-a lungul unui canal este de fapt redirecționată parțial, astfel încât Carol să nu-l abandoneze imediat când vede ceea ce i se face. trimis este mai puțin decât se așteaptă să transmită. În acest fel, dacă sunt disponibile rute alternative între Bob și Carol atunci când ruta decisă de expeditor nu este viabilă, ele pot pur și simplu redirecționa suma necesară și plata poate reuși fără a fi nevoie să eșueze complet, să se propagă înapoi către expeditor și să fie redirecționată de către lor.
Dacă este adoptat pe scară largă ca comportament standardizat în rețea, acesta ar putea avea un impact pozitiv uriaș asupra ratei de succes a plăților, îmbunătățind drastic UX-ul utilizatorilor Lightning care caută un mecanism de plată simplu care să funcționeze. Este un comportament incredibil de simplu și logic, care ar putea îmbunătăți în mod semnificativ un neajuns bine cunoscut. Nu este tot ce poate face totuși.
Unul dintre marile motive pentru care Gijs van Dam a devenit interesat să abordeze această problemă nu are nimic de-a face cu pur și simplu îmbunătățirea ratei de succes a plății și a UX pentru utilizatori, a fost de fapt din cauza unei deficiențe de confidențialitate. Una dintre cele mai cunoscute probleme de confidențialitate la care este vulnerabil Lightning este sondarea canalului, aceasta este problema de care se preocupa Gijs.
După cum am menționat mai sus, este folosit de unele portofele pentru a se asigura că o plată va reuși înainte de a încerca efectiv plata reală, dar această tehnică poate fi folosită și pentru a stabili distribuția fondurilor pe ambele părți ale unui canal. Efectuat în mod repetat și cu sume alese cu grijă, succesul și eșecul fiecărei încercări de sondare pot deduce modul în care fondurile sunt împărțite pe fiecare parte a canalului. Dusă și mai departe și realizată în mod sistematic pe numeroase canale în mod regulat, această tehnică poate chiar să deanonimizeze plățile urmărind efectiv în timp real cum se schimbă soldurile pe canale.
Lightning este în mod constant încadrat ca un instrument de confidențialitate pentru uz tranzacțional, dar realitatea este dată de tehnici precum sondarea canalului de confidențialitate în multe cazuri, în cel mai bun caz, pot fi slabe fără ca un utilizator să fie sofisticat în modul în care interacționează cu rețeaua. Unul dintre efectele secundare interesante ale împărțirii și comutării plăților este că subminează atacurile de sondare. Motivul pentru care un atac de sondare funcționează este că puteți continua să sondați cu sume diferite până când o plată nu reușește. Dacă este făcut corect, acest lucru vă oferă un interval foarte mic între ultima încercare de plată reușită și cea eșuată, care este distribuția soldului canalului.
Într-o lume în care nodurile Lightning pot redirecționa din zbor părți plăți care ar fi altelewise eșuează, așa că reușesc, se rupe complet ipoteza inerentă pe care se bazează sondarea echilibrului canalului. Că încercarea dvs. de plată va eșua atunci când canalul prin care ați decis să îl direcționați nu are lichiditatea necesară pentru a o transmite. Odată cu împărțirea și schimbarea plăților, această ipoteză nu mai este adevărată și cu cât mai multe noduri de pe rețea acceptă comutarea, cu atât este mai predispusă la erori (cu până la 62% conform unei simulări care utilizează date din rețeaua Lightning din lumea reală realizată de Gijs).
Prin urmare, această propunere nu numai că este relativ simplă, nu numai că oferă o cale de îmbunătățire a ratei de succes a încercărilor de plată, dar ajută și la rezolvarea uneia dintre cele mai mari deficiențe de confidențialitate ale rețelei Lightning. Cred că mai ales în urma celor recente Vulnerabilitatea fulgerului, această propunere arată că, deși Lightning nu este lipsit de probleme, acestea nu sunt imposibil de rezolvat sau atenuat. Va fi chiar foarte comun ca soluțiile la o problemă să ajute cu o altă problemă.
Roma nu a fost construită într-o zi și soluții care de fapt păstrează BitcoinProprietățile de bază ale lui într-un mod scalabil și durabil nu vor fi nici.
Sursă originală: Bitcoin Revistă