9-28 @Dusk En la segunda parte de ese artículo se esconde un detalle de trabajo realmente “sucio”: las transferencias entre cadenas deben pasar por dos controles. Una orden de un bono emitido nativamente en DuskEVM hay que moverla hacia el lado de Ethereum; pero no basta con enviar la instrucción, del otro lado también hay que rehacer una verificación de elegibilidad. No se puede ahorrar tiempo usando los viejos justificantes de la transferencia para pasarlo. Estas son las dos líneas: la verificación para una transferencia normal es un conjunto, la verificación para una emisión adicional es otro. El código de la nueva acuñación no es el mismo que el de la transferencia; no se pueden mezclar.
El costo concreto de tropezar aquí es este: en la cadena A se consumen 100 unidades preparadas para acuñar 100 unidades en la cadena B. Si el justificante que tiene el receptor ya está vencido, la acuñación en la cadena B fallará, pero esas 100 unidades ya se quemaron en la cadena A. Esas 100 unidades quedan “pendientes” hasta que el justificante se reactive o que el equipo de operaciones haga un rollback y reinicio. Por eso, en la arquitectura de Dusk, la capa Citadel debe escribirse en el contrato nativo, no como un parche posterior. Los justificantes están vinculados al ciclo de vida de los activos, no a una comprobación en el instante de la transferencia.
Al trasladar este asunto desde la perspectiva de ingeniería a la de producto, lo que una institución recibe hoy no es el número de “cuánto se puede ahorrar en la cadena”, sino estos tres problemas reales: “cuántas unidades hay que revertir si falla una vez”, “quién firma esa reversión” y “cómo se registra en el lado de la supervisión”. El verdadero rival de la emisión nativa no son los tokens tipo envoltorio, sino ese flujo antiguo de conciliación con hojas de cálculo.
@Dusk Este enfoque no es nuevo, lo valioso es que conecta Citadel y DuskVM directamente en la capa de contratos nativos. $DUSK no llama la atención hoy, pero el costo de fallos de interoperabilidad en un mercado regulado es el dinero que, en realidad, termina pagando una institución.
#dusk #原生发行 #跨链失败案例 $DUSK @Dusk
El costo concreto de tropezar aquí es este: en la cadena A se consumen 100 unidades preparadas para acuñar 100 unidades en la cadena B. Si el justificante que tiene el receptor ya está vencido, la acuñación en la cadena B fallará, pero esas 100 unidades ya se quemaron en la cadena A. Esas 100 unidades quedan “pendientes” hasta que el justificante se reactive o que el equipo de operaciones haga un rollback y reinicio. Por eso, en la arquitectura de Dusk, la capa Citadel debe escribirse en el contrato nativo, no como un parche posterior. Los justificantes están vinculados al ciclo de vida de los activos, no a una comprobación en el instante de la transferencia.
Al trasladar este asunto desde la perspectiva de ingeniería a la de producto, lo que una institución recibe hoy no es el número de “cuánto se puede ahorrar en la cadena”, sino estos tres problemas reales: “cuántas unidades hay que revertir si falla una vez”, “quién firma esa reversión” y “cómo se registra en el lado de la supervisión”. El verdadero rival de la emisión nativa no son los tokens tipo envoltorio, sino ese flujo antiguo de conciliación con hojas de cálculo.
@Dusk Este enfoque no es nuevo, lo valioso es que conecta Citadel y DuskVM directamente en la capa de contratos nativos. $DUSK no llama la atención hoy, pero el costo de fallos de interoperabilidad en un mercado regulado es el dinero que, en realidad, termina pagando una institución.
#dusk #原生发行 #跨链失败案例 $DUSK @Dusk
