Vitalik Buterin recunoaște cea mai mare greșeală de design din 2017 – așadar, este Ethereum-ul tău în pericol?

Vitalik Buterin a declarat că nu mai este de acord cu tweet-ul său din 2017 care minimiza necesitatea ca utilizatorii să verifice personal Ethereum de la un capăt la altul.

Săptămâna aceasta, el a susținut că rețeaua ar trebui să trateze verificarea self-hosted ca o cale de scăpare non-negociabilă pe măsură ce arhitectura sa devine mai ușoară și mai modulară.

Poziția inițială a lui Buterin a crescut dintr-o dezbatere de design cu privire la dacă un blockchain ar trebui să se angajeze la starea pe lanț sau să trateze starea ca fiind "implicată", reconstructibilă doar prin redarea tranzacțiilor ordonate.

Abordarea Ethereum, care pune o rădăcină de stare în fiecare antet de bloc și susține dovezile de stil Merkle, permite unui utilizator să dovedească un sold specific, cod de contract sau valoare de stocare fără a reexecuta întregul istoric, atâta timp cât utilizatorul acceptă validitatea consensului lanțului sub o presupunere de majoritate onestă.

În noua sa postare, Buterin a recadrat acel compromis ca fiind incomplet în practică, deoarece poate încă să forțeze utilizatorii să aleagă între redarea lanțului complet sau încrederea într-un intermediar precum un operator RPC, un host de date de arhivare sau un serviciu de dovezi.

Schimbarea de direcție a lui Vitalik privind verificarea personală a istoricului blockchain

El a ancorat schimbarea în două deplasări: fezabilitate și fragilitate.

Cu privire la fezabilitate, Buterin a scris că dovezile cu cunoștințe zero oferă acum o cale de a verifica corectitudinea fără a "reexecuta literal fiecare tranzacție."

În 2017, el a susținut că acest lucru ar fi împins Ethereum către o capacitate mai mică pentru a menține verificarea la îndemână.

Schimbarea contează deoarece foaia de parcurs publică a Ethereum tratează din ce în ce mai mult ZK ca o primitivă de verificabilitate, ethereum.org prezentând dovezile cu cunoștințe zero ca o modalitate de a păstra proprietățile de securitate reducând în același timp ceea ce un verificator trebuie să calculeze.

Lucrarea asupra direcțiilor "ZK-light-client" indică, de asemenea, către un model în care un dispozitiv poate sincroniza folosind dovezi compacte, în loc să aibă încredere într-o poartă mereu online.

Cu privire la fragilitate, Buterin a enumerat moduri de eșec care se situează în afara modelelor de amenințare curate: rețele p2p degradate, servicii de lungă durată care se închid, concentrarea validatorilor care schimbă semnificația practică a "majorității oneste" și presiunea informală de guvernare care transformă "apelarea dezvoltatorilor" în sprijin de rezervă.

El a citat presiunea de cenzură în jurul Tornado Cash ca exemplu al modului în care intermediarii pot restrânge accesul, susținând că opțiunea de ultimă instanță a unui utilizator ar trebui să fie "utilizarea directă a lanțului."

Acea încadrare se aliniază cu discuția mai largă despre consolidarea nivelului de bază al Ethereum și limitarea schimbărilor, pe fondul unei presiuni către "osificarea" protocolului.

În povestirea lui Buterin, "cabana de munte" nu este un stil de viață implicit.

Este o opțiune de rezervă credibilă care schimbă stimulentele, deoarece cunoașterea faptului că utilizatorii pot ieși reduce influența oricărui singur nivel de serviciu.

Acel argument se produce în momentul în care Ethereum reduce ceea ce nodurile obișnuite sunt așteptate să stocheze, în timp ce povestea de verificare a rețelei trebuie să țină pasul.

Utilizarea și istoricul clientului Ethereum

Clienții de execuție se îndreaptă către expirarea parțială a istoricului, iar Fundația Ethereum a declarat că utilizatorii pot reduce utilizarea discului cu aproximativ 300-500 GB prin eliminarea datelor de bloc pre-Merge, punând un nod la îndemână pe un disc de 2 TB.

În același timp, clienții light reflectă deja un model de încredere formalizat optimizat pentru dispozitive cu resurse reduse, bazându-se pe un comitet de sincronizare de 512 validatori selectați la fiecare 1,1 zile aproximativ.

Acești parametri fac ca verificarea light-client să fie funcțională la scară.

Cu toate acestea, ele concentrează, de asemenea, experiența utilizatorului în jurul disponibilității datelor corecte și a releelor bine comportate atunci când condițiile se deteriorează.

Lucrarea pe termen lung "statelessness" a Ethereum urmărește să reducă nevoia nodurilor de a deține stare mare, menținând în același timp validarea blocurilor intactă.

Ethereum.org avertizează că "statelessness" este o denumire greșită, distingând formele mai slabe de designurile mai puternice care rămân cercetare, inclusiv expirarea stării.

Arborii Verkle se încadrează în acel plan deoarece reduc dimensiunile dovezilor și sunt poziționați ca un pas cheie de activare către validarea fără stocarea stării mari local.

Pe măsură ce mai multă povară de stocare se deplasează în exterior, fie către gazde de istoric specializate, fie către alte rețele de date, povestea de securitate devine mai puțin despre cine poate stoca totul și mai mult despre cine poate verifica independent corectitudinea și recupera ceea ce au nevoie atunci când o cale implicită eșuează.

Ce înseamnă acest lucru în continuare

În următoarele 12-36 de luni, întrebarea practică este dacă verificarea se extinde în exterior pe măsură ce Ethereum externalizează mai multe poveri de stocare sau dacă încrederea se grupează în jurul noilor puncte de sufocare ale serviciului.

O cale este ca portofelele și infrastructura să treacă de la "încredere în RPC" la "verifică dovada", în timp ce producția de dovezi se consolidează într-un set mic de stive optimizate care sunt dificil de replicat, mutând dependența de la o clasă de furnizor la alta.

O altă cale este ca verificarea bazată pe dovezi să devină obișnuită, cu implementări de probare redundante și instrumente care permit utilizatorilor să schimbe furnizorii sau să verifice local atunci când un punct final cenzurează, se degradează sau dispare, aliniindu-se cu eforturile care vizează fluxuri de verificare ușoare.

O a treia cale este că eliminarea și modularitatea progresează mai repede decât UX-ul de verificare, lăsând utilizatorii cu mai puține opțiuni funcționale în timpul întreruperilor sau evenimentelor de cenzură.

Acest lucru ar face ca "cabana de munte" să fie operațional reală doar pentru o porțiune îngustă a rețelei.

Buterin a încadrat cabana ca BATNA a Ethereum, rareori utilizată, dar mereu disponibilă, deoarece existența unei opțiuni autosuficiente constrânge termenii impuși de intermediari.

El a încheiat susținând că menținerea acelei opțiuni de rezervă face parte din menținerea Ethereum însuși.

Postarea Vitalik Buterin admits his biggest design mistake since 2017 – so is your Ethereum at risk? a apărut prima dată pe CryptoSlate.