Ethereum dorește ca validatorii casnici să verifice dovezile, dar realitatea cu 12 GPU-uri ridică o nouă amenințare

Cercetătorul Ethereum ladislaus.eth a publicat săptămâna trecută un ghid explicând cum Ethereum plănuiește să treacă de la re-executarea fiecărei tranzacții la verificarea dovezilor cu cunoștințe zero.

Postarea o prezintă ca pe o „transformare discretă, dar fundamentală", și această încadrare este precisă. Nu pentru că munca este secretă, ci pentru că implicațiile sale se răspândesc în întreaga arhitectură Ethereum în moduri care nu vor fi evidente până când piesele se vor conecta.

Nu este vorba despre Ethereum „adăugând ZK" ca o funcționalitate. Ethereum creează un prototip pentru o cale alternativă de validare în care unii validatori pot atesta blocuri prin verificarea dovezilor de execuție compacte, mai degrabă decât prin re-executarea fiecărei tranzacții.

Dacă funcționează, rolul layer-1 al Ethereum se deplasează de la „decontare și disponibilitatea datelor pentru rollup-uri" către „execuție de mare capacitate a cărei verificare rămâne suficient de ieftină pentru validatorii casnici".

Ce se construiește de fapt

EIP-8025, intitulat „Optional Execution Proofs", a fost lansat în formă de draft și specifică mecanica.
Dovezile de execuție sunt partajate în rețeaua peer-to-peer a stratului de consens printr-un subiect dedicat. Validatorii pot opera în două moduri noi: generare de dovezi sau validare fără stare.

Propunerea menționează în mod explicit că „nu necesită un hardfork" și rămâne compatibilă retroactiv, în timp ce nodurile pot totuși să re-execute așa cum fac astăzi.

Echipa zkEVM a Ethereum Foundation a publicat pe 26 ianuarie o foaie de parcurs concretă pentru 2026, prezentând șase sub-teme: standardizarea martor de execuție și program invitat, standardizarea API zkVM-invitat, integrarea stratului de consens, infrastructura prover, benchmarking și metrici, și securitate cu verificare formală.

Primul apel breakout L1-zkEVM este programat pentru 11 februarie la 15:00 UTC.

Pipeline-ul end-to-end funcționează astfel: un client de strat de execuție produce un ExecutionWitness, un pachet autonom care conține toate datele necesare pentru validarea unui bloc fără a deține starea completă.

Un program invitat standardizat consumă acel martor și validează tranziția de stare. Un zkVM execută acest program, iar un prover generează o dovadă a execuției corecte. Clientul stratului de consens verifică apoi acea dovadă în loc să apeleze clientul stratului de execuție pentru a re-executa.

Dependența cheie este ePBS (Enshrined Proposer-Builder Separation), țintit pentru următorul hardfork Glamsterdam. Fără ePBS, fereastra de demonstrare este aproximativ unu până la două secunde, ceea ce este prea strâns pentru demonstrarea în timp real. Cu ePBS oferind pipelining de blocuri, fereastra se extinde la șase până la nouă secunde.

Graficul arată că ePBS extinde fereastra de demonstrare a Ethereum de la 1-2 secunde la 6-9 secunde, făcând fezabilă generarea de dovezi în timp real comparativ cu timpul mediu actual de demonstrare de șapte secunde care necesită 12 GPU-uri.

Compromisul descentralizării

Dacă dovezile opționale și formatele martorilor se maturizează, mai mulți validatori casnici pot participa fără a menține starea completă a stratului de execuție.

Creșterea limitelor de gaz devine mai ușoară politic și economic deoarece costul de validare se decuplează de complexitatea execuției. Munca de verificare nu mai scalează liniar cu activitatea on-chain.

Cu toate acestea, demonstrarea aduce propriul risc de centralizare. O postare Ethereum Research din 2 februarie raportează că demonstrarea unui bloc Ethereum complet necesită în prezent aproximativ 12 GPU-uri și durează în medie 7 secunde.

