#dusk $DUSK @Dusk
¿LA CIFRA DE PRUEBA (TIEMPO DE GENERACIÓN DE PRUEBA) ES REALMENTE BUENA? TODAVÍA NO REFLEJA LA VELOCIDAD DE TRANSACCIÓN REAL.
Mucha gente se emociona al ver métricas criptográficas del lado del cliente: Hedger en DuskEVM puede generar una prueba ZK en menos de 2 segundos. Esto es, sin duda, un avance impresionante en términos de optimización algorítmica, que indica que los usuarios no tendrán que esperar varios minutos en sus dispositivos solo para crear una prueba de seguridad.
Pero un único número en el primer paso nunca ha reflejado por completo la experiencia de todo el proceso.
Generar una prueba ZK local (local proof) en menos de 2 segundos solo resuelve el cuello de botella del lado del cliente (client-side bottleneck). No nos dice cuánto tiempo tardará en completarse una transacción segura (End-to-End Settlement) cuando recorra todos los eslabones:
Verificación de la prueba (Proof Verification): ¿Cuánto tiempo tardan los nodos de la red en comprobar la validez de esa prueba?
Ordenamiento e inclusión en bloque (Sequencing & Inclusion Latency): ¿Cuánto tiempo debe esperar la transacción secreta en la cola antes de que se incluya en un bloque?
Ejecución y finalización (Execution & Finality): ¿Cuántos segundos tarda en total en actualizarse el estado privado (state) y quedar finalmente asentado (settle) en la cadena?
Los usuarios comunes y las instituciones financieras no experimentan un sistema por la velocidad del propio generador de pruebas (prover). Ellos experimentan la latencia total desde que presionan "Enviar" hasta que la transacción queda irrevocablemente completada.
Por ello, el estándar para evaluar el progreso técnico de Dusk no solo se basa en el número "menos de 2 segundos" en el laboratorio. Las señales que realmente determinan la capacidad operativa
¿LA CIFRA DE PRUEBA (TIEMPO DE GENERACIÓN DE PRUEBA) ES REALMENTE BUENA? TODAVÍA NO REFLEJA LA VELOCIDAD DE TRANSACCIÓN REAL.
Mucha gente se emociona al ver métricas criptográficas del lado del cliente: Hedger en DuskEVM puede generar una prueba ZK en menos de 2 segundos. Esto es, sin duda, un avance impresionante en términos de optimización algorítmica, que indica que los usuarios no tendrán que esperar varios minutos en sus dispositivos solo para crear una prueba de seguridad.
Pero un único número en el primer paso nunca ha reflejado por completo la experiencia de todo el proceso.
Generar una prueba ZK local (local proof) en menos de 2 segundos solo resuelve el cuello de botella del lado del cliente (client-side bottleneck). No nos dice cuánto tiempo tardará en completarse una transacción segura (End-to-End Settlement) cuando recorra todos los eslabones:
Verificación de la prueba (Proof Verification): ¿Cuánto tiempo tardan los nodos de la red en comprobar la validez de esa prueba?
Ordenamiento e inclusión en bloque (Sequencing & Inclusion Latency): ¿Cuánto tiempo debe esperar la transacción secreta en la cola antes de que se incluya en un bloque?
Ejecución y finalización (Execution & Finality): ¿Cuántos segundos tarda en total en actualizarse el estado privado (state) y quedar finalmente asentado (settle) en la cadena?
Los usuarios comunes y las instituciones financieras no experimentan un sistema por la velocidad del propio generador de pruebas (prover). Ellos experimentan la latencia total desde que presionan "Enviar" hasta que la transacción queda irrevocablemente completada.
Por ello, el estándar para evaluar el progreso técnico de Dusk no solo se basa en el número "menos de 2 segundos" en el laboratorio. Las señales que realmente determinan la capacidad operativa