Viitorul actualizărilor Ethereum, după fuziune [Partea a 2-a]

Cea mai mare actualizare vreodată a Ethereum - trecerea la un mecanism de consens pentru dovada mizei - este chiar după colț. Dar, deși Merge ar trebui să adauge securitate și durabilitate, nu include sharding, metoda mult așteptată de scalare a rețelei. 

In Partea I Din conversația noastră cu Danny Ryan, cercetător al Fundației Ethereum (EF), care a ajutat la coordonarea procesului de actualizare, am discutat despre ce este concepută Merge în ceea ce privește securitatea și stabilitatea.

În partea a II-a, Ryan vorbește despre upgrade-uri la care utilizatorii se pot aștepta în viitor, inclusiv danksharding, Ethereum fără stat și actualizări de securitate care se confruntă cu creșterea valorii extractibile pentru mineri (MEV). El explică, de asemenea, cum acest efort de-a lungul anilor a dus la noi metode de cercetare și testare a upgrade-urilor viitoare.

---

Coordonare pe o rețea descentralizată

VIITOR: Ați făcut aluzie la posibilitatea ca minerii să se bifurcă și să continue să încerce să folosească vechiul lanț. Dar, în cea mai mare parte, acest proces i-a adus pe toți la bord. Care este rolul tău în asta ca cercetător al Fundației Ethereum? Cum se coordonează o mișcare atât de masivă?

DANNY RYAN: Am început să mă implic în chestii de tip proof-of-stake în jurul anului 2017 și chiar și atunci mi s-a părut o concluzie dinainte. Asta a fost acum cinci ani. Și comunitatea Ethereum a fost foarte dispusă să nu stagneze și să o facă corect și să construiască un protocol care nu funcționează doar astăzi, ci funcționează, sperăm, timp de 100 de ani sau mai mult. 

Astfel, la începutul etosului său, când a existat bănuiala că dovada mizei poate fi făcută în siguranță și mai bine decât dovada muncii, oamenii au fost foarte încântați de asta. Și până în 2016, 2017, oamenii nu numai că sunt încântați de asta, dar sunt neliniştit ca sa se intample. Se pare că este foarte adânc în etosul comunității Ethereum că acest lucru se va întâmpla.

Sunt probleme mai sensibile. Există concluzii mai puțin anticipate în care EF, echipa de cercetare și clienții care se află în afara EF încearcă cu toții să vină cu soluții la probleme și să mențină lucrurile în mișcare. Uneori, soluțiile sunt într-o zonă puțin mai gri - aceasta este soluția potrivită? O facem acum? O facem mai târziu? Acest lucru sfârșește prin a fi dificil, iar EF încearcă să ajute la coordonarea acestor metode, să ajute la realizarea unor cercetări și dezvoltare pentru a ajuta la identificarea soluțiilor, să faciliteze conversațiile pentru a decide asupra termenelor, priorităților și comenzilor. 

Dar, la sfârșitul zilei, pentru majoritatea subiectelor, agenda EF este de a contribui la realizarea protocolului mai sustenabil, mai sigur și mai scalabil, în timp ce este descentralizat - și nu pentru a furniza o anumită caracteristică față de cealaltă. Deci, o mare parte din ceea ce ne concentrăm atât în ​​ceea ce privește munca tehnică, cât și coordonarea socială se referă la facilitarea unei bune informații, a unei cercetări bune și a unui dialog bun, astfel încât mulți participanți implicați în cercetare și dezvoltare, inginerie și comunitate să poată păstra lucrurile se mișcă și ajung la decizii.

În ultimii cinci ani s-au adăugat mult mai multe voci în comunitate, iar după Merge, teoretic va deveni mai descentralizată. Ce părere aveți despre viitorul proces de upgrade? Este posibil să ne uităm la un fel de DAO de nivel unu pentru a coordona upgrade-urile?

Din câte am înțeles, comunitatea Ethereum nu este interesată de votul în lanț – sau de orice fel de vot plutocratic și upgrade – și că protocolul este cel pe care utilizatorii decid să îl ruleze. În general, există un consens larg. Uneori există schisme - de exemplu, Ethereum vs. Ethereum clasic. Dar, la sfârșitul zilei, este dreptul tău și dreptul comunității și drepturile utilizatorilor să-și dea seama ce software doresc să ruleze. În general, suntem de acord pentru că oamenii încearcă să îmbunătățească Ethereum și nu există prea multe conflicte în unele dintre lucrurile de bază de acolo. 

