He estado prestando atención a un pequeño detalle arquitectónico en Dusk que dice más de lo que parece: el Transfer Contract actúa como el único punto de entrada tanto para DUSK público como para DUSK protegido, en lugar de ejecutar dos sistemas separados que ocasionalmente se hablan entre sí. Cada transferencia, pública o protegida, y cada conversión entre ambos, se encauza a través de la misma lógica del contrato. Esa es una elección de diseño deliberada, no un detalle incidental. Lo importante es sutil. Los sistemas fragmentados tienden a crear casos límite en los que las garantías de privacidad o el registro del balance pueden divergir silenciosamente. Un único punto de entrada reduce la superficie de ataque y hace que auditar la lógica sea más llevadero, al menos en teoría. Lo que aún no sé es cómo se comporta esto bajo una carga real, o si unificar la ruta introduce sus propios cuellos de botella a medida que crece el uso. Preferiría que esto se probara con el volumen real de transacciones, y no solo con documentación. La pregunta es si el diseño se mantiene limpio a medida que se construyen más tipos de contratos encima. Estoy observando su rendimiento cuando llegue el verdadero caudal.
@Dusk #dusk $DUSK
@Dusk #dusk $DUSK