En el marco de la prueba de estrés de inscripción, zkSync completó con éxito un "entrenamiento abierto"

Autor original: Haotian (X: @tmel0211)

Nota del editor: La pista de inscripción todavía está caliente, la cadena zkSync se ha inundado con una gran cantidad de transacciones en un corto período de tiempo, en esta “prueba de estrés”, zkSync está inactivo debido a la inscripción, ¿o se ha probado perfectamente? El criptoinvestigador Haotian (X:@tmel0211) aclaró la ilusión y el malentendido de la “mala experiencia” de zkSync desde la lógica técnica, y Odaily Planet Daily lo resolvió de la siguiente manera:

La inscripción grabada en la cadena zkSync y la afluencia a corto plazo de transacciones altísimas son, de hecho, una “prueba de estrés” del rendimiento de la cadena pública de Capa 2, pero el resultado no es un “tiempo de inactividad”, por el contrario, se trata de una formación pública @zksync, y el resultado es que el pico de TPS, la estabilidad del GAS, etc. han sido perfectamente probados. **

A primera vista, ¿no suena un poco contradictorio? A continuación, con lógica técnica, déjame aclarártelo:

El principio de funcionamiento de los bloques de empaquetado de zkSync es simplemente el siguiente: los usuarios construyen transacciones en la secuencia de clasificación de zkSync Sequencer, y luego Sequencer las empaqueta en bloques de acuerdo con la clasificación de las tarifas de gas, y luego pasa los bloques al sistema de prueba para su verificación, y finalmente los envía a la red principal para completar la confirmación del estado de finalidad. **

-Hay 2 puntos clave aquí, que son fáciles de crear la ilusión de “mala experiencia”:

1. Los usuarios construyen enlaces de transacciones: La mayoría de los usuarios iniciarán transacciones a través de billeteras como Metamask y enviarán transacciones a zkSync a través de billeteras, y las transacciones ingresarán primero al servidor de llamadas remotas RPC, y luego Sequencer recibirá estas transacciones e ingresará a la secuencia en cola. El tiempo de cola aquí puede ser tan corto como unos segundos o tan largo como unos minutos, y si espera mucho tiempo, MetaMask asumirá que la transacción ha fallado y, a continuación, el front-end devolverá un mensaje de que la transacción ha fallado.

Sin embargo, esto no significa que la transacción haya fallado realmente, sino solo debido a la “incompatibilidad” entre el tiempo de respuesta RPC y la lógica de retroalimentación de Metamask y la lógica de transacción de paquetes en cola del secuenciador de zkSync. **Esta es la razón por la que algunas transacciones que parecen fallar en MetaMask vuelven a tener éxito después de esperar un tiempo.

Si el usuario no pasa por la canalización de la billetera y usa directamente el código de back-end para llamar a la RPC de zkSync, no habrá tiempo de espera de tiempo de respuesta ni error de solicitud, y la experiencia será relativamente fluida. Esto da una ventaja a algunos “científicos” que pueden usar instrucciones de código de backend, pero es esencialmente un problema en el lado de la experiencia de la billetera y no tiene nada que ver con la potencia de procesamiento de la cadena zkSync.

2. Sesión de ordenación justa del secuenciador: cuando el usuario envía una transacción a la cola RPC por un corto tiempo, cada transacción se apilará a partir del valor nonce de 0, si la transacción anterior todavía está en el estado de cola, el nonce es 0, luego el usuario inicia una nueva transacción con un nonce de 1, y el secuenciador de zkSync asignará un nonce a estas transacciones de acuerdo con el tiempo y luego las ordenará en orden.

Sin embargo, si el usuario envía una nueva transacción al mismo tiempo después de ver que la transacción anterior falló en la sección anterior de MetaMask, es probable que algunas de las transacciones recién enviadas no se envíen correctamente a la cola RPC debido al problema del lado de la billetera y la llamada a la interfaz de la API zkSync. Los usuarios piensan que se han enviado muchas transacciones, pero en realidad zkSync solo ha recibido una parte de ellas, y tan pronto como las reciban, las ordenarán.

