- Tema
37k Popularidad
4k Popularidad
5k Popularidad
42k Popularidad
17k Popularidad
31k Popularidad
31k Popularidad
3k Popularidad
112k Popularidad
27k Popularidad
- Anclado
37k Popularidad
4k Popularidad
5k Popularidad
42k Popularidad
17k Popularidad
31k Popularidad
31k Popularidad
3k Popularidad
112k Popularidad
27k Popularidad
PSE Trading: ¿Dónde está la salida para las pruebas de conocimiento cero?
Publicación original de @Calvin, analista comercial de PSE
“En general, mi opinión es que en el corto plazo, Optimistic rollup tiene la ventaja en términos de compatibilidad con EVM, mientras que se espera que ZKrollup sea mejor en capas de pago simples, transacciones y otros casos de uso específicos.
Sin embargo, a medio y largo plazo, el rollup ZK ganará en todos los casos de uso con la mejora de la tecnología ZK-SNARK. "
Estas son las palabras originales de God V en su blog "An Incomplete Guide to Rollups".
ZK es el ideal de ETH. La aplicación de pruebas de conocimiento cero (en lo sucesivo, ZK) en el ecosistema Ethereum revela su capacidad para resolver el problema del triángulo imposible de la cadena de bloques (es decir, seguridad, escalabilidad y descentralización) sin centralización. tener que acceder a los detalles completos de la transacción, mejorando la escalabilidad del sistema sin comprometer la seguridad.
La introducción de ZK ha fortalecido aún más la descentralización del sistema ETH (reduciendo el umbral del nodo) y ha asegurado las capacidades de descentralización y anticensura de la red, lo que hace que ETH entre al mar como un dragón y sea difícil de borrar.
Con un ZK tan importante, ¿por qué todos tienen una experiencia tan mala al usarlo y la implementación a gran escala no puede causar ningún revuelo?
1. Problema actual del resumen de prueba de conocimiento cero
Atribuyo la razón por la cual la prueba actual de conocimiento cero todavía se encuentra en el período de cuello de botella a tres aspectos: problemas de compatibilidad, problemas de eficiencia y problemas de estructura de datos.
1.1 El problema principal y más urgente: problemas de compatibilidad
A medida que la EVM (Ethereum Virtual Machine) ha alcanzado un estado similar al de Java en el espacio de la cadena de bloques, se ha convertido en la lengua franca de la nueva Internet del valor. Con numerosas herramientas, servicios, bibliotecas e infraestructura, el uso generalizado de EVM casi se ha convertido en una tendencia inevitable en el entorno tecnológico actual.
Hay un dicho que circula en Internet: "Todo lo que se pueda implementar en Java, al final se implementará en Java".
Otro concepto importante pero confuso es "compatibilidad con EVM" y "equivalente a EVM".
Comprenda la brecha entre los dos desde la "cercanía" y el "método de implementación"——
"Compatible": un sistema puede ejecutar y comprender el código de bytes de EVM de una manera que admita contratos inteligentes escritos en Solidity u otros lenguajes de EVM.
"Equivalente": la equivalencia de EVM es un listón más alto. Un sistema equivalente a EVM no solo es capaz de ejecutar el código de bytes de EVM, sino que también coincide exactamente con el EVM en comportamiento y ruta. Todas las herramientas y bibliotecas dirigidas a Ethereum también deberían funcionar en sistemas equivalentes a EVM sin ninguna modificación.
Ventajas y desventajas del "equivalente a EVM":
Ventaja:
Soporte completo de infraestructura y cadena de herramientas: Ethereum tiene un gran ecosistema de infraestructura y cadena de herramientas, que incluye varias herramientas de desarrollo, marcos de prueba, bibliotecas de códigos y servicios. Si una solución L2 es equivalente a EVM, entonces todas estas herramientas y servicios pueden integrarse perfectamente con ella, porque desde su punto de vista, esta solución L2 es como otra red Ethereum.
Desventajas:
OP escribió un artículo para explorar la compatibilidad de EVM y la equivalencia de EVM Al principio, el OVM utilizado por OP se cambió más tarde a la equivalencia de EVM. Esta es también una razón importante por la que creo que el OP no hizo ARB en el período de crecimiento bárbaro inicial. Existe una brecha entre el equivalente de EVM y ARB en compatibilidad, pero ahora ha cambiado e incluso supera a ARB en compatibilidad. .
Desde esta perspectiva, también podemos comprender la importancia de la compatibilidad con EVM, e incluso se requiere equivalencia para atraer desarrolladores, creando así usuarios y, por lo tanto, creando una ecología.
1.2 El entorno técnico del paquete acumulativo de ZK es en realidad inmaduro
Desde la perspectiva de la verificabilidad de los datos, la verificabilidad de los datos es una característica clave en el sistema blockchain, que garantiza la transparencia y la auditabilidad del sistema.
La estructura de prueba de ZK Rollup es relativamente compleja y requiere que todos los datos estén disponibles en la cadena. Esto garantiza una sólida seguridad e integridad, pero también aumenta la complejidad y el costo del almacenamiento de datos, que es muy diferente del OP.
A medida que crece el tamaño de los datos de zkSync, puede resultar inviable almacenar todos los datos en la cadena principal. Esto puede requerir la introducción de una verificación de datos externa, cambiando así el método de verificación secundaria existente y reduciendo la dependencia de los datos de la red principal.
Estos cambios han planteado nuevos desafíos: ¿cómo garantizar la seguridad del sistema y al mismo tiempo reducir la dependencia de los datos de la cadena principal?
Por lo tanto, la transformación de zkSync a STARK también se debe en parte a esto, porque STARK es más adecuado para usar datos externos verificables que SNARK.
Según la descripción anterior, la implementación del paquete acumulativo de ZK aún necesita depender de ETH para realizar mejoras más compatibles con ZK, como la mejora de la capa DA y EVM.
1.3 Además del resumen de ZK, existen otros problemas, como problemas de eficiencia:
En el campo de blockchain, la velocidad de Sequencer (generalmente medida por el número de transacciones por segundo, TPS) es un indicador clave para evaluar el rendimiento del sistema ZK. El secuenciador es responsable de clasificar y procesar transacciones, y su capacidad de procesamiento determina directamente el rendimiento de toda la cadena.
Sin embargo, en la implementación actual (Zksync), la potencia de procesamiento de un solo secuenciador es solo de unos pocos cientos de transacciones por segundo, una limitación que expone un cuello de botella de rendimiento significativo.
Para expandir TPS, hay dos formas principales a considerar: una es continuar mejorando la capacidad de un solo secuenciador, pero hacerlo puede aumentar el riesgo de centralización del sistema; la otra es introducir más secuenciadores para distribuir el procesamiento. carga, aunque al hacerlo Descentralización mejorada, pero la coordinación de múltiples secuenciadores puede aumentar la latencia y reducir el TPS general. Este número pone de relieve el desafío cuidadosamente sopesado de encontrar el equilibrio adecuado entre mejorar el desempeño y mantener la descentralización.
La dirección de desarrollo de la tecnología ZK, como lo demuestra zkSync, tiende a promover el proceso de secuenciador descentralizado. Esta elección hará que el rendimiento siga siendo un obstáculo importante en el desarrollo de la tecnología ZK. Aunque el uso de múltiples secuenciadores y el diseño modular proporciona una cierta solución, en la práctica pueden surgir problemas complejos de coordinación y sincronización. Esto no sólo podría afectar el tiempo de respuesta y el rendimiento del sistema, sino que también podría introducir nuevos desafíos de seguridad y confiabilidad.
Los problemas de rendimiento siguen siendo un desafío clave que debe resolverse. Es posible que la investigación y el desarrollo futuros deban centrarse en cómo mejorar el rendimiento y la escalabilidad del sistema ZK optimizando algoritmos, estrategias de coordinación y soporte de hardware sin sacrificar el principio de descentralización.
2. La prueba de conocimiento cero es el ideal supremo de ETH
Hemos hablado sobre los problemas actuales de ZK y las dificultades que enfrenta, entonces, ¿cuál es el motivo de la muerte de ZK?
2.1
"El protocolo Ethereum se concibió originalmente como una versión mejorada de las criptomonedas, proporcionando una funcionalidad avanzada a través de un lenguaje de programación de propósito general... El protocolo Ethereum va mucho más allá de la moneda".
El futuro de ETH no se limita a ser una plataforma de transferencia de valor, su ideal final es crear un nuevo mundo digital que sea creíble, escalable y con privacidad garantizada.
La prueba de conocimiento cero es un paso clave para ayudar a ETH a avanzar hacia un objetivo más alto. La prueba de conocimiento cero no es solo el progreso tecnológico de ETH, sino también la encarnación de su cultura y filosofía. Representa una nueva comprensión y búsqueda de la privacidad, la seguridad y la escalabilidad.
2.2
Las estructuras sociales tradicionales dependen de instituciones centralizadas para generar confianza. Las pruebas de conocimiento cero permiten establecer confianza sin conocimiento mutuo. Este modelo de fideicomiso descentralizado tiene el potencial de trastornar las estructuras sociales, financieras y gubernamentales existentes, desencadenando una revolución social.
La estructura actual de Ethereum sacrifica la privacidad por la seguridad y la conveniencia. ETH redefine el concepto de privacidad mediante la introducción de prueba de conocimiento cero. Las personas ya no tienen que elegir entre privacidad y seguridad, sino que pueden disfrutar de ambos derechos al mismo tiempo.
La implementación de ZK permitirá un proceso de verificación liviano para que los nodos ETH verifiquen la validez de las transacciones incluso sin conocer los datos completos. Esto puede reducir los requisitos informáticos y de almacenamiento para el funcionamiento del nodo, lo que reduce el umbral para participar en la red. Según las palabras originales de V God, "Los teléfonos móviles pueden participar en la ejecución de nodos ETH".
Al reducir los requisitos de hardware y mantenimiento para la ejecución de los nodos, los ZKP ayudan a que más participantes se unan a la red. Esto aumenta la naturaleza descentralizada de la red, mejorando así la descentralización.
2.3
La implementación de ZK puede evitar que cualquier autoridad central rastree e interfiera con transacciones específicas al proteger la privacidad de las transacciones. Además, la descentralización garantiza aún más que no haya un único punto de falla, lo que hace que la red sea más difícil de ser atacada o cerrada.
La protección de la privacidad alienta a más personas a participar, ya sean individuos u organizaciones, para que este ecosistema abierto pueda crecer libremente sin las limitaciones de una autoridad central.
Al final, ZK convierte a ETH en una red verdaderamente global a través de la integración de la privacidad y la descentralización, con un potencial y una elasticidad ilimitados, tan indelebles como un dragón que se adentra en el mar.
3. El conocimiento cero demuestra ser un camino razonable para la implementación futura
La necesidad es el destino, el problema es el statu quo, entonces, ¿cuál es el camino?
** Primero hablemos de la conclusión: es hacer la acumulación ZK equivalente de EVM y esperar a que el Ethereum actual actualice el EVM compatible con ZK e ir de la mano para ayudar a la integración perfecta de la tecnología ZK y ETH. **
3.1 Los cuatro tipos de ZKrollup en boca de Dios V
El tipo 1 ZK-EVM pretende ser completamente equivalente a Ethereum sin compromiso. No cambia nada, incluso si dificulta la generación de pruebas.
Ventajas: perfecta compatibilidad.
Desventaja: tiempo de prueba prolongado.
¿Quién lo está desarrollando? : Edición comunitaria ZK-EVM.
El ZK-EVM tipo 2 busca ser completamente equivalente al EVM, pero con cambios en las estructuras de datos externas.
Ventaja: Exactamente equivalente a nivel de máquina virtual.
Desventaja: Tiempo de prueba mejorado pero todavía lento.
¿Quién lo está desarrollando? : Desplazamiento y Polígono Hermez.
El ZK-EVM tipo 3 es casi equivalente a EVM, pero se hacen algunos compromisos para mejorar aún más el tiempo de prueba y la facilidad de desarrollo.
Ventajas: Más fácil de construir, tiempo de prueba más rápido.
Desventaja: más incompatibilidades.
¿Quién lo está desarrollando? : Desplazamiento y Polígono.
Los sistemas de tipo 4 funcionan compilando directamente desde un lenguaje de alto nivel, sin ejecución a través del EVM.
Ventaja: Tiempo de prueba muy rápido.
Desventaja: más incompatibilidades.
¿Quién lo está desarrollando? : ZKSync y el proyecto Warp de Nethermind. (tenga en cuenta que StarkNet ni siquiera es compatible con EVM y está fuera de discusión)
Los diferentes tipos de ZK-EVM presentan un complejo conjunto de compensaciones entre compatibilidad y eficiencia.
El tipo 1 apunta a una compatibilidad completa, pero está sujeto a un largo tiempo de prueba, lo que expone el verdadero desafío de que Ethereum no ha considerado un diseño compatible con ZK.
El Tipo 2 y el Tipo 3 buscan un equilibrio entre compatibilidad total y eficiencia de prueba, mostrando la exploración y el compromiso de soluciones prácticas bajo las condiciones técnicas existentes.
El tipo 4 toma la búsqueda de la eficiencia como objetivo principal, pero a expensas de la compatibilidad, lo que dificulta un poco el desarrollo ecológico.
3.2 Actualización conjunta de EVM y ZK: trabajen juntos para encontrarse al final
El mejor camino para que ETH implemente ZK implica no solo la implementación de la prueba de conocimiento cero equivalente a ZK EVM, sino, más importante aún, la actualización y transformación del propio EVM.
La transformación del EVM compatible con ZK es un proceso complejo pero necesario. El EVM no solo debe ser equivalente al ZK-EVM, sino que también debe tener en cuenta el posible desarrollo futuro de los ASIC ZK-SNARK.
La colaboración entre ZK-EVM y EVM no radica solo en la compatibilidad y eficiencia a nivel técnico, sino también en la integración de herramientas de desarrollo y soporte de precompilación.
Es la visión de muchas personas realizar gradualmente el Tipo 1 a través de la mejora continua de ZK-EVM y Ethereum mismo. El proceso puede ser lento, pero traza un camino claro hacia el futuro.
3.3 Los esfuerzos conjuntos y la colaboración dentro de la ecología son la luz
El desafío de implementar la prueba de conocimiento cero (ZK) en Ethereum no es solo un problema técnico, sino una exploración para encontrar el mejor camino entre el ideal y la realidad. Este proceso revela cómo introducir gradualmente soluciones más rápidas y eficientes manteniendo la compatibilidad con la infraestructura existente.
En este proceso de exploración, la solución ideal es crear una solución ZK que sea completamente equivalente a la EVM existente y luego esperar la actualización compatible con ZK de la propia EVM. La esencia de este proceso es que ambas partes trabajen en conjunto y avancen juntas para encontrarse en algún punto intermedio.
Esta idea de esfuerzos conjuntos no solo se refleja en la implementación técnica, sino también en cómo guiar a toda la comunidad para que se desarrolle en una dirección más segura y escalable sobre la base de conservar el valor único de Ethereum y la ecología existente. Este proceso requiere conocimientos técnicos, planificación estratégica y un profundo conocimiento de la dinámica de todo el ecosistema.
Por lo tanto, podemos ver que el aterrizaje de la tecnología ZK en Ethereum no es solo una innovación tecnológica, sino un viaje de cambio en el que participa todo el ecosistema. Este viaje dará forma al futuro de Ethereum, buscando un entorno de cadena de bloques que equilibre la innovación y la estabilidad, la velocidad y la compatibilidad.
4. Resumen
La apertura de la era ZK no sólo marca un nuevo capítulo en la ecología de Ethereum, sino también un salto histórico. En esta ola de tendencias, se espera que Ethereum no solo supere el sistema de Internet existente en algunos aspectos, sino que también presagia el nacimiento de un método de conexión nuevo y más avanzado.