#dusk がっかりした。順位が上がらない。もうできることは全部試したし、今は終わりだ $TREE n $HEMI 今日の「新星」は誰だ

夕暮れのタスクで、エンジニアリングのアップデートを掘り下げているうちに、正直な話、考えたことがなかった転送メカニズムに行き詰まった。つまり「スマートコントラクトは、別のコントラクトから送られてきたからといって、DUSKを受け取る必要がない」ということだ。
Duskは transfer_to_contract を追加した。これにより、1つのコントラクトがDUSKを別のコントラクトへ転送し、呼び出しに任意のデータを添付できる。受け取る側のコントラクトは、そのデータを検査して、転送を受け入れるか拒否するかを決められる。
小さく聞こえるかもしれない。けど違う。
通常の転送モデルでは、受け取る側のお金は基本的に「受け身」だ。誰かがアドレスに価値を送れば、その価値は到着する。ここでは、受け取りがアプリケーションのロジックの一部になり得る。コントラクトは、添付された情報が自分のルールを満たす場合にのみ「この支払いを受け入れる」と実質的に言える。
私は、このことが金融ワークフローにとって何を意味するのかを何度も考え続けた。支払いは、受信するアプリがそれを有効だとみなす前に、特定の指示・状態・条件に対応している必要があるかもしれない。まず資金を受け入れてから「それが何のためだったのか」を後で理解するのではなく、受け入れを実行そのものの一部として組み込める。
それはよりスッキリしている。でも同時に、支払いがもはや普遍的に「中立」ではなくなる。転送先のコントラクトには、転送を完了させるかどうかの裁量がある。そして、設計の悪い受け入れロジックは、まったく正当なフローを拒否してしまう可能性がある。
面白いのは変な話、コントラクト同士が送金できることではない。そこは予想できることだ。問題は、受け取る側が「投票（判断）」できるという点だ。
では、条件付きの支払いが必要な金融コントラクトにとって、明示的な受信者の承認をプリミティブとして用意するのが正しいのか。それとも、コントラクトに「到来する価値を拒否する」ことを許すことで、転送をシンプルに保つはずのものに複雑さを追加してしまうのか？？
#dusk $DUSK @Dusk

条件付きのDUSK支払い：より良いプリミティブか、それとも追加の複雑さか？