ASMA_加密143

DI BALIK KAP: MENGAPA DUSK MENGGUNAKAN KADCAST BUKAN GOSIP BIASA

Lapisan jaringan mudah diabaikan sampai sebuah blockchain mulai sibuk.

DUSK menggunakan Kadcast, protokol P2P terstruktur yang dibangun berdasarkan prinsip Kademlia. Alih-alih secara acak mendorong setiap pesan ke banyak node tetangga, Kadcast mengatur rekan (peers) menggunakan jarak XOR dan perutean terstruktur, sehingga pesan dapat menyebar melalui jalur-jalur yang dipilih dengan transmisi yang lebih minim redundansi. DUSK mengatakan pendekatan ini dirancang untuk mengurangi penggunaan bandwidth dan membuat latensi lebih dapat diprediksi.

Hal ini penting karena infrastruktur keuangan tidak hanya membutuhkan kecepatan. Infrastruktur tersebut memerlukan perilaku jaringan yang tetap dapat diprediksi seiring meningkatnya jumlah partisipan. Whitepaper DUSK yang diperbarui melaporkan pengurangan bandwidth sebesar 25–50% dibanding protokol gosip yang populer, sementara Kadcast juga telah menjalani audit Keamanan Blaize.

Namun, propagasi terstruktur menghadirkan tantangan tersendiri: ketahanan ketika rekan gagal, menghilang, atau berperilaku tidak terduga.

Dapatkah Kadcast mempertahankan efisiensi dan keterprediksiannya saat DUSK berkembang menuju aktivitas keuangan yang benar-benar nyata?

@Dusk $DUSK #dusk

#dusk $DUSK @Dusk
Dulu, saya mengira virtual machine sebuah blockchain hanyalah tempat di mana smart contract “dijalankan.” Namun, mempelajari lebih dalam Dusk mengubah pandangan itu.

Piecrust dibangun sebagai virtual machine WASM milik Dusk, dengan “piecrust” yang menangani eksekusi kontrak dan “piecrust-uplink” yang menyediakan lapisan pengembang untuk membuat dan bekerja dengan kontrak. Bagian yang menarik bukanlah nama virtual machine tersebut. Yang lebih penting adalah pilihan desainnya: menggunakan WASM dan Rust untuk menciptakan lingkungan eksekusi yang terkontrol bagi smart contract Dusk.

Saat ini, dokumentasi Dusk menjelaskan jalur eksekusi ini sebagai DuskVM, berdasarkan runtime Wasmtime dengan dukungan khusus untuk model eksekusi Dusk. Ia menjalankan kontrak Rust/WASM secara langsung di Dusk L1, termasuk aplikasi yang membutuhkan akses langsung ke model transaksi Dusk, aset, privasi, atau kapabilitas zero knowledge.

Perbedaan itu penting.

Kini Dusk menghadirkan dua jalur berbeda bagi pengembang: DuskVM untuk aplikasi Rust/WASM yang memerlukan kapabilitas native L1, dan DuskEVM untuk tooling yang kompatibel dengan Solidity dan Ethereum.

Jadi, saya tidak lagi melihat virtual machine tersebut sekadar sebagai komponen teknis. Itu adalah bagian dari keputusan tentang jenis aplikasi apa yang dapat didukung Dusk secara native.

Pertanyaan yang sedang saya pantau adalah apakah model eksekusi ganda ini dapat memberi fleksibilitas bagi pengembang tanpa membuat ekosistem menjadi lebih sulit dipahami.

@Dusk $DUSK

Ikuti siaran langsung bersama Kim

Saya hampir melewatkan pembedaan dalam desain Phoenix milik Dusk yang mengubah cara saya memikirkan pendelegasian transaksi.

Asumsi pertama saya sederhana: jika pihak ketiga membantu transaksi privat, memberi pihak itu visibilitas yang lebih besar juga harus berarti memberi kontrol yang lebih besar.

Namun whitepaper menarik batas yang jauh lebih tajam. Phoenix memungkinkan pengguna mendelegasikan pemindaian jaringan dengan kunci tampilan (view key), sementara pihak yang didelegasikan tetap tidak dapat membelanjakan catatan (notes) karena ia tidak memiliki kunci rahasia lengkap milik pengguna. Whitepaper itu juga mengatakan pembuatan bukti ZK dapat didelegasikan melalui tanda tangan tanpa mengorbankan integritas transaksi.

