a página dos próprios componentes principais do docs.dusk.network menciona "native bridging" como parte do duskds, conectando duskevm e duskvm à camada base. essa é a terceira coisa que eu agora encontrei chamada de "bridge" na pilha do dusk. fui e confirmei se é o mesmo mecanismo que foi atingido em janeiro — e, sinceramente, quase presumi que fosse, dado o modo como "bridge" é usado de forma tão solta por toda parte — mas não é. o post sobre a arquitetura multi-layer do próprio dusk descreve essa aqui especificamente como "validator-run, native and trustless, no external custodians or wrapped assets required", enquanto o aviso de incidente de janeiro remete diretamente ao antigo endereço de bridge bep20, um mecanismo completamente diferente, estilo custódia, para mover dusk embrulhado para a bsc.
então são três bridges separados confirmados: o bridge nativo interno duskds-to-duskevm, o bridge externo bep20/bsc que foi atingido e o caminho de cct do chainlink para eth-solana. tudo real, tudo distinto, todos compartilhando a palavra "bridge" sem nada que os diferencie pelo nome em qualquer lugar que eu tenha encontrado.
não acho que isso seja o dusk sendo enganoso; arquiteturas modulares realmente precisam de múltiplas camadas de bridging para tarefas diferentes. eu só acho que "o bridge do dusk teve um incidente" está colocando uma precisão não garantida demais para uma frase que pode significar três coisas diferentes dependendo de qual delas você quer dizer.
o dusk tem alguma página única em algum lugar que nomeie e diferencie os três pelo nome em um só lugar? 🧐
#dusk $DUSK @Dusk