Müəllif: Kernel Ventures Turbo Guo
Rəyçi: Kernel Ventures Mandy, Kernel Ventures Joshua
TLDR:
ZK Kooperativ Prosessoru, dApp-ların zəncir xaricindəki hesablamalardan istifadə etməsinə imkan tanıyan bir həll yoludur. Bu məqalədə kooperativ prosessorun tətbiqetmə yolları, müxtəlif tətbiqlər və gələcək inkişaf istiqamətləri müzakirə olunur, əsas məzmun bunlardır:
RISC Zero-nun zkVM-i ZK kooperativ prosessoruna aid bir həll yoludur, bu, zəncir üzərindəki müqavilələrin zəncir xaricindəki zkVM-də müəyyən Rust kodunu işlətməsinə və nəticələri zəncir üzərinə geri qaytarmağa imkan tanıyır, eyni zamanda müqaviləyə hesablamanın düzgünlüyünü təsdiqləmək üçün zkp təqdim edir.
ZK kooperativ prosessorunun müxtəlif tətbiqetmə yolları var, zkVM-dən əlavə, istifadəçilər proqram üçün xüsusi ZK dövrələrini yaza bilər, yaxud da əvvəlcədən hazırlanmış çərçivələrdən istifadə edərək dövrələr qura bilər, bu da müqavilələrin zəncir xaricindəki hesablamalardan istifadə etməyə imkan tanıyır.
ZK ko-protsessorlar DeFi-də rol oynaya bilər: məsələn, AMM-in hesablamalarını zəncirdən kənara aparmaqla protokolun MEV-ə bənzər dəyəri ələ keçirməsinə kömək etmək və ya AMM-in mürəkkəb və çox hesab tələb edən işləmə məntiqini reallaşdırmaq. ZK ko-protsessorlar həmçinin borclanma protokollarına kredit faizini real vaxtda hesablamağa imkan verir; margin (təminat) hesablamalarının şəffaflaşması kimi. zkAMM-in iki reallaşdırma yolu var: biri zkVM, digəri isə zkOracle ilə.
ZK ko-protsessorun başqa potensial istifadələri də var: məsələn, pul kisəsi ZK ko-protsessordan istifadə edərək identifikasiya doğrulamasını zəncirdən kənarda icra edə bilər; ko-protsessor həmçinin zəncirdəki oyunların daha mürəkkəb hesablamaları yerinə yetirməsinə imkan verər, bununla da DAO-nun idarəetmə (governance) üçün tələb etdiyi gas-i azaldar və s.
ZK ko-protsessorun mənzərəsi hələ tam formalaşmayıb, amma istifadəçilərin özləri sxem yazması ilə müqayisədə bir layihənin interfeys çağırış zəncirlərini zəncirdən kənar resurslara bağlaması daha rahatdır. Lakin bu “interfeys” layihəsinin arxasında hansı hesablama xidmət təminatçısı dayanır (ənənəvi bulud provayderləri, mərkəzləşdirilməmiş resurs paylaşımı) məsələsi ayrıca müzakirə ediləcək bir problemdir.
1. ZK ko-protsessorun mənası və tətbiqləri
Şəkil mənbəyi: Kernel Ventures
ZK ko-protsessorun mərkəzi ideyası zəncirdəki hesablamaları zəncirdən kənara köçürməkdir: ZK ilə zəncirdən kənar hesablamanın etibarlılığını sübut etmək, beləliklə ağıllı müqavilələrin çoxlu hesabı asanlıqla emal edə bilməsi və eyni zamanda müqavilənin hesablamanın etibarlılığını yoxlaya bilməsidir. Bu, zkRollup yanaşmasına bənzəyir, amma Rollup zəncir protokol səviyyəsində zəncirdən kənar hesab resurslarından istifadə edir; ZK ko-protsessor isə dApp-lərin zəncirdən kənar resurslardan istifadə etməsidir.
Burada ZK ko-protsessorun bir reallaşdırma yolunu izah etmək üçün RISC Zero-dan nümunə kimi istifadə olunur, amma ZK ko-protsessorun çoxlu reallaşdırma yolları var və sonrakı bölmələrdə bunlar da təqdim olunacaq. RISC Zero Bonsai ZK ko-protsessor memarlığını hazırlayıb; əsas isə RISC Zero-nun zkVM-indir. Tərtibatçılar zkVM üzərində “bütöv bir Rust kod parçası düzgün icra olunub” məsələsi üçün zkp yarada bilərlər. zkVM olduqdan sonra ZK ko-protsessorun konkret axını belədir:
Tərtibatçılar Bonsai-nin relay müqaviləsinə sorğu göndərir — yəni zkVM daxilində tərtibatçının istədiyi proqramı işlətmək
Relay müqaviləsi sorğunu zəncirdən kənar sorğu hovuzuna (pool) göndərir
Bonsai zəncirdən kənar zkVM-də sorğunu icra edir və bunun üçün zəncirdən kənarda böyük həcmli hesablamalar aparır; sonra ona bir receipt (qəbul sənədi) yaradır.
Bu sübutlar — “qəbul sənədləri” də adlanır — Bonsai tərəfindən relay müqaviləsi vasitəsilə zəncirə geri dərc olunur.
Şəkil mənbəyi: RISC Zero
Bonsai-də sübut edilən proqram “Guest Program” adlanır; həmin “receipt” (qəbul sənədi) guest program-ın düzgün icra olunduğunu göstərmək üçün istifadə edilir. Receipt journal və seal (möhür) ehtiva edir. Konkret olaraq, Journal zkVM tətbiqinin public output-larını daşıyır; seal isə receipt-in etibarlılığını — yəni guest program-ın düzgün icra olunduğunu — sübut edir. Seal özü də sübut edən tərəfindən yaradılan zkSTARK-dır. Receipt-in doğrulanması journal-ın düzgün qurulmuş (məsələn, doğru sxemə əsasən) olduğunu təmin edir və s.
Bonsai tərtibatçıların Rust kodundan zkVM baytkoduna kompilyasiya, proqram yükləmə, VM daxilində icra və proof-un geri qaytarılması kimi prosesləri sadələşdirir; bu da tərtibatçıları daha çox proqramın məntiq dizaynına yönəldir. Bu yalnız müqavilənin bir hissəsi deyil — bütün müqavilə məntiqini zəncirdən kənarda işlətmək olar. RISC Zero həmçinin continuations-dan istifadə edir: böyük proof-u çoxlu hissələrə bölür və hər hissəni ayrıca sübut etdirir. Beləliklə böyük proqramlar üçün proof yaratmaq mümkün olur və çox yaddaş tutulmur. RISC Zero-dan başqa, IronMill, =nil; Foundation və Marlin kimi bir neçə layihə də oxşar ümumi həllər təqdim edir.
2. ZK ko-protsessorların DeFi-də tətbiqi
2.1 AMM — ko-protsessor üçün Bonsai
zkUniswap zəncirdən kənar hesab resurslarından istifadə edən AMM növüdür. Əsas ideya swap hissəsinin hesablamasını zəncirdən kənara çıxarmaqdır və o, Bonsai-dən istifadə edir. İstifadəçi zəncirdə bir swap sorğusu verir. Bonsai-nin relay müqaviləsi sorğunu qəbul edib zəncirdən kənar hesablamaya start verir. Bonsai hesablama tamamlandıqdan sonra nəticə və proof-u EVM-dəki callback funksiyasına qaytarır. Əgər proof uğurla təsdiqlənərsə, swap icra olunur.
Amma swap tək bir addımda tamamlanmır: sorğu və icra ayrı-ayrı transactions-larda baş verir. Bu isə müəyyən risk yaradır: sorğu təqdim edildikdən swap tamamlanana qədər hovuzun (pool) vəziyyəti dəyişə bilər. Çünki doğrulama sorğu təqdim edilərkən hovuzun vəziyyətinə əsaslanır. Əgər sorğu gözləmə mərhələsində olduğu vaxt hovuzun vəziyyəti dəyişərsə, doğrulama etibarsız ola bilər.
Bu problemi həll etmək üçün tərtibatçılar bir “hovuz” kilidi (pool lock) dizayn ediblər. İstifadəçi sorğu başladanda, swap hesablaşması istisna olmaqla bütün əməliyyatlar zəncirdən kənarda zəncir swap-ı uğurla işə salınana qədər və ya swap müddəti bitənə qədər (bu vaxt əvvəlcədən müəyyən edilir) kilidlənir. Vaxt məhdudiyyəti olduqda, relay və ya zkp hansısa səbəbdən problem yaratsa belə, hovuz heç vaxt uzun müddət kilidli qalmır. Konkretdə vaxt məhdudiyyəti bir neçə dəqiqə ola bilər.
zkUniswap MEV-ə xüsusi dizayn tətbiq edir: tərtibatçılar protokola MEV dəyərini əldə etdirmək istəyir. Nəzəri olaraq zkAMM-lər də MEV yaradır, çünki əvvəlcə əməliyyat edən lock-i ələ keçirir; buna görə hamı yenə gas uğrunda yarışır, builders də sorğuları sıralaya bilər. Amma zkUniswap MEV gəlirini özününküləşdirir; bunun üçün istifadə etdiyi üsul dəyişən faiz dərəcəli mərhələli holland auksionudur (VRGDA).
zkUniswap lock-u çıxarıb özü endirim qiyməti ilə auksiona çıxarır. Əgər lock tez satılırsa, protokol hazırda tələbın yüksək olduğunu anlayır və avtomatik qiyməti artırır; əgər lock-un satılma sürəti azalarsa, protokol qiyməti endirir. Bu, yeni gəlir mənbəyinə çevrilir. Yəni protokol əməliyyat sırasını müəyyən edən yeni bir mexanizm təqdim edir: rəqabət qiymətindən gələn pul birbaşa həmin mexanizm vasitəsilə layihəyə ötürülür — bu da çox maraqlı ideyadır.
2.2 AMM — ko-protsessor üçün zkOracle
zkVM-dən başqa, zəncirdən kənar hesab resurslarından istifadə etmək üçün zkOracle-dən istifadə təklif edənlər də var. zkOracle həm giriş, həm də çıxış təmin edən proqnozlaşdırıcı (oracle)dır. Adətən orakellərin iki növü olur: biri giriş oracle, digəri isə çıxış oracle. Giriş oracle zəncirdən kənar məlumatları (hesablamanı) yığır və zəncirdə yerləşdirir; çıxış oracle isə zəncirdəki məlumatları (hesablamanı) yığır və onları zəncirdən kənara təqdim edir. I/O (giriş və çıxış) oracle-lar (zkOracle) əvvəl çıxışı, sonra girişi edərək zəncirin zəncirdən kənar hesab resurslarını istifadə edə bilməsinə imkan yaradır.
zkOracle bir tərəfdən zəncir məlumatlarını məlumat mənbəyi kimi istifadə edir; digər tərəfdən isə ZK ilə oracle node-larının hesablamasının uydurma olmadığını təmin edir. Buna görə ko-protsessorun funksiyalarını yerinə yetirmək mümkündür. Bu səbəbdən AMM-in əsas hesablamasını zkOracle daxilində yerləşdirmək olar: həm ənənəvi AMM funksionallığını saxlamaq, həm də zkOracle ilə daha mürəkkəb və daha çox hesablama resursu tələb edən əməliyyatları reallaşdırmaq mümkündür.
Şəkil mənbəyi: github fewwwww/zkAMM
2.3 Borclanma faizinin hesablanması, margin (təminat) hesabı və digər tətbiqlər
Reallaşdırma üsulundan kənara çıxsaq, ZK ko-protsessorla çoxlu funksiyalar mümkün olur. Məsələn, borclanma protokolu artıq əvvəlcədən parametrlər təyin etmədən, borcvermə vəziyyətinə görə faiz dərəcəsini real vaxtda tənzimləyə bilər. Məsələn, kredit tələbi artanda faiz dərəcəsini yüksəldib təklifi cəlb etmək, tələb düşəndə isə faiz dərəcəsini endirmək. Bunun üçün borclanma protokolu zəncir məlumatlarını real vaxtda almalı və eyni zamanda çoxlu hesablamalar aparmalıdır ki, uyğun parametrlər hasil olsun; bunun üçün zəncirdən kənar hesablamalar lazımdır (əgər zəncir xərci çox aşağı deyilsə).
Hesablanan təminat (margin) bakı, reallaşmamış mənfəət və zərər (PnL), likvidasiya məbləği kimi mürəkkəb əməliyyatları da ko-protsessora köçürüb icra etmək olar. Ko-protsessorun üstünlüyü odur ki, bu cür tətbiqlər daha şəffaf və yoxlanıla bilən olur; margin engine-in məntiqi artıq sirrli qara qutu deyil. Hesablamalar zəncirdən kənarda edilsə də, istifadəçi onun düzgün icrasına tam etibar edə bilər. Bu yanaşma opsionların hesablanmasına da uyğundur.
3. ZK ko-protsessorun digər tətbiqləri
3.1 Pul kisəsi — ko-protsessor üçün Bonsai istifadə etmək
Bonfire Wallet zkVM-dən istifadə edərək identifikasiya doğrulamasının hesablamasını zəncirdən kənara keçirir. Bu pul kisəsinin məqsədi istifadəçinin biometrik məlumatlarla (barmaq izləri) və ya kripto cihazı olan yubikey ilə burner pul kisəsi yarada bilməsidir.
Məsələn, Bonfire Wallet ümumi veb doğrulama standartı olan WebAuthn-dən istifadə edir: istifadəçi paroldan istifadə etmir, sadəcə cihaz vasitəsilə vebdə identifikasiya doğrulamasını həyata keçirir. Beləliklə Bonfire pul kisəsində istifadəçi WebAuthn üçün (zəncirdə deyil) bir açar cütü yaradır, sonra bununla pul kisəsini qurur.
Hər bir Burner pul kisəsinin zəncirdə bir müqaviləsi var; bu müqavilədə WebAuthn-in açıq açarı yerləşir və müqavilə istifadəçinin WebAuthn imzasını yoxlamalıdır. Lakin bu hesablamanın həcmi çox böyükdür, ona görə Bonsai-dən istifadə edilərək hesablamalar zəncirdən kənara çıxarılır: zəncirdən kənarda zkVM guest proqramı imzanı yoxlayır və zəncdə yoxlanıla bilən zkp yaradır.
Şəkil mənbəyi: Bonfire Wallet
3.2 Zəncir məlumatı tələb etmə — istifadəçinin öz ZK sxemini yazması
Axiom zkVM-dən istifadə etmir, amma başqa bir ko-protsessor həllindən istifadə edən bir tətbiqdir. Gəlin əvvəlcə Axiom-un nə etmək istədiyini izah edək: o, ZK ko-protsessordan istifadə etməklə müqavilələrin tarixi zəncir məlumatlarını oxuya bilməsini hədəfləyir. Əslində müqavilələrin tarixi məlumatları oxuması çətindir, çünki ağıllı müqavilələr adətən real-time zəncir məlumatlarını əldə edir və bu bahalı olur; müqavilələr üçün hesabın keçmiş balansı və ya əməliyyat qeydləri kimi dəyərli zəncir məlumatlarını əldə etmək çətindir.
Şəkil mənbəyi: Axiom demo
Axiom node-larının ehtiyac duyduğu zəncir məlumatlarını əldə etməsi və zəncirdən kənarda müəyyən hesablamanı icra etməsi, sonra da həmin hesablamadan bir sıfır bilik sübutu (zero-knowledge proof) yaratmasıdır; yəni sübut edilən nəticə etibarlı zəncir məlumatlarına əsasən düzgün hesablandığını göstərir. Bu sübut zəncirdə doğrulanır və müqavilənin bu nəticəyə etibar etməsini təmin edir.
Zəncirdən kənarda hesablamadan zkp yaratmaq üçün proqramı ZK sxeminə kompilyasiya etmək lazımdır; yuxarıda da qeyd etdik ki, bunu etmək üçün zkVM istifadə olunur. Axiom-un rəsmi mövqeyinə görə bu iş üçün bir çox yanaşma var və performans, çeviklik və inkişaf təcrübəsi arasında balans qurmaq lazımdır:
Xüsusi sxem: tərtibatçılar proqram üçün xüsusi sxem tərtib edir — əlbəttə performans ən yaxşı olar, amma inkişaf üçün vaxt lazımdır;
eDSL/DSL: tərtibatçılar yenə də özləri sxem yazırlar, amma ZK ilə bağlı problemləri tərtibatçı üçün həll edən bəzi ixtiyari framework-lərdən istifadə olunur; beləliklə performansla inkişaf təcrübəsi arasında balans yaratmaq olur.
zkVM: tərtibatçılar ZK-ni birbaşa hazır virtual maşın daxilində işlədə bilir — bu çox rahatdır, amma Axiom-un fikrincə səmərəlilik aşağıdır
Buna görə Axiom ikinci yolu seçdi: layihə komandası istifadəçilərə optimallaşdırılmış bir sıra ZK modullar da təqdim edir ki, onlar özləri sxem dizayn edə bilsinlər.
Axiom-a bənzər layihələrdən biri də Herodotus-dur, amma o,跨zəncir məlumat ötürülməsi üçün vasitəçi (middleware) qurmaq istəyir. Çünki məlumat emalı zəncirdən kənarda aparılır, müxtəlif zəncirlərin emal edilmiş datanı əldə etməsi çox məntiqli yanaşmadır. Digər layihə Space and Time isə oxşar memarlıqla məlumat indeksləşdirilməsini həyata keçirir.
3.3 Zəncirdə oyunlar, DAO idarəetməsi və digər tətbiqlər
Bundan başqa, zəncirdə oyunlar və DAO idarəetməsi də ZK ko-protsessordan istifadə edə bilər. RISC Zero hesab edir ki, 250k gas-dan yuxarı hesab tələb edən hər hansı hesablamada ZK ko-protsessor istifadə etmək xərci daha aşağı edəcək, amma bunu necə dəqiq əldə etdikləri hələ araşdırılmalıdır. DAO idarəetməsi də ZK ko-protsessora uyğun ola bilər, çünki bu, çox insan və çoxlu müqavilə ilə bağlıdır və çox hesab resursu tələb edir. RISC Zero bildirir ki, Bonsai istifadə etdikdən sonra gas haqqı 50% azala bilər. ZKML mahiyyətcə də ZK ko-protsessor yanaşmasıdır; buna görə Modulus Labs və Giza da bu sahədə layihələrdir, sadəcə ZK ko-protsessor anlayışı daha genişdir.
Bundan əlavə, bu sahədə bir neçə köməkçi layihə də var: məsələn, ezkl — ZK sxemlər hazırlamaq üçün kompilyator təqdim edir; ZK deploy alətləri dəsti; zəncirdəki hesablamanı zəncirdən kənara köçürmək üçün alətlər və s.
4. Gələcək perspektivlər
Ko-protsessor zəncir tətbiqlərinə sanki “bulud” kimi xarici hesablama resursları verir: o, nisbətən ucuz böyük həcmli hesablamalar təmin edir, zəncirdə isə yalnız lazımi hesablamalar aparılır. Real vəziyyətdə zkVM də buludda işlədilə bilər; ZK ko-protsessor mahiyyətcə bir memarlıqdır — zəncirdəki hesablamaları zəncirdən kənara köçürmə üsuludur. Zəncirdən kənar hesab resurslarını kim təqdim edir isə məhdud deyil.
Əsasən zəncirdən kənar hesab resursları ənənəvi böyük provayderlərdən, hətta mərkəzləşdirilməmiş hesab resurslarının paylaşımdan, həm də lokal cihazdan gələ bilər. Bu üç istiqamətin hər biri fərqlidir: ənənəvi böyük provayderlər zəncirdən kənar hesab həllində nisbətən daha yetkin ola bilərlər; gələcəkdə mərkəzləşdirilməmiş hesab resurslarının “dayanıqlığı” daha güclü ola bilər. İstifadəçinin lokal hesablaması isə təsəvvür üçün daha çox yer verir. Amma hazırda bir çox ZK ko-protsessor layihəsi qapalı mənbə ilə xidmət təqdim etmək mərhələsini seçir, çünki bu sahədə yuxarı və aşağı axın tərəfləri hələ formalaşmayıb; xidmətin detallandırılıb müxtəlif layihələrə verilməsi mümkün deyil. Gələcəkdə iki ehtimal var:
ZK ko-protsessorun hər bir mərhələsində çoxlu sayda layihə bir-biri ilə rəqabət aparır
Yaxşı xidmət göstərən bir layihə bazarın böyük hissəsini tutur
Tərtibatçı baxımından, ZK ko-protsessoru istifadə edərkən onlar bəlkə də yalnız bir “interfeys” layihəsindən istifadə edəcək. Bunun səbəbi də Amazon buludunun bazarın böyük hissəsini tutmasının səbəblərindən birinin eynidir: tərtibatçılar bir yerləşdirmə (deployment) üsuluna vərdiş edir. Amma o “interfeys” layihəsi zəncirdən kənar hesab resursları ilə əlaqələndiriləndə arxasında hansı hesablama xidmət təminatçısı dayanır (ənənəvi bulud şirkətləri, mərkəzləşdirilməmiş resurs paylaşımı) — bu da başqa bir sahədə müzakirə edilməli sualdır.
Kernel Ventures tədqiqat və inkişaf icması tərəfindən idarə olunan kripto risk investisiya fondudur. 70-dən çox ilkin mərhələ investisiya portfelinə malikdir; infrastruktur, middleware və dApps-lara diqqət yetirir. Xüsusilə ZK, Rollup, DEX, modul blokçeyn və gələcək onlarla milyard kripto istifadəçini daşıyacaq şaquli sahələrə — məsələn, account abstraction, data availability, scalablelıq və s. — yönəlir. Son yeddi ildə biz dünyanın hər yerində əsas inkişaf icmalarının və universitet blokçeyn assosiasiyalarının inkişafını dəstəkləməyə çalışırıq.
İstinad materialları:
A Guide to ZK Coprocessors for Scalability：https://www.risczero.com/news/a-guide-to-zk-coprocessors-for-scalability
Defining zkOracle for Ethereum：https://ethresear.ch/t/defining-zkoracle-for-ethereum/15131
zkUniswap: a first-of-its-kind zkAMM：https://ethresear.ch/t/zkuniswap-a-first-of-its-kind-zkamm/16839
What is a ZK Coprocessor?：https://blog.axiom.xyz/what-is-a-zk-coprocessor/
A Brief Intro to Coprocessors：https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA
Latest Applications Building on Hyper Oracle (Bonus: Things You Can Build Now)：https://mirror.xyz/hyperoracleblog.eth/Tik3nBI9mw05Ql_aHKZqm4hNxfxaEQdDAKn7JKcx0xQ
Bonfire Wallet：https://ethglobal.com/showcase/bonfire-wallet-n1dzp