Saat Anda membangun aplikasi yang mengirim transaksi ke Dusk L1, respons sukses dari node tampak seperti momen yang jelas untuk memberi tahu pengguna bahwa tindakannya berhasil.

Saya sempat membacanya seperti itu sampai saya menelusuri siklus hidup transaksi Dusk dengan lebih saksama. `202 Accepted` dari endpoint propagasi hanya berarti node menerima transaksi untuk perutean. Itu tidak berarti transaksi telah mencapai sebuah blok, dieksekusi dengan sukses, atau menjadi final.

Hal ini mengubah integrasi “kirim transaksi” yang terlihat sederhana menjadi sesuatu yang lebih mirip pelacakan status. Setelah sebuah transaksi dieksekusi, Dusk mengekspos field `err`, di mana `null` berarti eksekusi berhasil. Namun bahkan blok yang diterima masih bisa dibatalkan. Finalitas datang ketika blok mencapai state `finalized`.

Menurut saya, ini mengubah klasifikasi pekerjaan pembuat (builder) dengan cara yang berguna.

Anda tidak sekadar memasang tombol ke sebuah endpoint dan menunggu kesuksesan HTTP. Anda sedang memutuskan keadaan jaringan mana yang benar-benar bersedia Anda terjemahkan sebagai “selesai” bagi orang yang menggunakannya.

Submitted adalah satu status.

Executed successfully adalah status lainnya.

Final adalah yang menutup alur.

@Dusk $DUSK #dusk