L’investigador d’Ethereum, ladislaus.eth, va publicar una guia la setmana passada explicant com Ethereum té previst passar de tornar a executar cada transacció a verificar proves de coneixement zero.
El post l’emmarca com una “transformació tranquil·la però fonamental” i l’enquadrament és precís. No perquè l’obra sigui secreta, sinó perquè les seves implicacions afecten tota l’arquitectura d’Ethereum d’una manera que no serà evident fins que les peces es connectin.
Això no és Ethereum “afegir ZK” com a característica. Ethereum està creant un prototip d’una ruta de validació alternativa en què alguns validadors poden donar fe dels blocs verificant proves d’execució compactes en lloc de tornar a executar cada transacció.
Si funciona, el paper de la capa 1 d’Ethereum passa de “liquidació i disponibilitat de dades per a acumulacions” a “execució d’alt rendiment la verificació de la qual es manté prou barata per als validadors domèstics”.
Què s’està construint realment
EIP-8025, titulat “Proves d’execució opcionals”, va aterrar en forma d’esborrany i especifica la mecànica.
Les proves d’execució es comparteixen a través de la xarxa peer-to-peer de la capa de consens mitjançant un tema dedicat. Els validadors poden operar en dos nous modes: generació de proves o validació sense estat.
La proposta indica explícitament que “no requereix una forca” i segueix sent compatible amb les versions anteriors, mentre que els nodes encara es poden tornar a executar com ho fan avui.
L’equip zkEVM de la Fundació Ethereum va publicar un full de ruta concret per al 2026 el 26 de gener, que descriu sis subtemes: estandardització del programa convidat i testimoni d’execució, estandardització de l’API zkVM-guest, integració de la capa de consens, infraestructura de proves, benchmarking i mètriques i seguretat amb verificació formal.
La primera trucada extraordinària L1-zkEVM està programada per a l’11 de febrer a les 15:00 UTC.
El pipeline d’extrem a extrem funciona així: un client de capa d’execució produeix un ExecutionWitness, un paquet autònom que conté totes les dades necessàries per validar un bloc sense mantenir l’estat complet.
Un programa de convidats estandarditzat consumeix aquest testimoni i valida la transició estatal. Un zkVM executa aquest programa i un provador genera una prova de l’execució correcta. Aleshores, el client de la capa de consens verifica aquesta prova en lloc de trucar al client de la capa d’execució perquè es torni a executar.
La dependència clau és ePBS (Enshrined Proposer-Builder Separation), objectiu per a la propera forca de Glamsterdam. Sense ePBS, la finestra de prova és d’aproximadament un o dos segons, cosa que és massa ajustada per a la prova en temps real. Amb ePBS que proporciona canalització de blocs, la finestra s’estén de sis a nou segons.
El compromís de la descentralització
Si les proves opcionals i els formats de testimoni maduren, més validadors domèstics podran participar sense mantenir l’estat complet de la capa d’execució.
Augmentar els límits de gas es fa políticament i econòmicament més fàcil perquè el cost de validació es desvincula de la complexitat d’execució. El treball de verificació ja no s’escala linealment amb l’activitat en cadena.
Tanmateix, la prova comporta el seu propi risc de centralització. Una publicació d’Ethereum Research del 2 de febrer informa que demostrar un bloc complet d’Ethereum actualment requereix aproximadament 12 GPU i triga una mitjana de 7 segons.
L’autor manifesta les preocupacions sobre la centralització i assenyala que els límits segueixen sent difícils de predir. Si la prova continua sent pesada per la GPU i es concentra en xarxes de generadors o proves, Ethereum pot canviar “tothom torna a executar” per “poques proves, molts verifiquen”.
El disseny pretén abordar això introduint la diversitat de clients a la capa de prova. El supòsit de treball de l’EIP-8025 és un llindar de tres de cinc, és a dir, un acreditador accepta l’execució d’un bloc com a vàlida un cop ha verificat tres de les cinc proves independents de diferents implementacions de client de capa d’execució.
Això preserva la diversitat del client a nivell de protocol però no resol el problema d’accés al maquinari.
L’enquadrament més honest és que Ethereum està canviant el camp de batalla de la descentralització. La restricció d’avui és “us podeu permetre el luxe d’executar un client de capa d’execució?” El de demà podria ser “podeu accedir a clústers de GPU o xarxes de prova?”
L’aposta és que la verificació de proves és més fàcil de comercialitzar que l’emmagatzematge i la reexecució de l’estat, però la qüestió del maquinari continua oberta.
Desbloqueig d’escala L1
El full de ruta d’Ethereum, actualitzat per darrera vegada el 5 de febrer, enumera “Statelessness” com un tema d’actualització important: verificar blocs sense emmagatzemar un estat gran.
Les proves d’execució opcionals i els testimonis són el mecanisme concret que fa que la validació sense estat sigui pràctica. Un node sense estat només requereix un client de consens i verifica les proves durant el processament de la càrrega útil.
La sincronització es redueix a la descàrrega de proves dels blocs recents des de l’últim punt de control de finalització.
Això és important per als límits de gas. Avui dia, cada augment del límit de gas fa que l’execució d’un node sigui més difícil. Si els validadors poden verificar les proves en lloc de tornar a executar, el cost de verificació ja no s’escala amb el límit de gas. La complexitat d’execució i la desacoblament dels costos de validació.
El flux de treball d’avaluació comparativa i revalorització del full de ruta del 2026 s’orienta explícitament a mètriques que mapegen el gas consumit als cicles de prova i al temps de prova.
Si aquestes mètriques s’estabilitzen, Ethereum guanya una palanca que no havia tingut abans: la capacitat d’augmentar el rendiment sense augmentar proporcionalment el cost d’executar un validador.
Què significa això per a les cadenes de blocs de capa 2
Una publicació recent de Vitalik Buterin argumenta que les cadenes de blocs de la capa 2 haurien de diferenciar-se més enllà de l’escala i lliga explícitament el valor d’una “precompilació de rollup nativa” amb la necessitat de proves de zkEVM consagrats que Ethereum ja necessita escalar la capa 1.
La lògica és senzilla: si tots els validadors verifiquen les proves d’execució, les mateixes proves també poden ser utilitzades per una precompilació EXECUTE per a acumulacions natives. La infraestructura de prova de la capa 1 es converteix en una infraestructura compartida.
Això canvia la proposta de valor de la capa 2. Si la capa 1 pot escalar a un alt rendiment i mantenint els costos de verificació baixos, les acumulacions no es poden justificar sobre la base de “Ethereum no pot gestionar la càrrega”.
Els nous eixos de diferenciació són màquines virtuals especialitzades, latència ultra baixa, preconfirmacions i models de composició com ara rollups que es basen en dissenys de prova ràpida.
L’escenari on les capes 2 segueixen sent rellevants és aquell en què els rols es divideixen entre l’especialització i la interoperabilitat.
La capa 1 es converteix en la capa d’execució i liquidació d’alt rendiment i baix cost de verificació. Els Layer-2 es converteixen en laboratoris de funcions, optimitzadors de latència i ponts de composició.
Tanmateix, això requereix que els equips de la capa 2 articulin noves propostes de valor i que Ethereum compleixi el full de ruta de verificació de proves.
Tres camins endavant
Hi ha tres escenaris potencials en el futur.
El primer escenari consisteix en que la validació de la prova primer esdevingui habitual. Si les proves opcionals i els formats de testimoni maduren i les implementacions del client s’estabilitzen al voltant d’interfícies estandarditzades, més validadors domèstics podran participar sense executar l’estat complet de la capa d’execució.
Els límits de gas augmenten perquè el cost de validació ja no s’alinea amb la complexitat d’execució. Aquest camí depèn del flux de treball d’estandardització del programa convidat i ExecutionWitness que convergeix en formats portàtils.
El segon escenari és on la centralització del provador es converteix en el nou punt d’asfixia. Si la prova continua sent pesada en GPU i concentrada en xarxes de generadors o proves, aleshores Ethereum canvia el camp de batalla de la descentralització del maquinari dels validadors a l’estructura del mercat de proves.
El protocol segueix funcionant, ja que un provador honest a qualsevol lloc manté la cadena viva, però el model de seguretat canvia.
El tercer escenari és que la verificació de prova de capa 1 es converteixi en una infraestructura compartida. Si la integració de la capa de consens s’endureix i l’ePBS ofereix la finestra de prova ampliada, la proposta de valor de la capa 2 s’inclina cap a màquines virtuals especialitzades, una latència molt baixa i nous models de composició en lloc d'”escalar Ethereum” només.
Aquesta ruta requereix que l’ePBS s’enviï segons el calendari previst per a Glamsterdam.
La imatge més gran
La maduresa de la integració de les especificacions de consens indicarà si les “proves opcionals” passen de la majoria de TODO a vectors de prova endurits.
L’estandardització del programa ExecutionWitness i convidat és la clau per a la portabilitat de validació sense estat entre clients. Els punts de referència que mapegen el gas consumit amb els cicles de prova i el temps de prova determinaran si la revalorització del gas per a la compatibilitat amb ZK és factible.
El progrés d’ePBS i Glamsterdam indicarà si la finestra de prova de sis a nou segons esdevé una realitat. Les sortides de les trucades desglossades revelaran si els grups de treball convergeixen en interfícies i una semàntica de distribució de proves mínima viable.
Ethereum no canviarà aviat a la validació basada en proves. L’EIP-8025 indica explícitament que “encara no es poden basar les actualitzacions en ell”, i l’enquadrament opcional és intencionat. Com a resultat, aquesta és una via provable en lloc d’una activació imminent.
No obstant això, el fet que la Fundació Ethereum hagi enviat un full de ruta per a la implementació del 2026, hagi programat una trucada amb els propietaris del projecte i hagi redactat un EIP amb mecàniques concretes de xafarderies peer-to-peer significa que aquest treball ha passat de la versemblança de la investigació a un programa de lliurament.
La transformació és silenciosa perquè no implica canvis econòmics simbòlics dramàtics ni funcions orientades a l’usuari. Però és fonamental perquè reescriu la relació entre la complexitat d’execució i el cost de validació.
Si Ethereum pot desacoblar els dos, la capa 1 ja no serà el coll d’ampolla que obliga tot allò interessant a la capa 2.
I si la verificació de prova de la capa 1 es converteix en una infraestructura compartida, tot l’ecosistema de la capa 2 ha de respondre a una pregunta més difícil: què estàs construint que la capa 1 no pot?