Deci nu mă aștept la un mecanism tehnic formal. Mă aștept ca procesul să continue să crească, să se schimbe și să evolueze în acest tip de guvernare liberă, unde sunt cercetători, există dezvoltatori, există membri ai comunității, există dapps și lucruri de genul acesta. 

Aș spune că – și cred că ai făcut aluzie la asta – sunt din ce în ce mai mulți oameni la masă și devine din ce în ce mai greu să iei decizii și să trimiți lucruri. Eu personal cred că aceasta este o caracteristică. Cred că, atât din punct de vedere al fiabilității pentru aplicații și utilizatori, cât și pentru evitarea captării pe termen lung, este probabil important ca o mare parte din protocolul Ethereum să se osifice. Așa că, deși este din ce în ce mai dificil să fiu în vâltoarea guvernării și să încerci să expediez, și uneori mi se pare că încerc să alerg cu o vestă cântărită și greutăți pe glezne și acum am greutăți pe încheieturi, cred că avem câteva lucruri cheie de făcut în următorii câțiva ani. Dar cred că va fi din ce în ce mai greu să duci la bun sfârșit lucrurile. Și cred că este un lucru bun.

Vitalik îl numește „viteza de evacuare functionala.” Să ducem Ethereum într-un loc în care are suficientă scară și funcționalitate încât să poată fi extins și utilizat într-o multitudine infinită de moduri în următorul strat al stivei. Asigurați-vă că EVM-ul are o funcționalitate minimă suficientă, să existe suficientă disponibilitate a datelor pentru a gestiona cantități masive de scară, iar apoi aplicațiile o pot extinde în contracte inteligente. Stratul doi pot experimenta cu noi VM-uri în interiorul construcțiilor lor de nivel doi; puteți scala Ethereum și așa mai departe și așa mai departe.

Cred că va fi din ce în ce mai greu să duci la bun sfârșit lucrurile. Și cred că este un lucru bun.

Furculițe de umbră

Unul dintre lucrurile care au ieșit din acest proces de testare specific au fost shadow forks, procesul de copiere a datelor Ethereum reale pe un testnet pentru a simula un mediu de testare mainnet. Asta a fost întotdeauna în plan? Și cum credeți că ar putea schimba procesul de cercetare și dezvoltare pentru upgrade-uri viitoare?

Ar fi trebuit să facem shadow forks în ultimii patru ani. Ei sunt grozavi; sunt chiar misto. În esență, iau un număr de noduri pe care le controlăm - le numim ca 10, 20, 30 - și ei cred că va veni o furcă, așa că sunt pe rețeaua principală sau pe una dintre aceste rețele de testare și apoi la o anumită condiție de furcă, cum ar fi înălțimea blocului, ei toți spun: „Bine, suntem în noua rețea”. Și se bifurcă și apoi petrec în propria lor realitate, dar au starea de dimensiune a rețelei principale.

Și pentru o perioadă, puteți transfera tranzacțiile de pe rețeaua principală în această realitate bifurcată pentru a obține o cantitate rezonabilă din ceea ce pare a activității organice ale utilizatorilor, ceea ce este foarte bun. Ne permite să testăm ceea ce au ajuns să fie procese extrem de organice care sunt greu de simulat. Și asta a fost grozav. Egal [Jayanthi] și alții care lucrează în echipa DevOps de la EF le-au orchestrat și am învățat atât de multe de la ei. Cred că dacă întrebi pe cineva, ar fi de genul: „Ei bine, da, ar fi fost grozav dacă am face asta acum trei ani, acum patru ani la fiecare upgrade”.

Dar voi spune altceva. Am spus-o [de] acum un an și acum suntem în coada lungă în securitate și testare: este cu adevărat zguduitor de chestia asta, asigurându-ne că toate cazurile marginale sunt corecte, asigurându-ne că atunci când vine, se întâmplă. — facem o lovitură și funcționează. Și se dovedește că modul în care software-ul este construit cu clienți de nivel de execuție consens, sunt doar multe de construit în ceea ce privește testarea. Shadow furks este una dintre ele. Folosind alte medii de simulare care pot testa aceste două lucruri împreună, de exemplu kurtotica, Antiteză, Și altele. 

