-
Hagopian considera que las redes L2 son “necesarias” para Ethereum.
-
El desarrollador también opinó sobre el plan de Justin Drake para escalar la capa base.
En la parte final de la entrevista exclusiva con CriptoNoticias, Ignacio Hagopian, desarrollador uruguayo de la Fundación Ethereum (EF), profundizó en el papel que juegan las redes de segunda capa (L2) y en los caminos posibles para escalar la red principal (L1).
En el evento Blockchain Summit, celebrado el 25 de julio en Montevideo, la capital uruguaya, el desarrollador también habló sobre los recientes ataques de phishing que han afectado a usuarios de Ethereum.
Sobre las L2, Hagopian comparte la visión de Vitalik Buterin, cofundador de Ethereum. El pasado 7 de agosto, tras celebrar una calificación alcanzada por algunas de esas cadenas, Buterin aseguró que las L2 son importantes por la «escalabilidad horizontal» que aportan.
En esa misma postura se identificó Hagopian:
“Lo que ofrece la L2 es escalabilidad horizontal. Yo creo que escalar L1 y escalar L2 son dos temas importantes en forma separada. Necesitamos las dos cosas. No veo que es una en contra de la otra”.
Ignacio Hagopian, desarrollador de la Fundación Ethereum.
En Ethereum, la escalabilidad horizontal se refiere a la capacidad de aumentar el rendimiento de la red añadiendo más «capas» o entornos de ejecución paralelos, en lugar de sobrecargar la capa base.
Esto se logra con las L2, que procesan transacciones fuera de la cadena principal y luego registran sus resultados en ella, distribuyendo la carga, reduciendo costos y mejorando la velocidad sin comprometer la seguridad que provee Ethereum como protocolo base.
Al tiempo de esta redacción, existen más de 150 redes L2 en Ethereum.
Hagopian reconoce que, por más optimizaciones que se apliquen, resulta inviable que todas las aplicaciones que quieran desarrollarse en Ethereum operen directamente sobre su L1:
“Por más de que hagamos todo lo que se pueda hacer, nunca vamos a poder hacer que todo el sistema financiero, todo el mundo que quiera crear una aplicación corra en L1. Es algo imposible, y necesitamos esta otra forma de escalabilidad, que son las L2”.
Ignacio Hagopian, desarrollador de la Fundación Ethereum.
En su análisis, ejemplifica con una aplicación para vender tickets de conciertos:
“Las L2 ofrecen otro tipo de beneficios a aplicaciones que no necesitan un nivel de 800 millones de dólares de seguridad económica para que no se pueda revertir una transacción en una aplicación que solo vende tickets de un concierto. Y esa aplicación que vende tickets de un concierto necesita capaz que un nivel de latencia mucho más rápido que bloques de 12 segundos y necesita una confirmación de un segundo. O necesita un precio mucho más bajo que lo que le puede ofrecer la L1. Porque al final de la L1, si es un poco más cara, es porque te ofrece algo más”.
La tecnología de conocimiento cero (ZK) se comenzaría a usar en 2026
Por otro lado, Ethereum avanza en mejoras para escalar su L1. A principios de julio, el reconocido desarrollador Justin Drake presentó una hoja de ruta que contempla el uso de dos tecnologías: máquinas virtuales de conocimiento cero (Zero-Knowledge Virtual Machines en inglés, ZKvm) y pruebas en tiempo real (real-time proving).
Las ZKvm permiten validar transacciones mediante pruebas criptográficas de conocimiento cero, que demuestran la validez de las transacciones sin revelar información de las partes involucradas. Esto reduciría drásticamente la carga de trabajo de los validadores.
Hagopian adelantó que la tecnología ZK podría comenzar a probarse en Ethereum en 2026:
“La idea que estamos teniendo es empezar a usar esta tecnología de forma paralela en el protocolo para el año que viene. Podemos pedirles a algunos validadores, si se animan, que sean pocos, un 1%, un 2% de ellos empiecen a validar los bloques usando esta tecnología y vemos qué pasa, vemos cómo funciona, cuáles son los problemas, qué hay que mejorar”.
Lo que motiva al uso de la tecnología ZK es encontrar respuesta a lo que el propio Hagopian plantea: «Entonces la pregunta de oro en escalar la Layer 1 es, ¿cómo podemos hacer para validar bloques más grandes sin aumentar los requerimientos de hardware? Ese es el problema fundamental de escalar la Layer 1 en Ethereum».
Hagopian advirtió que la escalabilidad de la red está directamente condicionada por el límite de gas (gas limit en inglés), que es determinado por los propios validadores en función de la demanda y la capacidad de la red.
El límite de gas define la cantidad máxima de operaciones que puede incluir un bloque, actuando como un techo para el procesamiento de transacciones. Aumentarlo permite mayor capacidad, pero también eleva las exigencias técnicas para quienes validan y producen bloques. Actualmente, ese parámetro está situado en 45 millones.
Hagopian explicó que, al intentar escalar la red, se corre el riesgo de acercarse al límite de gas, punto en el que el volumen de operaciones por bloque sería tan alto que la validación sería inviable para hardware común:
“Con una computadora de 800 dólares no se puede validar 150.000 transacciones por segundo”.
Si los nodos encargados de producir bloques requirieran hardware alto en recursos, el riesgo estaría en que solo grandes centros de datos podrían participar, lo que concentraría el poder y pondría en riesgo la descentralización
Con el uso de ZK el productor del bloque genera una prueba criptográfica que certifica la validez de todas las transacciones incluidas. Los validadores solo necesitan verificar esa prueba, reduciendo así la carga de hardware y manteniendo la participación accesible.
Hagopian se ocupó de sentenciar el beneficio de emplear la herramienta de conocimiento cero:
“Hoy en día si tienes un bloque con 100 transacciones y te lleva un segundo, si en vez de tener 100 tuvieses 200, te va a llevar dos segundos. Tiene un costo lineal. Con esto lo que logramos es, el costo de validar la prueba es constante independientemente de qué tan grande es el bloque”.
Ataques phishing ligados a la mejora EIP-7702
Finalmente, el desarrollador uruguayo también abordó los ataques de phishing ocurridos tras la implementación de la propuesta EIP-7702, incluida con la actualización Pectra en mayo pasado.
Si bien aclaró que el problema no es al nivel de protocolo, advirtió que ciertas funciones, como las blind signatures (firmas ciegas), habilitan ataques del tipo phishing en aplicaciones, como lo informó CriptoNoticias.
Hagopian indicó que la solución pasa por mejorar los monederos, aunque también reconoció que «cualquier funcionalidad nueva que el usuario pueda tener siempre hay un riesgo de qué nuevos ataques se pueden hacer a los usuarios. Así que es como un trade-off también de qué es lo que ganas y qué riesgos nuevos pueden existir».