Vitalik: Yelimlash va ko‘makchi protsessor arxitekturasi – samaradorlik va xavfsizlikni oshirish bo‘yicha yangi g‘oya

Yelimlovchi yaxshi yelimlovchi bo‘lishi uchun optimallashtirilishi kerak, xuddi koprotsessor ham yaxshi koprotsessor bo‘lishi uchun optimallashtirilishi kerak.

Asl sarlavha: "Glue and coprocessor architectures"

Muallif: Vitalik Buterin, Ethereum asoschisi

Tarjima: Deng Tong, Jinse Finance

Maxsus minnatdorchilik Justin Drake, Georgios Konstantopoulos, Andrej Karpathy, Michael Gao, Tarun Chitra va turli Flashbots ishtirokchilariga fikr va izohlar uchun.

Agar siz zamonaviy dunyoda davom etayotgan har qanday resurs talab qiluvchi hisoblashni o‘rta darajada batafsil tahlil qilsangiz, bir xususiyatni qayta-qayta ko‘rasiz: hisoblash ikki qismga bo‘linadi:

• Nisbatan kam miqdordagi murakkab, lekin hisoblash jihatidan og‘ir bo‘lmagan "biznes logikasi";
• Katta hajmdagi, zich, lekin yuqori darajada tuzilgan "qimmat ish".

Bu ikki xil hisoblash shaklini eng yaxshi turlicha usulda ko‘rib chiqish mumkin: birinchisi, arxitekturasi samaradorligi past bo‘lishi mumkin, lekin juda yuqori umumiylik talab qiladi; ikkinchisi, arxitekturasi umumiyligi past, lekin juda yuqori samaradorlik talab qiladi.

Amaliyotda bu turli usullarning misollari qanday?

Avvalo, men eng yaxshi biladigan muhitni ko‘rib chiqamiz: Ethereum Virtual Machine (EVM). Bu yaqinda amalga oshirgan Ethereum tranzaksiyamning geth debug izlanishi: ENSda blogimning IPFS hashini yangilash. Ushbu tranzaksiya jami 46924 gas sarfladi va quyidagicha tasniflanadi:

• Asosiy xarajat: 21,000
• Qo‘ng‘iroq ma’lumotlari: 1,556
• EVM bajarilishi: 24,368
• SLOAD opcode: 6,400
• SSTORE opcode: 10,100
• LOG opcode: 2,149
• Boshqalar: 6,719

ENS hash yangilanishining EVM izlanishi. Oxiridan ikkinchi ustun — gas sarfi.

Bu hikoyaning ma’nosi: bajarilayotgan ishlarning katta qismi (agar faqat EVMga qarasak taxminan 73%, hisoblashni qamrab olgan asosiy xarajatlarni ham qo‘shsak taxminan 85%) juda kam sonli tuzilgan qimmat operatsiyalarda jamlangan: saqlash o‘qish-yozish, loglar va kriptografiya (asosiy xarajatlar ichida 3000 imzo tekshirish uchun, EVMda esa 272 hash uchun). Qolgan bajarilish "biznes logikasi": calldata bitlarini almashtirish, men o‘rnatmoqchi bo‘lgan yozuv IDsi va hashini ajratib olish va hokazo. Token transferida bu balanslarni qo‘shish va ayirishni o‘z ichiga oladi, yanada murakkab ilovalarda esa sikllar va boshqalar bo‘lishi mumkin.

EVMda bu ikki xil bajarilish turlicha tarzda ko‘rib chiqiladi. Yuqori darajadagi biznes logikasi ko‘pincha Solidityda yoziladi, u EVMga kompilyatsiya qilinadi. Qimmat ishlar EVM opcode’lari (masalan, SLOAD) orqali ishga tushiriladi, lekin amalda hisoblashlarning 99% dan ortig‘i to‘g‘ridan-to‘g‘ri mijoz kodi (yoki kutubxona) ichida yozilgan maxsus modullarda amalga oshiriladi.

Bu modelni yanada chuqurroq tushunish uchun, boshqa bir kontekstda ko‘rib chiqamiz: torch yordamida python’da yozilgan AI kodi.

Transformer modelining bir blokining forward pass’i

