かつて、清掃担当者が委託先の資金を見失ってしまったのを見たことがあります。システムが2つの台帳を同期できなかったせいで。

友人の会社は、機関投資家のために公的資産と私的資産の両方を管理していました。ある日、変換が途中で失敗しました。資金は私的台帳から出ていったのに、公的台帳には届きません。システムは「残高が釣り合っている」状態を表示しているのに、お金はどこにもありませんでした。ほどくのに3週間かかったそうです。💀

この記憶が、Duskのデュアルステート・モデルについて読んだときに、別の意味で刺さりました。

アーキテクチャはこうです：公的な送金はMoonlight。私的で秘匿されたノートはPhoenix。どちらも同じチェーンに決済します。Transfer Contractが価値の移動を調整。

きれいでしょ？

でも、ドキュメントが触れていない「穴」があります。状態間の変換がアトミックではないこと。

例えばこう想像してみてください：

· 機関は両ステートにまたがって合計1M DUSKを保有（公的500k、私的500k）
· PhoenixからMoonlightへ200kの変換を開始
· Phoenixノートが消費される
· Moonlight側へのクレジットが失敗、または遅延する
· 総供給が一時的に減少する。200kがシステムから消える

攻撃者は監視して、消費されたノートを検知し、Moonlightがクレジットされていないのを確認する。そのギャップを突いて、Moonlightの残高だけを定期照会している取引所から資金を引き出す。

どちらのステートにも存在しない資金、あるいは両方に存在する資金。

対策は？ZKプローフを備えたUnified State Aggregator（統一ステート集約）。2つのモデルにまたがる保有総額を、個々の取引を明かさずに統一的に提示します。管理者が正確性を検証。同期ギャップなし。裁定取引の余地なし。

$DUSK は実際に規制されたインフラを作っている。でも、アトミックな変換なしのデュアルステート？それは保管（カストディ）に対する時限爆弾です。

Duskは、最初の悪用が起きる前にステート分裂を解決できるのでしょうか？ 🤔@Dusk #dusk $BMT $TAC