9-28 @Dusk あの記事の後半には、実際に泥臭い作業を担う重要なディテールが隠されている。クロスチェーン送金では、2段階のチェックを通らなければならない。DuskEVM上でネイティブ発行された債券をイーサリアム側に移して利用する場合、指示を送るだけでは終わらない。受け取り側でも資格を再チェックする必要があり、手間を省くために送金時の古い認証情報を使い回すことはできない。つまり、通常の送金には通常のチェック、新規発行には別のチェックがあるということだ。新規発行と送金は同じコードではなく、混在させて実行することもできない。

この段階でミスをすると、具体的にどんな代償が生じるのか。チェーンAで100単位をバーンし、チェーンBで100単位を発行しようとしたとき、受取人の認証情報がすでに期限切れなら、チェーンBでの発行は失敗する。しかし、チェーンAの100単位はすでにバーンされているため、その100単位は認証情報が再有効化されるか、運営者がロールバックしてリセットするまで宙に浮く。だからこそDuskのアーキテクチャでは、Citadelのレイヤーをネイティブコントラクトに組み込む必要がある。事後的なパッチでは済まない。認証情報は資産のライフサイクルに結び付いており、送金の瞬間にだけ確認するものではないからだ。

この話をエンジニアリングの視点からプロダクトの視点に移すと、今日、機関が手にするのは「オンチェーンでどれだけ節約できるか」という数字ではない。「一度失敗したら何単位をロールバックするのか」「誰がそのロールバックに署名するのか」「規制当局側ではどう記録するのか」という、3つの現実的な問題だ。ネイティブ発行の本当の競合相手はラップドトークンではなく、スプレッドシートで照合作業をする昔ながらのプロセスだ。

@Duskのこのやり方自体は目新しくない。価値があるのは、CitadelとDuskVMをネイティブコントラクト層に接続している点だ。$DUSK は今日、目立つ存在ではない。しかし、コンプライアンス市場におけるクロスチェーン失敗のコストこそ、機関が実際に対価を払うものだ。

#dusk #原生发行 #跨链失败案例 $DUSK @Dusk