#dusk $DUSK @Dusk
Al principio asumí que W3sper se trataba sobre todo de darle a las aplicaciones una forma de construir y firmar transacciones.
Pero a medida que miré más, destacó algo más silencioso:
construir una transacción aún depende de conocer el estado actual de la cuenta.
Lo que captó mi atención es el requisito de Bookkeeper.
Un perfil recién creado puede proporcionar la identidad necesaria para derivar una cuenta, pero sin una entrada de Bookkeeper sincronizada, la aplicación todavía no sabe el saldo y el nonce que debería usar.
Eso parece un detalle de implementación pequeño, pero traza una línea clara entre saber quién puede firmar y saber qué puede firmarse válidamente.
Una aplicación sin interfaz (headless) puede evitar depender de una extensión de billetera, pero entonces asume la responsabilidad de mantener ese estado exacto y de proteger las claves alrededor de él.
Quizá sea simplemente el costo del control a un nivel inferior.
Eso deja la pregunta más silenciosa:
¿separar la construcción de transacciones del estado de la billetera hace la firma personalizada más segura, o solo deja más margen para errores dentro de la propia aplicación?

¿Qué opinas sobre el diseño de W3sper?