Mai trebuie să facem și alte lucruri, cum ar fi recablarea Stup, care este cadrul nostru de testare seara de integrare, astfel încât să poată gestiona ambele tipuri de clienți și astfel încât să puteți scrie teste în care se întâmplă diferite complexități de ambele părți ale culoarului. Tot ce trebuia să se întâmple. În primul rând, cadrele au trebuit să fie dezvoltate sau modificate. Apoi au trebuit scrise multe dintre teste. Așadar, lucrul bun cu Merge este că am îmbunătățit cu adevărat instrumentele din centura noastră de instrumente pentru a putea testa upgrade-urile în așa fel încât următoarea actualizare să fie mult mai mult despre scrierea testelor decât să ne gândim la cum să le testăm și scrierea cadrelor pentru a-l testa. 

Ce urmează după dovada mizei?

Deoarece acest lucru se întâmplă de mult timp, inițial sharding-ul urma să fie pe primul loc. Dar evoluțiile ecosistemului au însemnat că puteți trece mai întâi la dovada mizei. Au existat și alte dezvoltări ecosistemice care au apărut în timpul acestui proces, care ar putea schimba abordarea dvs. către actualizările viitoare?

În primul rând, există probabil o serie de motive pentru care s-a acordat prioritate transferului de dovadă a mizei. Una a fost să nu mai plătești pentru securitate cu dovada muncii. Iar celălalt era că scara începea să vină prin aceste construcții cu două straturi. Deci, poate, dacă aveți o scară de 10-100x, vă puteți concentra asupra acestui alt lucru și puteți finaliza treaba și unifica aceste două sisteme disparate: lanțul de balize și rețeaua principală actuală. 

Există și alte lucruri care au afectat modul în care ne gândim la termene și priorități. Am menționat mai devreme că întreaga lume MEV a aruncat o cheie în unele lucruri. Există probleme de centralizare și alte probleme de securitate care apar atunci când începeți să vă gândiți unde ar putea merge MEV. Și au fost multe cercetări în ultimele peste 12 luni cu privire la modul de atenuare a unora dintre aceste preocupări cu modificări de la primul nivel. În funcție de analiza amenințărilor venite din lumea MEV, aceasta ar putea acorda prioritate anumitor funcții de securitate și adăugări de securitate la L1 față de altceva care ar putea fi de așteptat să fie prioritatea. 

Cred că ceva interesant este foaia de parcurs sharding și construcția actuală așteptată, care se numește danksharding, numită după Dankrad [Feist], cercetătorul nostru de la EF. Întreaga construcție este de fapt simplificată atunci când presupuneți că acești actori MEV extrem de stimulați există. Nu numai că unii dintre acești actori externi au modificat modul în care gândim noi despre securitate, dar au modificat și modul în care ne putem gândi la construirea acestor protocoale. Dacă presupuneți că MEV există, dacă presupuneți că acești actori extrem de stimulați sunt dispuși să facă anumite lucruri din cauza MEV, atunci dintr-o dată aveți acest participant terț în consensul că poate puteți descărca lucruri, ceea ce în multe feluri. poate fi simplificator. Deci nu sunt doar lucruri rele care vin, ci și noi tipuri de design care se deschid.

Am îmbunătățit cu adevărat instrumentele din centura noastră de instrumente pentru a putea testa upgrade-urile în așa fel încât următoarea actualizare să fie mult mai mult despre scrierea testelor, decât să ne gândim la cum să-l testăm.

Ethereum-ul apatrid este încă discutat și cercetat în mod activ? 

Da. Statul - toate conturile și contractele și soldurile și alte chestii - aceasta este starea Ethereum. Având în vedere locul în care vă aflați în blockchain, există o stare de realitate. Chestia aia crește în timp, crește liniar. Și dacă creșteți limita de gaz, acesta crește și mai repede. Deci aceasta este o preocupare. Dacă crește mai repede decât memoria și spațiul pe hard disk al mașinilor de consum, atunci aveți probleme cu posibilitatea de a rula noduri pe computerele de acasă și pe hardware-ul de consum, ceea ce are probleme de securitate și centralizare. De asemenea, dacă vorbești cu unii dintre GETH Membrii echipei [client], faptul că statul continuă să crească înseamnă că trebuie să continue să optimizeze lucrurile. Deci e greu.

