Autor: knower, crypto KOL Traducere: Golden Finance xiaozou

1. Introducere în MegaETH

Conținutul principal al acestui articol va fi câteva dintre gândurile mele personale despre cartea albă MegaETH și mă pot extinde mai departe de aici dacă pot. Indiferent care ar fi acest articol, sper că ați învățat ceva nou din el.

Site-ul web MegaETH este grozav, deoarece are un iepure mecanic cu o schemă de culori foarte atrăgătoare. Înainte de aceasta, exista un singur Github - a avea un site web face totul mult mai ușor.

M-am uitat la MegaETH Github și am aflat că ei dezvoltă un tip de strat de execuție, dar trebuie să fiu sincer, poate că m-am înșelat în privința asta. Adevărul este că nu știam suficient despre MegaETH și acum sunt un subiect fierbinte pe EthCC.

Trebuia să știu totul și să mă asigur că văd aceeași tehnologie pe care o vedeau băieții cool.

Cartea albă MegaETH spune că sunt un blockchain în timp real compatibil cu EVM, conceput pentru a aduce performanță asemănătoare web2 în lumea cripto. Scopul lor este de a îmbunătăți experiența de utilizare a Ethereum L2, oferind atribute precum peste 100.000 de tranzacții pe secundă, timpi de blocare mai mici de o milisecundă și taxe de tranzacție de un cent.

Cartea lor albă evidențiază numărul tot mai mare de L2 (discutat într-una dintre postările mele anterioare, deși numărul a urcat la peste 50, cu mult mai multe L2 în „dezvoltare activă”) și eforturile lor în cripto. Există o lipsă de PMF în lume. Ethereum și Solana sunt cele mai populare blockchain-uri, iar utilizatorii vor fi atrași de unul dintre ele și vor alege celălalt L2 doar dacă există token-uri pentru mine.

Nu cred că prea mult L2 este un lucru rău, la fel cum nu cred că este neapărat un lucru bun, dar sunt de acord că trebuie să facem un pas înapoi și să examinăm de ce industria noastră creează atât de multe L2.

Briciul lui Occam ar spune că VC se bucură de sentimentul de a ști că au într-adevăr potențialul de a construi următorul rege L2 (sau L1) și de a obține satisfacția de a investi în acele proiecte, dar cred, de asemenea, că poate mulți dezvoltatori Crypto își doresc de fapt mai mult L2 . Ambele părți pot avea dreptate, dar concluzia cu privire la care parte este mai corectă este lipsită de importanță. Este mai bine să aruncăm o privire obiectivă asupra ecosistemului actual de infrastructură și să profităm la maximum de ceea ce avem.

Performanța L2-ului pe care o avem în prezent disponibil este mare, dar nu suficientă. Cartea albă a MegaETH spune că, chiar și cu 100 MGas/s (relativ) ridicate ale opBNB, aceasta ar însemna doar 650 de tranzacții Uniswap pe secundă - infrastructura modernă sau web2 poate face 1 milion de tranzacții pe secundă.

Știm că, în ciuda avantajelor cripto-ului care provin din natura descentralizată și care permite plăți fără permisiune, este încă destul de lent. Dacă o companie de dezvoltare de jocuri precum Blizzard vrea să aducă Overwatch în lanț, nu o poate face - avem nevoie de o rată de clic mai mare pentru a oferi PvP în timp real și alte caracteristici pe care jocurile web2 le oferă în mod natural.

Una dintre soluțiile MegaETH la dilema L2 este de a delega securitatea și rezistența la cenzură lui Ethereum și, respectiv, EigenDA, transformând MegaETH în L2 cu cele mai înalte performanțe din lume, fără niciun compromis.

L1 necesită de obicei noduri omogene care îndeplinesc aceleași sarcini, fără spațiu pentru specializare. În acest caz, specializarea se referă la lucrări precum secvențierea sau demonstrarea. L2 eludează această problemă, permițând utilizarea nodurilor eterogene, separând sarcinile pentru a îmbunătăți scalabilitatea sau a ușura o parte din sarcină. Acest lucru se poate observa în popularitatea tot mai mare a secvențierelor partajate (cum ar fi Astria sau Espresso) și în creșterea serviciilor specializate de verificare zk (cum ar fi Succinct sau Axiom).

„Crearea unui blockchain live implică mai mult decât utilizarea unui client de execuție Ethereum de la raft și adăugarea de hardware de secvențiere De exemplu, experimentele noastre de performanță arată că, chiar și cu un server puternic echipat cu 512 GB RAM, performanța lui Reth pe blocurile Ethereum recente poate. de asemenea, obțineți doar aproximativ 1000 TPS în setarea de sincronizare în timp real, ceea ce este echivalent cu aproximativ 100 MGas/s.”

