Ecosistemul Ethereum L2 s-a extins rapid în ultimul an. Ecosistemul de acumulare ZK-EVM, compus în mod tradițional din StarkNet, Arbitrum, Optimism și Scroll, se mișcă rapid și face pași mari în îmbunătățirea securității. În plus, am văzut, de asemenea, echipe construind sidechain-uri care au început să construiască Rollup (Polygon), proiecte L1 care caută să se dezvolte în direcția verificării validității (Celo) și alte încercări noi-nouțe (Linea, Zeth...).

Un rezultat inevitabil al acestui lucru este că vedem că proiectele L2 arată o tendință de a deveni mai eterogene. Mă aștept ca această tendință să continue din câteva motive:

Unele proiecte care sunt în prezent independente L1 caută să se apropie de ecosistemul Ethereum și să devină potențial L2. Aceste proiecte ar putea dori să treacă treptat. Tranziția dintr-o dată va reduce gradul de utilizare, deoarece tehnologia nu este pregătită pentru a pune totul într-un pachet. Dacă faci o tranziție unică mai târziu, riști să sacrifici impulsul și să faci prea târziu pentru a avea sens.

Unele proiecte centralizate doresc să ofere utilizatorilor mai multe garanții de securitate și explorează abordări bazate pe blockchain. În multe cazuri, aceste proiecte ar fi explorat „lanțuri de consorțiu autorizate” în epoca anterioară. De fapt, ele pot necesita doar un nivel „semi-centralizat” de descentralizare. În plus, deoarece randamentul lor tinde să fie foarte mare, ele nici măcar nu sunt potrivite pentru dezvoltarea Rollup, cel puțin pe termen scurt.

Aplicațiile non-financiare precum jocurile de noroc sau rețelele sociale doresc să fie descentralizate, dar necesită doar un nivel de securitate „semi-centralizat”. Când vine vorba de rețelele sociale, realitatea este că diferitele părți ale aplicației trebuie tratate diferit: activități rare și de mare valoare, cum ar fi înregistrarea numelui de utilizator și recuperarea contului, ar trebui să fie făcute în Rollup, dar activități frecvente și cu valoare redusă, cum ar fi postările și sondajele nu. Dacă o eroare a linkului face ca postarea dvs. să dispară, acesta este un preț acceptabil de plătit. Dacă lanțul eșuează și contul tău este pierdut, problema este mult mai mare.

O temă importantă este că, în timp ce aplicațiile și utilizatorii aflati în prezent pe Ethereum L1 vor putea să plătească taxe de acumulare mai mici, dar încă vizibile pe termen scurt, utilizatorii din lumea non-blockchain nu pot: dacă plăteai anterior 1 USD, atunci plata 0,1 USD este mai mult. rezonabil decât să plătești 0 USD. Acest lucru se aplică atât aplicațiilor centralizate actuale, cât și aplicațiilor mai mici L1, care de obicei încarcă foarte puțin, dar au totuși o bază de utilizatori mică.

O întrebare care apare în mod natural este: Care dintre aceste compromisuri complexe între pachete, valabilitate și alte sisteme este rezonabilă pentru o anumită aplicație?

Rollup、validiums、Sisteme deconectate

Prima dimensiune a securității și amplorii pe care dorim să o examinăm poate fi descrisă după cum urmează: dacă aveți un activ emis pe L1, apoi îl depuneți în L2 și apoi vi-l transferați, cât de multă garanție puteți oferi că puteți transfera acest activ?

Există o întrebare paralelă: ce alegere tehnologică duce la acest nivel de asigurare și care sunt compromisurile acestei alegeri tehnologice?

Putem folosi o diagramă pentru a o descrie simplu:

Merită menționat că acesta este un mod simplificat cu multe opțiuni intermediare. De exemplu:

Între rollup și validium: în validium, oricine poate face plăți în lanț pentru a acoperi taxele de tranzacție, moment în care operatorii vor fi obligați să furnizeze anumite date lanțului sau să-și piardă depozitele.

