La manía de la inscripción se transmite a la capa 2, ¿por qué zkSync puede pasar la prueba de estrés de las operaciones altísimas?

Escrito por: Haotian

La inscripción grabada en la cadena zkSync y la afluencia a corto plazo de transacciones altísimas es 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 un entrenamiento público de zkSync, y el resultado es que el pico de TPS y la estabilidad de GAS se han probado perfectamente.

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 simple: 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 la tarifa 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 pueden crear fácilmente la ilusión de una “mala experiencia”:

1. Los usuarios construyen 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 de colas. 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 porque existe una “incompatibilidad” entre el tiempo de respuesta RPC y la lógica de retroalimentación de Metamask y la lógica de transacción de cola y empaquetado de Sequencer de zkSync. Es por eso que, después de esperar un tiempo, el servidor backend muestra que algunas transacciones que MetaMask muestra como fallando.

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. Enlace de orden justo del secuenciador: cuando el usuario envía una transacción a la cola RPC por un corto tiempo, cada transacción se superpondrá 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, 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 algunas 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 comportamiento 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 cree que lo ha enviado en el frontend.

En general, la lógica del tiempo de respuesta RPC de la billetera MetaMask y la prisa del usuario por superponer transacciones en la cadena causarán una gran cantidad de “fallas” de transacciones, y es relativamente fácil evitar estos problemas de experiencia de optimización si tiene claro el flujo de trabajo de procesamiento de transacciones en segundo plano 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 de la velocidad de proliferación de 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. Por lo general, el problema se resolverá cuando la velocidad de la transacción se ralentice adecuadamente y el navegador pueda capturar los 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 rumores de apagones, Anthony Rose, un miembro oficial del personal de zkSync, tuiteó con frecuencia informes de actualización 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. De hecho, esta es una “prueba de estrés” suficiente para miles o incluso 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 prorratea, 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, estos datos pueden no ser los mismos 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 debe aumentar la escala de usuario existente en un orden de magnitud.

¿Cuál es 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 del backend de zkSync que clasifica los bloques, y luego se deshace del malentendido de la “mala experiencia”, debe comprender que todo está funcionando bien y tenemos que darle a layer2 un poco más de confianza.