Rollups de ZK: el elefante en la habitación

Autor original: Jaehyun Ha

Compilado por: TechFlow

Resumen

• Si bien las pruebas de conocimiento cero (ZKP) son prometedoras para una Más privado y escalable En el ecosistema blockchain, muchos aspectos del conocimiento cero (ZK) se malinterpretan o se implementan de manera diferente a lo que comúnmente se cree.

• Hay dos aspectos principales de los ZKP: “conocimiento cero” y “concisión”. Si bien esta afirmación no es incorrecta, la mayoría de los paquetes acumulativos de ZK solo utilizan la propiedad de concisión, y los datos de transacciones y la información de la cuenta no son completamente de conocimiento cero o privados.

• Para varios tipos de DApps, Los paquetes acumulativos de ZK pueden no ser la mejor opción para las pilas de desarrollo Por ejemplo, la generación de ZKP puede convertirse en un cuello de botella para una finalización rápida, reduciendo así el rendimiento de los juegos Web3, mientras que las garantías de disponibilidad de datos basadas en la publicación de diferencias de estados pueden perjudicar los servicios de los protocolos de préstamos DeFi.

Figura 1: ZK es una gran palabra de moda

Fuente: imgflip

El estado actual de la industria blockchain puede compararse con la era del Conocimiento Cero (ZK). ZK se destaca donde quiera que vayas, y cada vez es más raro encontrar un proyecto de blockchain de próxima generación que no incorpore ZK en su nombre. Desde una perspectiva técnica, no se puede negar que ZK es una tecnología prometedora que puede contribuir a un ecosistema de blockchain más escalable y privado. Sin embargo, debido a la compleja base técnica de ZK, muchos inversores, tanto minoristas como institucionales, a menudo invierten en proyectos de ZK basados en la "creencia" de que se ve genial, novedoso y puede resolver el trilema de la blockchain, sin comprender completamente cómo la tecnología ZK puede beneficiar a cada proyecto.

En esta serie de ZK, exploraremos las verdades incómodas (las deficiencias y desventajas) de los rollups de ZK y sus aplicaciones beneficiosas. Primero, analizaremos las dos propiedades principales de las pruebas ZK (ZKP) en blockchain: "conocimiento cero" y "concisión". Luego, analizaremos cómo una gran cantidad de rollups de ZK actualmente en servicio realmente no aprovechan el aspecto de "conocimiento cero". A continuación, analizaremos áreas en las que la aplicación de rollups de ZK puede ser más perjudicial que útil, evitando problemas bien conocidos como la complejidad de la implementación. Finalmente, destacaremos proyectos destacados que incorporan de manera efectiva los principios de ZK y realmente obtienen beneficios claros al usar la tecnología ZK.

Resumen: Ciclo de vida de las transacciones en los rollups de ZK

Rollup es una solución de escalado que aborda las limitaciones de rendimiento de L1 al ejecutar paquetes de transacciones fuera de la cadena y luego almacenar datos resumidos del último estado de L2 en L1. Entre ellas, la característica destacada de ZK Rollups es la capacidad de retirar fondos rápidamente mediante el envío de pruebas de validez de los cálculos fuera de la cadena en la cadena. Antes de profundizar en los problemas de ZK Rollups, revisemos brevemente su ciclo de vida de las transacciones.

Figura 2: Ciclo de vida de las transacciones en los paquetes ZK

Fuente: Centro de Investigación Presto

• Cada usuario L2 genera y envía su transacción al secuenciador.

• El secuenciador agrega y ordena múltiples transacciones y luego ejecuta estas transacciones fuera de la cadena para calcular el nuevo estado de acumulación. Luego, el secuenciador envía este nuevo estado de acumulación al contrato inteligente en estado dentro de la cadena en forma de lote y comprime los datos de transacción L2 correspondientes en bloques de datos para garantizar la disponibilidad de los datos.

• Este lote se envía al probador, quien crea una prueba de validez (o ZKP) de la ejecución del lote. Esta prueba de validez se envía luego al contrato inteligente del validador en L1 junto con datos adicionales (es decir, la raíz del estado anterior), lo que ayuda al validador a identificar lo que está validando.

• Una vez que el contrato del validador verifica que la prueba es válida, se actualiza el estado de la acumulación y las transacciones L2 en el lote enviado se consideran completas.