Autorul semnalează îngrijorări cu privire la centralizare și observă că limitele rămân dificil de prezis. Dacă demonstrarea rămâne intensivă în GPU și se concentrează în rețele de constructori sau proveri, Ethereum poate schimba „toată lumea re-execută" cu „puțini demonstrează, mulți verifică".

Designul urmărește să rezolve acest lucru prin introducerea diversității clienților la stratul de demonstrare. Presupunerea de lucru a EIP-8025 este un prag de trei din cinci, ceea ce înseamnă că un attestator acceptă execuția unui bloc ca validă odată ce a verificat trei din cinci dovezi independente de la diferite implementări de clienți de strat de execuție.

Acest lucru păstrează diversitatea clienților la nivelul protocolului, dar nu rezolvă problema accesului la hardware.

Cea mai sinceră încadrare este că Ethereum deplasează câmpul de luptă al descentralizării. Constrângerea de astăzi este „îți poți permite să rulezi un client de strat de execuție?" Cea de mâine ar putea fi „ai acces la clustere GPU sau rețele de proveri?"

Pariul este că verificarea dovezii este mai ușor de transformat în marfă decât stocarea și re-executarea stării, dar problema hardware-ului rămâne deschisă.

Deblocarea scalării L1

Foaia de parcurs a Ethereum, actualizată ultima dată pe 5 februarie, enumeră „Statelessness" ca o temă majoră de upgrade: verificarea blocurilor fără stocarea unei stări mari.

Dovezile de execuție opționale și martorii sunt mecanismul concret care face validarea fără stare practică. Un nod fără stare necesită doar un client de consens și verifică dovezile în timpul procesării payload-ului.

Sincronizarea se reduce la descărcarea dovezilor pentru blocurile recente de la ultimul punct de control de finalizare.

Acest lucru contează pentru limitele de gaz. Astăzi, fiecare creștere a limitei de gaz face rularea unui nod mai dificilă. Dacă validatorii pot verifica dovezi în loc să re-execute, costul de verificare nu mai scalează cu limita de gaz. Complexitatea execuției și costul de validare se decuplează.

Fluxul de lucru de benchmarking și repricing din foaia de parcurs 2026 vizează în mod explicit metrici care mapează gazul consumat la ciclurile de demonstrare și timpul de demonstrare.

Dacă acele metrici se stabilizează, Ethereum câștigă o pârghie pe care nu a avut-o până acum: capacitatea de a crește throughput-ul fără a crește proporțional costul de rulare a unui validator.

Ce înseamnă acest lucru pentru blockchain-urile layer-2

O postare recentă de Vitalik Buterin argumentează că blockchain-urile layer-2 ar trebui să se diferențieze dincolo de scalare și leagă în mod explicit valoarea unui „native rollup precompile" de nevoia de dovezi zkEVM consacrate pe care Ethereum le necesită deja pentru a scala layer-1.

Logica este directă: dacă toți validatorii verifică dovezile de execuție, aceleași dovezi pot fi folosite și de un precompile EXECUTE pentru rollup-uri native. Infrastructura de demonstrare layer-1 devine infrastructură partajată.

Acest lucru schimbă propunerea de valoare layer-2. Dacă layer-1 poate scala la throughput ridicat menținând costurile de verificare scăzute, rollup-urile nu se pot justifica pe baza „Ethereum nu poate gestiona sarcina".

Noile axe de diferențiere sunt mașini virtuale specializate, latență ultra-scăzută, preconfirmări și modele de componibilitate precum rollup-uri care se bazează pe designuri de demonstrare rapidă.

Scenariul în care layer-2-urile rămân relevante este unul în care rolurile sunt împărțite între specializare și interoperabilitate.

Layer-1 devine stratul de execuție și decontare de mare capacitate și cost scăzut de verificare. Layer-2-urile devin laboratoare de funcționalități, optimizatori de latență și punți de componibilitate.

