*Reenviar el Título Original 'Cómo ZKP y ZK-Rollups ayudan a resolver el problema de escalabilidad: una revisión de la cadena de bloques zkSync'

En este artículo, explicaremos qué es la tecnología de prueba de conocimiento cero y hablaremos sobre una blockchain popular, zkSync: cómo funcionan las transacciones en zkSync y las principales diferencias con la Máquina Virtual Ethereum (EVM). También discutiremos las ventajas y desventajas de esta blockchain, que creemos que podría tener un futuro prometedor.

ZkSync es una blockchain de segundo nivel (Capa 2 — L2) para Ethereum, diseñada para abordar los problemas de altas tarifas y limitada capacidad de procesamiento (Transacciones Por Segundo — TPS) en la red de Ethereum. Esta plataforma emplea la tecnología ZK-Rollup, que utiliza Pruebas de Conocimiento Cero (ZKP) para agrupar múltiples transacciones fuera de la red principal (L1). Solo las pruebas criptográficas de la corrección de las transacciones y sus datos comprimidos se envían a L1, mejorando significativamente la eficiencia y reduciendo costos.

Desarrollado por Matter Labs, zkSync se anuncia como un producto totalmente de código abierto (100% de código abierto), gestionado por la comunidad. Según Cryptorank, el proyecto ya ha atraído atención, recaudando inversiones de $458 millones. A largo plazo, Matter Labs tiene como objetivo crear un ecosistema integral. Actualmente, dos blockchains están operativos: zkSync Lite, que procesa pagos en ETH y tokens ERC20, y zkSync Era, que soporta contratos inteligentes completos. Los planes futuros incluyen el lanzamiento de un sistema de hipercadena (L3), asegurando alta seguridad. El objetivo de Matter Labs es escalar la tecnología a un nivel que atraerá a los próximos mil millones de usuarios de blockchain.

Antecedentes

ZkSync representa un nuevo enfoque para resolver el problema de escalabilidad conocido como el trilema de la cadena de bloques. Este proyecto, al igual que otras soluciones de Capa 2 (L2), busca encontrar un equilibrio entre seguridad, escalabilidad y descentralización en las redes blockchain.

1. Escalabilidad: La capacidad de un sistema para manejar de manera eficiente un volumen creciente de transacciones o datos sin perder rendimiento y seguridad.
2. Seguridad de la cadena de bloques: Garantizar la fiabilidad y protección de los datos contra accesos no autorizados, manipulaciones o modificaciones.
3. Descentralización: La ausencia de una estructura de control centralizada. En un sistema descentralizado, la gestión y la toma de decisiones se distribuyen democráticamente entre todos los participantes de la red.

Ethereum se centra en la seguridad y la descentralización, haciendo hincapié en su estatus como un protocolo peer-to-peer con nodos distribuidos por todo el mundo. Para obtener la información más reciente sobre la distribución de nodos, consulte NodeWatch.

Para mantener la descentralización en la red, cada nodo debe verificar todas las transacciones. Esto ralentiza inherentemente la red. Además, bajo una carga de red alta, las transacciones pueden volverse bastante costosas y requerir un tiempo significativo para procesarse.

Capa 2

La tarea principal para aumentar el TPS de la red Ethereum sin aumentar la carga en los nodos fue la introducción de Fragmentaciónen combinación con la transición al consenso PoS (Prueba de Participación). Esto implicó dividir a los validadores en subgrupos para procesar segmentos separados de la red, reduciendo así la carga general y aumentando el rendimiento. Sin embargo, la comunidad se ha centrado en soluciones de Capa 2, considerando su rápido desarrollo.

Además de la idea de implementar Sharding en Ethereum, han surgido otras soluciones de escalabilidad, como:

• Canales de pago y estado
• Cadenas laterales
• Plasma
• Rollup optimista

Así como tecnologías basadas en Pruebas de Conocimiento Cero (ZKP), incluyendo:

• Validium
• zkRollup
• Voluntad

Se puede encontrar información más detalladaaquí.

