Gavin Wood nutqi: JAM yetkazib berilishi va JAMga ZKni joriy etish bo‘yicha o‘rta va uzoq muddatli strategiya!

Ushbu maqola Gavin Woodning o'tgan oy Web3 Summitda qilgan nutqining o'zbek tilidagi tarjimasidir! Mazkur seriya ko'plab mazmunni o'z ichiga olganligi sababli, biz uni to'rt qismga bo'lib e'lon qilamiz. Bu birinchi qism bo'lib, asosiy mazmun quyidagilardan iborat:

• JAM yetkazib berish holati
• ZK samaradorligi yaxshilandi, lekin hali ham tijorat uchun yetarli emas
• 33 marta qayta hisoblash vs matematik isbot: ikki xil xavfsizlik rejimining haqiqiy narxi
• Bitta ZK-JAM tuguni qancha turadi? Javob siz o'ylagandan 10 baravar qimmat!
• ZKning JAMdagi qisqa, o'rta va uzoq muddatli rivojlanish yo'li

Keling, Gavin qanday ajoyib fikrlar bilan o'rtoqlashganini birga ko'rib chiqamiz!

Xo'sh, ko'p cho'zmay, men ushbu nutqda nimalar haqida gaplashmoqchiman?

Avvalo, men Polkadot haqidagi umumiy qarashlarimni, ya'ni hozirgi fikrlash nuqtamni baham ko'rmoqchiman, buni "joriy holatning tezkor ko'rinishi" deb tushunsa bo'ladi. Ehtimol, sizlar JAM haqida eshitgansiz — bu men uzoq muddat o'rgangan loyiha bo'lib, Polkadot bilan chambarchas bog'liq. Biz uni oxir-oqibat Polkadotning keyingi rivojlanish bosqichini qo'llab-quvvatlashini umid qilamiz. Bundan tashqari, men nol bilimli kriptografiya (ZK) texnologiyalari haqida ham gaplashaman, ayniqsa ularning blokcheyn funksiyalarini kengaytirishdagi qo'llanilishi haqida.

Bundan tashqari, men DOT token iqtisodiy modeli haqida ham fikr bildiraman. Keyin, yaqinda o'rgangan yangi g'oyalarim bilan o'rtoqlashaman, bu izlanishlar mavjud imkoniyatlarni yaxshilash va hatto Polkadot hamda kengroq Web3 olamiga yangi imkoniyatlar olib kelishga qaratilgan. Bu qismda bir nechta yo'nalishlar bo'ladi, ba'zilari batafsil, ba'zilari esa qisqacha ko'rib chiqiladi. Xo'sh, rasmiy boshlaymiz.

JAMning hozirgi yetkazib berish holati

JAM dastlabki versiyasi 0.1 bo'lib, hozirda asta-sekin 1.0 ga yaqinlashmoqda. U 1.0 ga yetganda, bu JAM protokoli Polkadot yangilanishi uchun tayyor degani bo'ladi. Protokol barqarorlashgani sari, bizning e'tiborimiz optimallashtirishga, ayniqsa gas modellashtirishga qaratilmoqda. Joriy yil boshida men East Prague Ethereum konferensiyasida ham shu mavzuda maxsus nutq qilgan edim. Gas modellashtirish o'zi juda qiziqarli, lekin bir vaqtning o'zida nihoyatda murakkab masala.

JAM joriy yilda protokol auditini boshlashi kutilmoqda. 0.7 versiya seriyasida bajarilishi kerak bo'lgan ishlar ko'p emas; lekin 0.8 versiyada gas modellashtirish rasmiy joriy qilinadi va ish hajmi sezilarli darajada oshadi. Menimcha, biz bu yil 0.9 versiyaga yetamiz va o'shanda auditni rasmiy boshlaymiz.

Albatta, asosiy protokolga ega bo'lish bir narsa, uning ustida dasturlash imkoniyati esa boshqa narsa. Sizga SDK, hujjatlar va boshqa ishlab chiqish vositalari kerak bo'ladi. Bu qism hozirda hali erta bosqichda. Hozir JAMda dastur ishlab chiqish mumkin bo'lsa-da, Parityda asosan men SDK qurilishi va chiqarilishini ilgari suryapman. Lekin, real holat shuki, bu hali kelgusi oylar va hatto yillar davomida doimiy sarmoya va say-harakat talab qiladi. Albatta, SDK ishlab chiqilishi Parity bilan cheklanmaydi. Men yana ko'proq jamoalar JAM SDKlarini qurishga qo'shilishini kutyapman.