Bu yerda nimani ko‘ramiz? Python’da yozilgan nisbatan kam miqdordagi "biznes logikasi"ni ko‘ramiz, u bajarilayotgan operatsiyalar tuzilishini tasvirlaydi. Amalda, yana bir turdagi biznes logikasi bo‘ladi, u kirishlarni qanday olish va chiqishlarga qanday amal qilish kabi tafsilotlarni hal qiladi. Lekin har bir alohida operatsiyani chuqurroq ko‘rsak (self.norm, torch.cat, +, *, self.attn ichidagi bosqichlar...), vektorizatsiyalangan hisoblashni ko‘ramiz: bir xil operatsiya ko‘plab qiymatlar uchun parallel hisoblanadi. Birinchi misoldagidek, hisoblashlarning kichik qismi biznes logikaga, katta qismi esa yirik tuzilgan matritsa va vektor amallariga — asosan matritsa ko‘paytmasiga — sarflanadi.

EVM misolidagidek, bu ikki turdagi ish ikki xil tarzda amalga oshiriladi. Yuqori darajadagi biznes logikasi Python’da yoziladi, bu juda umumiy va moslashuvchan til, lekin juda sekin, biz samaradorlik pastligini qabul qilamiz, chunki u umumiy hisoblash xarajatining kichik qismini tashkil qiladi. Shu bilan birga, zich operatsiyalar yuqori optimallashtirilgan kodda yoziladi, ko‘pincha GPUda ishlaydigan CUDA kodida. Hatto LLM inference’ni ASICda bajarish ham tobora ko‘proq uchramoqda.

Zamonaviy dasturlashtiriladigan kriptografiya, masalan SNARK, yana ikki darajada shunga o‘xshash modelga amal qiladi. Birinchidan, prover yuqori darajadagi tilda yozilishi mumkin, og‘ir ish vektorizatsiyalangan operatsiyalar orqali amalga oshiriladi, yuqoridagi AI misolidagidek. Bu yerda mening aylana STARK kodim buni ko‘rsatadi. Ikkinchidan, kriptografiya ichida bajariladigan dastur ham umumiy biznes logikasi va yuqori tuzilgan qimmat ish o‘rtasida bo‘linadigan tarzda yozilishi mumkin.

Bu qanday ishlashini tushunish uchun, STARK isbotining so‘nggi tendensiyalaridan biriga qarashimiz mumkin. Umumiy va foydalanish uchun qulay bo‘lishi uchun, jamoalar tobora ko‘proq keng tarqalgan eng kichik virtual mashinalar (masalan, RISC-V) uchun STARK proverlar qurmoqda. Har qanday isbotlanishi kerak bo‘lgan dastur RISC-Vga kompilyatsiya qilinishi mumkin, so‘ngra prover ushbu kodning RISC-V bajarilishini isbotlashi mumkin.

RiscZero hujjatlaridan olingan diagramma

Bu juda qulay: bu shuni anglatadiki, biz faqat bir marta isbot logikasini yozamiz, shundan so‘ng har qanday isbotlanishi kerak bo‘lgan dastur har qanday "an’anaviy" dasturlash tilida yozilishi mumkin (masalan, RiskZero Rust’ni qo‘llab-quvvatlaydi). Lekin bir muammo bor: bu usul katta overhead keltirib chiqaradi. Dasturlashtiriladigan kriptografiya allaqachon juda qimmat; RISC-V interpreterida kodni ishlatish overheadi juda katta. Shuning uchun ishlab chiquvchilar bir hiyla o‘ylab topishdi: hisoblashlarning katta qismini tashkil etuvchi aniq qimmat operatsiyalarni (odatda hash va imzo) aniqlab, bu operatsiyalarni juda samarali isbotlash uchun maxsus modullar yaratish. So‘ngra, siz umumiy, lekin sekin RISC-V isbot tizimi va samarali, lekin maxsus isbot tizimini birlashtirib, eng yaxshi natijaga erishasiz.

ZK-SNARKdan tashqari dasturlashtiriladigan kriptografiya, masalan, ko‘p tomonlama hisoblash (MPC) va to‘liq gomomorfik shifrlash (FHE) ham shunga o‘xshash usullar bilan optimallashtirilishi mumkin.

Umuman olganda, bu hodisa qanday?

Zamonaviy hisoblash tobora ko‘proq men "yelim va koprotsessor arxitekturasi" deb ataydigan modelga amal qilmoqda: sizda markaziy "yelim" komponenti bor, u yuqori umumiylikka ega, lekin samaradorligi past, u bir yoki bir nechta koprotsessor komponentlari o‘rtasida ma’lumot uzatish uchun javobgar, bu koprotsessorlar esa past umumiylikka ega, lekin samaradorligi yuqori.

