Por qué el próximo paso de Ethereum es el conocimiento-cero

Portada/ilustración vía CryptoSlate. La imagen incluye contenido combinado que puede incluir contenido generado por IA.

Este artículo ha sido escrito por Rob Viglione, Director General de Horizen Labs.

En el último año, ha habido hitos importantes en la hoja de ruta de Ethereum que han mejorado significativamente la red. EIP-4844 (también conocido como Dencun) introdujo blobs y proto-danksharding, lo que hizo que el almacenamiento de datos fuera mucho más económico para las soluciones de Capa 2, resultando en comisiones de transacción considerablemente más bajas.

Mientras tanto, las soluciones de Capa 2 (principalmente del tipo optimista) se han integrado y utilizado más en aplicaciones, permitiendo transacciones por menos de un centavo y mejorando la infraestructura fundamental de Ethereum.

Sin embargo, como cualquiera que haya prestado atención a las comisiones de gas sabrá, sigue habiendo demasiada congestión en Ethereum, y a medida que crece el uso real de las blockchains, más y más aplicaciones descentralizadas (dApps) competirán por espacio en los bloques y capacidad de cómputo.

No hace falta ser ingeniero o criptógrafo para saber que esto es insostenible. Ya hemos visto lo que sucede cuando Ethereum se congestiona demasiado. En algunos momentos de alta demanda, los usuarios han pagado más de 2 ETH solo para completar una transacción, y algunas de esas transacciones aún fallaron mientras los usuarios intentaban que se les diera prioridad.

En un mundo ideal, trasladaríamos la mayor parte de ese cómputo fuera de la cadena, y aún así podríamos publicar una prueba concisa y verificable que garantice que los datos son correctos y están en el lugar adecuado.

Las pruebas de conocimiento cero (zk-proofs) hacen esto posible, pero sigue siendo un desafío para las blockchains verificar transacciones con tantas posibilidades en la EVM, y puede volverse costoso optar por esta ruta. Los zk-rollups deben pagar por hardware especializado que crea una prueba zk mediante un "prover", y luego generalmente esa prueba necesita ser convertida en un tipo de prueba que Ethereum pueda entender.

En resumen, los rollups optimistas son relativamente fáciles y asequibles de verificar, mientras que los zk-rollups son desafiantes y costosos. Para las pequeñas y medianas empresas que desean realizar parte de su negocio en la cadena y mantenerlo confidencial, los zk-rollups son la mejor opción, pero la verificación de pruebas puede ser un gasto prohibitivo.

Los ecosistemas de rollups tienen sus propios intereses

Hasta este punto, las soluciones de Capa 2 con marca propia no han mostrado interés en una solución modular de verificación de pruebas como zkVerify, que puede reducir los costos de verificación en un 90% o más. Podrían adoptarla más adelante, pero no es su prioridad en este momento. Generalmente, los grandes ecosistemas de Capa 2 creen en verificar todas estas pruebas zk en la misma cadena y amortizar estos costos entre los usuarios.

Sin embargo, encontramos una oportunidad con los proveedores de "rollup como servicio" (RaaS), ya que creen en un enfoque modular para las blockchains y tienden a atender proyectos pequeños y medianos que no pueden pagar esos costos de verificación. Para ellos, la idea de enviar pruebas a una cadena independiente y luego enviar la verificación de la prueba de regreso a Ethereum tiene mucho sentido. Al igual que con la disponibilidad modular de datos, ahora estamos viendo a los proveedores de RaaS adoptar la verificación modular de pruebas con los brazos abiertos.

Los grandes L2 tienen dos argumentos principales en contra de este enfoque: primero, creen que mover la verificación de pruebas a una capa diferente reduce la seguridad de la Capa 2. En realidad, algunas de estas L2 ya verifican sus pruebas fuera de la cadena; simplemente no lo publicitan.

Su otro argumento es que prefieren agregar pruebas, agrupando un gran lote de pruebas y, esencialmente, creando una "prueba de pruebas". Al hacer eso, los grandes L2 pueden distribuir el costo entre un número mucho mayor de transacciones. Sin embargo, no parecen estar tan preocupados por el hecho de que con este enfoque, podría tomar algunas horas agregar cientos de pruebas, a un costo potencialmente mayor.

La agregación tiene sentido para muchos casos de uso, pero no necesariamente para una aplicación en la que se desea hacer algo rápidamente y que se verifique en el mismo tiempo.

Al final del día, todavía tienes que confiar en la Capa 2 en la que te encuentras.

De alguna manera, la EVM sigue estancada en 2017

A medida que nuestro equipo siguió investigando en el espacio ZK y la relación de Ethereum con él, descubrimos que Ethereum en realidad tiene cierta compatibilidad con curvas elípticas de conocimiento cero utilizando una precompilación, lo que esencialmente hace que sea más eficiente manejar el cómputo involucrado en la verificación de una prueba. Pero actualmente la red solo admite tres operaciones matemáticas en una sola curva.

¿Qué significa esto para los usuarios? Dado que algunas zk-SNARKs no pueden ser verificadas, se requiere envolver las pruebas en una forma más amigable (utilizando la prueba bn128), lo que resulta en menos eficiencia, más margen de error y potencialmente costos más altos. Idealmente, los desarrolladores deberían poder elegir la zk-SNARK que mejor se adapte a su aplicación, y no poder hacerlo significa que tienen que comprometer la calidad.

Técnicamente, es posible que Ethereum adopte precompilaciones más avanzadas con el tiempo, pero puede tomar años implementarlas. La última precompilación se implementó en 2017, y no ha habido ninguna desde entonces.

¿Por qué es eso? ¿Falta de demanda? ¿No es factible implementarlas en Ethereum? Y aun si la comunidad logra hacerlo, ¿seguiría siendo ineficiente computar con estas nuevas precompilaciones en la EVM?

No está claro. Pero lo que sí está claro es que la EVM necesita una renovación, y tener pruebas zk verificadas en la cadena sigue siendo demasiado costoso para el caso de uso promedio. Después del hardware, es el mayor gasto al usar un zk-rollup.

En Horizen Labs, estamos abordando esto de dos maneras: ofreciendo verificación modular de pruebas en forma de zkVerify y construyendo una cadena completamente compatible con la EVM con soporte para las últimas precompilaciones de conocimiento cero.

Por ejemplo, Horizen 2.0 está construido sobre Substrate, lo que permite actualizaciones sin necesidad de forks que se aplican automáticamente después de una votación comunitaria. No es necesario hacer ningún trabajo en el lado del nodo, y no se requiere un hard fork.

Algunos equipos preferirán permanecer dentro de un ecosistema dedicado como Horizen 2.0, con su propia comunidad y efectos de red. Otros optarán por la ruta de RaaS para construir su propio rollup personalizado, y también podrán disfrutar de los ahorros en costos de la verificación de pruebas fuera de la cadena allí.

Existen múltiples formas de evolucionar la EVM con ZK, pero creemos que esto debe suceder antes de la próxima ola de adopción.