Între Plasma și validium: Sistemul Plasma oferă garanții de securitate similare cu Rollup, oferind în același timp disponibilitatea datelor în afara lanțului, dar poate suporta doar aplicații limitate. Un sistem poate oferi un EVM complet și poate oferi garanții la nivel de plasmă pentru utilizatorii care nu folosesc aceste aplicații mai complexe și garanții la nivel de validium pentru utilizatorii care o folosesc.

Aceste opțiuni intermediare pot fi gândite ca un spectru între valori cumulate și valori valide. Dar ce motivează o aplicație să aleagă un punct de pe spectru mai degrabă decât un punct mai la stânga sau la dreapta? Există doi factori principali:

1. Pe măsură ce tehnologia avansează, costul disponibilității native a datelor în Ethereum va scădea treptat. Următorul hard fork al Ethereum, Dencun, introduce EIP-4844 (cunoscut și sub numele de „native fork”), care oferă o disponibilitate a datelor în lanț de aproximativ 32 kB pe secundă. În următorii câțiva ani, se așteaptă ca această disponibilitate a datelor să crească în etape odată cu lansarea completă a „partajării datelor în lanț”, ajungând în cele din urmă la o disponibilitate a datelor de aproximativ 1,3 MB pe secundă. În același timp, îmbunătățirile în tehnologia de compresie a datelor ne vor permite să facem mai mult cu aceeași cantitate de date.

2. Nevoile aplicației în sine: Cât de mult vor suferi utilizatorii din cauza taxelor mari și cât va costa dacă aplicația merge prost? Aplicațiile financiare suferă mai mult de eșecurile aplicațiilor;

Compensațiile arată cam așa:

Un alt tip de garanție parțială care merită menționat este pre-confirmarea. O pre-confirmare este un mesaj semnat de un grup de părți în timpul unei perioade de acumulare sau de valabilitate, care spune „certificăm că aceste tranzacții sunt incluse în această comandă și că rădăcina post-stat este astfel”. Este posibil ca pre-confirmările semnate de acești participanți să nu se potrivească cu realitatea ulterioară, dar dacă nu, depozitul va fi distrus. Acest lucru este util pentru aplicațiile cu valoare redusă, cum ar fi plățile pentru consumatori, în timp ce aplicațiile cu valoare ridicată, cum ar fi transferurile de fonduri de mai multe milioane de dolari, ar putea avea nevoie să aștepte confirmări „regulate” cu suport de securitate complet din partea sistemului.

Prevalidarea poate fi văzută ca un alt exemplu de sistem hibrid, asemănător cu „sistemul hibrid plasmă/validium” menționat mai sus, dar de data aceasta cu securitate deplină, dar latență mai mare (sau validium) cu niveluri scăzute de securitate Un hibrid între sisteme cu latență mult mai mare, dar latență mai mică. Aplicațiile care necesită o latență mai mică vor primi o securitate mai mică, dar pot trăi în același ecosistem ca și cele care pot accepta o latență mai mare în schimbul unei securități maxime.

Citiți Ethereum fără încredere

O altă formă de conectivitate mai puțin luată în considerare, dar încă foarte importantă, se referă la capacitatea sistemului de a citi blockchain-ul Ethereum. În special, aceasta include posibilitatea de a se restabili atunci când Ethereum se recuperează. Pentru a înțelege valoarea acestui lucru, luați în considerare următoarea situație:

Să presupunem că lanțul Ethereum se întoarce, așa cum se arată în figură. Acesta ar putea fi un sughiț temporar într-o epocă, în care lanțul nu a fost finalizat sau ar putea fi o perioadă de scurgere de inactivitate, în care prea mulți validatori sunt offline și lanțul nu a fost finalizat de mult.

Cel mai rău scenariu care poate apărea este următorul:

Să presupunem că primul bloc al lanțului de sus citește unele date din blocul din stânga al lanțului Ethereum. De exemplu, cineva de pe Ethereum depune 100 ETH în lanțul de sus. Apoi, Ethereum a revenit. Cu toate acestea, lanțul superior nu va fi derulat înapoi. Prin urmare, blocurile viitoare ale lanțului superior vor urma corect noile blocuri din noul lanț Ethereum corect, dar consecințele verigii vechi greșite (adică depozitul de 100 ETH) sunt acum încă parte din lanțul superior. Această vulnerabilitate poate fi exploatată pentru a tipări bani, transformând ETH cu punte din lanțul superior într-o rezervă parțială.

Există două moduri de a rezolva această problemă:

1. Lanțul de sus poate citi doar blocul final al Ethereum, așa că nu trebuie să fie niciodată restaurat.

2. Dacă Ethereum este restaurat, lanțul superior poate fi, de asemenea, restaurat. Ambele metode evită această problemă. Primul este mai ușor de implementat, dar ar putea duce la pierderea prelungită a funcționalității dacă Ethereum intră într-o perioadă de scurgere inactivă. Acesta din urmă este mai greu de realizat, dar asigură o funcționalitate optimă în orice moment.

Rețineți că (1) are o carcasă marginală. Dacă un atac de 51% asupra Ethereum creează două blocuri noi incompatibile și ambele blocuri ajung în același timp, atunci lanțul de sus este probabil să blocheze blocul greșit (adică consensul social Ethereum ajunge să nu accepte blocul) și trebuie restaurat. la blocul corect. Se poate spune că nu este nevoie să scrieți cod în avans pentru a gestiona această situație;

Există două motive pentru care un lanț poate citi Ethereum fără încredere:

1. Reduce problemele de securitate implicate în conectarea jetoanelor emise pe Ethereum (sau alt L2) la acel lanț;

2. Permite portofelelor de abstracție a contului folosind o arhitectură de stocare a cheilor partajate pentru a păstra în siguranță activele în lanț.

Primul punct este important, deși nevoia este deja recunoscută pe scară largă. Al doilea punct este, de asemenea, important, deoarece înseamnă că puteți avea un portofel care permite schimbarea ușoară a cheilor și deține active pe un număr mare de lanțuri diferite.

Deținerea unui pod îl face valabil?

Să presupunem că lanțul de sus a început ca un lanț separat, iar apoi cineva a adăugat un contract bridge pe Ethereum. Un contract bridge este un contract simplu care acceptă un antet de bloc din lanțul de sus, verifică că orice antet de bloc trimis acestuia poartă un certificat valid care indică faptul că a fost acceptat de consensul lanțului de sus și adaugă acel antet de bloc la o listă. mijloc. Aplicațiile pot implementa funcții precum depunerea și retragerea monedelor pe această bază. Odată ce o astfel de punte este stabilită, va putea oferi garanția de securitate a activelor pe care am menționat-o mai devreme?

Până acum, nu încă! Există două motive:

1. Ceea ce verificăm este dacă blocul este semnat, nu dacă tranziția de stare este corectă. Deci, dacă depuneți active emise pe Ethereum în lanțul de sus, iar validatorii din lanțul de sus sunt indisciplinați, ei pot semna o tranziție de stare nevalidă și, astfel, pot fura acele active;

2. Lanțul de sus încă nu poate citi Ethereum. Prin urmare, nici măcar nu puteți depune active native Ethereum în lanțul superior fără să vă bazați pe alte poduri terțe (care pot fi nesigure);

Acum, să transformăm puntea într-o punte de validare: nu numai că verifică consensul, ci și ZK-SNARK-urile, demonstrând că starea oricărui bloc nou a fost calculată corect.

Odată ce faceți acest lucru, validatorii din lanțul de sus nu vă mai pot fura fondurile. Ei pot publica un bloc în care datele sunt indisponibile, împiedicând toată lumea să se retragă, dar nu pot fura (în afară de încercarea de a obliga utilizatorii să răscumpere în schimbul datelor pe care le pot retrage). Acesta este același cu modul sigur al validium.

