Ahora mi mayor duda sobre @Dusk no es si la tecnología puede hacerlo, sino si el usuario común se atreverá a usarlo.
Recientemente volví a revisar el proceso operativo real paso a paso. En el lado de la ingeniería, las actualizaciones sí que son bastante frecuentes, pero cuando llega a manos de los usuarios, acciones básicas como la migración, los cruces entre cadenas y el staking todavía tienen una tolerancia a fallos un poco baja.
Por ejemplo, migrar DUSK ERC20/BEP20 a la red principal no es simplemente hacer un clic y ya: primero está el Approve y luego el Execute; si te saltas un paso, ya no cuenta como migración completada. El tiempo de espera típico que da oficialmente sigue siendo de aproximadamente 1 hora, y además hay que preparar con antelación ETH/BNB para el gas.
Lo que más me preocupa es el traslado de la red principal a BSC. La dirección de recepción requiere que se especifique mediante el memo. La documentación oficial lo advierte directamente: si falta el memo o es inválido, la transacción puede no procesarse automáticamente e incluso existe el riesgo de que los activos no se puedan recuperar.
Para los jugadores veteranos quizá parezca “solo hay que fijarse y ya”, pero si el producto apunta a un público más amplio, no puede seguir trasladando toda la responsabilidad de prevención de errores al usuario.
El staking también es parecido. Hacer staking directamente desde un mínimo de 1000 DUSK, además exige que tú ejecutes el provisioner. El nodo tiene que mantenerse en línea, con sincronización y versión correctas; y para que la activación funcione normalmente se necesitan alrededor de 6 a 12 horas. Técnicamente no hay nada malo, pero desde la perspectiva de una persona con DUSK que solo lo mantiene, claramente no es una operación especialmente sencilla.
Además, este año en enero el servicio de puente también sufrió una intrusión en una wallet con firma. Aunque la entidad oficial luego aclaró que no era una vulnerabilidad del consenso de Dusk, el usuario común en realidad no distingue entre “seguridad del protocolo” y “seguridad del servicio”; él solo se preocupa por una cosa: si hago la operación mal o si el sistema falla, ¿mis fondos pueden volver?
Así que ahora más bien siento que, en la siguiente etapa, lo que Dusk debe reforzar no es solo el rendimiento de la base.
Sino lograr de verdad que la experiencia predeterminada del producto sea: “que no se pueda completar mal”, “que se entienda el estado” y “que si hay errores, haya forma de recuperarse”.
La complejidad técnica puede existir, pero la experiencia de usuario no debe ser compleja.
#dusk $DUSK @Dusk
Recientemente volví a revisar el proceso operativo real paso a paso. En el lado de la ingeniería, las actualizaciones sí que son bastante frecuentes, pero cuando llega a manos de los usuarios, acciones básicas como la migración, los cruces entre cadenas y el staking todavía tienen una tolerancia a fallos un poco baja.
Por ejemplo, migrar DUSK ERC20/BEP20 a la red principal no es simplemente hacer un clic y ya: primero está el Approve y luego el Execute; si te saltas un paso, ya no cuenta como migración completada. El tiempo de espera típico que da oficialmente sigue siendo de aproximadamente 1 hora, y además hay que preparar con antelación ETH/BNB para el gas.
Lo que más me preocupa es el traslado de la red principal a BSC. La dirección de recepción requiere que se especifique mediante el memo. La documentación oficial lo advierte directamente: si falta el memo o es inválido, la transacción puede no procesarse automáticamente e incluso existe el riesgo de que los activos no se puedan recuperar.
Para los jugadores veteranos quizá parezca “solo hay que fijarse y ya”, pero si el producto apunta a un público más amplio, no puede seguir trasladando toda la responsabilidad de prevención de errores al usuario.
El staking también es parecido. Hacer staking directamente desde un mínimo de 1000 DUSK, además exige que tú ejecutes el provisioner. El nodo tiene que mantenerse en línea, con sincronización y versión correctas; y para que la activación funcione normalmente se necesitan alrededor de 6 a 12 horas. Técnicamente no hay nada malo, pero desde la perspectiva de una persona con DUSK que solo lo mantiene, claramente no es una operación especialmente sencilla.
Además, este año en enero el servicio de puente también sufrió una intrusión en una wallet con firma. Aunque la entidad oficial luego aclaró que no era una vulnerabilidad del consenso de Dusk, el usuario común en realidad no distingue entre “seguridad del protocolo” y “seguridad del servicio”; él solo se preocupa por una cosa: si hago la operación mal o si el sistema falla, ¿mis fondos pueden volver?
Así que ahora más bien siento que, en la siguiente etapa, lo que Dusk debe reforzar no es solo el rendimiento de la base.
Sino lograr de verdad que la experiencia predeterminada del producto sea: “que no se pueda completar mal”, “que se entienda el estado” y “que si hay errores, haya forma de recuperarse”.
La complejidad técnica puede existir, pero la experiencia de usuario no debe ser compleja.
#dusk $DUSK @Dusk