Fui a ver el diseño de activos regulados de Dusk y seguí volviendo a un detalle: las obligaciones del mundo real rara vez se tratan solo de la propiedad.
La elegibilidad puede cambiar. Pueden aplicarse límites de transferencia. Puede que se requieran informes. Es posible que deba existir un proceso de recuperación. La liquidación puede depender de condiciones fuera de un simple saldo de una billetera.
Eso me hizo mirar a Dusk de forma diferente.
El modelo de cuenta importa porque las obligaciones pueden representarse como cambios de estado en lugar de gestionarse por completo mediante un proceso externo. La arquitectura de privacidad importa por una razón distinta. La información confidencial puede seguir protegida mientras la divulgación selectiva ofrece una forma controlada de probar algo cuando sea necesario.
Luego está el propio flujo de trabajo del activo regulado. Si las reglas de elegibilidad y las restricciones de transferencia se tratan como parte de la lógica de la transacción, entonces el cumplimiento ya no es solo un documento que se queda al lado del libro mayor. Parte de él puede volverse exigible a través del libro mayor.
Lo que me pareció interesante es la tensión que esto crea.
La automatización en cadena solo es útil cuando las reglas son lo bastante precisas como para ejecutarse. Las obligaciones del mundo real a menudo son condicionales y las excepciones son comunes. La recuperación es especialmente difícil porque revertir una liquidación no es lo mismo que revertir una entrada de base de datos.
Así que el verdadero desafío de infraestructura no es simplemente poner valores onchain. Es traducir obligaciones legales y operativas a transiciones de estado sin pretender que toda situación del mundo real se puede reducir a código.
Ahí es donde la arquitectura de Dusk se vuelve más interesante para mí.
Lo difícil quizá no sea la privacidad ni la liquidación por sí mismas. Podría ser diseñar el límite entre lo que el protocolo puede hacer cumplir y lo que todavía requiere intervención humana o institucional de confianza.#dusk $DUSK @Dusk
La elegibilidad puede cambiar. Pueden aplicarse límites de transferencia. Puede que se requieran informes. Es posible que deba existir un proceso de recuperación. La liquidación puede depender de condiciones fuera de un simple saldo de una billetera.
Eso me hizo mirar a Dusk de forma diferente.
El modelo de cuenta importa porque las obligaciones pueden representarse como cambios de estado en lugar de gestionarse por completo mediante un proceso externo. La arquitectura de privacidad importa por una razón distinta. La información confidencial puede seguir protegida mientras la divulgación selectiva ofrece una forma controlada de probar algo cuando sea necesario.
Luego está el propio flujo de trabajo del activo regulado. Si las reglas de elegibilidad y las restricciones de transferencia se tratan como parte de la lógica de la transacción, entonces el cumplimiento ya no es solo un documento que se queda al lado del libro mayor. Parte de él puede volverse exigible a través del libro mayor.
Lo que me pareció interesante es la tensión que esto crea.
La automatización en cadena solo es útil cuando las reglas son lo bastante precisas como para ejecutarse. Las obligaciones del mundo real a menudo son condicionales y las excepciones son comunes. La recuperación es especialmente difícil porque revertir una liquidación no es lo mismo que revertir una entrada de base de datos.
Así que el verdadero desafío de infraestructura no es simplemente poner valores onchain. Es traducir obligaciones legales y operativas a transiciones de estado sin pretender que toda situación del mundo real se puede reducir a código.
Ahí es donde la arquitectura de Dusk se vuelve más interesante para mí.
Lo difícil quizá no sea la privacidad ni la liquidación por sí mismas. Podría ser diseñar el límite entre lo que el protocolo puede hacer cumplir y lo que todavía requiere intervención humana o institucional de confianza.#dusk $DUSK @Dusk