#dusk $DUSK
Jujur saja, aku benar-benar terkejut. Hanya 5 poin padahal dapat 5K views terasa sangat tidak adil dan mengecewakan.
Posting hari ini dengan hati yang berat… tapi sebelum postingnya, ini scalp singkat:
Long $PORTAL 📈
Short $CYS 📉
jangan lupa untuk berterima kasih padaku saat kamu melakukan booking profit
Awalnya kupikir kalau kepotong di @Dusk berarti satu hal: kehilangan stake dan memulai ulang node
panduan pemulihan menggambar garis yang jauh lebih tegas.
Sanksi lunak dapat menangguhkan kelayakan seorang provisioner dan memindahkan sebagian dari active stake-nya menjadi locked stake. Stake itu masih milik operator dan bisa di-unbond.
Hard penalty berlaku untuk perilaku konsensus yang terbukti tidak valid seperti voting yang saling bertentangan atau equivocation. Sebagian dari stake akan hangus, dan memulai ulang atau restaking tidak bisa mengembalikannya
itulah pembeda yang benar-benar melekat.
Dusk memperlakukan missed participation dan contradictory participation secara berbeda. Versi yang sudah usang, downtime yang diperpanjang, sinkronisasi yang buruk, atau lalu lintas jaringan yang terblokir dapat menyebabkan kegagalan operasional. Menandatangani pesan yang saling bertentangan masuk ke perilaku yang bisa dibuktikan protokol sebagai tidak valid.
Peringatan duplicate-key membuat batasnya menjadi nyata.
Menjalankan consensus key yang sama pada dua node aktif bisa membuat kedua mesin menandatangani pesan yang tidak kompatibel meskipun operator mengira node kedua hanya cadangan.
Aku suka bahwa pemulihan dimulai dengan memperbaiki versi, sinkronisasi, konektivitas, dan konfigurasi kunci sebelum membuat posisi provisioner baru. Restaking tanpa menemukan penyebabnya hanya akan menempatkan posisi baru di belakang setup yang sama-sama rusak
model ini juga berarti redundansi harus dirancang dengan hati-hati. Cadangan yang dimaksud untuk meningkatkan ketersediaan bisa menciptakan risiko hard-slashing jika menjadi aktif dengan key yang sama.
Apakah memisahkan kegagalan operasional dari equivocation membuat penalti lebih adil, atau membuat manajemen consensus-key menjadi bagian yang paling tak kenal ampun dalam menjalankan provisioner?
Slashing provisioner di @Dusk mengangkat pertanyaan menarik
Apa yang lebih penting untuk menjaga validator tetap aman?
Jujur saja, aku benar-benar terkejut. Hanya 5 poin padahal dapat 5K views terasa sangat tidak adil dan mengecewakan.
Posting hari ini dengan hati yang berat… tapi sebelum postingnya, ini scalp singkat:
Long $PORTAL 📈
Short $CYS 📉
jangan lupa untuk berterima kasih padaku saat kamu melakukan booking profit
Awalnya kupikir kalau kepotong di @Dusk berarti satu hal: kehilangan stake dan memulai ulang node
panduan pemulihan menggambar garis yang jauh lebih tegas.
Sanksi lunak dapat menangguhkan kelayakan seorang provisioner dan memindahkan sebagian dari active stake-nya menjadi locked stake. Stake itu masih milik operator dan bisa di-unbond.
Hard penalty berlaku untuk perilaku konsensus yang terbukti tidak valid seperti voting yang saling bertentangan atau equivocation. Sebagian dari stake akan hangus, dan memulai ulang atau restaking tidak bisa mengembalikannya
itulah pembeda yang benar-benar melekat.
Dusk memperlakukan missed participation dan contradictory participation secara berbeda. Versi yang sudah usang, downtime yang diperpanjang, sinkronisasi yang buruk, atau lalu lintas jaringan yang terblokir dapat menyebabkan kegagalan operasional. Menandatangani pesan yang saling bertentangan masuk ke perilaku yang bisa dibuktikan protokol sebagai tidak valid.
Peringatan duplicate-key membuat batasnya menjadi nyata.
Menjalankan consensus key yang sama pada dua node aktif bisa membuat kedua mesin menandatangani pesan yang tidak kompatibel meskipun operator mengira node kedua hanya cadangan.
Aku suka bahwa pemulihan dimulai dengan memperbaiki versi, sinkronisasi, konektivitas, dan konfigurasi kunci sebelum membuat posisi provisioner baru. Restaking tanpa menemukan penyebabnya hanya akan menempatkan posisi baru di belakang setup yang sama-sama rusak
model ini juga berarti redundansi harus dirancang dengan hati-hati. Cadangan yang dimaksud untuk meningkatkan ketersediaan bisa menciptakan risiko hard-slashing jika menjadi aktif dengan key yang sama.
Apakah memisahkan kegagalan operasional dari equivocation membuat penalti lebih adil, atau membuat manajemen consensus-key menjadi bagian yang paling tak kenal ampun dalam menjalankan provisioner?
Slashing provisioner di @Dusk mengangkat pertanyaan menarik
Apa yang lebih penting untuk menjaga validator tetap aman?
- Fair penalty design
35%
- Consensus-key security
22%
- Reliable node uptime
13%
- All equally important
30%
23 Voting • Voting ditutup