Prefacio
Hasta ahora, la mayoría de los protocolos que hemos experimentado en Web3 tienen un cierto grado de confianza. Cuando esperamos lograr una mayor "descentralización", inevitablemente tenemos que sacrificar algo de privacidad. Por ejemplo, cuando un protocolo proporciona protección MEV, lo más probable es que utilice Private Mempool. Los usuarios deben asumir que esta parte de los proveedores del nodo funcionará de manera honesta, es decir, existe una suposición de confianza en terceros. es cierto para todos los protocolos: se asume un cierto nivel de confianza. Según nuestra observación en un informe de investigación anterior, para las instituciones y los grandes inversores, la protección de la privacidad es uno de los factores importantes a la hora de considerar la posibilidad de migrar activos a la cadena. Esto también significa que algunas plataformas de datos en cadena de terceros pueden intensificar los ataques dirigidos por parte de MEV-Searcher y piratas informáticos a grandes hogares e instituciones, por lo que la introducción de la protección de la privacidad en cadena sin duda satisfará naturalmente sus necesidades.
Antes de esto, también escribimos un informe de investigación sobre Singularity, un proyecto sobre la pista de privacidad dirigido a transacciones de grupos oscuros (Lectura ampliada: Explicación detallada de Singularity: Transacciones privadas en cadenas de bloques transparentes).
Entonces la pregunta es: ¿Qué podemos hacer para proteger la privacidad?
Las cuatro soluciones informáticas de privacidad más escuchadas son: cifrado totalmente homomórfico (FHE), computación multipartita (MPC), entorno de ejecución confiable (TEE) y prueba de conocimiento cero (ZKP, prueba de conocimiento cero). Lo que en realidad están resolviendo son las necesidades del escenario en diferentes situaciones.
En primer lugar, para los datos cifrados, la propiedad de los datos está determinada por quién posee la clave de descifrado/cifrado. En términos generales, los datos privados se pueden dividir en visibilidad personal y visibilidad grupal.
Datos personalmente visibles (Estado privado personal): Los datos solo pueden ser vistos y modificados por un sujeto, como el saldo personal.
Datos visibles del grupo (estado privado compartido): los datos se pueden utilizar para cálculos por parte de múltiples entidades garantizando al mismo tiempo la privacidad, como el saldo en un fondo común de liquidez.
Para FHE, MPC y TEE, todos pueden resolver el problema de los datos visibles del grupo. Sin embargo, FHE requiere recursos informáticos costosos, MPC requiere que todos los validadores estén en línea y TEE debe confiar en el proveedor de servicios. La exploración actual de estas soluciones por parte de la industria solo es adecuada para algunos escenarios, como transacciones de grupos oscuros, gestión de claves privadas, etc. Aunque la información de resultados generada por ZKP es limitada (es decir, preguntas "verdaderas o falsas") y en su mayoría solo se aplica a datos personales visibles, los usuarios actuales exploran completamente sus escenarios de aplicación, como puentes entre cadenas, Capa 2, KYC. , etc. Incluso en el futuro, si FHE y MPC, o incluso otras soluciones informáticas de privacidad, se vuelven populares, ZKP no será abandonado debido al efecto de canibalización/competencia de mercado, porque:
ZKP + FHE: por ejemplo, la cadena ZKVM que usa el modelo UTXO. Si desea verificar cada transacción, el verificador debe descargar todo el árbol Merkle y decodificarlo uno por uno antes de verificar, por lo que se introduce FHE para calcular sin decodificar. produce el mismo resultado.
ZKP + MPC: por ejemplo, un grupo oscuro que utiliza MPC + ZKP permite a los usuarios garantizar aún más la atomicidad de las transacciones al tiempo que garantiza su propia privacidad.
ZKP + TEE: por ejemplo, para ZK-SNARK, la generación de una cadena de referencia común puede realizarla el nodo que ejecuta TEE para garantizar que la información intermedia no se filtre.
Podemos prever que una amplia gama de escenarios de aplicación ZKP explotarán. Sin embargo, esta demanda aún es difícil de satisfacer según la capa 1 principal actual. No solo tiene que enfrentar altas tarifas de gas, sino que también debe esperar la verificación de la red. . Modular ZK As A Service (MZaaS), como marco de diseño de un proveedor de servicios ZKP, resuelve bien los problemas anteriores. MZaaS proporciona una serie de servicios relacionados con ZKP para reducir la complejidad de la generación de ZKP y mejorar la eficiencia. Estos servicios se pueden dividir a su vez en las siguientes subcategorías:
Mercado de prueba: basado principalmente en el concepto de separación entre solicitante y probador, divide al probador en diferentes escenarios para utilizar recursos inactivos del probador para proporcionar un mercado de prueba público. Los proyectos a los que se puede hacer referencia incluyen Mina, =nil; y ZKPool.
Capa de verificación: basado principalmente en el concepto de agregación, el probador recopila múltiples pruebas y genera una nueva prueba para demostrar la validez de la prueba inicial y reduce el costo del proceso de verificación al proporcionar una capa de verificación. Los proyectos a los que se puede hacer referencia incluyen Aligned Layer, Horizen, Cloaking Layer (zCloak Network) y Nebra.
¿Cómo debe entenderse ZKP?
Antes de comprender el mercado de ZKP, tengamos un concepto general del ciclo de vida de ZKP. Básicamente, el sistema de prueba ZKP sigue el siguiente proceso:
Prover declara que conoce cierta información y la expresa en un sistema de restricciones basado en este problema.
Generar circuitos según el sistema de restricciones formulado.
Probador Ingrese la respuesta de la solución (Testigo) que coincida con el circuito para calcular la prueba ZK
El validador puede verificar ZKP para identificar si Prover realmente conoce la información.
Supongamos que ahora tenemos un árbol Merkle que se utiliza para registrar los saldos de las cuentas de los usuarios. Normalmente, para actualizar el saldo de la cuenta, debemos seguir el siguiente proceso:
Verificar registros de remitente y receptor en nodos hoja
Verificar la firma del remitente
Actualizar saldos del remitente y del destinatario
Actualizar la raíz Merkle del árbol Merkle
Pero con la bendición de ZKP, este proceso se desarrolla de la siguiente manera:
Construya completamente el proceso de verificación de Merkle Tree en un circuito.
Tomando como entrada el árbol Merkle antes y después de la actualización y el registro de transacción (alguien envió $10 a A), calcule el ZKP.
El verificador verifica ZKP (tomando ZKP, clave de verificación y entrada pública como entrada) y, si el resultado es correcto, entonces la transacción se considera creíble.
En este proceso, el verificador en sí no necesita verificar repetidamente el árbol Merkle y solo necesita creer en los resultados de la verificación (siempre que el circuito esté construido correctamente).
Si ZKP se desmantela aún más desde una perspectiva superior, entonces el proceso desde la definición del problema hasta la construcción del circuito lo realiza el front-end (compilado en un lenguaje de alto nivel), mientras que el back-end (compilado en un lenguaje de bajo nivel). ) es responsable de incrustar/combinar este circuito con un determinado sistema de prueba para generar ZKP, específicamente, el circuito primero se combina con el Protocolo teórico de la información y luego se compila en un sistema ZKP adecuado utilizando un compilador criptográfico, como Groth16.
sexualidad e integridad. La solidez dice que una afirmación es verdadera si se prueba en un sistema de prueba. La integridad garantiza que si una afirmación es verdadera, se puede demostrar en el sistema.
Prueba interactiva (IP): el verificador le hace al probador una serie de preguntas "aleatorias". El probador responde. Esto continúa durante muchas rondas hasta que el verificador está convencido de que la afirmación del probador es correcta.
Pruebas comprobables probabilísticas (PCP): la prueba se convierte a un formato de tamaño fijo llamado "copia de prueba". El verificador puede consultar aleatoriamente una pequeña cantidad de datos en la réplica como prueba de verificación. Para evitar que el probador prediga el valor de la consulta de antemano y prepare una prueba falsificada, se puede introducir un oráculo para generar valores aleatorios para que el verificador los utilice en consultas aleatorias. Desde un punto de vista teórico, este método es más eficaz, pero desde la perspectiva del proceso de verificación, es relativamente ineficiente.
Prueba interactiva de Oracle (IOP): el probador y el verificador interactúan entre sí y tienen acceso a ejemplos aleatorios. IOP mejora la eficiencia de las pruebas interactivas mediante el uso de copias de datos parciales para reducir la complejidad de la comunicación y las consultas. Este es también el sistema de prueba comúnmente utilizado en el sistema ZKP.
Todos los sistemas de prueba de la teoría de la información mencionados anteriormente parten de suposiciones ideales que son difíciles de implementar en la vida real. Por ejemplo, se podría suponer que el verificador es digno de confianza y que el acceso a la certificación está restringido. Pero las características de Cryptograph hacen que estas suposiciones sean factibles en determinadas circunstancias, como en problemas matemáticos comunes:
El problema de la factorización de enteros: por ejemplo, la seguridad de RSA depende de la factorización de números grandes.
El problema del logaritmo discreto: el intercambio de claves Diffie-Hellman se basa en cálculos de logaritmos discretos de números grandes.
El problema del logaritmo discreto de curva elíptica: la criptografía de curva elíptica (ECC) se basa en curvas elípticas en campos finitos y en logaritmos discretos de curvas elípticas complejas.
Después de combinar el sistema de prueba teórica de la información y el compilador criptográfico, se puede obtener el sistema ZKP, por lo que las características de ZKP cambiarán con diferentes combinaciones:
Métodos computacionales: Hay dos modos principales de computación general: circuitos y máquinas de Turing. Aunque la mayoría de los lenguajes de programación convencionales intentan describir la ruta computacional de una máquina de Turing, una máquina de Turing no es el modelo de programación más eficiente para los cálculos criptográficos. Todos los modelos de programación más eficientes suelen aumentar considerablemente la complejidad, lo que complica el cambio de protocolos criptográficos. Por lo tanto, la gente usa circuitos en lugar de máquinas de Turing porque los circuitos pueden expresar muchas declaraciones directas muy fácilmente, pero la desventaja es que el usuario necesita preprocesar los cálculos procesados.
Costo computacional: para diferentes combinaciones, los costos de verificadores, probadores y comunicación serán diferentes. Por ejemplo, en el sistema ZKP combinado con PCP + Función Hash resistente a colisiones (CRFS), el costo de cálculo es el siguiente:
Anticuántico: algunos algoritmos de cifrado pueden resistir eficazmente el descifrado por fuerza bruta de las computadoras cuánticas. Por ejemplo, la función hash resistente a colisiones utilizada por ZK-STARK no puede ser descifrada directamente por las computadoras cuánticas en el desarrollo actual. Sin embargo, todavía existe el riesgo de ser descifrado. Por ejemplo, dos académicos de la Universidad de Shandong describieron cómo descifrar SHA1 y MD5 en un artículo publicado en 2009. Así que todavía necesitamos tener supuestos de confianza.
Configuración confiable: la configuración confiable generalmente se divide en dos categorías: Cadena de referencia uniforme (URS). Los números aleatorios generados por URS son públicamente visibles, lo que significa que la "aleatoriedad" es justa y se divide en dos tipos. Configuración universal y configuración específica, la primera permite que múltiples sujetos participen en la generación de números aleatorios, generalmente en forma de MPC, y la segunda permite participar en la generación de números aleatorios para un escenario específico.
Si en un escenario peer-to-peer, el mal actor conoce el valor aleatorio, entonces puede falsificar la salida del sistema y generar el ZKP correcto.
De lo anterior también se desprende que se pueden ampliar diferentes combinaciones a distintos tipos de sistemas ZKP. En resumen, se puede dividir principalmente en ZK-SNARK, ZK-STARK y Bulletproof. Las siguientes diferencias principales pueden ayudarnos a comprender mejor:
Configuración confiable: los ZK-SNARK generalmente adoptan una configuración confiable, los ZK-STARK y Bulletproof no requieren dicha configuración.
Costos de computación:
Tiempo de prueba: A prueba de balas > ZK-SNARKs > ZK-STARKs
Tiempo de verificación: A prueba de balas > ZK-STARKs > ZK-SNARKs
Complejidad de la comunicación/tamaño de la prueba: ZK-STARKs > Bulletproof > ZK-SNARKs, pero cuando la cantidad de datos aumenta, el espacio de almacenamiento requerido por ZK-STARKs y Bulletproof será menor que el de ZK-SNARKs.
Resistencia cuántica: Los ZK-STARKS son generalmente resistentes a lo cuántico, los ZK-SNARK y Bulletproof no requieren tales propiedades.
Fuente de la imagen: https://github.com/matter-labs/awesome-zero-knowledge-proofs?ref=blog.pantherprotocol.io
Fuente de la imagen: https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa Prueba de conocimiento cero Potencial y escala del mercado
Actualmente, la trayectoria de ZKP se está desarrollando principalmente en dos direcciones principales: privacidad y expansión.
Plan de expansión
Se refiere principalmente a la adopción de ZKP como una solución para mejorar la escalabilidad, incluida la prueba de disponibilidad de Capa 2, cadena cruzada, etc. Las soluciones comunes actualmente incluyen Starknet, ZKsync, Polyhedra, etc. Generalmente se puede dividir en dos sistemas constructivos: Capa1/Capa2 y protocolo. En el sistema de construcción Layer1/Layer2, las transacciones y aplicaciones acumuladas se ejecutan en ZKEVM y tienen características de prueba de conocimiento cero. Un ZKEVM ideal debería ser equivalente a EVM, lo que significa que puede ser totalmente compatible con los protocolos existentes y la experiencia de desarrollo de EVM. Según el blog de Vitalik, el ZKEVM actual se puede dividir en 5 categorías:
Tipo 1: Totalmente idéntico a Ethereum, no se realizarán cambios en su estado ni en su árbol de transacciones, código hash ni ninguna otra lógica en su consenso. Type-1 será totalmente compatible con todas las aplicaciones nativas de Ethereum, pero requerirá tiempos de prueba más largos ya que no se realiza ninguna compilación previa para acelerar la generación de pruebas. Los proyectos actualmente disponibles como referencia incluyen Scroll y Taiko.
Tipo 2: similar a Ethereum en apariencia, pero con ligeros cambios internos, como árbol de estado, estructura de bloques, etc., para facilitar el desarrollo y acelerar la generación de pruebas. Los proyectos actuales disponibles como referencia incluyen Polygon Hermez.
Tipo 2.5: Limite algunas funciones de ZK aumentando la tarifa de gas para reducir el posible tiempo de verificación, que esencialmente trata los síntomas pero no la causa raíz.
Tipo 3: es posible que se eliminen algunas funciones que son particularmente difíciles de implementar en la implementación de ZK-EVM. Además, a veces existen diferencias sutiles en cómo se maneja el código de contrato, la memoria o las pilas, por lo que la compatibilidad con Ethereum será más débil. Esta categoría se parece más a un período de transición del desarrollo de un producto que a un posicionamiento del producto.
Tipo 4: el código fuente del contrato inteligente escrito en un lenguaje de alto nivel (como Solidity) se compila en un lenguaje diseñado explícitamente para ser compatible con el sistema ZKP, como Cairo. Aunque resulta que el tiempo se puede acelerar. Sin embargo, su compatibilidad es la peor. Por ejemplo, es posible que algunas DApps desarrolladas con el código de bytes de Ethereum no se puedan migrar. Los proyectos actualmente disponibles como referencia incluyen ZKsync y Starknet.
Fuente de la imagen: https://vitalik.eth.limo/general/2022/08/04/zkevm.html
Al comienzo del diseño de Ethereum, no se previó que ZKEVM se utilizaría para la expansión en el futuro, por lo que la dificultad de desarrollo es sin duda muy alta. Por lo tanto, la elección de ZKsync y Starknet también es lanzar un ZKEVM de uso general. en el mercado lo antes posible. De hecho, deberían Se llaman ZKVM porque su compatibilidad con Ethereum (para desarrolladores) es relativamente baja, pero a cambio tienen una mayor flexibilidad arquitectónica y menores costos de generación de ZKP.
Este tipo de ZKVM puede romper con las limitaciones del sistema EVM y convertirse en una Capa 1. Los desarrolladores usan lenguajes de alto nivel para escribir códigos para arquitecturas de máquinas virtuales específicas y luego compilarlos en circuitos ZK, o usar dominios específicos. Idiomas (DSL) (como Circom) para escribir códigos directamente para generar circuitos ZK.
Fuente de la imagen: https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
Si consideramos solo el tamaño del mercado de ZK Layer2, según los datos de L2Beat, el TVL actual de ZK Layer2 (incluidos ZK Rollup y Validium) es de aproximadamente $ 5,015 mil millones, lo que representa el 10% y el 7% del TVL total de Layer2 de Layer2 y Ethereum TVL. respectivamente. Si se utiliza la participación de mercado de OP Rollup como punto de referencia, ZK Rollup actualmente tiene espacio para un crecimiento de aproximadamente 10 veces TVL, y se espera que lance entre 10 y 12 nuevas líneas ZK Layer 2 adicionales.
Entre ellos, Linea, Starknet y ZKsync son los tres primeros, representando $1,22 mil millones, $1,06 mil millones y $855 millones respectivamente. La tasa de concentración de tres empresas es del 62%, lo que significa que la actual competencia de Capa 2 está monopolizada por unos pocos proyectos. . Observando más a fondo el crecimiento de Layer2 TVL, el crecimiento de TVL se produjo principalmente el 20 de febrero de 2024. La razón es la entrada y apreciación de los tokens nativos de Starknet. Actualmente, el 75% de los tokens nativos de Starknet todavía se conservan en la cadena.
Entre ellos, Linea pertenece al ZKEVM tipo 2, y Starknet y ZKsync pertenecen al ZKEVM tipo 4. Y los tres primeros son todos ZK Rollup en lugar de Validium. El primero usa Ethereum como DA, y el DA del segundo se colocará fuera de la cadena y será administrado por DAC. En Validium, Immutable X ocupa el primer lugar con un TVL de casi 200 millones de dólares. También vale la pena señalar que en OP Rollup, la mayoría de las 10 capas 2 principales con el TVL más alto usan pila OP, lo que significa que una determinada pila tiene una alta participación de mercado. Pero en ZK Rollup, los 10 Layer2 principales con el TVL más alto básicamente eligen desarrollar su propio ZK Stack.
Fuente de la imagen: https://l2beat.com/scaling/summary
Fuente de la imagen: https://l2beat.com/scaling/summary
Además de la Capa1/Capa2 mencionada anteriormente, los principales escenarios para la expansión de ZKP incluyen la capa de protocolo, como la cadena cruzada. La introducción de ZKP en la cadena cruzada sirve principalmente a la infraestructura de cadena cruzada de verificación de nodos ligeros y Maker & Sender, como Polyhedra, Orbiter Finance, etc. Durante el proceso de verificación original del nodo ligero, el contrato implementado en la cadena de destino debe obtener continuamente el encabezado del bloque de la cadena de origen para la posterior verificación de la información entre cadenas, lo que inevitablemente consumirá gas. Sin embargo, si se realiza el proceso de verificación. Fuera de la cadena, si solo se almacena un Compromiso en la cadena, el costo de almacenamiento se reducirá considerablemente y cuanto mayor sea la frecuencia de actualización de la cadena de origen, mayor será el costo del Gas. La forma en que se construye el Compromiso se puede llevar a cabo utilizando ZKP, que puede comprimir efectivamente una o más transacciones. En el modo Maker&Sender, ZKP se combina con pruebas de fraude para reducir aún más la generación de ZKP. En términos de tamaño del mercado, tomando como ejemplo Orbiter Finance, aunque actualmente tiene un volumen de transacciones mensuales de aproximadamente $628 millones y un TVL de $1,48 millones, la demanda de ZKP también aumentará en el caso de una alta rotación.
plan de privacidad
Se refiere principalmente a protocolos/redes que utilizan ZKP como solución de seguridad de privacidad, incluidos Zcash, Aztec y Tornado Cash.
Las soluciones centradas en la privacidad requieren menos esfuerzo de desarrollo que las direcciones de desarrollo centradas en la escala. Las aplicaciones de privacidad existentes se centran principalmente en la privacidad de los pagos y no son altamente programables. Combinar privacidad y programabilidad es una tarea desafiante. Las soluciones centradas en la privacidad se pueden crear de dos maneras:
Protocolos: estos protocolos utilizan principalmente ZKP para crear grupos de fondos privados. Los usuarios utilizan estos fondos privados como soluciones de protección de la privacidad, como Tornado Cash. Para estas aplicaciones, la prueba la realiza el usuario y la verificación se produce en cadena. Debido a que Layer1 no está diseñada para cálculos criptográficos, los costos de verificación suelen ser altos para los usuarios principales, lo que limita la adopción de estas aplicaciones. La solución intuitiva es trasladar las aplicaciones de transacciones privadas a Rollup para reducir las tarifas del gas. En este caso, la prueba de la transacción privada debe incluirse en la prueba acumulativa, es decir, la prueba recursiva, lo que actualmente no es posible con el ZK Rollup normal en Ethereum.
Capa1/Capa2: Estas Capas1/Capa2 implementan principalmente protección de privacidad a través de ZKP, como Manta Network y Aztec. La mayoría de las cadenas centradas en la privacidad aún no pueden admitir la informática de propósito general y solo pueden centrarse en casos de uso específicos. Penumbra y Renegade, por ejemplo, se centran en transacciones privadas. Los modelos de cuenta utilizados por estas Capa1/Capa2 se pueden dividir en: Basado en cuentas y Basado en UTXO. Ambos tienen sus propias deficiencias: el primero puede perder algo de privacidad debido a la ruta de la transacción y requiere procesamiento en serie, mientras que el segundo requiere el descifrado de cada subnodo antes de que se pueda consultar correctamente al verificar y actualizar el saldo de la transacción.
Según Defilama, el TVL actual de la pista de privacidad es de aproximadamente $ 709 millones, y la tasa de concentración de tres empresas representa casi el 99%, a saber, Tornado Cash ($ 595 millones), Railgun ($ 96,97 millones) y Aztec ($ 9,45 millones). Entre ellos, Tornado Cash y Railgun son protocolos, y Aztec pertenece a la Capa 2.
Fuente de la imagen: https://defillama.com/protocols/Privacy
Entre ellos, Tornado Cash se enfrenta a la supresión del cumplimiento, lo que también significa que muchos requisitos de "privacidad de cumplimiento" migrarán gradualmente a otros protocolos y redes, y la tasa de concentración solo disminuirá gradualmente. Además, muchas plataformas de datos de terceros y proveedores de nodos centralizados en el mercado actualmente socavan la resistencia a la censura, y algunos grandes inversores e instituciones esperan transferir grandes cantidades de fondos de una manera más segura y privada. Al 3 de junio, aproximadamente el 37% de los bloques estaban sujetos a revisión de la OFAC, algo que el público Mempool no puede evitar.
Fuente de la imagen: https://www.mevwatch.info
Esto también amplía aún más los requisitos de cumplimiento, por lo que los proveedores de servicios como KYC también son muy importantes. Sin embargo, los usuarios a menudo todavía quieren mantener la privacidad personal al máximo. Los escenarios potenciales de ZKP + KYC aumentarán con la mejora de las transacciones de privacidad. Los principales proveedores de servicios en el mercado actual son zCloak, zkMe, etc. En el proceso tradicional de KYC, cuando necesitamos confiar a varios proveedores de servicios de KYC, debemos realizar verificaciones repetidas, pero en el caso de ZKP + KYC, otros proveedores de servicios pueden intentar verificar el ZKP para garantizar la validez de la identidad. Además, durante el proceso KYC, los proveedores de servicios deben registrar cierta información necesaria, como información confidencial como tarjetas de identificación. Si se realiza en varios proveedores de servicios, el riesgo de fuga de información también aumentará linealmente.
¿A qué problemas se enfrenta ahora ZKP?
Como mencionamos antes, la generación de ZKP requiere importantes recursos informáticos. Tomando como ejemplo el ZK-Rollup común, el tiempo de generación de ZKP de ZKsync es de aproximadamente 1 hora. Si se desmantela aún más, el proceso de generación de ZKP de ZK-SNAKS implica principalmente la multiplicación multiescalar (MSM) y la transformada teórica de números (NTT). Estos dos procesos pueden representar del 80% al 95% del tiempo de generación de pruebas. Aunque ZK-STARK utiliza algoritmos diferentes, también enfrenta el problema de la baja eficiencia.
Además, en los últimos años, los sistemas ZKP han proporcionado una gama amplia y en constante expansión de opciones con diferentes compensaciones. Por ejemplo, la contrapartida de una mayor velocidad de prueba es un mayor tamaño de prueba o un mayor uso de memoria. La variedad de sistemas de prueba con diversas capacidades de personalización es amplia y está en constante expansión. Pero Ethereum no puede soportar el sistema de prueba en evolución. Por ejemplo, sólo se pueden admitir curvas elípticas BN-254 a bajo costo. Pero migrar a una curva más segura (como la BLS12-381) es una tarea muy complicada, y mucho menos ser compatible con el nuevo sistema ZKP.
Además, en términos de verificación ZKP de Capa 1, el costo de verificar STARK es de aproximadamente 5.000.000 de Gas, mientras que la prueba basada en Plonk es de menos de 290.000 Gas. Si el sistema de prueba se verifica directamente en Ethereum, actualmente existen varias limitaciones, por ejemplo, los sistemas de prueba basados en argumentos internos del producto, como el Kimchi de Mina (que implementa una recursividad eficiente a través de Pickles) o Binius basado en Brakedown (pruebas con tamaño de raíz cuadrada). , la cantidad de cálculo o el tamaño de la prueba involucrada es relativamente grande, por lo que el costo de verificación será muy elevado. Para esto, es posible que necesitemos convertir a ZKP compatible con Ethereum.
Cómo los servicios modulares ZK aceleran el proceso ZKP
Por lo tanto, cómo mejorar la eficiencia se ha convertido en la dirección a discutir en el próximo desarrollo de ZKP. Además de los cambios en los algoritmos/circuitos, las principales soluciones actuales se pueden dividir en dos categorías:
Aceleración de Hardware: Mejorar el proceso de generación de ZKP mejorando el hardware. La GPU generalmente tiene una mejora limitada en el tiempo de verificación ZKP. Otra opción es usar hardware dedicado, como FPGA o ASIC, y luego extender la capa de abstracción de hardware, que puede derivarse al servicio en la nube de IA. Dado que el objetivo de este artículo no es discutir la aceleración de hardware, no la discutiremos en detalle.
Modular ZK-As-A-Service (MZaaS): Reduce la complejidad de la generación de ZKP y mejora la eficiencia al proporcionar una serie de servicios relacionados con ZKP. Estos servicios se pueden dividir a su vez en las siguientes subcategorías:
Mercado de prueba: basado principalmente en el concepto de separación entre solicitante y probador, divide al probador en diferentes escenarios para utilizar recursos inactivos del probador para proporcionar un mercado de prueba público. Los proyectos a los que se puede hacer referencia incluyen Mina, =nil y ZKPool.
Capa de verificación: basado principalmente en el concepto de agregación, el probador recopila múltiples pruebas y genera una nueva prueba para demostrar la validez de la prueba inicial y reduce el costo del proceso de verificación al proporcionar una capa de verificación. Los proyectos a los que se puede hacer referencia incluyen Aligned Layer, Horizen, Cloaking Layer (zCloak Network) y Nebra.
Mercado de pruebas
En primer lugar, podemos encontrar en los escenarios de aplicación anteriores que no todas las transacciones se generarán en los escenarios de aplicación ZKP, por lo que podemos clasificarlas en dos métodos de generación (tomando la cadena cruzada como ejemplo):
ZK completo: ZKP se genera para cada transacción. Por ejemplo, para cada transacción en ZK Bridge, Maker generará ZKP para su verificación.
Half ZK: ZKP solo se generará cuando se cumplan ciertas condiciones. Por ejemplo, Orbiter Finance solo necesita generar ZKP cuando aparece información de transacción incorrecta o no confiable.
Entonces, en el escenario Half ZK, no todos los Prover se utilizan por completo. Cuando dividimos el rol de Prover en Solicitante y Prover, y creamos una plataforma/mercado compartido de Prover, podemos mejorar la utilización de Prover y potencialmente reducir el tiempo necesario para la generación de ZKP en escenarios ZK completos. Pero la pregunta es ¿cómo elegir un Prover?
En realidad, el diseño específico de cómo seleccionar Prover se puede considerar en múltiples dimensiones: rendimiento, costo y descentralización. Es esencialmente similar al triángulo imposible del mecanismo de consenso. Por ejemplo, se elige la verificación de múltiples nodos para garantizar la descentralización, pero la verificación repetida indudablemente solo aumentará el tiempo de verificación (menor rendimiento). Con base en los diversos modelos económicos de ZKP que Taiko exploró, resumieron el siguiente gráfico. El autor no entrará aquí en demasiados detalles.
Fuente de la imagen: https://www.theblockbeats.info/news/45260 Capa de verificación
Primero, debemos aclarar la diferencia entre agregación y capa de verificación: la primera simplemente comprime ZKP de alguna manera, como la recursión y el plegado; la segunda agrega un proceso de verificación preliminar (finalidad suave) sobre esta base. El proceso de Finalidad Suave puede depender de contratos/redes externos, lo que requiere un cierto grado de asunción de confianza.
En el proceso de agregación real, la arquitectura adoptada por diferentes proyectos es ligeramente diferente, pero generalmente existen los siguientes cuatro enlaces (tomando ZKTree utilizado por Polymer como ejemplo):
Composición ZKP: combine cualquier circuito en un nuevo ZKP, posiblemente con la ayuda de recursión y plegado.
Uniformación ZKP: unifique el proceso anterior en una nueva ZKP.
Recursión de ZKP: recurra nuevamente al lote de nodos secundarios recién generado (ZKP unificado) y utilice este lote de ZKP como prueba de verificación para lograr una validez/finalidad suave.
Transformación ZKP: si necesitan servir a una VM específica, pueden tener su propia adaptabilidad a diferentes sistemas ZKP y se asignarán aún más a ZKP de diferentes sistemas según la situación para reducir los costos de verificación.
La capa de verificación puede proporcionar verificación instantánea a través de Soft Finality e integrarse con varios sistemas (no limitado a Ethereum). Cuando se persiguen requisitos de seguridad relativamente bajos, Soft Finality se puede utilizar para lograr una mayor eficiencia. Y a través de la Capa de Verificación, también se puede hacer posible la computación paralela, eliminando aún más la deuda técnica de Ethereum. Más importante aún, puede reducir los costos de verificación. Según las pruebas reales de Nebra, cada prueba enviada en la cadena Ethereum puede ahorrar hasta 184.000 gases (aproximadamente el 75%), y cada prueba enviada fuera de la cadena puede ahorrar hasta 207.000 gases (aproximadamente el 85%). Además, Aligned Layer también estima que el costo de la verificación en Groth16 y STARK será 29 y 80 veces menor que la verificación original en Ethereum, y utilizará hardware de nivel doméstico.
Capa de encubrimiento Cómo implementar la capa de verificación
Introducción
Cloaking Layer es un nuevo producto de zCloak Network, que se centra en proporcionar servicios de capa de verificación para ZKP. La idea central es aprovechar la eficiencia ultra alta y el costo ultra bajo de Internet Computer (ICP) y utilizar el contrato Canister basado en WebAssembly (WASM) para verificar directamente cada ZKP. Luego, basándose en el mismo supuesto de confianza, se utiliza la tecnología de firma de umbral para enviar los resultados de la verificación a cualquier cadena pública objetivo para lograr servicios de verificación ZKP que cubran toda la cadena. (Lectura ampliada: Capa de encubrimiento: una infraestructura de verificación ZK para todas las cadenas)
Arquitectura principal
Fuente de la imagen: https://zcloaknetwork.medium.com/cloaking-layer-a-zk-verification-infra-for-all-chains-1162d3fcc37b
En primer lugar, el núcleo de Cloaking Layer es ICP Canister, que puede ejecutar directamente el verificador de ZKP (Verifier) en forma WASM para verificar directamente las pruebas "SNARK" y "STARK". ICP Canister puede entenderse como un contrato inteligente en la cadena EVM. No se puede alterar después de la implementación y los resultados de la operación requieren el consenso de toda la red. A diferencia de los contratos EVM, que deben escribirse en lenguaje Solidity, los contratos Canister pueden admitir objetos compilados WASM. Dado que la gran mayoría de los sistemas ZKVM actuales, como Polygon Miden, RISC0, SP1, Jolt, etc., están escritos en el lenguaje de programación Rust y se pueden compilar fácilmente en WASM, Canister es muy adecuado para servir como validador de ZKP.
La cadena pública ICP consta de varias subredes (Subredes) y cada subred contiene una gran cantidad de nodos (Réplica). Después de implementar un contrato de Canister, se guardará una copia en cada nodo de la subred y se ejecutará de forma independiente en cada nodo. Luego, la subred comparará los resultados de ejecución de todos los nodos y obtendrá un consenso para garantizar que los resultados de ejecución de Canister sean correctos. Cuando la capa de encubrimiento recibe el ZKP, el recipiente validador implementado en cada nodo calculará y verificará el ZKP de forma independiente. Una vez que el resultado de la certificación alcanza un consenso dentro de la subred, la subred firma digitalmente el resultado de la verificación utilizando la tecnología de firma Threshold ECDSA. Los resultados de la verificación firmada se pueden enviar a cualquier cadena pública que admita la verificación de firma ECDSA, como Bitcoin, Ethereum y Solana para su uso.
análisis de la competencia
Puntos clave:
Actualmente existe una gran brecha entre las valoraciones de las soluciones en el mercado.
Actualmente, la mayoría de las soluciones ya están en Testnet.
Se estima que el costo promedio de verificación se reducirá más de 10 veces, siendo Cloaking Layer el que tendrá el mayor rendimiento.
La mayoría de los supuestos de confianza se basan en la capa 1.
La mayoría de los proyectos sólo realizan una "expansión de verificación" para Ethereum
evaluar
La mayor diferencia entre Cloaking Layer y otras soluciones actuales de Verification Layer radica en su suposición de confianza. Actualmente, postularse para convertirse en una réplica (nodo ICP) es extremadamente exigente. Requiere la aprobación de la Fundación ICP y requisitos de configuración de hardware de nodo más altos (más altos que la Capa 1 con configuraciones de nodos más pesadas como Solana y Sui). cierto límite de confianza en la eficiencia del umbral de firma ECDSA, que esencialmente todavía depende de 2/3 de los nodos honestos de la red. Además, debido a las ventajas de rendimiento de los nodos ICP, Cloaking Layer no necesita recurrir a complicados esquemas de recursividad ZKP para lograr la compresión ZKP. Este método también es el más directo y conveniente.
discusión extendida
¿Cómo puedo crear resistencia a la censura en la capa de verificación?
La forma más sencilla y eficaz es utilizar el mecanismo anticensura de Layer1. Siempre que el Verificador/Prover unificado en la Capa de verificación no pueda interceptar la transacción enviada, se puede heredar la capacidad anticensura de Layer1. El entendimiento real es que el usuario/protocolo puede enviar ZKP directamente al contrato inteligente de la capa de verificación en la capa 1 (recipiente en ICP) y almacenarlo en una cola de espera a la espera de ser empaquetado por el verificador/probador unificado. Desde el punto de vista de Arbitrum, cualquiera puede incorporar una transacción al historial de transacciones de la Capa 2 después de un período de tiempo sin un secuenciador correspondiente.
¿Qué es el mercado ZKP-EV?
A través del pensamiento anterior, podemos proporcionar tarifas de manipulación adicionales para priorizar el embalaje. Si la escala es relativamente grande, es posible desarrollar un mercado ZKP-EV (valor extraíble) similar al mercado MEV.
¿Cómo se compensan la finalidad suave y la finalidad dura?
Todas las capas de verificación proporcionarán una finalidad suave y, dado que el rendimiento de estas capas de verificación es mayor que el de Ethereum, la velocidad de verificación también es mejor que la de Ethereum. Pero si necesita pasar por la Finalidad Dura de la Capa 1, entonces el tiempo será más largo que el tiempo sin usar la Capa de Verificación. Esto también es un inconveniente de mantener la Finalidad Dura + ZKP Agregado. Por lo tanto, para los protocolos que requieren más precaución en la finalidad estricta, la capa de verificación actual puede no ser una solución suficientemente buena. Se deben introducir módulos de reducción, sistemas de reputación y mecanismos de seguro para lograr un equilibrio entre eficiencia y seguridad. Puede consultar nuestros artículos anteriores (lectura ampliada: TeleportDAO: The Game of Data Verification Security and Efficiency, las últimas prácticas en diseño de nodos ligeros).
¿Cuáles son las fuentes de ingresos de ZK-As-A-Service?
El modelo de negocio actual de todos los ZaaS todavía es relativamente vago. Además de poder cobrar parte de la comisión en el proceso ZKP, se trata de emitir monedas. Pero el flujo de caja del negocio está esencialmente desacoplado del valor simbólico a menos que esté vinculado mediante un fuerte compromiso de recompra (como el MKR de MakerDAO). Por lo tanto, aunque se espera que el tamaño actual del mercado sea grande, el mercado aún debe verificar el desempeño real de los ingresos.
Referencia
https://medium.com/casperblockchain/verified-merkle-tree-updates- without-zk-90d8f5100ccd
https://www.zkcamp.xyz/blog/teoría-de-la-información
https://x.com/iam_preethi/status/1656411033366396929 https://crypto.stackexchange.com/questions/92018/cuál-es-la-relación-entre-cero-pruebas-de-conocimiento-de-conocimiento-y-circuitos https://web.archive.org/web/20090521024709/http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
https://medium.com/@emilpepil/historia-de-la-formacion-de-zkp-151dd7001ffa
https://www.paradigm.xyz/2022/04/zk-hardware
https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4?ref=blog.pantherprotocol.io
https://x.com/jaosef/status/1730313497513476326
https://l2beat.com/scaling/summary
https://defillama.com/protocols/Privacidad
https://docs.zksync.io/zk-stack/concepts/finality.html#finality-on-zksync-era
https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
https://dune.com/nebra/zkp-verify-spending
https://medium.com/@eternal1997L/Las razones del declive de icp-tecnología única y ecología delgada-51dd7a9362fb
