Ayer por la noche revisé la documentación de Dusk y quería entender exactamente cómo se activa en la práctica la “divulgación selectiva”. El documento lo explica muy bonito: privacidad predeterminada, divulgación bajo demanda, y que la supervisión puede verificarse con licencias. Pero al llegar al capítulo de gestión de permisos me detuve: en todo el texto solo dice “el otorgante conserva la clave para ver”, pero no especifica si ese otorgamiento se puede revocar, si existe un tiempo de caducidad, o quién registra las acciones de concesión.
Así que fui a probarlo en la red de pruebas: creé una identidad y concedí el permiso de visualización a un auditor simulado. El flujo funciona: se genera la clave de autorización, se envía la transacción y la otra parte valida; en total son cuatro pasos, y toma alrededor de dos minutos. Pero cuando volví a revisar el registro de autorizaciones, descubrí que no hay ninguna documentación sobre la revocación, y tampoco existe un punto de entrada correspondiente en la consola de la red de pruebas. Es como un interruptor que solo tiene “encender” y no tiene “apagar”: en escenarios de cumplimiento esto es peligroso. Si los permisos de auditoría se otorgan y no se pueden revocar, entonces la “divulgación bajo demanda” se convierte en “una autorización permanente y visible”.
Luego entré a GitHub a revisar el código del contrato del módulo de autorizaciones: busqué “revoke” y “expire” y los resultados fueron vacíos. Tal vez no busqué en la rama correcta del repositorio, o quizá esas funciones aún estén en planes. Pero como usuario, solo puedo guiarme por la documentación existente y el código existente.
Más tarde lo entendí: este no es un problema exclusivo de Dusk; es una lección compartida de la ruta de “privacidad programable”. La concesión de permisos es criptografía; la revocación de permisos es gobernanza. La concesión se puede hacer con matemáticas, pero la revocación solo puede hacerse con procesos. Y el documento, por ahora, no tiene esos procesos.
Por eso, en mi monedero de red de pruebas ahora tengo varios cientos de DUSK, pero de momento no muevo los fondos de la red principal. Esperaré a que el equipo oficial escriba la gestión de autorizaciones (revocación, caducidad, registros de auditoría) tanto en la documentación como en el código, y entonces sí meteré el dinero de verdad. Hasta entonces, admito que “divulgación selectiva” es un buen diseño, pero un diseño no puede tener solo el botón para encender y no tener el botón para apagar.
@Dusk_Foundation $DUSK #dusk
Así que fui a probarlo en la red de pruebas: creé una identidad y concedí el permiso de visualización a un auditor simulado. El flujo funciona: se genera la clave de autorización, se envía la transacción y la otra parte valida; en total son cuatro pasos, y toma alrededor de dos minutos. Pero cuando volví a revisar el registro de autorizaciones, descubrí que no hay ninguna documentación sobre la revocación, y tampoco existe un punto de entrada correspondiente en la consola de la red de pruebas. Es como un interruptor que solo tiene “encender” y no tiene “apagar”: en escenarios de cumplimiento esto es peligroso. Si los permisos de auditoría se otorgan y no se pueden revocar, entonces la “divulgación bajo demanda” se convierte en “una autorización permanente y visible”.
Luego entré a GitHub a revisar el código del contrato del módulo de autorizaciones: busqué “revoke” y “expire” y los resultados fueron vacíos. Tal vez no busqué en la rama correcta del repositorio, o quizá esas funciones aún estén en planes. Pero como usuario, solo puedo guiarme por la documentación existente y el código existente.
Más tarde lo entendí: este no es un problema exclusivo de Dusk; es una lección compartida de la ruta de “privacidad programable”. La concesión de permisos es criptografía; la revocación de permisos es gobernanza. La concesión se puede hacer con matemáticas, pero la revocación solo puede hacerse con procesos. Y el documento, por ahora, no tiene esos procesos.
Por eso, en mi monedero de red de pruebas ahora tengo varios cientos de DUSK, pero de momento no muevo los fondos de la red principal. Esperaré a que el equipo oficial escriba la gestión de autorizaciones (revocación, caducidad, registros de auditoría) tanto en la documentación como en el código, y entonces sí meteré el dinero de verdad. Hasta entonces, admito que “divulgación selectiva” es un buen diseño, pero un diseño no puede tener solo el botón para encender y no tener el botón para apagar.
@Dusk_Foundation $DUSK #dusk