Bu soddalashtirish: amalda, samaradorlik va umumiylik o‘rtasidagi muvozanat egri chizig‘i deyarli har doim ikki darajadan ko‘proq bo‘ladi. GPU va boshqa sanoatda odatda "koprotsessor" deb ataladigan chiplar CPUga qaraganda kamroq umumiy, lekin ASICga qaraganda umumiyroq. Maxsuslashuv darajasidagi muvozanat murakkab, bu algoritmning qaysi qismlari besh yildan keyin ham o‘zgarmasligi, qaysi qismlari esa olti oydan keyin o‘zgarishi haqidagi bashorat va intuitiv hislarga bog‘liq. ZK isbot arxitekturasida ham shunga o‘xshash ko‘p qatlamli maxsuslashuvni ko‘ramiz. Lekin kengroq fikrlash modeli uchun ikki darajani ko‘rib chiqish yetarli. Ko‘plab hisoblash sohalarida shunga o‘xshash holatlar mavjud:

Yuqoridagi misollardan ko‘rinib turibdiki, hisoblashni bu tarzda bo‘lish mumkin, bu go‘yo tabiiy qonun. Aslida, o‘nlab yillar davomida hisoblash maxsuslashuvining misollarini topish mumkin. Biroq, menimcha, bu ajratish kuchaymoqda. Buning sabablari bor, deb o‘ylayman:

Yaqinda biz CPU soat tezligi oshishining chegarasiga yetdik, shuning uchun faqat parallelizatsiya orqali keyingi yutuqlarga erishish mumkin. Lekin parallelizatsiyani tushunish qiyin, shuning uchun ishlab chiquvchilar uchun ketma-ket fikrlashni davom ettirish va parallelizatsiyani backendda amalga oshirish ko‘pincha amaliyroq, va bu maxsus modullarga o‘ralgan bo‘ladi.

Hisoblash tezligi yaqinda shunchalik tezlashdiki, biznes logikasi hisoblash xarajati haqiqatan ham e’tiborga olinmaydigan darajaga yetdi. Bu dunyoda, biznes logikasi ishlashini optimallashtiruvchi VMni hisoblash samaradorligidan tashqari maqsadlar uchun optimallashtirish ham ma’noga ega: ishlab chiquvchilar uchun qulaylik, tanishlik, xavfsizlik va boshqa shunga o‘xshash maqsadlar. Shu bilan birga, maxsus "koprotsessor" modullari samaradorlik uchun ishlab chiqilishi mumkin va ular yelimlovchi bilan nisbatan oddiy "interfeys"dan xavfsizlik va ishlab chiquvchilar uchun qulaylik oladi.

Eng muhim qimmat operatsiyalar nima ekani tobora aniqroq bo‘lib bormoqda. Bu kriptografiyada eng yaqqol ko‘rinadi, bu yerda eng ko‘p ishlatiladigan aniq qimmat operatsiyalar: modul operatsiyalari, elliptik egri chiziqli kombinatsiyalar (ko‘p skalyar ko‘paytma deb ham ataladi), tezkor Furye o‘zgartirish va boshqalar. AIda ham bu holat tobora aniqroq bo‘lib bormoqda, yigirma yildan ortiq vaqt davomida hisoblashlarning katta qismi "asosan matritsa ko‘paytmasi" bo‘lib kelmoqda (aniqlik darajasi har xil bo‘lsa ham). Boshqa sohalarda ham shunga o‘xshash tendensiyalar mavjud. 20 yil avvalgiga qaraganda, (hisoblash talab qiluvchi) hisoblashda noma’lum noma’lumlar ancha kam.

Bu nimani anglatadi?

Asosiy nuqta shundaki, yelimlovchi (Glue) yaxshi yelimlovchi bo‘lishi uchun optimallashtirilishi kerak, koprotsessor (coprocessor) esa yaxshi koprotsessor bo‘lishi uchun optimallashtirilishi kerak. Biz bu nuqtaning mazmunini bir nechta muhim sohalarda ko‘rib chiqishimiz mumkin.

EVM

Blockchain virtual mashinalari (masalan, EVM) samarador bo‘lishi shart emas, faqat tanish bo‘lishi kerak. Faqat to‘g‘ri koprotsessorlarni (ya’ni "precompiled") qo‘shish kifoya, sust VMda hisoblash aslida mahalliy samarali VMdagi hisoblash kabi samarali bo‘lishi mumkin. Masalan, EVMning 256 bitli registrlari keltiradigan overhead nisbatan kichik, EVMning tanishligi va mavjud ishlab chiquvchilar ekotizimi keltiradigan foyda esa juda katta va uzoq muddatli. EVMni optimallashtirayotgan jamoalar hatto parallelizatsiyaning yo‘qligi ko‘pincha kengayuvchanlik uchun asosiy to‘siq emasligini aniqlashdi.

