Pongo a mí mismo en el puesto de responsable de cumplimiento de una empresa de gestión de activos: muchas cosas salen a la luz por sí solas. Para emitir un fondo tokenizado on-chain, la identidad de los inversionistas debe verificarse: KYC y permisos deben tener un propietario. El reequilibrio del fondo y el ritmo de entradas y salidas no pueden quedar expuestos para que los competidores y el mercado lo vean. Cuando llega la supervisión y pregunta, cada transferencia debe tener sustento y documentación para poder entregarla. Con esas tres cosas ordenadas, cómo elegir la cadena queda claro.

El Zedger de DUSK para esta clase de necesidades, en su diseño, casi está escrito siguiendo la respuesta. Crea una cuenta on-chain para cada usuario; la verificación de identidad, listas blancas y permisos quedan montados en esa cuenta. Del lado de la ejecución, sigue una vía de privacidad: el monto, la ruta y las relaciones con contrapartes no se exponen hacia afuera. La cuenta se encarga de rendir cuentas; la ejecución con privacidad se encarga de ocultar los detalles. Comparé el modelo de cuenta puro y el modelo UTXO puro, y ambos extremos se evitan. $ETH .

Dicho con franqueza, esta estructura todavía no está completamente funcionando de punta a punta como yo lo idealizo; aún está en fase Beta y sigue avanzando, y la división de tareas con Hedger también se está ajustando en todo momento. El diseño está alineado con la necesidad; el aterrizaje aún falta una parte del camino, pero este margen lo controlo.

No tengo muchas conclusiones: la estructura de libro contable de Zedger es el primer trabajo central que DUSK entrega para el escenario financiero, y además es el que mejor muestra el esfuerzo. No hizo que privacidad y cumplimiento se pelearan por el carril, sino que colocó dos exigencias en posiciones distintas dentro del mismo sistema de contabilidad. La progresión del despliegue posterior y la división con Hedger seguiré vigilándolas. #dusk $DUSK @Dusk