Biz allaqachon xizmatlararo xabar almashinuvi standartlarini ishlab chiqishni boshladik, bu JAM versiyasidagi XCM/XCMP deb qaralishi mumkin. Shu bilan birga, CoreVM SDKning bir qismiga aylanib bormoqda va kelgusi oylar davomida doimiy takomillashtiriladi. CoreVM hozirda ko'plab funksiyalarni qo'llab-quvvatlaydi, masalan, audio chiqishi, video chiqishi, ma'lumotlar kiritish/chiqarish, tranzaksiya ishlov berish va yaqin orada ichki xizmatlar. Hozircha u EVMni qo'llab-quvvatlamaydi, lekin bu biz rejalashtirayotgan yangi funksiya. Bundan tashqari, ilgari men "coreplay" deb atagan asosiy hamkorlikli rejalashtirish mexanizmi ham kelgusi 12–24 oy ichida amalga oshirilishi rejalashtirilgan.

Yaqinda JAM chat guruhida kimdir juda qiziqarli savol berdi: Qanday qilib meni JAMning yagona xatolik nuqtasiga (single point of failure) aylanishimdan saqlanish mumkin? Hozirda JAM protokolining rivojlanishi to'liq mening Gray Paperda yozganlarimga bog'liq. Bu shuni anglatadiki, agar menga biror narsa bo'lsa, butun loyiha to'xtab qolishi mumkin. Albatta, bu JAM ham, men uchun ham yaxshi emas.

Shu sababli, biz Gray Paper mazmunini JAMning texnik spetsifikatsiyasi sifatida ko'ramiz. Eng so'nggi Gray Paper — bu eng so'nggi JAM. Agar biror versiyadagi Gray Paper auditdan o'tgan bo'lsa, u belgilagan JAM protokoli ishlab chiqarish darajasiga yetgan degani, bu juda aniq.

Xo'sh, kelajakda Gray Paper yangilanishi to'liq men tomonidan boshqarilmasa, u qanday rivojlanadi?

Mening tasavvurimda, tahririyat kengashi tuziladi. Dastlabki a'zolar Gray Paper yozilishida haqiqiy ishtirok etgan, uni chuqur tushungan va amaliy hissa qo'shganlardan iborat bo'ladi. Men bu a'zolar JAMni amalga oshirishda yuqori texnik ishtirokni saqlashlarini kutaman. Men o'zim to'liq chekinmayman, bosh muharrir bo'lib qolaman, lekin o'z yukimni kamaytirishni va boshqalarga o'zgartirishlarni taklif qilish, ko'rib chiqish va birlashtirish huquqini berishni istayman.

JAM 1.0 versiyasidan oshgach, bu tahririyat kengashi yuqori darajadagi mas'uliyatni o'z zimmasiga oladi:

• Faqat kichik o'zgarishlarni ko'rib chiqish emas, balki JAMning rivojlanish yo'nalishi va ustuvorligini belgilash;
• Turli fikrlar paydo bo'lsa, kengashning jamoaviy qarori eng muhim ovoz bo'lishi kerak.

Men yordamchi tayinlashni rejalashtiryapman, shunda men yo'q bo'lganimda, ta'tilda yoki boshqa holatlarda ishni davom ettira oladi. Uzoq muddatda, yordamchilar yangi tahririyat kengashi a'zolarini tanlash, taklif qilish va qaror qilish uchun mas'ul bo'lishadi, bu butun mexanizmning o'z-o'zini boshqarishini ta'minlaydi. Nihoyat, men ushbu boshqaruv tizimi asta-sekin mustaqil bo'lishini, hatto tashqi tashkilotlar, masalan, Polkadot Fellowship ishtirokini ham qabul qilishini istayman.

Men Gray Paper'ni ochiq litsenziya ostiga qo'yishni rejalashtiryapman, qaysi birini tanlash hali aniq emas, lekin ehtimol copyleft litsenziyasi va patent suiiste'molini oldini oluvchi ba'zi bandlar bo'ladi.