(Tenga en cuenta que esta explicación es una versión simplificada del proceso ZK Rollup, y cada implementación puede variar de un protocolo a otro. Si distinguimos roles, puede haber más entidades en L2, como agregadores, ejecutores y proponentes. La jerarquía de bloques de datos también puede ser diferente, como bloques, grupos de bloques y lotes, según su propósito. La explicación anterior supone una situación en la que un secuenciador centralizado tiene una fuerte autoridad para ejecutar transacciones y también genera un formato de bloque de datos unificado como lotes).

A diferencia de los Optimistic Rollups, gracias a los ZKPs (como los ZK-SNARKs o los ZK-STARKs), los ZK Rollups pueden verificar la corrección de la ejecución de miles de transacciones verificando una prueba simple sin tener que volver a ejecutar todas las transacciones. Entonces, ¿qué es este ZKP y cuáles son sus características?

Dos propiedades de los ZKP: conocimiento cero y simplicidad

Como su nombre lo indica, una ZKP es básicamente una prueba. Una prueba puede ser cualquier cosa que pueda respaldar de manera suficiente la afirmación del proveedor. Digamos que Bob (proveedor) quiere convencer a Alice (verificador) de que tiene autoridad sobre su computadora portátil. La forma más sencilla de demostrarlo es que Bob simplemente le diga a Alice la contraseña, y Alice la ingrese en la computadora portátil y verifique que Bob tiene autoridad. Sin embargo, este proceso de verificación no es satisfactorio ni para Alice ni para Bob. Si Bob establece una contraseña muy larga y compleja, será muy difícil para Alice ingresarla correctamente (suponiendo que Alice no pueda copiar y pegar). De manera más realista, Bob puede no estar dispuesto a revelar su contraseña a Alice para demostrar su autoridad.

¿Qué sucedería si existiera un proceso de verificación mediante el cual Alice pudiera verificar rápidamente el acceso a la computadora sin que Bob revele su contraseña? Por ejemplo, Bob podría desbloquear su computadora portátil con reconocimiento de huellas dactilares frente a Alice, como se muestra en la Figura 3 (tenga en cuenta que este no es un ejemplo perfecto de un ZKP). Aquí es donde tanto Alice como Bob pueden beneficiarse de dos propiedades clave de los ZKP: la propiedad de conocimiento cero y la propiedad de simplicidad.

Figura 3: Intuición de alto nivel de conocimiento cero y simplicidad

Fuente: imgflip

Conocimiento Cero (ZK)

La propiedad de conocimiento cero se refiere al hecho de que la prueba generada por el proveedor no revela ninguna información sobre el testigo secreto (es decir, datos privados) excepto la validez de la prueba, dejando al verificador en la oscuridad sobre los datos. En blockchain, esta propiedad se puede utilizar para proteger la privacidad de los usuarios individuales. Si se aplican los ZKP a cada transacción, los usuarios pueden demostrar la legitimidad de sus acciones (es decir, demostrar que un usuario tiene fondos suficientes para realizar una transacción) sin exponer los detalles de sus transacciones (por ejemplo, transferencias, actualizaciones de saldo de cuenta, implementación y ejecución de contratos inteligentes) al público.

Sencillez

La propiedad sucinta se refiere a la capacidad de ZK de generar una prueba breve y rápidamente verificable a partir de una declaración de gran tamaño; en otras palabras, comprime algo grande en una forma compacta. En blockchain, esto es particularmente útil para los rollups. Usando ZKP, un verificador en L2 puede reclamar la ejecución correcta de una transacción enviando una prueba sucinta a un verificador en L1 (la validez de una transacción de tamaño TB puede representarse por una prueba de 10~100 KB). El verificador puede entonces confirmar fácilmente la validez de la ejecución en un corto tiempo (es decir, 10 milisegundos a 1 segundo) verificando la prueba sucinta en lugar de reproducir todas las transacciones.

ZK Rollup es genial, pero no significa privacidad

Las propiedades de los ZKP descritas anteriormente se utilizan bien en los ZK Rollups. Si bien los validadores no pueden inferir los datos de la transacción original a partir de los ZKP recibidos de los proveedores, la verificación de pruebas sucintas les permite verificar de manera efectiva las afirmaciones de los proveedores (es decir, el nuevo estado L2). Dicho esto, es engañoso afirmar que los ZK Rollups actuales se adhieren completamente a las propiedades de conocimiento cero y concisión. Esto puede ser cierto cuando se centra en la interacción entre proveedores y validadores, pero hay otros componentes en los ZK Rollups, como secuenciadores, proveedores y nodos de rollup. Entonces, ¿el principio de conocimiento cero también está garantizado para ellos?

