#dusk $DUSK Ayer, cuando revisaba el documento de Dusk, sentí un escalofrío en la espalda.
Compatible con EVM: suena fantástico. Pero si lo miras con detenimiento, el mecanismo de salida me puso nervioso: no es una estafa de cobros, es que la arquitectura es demasiado profunda.
Las aplicaciones se ejecutan del lado de EVM, y la capa L1 se encarga de la verificación y la liquidación. Para salir hay que seguir tres pasos: esperar el envío de la propuesta, esperar el envío de la prueba y esperar a que termine la ventana de disputas. La validación del estado es entre capas: en cada capa hay que pagar Gas. No es un cobro repetido, es que cada puerta hay que pagar su entrada por separado. Si en cualquiera de los pasos el saldo no alcanza, los activos quedan bloqueados a mitad de camino: sin opción clara para avanzar ni para retroceder.
Lo que más me inquieta es que, por ahora, todo son datos de la red de pruebas.
Hacer funcionar el flujo solo demuestra que el código puede ejecutarse. Pero después de que @Dusk se publique en la red principal, el conjunto de validadores, la frecuencia de disputas y la volatilidad de los precios de Gas — cualquier variable puede convertir un “se puede salir” en “no se puede salir”. El equipo dice que admite salidas, pero nunca ha publicado el tiempo medio de salida en la red principal, ni ha dado detalles de cómo se recupera de fallos. Si ocurriera un problema, ¿quién te ayudaría a recuperar los activos? En la documentación no se menciona.
Un puente maduro entre capas nunca se trata de tener pocos botones, sino de que el usuario entienda cada paso: qué se está haciendo, a dónde van los activos y por qué hay que esperar. En el caso de DuskEVM, la lógica de la división técnica está clara, pero para el usuario es una caja negra: presionas salir y luego viene una larga espera; en la pantalla aparecen varios estados pending que no se entienden.
Esta industria nunca ha carecido de visiones técnicas; lo que falta es esto: si se descarrila todo, ¿qué haces? Cuando el protocolo ni siquiera deja claro el mecanismo de recuperación ante fallos, ¿en qué estás apostando: en la tecnología o en la suerte?
Compatible con EVM: suena fantástico. Pero si lo miras con detenimiento, el mecanismo de salida me puso nervioso: no es una estafa de cobros, es que la arquitectura es demasiado profunda.
Las aplicaciones se ejecutan del lado de EVM, y la capa L1 se encarga de la verificación y la liquidación. Para salir hay que seguir tres pasos: esperar el envío de la propuesta, esperar el envío de la prueba y esperar a que termine la ventana de disputas. La validación del estado es entre capas: en cada capa hay que pagar Gas. No es un cobro repetido, es que cada puerta hay que pagar su entrada por separado. Si en cualquiera de los pasos el saldo no alcanza, los activos quedan bloqueados a mitad de camino: sin opción clara para avanzar ni para retroceder.
Lo que más me inquieta es que, por ahora, todo son datos de la red de pruebas.
Hacer funcionar el flujo solo demuestra que el código puede ejecutarse. Pero después de que @Dusk se publique en la red principal, el conjunto de validadores, la frecuencia de disputas y la volatilidad de los precios de Gas — cualquier variable puede convertir un “se puede salir” en “no se puede salir”. El equipo dice que admite salidas, pero nunca ha publicado el tiempo medio de salida en la red principal, ni ha dado detalles de cómo se recupera de fallos. Si ocurriera un problema, ¿quién te ayudaría a recuperar los activos? En la documentación no se menciona.
Un puente maduro entre capas nunca se trata de tener pocos botones, sino de que el usuario entienda cada paso: qué se está haciendo, a dónde van los activos y por qué hay que esperar. En el caso de DuskEVM, la lógica de la división técnica está clara, pero para el usuario es una caja negra: presionas salir y luego viene una larga espera; en la pantalla aparecen varios estados pending que no se entienden.
Esta industria nunca ha carecido de visiones técnicas; lo que falta es esto: si se descarrila todo, ¿qué haces? Cuando el protocolo ni siquiera deja claro el mecanismo de recuperación ante fallos, ¿en qué estás apostando: en la tecnología o en la suerte?
