Vi a un amigo quejarse de que @zkSync siempre está inactivo. De hecho, llamarlo "tiempo de inactividad" es un poco exagerado. Para ser precisos, es "generación de bloques inestable".
Esencialmente, 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 en la 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 el "tiempo de inactividad" puede ser el problema de la falla de la transacción causado por la compatibilidad entre algunas DApps y la capa inferior 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, mientras que 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 divulgación científica y le brinda 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 secuenciador a través del reenvío de retransmisión;
Sequencer es responsable de clasificar transacciones, agregar y empaquetar lotes en un árbol Merkle;
zkPorter genera certificados zk-SNARK a partir del árbol Merkle; los certificados zk-SNARK se transmiten respectivamente a los validadores L2 y a la cadena principal L1 para generar Commit Hash; los validadores son responsables de la verificación
La corrección de la prueba zk-SNARK se envía al contrato inteligente L1 para generar un Verify Hash;
El contrato inteligente zkSync en L1 verifica la coincidencia de Commit Hash y Verify Hash;
Después de una coincidencia exitosa, se genera una transacción verificada y la transacción finalmente se carga en la cadena;
Si la coincidencia falla, el Commit Hash original se invalidará y el secuenciador volverá a enviar el lote y volverá a realizar 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 en 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:
Múltiples nodos distribuidos pueden evitar la inestabilidad de la red causada por un único punto de falla, y el sistema es robusto; 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 otro ángulo, 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 fortalecer su confianza en la pista técnica L2.
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.
El mecanismo de operación de zkSync está resuelto, no "tiempo de inactividad" con frecuencia
Vi a un amigo quejarse de que @zkSync siempre está inactivo. De hecho, llamarlo "tiempo de inactividad" es un poco exagerado. Para ser precisos, es "generación de bloques inestable".
Esencialmente, 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 en la 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 el "tiempo de inactividad" puede ser el problema de la falla de la transacción causado por la compatibilidad entre algunas DApps y la capa inferior 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, mientras que 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 divulgación científica y le brinda 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 secuenciador a través del reenvío de retransmisión;
Sequencer es responsable de clasificar transacciones, agregar y empaquetar lotes en un árbol Merkle;
zkPorter genera certificados zk-SNARK a partir del árbol Merkle; los certificados zk-SNARK se transmiten respectivamente a los validadores L2 y a la cadena principal L1 para generar Commit Hash; los validadores son responsables de la verificación
La corrección de la prueba zk-SNARK se envía al contrato inteligente L1 para generar un Verify Hash;
El contrato inteligente zkSync en L1 verifica la coincidencia de Commit Hash y Verify Hash;
Después de una coincidencia exitosa, se genera una transacción verificada y la transacción finalmente se carga en la cadena;
Si la coincidencia falla, el Commit Hash original se invalidará y el secuenciador volverá a enviar el lote y volverá a realizar 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 en 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:
Múltiples nodos distribuidos pueden evitar la inestabilidad de la red causada por un único punto de falla, y el sistema es robusto; 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 otro ángulo, 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 fortalecer su confianza en la pista técnica L2.