Aunque Sharding todavía está en desarrollo, se planea la bifurcación dura de Dencun para principios de 2024, que implementaráProto-Danksharding. Este paso intermedio tiene como objetivo mejorar las soluciones de Capa 2, haciendo que el almacenamiento de datos en L1 sea más económico. Así, Proto-Danksharding promete reducir los costos de transacción en L2, como un paso hacia una solución de Fragmentación completa.

A primera vista, las blockchains L2 pueden parecer similares, ya que su tarea principal es aumentar el número de transacciones fuera de L1 mientras delegan el papel de garante de seguridad a L1. Los desarrolladores de tales blockchains a menudo afirman que sus soluciones son las más rápidas, confiables y simples. En realidad, cada enfoque de escalabilidad tiene sus matices y compromisos inevitables con respecto a la velocidad de las transacciones, el nivel de seguridad o el grado de descentralización. Las soluciones totalmente centralizadas también son comunes. Todos estos aspectos nos devuelven a los problemas fundamentales del trilema de las blockchains.

En este artículo, se proponen criterios clave para evaluar los protocolos utilizados en las soluciones de Capa 2. Incluyen:

• seguridad,
• rendimiento y eficiencia económica,
• facilidad de uso,
• aspectos adicionales como el soporte de contratos inteligentes, la compatibilidad con el bytecode EVM y las opciones de privacidad.

¡Importante! El artículo está escrito por Matter Labs y, en mi opinión, algunas cosas están "exageradas" a favor de zkRollup (ya que hay un claro conflicto de interés), pero eso no es tan importante, lo principal es ver qué diferencias existen entre los protocolos de Capa-2.

A continuación proporcionaré una tabla, y aquí describiré brevemente su contenido.

Seguridad

• Suposición de vitalidad o 'viabilidad' de la Capa-2. Se asume que para mantener la funcionalidad de la Capa-2, algunos participantes siempre estarán en la cadena en el nivel de Capa-1 para responder a posibles casos de fraude. Estos son ya sea validadores que apuestan una cierta cantidad de fondos (marcados como 'Bonded' en la tabla) en L1, o terceros que aseguran la seguridad del protocolo a cambio de una recompensa. Como se ve en la tabla, las soluciones que utilizan ZKP (Validium y zkRollup) no tienen esta necesidad.
• Problema de Salida Masiva. Un problema que surge si, por razones de seguridad, es necesario iniciar la retirada de fondos por parte de todos los usuarios de L2 a L1. Como se ve en la tabla, este problema solo existe con el protocolo Plasma, del cual se puede leer más aquí.
• Custodia. La pregunta de si los validadores de L2 pueden bloquear temporalmente o confiscar los fondos de los usuarios.
• Vulnerabilidades económicas. Incluye varios ataques a los validadores de L2, incluyendo el soborno a los mineros de L1, la creación de DAOs 'sombra' y otros ataques motivados económicamente.
• Criptografía. La diferencia entre primitivas criptográficas estándar y nuevas. Las estándar están más estudiadas y potencialmente vulnerables, mientras que las nuevas (como SNARK y STARK) ofrecen una mayor fiabilidad pero requieren conocimientos adicionales y auditorías por parte de los desarrolladores.

Rendimiento y Economía

Con el rendimiento, es sencillo. TPS (Transacciones Por Segundo) indica la capacidad de la red, y en el contexto de escalabilidad, es el parámetro más crucial.

Aspectos económicos:

• Eficiencia de capital: Este aspecto es especialmente importante para los Canales de Pago. Requieren congelar fondos iguales al volumen promedio de operaciones en el canal, lo que los hace menos eficientes en términos de inversión de capital.
• Transacción L1 para crear una cuenta L2. También una desventaja para los canales de pago, ya que en todas las demás soluciones una cuenta creada en L1 funciona en L2 por defecto.
• Costo de transacción: Junto con TPS, este es uno de los factores más críticos de escalabilidad, que determina la atractividad económica de la solución.

Facilidad de uso