Polkadot boshqaruvi esa, o'zi qaysi protokolni ishlatishni to'liq mustaqil hal qiladi. Polkadot — bu suveren protokol, boshqaruv mexanizmi esa shu suverenitetning ifodasidir. Hozirda Polkadot boshqaruvi aniq bayon qilgan: u JAMni qabul qilmoqchi. Bu yaxshi. Shu bilan birga, boshqa tarmoqlar ham JAMdan foydalanishni tanlashi mumkin, chunki JAM ochiq protokol.

Agar kelajakda JAM rivojlanishda davom etsa, Polkadot eng so'nggi versiyani kuzatib borishni tanlashi mumkin; agar JAMning rivojlanish yo'nalishidan norozi bo'lsa, ma'lum bir versiyada to'xtab, hatto asosiy protokolni o'zgartirishi yoki Gray Paper'ni fork qilishi mumkin. Bu JAM o'zi mustaqil tizim ekanini ko'rsatadi va men ham JAM va Polkadot uzoq muddatli o'zaro foydali aloqada bo'lishini istayman. Albatta, agar bir kun ular mustaqil yo'l tanlasa, bu ham mumkin.

Har ikki tomon kelishuvda bo'lsa, men Polkadot boshqaruvi Gray Paper tahririyat kengashi faoliyatida faol ishtirok etishini kutaman. Agar kelajakda boshqa protokollar JAMni qabul qilsa, men ular ham xuddi shunday ishtirok etishini istayman.

Xo'sh, bu JAMning hozirgi rivojlanishi yoki yaqin orada erishiladigan bosqichi. Endi men nol bilimli isbotlar (ZK) haqida gaplashmoqchiman.

ZK samaradorligi yaxshilandi, lekin hali ham tijorat uchun yetarli emas

Ko'pchilik mendan shunday savol so'raydi: ZK (nol bilimli isbot) qachon haqiqiy tijoratda ishlatiladi?

Ethereum ZKga juda qiziqadi, ularning yo'l xaritasi deyarli to'liq ZK atrofida qurilgan. JAMda esa, biz ZKni faqat blok qurilishidagi ba'zi maxsus konsensus mexanizmlarida ishlatamiz, umumiy tizim unga tayanmaydi. Lekin, baribir, bu jiddiy o'ylab ko'rish kerak bo'lgan masala:

• ZK qachon haqiqiy hisoblash quvvatini kengaytirish va tijoratda ishlatish uchun mos texnologiyaga aylanadi?
• Bu hozir sodir bo'ldimi?
• Agar hali bo'lmasa, yana qancha vaqt kerak?

Agar siz Ethereum ekotizimidagi ma'lumotlarni (masalan, ethprovers.com) ko'rsangiz, ZK allaqachon iqtisodiy jihatdan foydali ekanini ko'rsatuvchi hayratlanarli raqamlarni ko'rasiz. Lekin biz tekshirdik va bu raqamlar haqiqatga to'g'ri kelmaydi. Yaxshi tomoni shundaki, hali to'liq foydali bo'lmasa-da, 18 oy oldingiga qaraganda farq ancha qisqardi.

Masalan: hozirgi JAM virtual mashinasi PVM (JAM versiyasidagi EVM) kodni bajarishda tabiiy bajarilishdan taxminan 34% sekinroq. Boshqacha aytganda, agar tabiiy muhitda dastur 34 daqiqada ishlasa, PVMda uni ishlatish uchun taxminan 100 daqiqa kerak bo'ladi.

Bu natija juda yaxshi, biz undan mamnunmiz va hali ham yaxshilash imkoniyati bor.

Albatta, ba'zi holatlarda farq kattaroq bo'ladi, masalan, 50% yoki undan ko'p. Ayniqsa, SHA-1 xesh kabi vazifalarda, PVM bajarilishi sekinroq. Bu, ehtimol, tabiiy muhitda kompilyator SIMD buyruqlar to'plami yoki boshqa optimallashtirishlardan foydalana olgani, PVM esa hozircha bunga qodir emasligi bilan bog'liq.

Endi yana bir muhim raqamga qaraymiz: bu hozirgi eng yaxshi isbotlovchi Succinct SP1dan foydalanganda, bajarilishni isbotlash narxi — ya'ni PVMda to'g'ridan-to'g'ri ishlatishga nisbatan ortiqcha xarajat. E'tibor bering, bu yerda taqqoslanayotgan narsa PVM, tabiiy muhit emas. PVM o'zi ham tabiiydan taxminan 34% sekinroq.