Stateless Ethereum și lucrurile în acea direcție de cercetare sunt o potențială cale de soluție pentru aceasta, unde să execut un bloc nu am nevoie de fapt de întreaga stare; Există un fel de această intrare ascunsă la executarea funcției unui bloc. Am nevoie de pre-starea, am nevoie de bloc și apoi obțin post-starea să știu dacă blocul este valid. În timp ce cu Ethereum fără stat, cerințele de stat - conturile și alte lucruri de care aveți nevoie pentru a executa acel bloc anume - sunt încorporate în bloc și sunt dovezi că acestea sunt starea corectă. Acum executarea unui bloc și verificarea validității Ethereum devine doar [trebuie] să aibă blocul, ceea ce este foarte bun. Acum putem avea noduri complete care nu au neapărat stare completă. Deschide un întreg spectru de modul de construire a nodurilor. Așa că s-ar putea să am un nod care validează complet și nu are starea, s-ar putea să am un nod care doar păstrează starea relevantă pentru mine sau s-ar putea să am noduri foarte pline care au toată starea și genul de chestii.

Se lucrează activ la acest lucru. În prezent, cred că există un testnet cu toate celelalte lucruri distractive care trebuie să se întâmple pentru ca acest lucru să se întâmple. Evaluarea mea actuală este că cererea de sharding și scară L1 este mai mare decât amenințarea iminentă a creșterii statului. Deci, este foarte probabil, întrucât unul va fi prioritizat față de celălalt, ca scara să fie prioritizată. 

Acestea fiind spuse, e greu de spus. Există „proto-danksharding”, care este un fel ca o modalitate treptată de a obține un pic mai multă amploare. Poate că asta se întâmplă și apoi se întâmplă apatrid și apoi se întâmplă sharding complet, în funcție de nevoile și evaluarea a ceea ce se întâmplă și amenințările implicate. Cred că ideea generală despre creșterea statului este că trebuie să avem o cale și trebuie să o reparăm, dar [că] incendiile iminente au fost stinse și că acesta nu este un lucru care va paraliza Ethereum în următorii doi ani. Dar este un lucru care trebuie reparat.

Îndrumă-mă prin upgrade-urile pe care le-am do știe după Fuziune. Va exista un upgrade de curățare? Este separat de upgrade-ul de la Shanghai? Și când se introduce sharding-ul?

Shanghai va fi probabil numele oricărei furcături după Merge. Pentru a vă retrage efectiv fondurile pe care le-ați mizat de aproape doi ani acum — [asta nu este] activată la Merge. Inițial, se aștepta să fie făcute, dar având în vedere complexitatea Merge, de-a lungul timpului, s-a decis să o dezlipiți cu adevărat și să faceți Merge și să nu adăugați funcționalitatea suplimentară a retragerilor. M-aș aștepta foarte, foarte, foarte mult ca retragerile să fie activate în Shanghai - deci, prima actualizare după Merge. Acest lucru a fost promis multor, multor oameni care au o mulțime de capital pe linie și nu mă aștept la nicio problemă cu asta. Acestea sunt în general specificate, sunt teste scrise și așa ceva. 

Există o serie de alte îmbunătățiri EVM [Ethereum Virtual Machine] care cred că ar fi aduse în acest sistem - diferite operații matematice, câteva lucruri diferite de extensibilitate, o versiune puțin mai bună în EVM și alte caracteristici. Este un pic o supapă de eliberare a presiunii asupra îmbunătățirilor EVM, care au fost puse la o parte de mai mulți ani acum pentru a face Merge și alte upgrade-uri. Și oamenii chiar vor să vadă un fel de upgrade minor de scalabilitate aici. Deci ar putea fi fie proto-danksharding, care pune o parte din temelia pentru sharding complet și obține puțin mai multă scară, fie eventual reduceri ale prețurilor la gaze calldata, care sunt foarte ușoare, dar nu sunt cu adevărat o soluție durabilă. Deci, la asta ne așteptăm, sperăm, la Shanghai: retrageri și puțină amploare.

Atunci întrebarea este: ce urmează după asta? Și asta e greu de spus. Dacă obținem un pic de scară acolo, și completează foarte frumos L2-urile și lucrurile sunt destul de bune, atunci poate că există o cerere de a face apatrid în acel moment. Sau dacă L2-urile au o nevoie nesățioasă de mai multă scară, atunci poate că asta pregătește scena pentru totalul danksharding.

Acest interviu a fost editat și condensat. 

Postat pe 27 iulie 2022