• Tiempo de retiro de L2 a L1: Este período puede variar desde varios minutos hasta varias semanas. Los Rollups Optimistas y Plasma son particularmente incómodos en este sentido, ya que requieren más tiempo para el retiro de fondos.
• Tiempo de Finalidad Subjetiva de la Transacción: Determina qué tan rápido una transacción se vuelve irrevocable en L1 desde la perspectiva de observadores externos. Por ejemplo, en Rollups Optimistas, lograr la finalidad en L1 solo requiere una confirmación en Ethereum, pero la finalidad completa de la transacción lleva aproximadamente una semana.
• Verificación de la Finalidad Subjetiva con Código del Cliente: Determina si el tiempo de finalidad subjetiva puede ser verificado por clientes ligeros (navegadores/billeteras móviles). Continuando con el ejemplo de los Rollups Optimistas, para confirmar la finalidad de la transacción, un usuario debe descargar y verificar todo el rollup del estado de la semana pasada.
• Confirmaciones instantáneas de transacciones. ¿Puede el protocolo proporcionar confirmaciones instantáneas de transacciones con garantía total? ¿O solo garantiza esto a nivel de consenso L2?
• Finalidad Visible Instantánea: Puede implementarse en la mayoría de los protocolos L2, lo que significa que las transacciones se confirman instantáneamente en la interfaz de usuario. Solo los canales de pago (canales de estado) ofrecen garantías de seguridad completas para estas confirmaciones, mientras que en otros protocolos estas transacciones aún pueden ser revertidas dentro de cierto tiempo antes de que se confirmen en L1.

Otros Aspectos

• Contratos inteligentes: Consideración de si la solución L2 admite contratos inteligentes totalmente programables, o solo un subconjunto limitado de funciones a través de predicados.
• Compatibilidad con el Código Byte EVM: Evalúa la viabilidad de transferir contratos inteligentes existentes de Ethereum EVM a L2 sin cambios significativos.
• Soporte de privacidad incorporado: Consideración de la eficiencia de la protección de la privacidad en soluciones L2, especialmente en el contexto de la disponibilidad y rentabilidad de transacciones confidenciales.

A continuación se muestra una tabla comparativa de las principales soluciones basadas en ZKP:

Para una comprensión más detallada de las Pruebas de Conocimiento Cero (ZKP), recomiendo consultar este artículoen nuestroblockchain-wiki, creado por desarrolladores para desarrolladores a los que les encantan las pruebas y profundizan en los detalles.

Ciclo de vida de transacción en zkSync

La operación de ZK-Rollups se puede representar a un alto nivel de la siguiente manera:

1. Formación de Rollup: Las transacciones se empaquetan en un rollup.
2. Creación de ZKP: Se forma una Prueba de Conocimiento Cero.
3. Verificación en Ethereum: La prueba se envía para su verificación a un contrato inteligente de Ethereum.

En el contexto de la arquitectura de zkSync, el proceso se ve así:

1. Colección de bloques internos: los validadores de zkSync recopilan bloques internos de transacciones cada pocos segundos.
2. Formación de paquete de bloques: Cada 30-90 segundos, se crea un paquete de bloques a partir de los bloques internos.
3. Compromiso de estado de la cadena de bloques: Los validadores registran el estado actual de la cadena de bloques y transmiten los datos modificados a L1 como datos de llamada para una posible recuperación.
4. Cálculo y envío de SNARK: Los validadores calculan el SNARK (ZKP) para el paquete y lo envían para su verificación a un contrato inteligente de Ethereum. Después de la verificación, el nuevo estado de la red se vuelve final.

Los validadores en ZK-Rollups juegan un papel clave, empaquetando transacciones en bloques y generando Pruebas de Conocimiento Cero para ellas. Una característica del sistema es que los validadores físicamente no pueden robar fondos. El daño potencial más significativo que pueden causar es una pausa temporal en la red.

Nota: En la Era zkSync, el papel de los validadores lo desempeñan los operadores.

Los desarrolladores de zkSync destacan las siguientes garantías de su arquitectura:

1. Seguridad del Fondo: Los operadores nunca pueden dañar el estado de la red o robar fondos, lo cual es una ventaja en comparación con las Sidechains.
2. Posibilidad de Recuperación de Fondos: Los usuarios siempre pueden extraer sus fondos incluso si los operadores cesan sus operaciones. Esto es posible gracias a la disponibilidad de datos, a diferencia del sistema Plasma.
3. Independence from Monitoring: Gracias a ZKP, los usuarios o terceros de confianza no necesitan monitorear continuamente los bloques de Rollup para prevenir fraudes, lo cual es una ventaja en comparación con sistemas basados en pruebas de fraude, como canales de pago u Optimistic Rollups.

