Dua fungsi pengirim (sender) dalam smart contract Dusk menarik perhatian saya: caller() dan public_sender().
Keduanya terdengar seperti dua cara untuk menjawab pertanyaan yang sama, siapa yang memulai tindakan ini, tetapi keduanya bisa menunjuk ke aktor yang berbeda. Pembedaan ini penting karena Dusk mendorong pasar keuangan agar berjalan di onchain dengan institusi berlisensi UE, di mana otorisasi harus bertahan dari interaksi kontrak yang lebih kompleks tanpa kehilangan jejak aktor aslinya. caller() mengidentifikasi kontrak yang membuat panggilan langsung, sedangkan public_sender() masih dapat menunjuk kembali ke akun Moonlight yang memulai transaksi tersebut.
Yang belum saya ketahui adalah apakah smart contract Dusk akan secara konsisten mengotorisasi pengguna yang benar-benar memulai suatu tindakan, atau apakah menambahkan kontrak perantara dapat diam-diam mengubah identitas yang dilihat oleh logika otorisasi. Mekanisme yang layak diperhatikan itu sederhana: ketika kontrak bergantung pada caller(), ketika bergantung pada public_sender(), dan apa yang terjadi begitu batcher atau forwarder berada di tengah.
Transaksi yang dieksekusi dengan sukses tidak cukup untuk menjawab itu. Uji yang lebih kuat adalah apakah aturan otorisasi yang sama tetap menunjuk kembali ke aktor yang dimaksud bahkan ketika jalur eksekusi berubah.
Saya tidak terlalu peduli berapa banyak kontrak perantara yang dilewati suatu tindakan, selama otorisasi tetap terselesaikan ke aktor yang benar-benar memulai tindakan tersebut.
Hal ini penting karena menambahkan perantara dapat mengubah siapa yang dilihat sebuah kontrak tanpa mengubah siapa yang benar-benar mengotorisasi tindakan tersebut.
Pertanyaannya adalah apakah Dusk dapat menambahkan lebih banyak jalur eksekusi yang dapat disusun (composable) tanpa membuat otorisasi bergantung pada kontrak mana pun yang kebetulan berada di tengah.
Saya memantau bagaimana caller() dan public_sender() digunakan saat pola-pola itu berkembang.
@Dusk $DUSK #dusk
Keduanya terdengar seperti dua cara untuk menjawab pertanyaan yang sama, siapa yang memulai tindakan ini, tetapi keduanya bisa menunjuk ke aktor yang berbeda. Pembedaan ini penting karena Dusk mendorong pasar keuangan agar berjalan di onchain dengan institusi berlisensi UE, di mana otorisasi harus bertahan dari interaksi kontrak yang lebih kompleks tanpa kehilangan jejak aktor aslinya. caller() mengidentifikasi kontrak yang membuat panggilan langsung, sedangkan public_sender() masih dapat menunjuk kembali ke akun Moonlight yang memulai transaksi tersebut.
Yang belum saya ketahui adalah apakah smart contract Dusk akan secara konsisten mengotorisasi pengguna yang benar-benar memulai suatu tindakan, atau apakah menambahkan kontrak perantara dapat diam-diam mengubah identitas yang dilihat oleh logika otorisasi. Mekanisme yang layak diperhatikan itu sederhana: ketika kontrak bergantung pada caller(), ketika bergantung pada public_sender(), dan apa yang terjadi begitu batcher atau forwarder berada di tengah.
Transaksi yang dieksekusi dengan sukses tidak cukup untuk menjawab itu. Uji yang lebih kuat adalah apakah aturan otorisasi yang sama tetap menunjuk kembali ke aktor yang dimaksud bahkan ketika jalur eksekusi berubah.
Saya tidak terlalu peduli berapa banyak kontrak perantara yang dilewati suatu tindakan, selama otorisasi tetap terselesaikan ke aktor yang benar-benar memulai tindakan tersebut.
Hal ini penting karena menambahkan perantara dapat mengubah siapa yang dilihat sebuah kontrak tanpa mengubah siapa yang benar-benar mengotorisasi tindakan tersebut.
Pertanyaannya adalah apakah Dusk dapat menambahkan lebih banyak jalur eksekusi yang dapat disusun (composable) tanpa membuat otorisasi bergantung pada kontrak mana pun yang kebetulan berada di tengah.
Saya memantau bagaimana caller() dan public_sender() digunakan saat pola-pola itu berkembang.
@Dusk $DUSK #dusk
