El cofundador de Scroll, Zhang Ye, habló de cuatro partes. En la primera parte, Zhang Ye presentó los antecedentes del desarrollo y por qué necesitamos zkEVM en primer lugar y por qué se ha vuelto tan popular en los últimos dos años. Se explica cómo, a través de un proceso completo, la construcción de zkEVM desde cero incluye sistemas aritméticos y de prueba. La tercera parte habla sobre los problemas que encontró Scroll al construir zkEVM a través de algunas preguntas de investigación interesantes y, finalmente, presenta algunas otras aplicaciones que utilizan zkEVM.
La cadena de bloques tradicional de Capa 1 tendrá algunos nodos mantenidos juntos a través de la red P2P. Cuando reciben la transacción del usuario, la ejecutarán en la máquina virtual EVM, leerán el contrato de llamada y el almacenamiento y actualizarán el árbol de estado global de acuerdo con la transacción.
La ventaja de dicha arquitectura es la descentralización y la seguridad. La desventaja es que las tarifas de transacción en L1 son costosas y la confirmación de la transacción es lenta.
En la arquitectura ZK-Rollup, la red L2 solo necesita cargar los datos y la prueba para verificar la exactitud de los datos en L1, donde la prueba se calcula a través de un circuito de prueba de conocimiento cero.
En el ZK-Rollup inicial, el circuito se diseñó para aplicaciones específicas. Los usuarios necesitaban enviar transacciones a diferentes probadores, y luego el ZK-Rollup de diferentes aplicaciones enviaba sus propios datos y pruebas a L1. El problema que esto trae es que se pierde la componibilidad del contrato L1 original.
Lo que hace Scroll es una solución zkEVM nativa, que es un ZK-Rollup de uso general. Esto no sólo es más fácil de usar, sino que también proporciona a los desarrolladores una mejor experiencia de desarrollo en L1. Por supuesto, el desarrollo detrás de esto es muy difícil y el costo de la generación de pruebas actual también es muy alto.
Afortunadamente, la eficiencia de las pruebas de conocimiento cero ha mejorado significativamente en los últimos dos años, razón por la cual zkEVM se ha vuelto tan popular en los últimos dos años. Hay al menos cuatro razones por las que esto se vuelve factible. La primera es el surgimiento del compromiso polinómico. Bajo el sistema de prueba original de Groth16, la escala de restricciones era muy grande, pero el compromiso polinómico puede soportar restricciones de orden superior y reducir la escala de las mismas. prueba; en segundo lugar, la aparición de tablas de búsqueda y puertas personalizadas puede admitir diseños más flexibles y hacer que las pruebas sean más eficientes; el tercero son los avances en la aceleración de hardware, que pueden acortar el tiempo de prueba en 1-2 órdenes de magnitud a través de GPU, FPGA y ASIC; El cuarto En la prueba recursiva, se pueden comprimir varias pruebas en una sola, lo que hace que la prueba sea más pequeña y más fácil de verificar. Entonces, combinando estos cuatro factores, la eficiencia de generación de pruebas de conocimiento cero es tres órdenes de magnitud mayor que hace dos años, que también es el origen de Scoll.
Según la definición de Justin Drake, zkEVM se puede dividir en tres categorías. La primera categoría es la compatibilidad a nivel de idioma. La razón principal es que EVM no está diseñado para ZK y tiene muchos códigos de operación que no son compatibles con ZK, por lo que provocará un error. muchos gastos generales adicionales. Por lo tanto, empresas como Starkware y zkSync optan por compilar Solidity o Yul en compiladores compatibles con ZK a nivel de lenguaje.
El segundo tipo es la compatibilidad a nivel de código de bytes que realiza Scroll, que prueba directamente si el procesamiento del código de bytes de EVM es correcto o no, y hereda directamente el entorno de ejecución de Ethereum. Algunas compensaciones que se pueden hacer aquí son usar una raíz de estado diferente a la de EVM, como usar una estructura de datos compatible con ZK. Hermez y Consensys están haciendo algo parecido.
La tercera categoría es la compatibilidad a nivel de consenso. La desventaja aquí es que no solo es necesario mantener el EVM sin cambios, sino también incluir la estructura de almacenamiento para lograr una compatibilidad total con Ethereum, a costa de un tiempo de prueba más prolongado. Scroll se está construyendo en cooperación con el equipo PSE de la Fundación Ethereum para realizar la ZKización de Ethereum.
En la segunda parte, Zhang Ye les mostró a todos cómo construir ZKVM desde cero.
Proceso completo
En primer lugar, en la parte frontal de ZKP, debe expresar sus cálculos mediante aritmética matemática. Los más utilizados son R1CS lineal, así como Plonkish y AIR. Después de obtener las restricciones mediante aritmética, debe ejecutar el algoritmo de prueba en el backend de ZKP para demostrar la exactitud del cálculo. A continuación se muestran las pruebas de Oracle interactivas polinómicas (Polynomial IOP) y el esquema de compromiso polinómico (PCS) más utilizados.
Aquí debemos demostrar que zkEVM y Scroll usan una combinación de Plonkish, Plonk IOP y KZG.
Para entender por qué utilizamos estas tres soluciones. Primero comenzamos con el R1CS más simple. La restricción en R1CS es que la combinación lineal multiplicada por la combinación lineal es igual a la combinación lineal. Puede agregar cualquier combinación lineal de variables sin gastos adicionales, pero el orden máximo en cada restricción es 2. Por lo tanto, para operaciones de orden superior, se requieren más restricciones.
En Plonkish, debe completar todas las variables en la tabla, incluidas las entradas, las salidas y los testigos de las variables intermedias. Además de esto, puede definir diferentes restricciones. Hay tres tipos de restricciones disponibles en Plonkish.
El primer tipo de restricción es una puerta personalizada. Puede definir relaciones de restricción polinómica entre diferentes celdas, como va3 * vb3 * vc3 - vb4 =0. En comparación con R1CS, el orden puede ser mayor porque puede definir restricciones en cualquier variable y puede definir algunas restricciones muy diferentes.
El segundo tipo de restricción es la permuación o controles de igualdad. Puede usarse para verificar la equivalencia de diferentes celdas y, a menudo, se usa para asociar diferentes puertas en un circuito, como para demostrar que la salida de la puerta anterior es igual a la entrada de la siguiente puerta.
El último tipo de restricción es una tabla de consulta. Podemos entender la tabla de búsqueda como una relación entre variables, que se puede expresar como una tabla. Por ejemplo, queremos demostrar que vc7 está en el rango de 0 a 15. En R1CS, primero debe descomponer este valor en un binario de 4 bits y luego demostrar que cada bit está en el rango de 0 a 1. requerirá cuatro restricciones. En Plonkish, puede enumerar todos los rangos posibles en la misma columna y solo necesita demostrar que vc7 pertenece a esa columna. Esto es muy eficiente para pruebas de rangos. En zkEVM, las tablas de búsqueda son muy útiles para probar lecturas y escrituras de memoria.
En resumen, Plonkish también admite puertas personalizadas, verificaciones de equivalencia y tablas de búsqueda, que pueden ser muy flexibles para satisfacer diferentes necesidades de circuitos. Una comparación simple de STARK. Cada fila en STARK es una restricción. La restricción debe representar la transición de estado entre filas, pero la flexibilidad de las restricciones personalizadas en Plunkish es obviamente mayor.
La pregunta ahora es cómo elegimos el front-end en zkEVM. Hay cuatro desafíos principales para zkEVM. El primer desafío es que el campo de EVM es de 256 bits, lo que significa que las variables deben tener un rango restringido de manera eficiente. El segundo desafío es que EVM tiene muchos códigos de operación no compatibles con ZK, por lo que se necesitan restricciones a gran escala para probar estas operaciones; código, como Keccak-256; el tercer desafío es el problema de lectura y escritura de la memoria, necesita un mapeo efectivo para demostrar que lo que lee es consistente con lo que escribió antes. Está cambiando dinámicamente, por lo que necesitamos puertas personalizadas para adaptarnos a diferentes seguimientos de ejecución. Elegimos Plunkish por las consideraciones anteriores.
A continuación, veamos el proceso completo de zkEVM. Según el árbol de estado global inicial, después de que ingresa una nueva transacción, EVM leerá el código de bytes de los contratos almacenados y llamados y generará los seguimientos de ejecución correspondientes en función de la transacción, como por ejemplo. PUSH, PUSH, STORE, CALLVALUE y luego actualice gradualmente el estado global para obtener el árbol de estado global después de la transacción. zkEVM toma como entrada el árbol de estado global inicial, la transacción en sí y el árbol de estado global después de la transacción, y utiliza la especificación EVM para demostrar la exactitud del seguimiento de ejecución.
Profundizando en los detalles del circuito EVM, cada paso del seguimiento de ejecución tiene sus correspondientes restricciones de circuito. Específicamente, las restricciones del circuito de cada paso incluyen el contexto del paso, el cambio de caso y el testigo específico del código de operación. El contexto del paso contiene el código hash, el gas restante y el contador correspondiente al seguimiento de ejecución; el cambio de caso contiene todos los códigos de operación, todas las condiciones de error y las operaciones correspondientes del paso. El testigo específico del código de operación contiene testigos adicionales requeridos por el código de operación, como los operandos en espera.
Tomando la suma simple como ejemplo, debe asegurarse de que la variable de control sADD del código de operación de adición esté establecida en 1 y que las variables de control de otros códigos de operación sean todas cero. En el contexto de paso, el gas consumido se limita a ser igual a 3 configurando gas' - gas - 3 = 0. De manera similar, el contador está restringido a 1 después del paso en el cambio de caso; las variables se controlan a 1 a través del código de operación. Para restringir este paso para que sea una operación de suma en Testigo específico del código de operación, restrinja la adición real de operandos.
Además, se requieren restricciones de circuito adicionales para garantizar la exactitud de los operandos que se leen de la memoria. Aquí primero necesitamos crear una tabla de búsqueda para demostrar que el operando pertenece a la memoria. Y verifique la corrección de la tabla de memoria a través del circuito de memoria (Circuito RAM).
El mismo método se puede aplicar a funciones hash no compatibles con zk. Cree una tabla de búsqueda de la función hash, asigne la entrada y salida hash en el seguimiento de ejecución a la tabla de búsqueda y use un circuito hash adicional para verificar la función hash. la exactitud de la tabla de búsqueda.
Ahora veamos la arquitectura del circuito de zkEVM. El circuito EVM central se utiliza para restringir la exactitud de cada paso del seguimiento de ejecución. En algunos lugares donde las restricciones del circuito EVM son difíciles, utilizamos tablas de búsqueda para mapear, incluida la tabla fija y Keccak. Tabla, tabla RAM, código de bytes, transacción, contexto de bloque y luego use circuitos separados para restringir estas tablas de búsqueda, como circuitos Keccak para restringir las tablas Keccak.
En resumen, el flujo de trabajo completo de zkEVM se muestra en la siguiente figura.
sistema de prueba
Debido a que la verificación directa de los circuitos EVM, circuitos de memoria, circuitos de almacenamiento, etc. mencionados anteriormente en L1 es costosa, el sistema de prueba de Scroll adopta una arquitectura de dos capas.
La primera capa es responsable de probar directamente el propio EVM, lo que requiere una gran cantidad de cálculos para generar la prueba. Por lo tanto, se requiere que el sistema de prueba de primer nivel admita puertas personalizadas y tablas de búsqueda, sea compatible con la aceleración de hardware, genere cálculos en paralelo con un pico de memoria bajo y tenga un pequeño circuito de verificación que pueda verificarse rápidamente. Las alternativas prometedoras incluyen Plonky2, Starky y eSTARK. Básicamente, todas usan Plonk en el front-end, pero pueden usar FRI en el back-end y todas cumplen con las cuatro características anteriores. Otro tipo de soluciones alternativas incluyen Halo2 desarrollado por Zcash y la versión KZG de Halo2.
También hay algunos sistemas de prueba nuevos que son prometedores, como HyperPlonk, que recientemente eliminó FFT, y el sistema de prueba NOVA puede lograr pruebas recursivas más pequeñas. Pero solo apoyan a R1CS en la investigación. Si pueden apoyar a Plonkish en el futuro y aplicarlo en la práctica, será muy práctico y eficiente.
El sistema de prueba de segundo nivel se utiliza para demostrar la exactitud de la prueba de primer nivel y debe verificarse de manera eficiente en el EVM. Idealmente, debería ser compatible con la aceleración de hardware y admitir una configuración transparente o universal. Las alternativas prometedoras incluyen Groth16 y el sistema de prueba Plonkish sin columnas. Groth16 sigue siendo un representante de una eficiencia de prueba extremadamente alta en la investigación actual, y el sistema de prueba Plunkish también puede lograr una alta eficiencia de prueba incluso con una pequeña cantidad de columnas.
En Scroll, utilizamos el sistema de prueba Halo2-KZG en nuestros dos sistemas de prueba de dos capas. Debido a que Halo2-KZG puede admitir puertas personalizadas y tablas de búsqueda, funciona bien con la aceleración de hardware de GPU y el circuito de verificación es de tamaño pequeño y se puede verificar rápidamente. La diferencia es que usamos hash Poseidon en el sistema de prueba de primera capa para mejorar aún más la eficiencia de la prueba, mientras que el sistema de prueba de segunda capa todavía usa hash Keccak porque se verifica directamente en Ethereum. Scroll también está explorando la posibilidad de un sistema de prueba de múltiples capas para agregar aún más las pruebas agregadas generadas por el sistema de prueba de segundo nivel.
Según la implementación actual, el circuito EVM del sistema de prueba de primer nivel de Scroll tiene 116 columnas, 2496 puertas personalizadas, 50 tablas de búsqueda, el orden más alto es 9 y requiere 2 ^ 18 líneas bajo 1M Gas, mientras que el sistema de prueba de segundo nivel tiene The; El circuito de agregación tiene solo 23 columnas, 1 puerta personalizada, 7 tablas de búsqueda y el orden más alto es 5. Para agregar el circuito EVM, el circuito de memoria y el circuito de almacenamiento, se necesitan 2 ^ 25 filas.
Scroll también ha investigado y optimizado mucho la aceleración del hardware de la GPU. Para los circuitos EVM, el probador de GPU optimizado solo tarda 30 segundos, que es 9 veces más eficiente que el probador de CPU para los circuitos de agregación, después de la optimización Solo el probador de GPU. tarda 149 segundos, que es 15 veces más eficiente que la CPU. En las condiciones de optimización actuales, el sistema de prueba de primer nivel de 1M Gas tarda aproximadamente 2 minutos y el sistema de prueba de segundo nivel tarda aproximadamente 3 minutos.
En la tercera parte, Zhang Ye habló sobre algunos temas de investigación interesantes en el proceso de construcción de zkEVM de Scroll, desde el circuito aritmético frontal hasta la implementación del probador.
circuito
La primera es la aleatoriedad en el circuito. Debido a que el campo EVM es de 256 bits, necesitamos dividirlo en 32 campos de 8 bits para realizar la prueba de rango de manera más eficiente. Luego usamos el método de combinación lineal aleatoria (RLC) para codificar 32 campos en 1 usando números aleatorios. Solo necesitamos verificar este campo para verificar el campo original de 256 bits. Pero el problema es que el número aleatorio debe generarse después de dividir los campos para garantizar que no sea manipulado. Por lo tanto, Scroll y el equipo de PSE propusieron una solución de prueba de múltiples etapas para garantizar que después de la división del campo, se utilicen números aleatorios para generar RLC. Esta solución está encapsulada en la API Challenge. RLC tiene muchos escenarios de aplicación en zkEVM. No solo puede comprimir el campo EVM en un campo, sino también cifrar la entrada de longitud variable u optimizar el diseño de la tabla de búsqueda. Sin embargo, todavía hay muchos problemas abiertos que deben resolverse.
Una segunda pregunta de investigación interesante en circuitos es el diseño de los circuitos. La razón por la cual el front-end de Scroll usa Plonkish es porque el seguimiento de ejecución de EVM cambia dinámicamente y debe poder admitir diferentes restricciones y pruebas de equivalencia cambiantes, mientras que la puerta estandarizada de R1CS requiere una escala de circuito mayor para implementarse. Sin embargo, Scroll utiliza actualmente más de 2000 puertas personalizadas para cumplir con los seguimientos de ejecución que cambian dinámicamente y también está explorando cómo optimizar aún más el diseño del circuito, incluida la división del código de operación en microcódigo de operación o la reutilización de celdas en la misma tabla.
Una tercera pregunta de investigación interesante en circuitos es el escalamiento dinámico. Debido a que la escala del circuito de diferentes códigos de operación es diferente, pero para cumplir con el seguimiento de ejecución que cambia dinámicamente, el código de operación de cada paso debe cumplir con la escala de circuito máxima, como el hash Keccak, por lo que en realidad pagamos gastos generales adicionales. Suponiendo que podamos hacer que zkEVM se adapte dinámicamente a los seguimientos de ejecución que cambian dinámicamente, esto ahorrará gastos generales innecesarios.
tirador de pruebas
En términos de probadores, Scroll ha realizado muchas optimizaciones para MSM y NTT en términos de aceleración de GPU, pero ahora el cuello de botella se ha desplazado a la generación de testigos y la copia de datos. Debido a que se supone que MSM y NTT ocupan el 80% del tiempo de prueba, incluso si la aceleración de hardware puede mejorar esta eficiencia en varios órdenes de magnitud, el tiempo de prueba original del 20% para generar y copiar datos se convertirá en un nuevo cuello de botella. Otro problema con el probador es que requiere mucha memoria, por lo que es necesario explorar soluciones de hardware más económicas y descentralizadas.
Al mismo tiempo, Scroll también está explorando algoritmos de prueba y aceleración de hardware para mejorar la eficiencia de los probadores. Actualmente hay dos direcciones principales: cambiar a un dominio más pequeño, como usar el dominio Goldilocks de 64 bits, Mersenne Prime de 32 bits, etc., o apegarse a un nuevo sistema de prueba basado en curvas elípticas (EC, por ejemplo, SuperNova). . Por supuesto, hay otros caminos posibles, y los amigos con ideas pueden contactar a Scroll directamente.
seguridad
Al crear zkEVM, la seguridad es primordial. El zkEVM construido conjuntamente por PSE y Scroll tiene aproximadamente 34.000 líneas de código. Desde una perspectiva de ingeniería de software, es imposible que estas bases de código complejas estén libres de vulnerabilidades durante mucho tiempo. Actualmente, Scroll está revisando la base del código zkEVM a través de una gran cantidad de auditorías, incluidas las de las principales firmas de auditoría de la industria.
La parte 4 explora otras aplicaciones que utilizan zkEVM.
En la arquitectura zkRollup, verificamos que n transacciones en L2 sean válidas a través del contrato inteligente en L1.
Si verificamos directamente el bloque L1, entonces el nodo L1 no necesita ejecutar la transacción repetidamente, solo necesita verificar la validez de cada certificado de bloque. Esta solución arquitectónica se llama Enshrine Blockchain. Actualmente, es muy difícil implementarlo directamente en Ethereum porque es necesario verificar todo el bloque de Ethereum, lo que incluirá la verificación de una gran cantidad de firmas, lo que resultará en un tiempo de verificación más largo y una menor seguridad. Por supuesto, ya existen otras cadenas públicas que utilizan pruebas recursivas para verificar toda la cadena de bloques utilizando una única prueba, como Mina.
Debido a que zkEVM puede probar transiciones de estado, los sombreros blancos también pueden usarlo para demostrar que conocen las vulnerabilidades de ciertos contratos inteligentes y buscan recompensas de las partes del proyecto.
El último caso de uso es probar afirmaciones sobre datos históricos mediante pruebas de conocimiento cero y utilizarlos como un oráculo que actualmente fabrica Axiom en esta área. En el reciente Hackathon ETHBeijing, el equipo de GasLockR aprovechó esta característica para demostrar los gastos generales históricos de Gas.
Finalmente, Scroll está construyendo la solución de escalamiento universal de zkRollup para Ethereum, utilizando circuitos aritméticos y sistemas de prueba muy avanzados, y construyendo verificadores rápidos a través de aceleración de hardware para demostrar la recursividad. En la actualidad, la red de prueba Alpha ha estado en línea y ha estado funcionando de manera estable durante mucho tiempo.
Por supuesto, todavía hay algunos problemas interesantes que deben resolverse, incluido el diseño de protocolos y mecanismos, la ingeniería de conocimiento cero y la eficiencia real. ¡Todos pueden unirse a Scroll para construir juntos!
