Recientemente, al revisar la documentación de puentes de DuskEVM, noté un aviso que se recalca una y otra vez.
El puente actual solo es compatible con la red de pruebas DUSK.
Esto no es una limitación técnica.
Es que la publicación del estado, la madurez de las pruebas y la ventana de controversias aún requieren tiempo de validación.$BTC
Esto me hizo pensar en un problema más realista: que la red de pruebas funcione no significa que la red principal vaya a servir.
En la arquitectura multicapa de @Dusk , DuskDS se encarga del consenso y la liquidación; DuskEVM usa OP Stack para proporcionar compatibilidad con EVM. Entre ambos, el puente transmite mensajes y activos. En teoría, los desarrolladores pueden desplegar contratos Solidity directamente en DuskEVM y comenzar rápido con herramientas familiares.
Pero el puente no es instantáneo.
Los depósitos deben esperar la confirmación de DuskDS; los retiros deben esperar la publicación del estado en L1, la presentación de la prueba y el final del período de disputa. Si alguna aplicación DeFi necesita arbitraje de alta frecuencia o liquidaciones rápidas, ¿estas demoras son aceptables? Y si en algún punto del intercambio entre capas se queda detenido, ¿quién se hace cargo, cómo se recupera y a quién se atribuyen las pérdidas del usuario?
Lo más importante, además, es la liquidez.
En la red de pruebas puedes acuñar sin problema; en la red principal, cada operación $DUSK tiene un costo real. Si al lanzarse DuskEVM hay liquidez insuficiente en el puente, a los usuarios les resultará fácil depositar, pero difícil retirar. O bien, si el tiempo de espera para retirar es demasiado largo, incluso la mejor compatibilidad difícilmente retendrá la aplicación.
Revisé el roadmap de #dusk y el calendario de auditorías de los contratos del puente y el despliegue en la red principal no está lo suficientemente claro. No es que la tecnología no funcione; simplemente, desde la red de pruebas hasta producción hay varias puertas más: operación y mantenimiento, monitoreo, manejo de anomalías y guías de liquidez.
Así que, al observar el avance de DuskEVM ahora, no me limitaré a preguntar "¿pueden desplegarse contratos".
Me interesan más tres puntos de transformación: la proporción de aplicaciones de red de pruebas que migran a la red principal, el tamaño inicial de la liquidez del puente y su mecanismo de reposición, y la velocidad real de respuesta cuando ocurren anomalías entre capas.
La compatibilidad con EVM reduce el costo de entrada, pero para retener a desarrolladores y usuarios se necesita que el puente sea estable, que el dinero llegue rápido y que alguien se encargue de los problemas.
¿Esta distancia, en serio, es solo un tema de tiempo?
#dusk @Dusk $DUSK