Hal ini menarik perhatian saya karena arsitekturnya memisahkan komputasi dari otoritas. Sebuah layanan bisa melakukan pekerjaan yang mahal, tetapi kemampuan untuk benar-benar membelanjakan sebuah catatan tetap terikat pada kunci rahasia lengkap. Rahasia catatan itu sendiri memerlukan pasangan kunci lengkap, bukan sekadar kunci tampilan.

Tapi ini menimbulkan pertanyaan sistem yang berbeda.

Batas keamanan mungkin lebih kuat terhadap layanan yang mendelegasikan dan membelanjakan dana, namun kini pengguna harus mengelola kemampuan (capability) mana yang diekspos ke layanan mana. Lapisan pendelegasian yang dikompromikan atau dirancang buruk tetap bisa menimbulkan masalah operasional atau privasi, bahkan jika ia tidak dapat langsung membelanjakan.

@Dusk $DUSK #dusk

Apakah pemisahan ini benar-benar meminimalkan permukaan serangan, atau sekadar memindahkan masalah keamanan yang paling sulit ke manajemen kemampuan dan kepercayaan operasional?

Saya menyelami lebih dalam aturan “finalitas” yang bergulir dari Dusk, dan satu detail mengubah cara saya memandang “finalitas.”
Sebuah blok tidak otomatis menjadi final hanya karena berhasil mendapatkan attestation. Dusk membedakan antara status yang accepted (diterima), attested (ter-attest), confirmed (ter-konfirmasi), dan final (final).
Sebuah blok yang accepted masih bisa digantikan oleh blok iterasi yang lebih rendah, sementara blok yang attested tidak bisa digantikan oleh blok tersebut.
Bagian yang menarik adalah bagaimana blok-blok berikutnya memperkuat kepercayaan. Blok yang accepted menjadi confirmed hanya setelah 2×n blok berturut-turut yang attested atau confirmed, di mana n mewakili iterasi sebelumnya yang belum attested. Finalitas kemudian bergantung pada apakah parent-nya sudah final.
Jadi pertanyaan yang lebih mendalam untuk @Dusk dan $DUSK bukan sekadar “Seberapa cepat finalitas?”
Melainkan: bagaimana seharusnya aplikasi memberi harga atas risiko saat sebuah blok melewati status perantara tersebut?
Untuk infrastruktur keuangan, perbedaan ini bisa jadi lebih penting daripada angka finalitas di judul.
Bagaimana Anda akan merancang sebuah aplikasi berdasarkan progresi accepted → confirmed → final dari Dusk?

#dusk

#dusk $DUSK @Dusk
Kebanyakan blockchain banyak membahas apa yang terjadi ketika semuanya berjalan dengan baik. Saya justru merasa kasus kegagalan lebih mengungkap.

Dusk punya detail yang sebelumnya belum saya perhatikan: konsensusnya dapat masuk ke mode darurat setelah 16 iterasi gagal ketika provisioner tidak tersedia atau terisolasi. Alih-alih sekadar berhenti, protokol terus membuka iterasi sampai sebuah blok kandidat mencapai kuorum.

Jika jaringan masih tidak bisa pulih, provisioner yang memegang mayoritas saham dapat meminta sebuah blok darurat. Blok tersebut tidak berisi transaksi; ia membawa seed baru yang dapat diverifikasi untuk membantu memulai kembali progres.

Yang membuat ini menarik adalah komprominya. Mode darurat bisa membuat jaringan tetap bergerak, tetapi desainnya secara eksplisit mengakui bahwa upaya pemulihan yang berlangsung bersamaan dapat meningkatkan kemungkinan terjadinya fork.

Jadi pertanyaan sebenarnya bukan apakah sebuah blockchain bisa menangani kondisi normal.

Seberapa besar risiko pemulihan yang seharusnya diterima oleh sebuah protokol konsensus sebelum “tetap hidup” menjadi lebih berbahaya daripada berhenti?

Apa yang lebih penting selama kegagalan jaringan yang parah?

Bergabunglah secara langsung bersama Kim

