Ich habe heute einen kleinen Transfer getestet: DUSK von DuskEVM zurück zu DuskDS, größtenteils weil mich dieses Spin-Time-Thema letzte Woche paranoid gemacht hat, irgendeiner Bridge blind zu vertrauen.
Stellt sich heraus: „die Bridge“ ist nicht eine Sache. DUSK läuft über einen validator-geführten nativen Pfad, ohne eine Wrapped-Version, und mit demselben Token auf beiden Seiten. Wertpapiere, die auf DuskEVM über die NPEX-Route ausgegeben werden, laufen über Chainlink CCIP ab – ein völlig separates System.
Ich nahm an, das bedeutet zwei Varianten derselben Garantie, tbh, beide werden als keine Verwahrung, kein synthetischer Asset vermarktet. Wirkte wie ein Detail, nicht wie eine echte Unterscheidung.
Doch so war es nicht. Dass es zwei Routen gibt, liegt an der Geografie. Es ist keine Koordination. Die native Strecke stützt sich auf Dusk-eigene Validatoren, CCIP auf das eigene Netzwerk von Chainlink – und keine dieser Annahmen lässt sich auf die andere übertragen.
Außer: Beide starten am selben Ort. Alles auf DuskEVM klärt zuerst den Sequencer, und davor gibt es keinen öffentlichen Mempool, den man prüfen könnte. Ein Operator ordnet einfach alles an, bevor eine der beiden Bridges es überhaupt sieht.
Ich weiß nicht, was darüber öffentlich dokumentiert ist, wie man diesen Teil dezentralisiert.
Das NPEX-Volumen über CCIP ist inzwischen real, DuskEVM-Traffic steigt weiter 👍. Wenn dieser Sequencer mitten im Batch ins Stocken gerät: verschlechtert sich dann ein Pfad, während der andere weiterläuft, oder sitzen beide einfach fest?
#dusk $DUSK @Dusk
Stellt sich heraus: „die Bridge“ ist nicht eine Sache. DUSK läuft über einen validator-geführten nativen Pfad, ohne eine Wrapped-Version, und mit demselben Token auf beiden Seiten. Wertpapiere, die auf DuskEVM über die NPEX-Route ausgegeben werden, laufen über Chainlink CCIP ab – ein völlig separates System.
Ich nahm an, das bedeutet zwei Varianten derselben Garantie, tbh, beide werden als keine Verwahrung, kein synthetischer Asset vermarktet. Wirkte wie ein Detail, nicht wie eine echte Unterscheidung.
Doch so war es nicht. Dass es zwei Routen gibt, liegt an der Geografie. Es ist keine Koordination. Die native Strecke stützt sich auf Dusk-eigene Validatoren, CCIP auf das eigene Netzwerk von Chainlink – und keine dieser Annahmen lässt sich auf die andere übertragen.
Außer: Beide starten am selben Ort. Alles auf DuskEVM klärt zuerst den Sequencer, und davor gibt es keinen öffentlichen Mempool, den man prüfen könnte. Ein Operator ordnet einfach alles an, bevor eine der beiden Bridges es überhaupt sieht.
Ich weiß nicht, was darüber öffentlich dokumentiert ist, wie man diesen Teil dezentralisiert.
Das NPEX-Volumen über CCIP ist inzwischen real, DuskEVM-Traffic steigt weiter 👍. Wenn dieser Sequencer mitten im Batch ins Stocken gerät: verschlechtert sich dann ein Pfad, während der andere weiterläuft, oder sitzen beide einfach fest?
#dusk $DUSK @Dusk