La propuesta de las "unified workflows" (flujos de trabajo unificados) me hizo imaginar un único conducto continuo: emitir, intercambiar, liquidar todo dentro de un solo entorno de ejecución. Lo que encontré en cambio fue algo más parecido a un conjunto de etapas especificadas por separado que, aun así, comparten una capa de liquidación. DUSK, $DUSK , #dusk , @Dusk Foundation contempla la emisión de marcos, la transferencia de propiedad, las comprobaciones de cumplimiento y la liquidación final como pasos distintos, cada uno con su propio módulo o lógica de contrato, que convergen en el mismo libro mayor base en lugar de ejecutarse a través de un único motor de flujos de trabajo compartido. La unificación es realmente a nivel de la finalidad de la liquidación, no a nivel del proceso: las transacciones de Phoenix y Moonlight se resuelven en la misma cadena, pero la lógica de cumplimiento que rige un activo aguas arriba se configura por emisión; es decir, dos tokens pueden atravesar conjuntos de reglas bastante diferentes antes de tocar siquiera las mismas garantías de liquidación. Al principio leí "unified" como que significaba un comportamiento estandarizado de principio a fin, y tuve que revisarlo para algo más cercano a "estado final compartido, rutas divergentes para llegar allí". No es un mal diseño; de hecho, quizá sea más realista dada la variedad de activos regulados, pero eso significa que la coherencia vive en la parte baja de la pila, no en la parte superior. Todavía estoy resolviendo si esa distinción importa mucho para un usuario final, o solo para quien esté construyendo encima de ello.
#dusk $DUSK @Dusk