#dusk kecewa peringkat saya tidak membaik, sudah mencoba semuanya sekarang saya selesai $TREE n $HEMI apakah bintang yang sedang naik daun hari ini

Menghabiskan waktu menjelang senja untuk tugas Dusk dengan menggali pembaruan rekayasa dan malah terjebak pada mekanisme transfer yang belum pernah saya pikirkan sebelumnya: kontrak pintar tidak harus menerima DUSK hanya karena kontrak lain mengirimkannya.
Dusk menambahkan transfer_to_contract, di mana satu kontrak bisa mentransfer DUSK ke kontrak lain dan melampirkan data sewenang-wenang pada pemanggilan tersebut. Kontrak penerima bisa memeriksa data itu dan menerima atau menolak transfer.
Kedengarannya kecil. Padahal tidak.
Model transfer biasa pada dasarnya menganggap penerimaan uang sebagai hal pasif. Jika seseorang mengirim nilai ke sebuah alamat, nilai itu akan masuk. Di sini, penerimaan bisa menjadi bagian dari logika aplikasi. Kontrak bisa secara efektif berkata “saya menerima pembayaran ini hanya jika informasi yang dilampirkan memenuhi aturan saya.”
Saya terus kembali pada apa artinya untuk alur kerja keuangan. Pembayaran mungkin perlu sesuai dengan instruksi, status, atau kondisi tertentu sebelum aplikasi penerima menganggapnya valid. Alih-alih menerima dana dulu lalu mencari tahu peruntukannya setelahnya, penerima bisa menjadikan penerimaan sebagai bagian dari eksekusi itu sendiri.
Lebih rapi, tapi juga berarti pembayaran tidak lagi netral secara universal. Kontrak tujuan punya kendali atas apakah transfer selesai, dan logika penerimaan yang dirancang buruk bisa menolak alur yang sepenuhnya sah.
Uniknya, bagian menariknya bukan karena kontrak bisa mengirim uang. Itu sudah diharapkan. Yang menarik adalah sisi penerima diberi hak suara.
Jadi, apakah penerimaan penerima yang eksplisit adalah primitif yang tepat untuk kontrak keuangan yang membutuhkan pembayaran bersyarat, atau apakah membiarkan kontrak menolak nilai masuk menambah kompleksitas pada sesuatu yang seharusnya tetap sederhana??
#dusk $DUSK @Dusk

Pembayaran DUSK bersyarat: primitif yang lebih baik atau kompleksitas tambahan?


🔘 Receiver acceptance makes s
100%
🔘 Transfers should stay simpl
0%
🔘 Useful for financial apps
0%
🔘 Depends on contract design
0%
5 Voting • Voting ditutup