Timeout Penarikan Tidak Boleh Menciptakan Identitas Baru
Permintaan penarikan mengalami timeout. Respons yang menggoda adalah yang sederhana: bangun ulang transaksinya dan kirim ulang.
Di Dusk, itu bisa membuat masalah operasional menjadi lebih sulit.
Untuk penarikan Moonlight, panduan integrasinya menyatakan bahwa transaksi harus dibangun dan ditandatangani sekali saja, dengan byte terserialisasi serta ID transaksinya disimpan sebelum dipancarkan (dibroadcast). Jika pengiriman mengalami timeout transport, upaya ulang yang aman adalah memancarkan ulang byte tersertifikasi (signed) yang persis sama. Transaksi tetap menggunakan identitas yang sama saat statusnya di rantai sedang diselidiki.
Mengapa ini penting? Karena timeout tidak membuktikan upaya pertama gagal. Bahkan respons 202 Accepted hanya mengonfirmasi perutean (routing), bukan penyertaan atau finalitas. Membuat transaksi lain sebelum menyelesaikan ketidakpastian itu menambah satu objek lain yang harus dilacak oleh sistem penarikan.
Moonlight membuat perbedaannya secara eksplisit. Transaksi menggunakan nonce akun berurutan, dan transaksi lain dengan nonce yang sama hanya menggantikan entri mempool yang sudah ada jika harga gasnya secara ketat lebih tinggi. Penggantian ini menghasilkan ID transaksi yang berbeda. Karena itu, Dusk memberi tahu operator pertukaran untuk merekonsiliasi kedua ID dan menghindari pendebitan dua kali.
Jadi, “retry” dan “replacement” bukan tindakan backend yang dapat saling dipertukarkan. Retry mempertahankan identitas dari upaya pembayaran. Replacement secara sengaja menciptakan identitas baru untuk nonce yang sama.
Untuk infrastruktur custody, idempotency dengan demikian melampaui desain basis data: konstruksi transaksi, alokasi nonce, byte yang ditandatangani, serta catatan akuntansi semuanya harus mendeskripsikan penarikan yang sama.
@Dusk $DUSK #dusk
Permintaan penarikan mengalami timeout. Respons yang menggoda adalah yang sederhana: bangun ulang transaksinya dan kirim ulang.
Di Dusk, itu bisa membuat masalah operasional menjadi lebih sulit.
Untuk penarikan Moonlight, panduan integrasinya menyatakan bahwa transaksi harus dibangun dan ditandatangani sekali saja, dengan byte terserialisasi serta ID transaksinya disimpan sebelum dipancarkan (dibroadcast). Jika pengiriman mengalami timeout transport, upaya ulang yang aman adalah memancarkan ulang byte tersertifikasi (signed) yang persis sama. Transaksi tetap menggunakan identitas yang sama saat statusnya di rantai sedang diselidiki.
Mengapa ini penting? Karena timeout tidak membuktikan upaya pertama gagal. Bahkan respons 202 Accepted hanya mengonfirmasi perutean (routing), bukan penyertaan atau finalitas. Membuat transaksi lain sebelum menyelesaikan ketidakpastian itu menambah satu objek lain yang harus dilacak oleh sistem penarikan.
Moonlight membuat perbedaannya secara eksplisit. Transaksi menggunakan nonce akun berurutan, dan transaksi lain dengan nonce yang sama hanya menggantikan entri mempool yang sudah ada jika harga gasnya secara ketat lebih tinggi. Penggantian ini menghasilkan ID transaksi yang berbeda. Karena itu, Dusk memberi tahu operator pertukaran untuk merekonsiliasi kedua ID dan menghindari pendebitan dua kali.
Jadi, “retry” dan “replacement” bukan tindakan backend yang dapat saling dipertukarkan. Retry mempertahankan identitas dari upaya pembayaran. Replacement secara sengaja menciptakan identitas baru untuk nonce yang sama.
Untuk infrastruktur custody, idempotency dengan demikian melampaui desain basis data: konstruksi transaksi, alokasi nonce, byte yang ditandatangani, serta catatan akuntansi semuanya harus mendeskripsikan penarikan yang sama.
@Dusk $DUSK #dusk