El desafío de lograr privacidad total con ZKP en cualquier ZK Rollup proviene de los riesgos que pueden ocurrir si algunas partes se vuelven privadas a través de ZK mientras que otras permanecen públicas. Piense en el ciclo de vida de las transacciones en los rollups de ZK: ¿se mantiene la privacidad cuando las transacciones se envían desde los usuarios al secuenciador? ¿Y qué sucede con los proveedores? ¿O se preserva la privacidad de la información de las cuentas individuales cuando los lotes L2 se envían a la capa DA? Actualmente, ninguna de estas afirmaciones es cierta.

Figura 4: Fuga de privacidad en los rollups de ZK

Fuente: Investigación Presto

En la mayoría de los ZK Rollups convencionales, el secuenciador o proveedor (u otra entidad centralizada con permisos poderosos) puede ver claramente los detalles de la transacción, incluidos los montos de transferencia, las actualizaciones del saldo de la cuenta, la implementación y ejecución del contrato. Como ejemplo simple, puede observar fácilmente todos los detalles mencionados visitando cualquier navegador de bloques de ZK Rollup. No solo eso, considere una situación en la que el secuenciador centralizado deja de funcionar por alguna razón y otro nodo de rollup intenta recuperar el estado del rollup. Extraerá información de los datos L2 publicados públicamente por la capa DA (en la mayoría de los casos, L1 Ethereum) y reconstruirá el estado L2. En este proceso, cualquier nodo que pueda reproducir las transacciones L2 almacenadas por la capa DA puede recuperar información sobre el estado de la cuenta de cada usuario.

Por lo tanto, la terminología de “conocimiento cero” se implementa de forma fragmentada en los ZK Rollups actuales. Si bien esto no se puede considerar incorrecto, Es claramente diferente de la percepción común de que “ZK significa conocimiento cero equivalente a privacidad total”. La novedad de los Rollups ZK actuales es explotar la propiedad de “concisión” en lugar de “conocimiento cero”, es decir, ejecutar transacciones fuera de la cadena y generar pruebas concisas para los validadores de modo que puedan verificar de manera rápida y escalable la validez de la ejecución sin tener que volver a ejecutarlas.

Por este motivo, algunos ZK Rollups, como Starknet, se denominan a sí mismos “Validity Rollups” para evitar confusiones, mientras que otros que garantizan la verdadera privacidad de ZK, como Aztec, se autodenominan ZK-ZK Rollups.

Consideraciones más profundas sobre la practicidad de los ZK Rollups

Como se mencionó anteriormente, la mayoría de los Rollups de ZK no implementan completamente la privacidad de ZK. Entonces, ¿cuál es nuestro próximo objetivo? ¿Lograr una privacidad total de las transacciones mediante la implementación total de ZK en cada parte del Rollup? De hecho, esta no es una pregunta sencilla. Además de la necesidad de un progreso técnico significativo para madurar aún más la tecnología, ZK aún tiene problemas controvertidos en la ideología (como los usos ilegales de las transacciones privadas) y la practicidad (como, por ejemplo, ¿es realmente útil?). Dado que discutir los problemas éticos de la privacidad total de las transacciones está más allá del alcance de este artículo, nos centraremos en dos problemas prácticos de los Rollups de ZK que se encuentran en los proyectos de blockchain.

Punto 1: La generación de ZKP puede ser un cuello de botella para una rápida finalización

Primero, analicemos la practicidad de ZK Rollups. El punto de venta más atractivo de ZK Rollups es la latencia reducida de los retiros de activos debido a la rápida finalización de sus transacciones, gracias a ZKP. El aumento de TPS y las bajas tarifas de transacción son beneficios adicionales. El campo que utiliza de manera más efectiva las características de ZK Rollups es la industria del juego, porque los depósitos y retiros de monedas del juego son muy frecuentes, lo que genera una gran cantidad de transacciones en el juego cada segundo.

Pero ¿pueden realmente considerarse los ZK Rollups la mejor pila tecnológica para los juegos? Para ello, debemos pensar más profundamente en el concepto de finalización rápida en los ZK Rollups. Imaginemos que un usuario está disfrutando de un juego Web3 que se ejecuta en una pila tecnológica basada en ZK Rollup. El usuario intercambia elementos del juego por monedas del juego e intenta retirar el activo del juego.

