Dusk Hyperlaneの制作上のサインオフで印象に残るフレーズがあります。それは「admin recovery pathがない」。
これはクリーンな信頼最小化の選択のように聞こえます。保留中のエスクローを吸い上げたりリダイレクトしたりできる特権的な管理者キーがないなら、介入の可能な明確な源泉が1つ消えます。
しかし同時に、それによって、正当な資金が詰まったときに介入するための明白な手段も1つ失われます。これは重要です。Duskは、EUライセンスを持つ機関とともにオンチェーンで金融市場を扱おうとしており、送金が詰まることは単なる技術的な例外ではなく、インフラが支える必要がある運用上の信頼性の一部だからです。
私がまだ分かっていないのは、Dusk Hyperlaneが特権的な広範な管理を取り除きつつ、それでも正当な失敗から復旧するための狭く決定論的な手段を維持できるのか、それとも一部のミスが単に恒久的なロックアップになってしまうのか、という点です。
注目すべき詳細はかなり具体的です。recipient（受取人）の一致による回復、鍵を失ったケース、そして誤ったrecipientまたはハッシュデータ。
adminの脱出用の抜け道がないことは、特権的な統制が減らされたことを示す有用な証拠です。ですが、何か問題が起きたときに資金が回復可能なままでいるかどうかの証拠としては弱いです。
設計を評価する際は、adminが介入できるかどうかよりも、正当な回復に関して、広範な裁量的統制を再び開くことなく、予測可能な道筋が残っているかどうかで判断すべきだと思います。
回復権限を取り除くことは、ある信頼前提を減らす一方で、別の失敗モードをより不可逆にする可能性があります。
ポイントは、Dusk Hyperlaneが、回復可能なミスを恒久的な状態に変えてしまうことなく、特権的な回復を最小化できるかどうかです。
私は、pending-escrow（保留中のエスクロー）の回復設計を注視しています。特に、Duskが失われた鍵や誤ったrecipientデータをどう扱うかです。

@Dusk $DUSK #dusk