Duskのスマートコントラクトにおける2つの送信者（sender）関数が気になりました。caller() と public_sender() です。
どちらも同じ質問—このアクションを開始したのは誰か—に答えるための2つの手段のように聞こえますが、指し示す主体が異なり得ます。Duskが、EUのライセンスを持つ機関とともに金融市場をオンチェーン化しようとしている中で、この違いは重要です。より複雑なコントラクト同士のやり取りを経ても、最初に行為を開始した主体を見失わない認可（authorization）が必要になるからです。caller() は、直近の呼び出しを行っているコントラクトを特定します。一方 public_sender() は、取引を開始した Moonlight アカウントへと逆参照し続けられる可能性があります。
私がまだ分かっていないのは、Dusk のコントラクトが「実際にアクションを開始したユーザー」を一貫して認可するのか、それとも中間コントラクトを追加すると、認可ロジックが参照するアイデンティティが静かに変わってしまうのか、という点です。注目すべきメカニズムはシンプルです。コントラクトが caller() に依存する場合、public_sender() に依存する場合、そしてバッチャーやフォワーダーが途中に入ったときに何が起きるのか。成功した取引（トランザクション）だけでは結論は出せません。より強いテストは、実行パスが変わっても、同じ認可ルールが意図した主体を指し続けるかどうかです。
途中にどれだけ多くの中間コントラクトが介在するかよりも、「認可がなお、実際にそれを開始した主体へ解決されるか」の方を重視しています。
中間者（intermediary）を追加すると、実際にアクションを認可した“誰”は変わらなくても、あるコントラクトが見える相手（誰が呼び出したように見えるか）が変わり得るからです。
問題は、Duskが“ど真ん中にあるたまたまのコントラクト”に認可が依存することなく、より合成可能な実行パスを追加できるかどうかです。
これらのパターンが発展していく中で、caller() と public_sender() がどう使われているかを見ています。
@Dusk $DUSK #dusk
どちらも同じ質問—このアクションを開始したのは誰か—に答えるための2つの手段のように聞こえますが、指し示す主体が異なり得ます。Duskが、EUのライセンスを持つ機関とともに金融市場をオンチェーン化しようとしている中で、この違いは重要です。より複雑なコントラクト同士のやり取りを経ても、最初に行為を開始した主体を見失わない認可（authorization）が必要になるからです。caller() は、直近の呼び出しを行っているコントラクトを特定します。一方 public_sender() は、取引を開始した Moonlight アカウントへと逆参照し続けられる可能性があります。
私がまだ分かっていないのは、Dusk のコントラクトが「実際にアクションを開始したユーザー」を一貫して認可するのか、それとも中間コントラクトを追加すると、認可ロジックが参照するアイデンティティが静かに変わってしまうのか、という点です。注目すべきメカニズムはシンプルです。コントラクトが caller() に依存する場合、public_sender() に依存する場合、そしてバッチャーやフォワーダーが途中に入ったときに何が起きるのか。成功した取引（トランザクション）だけでは結論は出せません。より強いテストは、実行パスが変わっても、同じ認可ルールが意図した主体を指し続けるかどうかです。
途中にどれだけ多くの中間コントラクトが介在するかよりも、「認可がなお、実際にそれを開始した主体へ解決されるか」の方を重視しています。
中間者（intermediary）を追加すると、実際にアクションを認可した“誰”は変わらなくても、あるコントラクトが見える相手（誰が呼び出したように見えるか）が変わり得るからです。
問題は、Duskが“ど真ん中にあるたまたまのコントラクト”に認可が依存することなく、より合成可能な実行パスを追加できるかどうかです。
これらのパターンが発展していく中で、caller() と public_sender() がどう使われているかを見ています。
@Dusk $DUSK #dusk
