Un amigo se quejó de que zkSync siempre está inactivo. De hecho, llamarlo "tiempo de inactividad" es un poco exagerado. Para ser precisos, significa "generación de bloques inestables". En esencia, el tiempo final verificado de la transacción enviada por Sequencer es inestable, pero la percepción del usuario no es obvia en el extremo interactivo, porque el diseño Verify de zkSync tiene un retraso de confirmación. Se paliará la inestabilidad en la futura etapa de descentralización. Dibujé un flujo de trabajo para discutir con usted.
La razón por la que los usuarios perciben "tiempo de inactividad" puede ser la falla de la transacción causada por algunas DApps y la compatibilidad subyacente de la cadena.Después de todo, desarrollar DApps en zkSync en sí mismo es un gran desafío. Me toma entre 30 minutos y 1 hora observar el cambio de estado de Confirmar a Verificado desde el navegador oficial, y la DApp interactiva del lado del usuario apenas se ve afectada por esto. Este artículo se centra en la lógica subyacente de la tecnología zkSync de ciencia popular, para brindarle una comprensión clara de zkSync.
Como se muestra en el flujo de trabajo, zkSync se ejecuta en los siguientes pasos:
El usuario envía transacciones por lotes al clasificador Sequencer a través del reenvío de retransmisión;
Sequencer es responsable de clasificar transacciones, agregar y empaquetar lotes en árboles Merkle;
zkPorter genera una prueba zk-SNARK del árbol Merkle;
zk-SNARK demuestra que el relé genera Commit Hash a L2 Validators y L1 main chain respectivamente
El Validador es responsable de verificar la corrección de la prueba zk-SNARK y enviarla al contrato inteligente L1 para generar un Verify Hash después de que sea correcto; 6) El contrato inteligente zkSync en L1 verifica la coincidencia del Commit Hash y Verify Hash; 7) Genera un Verified después de una coincidencia exitosa La transacción Transaction finalmente se carga en la cadena; 8) Si la coincidencia falla, el Commit Hash original se invalidará y el secuenciador volverá a enviar el lote y volverá a pasar por el proceso .
Debe enfatizarse aquí que zkSync adopta "compromiso de dos fases (2PC)" y finalmente determina el lote de transacciones legales a través de la verificación Hash de las dos etapas de Commit Hash y Verify Hash. Por un lado, esto puede garantizar la consistencia y seguridad de los datos en el proceso de operación del sistema. A mi entender, también es una manifestación de la idea de descentralización que restringe los dos componentes del sistema, Secuenciador y Validador, y es digno de alabanza
El flujo de trabajo de zkSync tiene principalmente cuatro funciones: relé, secuenciador, zkPorter y validador. Habrá muchos "factores inestables" en el trabajo de coordinación. Se puede resumir como la estabilidad de las funciones de los nodos, la estabilidad de la cooperación de los nodos y la complejidad de los algoritmos y protocolos subyacentes. Cualquier error en cualquier enlace puede causar retraso en el bloqueo. Las fallas técnicas comunes de Arbitrum Sequencer son típicas, y zkSync solo enfrentará más desafíos.
En cuanto a la complejidad del algoritmo, este es el destino de la cadena zkSync y los desarrolladores ecológicos deben trabajar duro para superarlo. En cuanto a la estabilidad de la inteligencia y la colaboración de los nodos, creo que después de la llegada de la etapa de descentralización en el futuro, se mejorará de manera efectiva. La lógica también es simple:
Los nodos multidistribuidos pueden evitar la inestabilidad de la red causada por un punto único de falla, que se debe a la solidez del sistema;
El mecanismo de incentivo de token distribuido puede proporcionar a los desarrolladores una fuente de motivación para mantener la estabilidad del nodo.
Pensando desde otra perspectiva, el largo tiempo de verificación no es un problema en la etapa inicial de la ecología, puede mejorar efectivamente la seguridad de la cadena y evitar que algunos nodos en el sistema hagan el mal. En resumen, si aclara todo el proceso operativo de zkSync y comprende mejor la complejidad técnica de la capa 2 y el mecanismo "especial" diseñado para la seguridad, puede consolidar su confianza en la pista técnica L2. Todos son bienvenidos a reenviar y compartir, enviarme un mensaje privado en cualquier momento y tengamos un intercambio y estudio en profundidad de zkSync.
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.
¿Por qué zkSync es siempre "tiempo de inactividad"? Un artículo sobre el flujo de trabajo de zkSync
Un amigo se quejó de que zkSync siempre está inactivo. De hecho, llamarlo "tiempo de inactividad" es un poco exagerado. Para ser precisos, significa "generación de bloques inestables". En esencia, el tiempo final verificado de la transacción enviada por Sequencer es inestable, pero la percepción del usuario no es obvia en el extremo interactivo, porque el diseño Verify de zkSync tiene un retraso de confirmación. Se paliará la inestabilidad en la futura etapa de descentralización. Dibujé un flujo de trabajo para discutir con usted.
La razón por la que los usuarios perciben "tiempo de inactividad" puede ser la falla de la transacción causada por algunas DApps y la compatibilidad subyacente de la cadena.Después de todo, desarrollar DApps en zkSync en sí mismo es un gran desafío. Me toma entre 30 minutos y 1 hora observar el cambio de estado de Confirmar a Verificado desde el navegador oficial, y la DApp interactiva del lado del usuario apenas se ve afectada por esto. Este artículo se centra en la lógica subyacente de la tecnología zkSync de ciencia popular, para brindarle una comprensión clara de zkSync.
Como se muestra en el flujo de trabajo, zkSync se ejecuta en los siguientes pasos:
El usuario envía transacciones por lotes al clasificador Sequencer a través del reenvío de retransmisión;
Sequencer es responsable de clasificar transacciones, agregar y empaquetar lotes en árboles Merkle;
zkPorter genera una prueba zk-SNARK del árbol Merkle;
zk-SNARK demuestra que el relé genera Commit Hash a L2 Validators y L1 main chain respectivamente
El Validador es responsable de verificar la corrección de la prueba zk-SNARK y enviarla al contrato inteligente L1 para generar un Verify Hash después de que sea correcto; 6) El contrato inteligente zkSync en L1 verifica la coincidencia del Commit Hash y Verify Hash; 7) Genera un Verified después de una coincidencia exitosa La transacción Transaction finalmente se carga en la cadena; 8) Si la coincidencia falla, el Commit Hash original se invalidará y el secuenciador volverá a enviar el lote y volverá a pasar por el proceso .
Debe enfatizarse aquí que zkSync adopta "compromiso de dos fases (2PC)" y finalmente determina el lote de transacciones legales a través de la verificación Hash de las dos etapas de Commit Hash y Verify Hash. Por un lado, esto puede garantizar la consistencia y seguridad de los datos en el proceso de operación del sistema. A mi entender, también es una manifestación de la idea de descentralización que restringe los dos componentes del sistema, Secuenciador y Validador, y es digno de alabanza
El flujo de trabajo de zkSync tiene principalmente cuatro funciones: relé, secuenciador, zkPorter y validador. Habrá muchos "factores inestables" en el trabajo de coordinación. Se puede resumir como la estabilidad de las funciones de los nodos, la estabilidad de la cooperación de los nodos y la complejidad de los algoritmos y protocolos subyacentes. Cualquier error en cualquier enlace puede causar retraso en el bloqueo. Las fallas técnicas comunes de Arbitrum Sequencer son típicas, y zkSync solo enfrentará más desafíos.
En cuanto a la complejidad del algoritmo, este es el destino de la cadena zkSync y los desarrolladores ecológicos deben trabajar duro para superarlo. En cuanto a la estabilidad de la inteligencia y la colaboración de los nodos, creo que después de la llegada de la etapa de descentralización en el futuro, se mejorará de manera efectiva. La lógica también es simple:
Los nodos multidistribuidos pueden evitar la inestabilidad de la red causada por un punto único de falla, que se debe a la solidez del sistema;
El mecanismo de incentivo de token distribuido puede proporcionar a los desarrolladores una fuente de motivación para mantener la estabilidad del nodo.
Pensando desde otra perspectiva, el largo tiempo de verificación no es un problema en la etapa inicial de la ecología, puede mejorar efectivamente la seguridad de la cadena y evitar que algunos nodos en el sistema hagan el mal. En resumen, si aclara todo el proceso operativo de zkSync y comprende mejor la complejidad técnica de la capa 2 y el mecanismo "especial" diseñado para la seguridad, puede consolidar su confianza en la pista técnica L2. Todos son bienvenidos a reenviar y compartir, enviarme un mensaje privado en cualquier momento y tengamos un intercambio y estudio en profundidad de zkSync.