#dusk $DUSK @Dusk
He estado pensando en el diseño post-contratación de Dusk de una manera un poco diferente después de leer el material sobre el ciclo de vida. Antes pensaba que la conformidad programable se trataba sobre todo de asegurarse de que una operación esté permitida antes de que ocurra. Pero la pregunta más difícil parece comenzar después de la operación, cuando la titularidad, los derechos de voto, la elegibilidad para dividendos y el estado de cumplimiento tienen que mantenerse correctos.
Eso hace que la idea de que el cumplimiento se vuelva programable sea bastante útil, pero también ligeramente incómoda. El código puede hacer cumplir una regla de forma consistente. No puede saber automáticamente qué hacer cuando la situación del mundo real detrás de esa regla cambia o no encaja con las suposiciones en las que se construyó. Si la elegibilidad de un titular cambia, o si alguna condición regulatoria requiere una excepción, tiene que haber un mecanismo para gestionar ese estado en lugar de simplemente confiar en la lógica original.
Ahí es donde creo que Dusk resulta más interesante que solo tokenizar un activo. El propio token es casi la capa más sencilla. El problema más difícil es mantener el registro preciso a medida que siguen ocurriendo operaciones. Pero aún me queda la duda sobre la capa de anulación. ¿Quién es realmente confiable para intervenir cuando las reglas codificadas producen el resultado incorrecto, y cómo evitas que esa autoridad se convierta en el punto más débil en un sistema por lo demás programable?
He estado pensando en el diseño post-contratación de Dusk de una manera un poco diferente después de leer el material sobre el ciclo de vida. Antes pensaba que la conformidad programable se trataba sobre todo de asegurarse de que una operación esté permitida antes de que ocurra. Pero la pregunta más difícil parece comenzar después de la operación, cuando la titularidad, los derechos de voto, la elegibilidad para dividendos y el estado de cumplimiento tienen que mantenerse correctos.
Eso hace que la idea de que el cumplimiento se vuelva programable sea bastante útil, pero también ligeramente incómoda. El código puede hacer cumplir una regla de forma consistente. No puede saber automáticamente qué hacer cuando la situación del mundo real detrás de esa regla cambia o no encaja con las suposiciones en las que se construyó. Si la elegibilidad de un titular cambia, o si alguna condición regulatoria requiere una excepción, tiene que haber un mecanismo para gestionar ese estado en lugar de simplemente confiar en la lógica original.
Ahí es donde creo que Dusk resulta más interesante que solo tokenizar un activo. El propio token es casi la capa más sencilla. El problema más difícil es mantener el registro preciso a medida que siguen ocurriendo operaciones. Pero aún me queda la duda sobre la capa de anulación. ¿Quién es realmente confiable para intervenir cuando las reglas codificadas producen el resultado incorrecto, y cómo evitas que esa autoridad se convierta en el punto más débil en un sistema por lo demás programable?