#dusk $DUSK @Dusk A Zedger送金は「送信」を押しても完了しません——受信者側に、完了するための役割がまだ残っています。
DuskのZedger設計では、SEND操作は受信者のために資産移転を即座に確定させません。受信者は、その移転が利用可能残高の一部になる前に、明示的にACCEPT(承諾)する必要があります。
これにより、所有権の移動は単一の行動ではなく、制御されたライフサイクルになるという興味深い設計上の選択が生まれます。
SENDは保留中の送金を作成します。ACCEPTは受信者側を完了させます。もし承諾が行われなければ、プロトコルには、送金状態を未解決のままにしておくのではなく、定義された期限切れの経路があります。
重要な示唆は、Zedgerが「送金の開始」と「送金の確定」を分離していることです。これは制御性を高めますが、その一方で、ユーザーやアプリケーションが送金状態を注意深く扱う必要も意味します。
仕組みは明確です。
次に気になるのは、こうした保留状態が実際のネットワーク活動の中でどれくらい頻繁に現れるのか、という点です。
@Dusk_Foundation $DUSK
DuskのZedger設計では、SEND操作は受信者のために資産移転を即座に確定させません。受信者は、その移転が利用可能残高の一部になる前に、明示的にACCEPT(承諾)する必要があります。
これにより、所有権の移動は単一の行動ではなく、制御されたライフサイクルになるという興味深い設計上の選択が生まれます。
SENDは保留中の送金を作成します。ACCEPTは受信者側を完了させます。もし承諾が行われなければ、プロトコルには、送金状態を未解決のままにしておくのではなく、定義された期限切れの経路があります。
重要な示唆は、Zedgerが「送金の開始」と「送金の確定」を分離していることです。これは制御性を高めますが、その一方で、ユーザーやアプリケーションが送金状態を注意深く扱う必要も意味します。
仕組みは明確です。
次に気になるのは、こうした保留状態が実際のネットワーク活動の中でどれくらい頻繁に現れるのか、という点です。
@Dusk_Foundation $DUSK