He comparado @Dusk con la documentación pública de este año sobre Dusk Connect y la nueva wallet, y al principio pensé que no era más que “hacer otra wallet”. Al mirar más de cerca, entendí que la vieja web wallet permitía a los usuarios operar directamente en la red, pero no era un punto de entrada estándar para llamadas desde dApp: las aplicaciones no podían descubrir wallets de forma unificada, solicitar cuentas, iniciar firmas ni gestionar permisos. Que un contrato pueda ejecutarse no significa que un usuario normal pueda entrar y usarlo sin fricciones.
Dusk Connect cubre esa capa de pegamento. Se inspira en EIP-6963 para el descubrimiento de wallets, ofrece RPC con espacio de nombres como dusk_requestAccounts y dusk_signMessage, y deja las pruebas de compatibilidad en manos de los desarrolladores de wallets. La nueva wallet de primera parte, por su parte, está orientada a extensiones de navegador, escritorio y móvil, y cubre transferencias públicas/privadas, shield/unshield, staking, recompensas, DRC-20, DRC-721 y permisos de dApp. Las claves se quedan en local: en la extensión se usa PBKDF2 y AES-GCM, y en el cliente nativo, Stronghold y Argon2.
Pero las tres palabras que más fácilmente se borran de un texto promocional son “vista previa para desarrolladores”. Connect y el repositorio de la wallet ya son públicos, lo que indica que la carencia ya tiene una implementación comprobable; pero una vista previa no equivale a que muchas dApps ya estén integradas, ni a que los avisos de permisos, la experiencia móvil y el flujo de recuperación hayan pasado pruebas reales de presión de usuarios. La entrada frontal solo lleva de “se puede desarrollar” a “hay posibilidad de que se use”.
Por eso ahora observo $DUSK no solo fijándome en el TPS o en los nuevos contratos, sino también en cuántas aplicaciones del ecosistema #dusk se conectan realmente a Connect, si el flujo de firma da menos rodeos y si las wallets de terceros se van a sumar. ¿Creéis que lo más difícil de corregir en una cadena nueva es el rendimiento de base, o esas interfaces de wallet discretas pero decisivas para la retención?
$AIO $ETH
Dusk Connect cubre esa capa de pegamento. Se inspira en EIP-6963 para el descubrimiento de wallets, ofrece RPC con espacio de nombres como dusk_requestAccounts y dusk_signMessage, y deja las pruebas de compatibilidad en manos de los desarrolladores de wallets. La nueva wallet de primera parte, por su parte, está orientada a extensiones de navegador, escritorio y móvil, y cubre transferencias públicas/privadas, shield/unshield, staking, recompensas, DRC-20, DRC-721 y permisos de dApp. Las claves se quedan en local: en la extensión se usa PBKDF2 y AES-GCM, y en el cliente nativo, Stronghold y Argon2.
Pero las tres palabras que más fácilmente se borran de un texto promocional son “vista previa para desarrolladores”. Connect y el repositorio de la wallet ya son públicos, lo que indica que la carencia ya tiene una implementación comprobable; pero una vista previa no equivale a que muchas dApps ya estén integradas, ni a que los avisos de permisos, la experiencia móvil y el flujo de recuperación hayan pasado pruebas reales de presión de usuarios. La entrada frontal solo lleva de “se puede desarrollar” a “hay posibilidad de que se use”.
Por eso ahora observo $DUSK no solo fijándome en el TPS o en los nuevos contratos, sino también en cuántas aplicaciones del ecosistema #dusk se conectan realmente a Connect, si el flujo de firma da menos rodeos y si las wallets de terceros se van a sumar. ¿Creéis que lo más difícil de corregir en una cadena nueva es el rendimiento de base, o esas interfaces de wallet discretas pero decisivas para la retención?
$AIO $ETH
