二度見したのは「ZKスタック」ではありません。遮蔽（シールド）されたトランザクションが成功したかどうか分からないとき、ウォレットが何をするか——その夕闇のディテールです。
Dusk Wallet v0.1.0では、Phoenixトランザクションに「pending-nullifier reservation（保留中のnullifier予約）」の追跡が追加されました。変更履歴には、これらの予約はウォッチャーのタイムアウト、未知のステータス、削除されたステータス、あるいはメモリプールのポーリングが1回だけ欠けた場合には、自動的に解放されないと書かれています。
不確実性の後でも資金を意図的に拘束するのはなぜでしょう？
理由は、Phoenixはノートを消費するからです。もしウォレットが、最初のトランザクションがまだ着地する可能性がある間に、同じ「支払い可能なノート集合」をすぐに再利用してしまうと、互いに衝突する遮蔽された消費（shielded spends）を構築してしまうかもしれません。Duskはまた、同じノートに対して競合するPhoenix送信が同時に組み立てられないようにするための「spend mutex」も追加しました。
事実：これはウォレット側の安全性ロジックであって、新しいコンセンサス（合意）ルールではありません。私の解釈では、Duskはトランザクション状態が曖昧なとき、残高の可用性を楽観的に提供するよりも、保守的なUXを選んでいます。
そのトレードオフは重要です。プライバシー・システムには強力な暗号だけでは足りません。ネットワークの見通しが不完全な場合でも、ウォレットの状態管理は安全である必要があります。
DUSKでは、今後のウォレットリリースがその「不確実」な期間を、保護を弱めることなく短縮できるかを見ています。チェーン状態が不明なとき、プライバシーウォレットはどれほど積極的に資金をアンロックすべきでしょう？
@Dusk $DUSK #dusk
Dusk Wallet v0.1.0では、Phoenixトランザクションに「pending-nullifier reservation（保留中のnullifier予約）」の追跡が追加されました。変更履歴には、これらの予約はウォッチャーのタイムアウト、未知のステータス、削除されたステータス、あるいはメモリプールのポーリングが1回だけ欠けた場合には、自動的に解放されないと書かれています。
不確実性の後でも資金を意図的に拘束するのはなぜでしょう？
理由は、Phoenixはノートを消費するからです。もしウォレットが、最初のトランザクションがまだ着地する可能性がある間に、同じ「支払い可能なノート集合」をすぐに再利用してしまうと、互いに衝突する遮蔽された消費（shielded spends）を構築してしまうかもしれません。Duskはまた、同じノートに対して競合するPhoenix送信が同時に組み立てられないようにするための「spend mutex」も追加しました。
事実：これはウォレット側の安全性ロジックであって、新しいコンセンサス（合意）ルールではありません。私の解釈では、Duskはトランザクション状態が曖昧なとき、残高の可用性を楽観的に提供するよりも、保守的なUXを選んでいます。
そのトレードオフは重要です。プライバシー・システムには強力な暗号だけでは足りません。ネットワークの見通しが不完全な場合でも、ウォレットの状態管理は安全である必要があります。
DUSKでは、今後のウォレットリリースがその「不確実」な期間を、保護を弱めることなく短縮できるかを見ています。チェーン状態が不明なとき、プライバシーウォレットはどれほど積極的に資金をアンロックすべきでしょう？
@Dusk $DUSK #dusk