Estaba leyendo la documentación de la infraestructura de mercado de Dusk y me quedaba atascado en la parte del pago. Transferir un activo por sí solo es bastante fácil de imaginar. Lo problemático empieza cuando el pago tiene que coincidir con eso.
Dusk trata la Entrega contra Pago como un problema de flujo de trabajo más que como una simple transferencia más de tokens. La pata de activos y la pata de pagos pueden coordinarse a través de las rutas de ejecución de Dusk, mientras que DuskDS proporciona la liquidación y la finalidad determinista que hay debajo. Eso significa que la parte interesante no es realmente poner ambos activos en la misma cadena. Es lograr que ambos cambios de estado se liquiden de forma predecible.
Me gusta la idea, pero también creo que es fácil exagerar lo que el protocolo está haciendo aquí.
Dusk proporciona los bloques de construcción para esta coordinación. La aplicación real todavía tiene que definir cómo encajan entre sí las condiciones de activos, pagos, elegibilidad y liquidación. La propia documentación de Dusk es bastante explícita en que distintos productos pueden implementar el flujo de trabajo de formas diferentes.
Esto importa porque el DvP puede parecer engañosamente simple desde fuera. Mueves la seguridad, mueves el pago, y lo llamas liquidado. En un flujo de trabajo regulado real hay más condiciones alrededor de esas dos patas.
Así que no diría que Dusk haya eliminado de alguna manera el problema de la coordinación. Lo que ha hecho es trasladar la coordinación a una base de liquidación común con finalidad determinista.
Lo que aún me gustaría inspeccionar en una implementación real es algo bastante concreto: cuando una de las patas falla sus condiciones a nivel de aplicación, ¿qué estado exacto conserva la otra pata y qué tan rápido puede el flujo de trabajo desmontarse de forma segura?
#dusk $DUSK @Dusk $ACE
Dusk trata la Entrega contra Pago como un problema de flujo de trabajo más que como una simple transferencia más de tokens. La pata de activos y la pata de pagos pueden coordinarse a través de las rutas de ejecución de Dusk, mientras que DuskDS proporciona la liquidación y la finalidad determinista que hay debajo. Eso significa que la parte interesante no es realmente poner ambos activos en la misma cadena. Es lograr que ambos cambios de estado se liquiden de forma predecible.
Me gusta la idea, pero también creo que es fácil exagerar lo que el protocolo está haciendo aquí.
Dusk proporciona los bloques de construcción para esta coordinación. La aplicación real todavía tiene que definir cómo encajan entre sí las condiciones de activos, pagos, elegibilidad y liquidación. La propia documentación de Dusk es bastante explícita en que distintos productos pueden implementar el flujo de trabajo de formas diferentes.
Esto importa porque el DvP puede parecer engañosamente simple desde fuera. Mueves la seguridad, mueves el pago, y lo llamas liquidado. En un flujo de trabajo regulado real hay más condiciones alrededor de esas dos patas.
Así que no diría que Dusk haya eliminado de alguna manera el problema de la coordinación. Lo que ha hecho es trasladar la coordinación a una base de liquidación común con finalidad determinista.
Lo que aún me gustaría inspeccionar en una implementación real es algo bastante concreto: cuando una de las patas falla sus condiciones a nivel de aplicación, ¿qué estado exacto conserva la otra pata y qué tan rápido puede el flujo de trabajo desmontarse de forma segura?
#dusk $DUSK @Dusk $ACE