TRANSAKSI SENJA BISA “DITERIMA” SEBELUM PERTUKARAN MENGANGGAPNYA SEBAGAI SUDAH SELESAI.
Saya sedang membaca melalui API transaksi milik @Dusk dan satu kode status berakhir mengganggu saya lebih dari biasanya dalam diskusi tentang kepastian akhir:
202 Accepted.
Ketika node Dusk mengembalikan 202 setelah sebuah transaksi disebarkan, itu berarti transaksi tersebut telah diterima untuk perutean.
Namun itu belum membuktikan bahwa transaksi itu masuk ke mempool nyata, mencapai rekan-rekan (peers), dieksekusi dengan sukses, atau menjadi final.
Kedengarannya seperti detail API kecil.
Tapi untuk pemrosesan penarikan (withdrawals) di sebuah bursa, saya rasa itu tidak.
Saya sebelumnya secara mental menganggap pemrosesan penarikan sebagai sesuatu yang mirip dengan:
kirim transaksi → jaringan menerimanya → tunggu hingga finalitas → tutup penarikan.
Namun ada status yang canggung di tengah ketika bursa telah mengirim sesuatu dan masih belum punya cukup informasi untuk dengan aman menyatakan tindakan ekonomi tersebut selesai.
Itu mengubah persoalannya.
Pengiriman transaksi bukanlah penyelesaian transaksi.
Dan mencoba ulang permintaan API yang gagal tidak selalu sama dengan memutuskan bahwa penarikan awal tidak pernah ada.
Dokumentasi Dusk bahkan memperingatkan bahwa layanan penandatangan (signing service) perlu menyerialkan alokasi nonce, menyimpan transaksi yang telah dikirim, serta memeriksa status akun yang tertunda (pending) dan yang telah dikomit (committed) sebelum menggunakan ulang sebuah nonce.
Bagian inilah yang saya anggap menarik.
Kepastian akhir yang deterministik dapat membuat akhir sebuah transaksi menjadi sangat jelas.
Namun itu tidak otomatis membuat setiap keadaan sebelum finalitas sama mudahnya untuk ditangani oleh sebuah bursa.
Jadi jika saya menilai integrasi serius Dusk, saya tidak hanya ingin mengukur kecepatan penyelesaian (settlement).
Saya ingin tahu apa yang terjadi selama kegagalan node, timeouts, dan pengiriman yang ambigu:
Berapa banyak penarikan yang bisa pulih secara otomatis tanpa membuat instruksi duplikat atau tanpa mengharuskan seseorang memutuskan secara manual apa yang terjadi?
Infrastruktur transaksi terbaik mungkin adalah yang jalur kegagalannya menjadi hal yang membosankan.
Itu tampaknya jauh lebih sulit daripada membuat jalur yang berhasil menjadi cepat.
#dusk $DUSK @Dusk
$GPS $TUT
Saya sedang membaca melalui API transaksi milik @Dusk dan satu kode status berakhir mengganggu saya lebih dari biasanya dalam diskusi tentang kepastian akhir:
202 Accepted.
Ketika node Dusk mengembalikan 202 setelah sebuah transaksi disebarkan, itu berarti transaksi tersebut telah diterima untuk perutean.
Namun itu belum membuktikan bahwa transaksi itu masuk ke mempool nyata, mencapai rekan-rekan (peers), dieksekusi dengan sukses, atau menjadi final.
Kedengarannya seperti detail API kecil.
Tapi untuk pemrosesan penarikan (withdrawals) di sebuah bursa, saya rasa itu tidak.
Saya sebelumnya secara mental menganggap pemrosesan penarikan sebagai sesuatu yang mirip dengan:
kirim transaksi → jaringan menerimanya → tunggu hingga finalitas → tutup penarikan.
Namun ada status yang canggung di tengah ketika bursa telah mengirim sesuatu dan masih belum punya cukup informasi untuk dengan aman menyatakan tindakan ekonomi tersebut selesai.
Itu mengubah persoalannya.
Pengiriman transaksi bukanlah penyelesaian transaksi.
Dan mencoba ulang permintaan API yang gagal tidak selalu sama dengan memutuskan bahwa penarikan awal tidak pernah ada.
Dokumentasi Dusk bahkan memperingatkan bahwa layanan penandatangan (signing service) perlu menyerialkan alokasi nonce, menyimpan transaksi yang telah dikirim, serta memeriksa status akun yang tertunda (pending) dan yang telah dikomit (committed) sebelum menggunakan ulang sebuah nonce.
Bagian inilah yang saya anggap menarik.
Kepastian akhir yang deterministik dapat membuat akhir sebuah transaksi menjadi sangat jelas.
Namun itu tidak otomatis membuat setiap keadaan sebelum finalitas sama mudahnya untuk ditangani oleh sebuah bursa.
Jadi jika saya menilai integrasi serius Dusk, saya tidak hanya ingin mengukur kecepatan penyelesaian (settlement).
Saya ingin tahu apa yang terjadi selama kegagalan node, timeouts, dan pengiriman yang ambigu:
Berapa banyak penarikan yang bisa pulih secara otomatis tanpa membuat instruksi duplikat atau tanpa mengharuskan seseorang memutuskan secara manual apa yang terjadi?
Infrastruktur transaksi terbaik mungkin adalah yang jalur kegagalannya menjadi hal yang membosankan.
Itu tampaknya jauh lebih sulit daripada membuat jalur yang berhasil menjadi cepat.
#dusk $DUSK @Dusk
$GPS $TUT