Hozirgi test natijalari shunday: biz eng so'nggi dasturiy ta'minotdan foydalandik va faqat bitta GPU ishlatilganini faraz qildik (chunki ochiq kodli kutubxona faqat bitta GPUni qo'llab-quvvatlaydi). Agar yopiq kodli tijorat versiyasi bo'lsa, ehtimol GPU klasteriga kengaytirish mumkin, lekin ochiq kodli muhitda faqat shunday. Test mazmuni avvalgidek, yana SHA-1 xesh, taqqoslash bir xil bo'lishi uchun.

Xo'sh, o'zgarish qayerda?

18 oy oldin biz shunga o'xshash tajriba o'tkazganmiz, o'shanda raqamlar ancha katta edi, taxminan 60 milliondan 64 milliongacha. Hozirgi xarajat ancha kamaydi.

Buning ikki sababi bor:

• Birinchidan, GPU ijarasi arzonlashdi;
• Ikkinchidan, dasturiy ta'minotning o'zi juda katta optimallashtirildi, ehtimol bir necha baravar yoki undan ham ko'p.

Qo'shimcha qilish kerakki, 18 oy oldin biz SP1 emas, RISC-0 isbotlovchidan foydalanganmiz. Lekin, baribir, natijalar shuni ko'rsatadiki: ilg'or texnologiyalar tez rivojlanmoqda va taraqqiyot sezilarli.

2025 yil iyul holatiga ko'ra, SP1 (Succinct isbotlovchisi) yordamida bajarilish izini (execution trace) isbotlash, PVMda xavfsiz bajarilishdan 306,451 baravar qimmatga tushadi. So'nggi 18 oyda isbotlash narxi taxminan 200 baravar kamaydi, lekin bu raqam hali ham juda katta. ZK texnologiyasi tez rivojlanmoqda, lekin hali ham to'g'ridan-to'g'ri bajarilishdan ancha qimmat.

Endi Gas hisoblashga o'tamiz.

Kodni tez ishlatish bir narsa, lekin eng muhimi — unga ishonish mumkin bo'lishi. Agar kimdir ataylab "sekinlashtiruvchi" kod yozsa-chi? Konsensus mexanizmida, agar tizim belgilangan vaqtda kelishuvga erishishi kerak bo'lsa, lekin kod ataylab sekin ishlash uchun yozilgan bo'lsa, butun tizim to'xtab qolishi yoki ishdan chiqishi mumkin.

Polkadotda bu muammo unchalik dolzarb emas, chunki bizda parallel zanjir slot auktsionlari bor. Ya'ni, tizimga kod yuboradiganlarning shaxsi aniq, ular slotni haqiqiy pulga sotib olishgan, shuning uchun zararli harakat qilish ehtimoli juda past.

Lekin, agar biz bu holatni ochiq va umumiy muhitga ko'chirsak, muammo jiddiylashadi.

Yechim nima?

Ya'ni, kodning bajarilishining eng yomon holatda qancha vaqt olishini oldindan taxminan hisoblash kerak — ya'ni eng yomon holatda u qancha ishlaydi. Keyin, har qanday holatda ham, uning ishlash vaqti bu eng yomon holatdan sekin bo'lmasligiga ishonch hosil qilish kerak. Aks holda, kimdir kodni biz kutganimizdan 10 baravar sekinlashtira olsa, bu katta muammo.

Xo'sh, hozir bizning eng yomon holat bahomiz qanday?

SHA-1 xesh misolida, hozirgi natija shunday: xavfsizlikni ta'minlash uchun, biz uni odatdagidan 4.5 baravar sekin ishlashi mumkin deb hisoblashimiz kerak. Ya'ni, agar kod odatda 1 soniyada ishlasa, eng yomon holatda uni 4.5 soniya deb hisoblashimiz kerak. Shunda eng zararli hujumchi ham uni bundan sekinlashtira olmaydi.

Bu "bir necha baravar ko'proq hisoblash" usuli, vaqt cheklovli konsensus mexanizmida xavfsizlikni ta'minlash uchun zarur.

Kelajakda, bu ko'paytma yana kamayishi mumkin, ya'ni baholash yanada aniq va samarali bo'ladi. Hozirgi 4.5 baravar — bu bir-ikki hafta harakatdan so'ng erishilgan eng yaxshi natija. Optimistik qarasak, kelajakda 3 baravarga tushishi mumkin, lekin bundan past bo'lmaydi.

33 marta qayta hisoblash vs matematik isbot: ikki xil xavfsizlik rejimining haqiqiy narxi

Polkadot va JAMda biz hisoblash xavfsizligini ta'minlash uchun elves deb ataladigan protokoldan foydalanamiz. Uning vazifasi — ma'lum bir hisoblash to'g'ri bajarilganini aniqlash.

Aslida, elves va nol bilimli isbot (ZK) bir-biriga o'xshaydi:

• ZK matematik isbotdan foydalanadi, to'g'ridan-to'g'ri "temir isbot" beradi;
• Elves esa ko'proq kriptoiqtisodiy o'yin: ishtirokchilar natijaning to'g'riligini imzo va ba'zi qoidalarga asoslanib isbotlashadi, asosiy shart — "yomon odamlar uchdan birdan oshmasligi".

Elves ishlaganda, hisoblash bir necha marta takroran bajariladi. Ishtirokchilar o'zlari tasodifiy ravishda bu "qayta hisoblash"ni bajarish-bajarmaslikka qaror qilishadi.

Natija: bu rejimda ish o'rtacha 33 marta qayta bajariladi. Shuning uchun uning narxi oddiy bajarilishdan taxminan 33 baravar yuqori.

Shunday qilib, biz ZK va elves narxi farqini hisoblashimiz mumkin. Javob: ZK elvesdan taxminan 4000 baravar qimmat. Boshqacha aytganda, nol bilimli isbot yordamida to'g'rilikni tekshirish, elves kriptoiqtisodiy tizimidan foydalanishga qaraganda ancha qimmat. Buni turli Rollup yechimlarining narxini taqqoslash deb tasavvur qilishingiz mumkin.

PolkaWorld izohi: Elvesni tasavvur qiling, sinfda 33 o'quvchi bir xil uy vazifasini ko'chiradi, oxirida javoblarni solishtirib, muammo yo'qligini tasdiqlashadi; ZK esa siz uchun matematika doktori "mutlaqo xatosiz isbot" yozib beradi, lekin doktor bu isbotni yozish uchun bir necha kun vaqt sarflaydi.

4000 baravar farq juda katta, ZK amaliyotda foydali bo'lishi uchun uning narxi ancha kamayishi kerak. Albatta, biz elvesni ham optimallashtirib, uni yanada samaraliroq qilishimiz mumkin.

Lekin, narx muammosi faqat apparatga bog'liq emas. Yana bir nechta muhim jihatlar bor:

• Ekspluatatsiya xarajatlari (sysadmin): Qaysi apparatda ishlasangiz ham, ekspluatatsiya xodimlari maoshi deyarli bir xil. Ko'pincha ekspluatatsiya xarajatlari apparatdan ham qimmatroq bo'ladi.
• Staking xarajatlari: Yomon odamlar uchdan birdan oshmasligi uchun tizimda filtr mexanizmi bo'lishi kerak. Polkadotda bu "staking + jazolash mexanizmi" orqali amalga oshiriladi. Ya'ni, ishtirokchilar bir qism mablag'ni (xavf kapitali) garovga qo'yishlari kerak, shunda "yaxshi validatorlar" va "yomon validatorlar" ajratiladi.

Muammo shundaki: stakingning o'zi ham qimmat, bu yana bir ortiqcha xarajat (buni keyinroq batafsil tushuntiraman).

Taqqoslash uchun, ZKning o'zi staking yukidan xoli. ZKning mantiqi juda oddiy: yoki isbot to'g'ri, yoki noto'g'ri, darhol ko'rinadi.

Lekin muammo shundaki, ZK isbotini yaratish juda sekin. Agar bitta GPUda ishlatsangiz, bir necha soat kerak bo'lishi mumkin; PVMda (yoki oddiy CPUda) xuddi shu hisoblashni to'g'ridan-to'g'ri bajarish uchun bir necha millisekunddan bir necha sekundgacha vaqt ketadi. Farq juda katta.

Lekin, allaqachon ko'rsatib berilgan, GPU klasterini paralellash orqali kechikishni qisqartirish mumkin. Agar yetarlicha GPU bir-biriga ulangan bo'lsa, kechikishni kamaytirish mumkin. Lekin muammo shundaki:

Paralellash samaradorligi noma'lum: ya'ni, xarajat qancha oshadi, hozircha aniq emas. Tajriba o'tkazganlar bu ma'lumotni oshkor qilishmagan, ehtimol ular ham oshkor qilishni istamagan. Shuning uchun, biz yoki o'zimiz yashirin tajriba o'tkazamiz, yoki o'zimiz kod yozamiz, yoki hali topilmagan tadqiqotlarni izlaymiz.

Bundan tashqari, tekshirish va hisob-kitob masalalari ham bor.

Masalan, Ethereum L1da tekshirish, hozirda isbot yaratishdan ham qimmatroq. Biz hisoblab chiqdik, bitta isbot yaratish taxminan 1 dollar yoki 1.20 dollar, lekin Ethereum L1da tekshirish esa 1.25 dollar. Albatta, agar o'z zanjiringiz bo'lsa, tekshirish ancha arzon bo'lishi mumkin, lekin baribir sizga quyidagilar kerak bo'ladi:

• Tekshirish (verification)
• Hisob-kitob (settlement)
• Yakuniylik (finality)
• Saqlash (storage)

Bu bosqichlarni ZK yo'q qila olmaydi. Shuning uchun, oxir-oqibat, siz hali ham zararli ishtirokchilar uchdan birdan oshmasligiga ishonch hosil qilishingiz kerak, ya'ni yana staking mexanizmiga qaytasiz, xuddi Ethereum L1, Polkadot va ko'pchilik zanjirlar kabi.

Bitta ZK-JAM tuguni qancha turadi? Javob siz o'ylagandan 10 baravar qimmat!

Xo'sh, endi boshqa tomondan qaraymiz: agar ZK-JAM kafolatlovchi tuguni (guarantor node) bo'lsa, uning ishlash narxi taxminan qancha?

Qisqacha tushuntiraman: JAMda kafolatlovchilar (guarantors) deb ataladigan rollar bor, ular tizimning "qo'riqchilari"ga o'xshaydi. Barcha tranzaksiyalar yoki vazifalar avval ularga topshiriladi, ular hisoblashni bajarib, natijani paketlab, boshqa validatorlarga uzatadi. Validatorlar ularning natijasini qayta tekshirishi mumkin, lekin har doim ham tekshirishmaydi.

Endi bir ssenariyni tasavvur qilamiz:

• Qayta tekshirish bosqichini olib tashlash (boshqalar kafolatlovchining ishini takroran tekshirishmaydi);
• Staking talabini pasaytirish (chunki kafolatlovchining ishonchiga to'liq tayanilmaydi);
• Lekin kafolatlovchi GPU klasterini ishlatishi va ZK isbotini yaratishi majburiy.

Xo'sh, bunday qilish narxi qancha?

Hisob-kitoblarga ko'ra: bitta ZK isbotini yaratish narxi taxminan 1.18 dollar (SHA-1 misolida, 6 soniya hisoblash, 12MB I/O). Bu taxminan JAM core bir slotda bajaradigan ishga teng. JAMda jami 341 core bor, bu esa bitta core narxi.

Albatta, bu taxminiy hisob. Turli vazifalarda narx o'zgarishi mumkin: boshqa hisoblashlar 1.18 dollardan qimmatroq yoki arzonroq bo'lishi mumkin, lekin taxminan shu atrofda.

Agar yillik hisoblasak: bitta core uchun bir yilda taxminan 9.5 million dollar.

Bu yerda GPU klasterini paralellash kechikishni kamaytirish uchun 50% ortiqcha xarajat keltiradi deb faraz qilinmoqda. Lekin bu 50% faqat taxmin, amalda 5% bo'lishi yoki 200%gacha yetishi mumkin. Aniq narsa — ortiqcha xarajat bo'ladi va ehtimol ancha katta.

Xo'sh, bu Polkadotning hozirgi staking mexanizmi bilan qanday taqqoslanadi?

Hozirgi mexanizmda, elves (yoki taxminan 80% elves xavfsizligi) darajasidagi xavfsizlikni ta'minlash uchun, har bir core uchun narx 1 million dollardan kam.

Bu yerda 80% deyilmoqda, chunki: ZKga o'tsangiz ham, hali ham ma'lum staking kerak, asosiy xavfsizlik qismlarini, masalan:

• Asosiy zanjir normal ishlashi
• Hisob-kitob
• Yakuniylik
• Saqlash

Bular juda muhim, lekin hisoblash to'g'riligi eng asosiy, u staking xarajatining taxminan 80%ini tashkil qiladi.

Agar biz 341 core ishlatsak va hozirgi Polkadot staking iqtisodiy modelini saqlasak, narx shunday bo'ladi. Agar core soni kamaytirilsa, bitta core narxi oshadi, chunki staking "umumiy havzasi" o'zgarmaydi, lekin bo'lishadiganlar soni kamayadi.

Xulosa qilib aytganda: hozirgi ZK narxi elvesdan taxminan 10 baravar yuqori.

Albatta, agar biz xavfsizlik narxini pasaytira olsak (menimcha, bu mumkin), masalan, 9.16 million dollardan 2.7 million dollarga, hatto yangi mexanizmlar yordamida 1.44 million dollargacha tushirsak. O'shanda ZK va elves narxi farqi qisqaradi. Lekin, 1.44 million allaqachon optimistik baho.

Xo'sh, yakuniy xulosa nima?

ZK narxi haqiqatan ham pasaymoqda, lekin baribir, hozirda u elvesdan taxminan 10–100 baravar qimmat. Bundan tashqari, hisob-kitob, saqlash va yakuniylik kabi qo'shimcha noma'lum xarajatlar bor — bular JAMda ichki qo'llab-quvvatlanadi yoki elvesdan foydalanish mumkin, lekin ZKda emas.

Bundan tashqari, elvesning bir afzalligi bor: u chiziqli emas, balki ortiqcha kengaytira oladi. Ya'ni, bir nechta JAM tarmoqlarini birlashtirib, ularni bir validator to'plami bilan ishlatish mumkin, shunda umumiy samaradorlik oshadi. ZKda esa bu imkoniyat yo'q, u faqat chiziqli o'sadi — har bir yangi core uchun isbot yaratish uchun yana shuncha xarajat qilish kerak, birlashtirish yoki qayta ishlatish mumkin emas.

ZKning JAMdagi qisqa, o'rta va uzoq muddatli rivojlanish yo'li

Shunday qilib, strategik nuqtai nazardan, qaysi yo'lni tanlash kerakligi aniq holatga bog'liq.

Menimcha, oqilona strategiya quyidagicha:

• Isbot narxini pasaytirish: kamida yana 1–2 pog'ona kamayishi kerak. Oldingi tajribaga ko'ra, bu 18 oy — 5 yil talab qilishi mumkin.
• Ochiq kodli vositalar kerak: GPU klasterida samarali taqsimlangan isbot yaratish imkonini beradigan. Hozircha bunday vositalar yo'q yoki eng tez va eng yaxshi emas. Agar bunday vositalar bo'lmasa, hozirgi narx baholarimiz ham asossiz.
• Core narxi masalasi: agar core bozor narxi allaqachon elves rejimi uchun maqbul bo'lsa, ZK afzalligi yo'qoladi.
• Xavfsizlik tanlovi: bozor ikkita xavfsizlikni ajrata olishi kerak: ZK "mukammal xavfsizlik" beradi, elves esa "iqtisodiy cheklovli xavfsizlik". Savol shuki, bozor qaysi biriga ahamiyat beradi, hozircha noma'lum.
• Yuqori stakingga tayanishni yo'qotish: JAM/elves boshqa vazifalarni, masalan, saqlash, hisob-kitob, yakuniylikni katta stakingga tayanmasdan bajara olishi kerak. Agar hozirgidek katta staking kerak bo'lsa, ZK faqat qimmatroq bo'ladi.

Shu asosda, men tavsiya qiladigan ZK strategiyasi:

• Oson sinab ko'riladigan yo'nalishdan boshlash: masalan, ZK-JAM xizmatlar ramkasini ishlab chiqish, lekin xavfsizlik uchun hali ham JAMning kriptoiqtisodiy mexanizmidan (elves) foydalanish.
• JAMning afzalligidan foydalanish: bitta JAM core juda kuchli hisoblash quvvatiga (CPU) va yaxshi I/Oga (12MB) ega, PVM bajarilish samaradorligi ham yuqori. Bu JAM core ichida ko'plab ZK tekshiruvlarini to'g'ridan-to'g'ri bajarish mumkinligini anglatadi, tashqi qimmat va murakkab isbot jarayoniga ehtiyoj yo'q.
• Isbot bosqichini optimallashtirish: An'anaviy ZK isbot jarayoni bir necha bosqichdan iborat, oxirida "isbot siqish" bosqichi bor, isbotni kichik va tekshirish uchun qulay qiladi. Lekin JAM core ichida, hisoblash quvvati kuchli bo'lgani uchun, bu bosqichga ehtiyoj bo'lmasligi mumkin, bu esa xarajatni tejaydi.
• Saqlash isbotini ustuvor qilish: Chunki JAM core hisoblash quvvati kuchli, lekin I/O nisbatan kam, saqlash isboti bu zaiflikni qoplaydi va tizim ko'plab tranzaksiyalarni tezda qayta ishlay oladi.
• Boshqa oddiy vazifalar: masalan, imzo tekshirish, bu oson va muammo emas.

Boshqacha aytganda, haqiqiy muammo — tranzaksiyalar tayanadigan ma'lumotlarning to'g'riligini kafolatlash. Aynan shu muammoni hal qilishimiz kerak.

O'rta muddatda, eng maqbul yo'l quyidagicha:

Bizda allaqachon yangi Kusama konsepsiyasi bor — ZKni qo'llab-quvvatlaydigan tarmoq yaratish. Demak, ushbu byudjet va boshqa jamoalar bilan hamkorlik qilib, samarali, taqsimlangan isbot yaratish vositalariga sarmoya kiritish juda to'g'ri.

• Agar hozirda hech kim bu ishni qilmayotgan bo'lsa, yangi loyiha boshlash kerak;
• Agar allaqachon jamoa bo'lsa yoki bu ishga o'tishga tayyor bo'lsa, ular bilan hamkorlik qilib, ishni yaxshi bajarishga yordam berish kerak.

Ayniqsa, PVM bajarilish isbotiga e'tibor qaratish kerak, chunki bu kelajakda ZK-JAM va oddiy JAM o'rtasida moslikni ta'minlash uchun muhim va taqsimlangan isbot yaratish zarur.

Maqsad — tizimni modulli va ochiq saqlash, shunda eng ilg'or tadqiqotlar bilan hamnafas bo'lish mumkin. Faqat texnologik taraqqiyotga hamnafas bo'lsak, isbot narxini yana bir necha pog'ona kamaytirib, uni haqiqiy tijoratga mos qila olamiz.

Uzoq muddatda, agar biz ZKni asosiy yechim qilishni istasak, stakingni (staking) o'rnini bosadigan usul topishimiz kerak. Chunki staking bor ekan, xarajat juda yuqori bo'ladi.

Xo'sh, to'liq ZKga asoslangan JAMni qanday amalga oshiramiz?

Avvalo, bu faqat ZK narxi yetarlicha pasayganda va coredan foydalanish hozirgi rejimda iqtisodiy jihatdan foydali bo'lmaganda ma'no kasb etadi. Hozircha bu aniq emas, shuning uchun bu shartli taxmin.

Agar shartlar bajarilsa, JAMni ko'p rejimli xavfsizlik modeliga aylantirish mumkin:

• Bir tomondan, arzon, lekin cheklangan xavfsizlik (elvesga o'xshash, xarajati past);
• Ikkinchi tomondan, qimmat, lekin kuchli mukammal xavfsizlik (ZKga tayanadi, xarajat chiziqli o'sadi).

Asosiy muammo: yakuniylik (finality) va saqlash (storage)ni stakingga tayanmasdan amalga oshirish yo'lini topishimiz kerak.

Bitta mumkin bo'lgan yo'nalish — shaxs isboti (Proof of Personhood). Agar bu mexanizmni asosiy protokolga integratsiya qila olsak, samaradorlik va kapitaldan foydalanishni ancha oshirish mumkin.

Lekin, buni amalga oshirish uchun juda kuchli anti-sybil mexanizmi (anti-sybil mechanism) kerak. Hozirgi ko'pchilik yechimlar yetarli emas, ular yoki biror markaziy tashkilotga tayanadi, yoki biror tashkilot foydalanuvchi ma'lumotlarini yig'ib, kim haqiqiy odam, kim emas, deb qaror qiladi. Bu usul markazlashuv muammosini keltirib chiqaradi, faqat juda kam sonli yechimlar amaliyotga yaqin.