#dusk $DUSK @Dusk Cuanto más profundo se mira, más aparece una pregunta que no me deja en paz: para los servicios financieros regulados, la privacidad por sí sola no es suficiente. Lo verdaderamente importante es si las reglas de transacción pueden llevarse a la práctica. Por eso, me puse a revisar a fondo el enfoque de cumplimiento de Dusk.
Phoenix cubre los detalles de las transacciones con pruebas de conocimiento cero; Moonlight ofrece un flujo de cuenta transparente; Citadel añade una capa adicional de divulgación selectiva; y, además, los contratos de XSC pueden incorporar directamente al motor de la transacción cosas como las restricciones de elegibilidad, las limitaciones de transferencia y los requisitos de reporte. Esto en realidad demuestra que el cumplimiento no necesariamente tiene que colocarse por completo fuera de la cadena.
Pero hay un requisito ineludible: cuando los productos financieros se vuelven complejos, las reglas también tienden a volverse más complejas. Por ejemplo, algunos activos requieren restricciones de transferencia, votación, acciones corporativas, procesos de recuperación, e incluso distintos niveles de divulgación. En cierto punto, el problema ya no es si la privacidad sirve, sino si, al superponerse todas esas reglas, el sistema aún puede funcionar exactamente como se espera.
Por poner un ejemplo: si una transferencia de valores activa simultáneamente reglas de restricción de venta, cambios en los derechos de voto y obligaciones de divulgación entre jurisdicciones, el contrato en cadena debe poder comprobar todas las condiciones de restricción en el mismo ciclo de ejecución. Cualquier condición que se pase por alto podría hacer que toda la transacción sea inválida, e incluso provocar un incidente de cumplimiento. En escenarios financieros reales, estas combinaciones de reglas complejas no son un caso raro: son parte del día a día.
Supongo que ahí es donde más he estado poniendo el foco cuando miro a Dusk. Solo con el diagrama de arquitectura todo encaja; lo que de verdad quiero comprobar es si, cuando el flujo de trabajo real empieza a desordenarse y surgen todo tipo de casos límite, el sistema aguanta o no.
Phoenix cubre los detalles de las transacciones con pruebas de conocimiento cero; Moonlight ofrece un flujo de cuenta transparente; Citadel añade una capa adicional de divulgación selectiva; y, además, los contratos de XSC pueden incorporar directamente al motor de la transacción cosas como las restricciones de elegibilidad, las limitaciones de transferencia y los requisitos de reporte. Esto en realidad demuestra que el cumplimiento no necesariamente tiene que colocarse por completo fuera de la cadena.
Pero hay un requisito ineludible: cuando los productos financieros se vuelven complejos, las reglas también tienden a volverse más complejas. Por ejemplo, algunos activos requieren restricciones de transferencia, votación, acciones corporativas, procesos de recuperación, e incluso distintos niveles de divulgación. En cierto punto, el problema ya no es si la privacidad sirve, sino si, al superponerse todas esas reglas, el sistema aún puede funcionar exactamente como se espera.
Por poner un ejemplo: si una transferencia de valores activa simultáneamente reglas de restricción de venta, cambios en los derechos de voto y obligaciones de divulgación entre jurisdicciones, el contrato en cadena debe poder comprobar todas las condiciones de restricción en el mismo ciclo de ejecución. Cualquier condición que se pase por alto podría hacer que toda la transacción sea inválida, e incluso provocar un incidente de cumplimiento. En escenarios financieros reales, estas combinaciones de reglas complejas no son un caso raro: son parte del día a día.
Supongo que ahí es donde más he estado poniendo el foco cuando miro a Dusk. Solo con el diagrama de arquitectura todo encaja; lo que de verdad quiero comprobar es si, cuando el flujo de trabajo real empieza a desordenarse y surgen todo tipo de casos límite, el sistema aguanta o no.