La siguiente es una publicación invitada de Rob Viglione, Director ejecutivo de Laboratorios Horizen.
Durante el año pasado, se lograron hitos importantes a lo largo de la hoja de ruta de Ethereum que han mejorado 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 barato para las capas 2 y dio como resultado tarifas de transacción mucho más bajas.
Mientras tanto, la capa 2 (en su mayoría optimista) se ha vuelto más integrada y ampliamente utilizada en las aplicaciones, lo que permite realizar transacciones por menos de un centavo y mejorar la infraestructura fundamental de Ethereum.
Sin embargo, como sabe cualquiera que haya prestado atención a las tarifas del gas, todavía hay demasiada congestión en Ethereum y, a medida que crece el uso de blockchains en el mundo real, más y más dApps competirán por el espacio de bloques y la computación.
No hace falta ser ingeniero o criptógrafo para saber que esto es insostenible. Hemos visto lo que sucede cuando Ethereum se llena demasiado. En algunos momentos particularmente intensos, los usuarios pagaron más de 2 ETH solo para completar una transacción, y algunas de estas transacciones aún fallaron porque los usuarios se apresuraron a priorizarlas.
En un mundo perfecto, trasladaríamos gran parte de este cálculo fuera de la cadena y, al mismo tiempo, podríamos publicar una prueba concisa y verificable que garantice que los datos sean correctos y estén en el lugar correcto.
Las pruebas de conocimiento cero lo hacen posible, pero sigue siendo difícil para las cadenas de bloques verificar transacciones con tantas posibilidades potenciales en el EVM, y rápidamente puede resultar costoso tomar esta ruta. Los Zk-rollups deben pagar por hardware especializado que crea una prueba ZK a través de un probador y que luego, por lo general, debe convertirse 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 rollups zk son difíciles y costosos. Para las pequeñas e incluso medianas empresas que desean hacer algunos de sus negocios en la cadena y mantenerlos privados, los zk-rollups son el camino a seguir, pero verificar la evidencia puede ser un gasto prohibitivo.
Los ecosistemas acumulativos tienen sus propios intereses
Hasta ahora, los L2 de marca no han estado interesados 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. Quizás lo adopten más adelante, pero ese no es su objetivo por el momento. Por lo general, los grandes ecosistemas L2 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 blockchains y tienden a atender proyectos pequeños y medianos que no pueden permitirse pagar estos costos de auditoría. Para ellos, la idea de enviar pruebas a una cadena autónoma y luego enviar la verificación de las pruebas a Ethereum tiene mucho sentido. Al igual que con la disponibilidad de datos modulares, ahora estamos viendo que los proveedores de RaaS adoptan la verificación de pruebas modular con los brazos abiertos.
Las grandes L2 tienen dos argumentos principales en contra de este enfoque: primero, creen que trasladar la verificación de pruebas a un nivel diferente disminuye la seguridad de la L2. De hecho, algunas de estas L2 ya están verificando sus pruebas fuera de la cadena. Simplemente no lo anuncian.
Su otro argumento es que preferirían consolidar la evidencia, reuniendo una gran cantidad de pruebas y esencialmente creando una “prueba de evidencia”. Al hacerlo, las grandes L2 pueden distribuir los costos entre un número mucho mayor de transacciones. Sin embargo, no parecen tan preocupados de que con este enfoque se puedan tardar unas horas en reunir cientos de pruebas, a un coste potencialmente mayor.
La agregación tiene sentido para muchos casos de uso, pero no necesariamente para una aplicación en la que desea hacer algo rápidamente y verificarlo en el mismo período de tiempo.
En última instancia, siempre debes confiar en la L2 en la que estás jugando.
En cierto modo, la EVM está estancada en 2017.
A medida que nuestro equipo continuó profundizando 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 mediante la precompilación, lo que esencialmente hace que sea más eficiente administrar los cálculos involucrados en la verificación de una prueba. Pero actualmente la red sólo admite tres operaciones matemáticas en una sola curva.
¿Qué significa esto para los usuarios? Dado que algunos zk-SNARK no se pueden verificar, esto requiere que las pruebas se presenten en una forma más fácil de usar (utilizando la prueba bn128), lo que resulta en menos eficiencia, más margen de error y costos potencialmente más altos. Idealmente, los desarrolladores deberían poder elegir el 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 su implementación puede tardar años. La última precompilación se implementó en 2017 y no ha habido ninguna desde entonces.
¿Por qué entonces? ¿Falta de demanda? ¿Realmente no es posible implementarlos en Ethereum? E incluso si la comunidad fuera capaz de hacerlo, ¿seguiría siendo ineficaz calcular con estas nuevas precompilaciones en el EVM?
No está claro. Pero lo que está claro es que es necesario revisar el EVM y verificar las pruebas ZK en cadena sigue siendo demasiado costoso para el caso de uso promedio. Después del hardware, este es el mayor gasto cuando se utiliza un zk-rollup.
En Horizen Labs, abordamos este problema de dos maneras: ofreciendo verificación de prueba modular en forma de zkVerify y creando una cadena totalmente compatible con EVM con soporte para las últimas precompilaciones de conocimiento cero.
Por ejemplo, Horizen 2.0 se basa en Substrate, que permite actualizaciones sin bifurcaciones que se aplican automáticamente inmediatamente después de una votación de la comunidad. No es necesario realizar ningún trabajo en el lado del nodo y no se requiere una bifurcación dura.
Algunos equipos preferirán permanecer dentro de un ecosistema dedicado como Horizen 2.0, con su propia comunidad unida y efectos de red. Otros optarán por tomar la ruta RaaS para crear su propio paquete acumulativo personalizado y también podrán aprovechar los ahorros de costos de verificar la evidencia fuera de la cadena.
Hay varias formas de escalar EVM con ZK, pero creemos que esto debe suceder antes de la próxima ola de adopción.