MegaETH extinde această partiționare prin abstracția execuției tranzacțiilor de la nodurile complete, folosind doar un secvențior „activ” pentru a elimina suprasarcina de consens în execuția tipică a tranzacțiilor. „Majoritatea nodurilor complete primesc diferențe de stare de la acest ordonator prin rețeaua p2p și aplică diferențele direct pentru a actualiza starea locală.

Nu am citit prea multe analize despre cât de bun este MegaETH în afară de comentariile „este rapid” sau „e ieftin”, așa că voi încerca să analizez cu atenție arhitectura acestuia și să-l compar cu alte L2-uri.

MegaETH folosește EigenDA pentru a gestiona disponibilitatea datelor, ceea ce este o practică destul de standard în zilele noastre. Platformele Rollup-as-a-Service (RaaS: rollup as a service) precum Conduit vă permit să alegeți Celestia, EigenDA sau chiar Ethereum (dacă preferați) ca furnizor de disponibilitate a datelor pentru rollup. Diferența dintre cele două este mai degrabă tehnică și nu în întregime relevantă și se pare că decizia de a alege unul față de celălalt se bazează mai mult pe rezonanță decât pe orice altceva.

Sequencerul comandă și în cele din urmă execută tranzacții, dar este și responsabil pentru publicarea blocurilor, martorilor și diferențelor de stat. Într-un context L2, un martor este date suplimentare utilizate de către probator pentru a verifica blocul secvențer.

Diferențele de stare sunt modificări ale stării blockchain-ului și pot fi practic orice se întâmplă pe lanț - funcția blockchain-ului este de a adăuga și verifica în mod constant informații noi adăugate la starea sa, iar funcția acestor diferențe de stare este de a permite noduri Confirmați tranzacția fără a o reexecuta.

Prover constă dintr-un hardware special folosit pentru a calcula dovezi criptografice pentru a verifica conținutul blocurilor. De asemenea, permit nodurilor să evite execuțiile repetate. Există dovezi de zero cunoștințe și dovezi de fraudă (sau dovezi optimiste?), dar diferența dintre ele nu este importantă în acest moment.

A pune toate acestea împreună este sarcina rețelei de noduri complete, care acționează ca un fel de agregator între doveditori, ordonanți și EigenDA pentru a (sperăm) să transforme magia MegaETH în realitate.

Designul MegaETH se bazează pe o neînțelegere fundamentală a EVM. Deși L2 acuză adesea EVM pentru performanța sa slabă (debitul), s-a descoperit că revm poate ajunge la 14000 TPS. Dacă nu este EVM, care este motivul?

2. Probleme actuale de scalabilitate

Principalele trei ineficiențe EVM care duc la blocaje de performanță sunt lipsa execuției paralele, supraîncărcarea interpretului și latența mare a accesului la stare.

MegaETH este capabil să stocheze starea întregului blockchain datorită abundenței sale de RAM, RAM exactă a Ethereum este de 100 GB. Această configurare accelerează semnificativ accesul la stare prin eliminarea latenței de citire a SSD-ului.

Nu știu prea multe despre latența de citire a SSD-ului, dar se presupune că unele coduri operaționale sunt mai intense decât altele, iar dacă aruncați mai multă RAM la problemă, o puteți abstrage. Mai funcționează asta la scară? Nu sunt sigur, dar pentru acest articol, voi lua asta ca un fapt. Încă sunt sceptic că lanțurile pot determina simultan debitul, costurile de tranzacție și latența, dar încerc să fiu un învățător activ.

Un alt lucru pe care ar trebui să-l menționez este că nu vreau să fiu prea pretențios. Ideea mea este să nu susțin niciodată un protocol față de altul și nici măcar să le prețuiesc în mod egal în primul rând - fac asta doar pentru o mai bună înțelegere și pentru a ajuta pe oricine citește acest lucru să obțină aceeași înțelegere în același timp.

Poate că sunteți familiarizat cu tendința EVM paralelă, dar se spune că există o problemă. Deși s-au făcut progrese în portarea algoritmului Block-STM la EVM, se spune că „accelerarea reală care poate fi realizată în producție este limitată în mod inerent de paralelismul disponibil în sarcina de lucru Aceasta înseamnă că, chiar dacă EVM-ul paralel este eliberat”. În cele din urmă, implementată pe lanțul EVM de pe rețeaua principală, tehnologia este, de asemenea, limitată de realitatea de bază că majoritatea tranzacțiilor ar putea să nu fie nevoie să fie executate în paralel.

