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:

2026 este anul în care recuperăm terenul pierdut în ceea ce privește autosuveranitatea și lipsa de încredere. Unele dintre ce înseamnă practic asta: Noduri complete: datorită ZK-EVM și BAL, va deveni din nou mai ușor să rulezi local un nod și să verifici lanțul Ethereum pe propriul calculator. Helios: verifică efectiv datele pe care le primești de la RPC-uri în loc să ai încredere oarbă în ele. ORAM, PIR: cere date de la RPC-uri fără să dezvălui ce date ceri, ca să poți accesa dapp-urile fără ca tiparele tale de acces să fie vândute către zeci de terți din întreaga lume. Portofelele de recuperare socială și timelock-urile: portofele care nu te fac să pierzi toți banii dacă îți pierzi seedphrase-ul sau dacă un atacator online sau offline îți extrage seedphrase-ul și *de asemenea* nu fac toți banii tăi pe backdoor de către Google. UX de confidențialitate: efectuează plăți private din portofelul tău, cu aceeași experiență de utilizare ca și plățile publice. Rezistență la cenzura confidențialității: plăți private cu mempool-ul ERC-4337 și, în curând, AA + FOCIL nativ, fără a se baza pe ecosistemul radiodifuzorului public. Interfețele aplicațiilor: folosește mai multe dapp-uri dintr-o interfață onchain cu IPFS, fără a te baza pe servere de încredere care te-ar bloca recuperarea practică a activelor tale dacă acestea ar fi offline și ți-ar oferi o interfață deturnată care îți fură fondurile dacă sunt sparse măcar o fracțiune de secundă. În multe dintre aceste domenii, în ultimii zece ani am asistat la un regres serios în Ethereum. Nodurile au trecut de la ușor de folosit la greu de condus. Dapp-urile au trecut de la pagini statice la uriașe complicate care îți scurg toate datele către o duzină de servere. Portofelele au trecut de la a ruta totul prin RPC, care putea fi orice nod la alegere, inclusiv pe propriul tău calculator, la a scurge datele către o duzină de servere la alegerea lor. Construirea de blocuri a devenit mai centralizată, punând garanțiile de includere a tranzacțiilor Ethereum sub controlul unui număr foarte mic de constructori. În 2026, nu va mai exista. Fiecare compromis de valori pe care Ethereum l-a făcut până acum – fiecare moment în care te-ai fi gândit dacă merită cu adevărat să ne diluăm atât de mult în numele adoptării pe scară largă – nu mai facem acel compromis. Va fi un drum lung. Nu vom obține tot ce ne dorim în următoarea versiune Kohaku, sau în următorul hard fork, sau în hard fork-ul de după aceea. Dar va transforma Ethereum într-un ecosistem care merită nu doar locul său actual în univers, ci și unul mult mai mare. În world computer, nu există un stăpân centralizat. Nu există un singur punct de eșec. Există doar dragoste. Doamnă.