страница собственных основных компонентов docs.dusk.network упоминает «native bridging» как часть duskds, соединяющую duskevm и duskvm с базовым уровнем. это уже третье, что я теперь нашёл в стеке dusk, и что называется «bridge». я сходил и в действительности подтвердил, является ли это тем же механизмом, который задело в январе — и честно говоря, я почти предположил, что так и есть, учитывая насколько свободно везде используется слово «bridge», — но нет. пост о многослойной архитектуре самой dusk описывает именно этот вариант как «validator-run, native and trustless, no external custodians or wrapped assets required», а уведомление о инциденте за январь напрямую отсылает к старому адресу bep20 bridge — совершенно другому механизму, кастодиальному по своей природе, для переноса wrapped dusk в bsc.

итак, подтверждено три отдельных моста: внутренний duskds-to-duskevm native bridge, внешний bep20/bsc bridge, по которому попали, и цепочка chainlink cct pathway для eth-solana. все реальны, все разные, все используют слово «bridge», и нигде их не различают названиями.

я не думаю, что это обман со стороны dusk: модульным архитектурам действительно нужны несколько уровней «связывания» для разных задач. я просто считаю, что фраза «у bridge от dusk был инцидент» даёт слишком точное утверждение без оснований для предложения, которое может означать три разных вещи — в зависимости от того, о каком именно мосте речь.

есть ли у dusk где-то одна страница, которая называет и отличает все три по именам в одном месте? 🧐
#dusk $DUSK @Dusk