Para retirar activos, las transacciones dentro del juego deben finalizarse. Esto significa que la transacción debe incluirse en un nuevo compromiso de estado de Rollup, el ZKP correspondiente debe enviarse a L1 y es necesario esperar a que la prueba en L1 Ethereum sea definitiva para garantizar que la transacción sea irreversible. Si todos estos procesos pueden suceder instantáneamente, entonces podemos lograr la confirmación instantánea de la transacción que los ZK Rollups suelen promocionar, lo que permite a los usuarios retirar activos de inmediato.

Sin embargo, la realidad está muy lejos de esto. Según las estadísticas de tiempo de finalización de diferentes ZK Rollups proporcionadas por L2beat , zkSync Era tarda unas 2 horas, Linea tarda 3 horas y Starknet tarda unas 8 horas en promedio. Esto se debe a que lleva tiempo generar un ZKP y también lleva tiempo adicional incluir más transacciones en un lote (es decir, una sola prueba) para reducir las tarifas de transacción. En otras palabras, la velocidad de generación y envío de pruebas es un cuello de botella potencial para lograr una rápida finalización de los ZK Rollups, lo que puede reducir la experiencia del usuario en los juegos Web3.

Figura 5: La generación de ZKP puede ser un cuello de botella potencial para la rápida finalización de las acumulaciones de ZK

Fuente: imgflip

Por otro lado, las cadenas optimizadas para juegos como Ronin (que impulsa juegos Web3 como Pixels y Axie Infinity) garantizan una finalidad ultrarrápida, sacrificando la descentralización y la seguridad. Ronin no es una cadena basada en ZK o Rollup: es una cadena de bloques EVM que se ejecuta bajo el algoritmo de consenso PoA (Proof of Authority) + DPoS (Delegated Proof of Stake). Selecciona 22 validadores en función de la cantidad de participaciones delegadas, y estos validadores luego generan y validan bloques de manera PoA (es decir, un proceso de votación solo entre los 22 validadores). Como resultado, en Ronin, las transacciones pueden finalizar rápidamente, se incluyen en bloques casi sin demora y tienen un tiempo de validación bajo. Después de la bifurcación dura de Shillin, tomó un promedio de solo 6 segundos para que cada transacción se finalice. Ronin logra todo esto sin la necesidad de ZKP.

Por supuesto, Ronin también tiene desventajas. El hecho de que esté gestionado por validadores centralizados lo hace relativamente más vulnerable a la amenaza de un ataque 51%. Además, dado que no utiliza Ethereum como capa de liquidación, no puede heredar la seguridad de Ethereum. También existen riesgos de seguridad al utilizar puentes entre cadenas. Pero desde la perspectiva de los usuarios: ¿les importan estos? Los ZK Rollups actuales sin ordenamiento descentralizado también tienen problemas de punto único de falla (SPOF). Ethereum les proporciona garantías porque reduce la posibilidad de reversiones de transacciones, pero los ZK Rollups también pueden congelarse si el secuenciador o validador centralizado falla. Tenga en cuenta nuevamente que el ZK en ZK Rollups solo se usa para verificar la validez de la corrección de la ejecución. Si hay otro proyecto que proporcione la misma funcionalidad pero más rápido y más barato, es posible que los ZK Rollups ya no se consideren la pila de tecnología preferida por los usuarios y desarrolladores de juegos Web3.

Punto 2: Las diferencias en el estado de publicación son un arma de doble filo

Otro punto es la practicidad de la implementación del protocolo ZK Rollup. Entre ellos, aquí nos centramos en la publicación de diferencias de estado, que es uno de los métodos para garantizar la disponibilidad de datos en los rollups ZK (ver Desbloqueo de la actualización de Dencun: la verdad oculta sobre el escalado de capas de DA , Jaehyun Ha, 12 de abril de 2024).