Las transacciones en la era de zkSync pasan por varios estados clave, diferentes de las confirmaciones habituales de Rollup en L1:

• Pendiente: El operador ha recibido la transacción pero aún no ha sido procesada.
• Procesado: La transacción está siendo procesada por el operador y está lista para ser incluida en el próximo bloque.
• Comprometido: Los datos de transacción se publican en Ethereum, asegurando la disponibilidad de datos, pero no confirman su correcta ejecución.
• Ejecutado: La etapa final donde la prueba de validez (SNARK) de la transacción es verificada por un contrato inteligente de Ethereum, haciendo que la transacción sea final.

Además del número de bloque, las transacciones en zkSync también muestran el número de paquete. Originalmente, parámetros como block.number, block.timestamp y blockhash se tomaron de L1. Sin embargo, después,una actualización, estos valores ahora se obtendrán de L2. A pesar de esto, los desarrolladores planean proporcionar métodos para acceder a los datos desde L1.

Diferencias entre zkEVM y EVM

La compatibilidad de las soluciones L2 basadas en ZKP con Ethereum es una tarea compleja. Esto se debe a que Ethereum no fue diseñado originalmente para una interacción óptima con ZKP. Como resultado, al desarrollar dichos sistemas, se debe encontrar un compromiso entre el rendimiento y el potencial de escalabilidad, por un lado, y la compatibilidad con Ethereum y EVM, por otro. Artículo de Vitalik Buterin Los diferentes tipos de ZK-EVMsdiscute estos aspectos en detalle y destaca diferentes niveles de compatibilidad.

zkSync eligió uno de los caminos más desafiantes, apuntando a un alto rendimiento pero con compatibilidad limitada tanto con Ethereum como con EVM. Para obtener bytecode compatible con zkEVM, el LLVMEl proyecto se utiliza con un conjunto de compiladores y optimizadores propietarios. En el caso de Solidity y Yul, después del compilador solc estándar, el código pasa por varias etapas más antes de convertirse en bytecode zkEVM. El diagrama a continuación ilustra todas las etapas de este proceso (descrito con más detalle aquí):

¡Importante! Se admiten optimizaciones en zksolc.

El bytecode compilado específicamente para EVM no es compatible con zkEVM. Esto significa que las direcciones de contratos inteligentes idénticos en Ethereum y zkSync serán diferentes. Sin embargo, los desarrolladores planean resolver este problema en el futuro.

Una de las ventajas significativas de este enfoque es la independencia de lenguajes de programación específicos. En el futuro, los desarrolladores de zkSync prometen añadir soporte para lenguajes como Rust y C++. Es importante que la demora en las actualizaciones y la integración de innovaciones entre compiladores de alto nivel (por ejemplo, solc) y compiladores de plataforma (por ejemplo, zksolc) sea mínima. Inicialmente, se tuvo la idea de crear su propio lenguaje de programación, Zinc, pero por el momento, el equipo está centrado en el soporte de lenguajes de programación más populares.

El problema de la compatibilidad de los compiladores zk con las herramientas existentes de desarrollo y depuración para contratos inteligentes de Solidity y Vyper es significativo. Plataformas de desarrollo actuales como Remix, Hardhat y Foundry no admiten compiladores zk de forma nativa, lo que crea dificultades al trabajar con ellos. Sin embargo, solucionesestán siendo desarrollados que prometen facilitar el proceso de migración de proyectos y adaptación a nuevas tecnologías.

El artículo de Vitalik Buterin menciona que es probable que Ethereum se esfuerce por mejorar la compatibilidad con ZKP a nivel de protocolo con el tiempo. De manera similar, las soluciones L2 con ZKP se adaptarán para una mejor compatibilidad con Ethereum. Como resultado, en el futuro, las diferencias entre estos sistemas pueden volverse casi imperceptibles, asegurando una integración y transición más fluidas para los desarrolladores.