Viéndolo de esta manera, los usuarios ven que MetaMask informa que las transacciones han fallado, y el acto de enviar constantemente nuevas transacciones también causará una gran cantidad de fallas en las transacciones, porque no hay ningún envío al backend de la cadena zkSync, pero crees que lo has enviado en el frontend. **

En general, los problemas de lógica de tiempo de respuesta RPC de la billetera MetaMask y la prisa de los usuarios por superponer transacciones en la cadena causarán una gran cantidad de “fallas” de transacciones, y es relativamente más fácil evitar estos problemas de experiencia de optimización si tiene claro el flujo de trabajo de procesamiento de transacciones de back-end de zkSync.

-Basándonos en la ciencia popular anterior, aclaremos el problema del “tiempo de inactividad”:

La cadena zkSync no está “inactiva”, es solo un problema de visualización en el front-end del navegador, porque el navegador extraerá los datos más recientes a través de la interfaz RPC de zkSync, pero habrá un retraso en la respuesta de la interfaz y una gran cantidad de transacciones nuevas ralentizarán la respuesta.

En resumen, la velocidad de sincronización de datos de extracción del navegador no puede seguir el ritmo del aumento de las transacciones en cola, lo cual es un problema con el front-end del navegador y no tiene nada que ver con el funcionamiento de la cadena. ** El problema generalmente se resuelve cuando la velocidad de la transacción se ralentiza adecuadamente y el navegador puede capturar nuevos datos.

Cuando el navegador no funciona, puede utilizar otros navegadores que sincronicen la información de datos del bloque zkSync para realizar una verificación cruzada, como:

-¿Cuál es el “rendimiento operativo” de la cadena real?

1. Después de que se conocieran los llamados rumores de interrupción, el personal oficial de zkSync @anthonykrose tuiteado actualizaciones de TPS. De hecho, zkSync TPS se ha disparado a un máximo de 187.9, y en circunstancias normales, el TPS es solo alrededor de 50-100, lo que indica que hay una gran afluencia de nuevas transacciones, y zkSync realmente ha resistido la presión. Esto proporciona una “prueba de estrés” completa para miles, si no decenas de miles, de TPS en el futuro.

2. El mecanismo especial de ZK-Rollup determina que cuanto mayor sea el volumen de transacciones procesado, más barata será la tarifa de gas, de hecho, la tarifa de gas de zkSync es de hecho más barata, porque el costo de transacción también se comparte, según los datos de growthepie, ** En las últimas 24 horas, el gas promedio de zkSync también ha disminuido en un 5.2%, con un promedio de alrededor de $ 0.19, este dato puede no ser el mismo para todos, pero los datos de operación de la cadena integrada son de hecho más baratos. **Esto demuestra que la experiencia más fluida de ZK-Rollup requiere un aumento de orden de magnitud en la escala de usuario existente.

-¿El impacto de los eventos de inscripción en las cadenas públicas de capa 2?

Según los datos de Dune, la acuñación de inscripciones de Sync ha sumado 5 millones de transacciones en 14 horas, y han participado 65.575 titulares. Como se mencionó anteriormente, los funcionarios de zkSync están al tanto de esta “prueba de estrés” iniciada por la comunidad y están tomando medidas urgentes para garantizar que la cadena zkSync funcione de manera ordenada.

Estos datos son, de hecho, un buen experimento de prueba de estrés para zkSync, y sus efectos positivos superan a los negativos. ** A largo plazo, el incidente de la inscripción no fue un rumor, sino que proporcionó experiencia práctica para una mayor optimización del rendimiento de la capa 2. **

Sin embargo, hasta donde yo sé, hay otras inscripciones que se están acuñando además de Sync, que no son tan fomo como Sync, pero añaden leña al fuego de esta prueba de estrés.

De todos modos, los resultados son generalmente buenos, si aclara la lógica técnica de los bloques de clasificación de backend de zkSync y luego se deshace del malentendido de “mala experiencia”, debe comprender que todo funciona bien y debemos darle un poco más de confianza a la capa 2.

Enlace al artículo original