la page des propres composants centraux de docs.dusk.network mentionne « le native bridging » comme faisant partie de duskds, reliant duskevm et duskvm à la couche de base. c’est la troisième chose que j’ai maintenant trouvée appelée « bridge » dans la pile de dusk. je suis allé(e) et j’ai effectivement confirmé s’il s’agissait du même mécanisme que celui qui a été touché en janvier — et honnêtement, je me suis presque dit que oui, vu à quel point « bridge » est utilisé de façon lâche partout — mais non. le billet sur l’architecture multi-couches de dusk décrit précisément celui-ci comme « validator-run, native and trustless, no external custodians or wrapped assets required », tandis que l’avis d’incident de janvier fait directement le lien avec l’ancienne adresse de pont bep20, un mécanisme complètement différent, de type custodial, pour transférer du dusk enveloppé vers bsc.
soit trois ponts distincts confirmés : le pont natif interne duskds-to-duskevm, le pont externe bep20/bsc qui a été touché, et le chemin cct de chainlink pour eth-solana. tous réels, tous distincts, tous partageant le mot « bridge » sans que rien ne les distingue par un nom quelque part dans tout ce que j’ai trouvé.
je ne pense pas que dusk trompe volontairement. les architectures modulaires ont réellement besoin de plusieurs couches de bridging pour des tâches différentes. je pense juste que « le bridge de dusk a eu un incident » apporte une précision injustifiée pour une phrase qui pourrait vouloir dire trois choses différentes selon celui dont on parle.
dusk a-t-il une page unique quelque part qui nomme et distingue les trois, chacun par son nom, en un seul endroit ? 🧐
#dusk $DUSK @Dusk