Node mengembalikan “202 Accepted”—masih kurang berapa langkah lagi sampai benar-benar berhasil diselesaikan?
Dalam sistem pembayaran tradisional, “bank telah menerima” dan “dana sudah masuk” adalah dua status yang berbeda. Setelah meneliti siklus hidup transaksi milik @Dusk , saya menemukan bahwa transaksi di blockchain juga tidak bisa hanya dinilai dari satu pesan “berhasil”.
Satu transaksi Dusk L1 secara garis besar melalui tahapan berikut:
pengiriman (submit), validasi awal oleh node, masuk ke mempool lokal, dipropagasikan ke node-node lain, dipilih oleh pembuat blok, dieksekusi, dan akhirnya dikonfirmasi.
Yang paling mudah disalahpahami adalah: respons dari antarmuka pengiriman transaksi yang mengembalikan 202 Accepted hanya berarti node telah menerima data tersebut dan bersiap untuk melakukan propagasi—bukan berarti transaksi itu sudah masuk ke dalam blok.
Bahkan jika transaksi sudah masuk ke mempool node, itu hanya menunjukkan transaksi tersebut lolos pemeriksaan awal di node itu. Setelah masuk ke blok, masih perlu memeriksa apakah err pada hasil eksekusi kosong. Jika kontrak melakukan rollback karena parameter, status, atau masalah Gas, maka Nonce dan Gas yang sudah terpakai tetap mungkin tidak bisa dipulihkan.
Pada akhirnya, masih perlu menunggu blok mencapai status finalized. Dokumentasi resmi secara tegas mengingatkan: jangan menganggap included, removed, atau accepted biasa secara langsung sebagai sinyal finalitas pembayaran.
Hal ini sangat penting untuk layanan penyelesaian efek di masa depan dari Dusk. Yang dipedulikan institusi bukan apakah layar menampilkan notifikasi hijau, melainkan berdasarkan status finalitas yang tidak dapat dibatalkan, kapan penyerahan aset dan pencatatan buku dilakukan.
Indikator finalitas akhir yang diberikan oleh situs resmi Dusk sekitar 10 detik, tetapi aplikasi tetap harus mengenali status finalitas dengan benar—bukan menebak hasil hanya dengan mengandalkan penantian tetap 10 detik.
Saya menilai kedewasaan sistem penyelesaian level institusi dengan memperhatikan:
1. Stabilitas waktu konfirmasi akhir;
2. Tingkat kegagalan eksekusi;
3. Jumlah kali blok di-rollback dan rekonsiliasi ulang;
4. Apakah aplikasi membedakan pengiriman, eksekusi, dan konfirmasi akhir;
5. Apakah sisi aset dan sisi pembayaran menggunakan standar finalitas yang sama.
Penyelesaian on-chain yang benar bukan sekadar transaksi sudah dikirim, melainkan semua pihak yang terlibat memiliki jawaban yang sama mengenai “kapan boleh mencatat (accounting)”. #dusk $DUSK
Dalam sistem pembayaran tradisional, “bank telah menerima” dan “dana sudah masuk” adalah dua status yang berbeda. Setelah meneliti siklus hidup transaksi milik @Dusk , saya menemukan bahwa transaksi di blockchain juga tidak bisa hanya dinilai dari satu pesan “berhasil”.
Satu transaksi Dusk L1 secara garis besar melalui tahapan berikut:
pengiriman (submit), validasi awal oleh node, masuk ke mempool lokal, dipropagasikan ke node-node lain, dipilih oleh pembuat blok, dieksekusi, dan akhirnya dikonfirmasi.
Yang paling mudah disalahpahami adalah: respons dari antarmuka pengiriman transaksi yang mengembalikan 202 Accepted hanya berarti node telah menerima data tersebut dan bersiap untuk melakukan propagasi—bukan berarti transaksi itu sudah masuk ke dalam blok.
Bahkan jika transaksi sudah masuk ke mempool node, itu hanya menunjukkan transaksi tersebut lolos pemeriksaan awal di node itu. Setelah masuk ke blok, masih perlu memeriksa apakah err pada hasil eksekusi kosong. Jika kontrak melakukan rollback karena parameter, status, atau masalah Gas, maka Nonce dan Gas yang sudah terpakai tetap mungkin tidak bisa dipulihkan.
Pada akhirnya, masih perlu menunggu blok mencapai status finalized. Dokumentasi resmi secara tegas mengingatkan: jangan menganggap included, removed, atau accepted biasa secara langsung sebagai sinyal finalitas pembayaran.
Hal ini sangat penting untuk layanan penyelesaian efek di masa depan dari Dusk. Yang dipedulikan institusi bukan apakah layar menampilkan notifikasi hijau, melainkan berdasarkan status finalitas yang tidak dapat dibatalkan, kapan penyerahan aset dan pencatatan buku dilakukan.
Indikator finalitas akhir yang diberikan oleh situs resmi Dusk sekitar 10 detik, tetapi aplikasi tetap harus mengenali status finalitas dengan benar—bukan menebak hasil hanya dengan mengandalkan penantian tetap 10 detik.
Saya menilai kedewasaan sistem penyelesaian level institusi dengan memperhatikan:
1. Stabilitas waktu konfirmasi akhir;
2. Tingkat kegagalan eksekusi;
3. Jumlah kali blok di-rollback dan rekonsiliasi ulang;
4. Apakah aplikasi membedakan pengiriman, eksekusi, dan konfirmasi akhir;
5. Apakah sisi aset dan sisi pembayaran menggunakan standar finalitas yang sama.
Penyelesaian on-chain yang benar bukan sekadar transaksi sudah dikirim, melainkan semua pihak yang terlibat memiliki jawaban yang sama mengenai “kapan boleh mencatat (accounting)”. #dusk $DUSK