Minggu lalu saya mengirim paket cepat, ternyata salah kirim barang. Setelah saya menghubungi layanan pelanggan, CS menjelaskan: status logistik itu tidak sesederhana hitam-putih “dikirim” dan “tidak dikirim”. Di antaranya ada “sudah dikirim”, “dalam pengangkutan”, “sudah diterima”. Di setiap tahap, apakah bisa dicegah/ditahan (intercept) atau ditarik kembali (recall), aturannya benar-benar berbeda. Setelah saya menutup telepon, saya tiba-tiba teringat bahwa di blockchain, “konfirmasi” juga memakai logika yang sama—bukan cuma “sudah dikonfirmasi” atau “belum dikonfirmasi”.
Di sisi Dusk, status blok dibagi menjadi empat tingkat. Blok yang baru saja dibuat: jika pada pemungutan suara pertama langsung lolos, disebut “attested” (sudah dibuktikan). Jika sebelumnya pernah ada putaran pemungutan suara yang gagal, tapi sekarang baru lolos, disebut “accepted” (sudah diterima); yang ini masih mungkin digantikan oleh blok dari putaran yang lebih rendah. Seiring ke depan, untuk blok “attested”: selama ada blok-blok lanjutan yang tersambung, ia akan berubah menjadi “confirmed” (sudah dikonfirmasi). Sementara itu, blok “accepted” harus menunggu sejumlah blok lanjutan tertentu untuk menopangnya sebelum bisa naik menjadi “confirmed”. Tahap terakhir: blok “confirmed” hanya bisa naik menjadi “final” (final/penutup) jika “parent block”-nya juga sudah berstatus final. Begitu keadaan ini tercapai, statusnya benar-benar tidak bisa dibatalkan.
Desain tingkatan ini memecahkan masalah “seberapa cepat bisa merasa aman”—tidak semua blok harus menunggu level tertinggi dulu supaya bisa dipakai. Untuk skenario ringan, cukup mengakui “attested” sudah boleh bergerak; untuk skenario aset berat, harus menunggu “final” sebelum benar-benar bisa lega. Tingkat toleransi risiko yang berbeda memerlukan ambang konfirmasi yang berbeda pula—kelenturan ini cukup berguna.
Tapi ada biayanya: kompleksitas. Pengguna biasa sulit menilai langsung transaksi mereka sudah sampai level yang mana. Saat ini, bagian ini terutama bergantung pada tampilan yang dilakukan oleh perangkat lunak node dan lapisan dompet (wallet); apakah pengalamannya bagus atau tidak juga masih bergantung pada implementasi nyata.
$DUSK
#dusk @Dusk
Di sisi Dusk, status blok dibagi menjadi empat tingkat. Blok yang baru saja dibuat: jika pada pemungutan suara pertama langsung lolos, disebut “attested” (sudah dibuktikan). Jika sebelumnya pernah ada putaran pemungutan suara yang gagal, tapi sekarang baru lolos, disebut “accepted” (sudah diterima); yang ini masih mungkin digantikan oleh blok dari putaran yang lebih rendah. Seiring ke depan, untuk blok “attested”: selama ada blok-blok lanjutan yang tersambung, ia akan berubah menjadi “confirmed” (sudah dikonfirmasi). Sementara itu, blok “accepted” harus menunggu sejumlah blok lanjutan tertentu untuk menopangnya sebelum bisa naik menjadi “confirmed”. Tahap terakhir: blok “confirmed” hanya bisa naik menjadi “final” (final/penutup) jika “parent block”-nya juga sudah berstatus final. Begitu keadaan ini tercapai, statusnya benar-benar tidak bisa dibatalkan.
Desain tingkatan ini memecahkan masalah “seberapa cepat bisa merasa aman”—tidak semua blok harus menunggu level tertinggi dulu supaya bisa dipakai. Untuk skenario ringan, cukup mengakui “attested” sudah boleh bergerak; untuk skenario aset berat, harus menunggu “final” sebelum benar-benar bisa lega. Tingkat toleransi risiko yang berbeda memerlukan ambang konfirmasi yang berbeda pula—kelenturan ini cukup berguna.
Tapi ada biayanya: kompleksitas. Pengguna biasa sulit menilai langsung transaksi mereka sudah sampai level yang mana. Saat ini, bagian ini terutama bergantung pada tampilan yang dilakukan oleh perangkat lunak node dan lapisan dompet (wallet); apakah pengalamannya bagus atau tidak juga masih bergantung pada implementasi nyata.
$DUSK
#dusk @Dusk