Saya berasumsi bahwa jika saya ingin melakukan tiga hal di-chain—approve, swap, lalu stake—maka chain akan memperlakukannya sebagai satu hal yang terjadi atau tidak terjadi sama sekali. Sebuah isu terbuka di repositori Rusk milik Dusk sendiri mengatakan bahwa itu tidak seperti cara kerjanya saat ini.
Sebuah transaksi Dusk saat ini membawa satu operasi opsional: satu pemanggilan kontrak, satu deploy, atau satu memo, dengan satu nilai, satu penerima, satu nonce, dan satu tanda tangan. Jadi approve, swap, dan stake menjadi tiga transaksi terpisah, masing-masing bisa secara independen disertakan atau dihapus. Pernyataan isu Dusk menyebutkannya secara gamblang: tidak ada jaminan atomisitas di antara ketiganya. Lakukan approve dan swap tetapi tidak stake, dan Anda akan terjebak di tengah alur tanpa rollback pada level protokol.
Masalahnya bukan hanya bahwa alur multi-langkah bisa berhenti di tengah jalan. Memperbaikinya berarti mengubah siapa yang harus menanggung biaya kompatibilitas.
Kontrak batcher membuat seluruh rangkaian menjadi atomik, karena kegagalan pada sub-panggilan akan membatalkan transaksi luar. Tetapi kontrak target yang memeriksa siapa yang memanggilnya secara langsung akan melihat batcher, bukan Anda, kecuali kontrak tersebut sudah ditulis untuk mengabaikan pemanggil langsung (immediate caller). Sebuah batch transaction pada level protokol membuat Anda tetap menjadi pemanggil pada setiap langkah, tetapi tidak bisa “dikirim” tanpa format transaksi baru, perubahan konsensus, hard-fork, dan seluruh wallet SDK yang menyusul.
Menambahkan batching tidak menghapus tradeoff. Ia menentukan apakah beban kompatibilitas berada pada otorisasi aplikasi atau di tumpukan protokol.
"Memperbaiki atomisitas tidak menghapus tradeoff; ia menentukan ke mana beban kompatibilitas dan batas kepercayaan berpindah."
Yang sebenarnya ingin saya amati: apakah Dusk memilih batcher pada level aplikasi atau transaksi pada level protokol, dan asumsi otorisasi yang sudah ada yang dipaksa berubah oleh pilihan tersebut bagi para pengembang.
#dusk $DUSK @Dusk
Sebuah transaksi Dusk saat ini membawa satu operasi opsional: satu pemanggilan kontrak, satu deploy, atau satu memo, dengan satu nilai, satu penerima, satu nonce, dan satu tanda tangan. Jadi approve, swap, dan stake menjadi tiga transaksi terpisah, masing-masing bisa secara independen disertakan atau dihapus. Pernyataan isu Dusk menyebutkannya secara gamblang: tidak ada jaminan atomisitas di antara ketiganya. Lakukan approve dan swap tetapi tidak stake, dan Anda akan terjebak di tengah alur tanpa rollback pada level protokol.
Masalahnya bukan hanya bahwa alur multi-langkah bisa berhenti di tengah jalan. Memperbaikinya berarti mengubah siapa yang harus menanggung biaya kompatibilitas.
Kontrak batcher membuat seluruh rangkaian menjadi atomik, karena kegagalan pada sub-panggilan akan membatalkan transaksi luar. Tetapi kontrak target yang memeriksa siapa yang memanggilnya secara langsung akan melihat batcher, bukan Anda, kecuali kontrak tersebut sudah ditulis untuk mengabaikan pemanggil langsung (immediate caller). Sebuah batch transaction pada level protokol membuat Anda tetap menjadi pemanggil pada setiap langkah, tetapi tidak bisa “dikirim” tanpa format transaksi baru, perubahan konsensus, hard-fork, dan seluruh wallet SDK yang menyusul.
Menambahkan batching tidak menghapus tradeoff. Ia menentukan apakah beban kompatibilitas berada pada otorisasi aplikasi atau di tumpukan protokol.
"Memperbaiki atomisitas tidak menghapus tradeoff; ia menentukan ke mana beban kompatibilitas dan batas kepercayaan berpindah."
Yang sebenarnya ingin saya amati: apakah Dusk memilih batcher pada level aplikasi atau transaksi pada level protokol, dan asumsi otorisasi yang sudah ada yang dipaksa berubah oleh pilihan tersebut bagi para pengembang.
#dusk $DUSK @Dusk
