Casi se me pasa en el changelog: cero dependencias de tiempo de ejecución. Enterrado bajo titulares más grandes sobre el lanzamiento del SDK.
Lectura fácil: Dusk Connect simplemente hace que la conexión de wallets sea más fácil para los desarrolladores. Bien, esa es la propuesta: un SDK ligero, lo conectas y listo.
Si te quedas un poco más con ello, en realidad trata de quién controla la capa de conexión. Dusk usa un patrón de descubrimiento basado en eventos: `dusk:announceProvider`, `dusk:requestProvider`, modelado directamente en el EIP-6963 de Ethereum. En vez de que un dApp codifique alrededor de una sola wallet, envía una solicitud y deja que cada wallet compatible responda. El dApp nunca tiene que saber qué wallet gana.
Esto es lo que se pasa por alto: estandarizar el descubrimiento no estandariza la confianza. Cualquier extensión puede escuchar ese evento de solicitud y presentarse como proveedor. El EIP-6963 resolvió la antigua condición de carrera de window.ethereum en Ethereum, pero no resolvió la suplantación de wallets: solo trasladó la carga de verificar qué proveedores son legítimos al usuario, una ventana de conexión a la vez.
El mismo intercambio aparece en las finanzas tradicionales. Las APIs de open banking estandarizaron cómo las apps de terceros solicitan acceso a cuentas, pero un formato de solicitud estandarizado nunca garantizó que quien solicitaba fuera seguro; los bancos siguen añadiendo pantallas separadas de consentimiento y verificación justo por esa razón.
Mi primera impresión fue que cero dependencias solo significaba una instalación más ligera. Pero es más que eso: tener menos dependencias también implica menos lugares donde puede ocultarse una posible vulneración de la cadena de suministro, y menos excusas si aun así se cuela alguna.
¿Preferirías que Dusk se enfoque a continuación en que más proveedores de wallets adopten esto, o en reforzar cómo los dApps verifican con qué proveedor están hablando realmente?
@Dusk #dusk $DUSK
Lectura fácil: Dusk Connect simplemente hace que la conexión de wallets sea más fácil para los desarrolladores. Bien, esa es la propuesta: un SDK ligero, lo conectas y listo.
Si te quedas un poco más con ello, en realidad trata de quién controla la capa de conexión. Dusk usa un patrón de descubrimiento basado en eventos: `dusk:announceProvider`, `dusk:requestProvider`, modelado directamente en el EIP-6963 de Ethereum. En vez de que un dApp codifique alrededor de una sola wallet, envía una solicitud y deja que cada wallet compatible responda. El dApp nunca tiene que saber qué wallet gana.
Esto es lo que se pasa por alto: estandarizar el descubrimiento no estandariza la confianza. Cualquier extensión puede escuchar ese evento de solicitud y presentarse como proveedor. El EIP-6963 resolvió la antigua condición de carrera de window.ethereum en Ethereum, pero no resolvió la suplantación de wallets: solo trasladó la carga de verificar qué proveedores son legítimos al usuario, una ventana de conexión a la vez.
El mismo intercambio aparece en las finanzas tradicionales. Las APIs de open banking estandarizaron cómo las apps de terceros solicitan acceso a cuentas, pero un formato de solicitud estandarizado nunca garantizó que quien solicitaba fuera seguro; los bancos siguen añadiendo pantallas separadas de consentimiento y verificación justo por esa razón.
Mi primera impresión fue que cero dependencias solo significaba una instalación más ligera. Pero es más que eso: tener menos dependencias también implica menos lugares donde puede ocultarse una posible vulneración de la cadena de suministro, y menos excusas si aun así se cuela alguna.
¿Preferirías que Dusk se enfoque a continuación en que más proveedores de wallets adopten esto, o en reforzar cómo los dApps verifican con qué proveedor están hablando realmente?
@Dusk #dusk $DUSK
