He leído el libro blanco de @Dusk y, la verdad, me ha dado un poco de “subidón”, y también me ha dejado con dudas.
¿La gran apuesta sigue bien? ¿Y el BTC tiene futuro?
En su estándar XSC, lo que se propone es un “quiero ambos, por ambos lados” — privacidad y cumplimiento normativo a la vez. Suena bastante perfecto, pero si lo analizas con calma, no es tan sencillo. En el libro blanco describen detalles técnicos de forma bastante sutil, y cada vez que llegan a lo importante, lo despachan con un “para más detalles, consulta otro artículo”.
La gente que ha estado en el sector financiero sabe que lo más enrevesado nunca es si la tecnología se puede hacer realidad, sino quién tiene el control de los permisos. En el libro blanco de Dusk se menciona el rol del auditor (Auditor): dicen que los datos de las transacciones se cifran con la clave pública del auditor para facilitar el rastreo regulatorio. Pero el problema es: ¿quién es ese auditor? ¿Es la propia empresa del proyecto? ¿Es algún tercero designado? ¿O la propia entidad reguladora?
La lógica detrás de esto cambia muchísimo. Si la clave de auditoría la tiene el equipo del proyecto, ¿en qué se diferencia de la custodia centralizada de las finanzas tradicionales? Si el cliente institucional deposita los activos y, al final, tu contraparte, tus posiciones y el volumen de tus tenencias son visibles para el equipo del proyecto, ¿eso es privacidad? No: eso es “transparencia unilateral”.
El libro blanco también dice que el auditor puede ser un esquema de multisig “m-de-n” (m-of-n), gestionado con criptografía de umbral. Esa idea es correcta: distribuir el poder. Pero al aterrizarlo: ¿quién posee los fragmentos de la clave? ¿Cómo asegurar que el proceso de auditoría no se use de forma abusiva? En la práctica, esas cuestiones el libro blanco no las explica con claridad.
Otro punto interesante es que, más tarde, Dusk actualizó el modelo de transacciones Moonlight, diciendo que puede reconocer la identidad del remitente de las transacciones de Phoenix para que el receptor la vea. Eso convierte el anonimato puro en una “privacidad controlable”: sabes quién te envió el dinero, pero los transeúntes no. En realidad, ese es el estado que necesita el cumplimiento normativo en finanzas: entre contrapartes, claridad y transparencia; pero el mercado no revela secretos comerciales.
En pocas palabras: que XSC funcione o no no depende de lo “duro” que sea el ZK-proof, sino de dónde se monta exactamente esta llave para que “no se pueda acceder” detrás de esa pared. Si el diseño de la gestión de claves no es lo suficientemente riguroso, entonces privacidad y cumplimiento se convierten en un bucle de bloqueo que se frena mutuamente, en vez de una relación complementaria.
Y con la colaboración de NPEX para valores tokenizados de 300 millones de euros, el problema se puso sobre la mesa. @Dusk $DUSK #dusk
¿La gran apuesta sigue bien? ¿Y el BTC tiene futuro?
En su estándar XSC, lo que se propone es un “quiero ambos, por ambos lados” — privacidad y cumplimiento normativo a la vez. Suena bastante perfecto, pero si lo analizas con calma, no es tan sencillo. En el libro blanco describen detalles técnicos de forma bastante sutil, y cada vez que llegan a lo importante, lo despachan con un “para más detalles, consulta otro artículo”.
La gente que ha estado en el sector financiero sabe que lo más enrevesado nunca es si la tecnología se puede hacer realidad, sino quién tiene el control de los permisos. En el libro blanco de Dusk se menciona el rol del auditor (Auditor): dicen que los datos de las transacciones se cifran con la clave pública del auditor para facilitar el rastreo regulatorio. Pero el problema es: ¿quién es ese auditor? ¿Es la propia empresa del proyecto? ¿Es algún tercero designado? ¿O la propia entidad reguladora?
La lógica detrás de esto cambia muchísimo. Si la clave de auditoría la tiene el equipo del proyecto, ¿en qué se diferencia de la custodia centralizada de las finanzas tradicionales? Si el cliente institucional deposita los activos y, al final, tu contraparte, tus posiciones y el volumen de tus tenencias son visibles para el equipo del proyecto, ¿eso es privacidad? No: eso es “transparencia unilateral”.
El libro blanco también dice que el auditor puede ser un esquema de multisig “m-de-n” (m-of-n), gestionado con criptografía de umbral. Esa idea es correcta: distribuir el poder. Pero al aterrizarlo: ¿quién posee los fragmentos de la clave? ¿Cómo asegurar que el proceso de auditoría no se use de forma abusiva? En la práctica, esas cuestiones el libro blanco no las explica con claridad.
Otro punto interesante es que, más tarde, Dusk actualizó el modelo de transacciones Moonlight, diciendo que puede reconocer la identidad del remitente de las transacciones de Phoenix para que el receptor la vea. Eso convierte el anonimato puro en una “privacidad controlable”: sabes quién te envió el dinero, pero los transeúntes no. En realidad, ese es el estado que necesita el cumplimiento normativo en finanzas: entre contrapartes, claridad y transparencia; pero el mercado no revela secretos comerciales.
En pocas palabras: que XSC funcione o no no depende de lo “duro” que sea el ZK-proof, sino de dónde se monta exactamente esta llave para que “no se pueda acceder” detrás de esa pared. Si el diseño de la gestión de claves no es lo suficientemente riguroso, entonces privacidad y cumplimiento se convierten en un bucle de bloqueo que se frena mutuamente, en vez de una relación complementaria.
Y con la colaboración de NPEX para valores tokenizados de 300 millones de euros, el problema se puso sobre la mesa. @Dusk $DUSK #dusk
