#dusk $DUSK @Dusk ......Saya mengira model transaksi Dusk hanyalah detail implementasi yang lebih kecil. Masalah yang lebih dalam justru lebih sulit terlihat: satu maksud pengguna masih bisa memerlukan beberapa transaksi independen....
Anggap transaksi blockchain seperti instruksi tertutup rapat. Jika tindakan Anda memerlukan lima instruksi, menandatanganinya bersama-sama tidak otomatis berarti jaringan memperlakukannya sebagai satu tindakan. Satu instruksi bisa dieksekusi sementara instruksi lain gagal.
Itulah masalah yang sedang Dusk teliti di issue #4058.....
Hari ini, transaksi Moonlight atau Phoenix membawa satu operasi TransactionData opsional. Jadi alur seperti approve → swap → stake harus dipecah menjadi beberapa transaksi, masing-masing dengan tanda tangan, nonce, dan risiko inklusi sendiri.
Lebih dalam lagi....
Dusk mempertimbangkan batch transaksi tingkat-protokol yang dapat mengeksekusi beberapa pemanggilan kontrak secara atomik di bawah identitas pengguna. Itu juga akan memungkinkan setiap operasi membawa nilai atau deposit-nya sendiri, sekaligus berpotensi mencakup Phoenix tanpa mengubah circuit transfer-nya atau trusted setup...
Tapi ada jalur lain.
Sebuah kontrak batcher bisa mengeksekusi beberapa panggilan tanpa mengubah protokol. Konsekuensinya ada pada otorisasi: kontrak yang menggunakan caller() bisa melihat batcher, bukan pengguna asli, sementara public_sender() bisa mempertahankan akun Moonlight yang menjadi asal.
Perbedaan itu menarik perhatian saya....
Bagian tersulit dari batching bukanlah memasukkan beberapa panggilan ke dalam satu wadah. Bagian tersulitnya adalah mendefinisikan apa yang dimaksud identitas, gas, nilai, dan kegagalan ketika panggilan-panggilan itu berubah menjadi satu transisi keadaan.
Dan #4058 masih terbuka, dengan implementasi sebenarnya serta spesifikasi protokol yang secara eksplisit masih ditinggalkan untuk pekerjaan lanjutan.....
Untuk sebuah rantai yang menargetkan alur kerja finansial, apakah eksekusi multi-langkah atomik harus menjadi primitif protokol, atau tetap menjadi sesuatu yang disusun sendiri oleh kontrak?
$ADA $TUT
Anggap transaksi blockchain seperti instruksi tertutup rapat. Jika tindakan Anda memerlukan lima instruksi, menandatanganinya bersama-sama tidak otomatis berarti jaringan memperlakukannya sebagai satu tindakan. Satu instruksi bisa dieksekusi sementara instruksi lain gagal.
Itulah masalah yang sedang Dusk teliti di issue #4058.....
Hari ini, transaksi Moonlight atau Phoenix membawa satu operasi TransactionData opsional. Jadi alur seperti approve → swap → stake harus dipecah menjadi beberapa transaksi, masing-masing dengan tanda tangan, nonce, dan risiko inklusi sendiri.
Lebih dalam lagi....
Dusk mempertimbangkan batch transaksi tingkat-protokol yang dapat mengeksekusi beberapa pemanggilan kontrak secara atomik di bawah identitas pengguna. Itu juga akan memungkinkan setiap operasi membawa nilai atau deposit-nya sendiri, sekaligus berpotensi mencakup Phoenix tanpa mengubah circuit transfer-nya atau trusted setup...
Tapi ada jalur lain.
Sebuah kontrak batcher bisa mengeksekusi beberapa panggilan tanpa mengubah protokol. Konsekuensinya ada pada otorisasi: kontrak yang menggunakan caller() bisa melihat batcher, bukan pengguna asli, sementara public_sender() bisa mempertahankan akun Moonlight yang menjadi asal.
Perbedaan itu menarik perhatian saya....
Bagian tersulit dari batching bukanlah memasukkan beberapa panggilan ke dalam satu wadah. Bagian tersulitnya adalah mendefinisikan apa yang dimaksud identitas, gas, nilai, dan kegagalan ketika panggilan-panggilan itu berubah menjadi satu transisi keadaan.
Dan #4058 masih terbuka, dengan implementasi sebenarnya serta spesifikasi protokol yang secara eksplisit masih ditinggalkan untuk pekerjaan lanjutan.....
Untuk sebuah rantai yang menargetkan alur kerja finansial, apakah eksekusi multi-langkah atomik harus menjadi primitif protokol, atau tetap menjadi sesuatu yang disusun sendiri oleh kontrak?
$ADA $TUT