docs.dusk.networkの「duskdsの一部としてnative bridging（ネイティブブリッジ）」が、duskevmとduskvmをベースレイヤーに接続すると書かれている同社のコアコンポーネントのページについて触れていました。これが、duskのスタック内で「ブリッジ」と呼ばれているものとして、私が今までに見つけた3つ目の呼称です。実際に、これは1月に攻撃されたものと同じ仕組みなのかを確かめに行きました。正直、そうだろうとほぼ思っていました。どこでも「bridge（ブリッジ）」という語がかなり曖昧に使われているので。でも違いました。dusk自身のマルチレイヤーアーキテクチャの投稿では、このブリッジを「validator-run（バリデータが実行する）、native（ネイティブ）、trustless（信頼不要）、外部のカストディアンやラップド資産は不要」と具体的に説明しています。一方、1月のインシデント通知は、BEP20の古いブリッジアドレスに直接結びついており、bscへラップされたduskを移すための全く別の、カストディ型の仕組みです。
つまり確認できた「ブリッジ」は3つあります。内部のduskds-to-duskevmネイティブブリッジ、攻撃を受けた外部のbep20/bscブリッジ、そしてeth-solanaのためのchainlink cctパスウェイです。どれも実在し、互いに別物であり、また「bridge」という単語を共有しています。私が見つけた範囲では、どれがどれかを名前で区別する決定的な手がかりがありません。
duskが意図的に誤解を招いているとは思いません。モジュール型アーキテクチャには、仕事ごとに複数のブリッジレイヤーが必要なのだと思います。ただ「duskのブリッジにインシデントがあった」と言うのは、意味が3通りに分かれてしまう可能性がある文に対して、獲得されていないほどの精度を与えてしまっているだけだと思います。
duskは、どこかにある1つのページで、3つすべてを名前で挙げて区別している場所があるのでしょうか？ 🧐
#dusk $DUSK @Dusk