EVMni yaxshilashning eng yaxshi usuli, ehtimol, (i) yaxshiroq precompiled yoki maxsus opcode’larni qo‘shish, masalan, EVM-MAX va SIMDning biror kombinatsiyasi ma’qul bo‘lishi mumkin, va (ii) saqlash tartibini yaxshilash, masalan, Verkle daraxtidagi o‘zgarishlar natijasida bir-biriga yaqin saqlash slotlariga kirish xarajati sezilarli darajada kamayadi.

Ethereum Verkle daraxti taklifidagi saqlash optimallashtirishi, bir-biriga yaqin saqlash kalitlarini birga joylashtirish va gas xarajatini shunga moslashtirish. Bunday optimallashtirishlar va yaxshiroq precompiled’lar EVMning o‘zini o‘zgartirishdan ko‘ra muhimroq bo‘lishi mumkin.

Xavfsiz hisoblash va ochiq apparat

Zamonaviy hisoblash xavfsizligini apparat darajasida oshirishning eng katta muammolaridan biri uning haddan tashqari murakkab va maxsus xususiyatidir: chiplar samarali bo‘lishi uchun maxsus optimallashtiriladi. Orqa eshiklarni yashirish oson, yon kanal zaifliklari doimiy ravishda topilmoqda.

Odamlar turli nuqtai nazardan ochiqroq va xavfsizroq alternativalarni ilgari surishda davom etmoqda. Ba’zi hisoblashlar tobora ko‘proq ishonchli bajarilish muhitida amalga oshirilmoqda, jumladan foydalanuvchi telefonida, bu allaqachon foydalanuvchi xavfsizligini oshirdi. Ochiq kodli iste’molchi apparatini ilgari surish harakati davom etmoqda, yaqinda ba’zi yutuqlarga erishildi, masalan, Ubuntu ishlaydigan RISC-V noutbuki.

Debian ishlaydigan RISC-V noutbuki

Biroq, samaradorlik hali ham muammo. Yuqoridagi havola maqolasi muallifi shunday yozadi:

RISC-V kabi yangi ochiq kodli chip dizaynlari allaqachon mavjud va o‘n yillar davomida takomillashtirilgan protsessor texnologiyalari bilan raqobatlasha olmaydi. Taraqqiyot har doim bir nuqtadan boshlanadi.

Yana ham ehtiyotkor g‘oyalar, masalan, FPGAda RISC-V kompyuterini qurish dizayni, yanada katta overheadga duch keladi. Lekin, agar yelim va koprotsessor arxitekturasi bu overhead aslida muhim emasligini anglatadigan bo‘lsa-chi? Agar biz ochiq va xavfsiz chiplar maxsus chiplarga qaraganda sekinroq bo‘lishini qabul qilsak, zarurat tug‘ilganda hatto spekulyativ bajarilish va tarmoqlanishni bashorat qilish kabi keng tarqalgan optimallashtirishlardan voz kechsak, lekin eng zich aniq turdagi hisoblashlar uchun (zarur bo‘lsa, maxsus) ASIC modullarini qo‘shish orqali buni qoplashga harakat qilsak-chi? Nozik hisoblashlar "asosiy chip"da amalga oshiriladi, u xavfsizlik, ochiq kodli dizayn va yon kanalga qarshi chidamlilik uchun optimallashtiriladi. Eng zich hisoblashlar (masalan, ZK isbot, AI) ASIC modullarida amalga oshiriladi, ular bajarilayotgan hisoblash haqida kamroq ma’lumotga ega bo‘ladi (ehtimol, shifrlash orqali ko‘rinmaslik, ba’zi hollarda hatto nol ma’lumotga ega bo‘lishi mumkin).

Kriptografiya

Yana bir muhim nuqta shundaki, bu hammasi kriptografiyaga, ayniqsa dasturlashtiriladigan kriptografiyaning ommalashuviga juda ijobiy ta’sir qiladi. Biz allaqachon SNARK, MPC va boshqa sozlamalarda ba’zi aniq yuqori tuzilgan hisoblashlarning juda optimallashtirilgan implementatsiyalarini ko‘rdik: ayrim hash funksiyalari overheadi to‘g‘ridan-to‘g‘ri hisoblashni bajarishdan atigi bir necha yuz barobar qimmatroq, AI (asosan matritsa ko‘paytmasi) overheadi esa juda past. GKR kabi keyingi yaxshilanishlar bu darajani yanada pasaytirishi mumkin. To‘liq umumiy VM bajarilishi, ayniqsa RISC-V interpreterida bajarilganda, taxminan o‘n ming baravar overhead keltirishda davom etishi mumkin, lekin ushbu maqolada tasvirlangan sabablarga ko‘ra bu muhim emas: faqat hisoblashdagi eng zich qismlarni samarali maxsus texnologiyalar yordamida alohida ishlash kifoya, umumiy overhead boshqariladigan bo‘ladi.