Saya dulu mengira privasi di blockchain berarti pengguna harus menangani semuanya sendiri, tetapi satu detail dalam model Phoenix dari Dusk membuat saya melihatnya dengan cara yang berbeda. @Dusk memungkinkan komputasi intensif didelegasikan kepada pihak ketiga tepercaya, termasuk memindai jaringan untuk transaksi yang dialamatkan kepada Anda menggunakan view key dan bahkan menghasilkan bukti ZK, sementara pihak yang didelegasikan tetap tidak bisa membelanjakan catatan Anda karena pihak tersebut tidak memiliki kunci rahasia lengkap Anda. Pemisahan itu lebih menarik daripada yang terdengar. Ini menunjukkan bahwa aktivitas blockchain yang bersifat privat tidak harus berarti setiap pengguna melakukan setiap komputasi mahal secara lokal. Anda bisa mendelegasikan pekerjaan berat sambil tetap memegang otoritas untuk membelanjakan aset Anda di bawah kendali Anda. Untuk aplikasi keuangan, di mana kegunaan dan privasi sama-sama penting, perbedaan itu bisa menjadi penting jika sistem seperti ini harus melayani orang yang bukan ahli kriptografi. Pertanyaan yang tersisa bagi saya adalah: apakah Anda akan mempercayai delegasi yang aman untuk transaksi privat, atau Anda lebih memilih menjaga setiap komputasi tetap dalam kendali Anda sendiri? $DUSK #dusk

$EDEN
$RED

#dusk $DUSK @Dusk
Dulu saya mengira privasi blockchain hanya berarti menyembunyikan data transaksi.

Semakin saya mempelajari Dusk, semakin menarik masalahnya: dapatkah transaksi keuangan tetap privat sambil tetap dapat diverifikasi?

Di sinilah Phoenix menarik perhatian saya. Dalam mode obfuscated-nya, Dusk menggunakan bukti pengetahuan nol sehingga jaringan dapat memverifikasi kepemilikan, integritas saldo, cakupan biaya, dan pencegahan double spend tanpa secara langsung memeriksa detail transaksi yang mendasarinya.

Bagi pasar keuangan, perbedaan ini penting. Buku besar yang sepenuhnya transparan dapat mengungkap posisi sensitif dan detail transaksi. Tetapi opasitas total menimbulkan masalah untuk audit dan regulasi.

Dusk mencoba mendekati titik tengah: membuktikan bahwa aturan dipatuhi tanpa harus mengekspos semuanya yang berada di balik transaksi.

Itu membuat saya berpikir secara berbeda tentang $DUSK .

Pertanyaan yang lebih besar adalah apakah model ini bisa bekerja pada skala dan kompleksitas pasar keuangan dunia nyata.

Apa yang lebih penting untuk adopsi blockchain institusional?

#dusk $DUSK @Dusk
Dulu saya mengira blockchain privasi terutama tentang menyembunyikan detail transaksi. Dusk membuat saya melihat pertanyaan infrastruktur yang lebih besar.
Whitepaper Dusk yang diperbarui menyoroti sesuatu yang sebelumnya saya lewatkan: efisiensi lingkungan adalah bagian dari desain jaringan. Dusk menggunakan Proof of Stake melalui Succinct Attestation, sementara Kadcast dirancang untuk mengurangi komunikasi jaringan yang tidak perlu.
Whitepaper tersebut mengutip penggunaan bandwidth sekitar 25–50% lebih rendah untuk Kadcast dibandingkan protokol Gossip populer. Hal ini penting karena efisiensi blockchain tidak hanya soal kecepatan transaksi. Konsensus, komunikasi, dan beban kerja kriptografi semuanya memengaruhi bagaimana sumber daya digunakan di seluruh jaringan.
Yang menarik perhatian saya adalah bahwa @Dusk menempatkan efisiensi berdampingan dengan privasi dan pembiayaan yang teregulasi, bukan sebagai isu yang sepenuhnya terpisah.
Jika infrastruktur keuangan bergerak ke on-chain, apakah efisiensi lingkungan harus dianggap sebagai kebutuhan inti, bukan sekadar pemikiran setelahnya?

#dusk $DUSK @Dusk
Sebuah blockchain yang dibangun untuk keuangan tetap perlu mudah bagi pengembang untuk membangunnya.
Di sinilah DuskEVM menjadi menarik. @Dusk menyediakan lingkungan eksekusi EVM sehingga pengembang dapat menggunakan Solidity dan alat yang sudah familiar seperti Hardhat dan Foundry, sementara DuskDS menangani settlement dan ketersediaan data di balik layar.
Artinya, pengembang dapat bekerja dengan lingkungan yang sudah mereka pahami alih-alih harus mempelajari tumpukan smart contract yang sepenuhnya asing dari nol.
Untuk aplikasi keuangan, lapisan pengembang ini penting karena infrastruktur hanya berguna ketika tim benar-benar bisa membangun, melakukan deploy, dan memelihara aplikasi di atasnya.
Arsitektur Dusk memisahkan eksekusi dari settlement, memberi pengembang jalur yang kompatibel dengan EVM sambil tetap menjaga fondasi settlement Dusk di bawahnya.

