Saya kembali menelusuri dokumentasi dan menghabiskan waktu lebih lama dari perkiraan pada dua area: toleransi kesalahan Kadcast dan aturan finalitas protokol.
Awalnya, penggunaan Kadcast atas DHT Kademlia terlihat cukup jelas. Node dapat memperbarui tabel routing ketika rekan (peer) menghilang, sementara beberapa rekan dalam setiap bucket menyediakan jalur alternatif ketika satu node gagal. Namun, saya mulai bertanya: seberapa cepat jaringan bisa beradaptasi ketika node terus-menerus bergabung, keluar, atau menjadi tidak andal? Dan apakah partisipasi yang sangat tidak merata dapat menciptakan bagian-bagian yang lebih lemah dari struktur routing?
Model state konsensus bahkan lebih menarik.
Sebuah blok dengan @Dusk dapat berpindah melalui tahap accepted, attested, confirmed, dan akhirnya final. Yang membantu saya memahaminya adalah perbedaan antara blok attested dan accepted. Jika iterasi sebelumnya gagal, sebuah blok yang berhasil mungkin saja diterima (accepted), tetapi masih dapat digantikan (replaceable). Semakin banyak iterasi yang gagal, semakin lama waktu konfirmasi dapat berlangsung.
Sebagai contoh, jika ada dua iterasi gagal sebelumnya, aturan mensyaratkan empat blok berturut-turut yang attested atau confirmed sebelum sebuah blok accepted menjadi confirmed.
Hal ini membuat saya mempertanyakan keamanan dan desentralisasi. Apakah mekanisme ini memberikan perlindungan yang cukup terhadap instabilitas jaringan sementara tanpa membuat finalitas menjadi terlalu lambat? Bagaimana perilaku protokol ketika kegagalannya berkorelasi di banyak node, bukan hanya kasus yang terisolasi?
Saya juga ingin tahu bagaimana dinamika tabel routing dan finalitas konsensus berinteraksi selama periode gangguan jaringan yang serius.
Pemahaman saya masih berkembang, jadi saya akan tertarik mendengar bagaimana orang lain menafsirkan trade-off (pertukaran) ini.
Skenario kegagalan apa menurut Anda yang ditangani Kadcast dengan sangat baik? Dan di bagian mana asumsi-asumsinya bisa diuji?
$DUSK #dusk
#dusk $DUSK @Dusk
Awalnya, penggunaan Kadcast atas DHT Kademlia terlihat cukup jelas. Node dapat memperbarui tabel routing ketika rekan (peer) menghilang, sementara beberapa rekan dalam setiap bucket menyediakan jalur alternatif ketika satu node gagal. Namun, saya mulai bertanya: seberapa cepat jaringan bisa beradaptasi ketika node terus-menerus bergabung, keluar, atau menjadi tidak andal? Dan apakah partisipasi yang sangat tidak merata dapat menciptakan bagian-bagian yang lebih lemah dari struktur routing?
Model state konsensus bahkan lebih menarik.
Sebuah blok dengan @Dusk dapat berpindah melalui tahap accepted, attested, confirmed, dan akhirnya final. Yang membantu saya memahaminya adalah perbedaan antara blok attested dan accepted. Jika iterasi sebelumnya gagal, sebuah blok yang berhasil mungkin saja diterima (accepted), tetapi masih dapat digantikan (replaceable). Semakin banyak iterasi yang gagal, semakin lama waktu konfirmasi dapat berlangsung.
Sebagai contoh, jika ada dua iterasi gagal sebelumnya, aturan mensyaratkan empat blok berturut-turut yang attested atau confirmed sebelum sebuah blok accepted menjadi confirmed.
Hal ini membuat saya mempertanyakan keamanan dan desentralisasi. Apakah mekanisme ini memberikan perlindungan yang cukup terhadap instabilitas jaringan sementara tanpa membuat finalitas menjadi terlalu lambat? Bagaimana perilaku protokol ketika kegagalannya berkorelasi di banyak node, bukan hanya kasus yang terisolasi?
Saya juga ingin tahu bagaimana dinamika tabel routing dan finalitas konsensus berinteraksi selama periode gangguan jaringan yang serius.
Pemahaman saya masih berkembang, jadi saya akan tertarik mendengar bagaimana orang lain menafsirkan trade-off (pertukaran) ini.
Skenario kegagalan apa menurut Anda yang ditangani Kadcast dengan sangat baik? Dan di bagian mana asumsi-asumsinya bisa diuji?
$DUSK #dusk
#dusk $DUSK @Dusk
