Men Dusk’ning PLONK V3 aktivatsiyasini 3 590 904-blokda bir soat davomida kuzatdim, so‘ng bitta hamyon xavfsizligi liniyasi meni chalg‘itdi: repositoryda tashqi audit hali tugallanmagan, deb yozilgan.
Bu Dusk kriptografiyasini kuchsiz qiladi degani emas. Bu jiddiy kriptografik iste’dod uchun noto‘g‘ri ko‘rsatkich (sirt metrikasi) tanlanganini anglatadi.
Isbot tekshiruvchisi noto‘g‘ri (malformed) nuqtalarni, noto‘g‘ri public inputlarga mos kelmaydiganlarini va siqilgan (compressed) sxemalarni mutlaqo rad eta oladi, lekin foydalanuvchining tranzaksiyasi baribir extension kodi parolini chiqarish (password derivation) uchun JavaScript xotira ruxsatlari, node endpointi va imzolash so‘roviga bog‘liq bo‘lib qoladi.
Extension PBKDF2’ni 900 000 iteratsiya bilan ishlatadi va AES-GCM-256 ishlatiladi; mahalliy (native) yo‘l esa Stronghold hamda Argon2’dan foydalanadi. Yo‘llar turlicha — ishonch taxminlari ham turlicha.
Shuning uchun men xatti-harakatni o‘lchardim: nechta mustaqil build byte-ma’no jihatdan aynan bir xil Solidity verifikatorlarni yaratadi? Eng ko‘p gazni rad etilishigacha iste’mol qiladigan noto‘g‘ri (malformed) isbot qaysi? CLI Web Wallet’dagidek belgilangan (flagged) qabul qiluvchi (recipient) ogohlantirishini ham ko‘rsatadimi? Va imzolash yo‘li PLONK’ka qiyoslanadigan darajada ko‘rib chiqildimi?
Ba’zi asimmetriya normal. Brauzer hamyonlari JavaScript xotirasini nolga keltirishni (zeroization) kafolatlay olmaydi, verifikatorni soddaroq joylashtirish esa gaz xarajati tushmasa ham o‘z qiymatiga ega.
Lekin Dusk’ning institutsional xavfsizligi eng kuchsiz vakolat (authority) bo‘lgan tarkibiy qism bilan belgilanadi, uning eng nafis matematikasi bilan emas. Men auditlar tranzaksiya yo‘li bo‘ylab oxirigacha kuzatilishini kuzatyapman.
#dusk $DUSK @Dusk
Bu Dusk kriptografiyasini kuchsiz qiladi degani emas. Bu jiddiy kriptografik iste’dod uchun noto‘g‘ri ko‘rsatkich (sirt metrikasi) tanlanganini anglatadi.
Isbot tekshiruvchisi noto‘g‘ri (malformed) nuqtalarni, noto‘g‘ri public inputlarga mos kelmaydiganlarini va siqilgan (compressed) sxemalarni mutlaqo rad eta oladi, lekin foydalanuvchining tranzaksiyasi baribir extension kodi parolini chiqarish (password derivation) uchun JavaScript xotira ruxsatlari, node endpointi va imzolash so‘roviga bog‘liq bo‘lib qoladi.
Extension PBKDF2’ni 900 000 iteratsiya bilan ishlatadi va AES-GCM-256 ishlatiladi; mahalliy (native) yo‘l esa Stronghold hamda Argon2’dan foydalanadi. Yo‘llar turlicha — ishonch taxminlari ham turlicha.
Shuning uchun men xatti-harakatni o‘lchardim: nechta mustaqil build byte-ma’no jihatdan aynan bir xil Solidity verifikatorlarni yaratadi? Eng ko‘p gazni rad etilishigacha iste’mol qiladigan noto‘g‘ri (malformed) isbot qaysi? CLI Web Wallet’dagidek belgilangan (flagged) qabul qiluvchi (recipient) ogohlantirishini ham ko‘rsatadimi? Va imzolash yo‘li PLONK’ka qiyoslanadigan darajada ko‘rib chiqildimi?
Ba’zi asimmetriya normal. Brauzer hamyonlari JavaScript xotirasini nolga keltirishni (zeroization) kafolatlay olmaydi, verifikatorni soddaroq joylashtirish esa gaz xarajati tushmasa ham o‘z qiymatiga ega.
Lekin Dusk’ning institutsional xavfsizligi eng kuchsiz vakolat (authority) bo‘lgan tarkibiy qism bilan belgilanadi, uning eng nafis matematikasi bilan emas. Men auditlar tranzaksiya yo‘li bo‘ylab oxirigacha kuzatilishini kuzatyapman.
#dusk $DUSK @Dusk