La página de componentes base de “docs.dusk.network” menciona “native bridging” como parte de duskds, conectando duskevm y duskvm con la capa base. esa es la tercera cosa que ahora encuentro llamada “bridge” en el stack de dusk. fui y confirmé si es el mismo mecanismo que recibió el impacto en enero — y honestamente casi asumí que sí, dado lo suelto que se usa “bridge” en todas partes — pero no lo es. la publicación de la propia arquitectura multicapa de dusk describe esta como específicamente “validator-run, native and trustless, no external custodians or wrapped assets required”, mientras que el aviso del incidente de enero se relaciona directamente con la antigua dirección del puente bep20, un mecanismo completamente distinto, de estilo custodial, para mover dusk envuelto hacia bsc.
así que hay tres puentes separados confirmados: el puente nativo interno de duskds hacia duskevm, el puente externo bep20/bsc que recibió el ataque, y la vía de cct de chainlink para eth-solana. todo real, todo distinto, todos comparten la palabra “bridge” sin que los identifique con nombres en ninguna parte que haya encontrado.
no creo que dusk esté siendo engañoso; las arquitecturas modulares genuinamente necesitan múltiples capas de puente para distintos trabajos. solo que decir “el puente de dusk tuvo un incidente” está haciendo una precisión no ganada para una frase que podría significar tres cosas distintas según cuál de ellas te refieras.
hay alguna página de dusk que, en un solo lugar, nombre y distinga a las tres por su nombre? 🧐
#dusk $DUSK @Dusk