Una forma sencilla de entender la disponibilidad de datos en los Rollups es imaginar a un escalador aficionado que prueba y documenta su ascenso al Monte Everest. La forma más sencilla de hacerlo es grabar en video cada paso desde el campamento base hasta la cumbre. Aunque el archivo de video puede ser grande, cualquiera puede verificar el ascenso del escalador y potencialmente reproducir la grabación. Esta metáfora se puede comparar con el enfoque de publicación de datos de transacciones original para garantizar la disponibilidad de datos. Los Rollups optimistas siguen este enfoque para que los retadores individuales puedan reproducir y verificar la ejecución correcta porque no se puede confiar en los compromisos de estado de los secuenciadores. En los Rollups ZK, Polygon zkEVM y Scroll adoptan este enfoque, almacenando los datos de transacciones L2 originales en forma comprimida en L1 para que cualquiera pueda reproducir las transacciones L2 para restaurar el estado del Rollup cuando sea necesario.

Volviendo al ejemplo del escalador aficionado, otro método de verificación podría ser que un escalador famoso suba el Everest con el escalador aficionado para demostrar al mundo que la escalada se completó efectivamente. Dado que la escalada ha sido confirmada por una persona de confianza, el escalador ya no necesita registrar cada paso para llevar un registro. Simplemente tomar una foto en el punto de partida y en la cima de la montaña permitirá que otros crean que el escalador ha llegado a la cima. Esta metáfora refleja El enfoque de la diferencia de estados Se utiliza para garantizar la disponibilidad de los datos. En los rollups de ZK, zkSync Era y StarkNet adoptan este enfoque, almacenando solo la diferencia de estado antes y después de que se ejecute la transacción L2 en L1, de modo que cualquiera pueda calcular la diferencia de estado con respecto al estado inicial para restaurar el estado del rollup si es necesario.

Figura 6: Liberación de transacción original y liberación de diferencia de estado

Fuente: Investigación Presto

Este método de diferencia de estados es indudablemente rentable en comparación con el método de publicación de datos de transacciones original, ya que puede ahorrar el paso de almacenar transacciones intermedias, lo que reduce el costo de almacenamiento de L1. Aunque esto no suele ser un problema, existe una falla potencial aquí: este método no permite la recuperación del historial completo de transacciones de L2, lo que puede ser un problema para algunas DApps.

Tomemos como ejemplo Compound, un protocolo de préstamos DeFi, y supongamos que está construido sobre una pila ZK Rollup basada en diferencial de estados. Estos protocolos requieren un historial de transacciones completo para calcular la oferta y las tasas de préstamo cada segundo. Sin embargo, si el secuenciador ZK Rollup falla, ¿qué sucede cuando otros nodos Rollup intentan restaurar el último estado? Puede restaurar el estado, pero la tasa de interés se restaurará de manera incorrecta porque solo puede rastrear instantáneas entre lotes en lugar de cada transacción intermedia.

en conclusión

La afirmación principal de este artículo es que no hay “ZK” en la mayoría de los ZK Rollups actuales, y hay muchos lugares en DApps donde usar ZKP y procedimientos ZK puede no ser la mejor opción. La tecnología ZK puede parecer inocente de ser acusada porque no tiene nada de malo en sí misma, pero puede provocar una posible degradación del rendimiento de las DApps en el proceso de utilización de su avance tecnológico. Sin embargo, esto no quiere decir que la tecnología ZK sea inútil para la industria. Cuando las ZKP y las acumulaciones de ZK finalmente maduren, definitivamente podrán brindar mejores soluciones al trilema de la cadena de bloques. De hecho, ya existen proyectos basados en ZK que mantienen la privacidad de ZK, y hay muchos tipos de DApps que aprovechan eficazmente las ZKP y las convoluciones de ZK.

Enlace original

Este artículo proviene de Internet: ZK Rollups: El elefante en la habitación

Relacionado: El ETF al contado de Hong Kong está a punto de cotizar en bolsa. ¿A qué otros proyectos conceptuales de Hong Kong merece la pena prestar atención?

El 24 de abril, según noticias oficiales, China Asset Management (Hong Kong) anunció hoy que China Asset Managements Bitcoin ETF y China Asset Managements Ethereum ETF han sido aprobados por la Comisión de Valores y Futuros (SFC) de Hong Kong y están programados para ser emitido el 29 de abril de 2024 y cotizado en la plataforma comercial de Hong Kong el 30 de abril de 2024. Esta es la primera vez que se lanzan productos de este tipo en el mercado asiático. Estos dos tipos de productos están diseñados para proporcionar retornos de inversión anclados a los precios spot de Bitcoin y Ethereum. Este importante movimiento ha vuelto a llamar la atención sobre el concepto de Hong Kong. A principios de este año, CFX, el líder del concepto de Hong Kong, subió de US$0.19 a US$0.52 en dos meses.…