Cu toate acestea, încă nu am rezolvat a doua problemă: lanțul de sus nu poate citi Ethereum.

Pentru a face acest lucru, trebuie să facem unul dintre cele două lucruri:

1. Plasați un contract bridge în lanțul superior pentru a verifica blocul Ethereum finalizat;

2. Lăsați fiecare bloc din lanțul de sus să conțină un hash din cel mai recent bloc Ethereum și dezvoltați o regulă de alegere a furcăturii care impune înlănțuirea hash. Adică, un bloc de lanț superior care este legat de un bloc Ethereum care nu este în lanțul canonic este el însuși non-canonic Dacă un bloc de lanț superior este legat de un bloc Ethereum care a fost inițial canonic, dar ulterior a devenit non-canonic. lanțul de sus Blocurile trebuie să devină, de asemenea, non-canonice.

Legătura violetă poate fi o legătură hash sau un contract bridge care verifică consensul Ethereum.

Este suficient? Se dovedește că încă nu este suficient, deoarece există câteva cazuri marginale:

1. Ce se va întâmpla dacă Ethereum este atacat de 51%?

2. Cum să gestionați upgrade-ul hard fork al Ethereum?

3. Cum să gestionați upgrade-urile hard furk ale lanțului?

Consecințele unui atac de 51% asupra Ethereum sunt similare cu consecințele unui atac de 51% asupra lanțului superior, dar situația este inversă. Un hard fork a Ethereum are potențialul de a face puntea Ethereum din lanțul superior să nu mai fie valabilă. Cea mai simplă modalitate de a rezolva această problemă este să vă asumați un angajament social de a restabili un bloc final dacă Ethereum îl restabilește pentru a face un angajament social la hard fork în cazul în care Ethereum se îndreaptă. Este posibil ca o astfel de promisiune să nu fie niciodată aplicată efectiv: ați putea activa gadgetul de guvernanță de pe lanțul de sus atunci când vede dovada unui posibil atac sau hard fork și numai dacă gadgetul de guvernanță eșuează.

Din păcate, singurul răspuns fezabil la punctul (3) este crearea unei forme de gadget de guvernare pe Ethereum, care să facă contractul bridge pe Ethereum conștient de upgrade-urile hard fork ale lanțului superior.

Rezumat: Verificarea în două sensuri este aproape suficientă pentru a face un blockchain valid. Principalul factor rămas este un angajament social că, dacă se întâmplă ceva special cu Ethereum care face ca puntea să nu mai funcționeze, celălalt lanț se va bifurca greu ca răspuns.

în concluzie

Există două dimensiuni cheie pentru „conectarea la Ethereum”:

1. Securitatea retragerii de fonduri către Ethereum;

2. Citiți securitatea Ethereum.

Toate acestea sunt importante și au considerații diferite. În ambele cazuri există un spectru continuu:

Rețineți că aceste două dimensiuni sunt măsurate fiecare în două moduri diferite (deci există într-adevăr patru dimensiuni?): Securitatea unei retrageri poate fi măsurată prin (i) nivelul de securitate și (ii) beneficiind de cel mai înalt nivel de securitate Măsurat ca un procent de utilizatori sau cazuri de utilizare, securitatea citirilor poate fi măsurată prin (i) cât de repede lanțul citește blocurile Ethereum, în special blocurile finale față de orice blocuri și (ii) cât de repede lanțul gestionează 51% atacuri și scoruri greu de măsurat; puterea angajamentului social în cazuri marginale, cum ar fi încrucișările.

Valoarea proiectului există în multe zone ale acestui spațiu de design. Pentru unele aplicații, securitatea ridicată și conectivitatea strânsă sunt foarte importante. Pentru alte aplicații, este acceptabil să fie mai liber pentru a obține o scalabilitate mai mare. În multe cazuri, cea mai bună opțiune poate fi cea mai bună opțiune să începem cu o cuplare mai slăbită astăzi și să treceți la o cuplare mai strânsă în următorul deceniu, pe măsură ce tehnologia avansează.