Cu toate acestea, acest lucru necesită ca echipele layer-2 să articuleze noi propuneri de valoare și ca Ethereum să livreze pe foaia de parcurs de verificare a dovezilor.

Trei căi înainte

Există trei scenarii potențiale în viitor.

Primul scenariul constă în validarea cu dovadă-întâi devenind comună. Dacă dovezile opționale și formatele martorilor se maturizează și implementările clienților se stabilizează în jurul interfețelor standardizate, mai mulți validatori casnici pot participa fără a rula starea completă a stratului de execuție.

Limitele de gaz cresc deoarece costul de validare nu mai este aliniat cu complexitatea execuției. Această cale depinde de fluxul de lucru de standardizare ExecutionWitness și program invitat convergând pe formate portabile.

Scenariul doi este unde centralizarea prover devine noul punct de blocaj. Dacă demonstrarea rămâne intensivă în GPU și concentrată în rețele de constructori sau proveri, atunci Ethereum deplasează câmpul de luptă al descentralizării de la hardware-ul validatorilor la structura pieței prover.

Protocolul funcționează încă, deoarece un prover onest oriunde menține lanțul live, dar modelul de securitate se schimbă.

Al treilea scenariu este verificarea dovezilor layer-1 devenind o infrastructură partajată. Dacă integrarea stratului de consens se întărește și ePBS livrează fereastra extinsă de demonstrare, atunci propunerea de valoare a Layer 2 se înclină către VM-uri specializate, latență ultra-scăzută și modele noi de componibilitate mai degrabă decât doar „scalarea Ethereum".

Această cale necesită ca ePBS să fie livrat la timp pentru Glamsterdam.

Scenariu	Ce trebuie să fie adevărat (precondiții tehnice)	Ce se strică / risc principal	Ce se îmbunătățește (descentralizare, limite de gaz, timp de sincronizare)	Rezultat rol L1 (throughput execuție vs cost verificare)	Implicație L2 (axă nouă de diferențiere)	Semnal „Ce să urmărești"
Validarea cu dovadă-întâi devine comună	Standardele Execution Witness + program invitat converg; zkVM/guest API se standardizează; calea de verificare a dovezilor CL este stabilă; dovezile se propagă fiabil pe P2P; semantică acceptabilă a pragului multi-dovadă (ex. 3-din-5)	Disponibilitatea / latența dovezilor devine o nouă dependență; erorile de verificare devin sensibile la consens dacă/când se bazează pe acestea; nepotrivire între clienți/proveri	Validatorii casnici pot atesta fără stare EL; timpul de sincronizare scade (dovezi de la punctul de control de finalizare); creșterile limitei de gaz devin mai ușoare deoarece costul de verificare se decuplează de complexitatea execuției	L1 se deplasează către execuție de throughput mai mare cu cost de verificare constant-ish pentru mulți validatori	L2-urile trebuie să se justifice dincolo de „L1 nu poate scala": VM-uri specializate, execuție specifică aplicației, modele de taxe personalizate, confidențialitate, etc.	Întărirea spec/test-vector; portabilitate martor/invitat între clienți; gossip dovadă stabil + gestionare eșecuri; curbe benchmark (gaz → cicluri/timp demonstrare)
Centralizarea prover devine punctul de blocaj	Generarea dovezilor rămâne intensivă în GPU; piața de demonstrare se consolidează (constructori / rețele prover); demonstrare „la scară garaj" limitată; liveness se bazează pe un set mic de proveri sofisticați	„Puțini demonstrează, mulți verifică" concentrează puterea; dinamica cenzurii / MEV se intensifică; întreruperile prover creează stres de liveness/finalitate; risc de concentrare geografică / de reglementare	Validatorii pot verifica încă ieftin, dar deplasări descentralizate: atestare mai ușoară, demonstrare mai grea; ceva spațiu limită-gaz, dar constrâns de economia prover	L1 devine scalabil în execuție în teorie, dar practic limitat de capacitatea prover și structura pieței	L2-urile se pot orienta către designuri based / pre-confirmate, sisteme alternative de demonstrare sau garanții de latență—potențial crescând dependența de actori privilegiați	Tendințe cost demonstrare (cerințe hardware, timp per bloc); metrici diversitate prover; stimulente pentru demonstrare distribuită; exerciții mod-eșec (ce se întâmplă când lipsesc dovezile?)
Verificarea dovezilor L1 devine infrastructură partajată	Integrarea CL „se întărește"; dovezile devin produse / consumate pe scară largă; ePBS livrează și oferă o fereastră de demonstrare funcțională; interfețele permit reutilizarea (ex. precompile stil EXECUTE / hook-uri rollup native)	Risc de cuplare trans-domeniu: dacă infrastructura de demonstrare L1 este stresată, căile de verificare rollup ar putea suferi de asemenea; complexitatea / suprafața de atac se extinde	Infrastructura partajată reduce efortul duplicat de demonstrare; îmbunătățește interoperabilitatea; costuri de verificare mai previzibile; cale mai clară către throughput L1 mai mare fără a exclude validatorii prin preț	L1 evoluează într-un strat de execuție + decontare verificat prin dovadă care poate verifica rollup-uri nativ	L2-urile pivotează către latență (preconfs), medii de execuție specializate și modele componibile (ex. designuri de demonstrare rapidă / sincron-ish) mai degrabă decât doar „scalare"	Progres ePBS / Glamsterdam; demo-uri pipeline end-to-end (martor → dovadă → verificare CL); benchmark-uri + posibilă repricing gaz; lansarea semanticii minime viabile de distribuție a dovezilor și monitorizare