Dacă tranzacția B depinde de rezultatul tranzacției A, nu puteți executa ambele tranzacții în același timp. Dacă 50% din tranzacțiile unui bloc sunt interdependente ca în acest caz, atunci execuția paralelă nu este o îmbunătățire la fel de semnificativă precum se susține. În timp ce acest lucru este puțin prea simplificat (și poate chiar puțin incorect), cred că atinge obiectivul.

Diferența dintre Revm și execuția nativă este foarte vizibilă, în special revm, care este încă cu 1-2 OOM-uri mai lent și nu merită ca mediu VM autonom. S-a descoperit, de asemenea, că în prezent nu există suficiente contracte intensive de calcul pentru a justifica utilizarea revm. „De exemplu, am analizat timpul petrecut per cod operațional în timpul sincronizării istorice și am constatat că aproximativ 50% din timpul în revm a fost petrecut pe codurile operaționale „gazdă” și „sistem”.

În ceea ce privește sincronizarea stării, MegaETH a găsit mai multe probleme. Sincronizarea stării este pur și simplu descrisă ca procesul de sincronizare a nodurilor complete cu activitatea de comandă, o sarcină care poate consuma rapid lățimea de bandă a unui proiect precum MegaETH. Iată un exemplu pentru a ilustra acest lucru: dacă scopul este de a sincroniza 100.000 de transferuri ERC20 pe secundă, atunci aceasta va consuma aproximativ 152,6 Mbps de lățime de bandă. Se spune că acești 152,6 Mbps depășesc estimările (sau performanța) MegaETH și, practic, introduce o sarcină imposibilă.

Acest lucru ia în considerare doar transferurile simple de token și ignoră posibilitatea unor costuri mai mari dacă tranzacția este mai complexă. Acesta este un scenariu posibil, având în vedere diversitatea activității în lanț din lumea reală. MegaETH a scris că tranzacția Uniswap a modificat 8 sloturi de stocare (în timp ce transferul ERC20 a modificat doar 3 sloturi de stocare), aducând consumul total de lățime de bandă la 476,1 Mbps, ceea ce este un obiectiv și mai puțin fezabil.

O altă problemă în implementarea unui blockchain de înaltă performanță de 100k TPS constă în rezolvarea actualizărilor la rădăcina stării lanțului, o sarcină care gestionează trimiterea dovezilor de stocare către clienții ușoare. Chiar și în cazul nodurilor profesionale, nodurile complete trebuie să folosească nodul de secvențiere al rețelei pentru a menține rădăcina stării. Luând ca exemplu problema de mai sus de sincronizare a 100.000 de transferuri ERC20 pe secundă, aceasta va aduce costul actualizării a 300.000 de chei pe secundă.

Ethereum folosește structura de date MPT (Merkle Patricia Trie: Merkle Prefix Tree) pentru a calcula starea după fiecare bloc. Pentru a actualiza 300.000 de chei pe secundă, Ethereum ar trebui să „conversie 6 milioane de citiri de baze de date fără cache”, ceea ce este semnificativ mai mult decât este capabil în prezent orice SSD de consum. MegaETH scrie că această estimare nu include nici măcar operațiunile de scriere (sau estimări pentru tranzacții în lanț, cum ar fi tranzacțiile Uniswap), ceea ce face ca provocarea să fie mai mult ca un efort asemănător lui Sisif decât ar prefera majoritatea dintre noi.

Mai este o problemă, am ajuns la limita gazului de bloc. Viteza blockchain-ului este de fapt limitată de limita de gaz bloc, care este o barieră autoimpusă menită să crească securitatea și fiabilitatea blockchain-ului. „Regula generală pentru stabilirea limitelor de gaz de blocare este de a se asigura că orice bloc în această limită poate fi procesat în siguranță în timpul de blocare.” Cartea albă descrie limita de gaz de bloc ca un „mecanism de limitare”. fiabil, presupunând că îndeplinește cerințele hardware minime.

Alții spun că limita gazului bloc este o alegere conservatoare pentru a preveni cel mai rău scenariu, care este un alt exemplu de arhitectură blockchain modernă care se concentrează pe securitate în detrimentul scalabilității. Ideea că scalabilitatea este mai importantă decât securitatea se destramă atunci când iei în considerare câți bani sunt transferați între blockchains în fiecare zi și câți bani s-ar pierde pentru a îmbunătăți ușor scalabilitatea, provocând astfel o iarnă nucleară.

Blockchain-urile poate să nu fie grozave pentru a atrage aplicații de înaltă calitate pentru consumatori, dar sunt excepțional de bune la plăți peer-to-peer fără permisiune. Nimeni nu vrea să încurce asta.

