Privasi dari Dusk hanya benar-benar bisa dipercaya saat jaringan sedang mengalami tekanan
Hal yang membuat cara pandang saya berubah tentang Phoenix adalah menyadari bahwa “tidak terlihat” tidak berarti “tidak perlu diverifikasi”
Pada transaksi shielded, pengamat publik tidak dapat melihat sender, receiver, maupun amount seperti pada Moonlight, namun transaksi tetap harus diverifikasi oleh jaringan sebelum statusnya dapat diterima. Setelah itu, DuskDS memasukkan block melalui proposal, validation, dan ratification untuk mencapai deterministic finality.
Dalam kondisi normal, model ini cukup ringkas. Bagian yang ingin saya lihat lebih detail justru saat jaringan sedang padat.
Jika transaksi public dan confidential sama-sama memberi tekanan pada sistem, committee terus berubah, sementara beberapa provisioner mulai tertinggal ritmenya—privasi tidak lagi menjadi satu-satunya pertanyaan. Jaringan juga harus menjaga liveness dan finality tanpa menurunkan standar verifikasi.
Yang menurut saya masuk akal adalah Dusk tidak menganggap semua kesalahan itu sama. Provisioner yang melewatkan tugas mungkin hanya menerima soft penalty, sedangkan perilaku yang dapat dibuktikan salah seperti vote yang tidak valid atau tanda tangan yang saling bertentangan dapat berujung pada hard penalty.
Menurut saya, inilah justru tes yang lebih menarik dibanding sekadar melihat satu transaksi privat berjalan mulus.
Sistem privasi yang baik tidak hanya perlu menyembunyikan data saat semuanya berjalan normal. Ia harus tetap mempertahankan kemampuan verifikasi ketika node terpeleset ritmenya, committee berputar, dan beban jaringan meningkat tajam.
Jika Dusk mampu menjaga batas itu, barulah privasi benar-benar menjadi sifat dari infrastruktur, bukan sekadar pengalaman di dalam dompet.
@Dusk $DUSK #dusk
$RICE $BTW
Hal yang membuat cara pandang saya berubah tentang Phoenix adalah menyadari bahwa “tidak terlihat” tidak berarti “tidak perlu diverifikasi”
Pada transaksi shielded, pengamat publik tidak dapat melihat sender, receiver, maupun amount seperti pada Moonlight, namun transaksi tetap harus diverifikasi oleh jaringan sebelum statusnya dapat diterima. Setelah itu, DuskDS memasukkan block melalui proposal, validation, dan ratification untuk mencapai deterministic finality.
Dalam kondisi normal, model ini cukup ringkas. Bagian yang ingin saya lihat lebih detail justru saat jaringan sedang padat.
Jika transaksi public dan confidential sama-sama memberi tekanan pada sistem, committee terus berubah, sementara beberapa provisioner mulai tertinggal ritmenya—privasi tidak lagi menjadi satu-satunya pertanyaan. Jaringan juga harus menjaga liveness dan finality tanpa menurunkan standar verifikasi.
Yang menurut saya masuk akal adalah Dusk tidak menganggap semua kesalahan itu sama. Provisioner yang melewatkan tugas mungkin hanya menerima soft penalty, sedangkan perilaku yang dapat dibuktikan salah seperti vote yang tidak valid atau tanda tangan yang saling bertentangan dapat berujung pada hard penalty.
Menurut saya, inilah justru tes yang lebih menarik dibanding sekadar melihat satu transaksi privat berjalan mulus.
Sistem privasi yang baik tidak hanya perlu menyembunyikan data saat semuanya berjalan normal. Ia harus tetap mempertahankan kemampuan verifikasi ketika node terpeleset ritmenya, committee berputar, dan beban jaringan meningkat tajam.
Jika Dusk mampu menjaga batas itu, barulah privasi benar-benar menjadi sifat dari infrastruktur, bukan sekadar pengalaman di dalam dompet.
@Dusk $DUSK #dusk
$RICE $BTW