Matritsa ko‘paytmasiga maxsus MPCning soddalashtirilgan diagrammasi, bu AI model inference’dagi eng katta komponent. Batafsil ma’lumot uchun ushbu maqolaga qarang, jumladan model va kirishlarni maxfiy saqlash usullari.

"Yelim qatlami faqat tanish bo‘lishi kerak, samarador bo‘lishi shart emas" degan g‘oyaning istisnosi — kechikish va kichikroq darajada ma’lumot o‘tkazish kengligi. Agar hisoblash bir xil ma’lumotga o‘nlab marta takroriy og‘ir operatsiyalarni o‘z ichiga olsa (kriptografiya va AIda bo‘lgani kabi), sust yelim qatlami sababli yuzaga keladigan har qanday kechikish bajarilish vaqtining asosiy to‘sig‘iga aylanishi mumkin. Shuning uchun, yelim qatlami ham samaradorlik talablariga ega, lekin bu talablar aniqroq.

Xulosa

Umuman olganda, men yuqoridagi tendensiyalarni bir nechta nuqtai nazardan juda ijobiy rivojlanish deb hisoblayman. Birinchidan, bu hisoblash samaradorligini maksimal darajada oshirishning oqilona usuli, ishlab chiquvchilar uchun qulaylikni saqlab qolgan holda, har ikkala tomondan ko‘proq foyda olish imkonini beradi. Xususan, samaradorlik uchun mijoz tomonida maxsuslashuvni amalga oshirish orqali, bu foydalanuvchi apparatida mahalliy ravishda nozik va yuqori samaradorlik talab qiladigan hisoblashlarni (masalan, ZK isbot, LLM inference) bajarish imkoniyatini oshiradi. Ikkinchidan, bu samaradorlikka intilish boshqa qadriyatlarni, eng aniq xavfsizlik, ochiqlik va soddalikni qurbon qilmasligini ta’minlash uchun katta imkoniyat oynasini yaratadi: kompyuter apparatida yon kanal xavfsizligi va ochiqligi, ZK-SNARKda aylana murakkabligini kamaytirish va virtual mashinada murakkablikni kamaytirish. Tarixan, samaradorlikka intilish bu boshqa omillarni ikkinchi o‘ringa surib qo‘ydi. Yelim va koprotsessor arxitekturasi bilan endi bunga hojat yo‘q. Mashinaning bir qismi samaradorlik uchun, boshqa qismi esa umumiylik va boshqa qadriyatlar uchun optimallashtiriladi, va ular birga ishlaydi.

Bu tendensiya kriptografiya uchun ham juda foydali, chunki kriptografiyaning o‘zi "qimmat tuzilgan hisoblash"ning asosiy misollaridan biri, va bu tendensiya bu rivojlanishni tezlashtiradi. Bu xavfsizlikni oshirish uchun yana bir imkoniyat yaratadi. Blockchain dunyosida ham xavfsizlikni oshirish mumkin: biz virtual mashinani optimallashtirish haqida kamroq, precompiled va virtual mashina bilan birga ishlaydigan boshqa funksiyalarni optimallashtirish haqida ko‘proq o‘ylashimiz mumkin.

Uchinchidan, bu tendensiya kichikroq va yangi ishtirokchilarga ishtirok etish imkoniyatini beradi. Agar hisoblash kamroq monolitik, ko‘proq modulli bo‘lsa, bu kirish to‘sig‘ini sezilarli darajada pasaytiradi. Hatto hisoblashning bir turi uchun ASICdan foydalansangiz ham, natija ko‘rsatish mumkin. Bu ZK isbot sohasida va EVM optimallashtirishda ham shunday. Deyarli ilg‘or darajadagi samaradorlikka ega kod yozish osonroq va qulayroq bo‘ladi. Bunday kodni audit qilish va formal tekshirish osonroq va qulayroq bo‘ladi. Nihoyat, bu juda turli hisoblash sohalari ba’zi umumiy modellarga yaqinlashgani sababli, ular o‘rtasida ko‘proq hamkorlik va o‘zaro o‘rganish imkoniyati mavjud.