Imaginea de ansamblu

Maturitatea integrării consensus-specs va semnala dacă „dovezile opționale" trec de la majoritatea TODO-uri la vectori de test întăriți.

Standardizarea ExecutionWitness și a programului invitat este piatra de temelie pentru portabilitatea validării fără stare între clienți. Benchmark-urile care mapează gazul consumat la ciclurile de demonstrare și timpul de demonstrare vor determina dacă repricing-ul gazului pentru prietenie ZK este fezabil.

Progresul ePBS și Glamsterdam va indica dacă fereastra de demonstrare de șase până la nouă secunde devine realitate. Rezultatele apelului breakout vor dezvălui dacă grupurile de lucru converg pe interfețe și semantică minimă viabilă de distribuție a dovezilor.

Ethereum nu trece la validarea bazată pe dovezi în curând. EIP-8025 menționează în mod explicit că „nu poate baza upgrade-uri pe acesta încă", iar încadrarea opțională este intenționată. Ca rezultat, aceasta este o cale testabilă mai degrabă decât o activare iminentă.

Totuși, faptul că Ethereum Foundation a livrat o foaie de parcurs de implementare 2026, a programat un apel breakout cu proprietarii de proiecte și a redactat un EIP cu mecanică concretă de gossip peer-to-peer înseamnă că această muncă s-a mutat de la plauzibilitatea cercetării la un program de livrare.

Transformarea este discretă deoarece nu implică schimbări dramatice ale economiei token-urilor sau funcționalități orientate către utilizator. Dar este fundamentală deoarece rescrie relația dintre complexitatea execuției și costul de validare.

Dacă Ethereum poate decupla cele două, layer-1 nu va mai fi blocajul care forțează tot ce este interesant pe layer-2.

Și dacă verificarea dovezilor layer-1 devine infrastructură partajată, întregul ecosistem layer-2 trebuie să răspundă la o întrebare mai dificilă: ce construiești tu pe care layer-1 nu poate?

Postarea Ethereum wants home validators to verify proofs but a 12 GPU reality raises a new threat a apărut prima dată pe CryptoSlate.