#dusk $DUSK @Dusk Antes, pensé que una transferencia en blockchain solo tenía dos resultados posibles: tiene éxito o falla. El éxito significaba que el valor se movió. El fallo significaba que algo se rompió. Pero cuanto más profundicé en cómo Dusk describe las transferencias de activos regulados, más me di cuenta de que ese modelo es demasiado tosco para los mercados financieros.
En una cadena ordinaria, una transacción rechazada no te dice casi nada. Se acaba el gas, se activa una condición de tipo require, el estado cambia debajo de ti. Quedas adivinando cuál de esas cosas fue.
Para un activo regulado, esa ambigüedad no es aceptable. La documentación de Dusk describe comprobaciones de transferencia que fallan con razones claras y —la parte que me pareció más interesante— comprobaciones que pueden simularse antes de que se envíe una transacción.
Lo particularmente notable de esto es la implicación del segundo punto. Significa que la elegibilidad no es algo que descubres intentando una transferencia y viendo que se rompe. Puedes plantear la pregunta primero y recibir una respuesta, sin tocar el libro mayor en absoluto.
Esto refleja cómo ya funciona el lado tradicional. Un broker no envía una orden y espera que el sistema de cumplimiento la permita. La comprobación ocurre antes, y cuando una operación se rechaza, alguien puede explicar con precisión el motivo: la contraparte no estaba acreditada, el periodo de tenencia no había transcurrido, la jurisdicción estaba restringida. "Rechazada" sin un motivo no es una respuesta utilizable en un proceso regulado.
El fallo se convierte en información, no en un accidente. Y un rechazo que incluye una razón es, con argumentos, más útil que un éxito que no trae ninguna.
Todavía no puedo evaluar qué tan detalladas son esas razones en la práctica, ni cuánto de esto está disponible para una aplicación hoy, en lugar de estar descrito solo como un objetivo de diseño.
A partir de aquí, empecé a ver el diseño de manera diferente. El cumplimiento en cadena quizá no se trate de bloquear transacciones malas. Puede que se trate de hacer el resultado predecible antes de que nadie se comprometa con él.
En una cadena ordinaria, una transacción rechazada no te dice casi nada. Se acaba el gas, se activa una condición de tipo require, el estado cambia debajo de ti. Quedas adivinando cuál de esas cosas fue.
Para un activo regulado, esa ambigüedad no es aceptable. La documentación de Dusk describe comprobaciones de transferencia que fallan con razones claras y —la parte que me pareció más interesante— comprobaciones que pueden simularse antes de que se envíe una transacción.
Lo particularmente notable de esto es la implicación del segundo punto. Significa que la elegibilidad no es algo que descubres intentando una transferencia y viendo que se rompe. Puedes plantear la pregunta primero y recibir una respuesta, sin tocar el libro mayor en absoluto.
Esto refleja cómo ya funciona el lado tradicional. Un broker no envía una orden y espera que el sistema de cumplimiento la permita. La comprobación ocurre antes, y cuando una operación se rechaza, alguien puede explicar con precisión el motivo: la contraparte no estaba acreditada, el periodo de tenencia no había transcurrido, la jurisdicción estaba restringida. "Rechazada" sin un motivo no es una respuesta utilizable en un proceso regulado.
El fallo se convierte en información, no en un accidente. Y un rechazo que incluye una razón es, con argumentos, más útil que un éxito que no trae ninguna.
Todavía no puedo evaluar qué tan detalladas son esas razones en la práctica, ni cuánto de esto está disponible para una aplicación hoy, en lugar de estar descrito solo como un objetivo de diseño.
A partir de aquí, empecé a ver el diseño de manera diferente. El cumplimiento en cadena quizá no se trate de bloquear transacciones malas. Puede que se trate de hacer el resultado predecible antes de que nadie se comprometa con él.