Características de zkEVM

¡Importante! ¡El protocolo está siendo desarrollado activamente; siempre consulte la última versión de la documentación!

zkEVM difiere de EVM y a pesar de los esfuerzos de los desarrolladores por ocultar estas diferencias "bajo el capó", hay características importantes a considerar al escribir contratos inteligentes:

1. Diferencias respecto a EVM: El comportamiento del código escrito en Solidity para zkEVM puede diferir, especialmente en aspectos como block.timestamp y block.number. Es importante verificar regularmente el documentaciónpara cambios.
2. Contratos del sistema: En zkSync, hay contratos inteligentes del sistema para varias funciones, como ContractDeployer para implementar contratos inteligentes y MsgValueSimulator para trabajar con ETH. Puede encontrar más información sobre los contratos inteligentes del sistema en el documentación.
3. Patrón de Proxy para Implementación: Se recomienda utilizar un patrón de proxy durante los primeros meses después de la implementación para evitar posibles errores de compilación.
4. Cálculo de gas: El modelo de cálculo de gas en zkEVM difiere de Ethereum, incluyendo un conjunto diferente de opcodes y una dependencia del precio del gas en L1. Los detalles se pueden encontrar aquí.
5. Pruebas locales: Herramientas estándar como Hardhat Node o Anvil no son adecuadas para las pruebas locales de zkEVM. En su lugar, opciones especialesse utilizan, incluida la prueba del modo de bifurcación.
6. Verificación de firma: Se recomienda utilizar el soporte integrado para la abstracción de cuentas en lugar de ecrecover.
7. Seguimiento de errores relacionados con el gas: En zkSync, es imposible rastrear los errores relacionados con la escasez de gas debido a las especificidades de la ejecución dentro del contrato inteligente del sistema DefaultAccount.

Para una comprensión profunda de cómo trabajar con zkEVM, se recomienda estudiar la documentación, incluida la sección Seguridad y mejores prácticas.

Abstracción de cuenta

La abstracción de cuentas en zkSync ofrece varias ventajas clave sobre ERC-4337:

1. Nivel de implementación: En zkSync, la abstracción de cuentas está integrada en el nivel del protocolo, lo que hace que todas las cuentas, incluidas las Cuentas Propias Externas (EOA), sean funcionalmente similares a contratos inteligentes.
2. Procesamiento de transacciones: Mientras que ERC-4337 utiliza un mempool separado para los bundlers, creando dos flujos de transacciones diferentes, zkSync Era tiene un único mempool. Esto significa que las transacciones originadas desde EOAs y contratos inteligentes se procesan en un único flujo, asegurando una integración y procesamiento más fluidos.
3. Soporte para Maestros de Pago: zkSync admite maestros de pago para todo tipo de cuentas, lo que permite configurar las tarifas de gas en tokens ERC20 para cualquier cuenta.

Infraestructura zkSync

La infraestructura de zkSync Era está ganando rápidamente impulso e incluye actualmente docenas de protocolos: Puentes, DeFi, protocolos de infraestructura y más. (La lista actual se puede ver aquí).

Otra ventaja es la compatibilidad con monederos de Ethereum, como MetaMask o TrustWallet.

Hypercadenas

El protocolo zkSync comenzó su desarrollo con el lanzamiento de zkSync Lite, dirigido únicamente a transferencias de ether y tokens ERC-20, sin la capacidad de implementar protocolos completos. Esta etapa fue un paso importante en el desarrollo, pero solo precedió la llegada de zkSync Era, una solución L2 completa para Ethereum, que teóricamente también se puede adaptar a otras blockchains L1. Sin embargo, las ambiciones de zkSync no se detienen ahí, ya que los planes de desarrollo incluyen el lanzamiento de las llamadas hypercadenas.

Hyperchains, or “fractal scaling,” consist of ZKP networks, each forming its own blocks and proofs. These proofs are then collected together and posted on the main L1 network. Each of these networks is a complete copy of the entire system and can be considered its “fractal”.

