#dusk $DUSK
$GPS listo para volar más alto, más alto, pronto tocará el cielo, pero la línea que me detuvo en la documentación W3sper @Dusk no trataba de firmar.
Se trataba de la advertencia de que un generador de transacciones no es una cartera.
W3sper ofrece a una aplicación herramientas de bajo nivel para conectarse a Rusk, consultar el estado y construir transacciones. Pero si un cliente quiere firmar sin una extensión de cartera, tiene que proporcionar las piezas de las que W3sper deliberadamente no se hace responsable.
Eso incluye el almacenamiento de claves recuperable y una tesorería sincronizada detrás de su "Bookkeeper", incluido el saldo y el estado de nonce necesarios para construir una transacción válida.
Un perfil generado recientemente por sí solo no es suficiente.
Puede contener la identidad necesaria para derivar una cuenta, pero no tiene una entrada sincronizada de "Bookkeeper". Sin el estado actual, el generador de transacciones no puede determinar de forma fiable los fondos o el nonce necesarios para la transferencia.
Ese fue el límite que casi pasé por alto.
Firmar demuestra qué clave autorizó una transacción.
La sincronización le dice al firmante qué puede autorizar válidamente ahora mismo.
Me gusta que W3sper exponga los componentes fundamentales sin pretender en silencio resolver el almacenamiento seguro y la recuperación de la cartera. Pero una aplicación sin interfaz (headless) que elige ese control también hereda esas responsabilidades explícitamente.
¿Separar la construcción de transacciones del estado de la cartera hace que W3sper sea una infraestructura más segura, o hace que los firmantes personalizados sea más fácil crearlos de forma incorrecta?
#dusk @Dusk
La separación de W3sper en Dusk es…
$VELVET vuelco de nuevo, desastre total
$GPS listo para volar más alto, más alto, pronto tocará el cielo, pero la línea que me detuvo en la documentación W3sper @Dusk no trataba de firmar.
Se trataba de la advertencia de que un generador de transacciones no es una cartera.
W3sper ofrece a una aplicación herramientas de bajo nivel para conectarse a Rusk, consultar el estado y construir transacciones. Pero si un cliente quiere firmar sin una extensión de cartera, tiene que proporcionar las piezas de las que W3sper deliberadamente no se hace responsable.
Eso incluye el almacenamiento de claves recuperable y una tesorería sincronizada detrás de su "Bookkeeper", incluido el saldo y el estado de nonce necesarios para construir una transacción válida.
Un perfil generado recientemente por sí solo no es suficiente.
Puede contener la identidad necesaria para derivar una cuenta, pero no tiene una entrada sincronizada de "Bookkeeper". Sin el estado actual, el generador de transacciones no puede determinar de forma fiable los fondos o el nonce necesarios para la transferencia.
Ese fue el límite que casi pasé por alto.
Firmar demuestra qué clave autorizó una transacción.
La sincronización le dice al firmante qué puede autorizar válidamente ahora mismo.
Me gusta que W3sper exponga los componentes fundamentales sin pretender en silencio resolver el almacenamiento seguro y la recuperación de la cartera. Pero una aplicación sin interfaz (headless) que elige ese control también hereda esas responsabilidades explícitamente.
¿Separar la construcción de transacciones del estado de la cartera hace que W3sper sea una infraestructura más segura, o hace que los firmantes personalizados sea más fácil crearlos de forma incorrecta?
#dusk @Dusk
La separación de W3sper en Dusk es…
$VELVET vuelco de nuevo, desastre total
Safer infrastructure
Easier to misuse
Both at once
Builder dependent
4 hora(s) restante(s)
