Vitalik propune o soluție pentru a lega anumite proiecte de scalare cu două straturi

Într-un efort continuu de a lupta împotriva escaladării taxelor de tranzacție în timp ce creează un ecosistem unificat, cofondatorul Ethereum, Vitalik Buterin, a propus o soluție pentru un anumit tip de scalare încorporată.

propunere subliniază modul în care două protocoale care utilizează pachete de comunicare pot comunica între ele menținând în același timp interconectivitatea și compozibilitatea.

Pachetele sunt două soluții stratificate, care sunt în esență rețele contractuale inteligente care procesează și stochează datele tranzacțiilor din lanțul principal. Cu toate acestea, există o serie de tipuri diferite de acumulare, fiecare utilizând contracte inteligente unice, cum ar fi optimist și zero-cunoaștere.

În timp ce o serie de proiecte DeFi au implementat seturi de straturi două, cum ar fi Loopring și Synthetix, particularitățile diferitelor seturi de proiecte înseamnă că proiectele nu pot comunica între ele direct pe stratul doi.

Propunerea lui Buterin presupune că o acumulare poate procesa tranzacții easy, în timp ce cealaltă are suport complet pentru contract inteligent. Există deja propuneri pentru transferuri între două protocoale activate cu contract inteligent folosind pachete de stocare.

Pentru a explica modul în care funcționează propunerea, Buterin oferă exemplul unui intermediar ipotetic de schimb pe care l-a numit „Ivan” – unde Ivan are un cont „IVAN_A” în pachetul A pe care îl controlează pe deplin și are, de asemenea, unele fonduri depuse într-un contract inteligent „IVAN_B ‘pe pachet B.

Contractul inteligent ar fi programat pentru a accepta „observe” care includ date suplimentare de la oricine îi trimite pentru a asigura orice tranzacții viitoare. Tranzacțiile creează un strat de conectare care păstrează depozite în toate aceste contracte izolate, permițând pachetului A să trimită pachetului B prin acest strat.

Buterin a sugerat că comportamentul ar funcționa după cum urmează;

„Alice trimite o tranzacție către IVAN_A cu N monede și o notă ALICE_B. Ivan trimite o tranzacție trimitând TRADE_VALUE * (1 – taxă) monede prin IVAN_B către ALICE_B ”

El a adăugat că cel mai rău comportament ar fi dacă Ivan nu trimite monede către ALICE_B așa cum se așteaptă.

Abordând scenariul „în cel mai rău caz” care ar putea apărea ca urmare a utilizării situației propuse, Buterin a subliniat că Alice va fi în continuare în măsură să aștepte până când tranzacția din pachet A confirmă, va găsi o cale alternativă pentru a obține monede în pachet B pentru a plăti taxe, apoi pur și simplu revendică singură fondurile.

Răspunzând la propunere, Alon Muroch a subliniat că a funcționat într-un mod comparable cu modul în care băncile anulează tranzacțiile:

„Este foarte interesant, comparable cu modul în care băncile anulează tranzacțiile între ele. Împărțirea activelor în „conturi” separate ar putea avea limitări, o soluție ar putea fi doar fonduri mari la ambele capete și comisioanele împărțite proporțional. ”