En la tercera sección "Build" del CMC Crypto Playbook 2023, ConsenSys ofrece un desglose de los roll-ups de Capa 2, en particular de los roll-ups ZK, y hacia dónde se dirige el espacio.
Vista general de los roll-ups de capa 2
En los últimos años, las soluciones de rollup de Capa 2 (L2) han pasado a primer plano a medida que crecía la actividad en la red Ethereum. La actividad y la interacción con tokens no fungibles (NFT) y finanzas descentralizadas (DeFi) han provocado un aumento en la actividad de la cadena de bloques de capa 1 (L1). A su vez, ha aumentado la demanda de espacio en bloque, representada por los costes del gas. Y el tiempo de finalización de la transacción ha aumentado debido al aumento de la carga de red. Aunque la Fusión de Ethereum sentó las bases para futuras optimizaciones de las tasas de gas, no redujo directamente las tasas de gas de las transacciones.
En el año entre el verano de 2020 y la demanda máxima en verano de 2021, el coste de gas en Gwei en la red Ethereum aumentó hasta en un 1300 %. La necesidad de que las transacciones fueran rápidas y asequibles impulsó la creación de dos formas principales de rollup: Optimista y Cero Conocimiento (ZK por sus siglas en inglés).
Los rollups ayudan a eliminar las demandas computacionales de la red Ethereum al mover el procesamiento de transacciones fuera de la cadena, convertirlas en una sola pieza de datos y luego devolverlas como un lote para reducir el coste y el tiempo asociados. La gran diferencia entre los dos es que las implementaciones optimistas utilizan pruebas de fraude, mientras que los rollups ZK dependen de pruebas de conocimiento cero para verificar los cambios en la cadena principal.
Join us in showcasing the cryptocurrency revolution, one newsletter at a time. Subscribe now to get daily news and market updates right to your inbox, along with our millions of other subscribers (that’s right, millions love us!) — what are you waiting for?
Rollups Optimistas y ZK - Pruebas de fraude frente a pruebas de validez
Las pruebas de fraude agrupan las transacciones fuera de la cadena y luego las reenvían a la L1. Después de que se haya presentado un paquete en la L1 hay un periodo de impugnación, durante el cual cualquiera puede impugnar el resultado del rollup computando una prueba de fraude. Del mismo modo, las pruebas de conocimiento cero agrupan las transacciones fuera de la cadena y las presentan como una única transacción. En lo que difieren es en que, en lugar de suponer inicialmente que las transacciones son correctas, utilizan una prueba de validez para demostrar instantáneamente si las transacciones son válidas. Una vez confirmadas las transacciones como válidas, se envían a la L1. De ahí derivan sus respectivos nombres: las pruebas de fraude son aquellas en las que las transacciones se comprueban retrospectivamente para ver si hay alguna transacción fraudulenta, mientras que las pruebas de validez se completan antes de que las transacciones se envíen al L1.
Aunque hay proyectos destacados para ambos, cada uno tiene sus propios beneficios y desventajas. Los roll-ups optimistas tienen la ventaja de que las pruebas de fraude sólo son necesarias cuando hay un problema. Esto significa que requieren menos recursos computacionales y pueden escalarse bien. El problema radica en el periodo del desafío. Un período de desafío más largo aumenta la probabilidad de que se identifiquen transacciones fraudulentas, pero también significa que los usuarios deben esperar más tiempo para retirar sus fondos. Para las principales soluciones de rollup optimista, como Arbitrum y Optimism, este periodo de espera puede durar hasta una semana. Por otra parte, los rollups ZK tienen la ventaja de reflejar siempre un estado L2 correcto. Su inconveniente es que se requieren pruebas para todas las transiciones de estado, en lugar de sólo cuando son impugnadas, lo que limita la escalabilidad. Esto se compone aún más por la naturaleza compleja y la etapa inicial de la tecnología.
A pesar de sus respectivos retos, los roll-ups ZK se anuncian como el futuro de los roll-ups. Esto se debe principalmente a que la generación automática de pruebas de validez aumenta la seguridad del protocolo, a que el tiempo de retirada se reduce significativamente al no haber periodo de impugnación, y a que los ZK-rollups presentan una mejor compresión de datos. Por estas razones, nos centraremos en el estado actual del espacio ZK-rollup, las últimas innovaciones y lo que nos espera en el futuro.
Fuente: Galaxy Digital
El espacio ZK-Rollup
Como ya hemos comentado, las ZK-rollups están predominantemente en el punto de mira, con actores como zkSync, Starknet, Polygon zkEVM y Scroll, todos ellos recaudando grandes cantidades de capital para desarrollar sus soluciones, a pesar de que sólo StarkNet se ha lanzado en mainnet (780 millones de dólares en total). Cada uno de estos proyectos ha adoptado su propio ángulo, diferenciándose principalmente por su estrategia de disponibilidad de datos de los rollups y su algoritmo de prueba. La estrategia de disponibilidad de datos determina dónde se almacenan los datos de estado de un roll-up, el almacenamiento en la cadena ha aumentado la seguridad, pero consume espacio de bloques en la red Ethereum, lo que reduce el rendimiento de las transacciones.
El algoritmo de prueba es el medio de generar una prueba de validez, que puede ser STARK o SNARK. Ambos algoritmos ayudan a los desarrolladores a reubicar el cálculo y el almacenamiento fuera de la cadena, aumentando a su vez la escalabilidad. También son capaces de verificar si un usuario tiene fondos suficientes y la clave privada correcta sin tener que acceder a la información en sí, mejorando así la seguridad. Puedes leer más sobre las diferencias técnicas aquí. Los STARK tienen la ventaja de ofrecer más escalabilidad, seguridad y transparencia en comparación con los SNARK. Sin embargo, los STARKS de retorno tienen un tamaño de prueba mayor, que tarda más en verificarse y que los SNARK comparativamente solo utilizan el 24 % del gas. De este modo, tanto para los SNARKS como para los STARKS, tenemos el compromiso entre velocidad y coste vs. escalabilidad, seguridad y transparencia. Aunque se están explorando muchos métodos diferentes, aún no hay una respuesta definitiva para la mejor manera de configurar un ZK-rollup. Cada configuración aporta sus respectivas ventajas y muchos desarrolladores siguen explorando la elección o combinación óptima para sus diseños de rollup.
Los obstáculos que hay que superar
Como hemos comentado, los ZK-rollups aún están en desarrollo y hay varios desafíos que deben superar antes de que los usuarios de la cadena de bloques puedan obtener todas sus ventajas. La compatibilidad de lenguajes es uno de esos retos; traducir lenguajes de programación compatibles con EVM, como Solidity, a un lenguaje personalizado y optimizado específicamente para ZKP puede ayudar a aumentar su eficacia, pero conlleva retos de adopción para los desarrolladores. Por ejemplo, StarkNet está intentando resolver esto con Warp, un compilador de lenguajes Solidity a Cairo (el lenguaje del ZKP de StarkNet) que pretende convertir automáticamente Solidity en Cairo. El uso de Warp elimina la necesidad de que los desarrolladores reescriban su código en Cairo, lo que lo convierte en un proceso mucho más fluido.
Otros desafíos incluyen la naturaleza secretista de los proyectos, con muchos en contra de la ética de código abierto de las criptomonedas debido a preocupaciones sobre la primera ventaja de mover y captar una base de usuarios pegajosa. La mayoría de los ZK-rollups se lanzaron por primera vez este año, destacando la cantidad de trabajo que aún no se ha realizado en el espacio.
Por último, aunque los rollups (tanto optimistas como de conocimiento cero) tienen la ventaja de mejorar la velocidad y el coste, suele ser a costa de la descentralización. Esto se debe a la necesidad inherente de secuenciadores, los actores que batallan transacciones y confirman pruebas a la L1. Todos los rollups necesitan actualmente un secuenciador centralizado y utilizan contratos inteligentes actualizables gestionados por una sola entidad. Dado que el espacio sigue siendo tan temprano, normalmente se requiere un punto focal central para corregir rápidamente los errores en el código. Añade que los proyectos no son de código abierto, lo que crea otro obstáculo para que los miembros de la comunidad actúen como secuenciadores. Muchos proyectos han indicado que tienen previsto descentralizar sus funciones de secuenciador en el futuro, pero sin duda esto requerirá recursos y tiempo adicionales.
Planes de descentralización
Lanzar un token y abrir el código serán los siguientes pasos para muchos de los proyectos que buscan la descentralización. La tokenización de estos servicios para generar actividad y descentralizar el producto es otra área donde esperamos ver un sinfín de soluciones diferentes que se recortan a medida que los proyectos buscan crear la L2 más escalable, descentralizada y activa en el mercado. StarkWare y zkSync tienen previsto lanzar un token y Polygon podría utilizar MATIC para apoyar la iniciativa zkEVM de Polygon. La ingeniería de tokens en ZK-rollups es un espacio aún más incipiente que la tecnología optimista de rollups, y encontrar un modelo eficaz y sostenible puede diferenciar e impulsar la adopción.
El futuro
Los zkEVM están todavía en sus primeras etapas y la carrera está en marcha para su lanzamiento en la mainnet. StarkNet tiene la ventaja de ser el primero en actuar, pero sigue teniendo dificultades para admitir las funciones de Solidity debido al uso de Cairo, lo que deja margen para que los competidores introduzcan mejoras. Los proyectos que pueden abarcar bases de usuarios significativas atraerán a los desarrolladores de dapp, a su vez aportando más dapps a su plataforma y aumentando el conjunto de funciones. El zkEVM de ConsenSys se está trasladando actualmente a una testnet y, por este motivo, se están centrando específicamente en los desarrolladores de dapp, aprovechando herramientas como MetaMask, Infura y Truffle para que puedan desplegar y gestionar aplicaciones como si utilizaran directamente Ethereum.
Y aunque hemos hablado de los actores actuales del mercado de zkEVM, otras soluciones de rollup predominantes, como Polygon, Optimism y Arbitrum, siguen teniendo una cuota de mercado significativa. A medida que maduren las soluciones zkEVM, es posible que veamos que estos proyectos buscan la transición a pruebas de validez o soluciones híbridas, aprovechando sus bases de usuarios existentes para atraer el desarrollo de dapp y mantener su dominio del mercado. Al final, las numerosas soluciones de rollup (y la creciente competencia entre ellas) seguirán mejorando la experiencia del usuario web3 e introduciendo plataformas para que las aplicaciones incorporen a la próxima generación de usuarios.
Dadas estas amenazas, no nos sorprende el secretismo de los proyectos en este espacio, pero creemos que el verdadero ganador será capaz de aprovechar la eficacia de los ZK-rollups y combinarla con una experiencia sin fisuras para el desarrollador y el usuario para salir victorioso.
Este artículo contiene enlaces a sitios web de terceros u otro contenido solo con fines informativos ("Sitios de terceros"). Los Sitios de Terceros no están bajo el control de CoinMarketCap, y CoinMarketCap no es responsable del contenido de ningún Sitio de Terceros, incluidos, entre otros, cualquier enlace contenido en un Sitio de Terceros, o cualquier cambio o actualización en un Sitio de Terceros. CoinMarketCap te proporciona estos enlaces solo para tu conveniencia, y la inclusión de cualquier enlace no implica respaldo, aprobación ni recomendación por parte de CoinMarketCap del sitio ni de ninguna asociación con sus operadores. Este artículo está destinado a ser utilizado y debe utilizarse únicamente con fines informativos. Es importante hacer tu propia investigación y análisis antes de tomar cualquier decisión importante relacionada con cualquiera de los productos o servicios descritos. Este artículo no tiene como objetivo, y no debe interpretarse como asesoramiento financiero. Los puntos de vista y opiniones expresados en este artículo son del autor [de la empresa] y no reflejan necesariamente los de CoinMarketCap.
