Un aspect important, și mereu subestimat, al "lipsei de încredere", "trecerii testului de plecare" și "autosuveranității" este simplitatea protocolului. Chiar dacă un protocol este extrem de descentralizat, cu sute de mii de noduri și are o toleranță la defecte bizantine de 49%, iar nodurile verifică complet totul cu peerdas și stark sigure pentru nivel cuantic, dacă protocolul este un haos greu de gestionat de sute de mii de linii de cod și cinci forme de criptografie la nivel de doctorat, în cele din urmă protocolul eșuează toate cele trei teste: * Nu este fără încredere pentru că trebuie să ai încredere într-o mică clasă de mari preoți care îți spun ce proprietăți are protocolul * Nu trece testul de "walk-out" pentru că, dacă echipele cliente existente dispar, este extrem de greu pentru noile echipe să ajungă la același nivel de calitate * Nu este autosuveran pentru că dacă nici cei mai tehnici oameni nu pot inspecta și înțelege lucrurile, nu este pe deplin ale tale De asemenea, este mai puțin sigur, deoarece fiecare parte a protocolului, mai ales dacă poate interacționa cu alte părți în moduri complicate, implică riscul ca protocolul să se întrerupă. Una dintre temerile mele legate de dezvoltarea protocoalelor Ethereum este că putem fi prea dornici să adăugăm funcționalități noi pentru a răspunde unor nevoi foarte specifice, chiar dacă acele funcționalități suprasolicită protocolul sau adaugă tipuri complet noi de componente interacționante sau criptografie complicată ca dependențe critice. Acest lucru poate fi util pentru câștiguri funcționale pe termen scurt, dar este extrem de distructiv pentru păstrarea suveranității personale pe termen lung și crearea unei hiperstructuri descentralizate de o sută de ani care transcende ascensiunea și căderea imperiilor și ideologiilor. Problema de bază este că, dacă modificările de protocol sunt evaluate din perspectiva "cât de mari sunt ele ca modificări ale protocolului existent", atunci dorința de a păstra compatibilitatea retroactivă înseamnă că adăugirile au loc mult mai des decât scăderile, iar protocolul inevitabil se umflă în timp. Pentru a contracara acest lucru, procesul de dezvoltare Ethereum necesită o funcție explicită de "simplificare" / "colectare a gunoiului". "Simplificarea" are trei metrici: * Minimizarea numărului total de linii de cod din protocol. Un protocol ideal se potrivește pe o singură pagină – sau cel puțin pe câteva pagini * Evitarea dependențelor inutile de componente tehnice fundamental complexe. De exemplu, un protocol a cărui securitate depinde exclusiv de hash-uri (și mai bine: de exact o funcție hash) este mai bun decât unul care depinde de hash-uri și rețele. Adăugarea izogeniilor este cea mai rea, pentru că (scuze pentru tocilarilor cu adevărat muncitori care au descoperit asta) nimeni nu înțelege izogenii. * Adăugarea mai multor _invariante_: proprietăți de bază pe care protocolul se poate baza, de exemplu EIP-6780 (eliminarea autodistrugerii) a adăugat proprietatea că cel mult N sloturi de stocare pot fi schimbate pe slot, simplificând semnificativ dezvoltarea clientului, iar EIP-7825 (capac de gaz per-tx) a adăugat un maxim la costul procesării unei singure tranzacții, ceea ce ajută mult ZK-EVM-urile și execuția paralelă. Colectarea gunoiului poate fi fragmentată sau la scară largă. Abordarea fragmentată încearcă să ia funcționalitățile existente și să le simplifice astfel încât să fie mai simple și să aibă mai mult sens. Un exemplu este reformele privind costul gazului din Glamsterdam, care fac ca multe costuri ale gazului, anterior arbitrare, să depindă de un număr mic de parametri clar legați de consumul de resurse. O colectare a gunoiului la scară largă a fost înlocuirea PoW cu PoS. Un altul este probabil să aibă loc ca parte a consensului Lean, deschizând spațiul pentru a corecta un număr mare de greșeli în același timp ( ). O altă abordare este "compatibilitatea inversă în stil Rosetta", unde funcționalitățile complexe, dar puțin folosite, rămân utilizabile, dar sunt "retrogradate" din protocolul obligatoriu și devin cod de contract inteligent, astfel încât noii dezvoltatori de clienți nu trebuie să se deranjeze cu ele. Exemple: * După ce facem upgrade la abstracție nativă completă a contului, toate tipurile vechi de transfer pot fi retrase, iar EOA-urile pot fi convertite în portofele smart contract al căror cod poate procesa toate aceste tipuri de tranzacții * Putem înlocui precompilarile existente (cu excepția celor care sunt _cu adevărat_ necesare) cu EVM sau cod RISC-V ulterior * Putem în cele din urmă să schimbăm VM-ul din EVM în RISC-V (sau altă VM mai simplă); EVM ar putea fi transformat într-un contract inteligent în noua mașină virtuală. În final, vrem să ne îndepărtăm de faptul că dezvoltatorii clienți simt nevoia să gestioneze toate versiunile mai vechi ale protocolului Ethereum. Acest lucru poate fi lăsat în seama versiunilor mai vechi de client care rulează în containere docker. Pe termen lung, sper ca rata de schimbare a Ethereum să fie mai lentă. Cred că, din diverse motive, în cele din urmă asta _trebuie_ să se întâmple. Acești primii cincisprezece ani ar trebui priviți parțial ca o etapă a adolescenței în care am explorat multe idei și am văzut ce funcționează și ce este util și ce nu. Ar trebui să ne străduim să evităm ca părțile care nu sunt utile să fie o povară permanentă pentru protocolul Ethereum. Practic, vrem să îmbunătățim Ethereum într-un mod care să arate astfel: