Creo que el diseño crosschain se malinterpreta porque a menudo la gente se enfoca en la velocidad y las comisiones, mientras ignora dónde realmente vive el riesgo.
La mayoría de los puentes dependen de que la liquidez esté en algún lugar esperando para facilitar las transferencias. Eso funciona hasta que la liquidez se vuelve escasa, fragmentada o depende de un conjunto reducido de actores que se comportan como se espera.
El modelo CCT de Dusk toma una ruta diferente. En lugar de pasar por un pool, el activo se retira de la circulación en una cadena y se recrea en otra mediante un proceso de burn-and-mint.
El intercambio (tradeoff) es interesante.
No dependes de la liquidez disponible ni te preocupas por el deslizamiento. Pero eso no hace que el sistema sea libre de riesgos. La suposición crítica cambia a si el evento de quemado se verifica correctamente y si el proceso de acuñación (mint) se ejecuta como se pretende a través de las cadenas.
En otras palabras, la pregunta ya no es “¿Hay suficiente capital del otro lado?”
Se convierte en “¿Puede el sistema demostrar con certeza que la oferta fue destruida antes de que aparezca una nueva oferta en otro lugar?”
Eso se siente menos como un problema de liquidez y más como un problema de coordinación y de finalización (finality).
Me interesa cómo Dusk maneja casos límite donde un lado llega a la confirmación final, pero la acuñación correspondiente permanece retrasada o se interrumpe.
#dusk @Dusk $DUSK
La mayoría de los puentes dependen de que la liquidez esté en algún lugar esperando para facilitar las transferencias. Eso funciona hasta que la liquidez se vuelve escasa, fragmentada o depende de un conjunto reducido de actores que se comportan como se espera.
El modelo CCT de Dusk toma una ruta diferente. En lugar de pasar por un pool, el activo se retira de la circulación en una cadena y se recrea en otra mediante un proceso de burn-and-mint.
El intercambio (tradeoff) es interesante.
No dependes de la liquidez disponible ni te preocupas por el deslizamiento. Pero eso no hace que el sistema sea libre de riesgos. La suposición crítica cambia a si el evento de quemado se verifica correctamente y si el proceso de acuñación (mint) se ejecuta como se pretende a través de las cadenas.
En otras palabras, la pregunta ya no es “¿Hay suficiente capital del otro lado?”
Se convierte en “¿Puede el sistema demostrar con certeza que la oferta fue destruida antes de que aparezca una nueva oferta en otro lugar?”
Eso se siente menos como un problema de liquidez y más como un problema de coordinación y de finalización (finality).
Me interesa cómo Dusk maneja casos límite donde un lado llega a la confirmación final, pero la acuñación correspondiente permanece retrasada o se interrumpe.
#dusk @Dusk $DUSK