Una cosa llamó mi atención al profundizar en Dusk: una billetera puede seguir estando correctamente vinculada a una identidad y, aun así, fallar una transferencia porque la decisión de elegibilidad que hay detrás de esa transferencia ya no está actualizada.
Al principio asumí que eran, básicamente, un solo paso de validación.
No lo son.
Cuanto más miré la arquitectura, más empezó a parecer un problema de gestión de estado más que un problema de billetera.
La vinculación de billetera establece una relación criptográfica entre una identidad y una billetera.
Esa relación puede seguir siendo perfectamente válida mientras cambien las condiciones externas que afectan la elegibilidad para transferir.
Imagina una billetera vinculada el lunes. El martes, cambia un parámetro de cumplimiento fuera de la cadena (off-chain).
La asociación de identidad no se ha revocado, la billetera no ha cambiado y el usuario todavía puede demostrar que tiene el control de ella.
Pero si el estado de la política usado durante la evaluación de la transacción no se ha recalculado, la transferencia puede encontrarse con un resultado completamente distinto. #dusk .
Esa distinción es fácil de pasar por alto porque la interfaz comprime varias verificaciones en una sola experiencia: “verificado” no necesariamente significa “elegible ahora mismo”.
Debajo, puede haber varias transiciones de estado independientes: verificación de la firma, asociación de identidad, estado de credencial o de política, y la autorización final de la transferencia. @Dusk .
La pregunta de ingeniería importante es cómo los cambios en la política externa se propagan al estado que la transacción realmente evalúa.
Para $DUSK , esto crea un intercambio interesante. Mantener el estado de la política de forma conservadora puede reducir la exposición al cumplimiento, pero el estado obsoleto significa transferencias rechazadas y fricción operativa.
Actualizarlo con más agresividad mejora la vigencia, pero introduce cómputo adicional, coordinación y dependencias de infraestructura.
Lo que todavía intento entender es la capa de incentivos: cuando una billetera válida se vuelve un permiso desactualizado, ¿quién es responsable económica y operativamente de refrescar ese estado?
Al principio asumí que eran, básicamente, un solo paso de validación.
No lo son.
Cuanto más miré la arquitectura, más empezó a parecer un problema de gestión de estado más que un problema de billetera.
La vinculación de billetera establece una relación criptográfica entre una identidad y una billetera.
Esa relación puede seguir siendo perfectamente válida mientras cambien las condiciones externas que afectan la elegibilidad para transferir.
Imagina una billetera vinculada el lunes. El martes, cambia un parámetro de cumplimiento fuera de la cadena (off-chain).
La asociación de identidad no se ha revocado, la billetera no ha cambiado y el usuario todavía puede demostrar que tiene el control de ella.
Pero si el estado de la política usado durante la evaluación de la transacción no se ha recalculado, la transferencia puede encontrarse con un resultado completamente distinto. #dusk .
Esa distinción es fácil de pasar por alto porque la interfaz comprime varias verificaciones en una sola experiencia: “verificado” no necesariamente significa “elegible ahora mismo”.
Debajo, puede haber varias transiciones de estado independientes: verificación de la firma, asociación de identidad, estado de credencial o de política, y la autorización final de la transferencia. @Dusk .
La pregunta de ingeniería importante es cómo los cambios en la política externa se propagan al estado que la transacción realmente evalúa.
Para $DUSK , esto crea un intercambio interesante. Mantener el estado de la política de forma conservadora puede reducir la exposición al cumplimiento, pero el estado obsoleto significa transferencias rechazadas y fricción operativa.
Actualizarlo con más agresividad mejora la vigencia, pero introduce cómputo adicional, coordinación y dependencias de infraestructura.
Lo que todavía intento entender es la capa de incentivos: cuando una billetera válida se vuelve un permiso desactualizado, ¿quién es responsable económica y operativamente de refrescar ese estado?