Bergabunglah secara langsung bersama Kim

#dusk $DUSK @Dusk
Apa yang membuat Dusk berbeda? Settlement dirancang untuk keuangan teregulasi, bukan sekadar transfer.
Saat kita membahas infrastruktur blockchain untuk pasar keuangan, memindahkan aset dari satu dompet ke dompet lain hanyalah satu bagian dari masalahnya. Tantangan yang lebih besar adalah memastikan bahwa leg aset, leg pembayaran, data, aturan akses, dan penyelesaian akhir dapat bekerja bersama dengan cara yang dapat diprediksi.
@Dusk mendekati ini melalui DuskDS, fondasi settlement dan ketersediaan data. DuskDS menyediakan konsensus, finalitas, dan ketersediaan data untuk Dusk L1, dengan finalitas deterministik yang dirancang untuk alur kerja pasar keuangan.
Mengapa finalitas deterministik itu penting?
Dalam pasar keuangan tradisional, para peserta perlu kepastian tentang kapan sebuah transaksi benar-benar diselesaikan. Untuk aset tokenisasi, ketidakpastian mengenai settlement dapat menimbulkan kompleksitas operasional, kebutuhan rekonsiliasi, dan koordinasi tambahan antara sistem yang berbeda.
Dusk dirancang dengan model yang berbeda. Infrastruktur ini dapat mendukung alur kerja aset teregulasi di mana settlement perlu dapat diprediksi, sementara bagian lain dari tumpukan menangani eksekusi smart contract, privasi, identitas, dan kontrol akses.
Ini menjadi sangat menarik untuk sekuritas tokenisasi dan aset digital teregulasi. Blockchain tidak terlalu berguna untuk pasar keuangan hanya karena ia dapat mencatat kepemilikan. Infrastruktur juga perlu menangani bagaimana aset ditransfer, bagaimana pembayaran berkoordinasi dengan transfer tersebut, informasi apa yang tetap bersifat privat, siapa yang memenuhi syarat untuk berpartisipasi, dan kapan keadaan akhir dianggap telah tersettlement.
Itulah mengapa DuskDS menjadi bagian penting dari arsitektur Dusk. Ini bukan sekadar lapisan transaksi lain. Ia menyediakan fondasi settlement yang dapat dibangun oleh aplikasi untuk membentuk alur kerja keuangan yang lebih lengkap.
$ACE
$HEI

Ayo ayo ayo

Bergabunglah siaran langsung bersama Kim

Privasi pada blockchain keuangan tidak berarti membuat seluruh sistem menjadi tidak terlihat. Di sinilah Dusk mengambil pendekatan yang menarik.

@Dusk menggunakan dua model transaksi asli: Moonlight, yang menyediakan transfer berbasis akun publik, dan Phoenix, yang menyediakan transfer terselubung (shielded) menggunakan bukti pengetahuan nol (zero knowledge proofs). Bagian pentingnya adalah model-model ini dapat memenuhi kebutuhan keuangan yang berbeda dalam jaringan yang sama.

Sebagai contoh, sebuah alur kerja mungkin memerlukan informasi tertentu agar tetap dapat diamati secara publik, sementara detail transaksi yang sensitif tidak boleh diekspos kepada setiap peserta pasar. Model privasi Dusk dirancang di sekitar pembedaan ini, dengan pengungkapan selektif yang memungkinkan pihak berwenang memperoleh informasi spesifik ketika bukti, audit, atau kebutuhan regulasi menuntutnya.

Ini adalah pertimbangan desain yang berarti untuk keuangan onchain yang tunduk pada regulasi, karena privasi dan pengawasan tidak selalu merupakan dua hal yang berlawanan. Tantangan sebenarnya adalah menentukan apa yang harus dipublikasikan, apa yang harus tetap rahasia, dan siapa yang dapat melihat informasi spesifik ketika diperlukan.

Itulah masalah yang coba diatasi oleh Dusk di tingkat infrastruktur.
@Dusk $DUSK #dusk

Apa yang paling penting untuk adopsi blockchain institusional?