Se menționează apoi că viteza EVM paralelă depinde de volumul de lucru, iar performanța lor este blocată de „lanțul lung de dependență” care minimizează „accelerarea” excesivă a funcțiilor blockchain. Singura modalitate de a rezolva această problemă este introducerea prețurilor multidimensionale a gazelor (MegaETH se referă la piața nativă a taxelor Solana), care este încă dificil de implementat. Nu sunt sigur dacă există un EIP dedicat sau cum ar funcționa un astfel de EIP pe EVM, dar cred că din punct de vedere tehnic aceasta este o soluție.

În cele din urmă, utilizatorii nu vor interacționa direct cu nodul secvențer și majoritatea utilizatorilor nu vor rula un nod complet acasă. Prin urmare, experiența reală a utilizatorului a unui blockchain depinde în mare măsură de infrastructura de bază, cum ar fi nodurile și indexatoarele RPC. Indiferent de cât de repede rulează un blockchain live, dacă nodurile RPC nu pot gestiona eficient numărul mare de solicitări de citire în timpul orelor de vârf, propagă rapid tranzacțiile către nodurile secvențatorului sau indexatorul nu poate actualiza vizualizarea aplicației suficient de rapid pentru a ține pasul cu lanțul viteza, atunci nu contează cât de repede rulează blockchain-ul în timp real. "

Poate prea multe de spus, dar foarte important. Cu toții ne bazăm pe Infura, Alchemy, QuickNode etc., iar infrastructura pe care rulează probabil susține toate tranzacțiile noastre. Cea mai simplă explicație pentru această dependență vine din experiență. Dacă ați încercat vreodată să revendicați un airdrop în primele 2-3 ore după un airdrop L2, veți înțelege cât de dificil este pentru RPC să gestioneze acest tip de aglomerație.

3. Concluzie

Acestea fiind spuse, vreau doar să exprim că un proiect precum MegaETH trebuie să treacă prin multe obstacole pentru a ajunge la înălțimile pe care vrea să le atingă. O postare a spus că au reușit să realizeze o dezvoltare de înaltă performanță utilizând o arhitectură blockchain eterogenă și un mediu de execuție EVM super-optimizat. „Astăzi, MegaETH are o rețea de dezvoltare live de înaltă performanță și face progrese constante spre a deveni cel mai rapid blockchain, limitat doar de limitările hardware.”

Github-ul MegaETH enumeră câteva îmbunătățiri majore, inclusiv, dar fără a se limita la: cod octet EVM → compilator de cod nativ, motor de execuție dedicat pentru nodurile mari de sortare a memoriei și protocol eficient de control al concurenței pentru EVM paralel. Acum este disponibil un compilator EVM bytecode/cod nativ numit evmone și, deși nu sunt suficient de bine versat în codificare pentru a cunoaște funcționarea de bază a acestuia, am făcut tot posibilul să-l dezleg.

evmone este o implementare C++ a EVM care preia API-ul EVMC și îl convertește într-un modul de execuție pentru clientul Ethereum. Menționează și alte caracteristici pe care nu le înțeleg, cum ar fi abordarea sa de interpret dual (de bază și avansată) și bibliotecile intx și ethash. În rezumat, evmone oferă o procesare mai rapidă a tranzacțiilor (prin execuție mai rapidă a contractelor inteligente), o mai mare flexibilitate de dezvoltare și o scalabilitate mai mare (presupunând că diferite implementări EVM pot gestiona mai multe tranzacții per bloc) Șansă.

Există alte câteva baze de cod, dar cele mai multe dintre ele sunt destul de standard și nu sunt legate în mod specific de MegaETH (reth, geth). Cred că am terminat destul de mult cu hârtia albă, așa că acum las întrebarea celor care citesc asta: Ce urmează pentru MegaETH? Este cu adevărat posibil să implementăm coduri eficiente de răspândire? Cât timp va dura să se întâmple asta?

În calitate de utilizator blockchain, sunt încântat să văd dacă acest lucru este posibil. Am cheltuit prea mulți bani pe taxele de tranzacție pe rețeaua principală și este timpul pentru o schimbare, dar această schimbare pare tot mai dificil de realizat și este puțin probabil să se întâmple în curând.

Deși conținutul acestui articol se concentrează în principal pe îmbunătățiri arhitecturale și scalabilitate, rollup-urile interne trebuie totuși să partajeze instrumente de lichiditate și cross-chain pentru ca experiența pachetului A să fie compatibilă cu pachetul B. Nu suntem încă acolo, dar poate până în 2037 toată lumea se va așeza și își va aminti cât de obsedați eram de „remedierea” problemelor de scalabilitate.