Para resolver el problema de expansión de la red Blockchain Layer 1, surgió la solución Rollup. Combinado con la tecnología ZK, ZK Rollup se ha convertido en el nuevo favorito de la pista de Capa 2. Sin embargo, para la mayoría de las personas, los conceptos relacionados como ZK, Rollup y EVM pueden tener un cierto umbral de comprensión. Por lo tanto, el objetivo de este informe de investigación es ordenar sistemáticamente una serie de conceptos de zkEVM Rollup en un lenguaje conciso y fácil de entender, analizar en profundidad la evolución y el estado de desarrollo de la tecnología zkEVM Rollup e interpretar los principales aspectos ecológicos. proyectos en detalle Está diseñado para ayudarlo a comprender completamente y juzgar la tendencia de desarrollo de la pista zkEVM Rollup.
PARTE 1Comprender ZK
ZK (o ZKP), el nombre completo es Prueba de conocimiento cero, es decir, prueba de conocimiento cero. En criptografía, la prueba de conocimiento cero o el protocolo de conocimiento cero es un método a través del cual una parte (el probador) puede enviar a la otra parte (certificador de verificación) para probar un hecho sin revelar la información específica del hecho, es decir, una parte (probador) puede hacer saber a la otra parte si el hecho es correcto sin revelar ninguna "información específica" de el hecho, por lo que la tecnología ZK se puede utilizar en la privacidad El campo de protección nos deja mucho espacio para la imaginación.
Por supuesto, además de los beneficios de la protección de la privacidad que puede brindar la tecnología ZK, en ZK Rollup, la tecnología ZK es más importante para resolver el problema de la "verificación difícil". El proceso de "verificación" es muy importante para la cadena de bloques. La mayor parte del proceso de cálculo en Ethereum es cumplir con los requisitos de verificación, y ZK Rollup puede reducir en gran medida el tiempo dedicado a la verificación por parte de toda la red de nodos. Por ejemplo, si un bloque tarda mucho en verificar que cumple con las reglas de toda la red cuando se generó el bloque, puede haber un probador que primero lo verifique y genere una "prueba" del resultado del cálculo de este bloque, y el resto El propósito de verificar el bloque se puede lograr verificando rápidamente esta "prueba" en lugar del bloque original con una gran cantidad de cálculos.
Un protocolo ZK simple se divide en los siguientes pasos, generación de claves, prueba y verificación, y los desarmaré uno por uno.
01Generación de claves, prueba y verificación
En ZK, primero debemos convertir el problema a verificar en una expresión matemática y luego en un polinomio, y expresarlo en forma de un circuito aritmético. Cuando un programa se convierte en un circuito aritmético, se divide en pasos individuales que consisten en operaciones aritméticas básicas como suma, resta, etc. Como una función que se generará, se puede transformar en el siguiente diagrama de circuito, consulte la Figura 1.
Figura 1 Un ejemplo de un diagrama de circuito, se puede notar que todas las operaciones en el circuito se dividen en las operaciones básicas más simples | Fuente
Usando este circuito y algunos números aleatorios como entrada, podemos generar una clave de prueba (pk, clave de prueba) y una clave de verificación (vk, clave de verificación) para el proceso de verificación posterior, el diagrama esquemático se muestra en la Figura 2.
Figura 2 Generación de "parámetros públicos"
Nuestro sistema de prueba también requiere dos tipos de entradas: privada y pública, junto con la clave de prueba para generar la prueba. Entre ellos, el input privado (testigo) es el secreto que queremos ocultar, y el input público es la información que se puede hacer pública. Por ejemplo, en la ecuación X+Y*Z=OUT, X y OUT son entradas públicas, mientras que Y y Z tienen valores que no queremos que sean públicos para el validador. Aunque el valor de Y*Z se puede deducir en función de la opinión pública, los valores específicos de Y y Z aún son inciertos.
Figura 3 El proceso de prueba y el proceso de verificación de ZK-SNARK
Cuando el verificador recibe la prueba, utiliza la entrada pública, la prueba y la clave de verificación para verificar la prueba y devuelve el resultado de la verificación (es decir, si la verificación es exitosa).
Después de comprender el proceso anterior, podemos aplicar esta tecnología para bloquear la verificación para realizar un pequeño ZK-SNARK, como se muestra en la Figura 3. Hay muchos protocolos y métodos para realizar pruebas de conocimiento cero. SNARK es relativamente fácil de entender, y también es la elección de la mayoría de los proyectos en esta etapa. En el apartado "De ZK-SNARKs a ZK-STARKs" hablaremos de las ventajas y desventajas de los SNARKs.
02Prueba un poco de SNARK
Tomemos una prueba de conocimiento cero de un Merkle Tree que registra el estado de la cuenta como un ejemplo para practicar. El Merkle Tree registra la dirección y el saldo de la cuenta. Cuando hay una nueva transacción que necesita actualizar Merkle Tree, debemos realizar las siguientes operaciones:
Verifique que el remitente y el receptor de la transacción estén en los nodos hoja del árbol.
Verificar la firma del remitente.
Actualizar los saldos del remitente y del destinatario.
Actualice el nodo raíz de Merkle Tree (es decir, Merkle Root) y utilícelo como salida final.
En ausencia de pruebas de conocimiento cero, el verificador debe repetir estos pasos para garantizar la precisión del cálculo. Pero después de usar la prueba de conocimiento cero, la situación es diferente. Primero, necesitamos identificar dos tipos de entradas:
Durante este proceso, solo la información de la nueva transacción, el Merkle Root original y el Merkle Root actualizado son entradas públicas.
El Merkle Tree en sí mismo actúa como testigo (testigo) y no necesita ser leído o procesado por el verificador.
En segundo lugar, necesitamos generar claves y calcular circuitos. Construimos procesos de cálculo como la actualización de Merkle Tree y la verificación de direcciones de entrada y salida en circuitos de cálculo para obtener claves de prueba y claves de verificación. Este circuito no tiene nada que ver con la información de la transacción de entrada, ni con el Merkle Root existente, porque el método de cálculo del Merkle Tree es fijo.
En la etapa de generación de pruebas, tomamos como entrada los dos Merkle Trees y la información de la transacción. En la etapa de verificador, el verificador puede asegurar la confiabilidad de la actualización sin obtener el Merkle Tree, es decir, sin conocer la información de la cuenta. El circuito es como una caja negra sólida, siempre que la entrada sea correcta, obtendrá la salida correcta.
Al usar la prueba de conocimiento cero, otros verificadores pueden verificar rápidamente que el proceso de generación de Merkle Tree es creíble, lo que reduce el tiempo para la verificación repetida en la red, y la información de Merkle Tree no necesita ser revelada al verificador.
03De ZK-SNARK a ZK-STARK
El protocolo de prueba mencionado anteriormente es ZK-SNARKs. SNARK significa argumentos de conocimiento sucintos no interactivos, donde sucinto se refiere a la concisión de este método, y no interactivo se refiere a que, en comparación con otros métodos de prueba, los SNARK son pruebas no interactivas, es decir, el verificador solo necesita usar la prueba proporcionada por el probador La prueba generada puede obtener el resultado de la verificación. Sin embargo, existen algunos problemas con los ZK-SNARK. En la etapa de generación de claves, el circuito y el número aleatorio son equivalentes a un conjunto de parámetros públicos iniciales, y existe un problema de centralización inevitable en el proceso de generación de este parámetro público.
Los ZK-STARK tienen un enfoque diferente basado en SNARK, donde "s" significa escalabilidad, lo que demuestra que el tiempo de generación y el tiempo de cálculo original son casi lineales, mientras que el tiempo de verificación es logarítmico en el cálculo original, lo que significa que en el caso de un gran conjunto de datos como datos, el tiempo de verificación requerido por el verificador se acorta considerablemente.
Al mismo tiempo, como una versión mejorada de ZK-SNARK, ZK-STARK no solo puede mejorar la eficiencia de verificación (la eficiencia teórica es 10 veces mayor), sino que tampoco depende de curvas elípticas o configuraciones confiables, y no requiere el proceso. de generar parámetros públicos iniciales (la letra "T" significa transparencia), lo que elimina la necesidad de una configuración confiable centralizada. Algunos desarrolladores creen que la función hash de ZK-STARK puede ayudar a resistir los ataques cuánticos.
Sin embargo, ZK-STARKs se introdujo tarde, la tecnología actual no es lo suficientemente madura y se basa en funciones hash, lo que limita su versatilidad.ZK-SNARKs sigue siendo un algoritmo de prueba general. Algunos ejemplos de algoritmos basados en STARK incluyen Fractal, SuperSonic, etc., y proyectos relacionados incluyen StarkWare, Polygon Miden, etc.
PARTE 2Comprensión del resumen
Además de ZK, otro concepto que necesitamos entender es el de Rollup.La importancia de Rollup es resolver el problema de congestión de la red de capa 1.
Tome Ethereum como ejemplo, actualmente tiene el problema de la congestión de transacciones. Hay dos formas de resolver este problema: una es aumentar la capacidad de transacción de la propia cadena de bloques, como expandir el rendimiento de la cadena de bloques a través de tecnologías como la fragmentación. Otro enfoque es cambiar la forma en que se utiliza la cadena de bloques, es decir, realizar la mayoría de las actividades en la segunda capa (Capa 2, en lo sucesivo denominada L2), en lugar de hacerlo directamente en la cadena. En este caso, a menudo se implementa un contrato inteligente en la cadena, que solo es responsable de procesar depósitos y retiros, y utiliza varios métodos para leer datos fuera de la cadena para verificar que todo lo que sucede fuera de la cadena cumple con las reglas. Esto equivale a construir una autopista junto a una carretera pequeña, es decir, mediante la ampliación de la L2 para solucionar el problema de la congestión.
Actualmente, los tres tipos principales o soluciones para la expansión de L2 son los canales de estado, Plasma y Rollup. Son tres paradigmas diferentes, cada uno con ventajas y desventajas. Todas las extensiones L2 se pueden clasificar aproximadamente en estas tres categorías (aunque existen algunas disputas sobre nombres, como validium), entre las cuales Rollup tiene sus propias ventajas.
Resumen y disponibilidad de datos
En comparación con otras soluciones de expansión, Rollup tiene ciertas ventajas, una de las ventajas más intuitivas es que resuelve el problema de la disponibilidad de datos de Plasma (mencionado en el capítulo "Disponibilidad de datos" del artículo del Sr. Darren), y aquí también haré algunos suplemento.
El hecho de que los datos estén en cadena es muy importante (nota: poner datos "en IPFS" no funcionará, porque IPFS no proporciona una verificación de nivel de consenso de que no hay garantía de que un dato determinado esté disponible, es decir, los datos deben ser almacenado en bloques). En los dos esquemas de expansión de Plasma y el Canal anterior, los datos y los cálculos se colocan completamente en la red de segunda capa. Cuando la red de segunda capa interactúa con Ethereum, no se incluyen todos los datos de transacción en la cadena de segunda capa. estado Desde la perspectiva de la máquina, es decir, no se incluyen todos los cambios de estado de la cadena de plasma. Esto conducirá al hecho de que si Ethereum se separa de la red de segundo nivel, como Plasma, no podrá restaurar los cambios de estado anteriores. Por lo tanto, la disponibilidad de los datos de Ethereum depende en gran medida de la protección de los datos de Plasma.
Mecanismo de enrollamiento
Para garantizar la disponibilidad de datos, el mercado elige Rollup, entonces, ¿cómo funciona Rollup?
Figura 4 Estado Raíz en el contrato L1 | Fuente
En el diseño de resumen, hay un contrato de resumen en la cadena principal, que almacena una raíz de estado. Esta raíz de estado se puede considerar como una versión mejorada de la raíz de Merkle del árbol de Merkle, que almacena el saldo de la cuenta (es decir, un tipo de estado), el código del contrato y otra información. La figura 4 muestra la raíz de estado almacenada en el contrato acumulativo. .
El nodo L2 tiene tres funciones principales: primero, determinar qué transacciones deben empaquetarse primero (por lo general, este tipo de nodo o cliente se llama secuenciador Secuenciador), en segundo lugar, debe proporcionar una prueba para cada dato empaquetado y, finalmente, enviarlo a el contrato L1 The Rollup se verifica mediante este contrato. La figura 5 muestra el papel del secuenciador en L2.
Figura 5 La secuenciación, la prueba y el envío por lotes son las funciones principales de la fase L2 | Fuente
Específicamente, L2 puede transferir un lote de datos (lote) a L1. Estos datos pueden ser colecciones de transacciones altamente comprimidas o cambios de estado después de que se ejecuta el contrato, y también incluyen la raíz de estado almacenada en el contrato L1 y la nueva raíz posterior al estado ( post-state root) obtenido después de que L2 procese los datos. El contrato verifica la corrección de la raíz posterior al estado en función de estos datos. Una vez que se pasa la verificación, el lote de datos se confirmará en la capa L1, completando el proceso en cadena de L2 a L1.
La raíz posterior al estado (raíz posterior al estado) se calcula a partir de los datos originales. Para garantizar que la nueva raíz posterior al estado en los datos enviados sea correcta, la forma más sencilla es dejar que L1 vuelva a calcular una vez. Sin embargo, hacerlo sin duda ejercerá mucha presión sobre L1. Para resolver este problema crítico, existen dos esquemas de optimización completamente diferentes, Optimistic Rollup y ZK Rollup.
Acumulación de ZK y acumulación optimista
ZK Rollup utiliza pruebas de protocolo criptográfico como ZK-SNARK o ZK-STARK para verificar la corrección de la raíz posterior al estado después de ejecutar el lote. Independientemente de la cantidad de cálculo en L2, ZK Rollup puede verificar rápidamente en la cadena L1.
Otro tipo de prueba es Optimistic Rollup, que utiliza pruebas de fraude. Hay una analogía vívida aquí, es como una madre que no revisa la tarea de su hijo con frecuencia, pero mientras la tarea no se complete una vez, será severamente castigada. Bajo este mecanismo, el contrato de resumen realiza un seguimiento del historial completo de la raíz del estado y los hashes de cada lote. Si alguien descubre que un lote tiene una raíz posterior al estado incorrecta, puede publicar una prueba de que el lote se calculó incorrectamente. Los otros nodos juntos verifican la prueba y restauran el lote y todos los lotes subsiguientes.
La Figura 6 resume la comparación de las ventajas y desventajas de Optimistic Rollup y ZK Rollup. Es importante señalar aquí que ZK Rollup sobresale en TPS y tiene una ventaja significativa en los ciclos de reembolso. Sin embargo, sus desventajas son la compatibilidad con EVM y el consumo computacional en la capa L2:
Los proyectos Optimistic Rollup, como Optimism y Arbitrum, usan OVM y AVM respectivamente, y sus entornos virtuales son básicamente los mismos que EVM, por lo que los contratos en la capa L1 se pueden migrar directamente a L2 para su implementación. Sin embargo, en ZK Rollup, es bastante difícil usar ZK-SNARK para probar la ejecución general de EVM, porque EVM no se desarrolla de acuerdo con los requisitos matemáticos del cálculo de prueba ZK, por lo que es necesario transformar cierto tipo de cliente EVM para usar Tecnología ZK para verificar transacciones y operaciones de contratación.
Al mismo tiempo, incluso después de la conversión correspondiente, la operación ZK aún requiere una gran cantidad de entrada de energía informática, por lo que ZK Rollup no es tan eficiente como Optimistic Rollup en la eficiencia de la capa L2.
ZK Rollup proporciona una mejor compresión de datos que Optimistic Rollup, por lo que puede enviar datos más pequeños en L1.
Dado que el proceso de verificación de prueba en ZK es más rápido y tiene una mayor densidad de lotes, ZK Rollup es menor en el consumo de cálculo de la capa L1. Se puede entender que el pago del nodo en L2 reduce en gran medida los requisitos para los nodos L1, lo que mejora significativamente la escalabilidad de la capa L1.
Figura 6 Comparación de dos métodos de consolidación | Fuente:
**¿Paquete acumulativo ZK o acumulativo zkEVM? **
Aunque ZK Rollup parece atractivo, existen muchas dificultades en la implementación real. En la actualidad, ZK Rollup todavía tiene limitaciones considerables, mientras que Optimistic Rollup sigue siendo la solución principal. La mayoría de los ZK Rollups implementados también están hechos a medida para algunas aplicaciones específicas.
¿Cómo entender el ZK Rollup personalizado? Los desarrolladores construyen circuitos específicos de la aplicación ("ASIC") para diferentes DApps, como Loopring, StarkEx rollup y zkSync 1.0, que admiten tipos específicos de pago, intercambio de tokens o emisión de NFT. Sin embargo, el diseño de su circuito requiere un alto grado de conocimiento técnico, lo que conduce a una mala experiencia del desarrollador. Tomando como ejemplo un tipo específico de datos de pago, el nodo envía los datos de la transacción al secuenciador, y el secuenciador los empaqueta en un lote y lo envía al nodo que envía la prueba como entrada pública, el proceso de prueba y el contrato. proceso de ejecución en la máquina virtual No tiene nada que ver, ZK solo es responsable de probar el proceso de cálculo y compresión de acumulación de un resultado de ejecución específico.
Y zkEVM Rollup representa la capacidad de acumular los resultados de ejecución de la máquina virtual. Cuando se ejecuta un contrato inteligente de uso general en la capa L2, es necesario probar la validez de la transición de estado antes y después de que se ejecute el contrato, y se requiere un entorno virtual para respaldar la operación del algoritmo ZK. Por lo tanto, el significado de zkEVM es ejecutar el contrato, generar el estado final, probar la validez del proceso de ejecución del contrato y enviar los registros de transacciones, registros de cuentas y datos de registro de cambio de estado juntos en resumen. La capa L1 solo necesita verificar rápidamente la prueba, la sobrecarga es pequeña y no hay necesidad de ejecutar el contrato nuevamente.La Figura 7 ilustra vívidamente el papel de zkVM. Cabe señalar que zkEVM es en realidad una máquina virtual similar a EVM que se ejecuta en la capa L2, por lo que un término más preciso es Máquina virtual de conocimiento cero, zkVM, pero todos enfatizan que es compatible con Ethereum y lo llaman zkEVM.
Figura 7 Un diagrama que ilustra zkVM | Fuente
Los proyectos existentes también están considerando abandonar gradualmente la optimización para aplicaciones específicas y actualizarse para admitir la ejecución de contratos de propósito general, es decir, zkEVM Rollup. Por lo tanto, aunque zkEVM Rollup es un concepto subordinado de ZK Rollup, en la mayoría de los casos, cuando se menciona ZK Rollup, se refiere a zkEVM rollup.
PARTE 4Descripción general del proyecto de acumulación de zkEVM
En la primera mitad de 2023 surgirán de forma súbita varios proyectos zkEVM, a los que el autor presta atención principalmente en los siguientes aspectos:
Progreso actual del proyecto: incluida la etapa actual del proyecto y el tiempo de lanzamiento esperado de la red de prueba y la red principal, y si es consistente con la hoja de ruta de desarrollo.
La interacción real del proyecto: a través de la interacción con la red de prueba (principal), etc., sienta subjetivamente el TPS de la red, el tiempo de confirmación de una sola transacción, etc., y tenga una sensación intuitiva del rendimiento de la red.
Compatibilidad con zkEVM: este es el punto técnico más central y el más difícil de juzgar. Incluso si algunos proyectos son de código abierto, la tecnología a nivel de VM es la más difícil e involucra más protocolos ZK. En concreto, hay que prestar atención al protocolo ZK, seguridad de la VM, compatibilidad, etc.
Arquitectura de resumen de zkEVM: en comparación con zkEVM, los proyectos generales divulgarán su arquitectura de resumen en libros blancos y otros documentos técnicos, y la diferencia general es menor, pero se debe prestar atención a su grado general de descentralización.
Operación ecológica: El número de usuarios del proyecto, el grado de actividad, la operación e incubación de la ecología de la aplicación en la cadena y el mantenimiento de la comunidad de desarrolladores son indicadores que reflejan suavemente la operación del proyecto.
Situación de inversión y financiación.
Este artículo considera el proyecto más desde la perspectiva de los primeros cuatro puntos y presta más atención a la arquitectura general de zkEVM Rollup desde el nivel técnico.
Desplazarse
El equipo de Scroll, fundado en 2021, se compromete a desarrollar el equivalente de EVM de ZK Rollup para escalar Ethereum.Durante casi dos años, Scroll ha estado trabajando con el equipo de Exploraciones de privacidad y escalado y otros colaboradores de código abierto para crear públicamente un paquete acumulativo compatible con código de bytes. .zkEVM. A fines de febrero, Scroll anunció que su red de prueba Alpha ahora está activa en Goerli. Cualquier usuario puede participar en las pruebas técnicas sin permiso. El tiempo promedio de bloqueo de la red de prueba es de 3 segundos. Ya hay más de 20 millones de transacciones y más de 1,5 millones de bloques y más de 4 millones de direcciones interactivas. Al mismo tiempo, Scroll también abrió la interfaz del ecosistema del sitio web el 11 de abril.
A juzgar por la reciente divulgación de información, Scroll avanza constantemente en el camino de la equivalencia de EVM Tipo 2. Recientemente, Scroll completó el desarrollo compatible de todos los códigos de operación EVM y está en proceso de auditoría. Al mismo tiempo, el próximo objetivo es ser compatible con las transacciones EIP2718.
En términos de arquitectura técnica, la arquitectura de Scroll es relativamente tradicional, por lo que se presentará en detalle aquí. Como se muestra en la Figura 8, se divide principalmente en dos partes: la parte central es zkEVM, que se usa para probar la corrección de la ejecución de EVM en L2; pero para convertir zkEVM en un ZK Rollup completo en Ethereum, se necesita un L2 completo. construirse alrededor de la arquitectura zkEVM. Específicamente, la red de prueba Scroll Alpha existente consta de Scroll Node, Bridge Contract y Rollup Contract:
Figura 8 Arquitectura general del resumen de desplazamiento | Fuente
Nodo Scroll: compuesto por Secuenciador, Retransmisor y Coordinador.
a) Sequencer, el llamado secuenciador, abre JSON-RPC a usuarios y aplicaciones, lee transacciones en el grupo de transacciones y genera bloques L2 y raíces de estado. En esta etapa, los nodos Sequencer de Scroll están centralizados y se descentralizarán gradualmente en futuras actualizaciones.
b) El Coordinador es responsable de la comunicación entre el Roller y el Scroll Node.Cuando se genera un nuevo bloque en el Secuenciador, el Roller en el pool se selecciona aleatoriamente para la generación de prueba.
c) El Retransmisor monitorea el Contrato Puente y el Contrato Rollup en las cadenas Ethereum y Scroll. El contrato de resumen garantiza la disponibilidad de datos de los datos L2 en el nivel L1 y garantiza que el bloque L2 se pueda restaurar en la capa L1. Una vez que el bloque enviado por la capa L2 es verificado por el contrato de resumen en la capa L1, el bloque alcanzará la finalidad en la capa L2 El estado inmutable de . El contrato puente es responsable de la comunicación entre los contratos de doble cadena al cruzar cadenas, enviar mensajes arbitrarios en ambas direcciones o completar las operaciones de compromiso y retiro de activos al cruzar cadenas.
Figura 9 2. Red de rodillos | Fuente
Roller Network: Roller tiene un zkEVM incorporado, que actúa como probador en la red y es responsable de generar pruebas de validez para ZK Rollup, como se muestra en la Figura 9.
a) Roller primero convierte el rastro de acción recibido del Coordinador (es decir, qué operaciones específicas ha realizado el contrato y qué direcciones están involucradas) en testigos de circuito.
b) Genera pruebas para cada circuito zkEVM y finalmente agrega estas pruebas de múltiples circuitos ZK.
StarkWare
StarkWare proporciona una solución de escalado basada en STARK para garantizar la seguridad L2, la velocidad y una experiencia de usuario perfecta. Admiten múltiples modos de disponibilidad de datos. StarkNet es su red L2, mientras que StarkEx es un servicio de verificación de resumen para usuarios empresariales, y las DApps se pueden construir en los servicios de StarkEx. Sin embargo, actualmente solo se pueden escribir circuitos personalizados para DApps específicas, no para el paquete general de zkEVM. StarkEx admite una serie de servicios plug-and-play, que incluyen acuñación y comercio de NFT, comercio de derivados, etc. En términos de ecología, la plataforma descentralizada de comercio de contratos de futuros DYDX es un usuario leal de StarkWare.
StarkNet, estrictamente hablando, es zkVM En lugar de hacer circuitos ZK para los códigos de operación de Ethereum, ha creado un conjunto de lenguaje ensamblador más compatible con ZK, AIR (Representación intermedia algebraica) y lenguaje de alto nivel Cairo. Aunque StarkNet en sí mismo no es compatible con EVM, aún puede ser compatible con Ethereum a través de otros métodos, incluido Kakarot (Kakarot es un zkEVM escrito en El Cairo, que es un zkEVM cuyo código de bytes es equivalente a EVM). Según tengo entendido, StarkNet es un proyecto relativamente centralizado, uno de los cuales es que no se puede sincronizar con la actualización de seguridad de Ethereum, por lo que es necesario concentrar el personal de I+D para compensar las deficiencias en seguridad y seguir el desarrollo y adaptación de ETH nuevo acuerdo.
StarkNet usa STARK como su sistema de prueba Comparado con SNARK, STARK tiene más innovaciones. No necesita depender de "configuraciones confiables" como SNARK. Además, también tiene suposiciones criptográficas más simples, evita la necesidad de suposiciones de curva elíptica, emparejamiento y conocimiento exponencial, y se basa únicamente en la teoría de información y hashing, por lo que es más resistente a los ataques cuánticos. En general, los STARK son más seguros que los SNARK. En términos de capacidades de expansión, STARK tiene un efecto marginal significativo, y cuanto mayor sea la prueba, menor será el costo total.
Sin embargo, en términos de arquitectura, actualmente solo hay un Sequencer (secuenciador) en el sistema, que está controlado por StarkWare, y solo hay un Prover (es decir, el probador que genera ZK Proof), que no solo genera pruebas para StarkNet, pero también se ejecuta por su cuenta. Prueba de generación para todas las demás aplicaciones en el paquete acumulativo de StarkEx.
Variantes de ZK Rollup: Validiums y Volitions
Validium también es una solución de escalado L2 que utiliza pruebas de cálculo como ZK Rollup para reforzar la integridad del proceso de transacción. A diferencia de ZK Rollup, Validium no almacena datos de transacciones en la red principal de Ethereum. Sacrificar la disponibilidad de datos en la cadena es una compensación que puede conducir a grandes mejoras en la escalabilidad, siendo el punto más inmediato que Validiums puede procesar alrededor de 9000 transacciones por segundo.
Pero a los ojos del autor, Validium no puede ser considerado como un estricto ZK Rollup. Esta solución es similar a Plasma y no logra la disponibilidad de datos en la capa L1, por lo que no se puede contar como un Rollup. La diferencia con Plasma es que Plasma ha establecido un "mecanismo de salida de siete días" similar a OP Rollup en la capa L2, mientras que Validium usa y ZK significa acortar el tiempo de verificación de los datos en la capa L2 y no sincroniza el datos a la L1.
Volition, iniciado por StarkWare, permite a los usuarios cambiar fácilmente entre ZK Rollup y Validium. Por ejemplo, algunas aplicaciones, como los intercambios de derivados descentralizados, pueden ser más adecuadas para Validium, mientras que aún desean ser interoperables con aplicaciones en ZK Rollup, entonces Volition proporciona esta capacidad de conmutación.
zkSync
Al igual que StarkNet, zkSync siempre ha insistido en elegir zkVM, que es equivalente a un lenguaje de alto nivel, y ha llamado mucho la atención, con una popularidad y un volumen de bloqueo muy altos. zkSync 1.0 (zkSync Lite) se lanzó en la red principal de Ethereum el 15 de junio de 2020, logrando un rendimiento de transacción de aproximadamente 300 TPS, pero no es compatible con EVM. Y zkSync 2.0 (zkSync Era) se lanzará el 24 de marzo de 2023.
El objetivo de zkSync Era es generar pruebas más rápido mediante el uso de su VM personalizada para la optimización en lugar de perseguir la equivalencia de EVM. Es compatible con Solidity, Vyper, Yul y Zinc (lenguaje de programación interno de rollup) a través de un potente compilador LLVM para implementar la mayoría de las funciones de contrato inteligente. Debido a la VM de desarrollo propio, zkSync Era admite la abstracción de cuentas nativas, de modo que cualquier cuenta puede usar cualquier Token para pagar.
Además, mediante la aplicación del protocolo zkPorter, combinado con ZK Rollups y tecnología de fragmentación, el rendimiento de la red se ha incrementado exponencialmente, alcanzando más de 20 000 TPS (similar al cambio de disponibilidad de datos de Volitions).
En general, zkSync es un proyecto L2 ecológicamente rico que ha atraído la atención de desarrolladores e inversores. Aunque ha habido algunos casos recientes de proyectos completamente fallidos en zkSync, todavía existe la duda de si los desarrolladores pueden obtener una buena experiencia de desarrollo y migración en el lenguaje de alto nivel equivalente a zkVM. Actualmente hay una falta de informes de uso exactos a nivel de desarrollador.Si los desarrolladores tienen una buena experiencia, ¿cuál es el punto de otros tipos de zkVM que se esfuerzan por estar cerca del EVM? Todavía necesitamos más tiempo para observar.
Polígono zkEVM
Polygon lanzó la versión beta de la red principal zkEVM Rollup el 27 de marzo, que también es la máquina virtual equivalente de Ethereum, y abrió todo el código zkEVM. En comparación con zkSync, la cantidad bloqueada de polígonos zkEVM es mucho menor, pero también hay muchos proyectos interesantes y dinámicos en la ecología.
En términos de diseño de resumen, Polygon se diferencia de Scroll en que utiliza un modelo de prueba de eficiencia (PoE) para motivar al secuenciador y al agregador a resolver algunos de los desafíos de la descentralización y los validadores sin permiso. En el modelo clasificador-agregador de dos pasos sin permiso, cualquier clasificador puede enviar una solicitud para empaquetar lotes para obtener la tarifa de empaque, pero debe pagar la tarifa de gas de la capa L1 y depositar una cierta cantidad de Token Al mismo tiempo, los tokens de agregación deben establecer sus propios objetivos para maximizar la ganancia garantizada para cada generación de prueba. Además, los modos Polygon y Volition (ZK Rollup y Validium) también tienen modelos de disponibilidad de datos profundamente compatibles para brindar a los usuarios diferentes niveles de servicios.
Además, Polygon también ha invertido una cantidad considerable de trabajo en el protocolo ZK, y el efecto también es notable.En el documento, resumen sus ventajas técnicas, incluyendo principalmente los siguientes puntos:
Más compatible: Polygon siempre ha insistido en usar zkVM, que es equivalente a EVM, para reducir el costo de los desarrolladores que migran dApps. Al mismo tiempo, aunque Polygon Miden adopta el protocolo ZK-STARK, aún admite la ejecución de contratos de Solidity.
Verificación más sencilla: la razón por la que se suele criticar a ZK Rollup es que la generación de pruebas de validez requiere un costoso hardware especializado que los proveedores ejecutan y transfieren el costo a los usuarios. Polygon ZK Rollup (como Polygon Zero) tiene como objetivo simplificar los esquemas de prueba para que los dispositivos de nivel inferior puedan participar, por ejemplo, las pruebas de generación de prueba Plonky2 en PC de consumo.
Proceso de verificación y generación de pruebas más rápido: Polygon Zero puede generar una prueba de 45 kb en 170 milisegundos.
PARTE 5Brecha entre la tecnología teórica y los proyectos prácticos
Este informe de investigación llevó a cabo principalmente la divulgación científica de la tecnología ZK y la introducción del mecanismo Rollup, enfatizando la importancia de la disponibilidad de datos, e hizo una cierta distinción sobre el tema de ZK o zkEVM Rollup. Además, sobre la base de distinguir zkVM y zkEVM, también resuelve en detalle las diferencias entre los tres tipos de zkEVM y los diferentes tipos y pistas ZK relacionadas. Finalmente, combinado con varios proyectos ventajosos, revisaron sus respectivos marcos técnicos y la ecología existente.
Sin embargo, en términos de proyectos específicos, los proyectos que eligen lenguajes de alto nivel equivalentes ocupan la posición principal en el mercado, y algunos productos con una centralización seria como StarkWare también pueden ganar el favor del mercado. Aunque el primer tipo de VM mencionado en la investigación teórica tiene fuertes limitaciones, bajo los clientes de mercado limitados, la "universalidad" parece ser una carga, y no podemos distinguir qué problemas ha superado la "expansión eficiente" y se ha dado cuenta del efecto más allá de la teoría. . Por supuesto, de hecho, muchas personas no prestan atención a las características técnicas, por lo que esto no parece muy Web3, pero sí muy Web3.
El propósito de la tecnología Rollup es aprovechar aún más el valor de la cadena de bloques, pero a menudo, debido a la necesidad urgente de convertirse en un "concepto innovador" en el mercado, existe un fenómeno de "retroceso" y regreso a la centralización. Este es el problema del mercado actual.
El valor de la cadena de bloques es fácil de ver, ¿quién no querría tener una computadora eterna? Pero el problema central es que cuando la capacidad de funcionamiento de esta computadora es mucho menor que la de cualquier servidor que nos rodea y requiere una gran inversión de recursos, incluso si el valor de uso es mucho menor que nuestro costo de entrada, como un "producto público". , todavía es ¿Pueden todos participar?
Cuando ya tenemos productos de muchos países, sociedades e incluso individuos, ¿bajo qué circunstancias estamos dispuestos a ignorar el alto costo de uso y perseguir el resultado de "siempre en línea, siempre correcto"? Creo que esto es algo en lo que la industria blockchain debe pensar hoy. La tecnología de acumulación técnicamente puede mejorar este problema, pero todavía hay una gran cantidad de problemas que deben dejarse en manos del impetuoso mercado para que los resuelva.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Rollup zkEVM: la brecha entre la visión tecnológica y el proyecto
Para resolver el problema de expansión de la red Blockchain Layer 1, surgió la solución Rollup. Combinado con la tecnología ZK, ZK Rollup se ha convertido en el nuevo favorito de la pista de Capa 2. Sin embargo, para la mayoría de las personas, los conceptos relacionados como ZK, Rollup y EVM pueden tener un cierto umbral de comprensión. Por lo tanto, el objetivo de este informe de investigación es ordenar sistemáticamente una serie de conceptos de zkEVM Rollup en un lenguaje conciso y fácil de entender, analizar en profundidad la evolución y el estado de desarrollo de la tecnología zkEVM Rollup e interpretar los principales aspectos ecológicos. proyectos en detalle Está diseñado para ayudarlo a comprender completamente y juzgar la tendencia de desarrollo de la pista zkEVM Rollup.
PARTE 1 Comprender ZK
ZK (o ZKP), el nombre completo es Prueba de conocimiento cero, es decir, prueba de conocimiento cero. En criptografía, la prueba de conocimiento cero o el protocolo de conocimiento cero es un método a través del cual una parte (el probador) puede enviar a la otra parte (certificador de verificación) para probar un hecho sin revelar la información específica del hecho, es decir, una parte (probador) puede hacer saber a la otra parte si el hecho es correcto sin revelar ninguna "información específica" de el hecho, por lo que la tecnología ZK se puede utilizar en la privacidad El campo de protección nos deja mucho espacio para la imaginación.
Por supuesto, además de los beneficios de la protección de la privacidad que puede brindar la tecnología ZK, en ZK Rollup, la tecnología ZK es más importante para resolver el problema de la "verificación difícil". El proceso de "verificación" es muy importante para la cadena de bloques. La mayor parte del proceso de cálculo en Ethereum es cumplir con los requisitos de verificación, y ZK Rollup puede reducir en gran medida el tiempo dedicado a la verificación por parte de toda la red de nodos. Por ejemplo, si un bloque tarda mucho en verificar que cumple con las reglas de toda la red cuando se generó el bloque, puede haber un probador que primero lo verifique y genere una "prueba" del resultado del cálculo de este bloque, y el resto El propósito de verificar el bloque se puede lograr verificando rápidamente esta "prueba" en lugar del bloque original con una gran cantidad de cálculos.
Un protocolo ZK simple se divide en los siguientes pasos, generación de claves, prueba y verificación, y los desarmaré uno por uno.
01 Generación de claves, prueba y verificación
En ZK, primero debemos convertir el problema a verificar en una expresión matemática y luego en un polinomio, y expresarlo en forma de un circuito aritmético. Cuando un programa se convierte en un circuito aritmético, se divide en pasos individuales que consisten en operaciones aritméticas básicas como suma, resta, etc. Como una función que se generará, se puede transformar en el siguiente diagrama de circuito, consulte la Figura 1.
Figura 1 Un ejemplo de un diagrama de circuito, se puede notar que todas las operaciones en el circuito se dividen en las operaciones básicas más simples | Fuente
Usando este circuito y algunos números aleatorios como entrada, podemos generar una clave de prueba (pk, clave de prueba) y una clave de verificación (vk, clave de verificación) para el proceso de verificación posterior, el diagrama esquemático se muestra en la Figura 2.
Figura 2 Generación de "parámetros públicos"
Nuestro sistema de prueba también requiere dos tipos de entradas: privada y pública, junto con la clave de prueba para generar la prueba. Entre ellos, el input privado (testigo) es el secreto que queremos ocultar, y el input público es la información que se puede hacer pública. Por ejemplo, en la ecuación X+Y*Z=OUT, X y OUT son entradas públicas, mientras que Y y Z tienen valores que no queremos que sean públicos para el validador. Aunque el valor de Y*Z se puede deducir en función de la opinión pública, los valores específicos de Y y Z aún son inciertos.
Figura 3 El proceso de prueba y el proceso de verificación de ZK-SNARK
Cuando el verificador recibe la prueba, utiliza la entrada pública, la prueba y la clave de verificación para verificar la prueba y devuelve el resultado de la verificación (es decir, si la verificación es exitosa).
Después de comprender el proceso anterior, podemos aplicar esta tecnología para bloquear la verificación para realizar un pequeño ZK-SNARK, como se muestra en la Figura 3. Hay muchos protocolos y métodos para realizar pruebas de conocimiento cero. SNARK es relativamente fácil de entender, y también es la elección de la mayoría de los proyectos en esta etapa. En el apartado "De ZK-SNARKs a ZK-STARKs" hablaremos de las ventajas y desventajas de los SNARKs.
02 Prueba un poco de SNARK
Tomemos una prueba de conocimiento cero de un Merkle Tree que registra el estado de la cuenta como un ejemplo para practicar. El Merkle Tree registra la dirección y el saldo de la cuenta. Cuando hay una nueva transacción que necesita actualizar Merkle Tree, debemos realizar las siguientes operaciones:
Verifique que el remitente y el receptor de la transacción estén en los nodos hoja del árbol.
Verificar la firma del remitente.
Actualizar los saldos del remitente y del destinatario.
Actualice el nodo raíz de Merkle Tree (es decir, Merkle Root) y utilícelo como salida final.
En ausencia de pruebas de conocimiento cero, el verificador debe repetir estos pasos para garantizar la precisión del cálculo. Pero después de usar la prueba de conocimiento cero, la situación es diferente. Primero, necesitamos identificar dos tipos de entradas:
Durante este proceso, solo la información de la nueva transacción, el Merkle Root original y el Merkle Root actualizado son entradas públicas.
El Merkle Tree en sí mismo actúa como testigo (testigo) y no necesita ser leído o procesado por el verificador.
En segundo lugar, necesitamos generar claves y calcular circuitos. Construimos procesos de cálculo como la actualización de Merkle Tree y la verificación de direcciones de entrada y salida en circuitos de cálculo para obtener claves de prueba y claves de verificación. Este circuito no tiene nada que ver con la información de la transacción de entrada, ni con el Merkle Root existente, porque el método de cálculo del Merkle Tree es fijo.
En la etapa de generación de pruebas, tomamos como entrada los dos Merkle Trees y la información de la transacción. En la etapa de verificador, el verificador puede asegurar la confiabilidad de la actualización sin obtener el Merkle Tree, es decir, sin conocer la información de la cuenta. El circuito es como una caja negra sólida, siempre que la entrada sea correcta, obtendrá la salida correcta.
Al usar la prueba de conocimiento cero, otros verificadores pueden verificar rápidamente que el proceso de generación de Merkle Tree es creíble, lo que reduce el tiempo para la verificación repetida en la red, y la información de Merkle Tree no necesita ser revelada al verificador.
03 De ZK-SNARK a ZK-STARK
El protocolo de prueba mencionado anteriormente es ZK-SNARKs. SNARK significa argumentos de conocimiento sucintos no interactivos, donde sucinto se refiere a la concisión de este método, y no interactivo se refiere a que, en comparación con otros métodos de prueba, los SNARK son pruebas no interactivas, es decir, el verificador solo necesita usar la prueba proporcionada por el probador La prueba generada puede obtener el resultado de la verificación. Sin embargo, existen algunos problemas con los ZK-SNARK. En la etapa de generación de claves, el circuito y el número aleatorio son equivalentes a un conjunto de parámetros públicos iniciales, y existe un problema de centralización inevitable en el proceso de generación de este parámetro público.
Los ZK-STARK tienen un enfoque diferente basado en SNARK, donde "s" significa escalabilidad, lo que demuestra que el tiempo de generación y el tiempo de cálculo original son casi lineales, mientras que el tiempo de verificación es logarítmico en el cálculo original, lo que significa que en el caso de un gran conjunto de datos como datos, el tiempo de verificación requerido por el verificador se acorta considerablemente.
Al mismo tiempo, como una versión mejorada de ZK-SNARK, ZK-STARK no solo puede mejorar la eficiencia de verificación (la eficiencia teórica es 10 veces mayor), sino que tampoco depende de curvas elípticas o configuraciones confiables, y no requiere el proceso. de generar parámetros públicos iniciales (la letra "T" significa transparencia), lo que elimina la necesidad de una configuración confiable centralizada. Algunos desarrolladores creen que la función hash de ZK-STARK puede ayudar a resistir los ataques cuánticos.
Sin embargo, ZK-STARKs se introdujo tarde, la tecnología actual no es lo suficientemente madura y se basa en funciones hash, lo que limita su versatilidad.ZK-SNARKs sigue siendo un algoritmo de prueba general. Algunos ejemplos de algoritmos basados en STARK incluyen Fractal, SuperSonic, etc., y proyectos relacionados incluyen StarkWare, Polygon Miden, etc.
PARTE 2 Comprensión del resumen
Además de ZK, otro concepto que necesitamos entender es el de Rollup.La importancia de Rollup es resolver el problema de congestión de la red de capa 1.
Tome Ethereum como ejemplo, actualmente tiene el problema de la congestión de transacciones. Hay dos formas de resolver este problema: una es aumentar la capacidad de transacción de la propia cadena de bloques, como expandir el rendimiento de la cadena de bloques a través de tecnologías como la fragmentación. Otro enfoque es cambiar la forma en que se utiliza la cadena de bloques, es decir, realizar la mayoría de las actividades en la segunda capa (Capa 2, en lo sucesivo denominada L2), en lugar de hacerlo directamente en la cadena. En este caso, a menudo se implementa un contrato inteligente en la cadena, que solo es responsable de procesar depósitos y retiros, y utiliza varios métodos para leer datos fuera de la cadena para verificar que todo lo que sucede fuera de la cadena cumple con las reglas. Esto equivale a construir una autopista junto a una carretera pequeña, es decir, mediante la ampliación de la L2 para solucionar el problema de la congestión.
Actualmente, los tres tipos principales o soluciones para la expansión de L2 son los canales de estado, Plasma y Rollup. Son tres paradigmas diferentes, cada uno con ventajas y desventajas. Todas las extensiones L2 se pueden clasificar aproximadamente en estas tres categorías (aunque existen algunas disputas sobre nombres, como validium), entre las cuales Rollup tiene sus propias ventajas.
Resumen y disponibilidad de datos
En comparación con otras soluciones de expansión, Rollup tiene ciertas ventajas, una de las ventajas más intuitivas es que resuelve el problema de la disponibilidad de datos de Plasma (mencionado en el capítulo "Disponibilidad de datos" del artículo del Sr. Darren), y aquí también haré algunos suplemento.
El hecho de que los datos estén en cadena es muy importante (nota: poner datos "en IPFS" no funcionará, porque IPFS no proporciona una verificación de nivel de consenso de que no hay garantía de que un dato determinado esté disponible, es decir, los datos deben ser almacenado en bloques). En los dos esquemas de expansión de Plasma y el Canal anterior, los datos y los cálculos se colocan completamente en la red de segunda capa. Cuando la red de segunda capa interactúa con Ethereum, no se incluyen todos los datos de transacción en la cadena de segunda capa. estado Desde la perspectiva de la máquina, es decir, no se incluyen todos los cambios de estado de la cadena de plasma. Esto conducirá al hecho de que si Ethereum se separa de la red de segundo nivel, como Plasma, no podrá restaurar los cambios de estado anteriores. Por lo tanto, la disponibilidad de los datos de Ethereum depende en gran medida de la protección de los datos de Plasma.
Mecanismo de enrollamiento
Para garantizar la disponibilidad de datos, el mercado elige Rollup, entonces, ¿cómo funciona Rollup?
Figura 4 Estado Raíz en el contrato L1 | Fuente
En el diseño de resumen, hay un contrato de resumen en la cadena principal, que almacena una raíz de estado. Esta raíz de estado se puede considerar como una versión mejorada de la raíz de Merkle del árbol de Merkle, que almacena el saldo de la cuenta (es decir, un tipo de estado), el código del contrato y otra información. La figura 4 muestra la raíz de estado almacenada en el contrato acumulativo. .
El nodo L2 tiene tres funciones principales: primero, determinar qué transacciones deben empaquetarse primero (por lo general, este tipo de nodo o cliente se llama secuenciador Secuenciador), en segundo lugar, debe proporcionar una prueba para cada dato empaquetado y, finalmente, enviarlo a el contrato L1 The Rollup se verifica mediante este contrato. La figura 5 muestra el papel del secuenciador en L2.
Figura 5 La secuenciación, la prueba y el envío por lotes son las funciones principales de la fase L2 | Fuente
Específicamente, L2 puede transferir un lote de datos (lote) a L1. Estos datos pueden ser colecciones de transacciones altamente comprimidas o cambios de estado después de que se ejecuta el contrato, y también incluyen la raíz de estado almacenada en el contrato L1 y la nueva raíz posterior al estado ( post-state root) obtenido después de que L2 procese los datos. El contrato verifica la corrección de la raíz posterior al estado en función de estos datos. Una vez que se pasa la verificación, el lote de datos se confirmará en la capa L1, completando el proceso en cadena de L2 a L1.
La raíz posterior al estado (raíz posterior al estado) se calcula a partir de los datos originales. Para garantizar que la nueva raíz posterior al estado en los datos enviados sea correcta, la forma más sencilla es dejar que L1 vuelva a calcular una vez. Sin embargo, hacerlo sin duda ejercerá mucha presión sobre L1. Para resolver este problema crítico, existen dos esquemas de optimización completamente diferentes, Optimistic Rollup y ZK Rollup.
Acumulación de ZK y acumulación optimista
ZK Rollup utiliza pruebas de protocolo criptográfico como ZK-SNARK o ZK-STARK para verificar la corrección de la raíz posterior al estado después de ejecutar el lote. Independientemente de la cantidad de cálculo en L2, ZK Rollup puede verificar rápidamente en la cadena L1.
Otro tipo de prueba es Optimistic Rollup, que utiliza pruebas de fraude. Hay una analogía vívida aquí, es como una madre que no revisa la tarea de su hijo con frecuencia, pero mientras la tarea no se complete una vez, será severamente castigada. Bajo este mecanismo, el contrato de resumen realiza un seguimiento del historial completo de la raíz del estado y los hashes de cada lote. Si alguien descubre que un lote tiene una raíz posterior al estado incorrecta, puede publicar una prueba de que el lote se calculó incorrectamente. Los otros nodos juntos verifican la prueba y restauran el lote y todos los lotes subsiguientes.
La Figura 6 resume la comparación de las ventajas y desventajas de Optimistic Rollup y ZK Rollup. Es importante señalar aquí que ZK Rollup sobresale en TPS y tiene una ventaja significativa en los ciclos de reembolso. Sin embargo, sus desventajas son la compatibilidad con EVM y el consumo computacional en la capa L2:
Los proyectos Optimistic Rollup, como Optimism y Arbitrum, usan OVM y AVM respectivamente, y sus entornos virtuales son básicamente los mismos que EVM, por lo que los contratos en la capa L1 se pueden migrar directamente a L2 para su implementación. Sin embargo, en ZK Rollup, es bastante difícil usar ZK-SNARK para probar la ejecución general de EVM, porque EVM no se desarrolla de acuerdo con los requisitos matemáticos del cálculo de prueba ZK, por lo que es necesario transformar cierto tipo de cliente EVM para usar Tecnología ZK para verificar transacciones y operaciones de contratación.
Al mismo tiempo, incluso después de la conversión correspondiente, la operación ZK aún requiere una gran cantidad de entrada de energía informática, por lo que ZK Rollup no es tan eficiente como Optimistic Rollup en la eficiencia de la capa L2.
ZK Rollup proporciona una mejor compresión de datos que Optimistic Rollup, por lo que puede enviar datos más pequeños en L1.
Dado que el proceso de verificación de prueba en ZK es más rápido y tiene una mayor densidad de lotes, ZK Rollup es menor en el consumo de cálculo de la capa L1. Se puede entender que el pago del nodo en L2 reduce en gran medida los requisitos para los nodos L1, lo que mejora significativamente la escalabilidad de la capa L1.
Figura 6 Comparación de dos métodos de consolidación | Fuente:
**¿Paquete acumulativo ZK o acumulativo zkEVM? **
Aunque ZK Rollup parece atractivo, existen muchas dificultades en la implementación real. En la actualidad, ZK Rollup todavía tiene limitaciones considerables, mientras que Optimistic Rollup sigue siendo la solución principal. La mayoría de los ZK Rollups implementados también están hechos a medida para algunas aplicaciones específicas.
¿Cómo entender el ZK Rollup personalizado? Los desarrolladores construyen circuitos específicos de la aplicación ("ASIC") para diferentes DApps, como Loopring, StarkEx rollup y zkSync 1.0, que admiten tipos específicos de pago, intercambio de tokens o emisión de NFT. Sin embargo, el diseño de su circuito requiere un alto grado de conocimiento técnico, lo que conduce a una mala experiencia del desarrollador. Tomando como ejemplo un tipo específico de datos de pago, el nodo envía los datos de la transacción al secuenciador, y el secuenciador los empaqueta en un lote y lo envía al nodo que envía la prueba como entrada pública, el proceso de prueba y el contrato. proceso de ejecución en la máquina virtual No tiene nada que ver, ZK solo es responsable de probar el proceso de cálculo y compresión de acumulación de un resultado de ejecución específico.
Y zkEVM Rollup representa la capacidad de acumular los resultados de ejecución de la máquina virtual. Cuando se ejecuta un contrato inteligente de uso general en la capa L2, es necesario probar la validez de la transición de estado antes y después de que se ejecute el contrato, y se requiere un entorno virtual para respaldar la operación del algoritmo ZK. Por lo tanto, el significado de zkEVM es ejecutar el contrato, generar el estado final, probar la validez del proceso de ejecución del contrato y enviar los registros de transacciones, registros de cuentas y datos de registro de cambio de estado juntos en resumen. La capa L1 solo necesita verificar rápidamente la prueba, la sobrecarga es pequeña y no hay necesidad de ejecutar el contrato nuevamente.La Figura 7 ilustra vívidamente el papel de zkVM. Cabe señalar que zkEVM es en realidad una máquina virtual similar a EVM que se ejecuta en la capa L2, por lo que un término más preciso es Máquina virtual de conocimiento cero, zkVM, pero todos enfatizan que es compatible con Ethereum y lo llaman zkEVM.
Figura 7 Un diagrama que ilustra zkVM | Fuente
Los proyectos existentes también están considerando abandonar gradualmente la optimización para aplicaciones específicas y actualizarse para admitir la ejecución de contratos de propósito general, es decir, zkEVM Rollup. Por lo tanto, aunque zkEVM Rollup es un concepto subordinado de ZK Rollup, en la mayoría de los casos, cuando se menciona ZK Rollup, se refiere a zkEVM rollup.
PARTE 4 Descripción general del proyecto de acumulación de zkEVM
En la primera mitad de 2023 surgirán de forma súbita varios proyectos zkEVM, a los que el autor presta atención principalmente en los siguientes aspectos:
Progreso actual del proyecto: incluida la etapa actual del proyecto y el tiempo de lanzamiento esperado de la red de prueba y la red principal, y si es consistente con la hoja de ruta de desarrollo.
La interacción real del proyecto: a través de la interacción con la red de prueba (principal), etc., sienta subjetivamente el TPS de la red, el tiempo de confirmación de una sola transacción, etc., y tenga una sensación intuitiva del rendimiento de la red.
Compatibilidad con zkEVM: este es el punto técnico más central y el más difícil de juzgar. Incluso si algunos proyectos son de código abierto, la tecnología a nivel de VM es la más difícil e involucra más protocolos ZK. En concreto, hay que prestar atención al protocolo ZK, seguridad de la VM, compatibilidad, etc.
Arquitectura de resumen de zkEVM: en comparación con zkEVM, los proyectos generales divulgarán su arquitectura de resumen en libros blancos y otros documentos técnicos, y la diferencia general es menor, pero se debe prestar atención a su grado general de descentralización.
Operación ecológica: El número de usuarios del proyecto, el grado de actividad, la operación e incubación de la ecología de la aplicación en la cadena y el mantenimiento de la comunidad de desarrolladores son indicadores que reflejan suavemente la operación del proyecto.
Situación de inversión y financiación.
Este artículo considera el proyecto más desde la perspectiva de los primeros cuatro puntos y presta más atención a la arquitectura general de zkEVM Rollup desde el nivel técnico.
Desplazarse
El equipo de Scroll, fundado en 2021, se compromete a desarrollar el equivalente de EVM de ZK Rollup para escalar Ethereum.Durante casi dos años, Scroll ha estado trabajando con el equipo de Exploraciones de privacidad y escalado y otros colaboradores de código abierto para crear públicamente un paquete acumulativo compatible con código de bytes. .zkEVM. A fines de febrero, Scroll anunció que su red de prueba Alpha ahora está activa en Goerli. Cualquier usuario puede participar en las pruebas técnicas sin permiso. El tiempo promedio de bloqueo de la red de prueba es de 3 segundos. Ya hay más de 20 millones de transacciones y más de 1,5 millones de bloques y más de 4 millones de direcciones interactivas. Al mismo tiempo, Scroll también abrió la interfaz del ecosistema del sitio web el 11 de abril.
A juzgar por la reciente divulgación de información, Scroll avanza constantemente en el camino de la equivalencia de EVM Tipo 2. Recientemente, Scroll completó el desarrollo compatible de todos los códigos de operación EVM y está en proceso de auditoría. Al mismo tiempo, el próximo objetivo es ser compatible con las transacciones EIP2718.
En términos de arquitectura técnica, la arquitectura de Scroll es relativamente tradicional, por lo que se presentará en detalle aquí. Como se muestra en la Figura 8, se divide principalmente en dos partes: la parte central es zkEVM, que se usa para probar la corrección de la ejecución de EVM en L2; pero para convertir zkEVM en un ZK Rollup completo en Ethereum, se necesita un L2 completo. construirse alrededor de la arquitectura zkEVM. Específicamente, la red de prueba Scroll Alpha existente consta de Scroll Node, Bridge Contract y Rollup Contract:
Figura 8 Arquitectura general del resumen de desplazamiento | Fuente
a) Sequencer, el llamado secuenciador, abre JSON-RPC a usuarios y aplicaciones, lee transacciones en el grupo de transacciones y genera bloques L2 y raíces de estado. En esta etapa, los nodos Sequencer de Scroll están centralizados y se descentralizarán gradualmente en futuras actualizaciones.
b) El Coordinador es responsable de la comunicación entre el Roller y el Scroll Node.Cuando se genera un nuevo bloque en el Secuenciador, el Roller en el pool se selecciona aleatoriamente para la generación de prueba.
c) El Retransmisor monitorea el Contrato Puente y el Contrato Rollup en las cadenas Ethereum y Scroll. El contrato de resumen garantiza la disponibilidad de datos de los datos L2 en el nivel L1 y garantiza que el bloque L2 se pueda restaurar en la capa L1. Una vez que el bloque enviado por la capa L2 es verificado por el contrato de resumen en la capa L1, el bloque alcanzará la finalidad en la capa L2 El estado inmutable de . El contrato puente es responsable de la comunicación entre los contratos de doble cadena al cruzar cadenas, enviar mensajes arbitrarios en ambas direcciones o completar las operaciones de compromiso y retiro de activos al cruzar cadenas.
Figura 9 2. Red de rodillos | Fuente
a) Roller primero convierte el rastro de acción recibido del Coordinador (es decir, qué operaciones específicas ha realizado el contrato y qué direcciones están involucradas) en testigos de circuito.
b) Genera pruebas para cada circuito zkEVM y finalmente agrega estas pruebas de múltiples circuitos ZK.
StarkWare
StarkWare proporciona una solución de escalado basada en STARK para garantizar la seguridad L2, la velocidad y una experiencia de usuario perfecta. Admiten múltiples modos de disponibilidad de datos. StarkNet es su red L2, mientras que StarkEx es un servicio de verificación de resumen para usuarios empresariales, y las DApps se pueden construir en los servicios de StarkEx. Sin embargo, actualmente solo se pueden escribir circuitos personalizados para DApps específicas, no para el paquete general de zkEVM. StarkEx admite una serie de servicios plug-and-play, que incluyen acuñación y comercio de NFT, comercio de derivados, etc. En términos de ecología, la plataforma descentralizada de comercio de contratos de futuros DYDX es un usuario leal de StarkWare.
StarkNet, estrictamente hablando, es zkVM En lugar de hacer circuitos ZK para los códigos de operación de Ethereum, ha creado un conjunto de lenguaje ensamblador más compatible con ZK, AIR (Representación intermedia algebraica) y lenguaje de alto nivel Cairo. Aunque StarkNet en sí mismo no es compatible con EVM, aún puede ser compatible con Ethereum a través de otros métodos, incluido Kakarot (Kakarot es un zkEVM escrito en El Cairo, que es un zkEVM cuyo código de bytes es equivalente a EVM). Según tengo entendido, StarkNet es un proyecto relativamente centralizado, uno de los cuales es que no se puede sincronizar con la actualización de seguridad de Ethereum, por lo que es necesario concentrar el personal de I+D para compensar las deficiencias en seguridad y seguir el desarrollo y adaptación de ETH nuevo acuerdo.
StarkNet usa STARK como su sistema de prueba Comparado con SNARK, STARK tiene más innovaciones. No necesita depender de "configuraciones confiables" como SNARK. Además, también tiene suposiciones criptográficas más simples, evita la necesidad de suposiciones de curva elíptica, emparejamiento y conocimiento exponencial, y se basa únicamente en la teoría de información y hashing, por lo que es más resistente a los ataques cuánticos. En general, los STARK son más seguros que los SNARK. En términos de capacidades de expansión, STARK tiene un efecto marginal significativo, y cuanto mayor sea la prueba, menor será el costo total.
Sin embargo, en términos de arquitectura, actualmente solo hay un Sequencer (secuenciador) en el sistema, que está controlado por StarkWare, y solo hay un Prover (es decir, el probador que genera ZK Proof), que no solo genera pruebas para StarkNet, pero también se ejecuta por su cuenta. Prueba de generación para todas las demás aplicaciones en el paquete acumulativo de StarkEx.
Variantes de ZK Rollup: Validiums y Volitions
Validium también es una solución de escalado L2 que utiliza pruebas de cálculo como ZK Rollup para reforzar la integridad del proceso de transacción. A diferencia de ZK Rollup, Validium no almacena datos de transacciones en la red principal de Ethereum. Sacrificar la disponibilidad de datos en la cadena es una compensación que puede conducir a grandes mejoras en la escalabilidad, siendo el punto más inmediato que Validiums puede procesar alrededor de 9000 transacciones por segundo.
Pero a los ojos del autor, Validium no puede ser considerado como un estricto ZK Rollup. Esta solución es similar a Plasma y no logra la disponibilidad de datos en la capa L1, por lo que no se puede contar como un Rollup. La diferencia con Plasma es que Plasma ha establecido un "mecanismo de salida de siete días" similar a OP Rollup en la capa L2, mientras que Validium usa y ZK significa acortar el tiempo de verificación de los datos en la capa L2 y no sincroniza el datos a la L1.
Volition, iniciado por StarkWare, permite a los usuarios cambiar fácilmente entre ZK Rollup y Validium. Por ejemplo, algunas aplicaciones, como los intercambios de derivados descentralizados, pueden ser más adecuadas para Validium, mientras que aún desean ser interoperables con aplicaciones en ZK Rollup, entonces Volition proporciona esta capacidad de conmutación.
zkSync
Al igual que StarkNet, zkSync siempre ha insistido en elegir zkVM, que es equivalente a un lenguaje de alto nivel, y ha llamado mucho la atención, con una popularidad y un volumen de bloqueo muy altos. zkSync 1.0 (zkSync Lite) se lanzó en la red principal de Ethereum el 15 de junio de 2020, logrando un rendimiento de transacción de aproximadamente 300 TPS, pero no es compatible con EVM. Y zkSync 2.0 (zkSync Era) se lanzará el 24 de marzo de 2023.
El objetivo de zkSync Era es generar pruebas más rápido mediante el uso de su VM personalizada para la optimización en lugar de perseguir la equivalencia de EVM. Es compatible con Solidity, Vyper, Yul y Zinc (lenguaje de programación interno de rollup) a través de un potente compilador LLVM para implementar la mayoría de las funciones de contrato inteligente. Debido a la VM de desarrollo propio, zkSync Era admite la abstracción de cuentas nativas, de modo que cualquier cuenta puede usar cualquier Token para pagar.
Además, mediante la aplicación del protocolo zkPorter, combinado con ZK Rollups y tecnología de fragmentación, el rendimiento de la red se ha incrementado exponencialmente, alcanzando más de 20 000 TPS (similar al cambio de disponibilidad de datos de Volitions).
En general, zkSync es un proyecto L2 ecológicamente rico que ha atraído la atención de desarrolladores e inversores. Aunque ha habido algunos casos recientes de proyectos completamente fallidos en zkSync, todavía existe la duda de si los desarrolladores pueden obtener una buena experiencia de desarrollo y migración en el lenguaje de alto nivel equivalente a zkVM. Actualmente hay una falta de informes de uso exactos a nivel de desarrollador.Si los desarrolladores tienen una buena experiencia, ¿cuál es el punto de otros tipos de zkVM que se esfuerzan por estar cerca del EVM? Todavía necesitamos más tiempo para observar.
Polígono zkEVM
Polygon lanzó la versión beta de la red principal zkEVM Rollup el 27 de marzo, que también es la máquina virtual equivalente de Ethereum, y abrió todo el código zkEVM. En comparación con zkSync, la cantidad bloqueada de polígonos zkEVM es mucho menor, pero también hay muchos proyectos interesantes y dinámicos en la ecología.
En términos de diseño de resumen, Polygon se diferencia de Scroll en que utiliza un modelo de prueba de eficiencia (PoE) para motivar al secuenciador y al agregador a resolver algunos de los desafíos de la descentralización y los validadores sin permiso. En el modelo clasificador-agregador de dos pasos sin permiso, cualquier clasificador puede enviar una solicitud para empaquetar lotes para obtener la tarifa de empaque, pero debe pagar la tarifa de gas de la capa L1 y depositar una cierta cantidad de Token Al mismo tiempo, los tokens de agregación deben establecer sus propios objetivos para maximizar la ganancia garantizada para cada generación de prueba. Además, los modos Polygon y Volition (ZK Rollup y Validium) también tienen modelos de disponibilidad de datos profundamente compatibles para brindar a los usuarios diferentes niveles de servicios.
Además, Polygon también ha invertido una cantidad considerable de trabajo en el protocolo ZK, y el efecto también es notable.En el documento, resumen sus ventajas técnicas, incluyendo principalmente los siguientes puntos:
Más compatible: Polygon siempre ha insistido en usar zkVM, que es equivalente a EVM, para reducir el costo de los desarrolladores que migran dApps. Al mismo tiempo, aunque Polygon Miden adopta el protocolo ZK-STARK, aún admite la ejecución de contratos de Solidity.
Verificación más sencilla: la razón por la que se suele criticar a ZK Rollup es que la generación de pruebas de validez requiere un costoso hardware especializado que los proveedores ejecutan y transfieren el costo a los usuarios. Polygon ZK Rollup (como Polygon Zero) tiene como objetivo simplificar los esquemas de prueba para que los dispositivos de nivel inferior puedan participar, por ejemplo, las pruebas de generación de prueba Plonky2 en PC de consumo.
Proceso de verificación y generación de pruebas más rápido: Polygon Zero puede generar una prueba de 45 kb en 170 milisegundos.
PARTE 5 Brecha entre la tecnología teórica y los proyectos prácticos
Este informe de investigación llevó a cabo principalmente la divulgación científica de la tecnología ZK y la introducción del mecanismo Rollup, enfatizando la importancia de la disponibilidad de datos, e hizo una cierta distinción sobre el tema de ZK o zkEVM Rollup. Además, sobre la base de distinguir zkVM y zkEVM, también resuelve en detalle las diferencias entre los tres tipos de zkEVM y los diferentes tipos y pistas ZK relacionadas. Finalmente, combinado con varios proyectos ventajosos, revisaron sus respectivos marcos técnicos y la ecología existente.
Sin embargo, en términos de proyectos específicos, los proyectos que eligen lenguajes de alto nivel equivalentes ocupan la posición principal en el mercado, y algunos productos con una centralización seria como StarkWare también pueden ganar el favor del mercado. Aunque el primer tipo de VM mencionado en la investigación teórica tiene fuertes limitaciones, bajo los clientes de mercado limitados, la "universalidad" parece ser una carga, y no podemos distinguir qué problemas ha superado la "expansión eficiente" y se ha dado cuenta del efecto más allá de la teoría. . Por supuesto, de hecho, muchas personas no prestan atención a las características técnicas, por lo que esto no parece muy Web3, pero sí muy Web3.
El propósito de la tecnología Rollup es aprovechar aún más el valor de la cadena de bloques, pero a menudo, debido a la necesidad urgente de convertirse en un "concepto innovador" en el mercado, existe un fenómeno de "retroceso" y regreso a la centralización. Este es el problema del mercado actual.
El valor de la cadena de bloques es fácil de ver, ¿quién no querría tener una computadora eterna? Pero el problema central es que cuando la capacidad de funcionamiento de esta computadora es mucho menor que la de cualquier servidor que nos rodea y requiere una gran inversión de recursos, incluso si el valor de uso es mucho menor que nuestro costo de entrada, como un "producto público". , todavía es ¿Pueden todos participar?
Cuando ya tenemos productos de muchos países, sociedades e incluso individuos, ¿bajo qué circunstancias estamos dispuestos a ignorar el alto costo de uso y perseguir el resultado de "siempre en línea, siempre correcto"? Creo que esto es algo en lo que la industria blockchain debe pensar hoy. La tecnología de acumulación técnicamente puede mejorar este problema, pero todavía hay una gran cantidad de problemas que deben dejarse en manos del impetuoso mercado para que los resuelva.