La singularidad de las hyperchains es que pueden ser creadas e implementadas de forma independiente. Para mantener la coherencia y la compatibilidad, cada hyperchain debe utilizar un motor zkEVM común, parte del stack ZK (siendo zkSync Era el primer hyperchain). Esto permite que las hyperchains hereden su seguridad de L1, garantizando su fiabilidad y eliminando la necesidad de medidas adicionales de confianza y seguridad.

Hyperchains representan un enfoque innovador para escalar las redes blockchain, reduciendo la carga en la red principal y aumentando la velocidad de procesamiento de transacciones. Aspectos clave de este enfoque incluyen:

• Transferencia de Pruebas Entre Hypercadenas: Las Hypercadenas transferirán pruebas de bloques entre sí, aumentando la distancia que una transacción debe recorrer antes de llegar a la red principal L1. Esto ayuda a distribuir la carga y evitar problemas de cuellos de botella.

• Transparencia para los usuarios: los usuarios no notarán la diferencia: sus transacciones se procesan en hyperchains y pueden pasar por varios niveles antes de llegar a la red principal, creando asincronía en el procesamiento.
• Ventajas sobre las soluciones existentes: A diferencia de las soluciones actuales de L2, que son más rápidas pero aún limitadas en volumen de transacciones y a veces comprometen la seguridad, las hyperchains prometen una escalabilidad significativamente mayor.
• Flexibilidad en la creación de blockchains personalizadas: Hyperchains permiten la creación de blockchains personalizadas y cuentas con varios niveles de seguridad y privacidad. Incluso con un nivel más bajo de seguridad, en el peor de los casos, solo se espera una congelación temporal de fondos.

Más sobre todo esto se puede encontrar aquí.

Pros y contras de zkSync

Expertos

1. Seguridad: Seguridad cercana al nivel L1 y potencial de descentralización en el futuro.
2. Compatibilidad con EVM: Soporte para contratos inteligentes compatibles con EVM.
3. API Web3 y Carteras: API Web3 estándar y soporte para carteras Ethereum como MetaMask.
4. Abstracción de cuenta: Soporte nativo para la abstracción de cuenta.
5. Velocidad de transacción: Procesamiento rápido de transacciones en L2 con confirmación posterior en L1.
6. Tarifas bajas: Tarifas de gas reducidas en comparación con L1.
7. Pagos de gas ERC20: Capacidad para pagar tarifas de gas en tokens ERC20.
8. Infraestructura en evolución: Desarrollo de infraestructura muy activo.
9. Potencial de escalabilidad: Oportunidades para mejoras significativas en la escalabilidad.

Experto

1. Compatibilidad limitada con EVM: En comparación con competidores (por ejemplo, Polygon zkEVM, Scroll), tiene una compatibilidad menor con EVM.
2. Riesgo de Errores en Contratos Inteligentes: Mayor riesgo de errores, que requiere pruebas exhaustivas y auditorías.
3. Necesidades específicas de la pila de desarrollo: Necesidad de adaptar la pila de desarrollo a las especificidades del protocolo.
4. Atrasado en Tecnologías Centrales: Retraso en la adopción de innovaciones en compiladores y actualizaciones de bibliotecas.
5. Centralización de la red: Actualmente, la red es gestionada por un número limitado de operadores.
6. Necesidad de Contratos Inteligentes Actualizables: De todo lo anterior, se deduce que hay una necesidad de siempre hacer contratos actualizables al inicio del proyecto, para poder rectificar rápidamente deficiencias y vulnerabilidades.

Conclusión

El protocolo zkSync parece muy prometedor y tiene un gran potencial, aunque en la actualidad, el lanzamiento en esta blockchain todavía está asociado con una serie de riesgos que deben ser considerados. Desarrollar para zkSync actualmente es más desafiante que para blockchains que son mucho más compatibles con EVM y el stack de desarrollo de EVM. Sin embargo, quizás en el futuro, esta diferencia se volverá insignificante o desaparecerá por completo.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [MetaLamp]. Reenviar el Título Original 'Cómo ZKP y ZK-Rollups ayudan a resolver el problema de escalabilidad: una revisión de la cadena de bloques zkSync'. Todos los derechos de autor pertenecen al autor original [MetaLamp]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen consejos de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de aprendizaje de Gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.