Halaman “docs.dusk.network” tentang komponen inti milik mereka menyebut “native bridging” sebagai bagian dari duskds, yang menghubungkan duskevm dan duskvm ke lapisan dasar. Itu adalah hal ketiga yang sekarang sudah aku temukan yang disebut “bridge” dalam tumpukan (stack) Dusk. Aku lalu benar-benar memastikan apakah mekanisme itu sama dengan yang terkena dampak pada Januari—dan jujur saja, aku hampir mengira itu sama, mengingat betapa longgarnya kata “bridge” dipakai di mana-mana—tapi ternyata tidak. Post arsitektur multi-lapisan milik Dusk menjelaskan yang ini secara spesifik sebagai “validator-run, native and trustless, no external custodians or wrapped assets required,” sementara pemberitahuan insiden dari Januari merujuk langsung ke alamat bridge lama bep20, mekanisme yang benar-benar berbeda—gaya kustodian (custodial-style)—untuk memindahkan wrapped dusk ke bsc.
Jadi, ada tiga bridge terpisah yang sudah terkonfirmasi: bridge internal duskds-ke-duskevm yang native, bridge eksternal bep20/bsc yang terkena, dan jalur chainlink cct untuk eth-solana. Semua nyata, semuanya berbeda, semuanya berbagi kata “bridge” tanpa ada pembeda bernama apa pun di mana pun yang sudah aku temukan.
Aku tidak berpikir Dusk itu menipu—arsitektur modular memang benar-benar membutuhkan beberapa lapisan bridging untuk pekerjaan yang berbeda. Aku hanya merasa “bridge Dusk punya insiden” memberikan ketepatan yang berlebihan untuk kalimat yang bisa berarti tiga hal berbeda, tergantung yang mana yang kamu maksud.
Apakah Dusk punya satu halaman saja di mana mereka menyebutkan dan membedakan ketiga hal itu dengan nama di satu tempat? 🧐
#dusk $DUSK @Dusk