#dusk $DUSK Hozir men @Dusk ning xavfsizlik masalasini ko‘rib, “protokol xavfsizligi” va “ekotizim xavfsizligi”ni atay ajratib talqin qilaman. Birinchisi konsensus, kriptografiya implementatsiyasi, aqlli kontraktlar va virtual mashina (VM) chegaralarini o‘z ichiga oladi; ikkinchisi esa hamyon, frontend, ko‘prik (bridge) xizmati, kalitlar boshqaruvi, nod(lar)ni ekspluatatsiya qilish (operatsiya), hamda uchinchi tomon integratsiyasini qamrab oladi. Ko‘p loyihalar voqea yuz berganidan keyin “asosiy zanjirda muammo yo‘q” degan gapni ta’kidlashni yoqtiradi — bu ba’zan rostdir. Ammo $DUSKni ushlab turgan va ekotizim mahsulotlaridan foydalanadiganlar uchun mas’uliyat chegaralari qanchalik aniq bo‘linib ketgani bilan aktiv avtomatik ravishda xavfsiz bo‘lib qolmaydi.$SPCXB
Dusk kabi maxfiylik (privacy)ga yo‘naltirilgan moliyaviy ssenariylarga xizmat qiladigan tarmoqda xavfsizlik talablari aslida yanada yuqoriroq. Chunki foydalanuvchilar va muassasalar maxfiylik imkoniyatlaridan foydalanishga faqat algoritm ishonchli ekaniga ishonishning o‘zi yetmaydi: kirish nuqtasi, xizmatlar va operatsion jarayonlar yetarlicha tiyilgan bo‘lishi kerak, ya’ni haddan oshmaydigan nazoratda bo‘lishi lozim. Imzo kalitini boshqarishda bitta xato, avtorizatsiya sahifasi almashtirilib ketishi, ko‘prik monitoringida bitta kechikish — bularning barchasi bazaviy protokolning puxta dizaynini chetlab o‘tishga imkon berishi mumkin. Texnik tizim eng zaif bo‘ladigan joy ko‘pincha eng murakkab kriptografiya qismida emas, balki turli komponentlar o‘rtasidagi “default trusted” (odatda ishonchli deb qabul qilinadigan) interfeys va o‘tish nuqtalarida bo‘ladi.$SNDKB
Men ochiq qayta tahlil (public recap) va uzluksiz tuzatishlarning ahamiyatini tan olaman, lekin takroriy tahlildan keyin amalda tekshirib bo‘ladigan yaxshilanishlar paydo bo‘ldimi-yo‘qmi, shuni ko‘proq muhim deb bilaman. Masalan, muhim ruxsatlar (critical permissions) to‘liq ajratilganmi, sezgir operatsiyalar ko‘p bosqichli tasdiqni talab qiladimi, hot-wallet yoki xizmat akkauntlarining risk ta’siri (exposure) uchun aniq maksimal limit belgilanganmi, anomallikdagi tranzaksiyalar o‘z vaqtida aniqlanadimi, foydalanuvchi xizmat qaysi holatda turganini bilib olishi mumkinmi. DUSK ekotizimi uchun esa xavfsizlik e’lonlari shunchaki hodisadan keyingi izoh bo‘lib qolmasligi kerak — ular foydalanuvchilarga risklarni boshqarish yetukligi darajasini baholash uchun material bo‘lishi lozim.
Shu sababli, men bitta muammo bo‘lgani Duskning texnik yo‘nalishini inkor etish uchun yetarli, deb hisoblamayman, lekin “allaqachon tuzatildi”ni ham munozara yakuni deb qabul qilmayman. Haqiqatan kuzatishga arzigani shuki: tuzatishlar xuddi shunday yo‘llarni ham qamrab oladimi, tashqi auditlar (external review) davom etyaptimi, risk haqida ogohlantirishlar yetarlicha shaffofmi, va jamoa bosim ostida bo‘lganda tezda tekshirib bo‘ladigan ma’lumot bera oladimi. Maxfiy moliya ishonchni talab qiladi, ammo ishonch faqat shiorlar ustiga qurilmasligi kerak. Agar Dusk yanada murakkab aktivlar va foydalanuvchilarni qabul qilmoqchi bo‘lsa, har bir xizmat qatlamini xuddi shunday qat’iy savollar bilan tekshirishga bardosh bera olishi shart: anomaliya ro‘y bersa, kim uni aniqlay oladi, kim cheklay oladi, kim tushuntira oladi va yana kim buning uchun mas’ul bo‘ladi.
#dusk @Dusk