Fejlesztői útmutató a zkGalaxyhoz

Ez egy rendkívül hasznos heurisztika a zkEVM támogatására vonatkozó megközelítések megkülönböztetésére. A zkEVM-ek azonban a nulla tudású alkalmazások létrehozásának lehetséges módjainak egy részét képezik. Egy programozónak, aki ki akarja használni a zk számítás egyedi tulajdonságait, nevezetesen tömörség, nulla tudás és korrektség, a zkEVM nem biztos, hogy a legjobb választás. A fejlesztői eszközök teljes készletének felvázolásával remélem, hogy olyan útmutatót nyújthatok, amely segíti a döntéshozatali folyamatot az alkalmazásának megfelelő zk-verem körül.

Az elmúlt egy-két évben óriási előrelépés történt a zk eszközök terén. Közelednek ahhoz a ponthoz, ahol a hétköznapi szoftverfejlesztők kihasználhatják a zk erőteljes tulajdonságait anélkül, hogy mélyen megértenék a megfélemlítő matematikai és mérnöki ismereteket. Másrészt a nagyfelhasználóknak szánt eszközök elterjedtek, amelyek a zk szakértők számára rendkívül finom vezérlést biztosítanak a zk verem felett.

A modern szoftver az absztrakció számtalan rétegére épül, hogy maximalizálja a szakemberek termelékenységét. A mérnöki absztrakciónak számos előnye van, amelyek némileg intuitívak – a webfejlesztőnek nem kell alaposan megértenie az operációs rendszerek működését. 

A jó, újrafelhasználható absztrakciós rétegek felépítésének kulcsa egy réteg komplexitásának beágyazása, majd egyszerű, de kifejező felületek biztosítása a veremben magasabb rétegek számára. Helyesen végezve ez lehetővé teszi a különböző szakértelemmel és tudással rendelkező fejlesztők számára, hogy hasznos eszközöket építsenek ki a veremben.

Nem meglepő módon ugyanezek az elvek érvényesek a zk rendszerekre is, és ezek az absztrakciós rétegek eléggé érettek ahhoz, hogy a zk kezdők már ma elkezdhessék használni őket és alkalmazásokat építeni.

Arkworks-rs a Rust könyvtárak ökoszisztémája, amely a zkSNARK alkalmazás részösszetevőinek hatékony és biztonságos megvalósítását biztosítja. Az Arkworks biztosítja a szükséges felületeket a fejlesztők számára, hogy testreszabhassák a zk-alkalmazások szoftvercsomagját anélkül, hogy más meglévő könyvtárakkal kellene újból megvalósítani a közös jellemzőket.

Az Arkworks előtt az egyetlen módja annak, hogy új zk-alkalmazást hozzunk létre, az volt, hogy mindent a semmiből készítünk. Az Arkworks-rs fő előnyei az egyedi tervezésű, vertikálisan integrált eszközökkel szemben a rugalmasság szintje, a párhuzamos tervezés és az auditálási erőfeszítések csökkentése. Az Arkworks ésszerű interfészvonalai az összetevők között olyan ütemű bővíthetőséget tesznek lehetővé, amellyel a verem releváns maradhat a zk-technológiák rohamos ütemű innovációja közepette, anélkül, hogy a csapatokat arra kényszerítené, hogy mindent a semmiből újjáépítsenek.

Az Arkworks olyan projektekhez készült, amelyeknek a teljes zk szoftververem finom vezérlésére van szükségük, de nem akarják az összes redundáns darabot a semmiből felépíteni. Ha egy áramköri DSL egyedi verzióját fontolgatja, mert például egy új próbarendszer prototípusát készíti, de nem biztos a kötelezettségvállalási sémában vagy a megfelelő elliptikus görbében, az arkworks lehetővé teszi, hogy gyorsan váltson több lehetőség között megosztott interfészekkel. mint a nulláról kezdeni.

Ahhoz, hogy bizonyítást készítsünk bizonyos számításokról, először ezt a számítást olyan formában kell kifejezni, amelyet a zkSNARK rendszer képes megérteni. Számos tartományspecifikus nyelv hozott létre olyan programozási nyelveket, amelyek lehetővé teszik az alkalmazásfejlesztők számára, hogy számításaikat ilyen módon fejezzék ki. Ezek tartalmazzák Aztec Noir, Starknet Kairó, Circom, ZoKrates, és Aleo's oroszlán többek között. A mögöttes bizonyítási rendszer és a matematikai részletek általában nem hozzáférhetők az alkalmazásfejlesztő számára.

A zkApp fejlesztőknek jártasnak kell lenniük programjaik tartományspecifikus nyelveken történő megírásában. E nyelvek némelyike ​​nagyon hasonlít az ismert programozási nyelvekre, míg másokat meglehetősen nehéz megtanulni. Nézzünk meg ezek közül néhányat:

Kairó – Starkware DSL szükséges az alkalmazások Starkneten való építéséhez. A Cairo zkVM által értelmezhető Kairó-specifikus assembly nyelvre fordítja le.

ZoKrates — A ZoKrates egy eszközkészlet a gyakori SNARK-szükségletekhez, beleértve az áramkörök írásához szükséges magas szintű nyelvet. A ZoKrates rendelkezik némi rugalmassággal a görbék, a bizonyítási séma és a háttérrendszer körül is, lehetővé téve a fejlesztők számára, hogy egyszerű CLI-argumentummal üzem közben cseréljenek.

Circom — A Circom egy erre a célra kialakított nyelv áramkörök készítésére. Jelenleg ez a de facto nyelv a termelésben lévő áramkörökhöz. A nyelv nem kifejezetten ergonomikus. Maga a nyelv pontosan tudatában van annak a ténynek, hogy áramköröket írsz.

oroszlán - A Leo-t az Aleo blokklánc nyelveként fejlesztették ki. A Leo-nak van némi Rust-szerű szintaxisa, és kifejezetten a blokkláncon belüli állapotátmenetekhez készült.

Noir – Rozsda ihlette szintaxis. Inkább az infrastruktúra köré épül, mint maga a nyelv, ami azt jelenti, hogy tetszőleges frontendje lehet. 

Bármely alkalmazásfejlesztő, aki ki akarja használni a zk egyedi tulajdonságait az alkalmazásában. E nyelvek némelyikét harci tesztelésnek vetették alá, és dollármilliárdok mozogtak rajtuk olyan láncokon keresztül, mint a ZCash és a Starknet. Míg néhány projekt, amelyet meg fogunk vitatni, még nem teljesen készen a termelési használatra, jelenleg az áramkörök írása ezen nyelvek valamelyikén a legjobb stratégia, hacsak nincs szüksége azokra az eszközökre, mint az Arkworks.

A zkEVM elsődleges célja egy Ethereum állapotátmenet felvétele és érvényességének bizonyítása egy tömör nulla tudású helyességigazolás segítségével. Mint Vitalik bejegyzésében említettük, ennek számos módja van, finom különbségekkel és megfelelő kompromisszumokkal. 

A fő technikai különbség mindezek között pontosan az, hogy a nyelvi veremben a számítás hol alakul át egy bizonyító rendszerben használható formává (aritmetizálás). Egyes zkEVM-ekben ez a magas szintű nyelveken történik (Solidity, Vyper, Yul), míg más megközelítések az EVM-et próbálják bizonyítani egészen a műveleti kód szintjéig. Vitalik bejegyzése mélyen tárgyalta az e megközelítések közötti kompromisszumokat, de egy mondatban összefoglalom: Minél alacsonyabb a konverzió/aritmetizálás a veremben, annál nagyobb a teljesítménybüntetés.

A virtuális gépek bizonyítványainak létrehozásával a fő kihívás az, hogy az áramkör mérete arányosan nő az ÖSSZES lehetséges utasítás méretével minden végrehajtott utasításhoz. Ez azért fordul elő, mert az áramkör nem tudja, hogy az egyes programok milyen utasításokat hajtanak végre, ezért mindegyiket támogatnia kell.

Ez a gyakorlatban azt jelenti, hogy a lehető legdrágább utasításért fizet (teljesítményköltségben), még akkor is, ha csak a legegyszerűbb utasítást hajtja végre. Ez közvetlen kompromisszumhoz vezet az általánosíthatóság és a teljesítmény között – amint további utasításokat ad hozzá az általánosíthatósághoz, ezért fizetnie kell minden utasítást, amit bebizonyítasz!

Ez alapvető probléma az univerzális áramköröknél, de új technológiai fejlesztések az IVC-hez (inkrementálisan verifikálható számítás) hasonlóan ez a korlátozás enyhíthető, ha a számítást kisebb darabokra bontjuk, amelyek mindegyike speciális, kisebb aláramkörökkel rendelkezik.

A mai zkEVM-megvalósítások különböző stratégiákat használnak a probléma hatásának mérséklésére… A zkSync például a drágább műveleteket (főleg kriptográfiai előfordításokat, mint például a hash-eket és az ECDSA-t) a fő végrehajtás-ellenőrző áramkörből külön áramkörökbe szedi össze, amelyeket a vége snark rekurzióval. A zkSync ezt a megközelítést választotta, miután rájött, hogy költségeik többsége néhány összetett utasításból származik.

Lényegében az az oka, hogy az EVM-mel egyenértékűbb utasításkészlet bizonyítása drágább, hogy az EVM-et nem zk-számításokra tervezték. Az EVM korábbi veremben való elhagyása lehetővé teszi, hogy a zkEVM-ek olyan utasításkészleteken futhassanak, amelyek jobban optimalizáltak a zk-re, és így olcsóbb a bizonyítása.

A zkEVM ideális vásárlói az intelligens szerződéses alkalmazások, amelyeknek nagyságrendekkel olcsóbb tranzakciókra van szükségük, mint ami az L1 Ethereumon elérhető. Ezek a fejlesztők nem feltétlenül rendelkeznek azzal a szakértelemmel vagy sávszélességgel, hogy a semmiből írjanak zk-alkalmazásokat. Ezért inkább olyan magasabb szintű nyelveken írják meg alkalmazásaikat, amelyeket jól ismernek, mint például a Solidity. 

Scaling Ethereum jelenleg a zk technológia legkeresettebb alkalmazása.

A zkEVM egy Ethereum skálázási megoldás, amely súrlódásmentesen enyhíti az L1 dApp fejlesztőket korlátozó torlódási problémát.

A zkEVM célja egy olyan fejlesztői élmény támogatása, amely a lehető legközelebb áll a jelenlegi Ethereum fejlesztéshez. A teljes Solidity támogatás azt jelenti, hogy a csapatoknak nem kell több kódbázist felépíteniük és karbantartaniuk. Ezt némileg nem praktikus tökéletesen kivitelezni, mert a zkEVM-eknek bizonyos kompatibilitást kell kompromisszumot kötniük ahhoz, hogy ésszerű időn belül ésszerű méretű bizonyítékokat tudjanak előállítani.

Az elsődleges különbség a zkSync és a Scroll között az, hogy a veremben hol/mikor hajtanak végre aritmetizálást – vagyis hol konvertálják át a normál EVM-konstrukciókat SNARK-barát reprezentációvá. A zkSync esetében ez akkor történik, amikor a YUL bájtkódot saját egyéni zk utasításkészletükké alakítják. A Scroll esetében ez a végén történik, amikor a tényleges végrehajtási nyomkövetést tényleges EVM műveleti kódokkal állítják elő.

Tehát a zkSync esetében minden ugyanaz, mint az EVM-mel való interakció, amíg a zk bájtkód létre nem jön. A Scroll esetében minden ugyanaz, amíg a tényleges bájtkód le nem fut. Ez egy finom különbség, amely a teljesítményt a támogatással váltja fel. Például a zkSync nem támogatja az EVM bájtkódos eszközöket, mint például a hibakeresőt, mert ez egy teljesen más bájtkód. Míg a Scrollnak nehezebb lesz jó teljesítményt elérni egy utasításkészletből, ezt nem zk-hez tervezték. Mindkét stratégiának vannak előnyei és hátrányai, és végső soron sok külső tényező befolyásolja a relatív sikerüket.

???? Az LLVM elnevezése ellenére nem virtuális gép. Az LLVM a fordítóeszközök egy halmazának a neve, amelyet egy köztes reprezentáció (IR) rögzít, amely nyelvi agnosztikus.

=nil; Alapítvány (a névvel kapcsolatban ez a SQL injekciós vicc ha kíváncsi) olyan fordítót épít, amely bármely LLVM frontend nyelvet képes átalakítani egy köztes reprezentációvá, amely bizonyítható a SNARK-on belül. A zkLLVM a meglévő LLVM infrastruktúra kiterjesztéseként készült, egy iparági szabványnak megfelelő eszközlánc, amely számos magas szintű nyelvet támogat, mint például a Rust, C, C++ stb.

Az a felhasználó, aki bizonyítani akar valamilyen számítást, egyszerűen végrehajtja ezt a számítást C++ nyelven. A zkLLVM ezt a magas szintű forráskódot veszi fel, amelyet a módosított clang fordítójuk (jelenleg C++) támogat, és létrehozza az áramkör néhány közbenső reprezentációját. Ezen a ponton az áramkör készen áll a bizonyításra, de a felhasználó bizonyos dinamikus bemenetek alapján bizonyítani szeretné az áramkört. A dinamikus bemenetek kezelésére a zkLLVM rendelkezik egy további komponenssel, amelyet hozzárendelésnek neveznek, és amely hozzárendelési táblázatot generál az összes bemenettel és tanúval, amely teljesen előfeldolgozott, és készen áll az áramkör melletti bizonyításra.

Ez a 2 komponens mindössze annyi, ami a bizonyításhoz szükséges. A felhasználó elméletileg maga is generálhat bizonyítékot, de mivel ez egy kissé speciális számítási feladat, előfordulhat, hogy valaki másnak akar fizetni, aki rendelkezik a hardverrel, hogy ezt elvégezze helyette. Ennél a partnerfelderítési mechanizmusnál =nil; Az Alapítvány egy „bizonyítási piacot” is létrehozott, ahol a bizonyítók versengenek, hogy igazolják a számításokat azon felhasználók számára, akik fizetnek érte. Ez a szabadpiaci dinamika elvezeti a bizonyítókat a legértékesebb bizonyítási feladatok optimalizálásához.

Mivel minden bizonyítandó számítási feladat egyedi, és más-más áramkört generál, végtelen számú áramkör létezik, amelyet a bizonyítóknak tudniuk kell kezelni. Ez a kényszerített általánosíthatóság megnehezíti az egyes áramkörök optimalizálását. A próbapiac bevezetése lehetővé teszi a szakosodást azokra az áramkörökre, amelyeket a piac értékesnek tart. E piac nélkül nehéz lenne meggyőzni egy szakértőt, hogy optimalizálja ezt az áramkört a természetes hidegindítási probléma miatt.

A másik kompromisszum a klasszikus absztrakció kontra kontroll. Azok a felhasználók, akik hajlandóak elfogadni ezt a könnyen használható felületet, feladják a mögöttes kriptográfiai primitívek feletti irányítást. Sok felhasználó számára ez egy nagyon érvényes kompromisszum, mivel gyakran jobb, ha hagyja, hogy a kriptográfiai szakértők hozzák meg ezeket a döntéseket Ön helyett.

A zkVM az összes zk virtuális gép szuperkészletét írja le, míg a zkEVM a zkVM egy sajátos típusa, amelyet a mai elterjedtsége miatt külön témaként érdemes volt tárgyalni. Vannak olyan projektek is, amelyek általánosabb zkVM-ek létrehozásán dolgoznak, amelyek az egyedi kriptográfiai virtuális gépek mellett ISA-kon alapulnak.

Az EVM bizonyítása helyett a rendszer egy másik utasításkészlet-architektúrát (ISA), például RISC-V-t vagy WASM-et bizonyíthat egy új virtuális gépben. Két projekt, amely ezeken az általánosított zkVM-eken dolgozik, a RISC Zero és a zkWASM. Nézzünk egy kicsit a RISC Zero-ba, hogy bemutassuk, hogyan működik ez a stratégia és néhány előnye/hátránya. 

A RISC Zero képes bizonyítani minden olyan számítást, amelyet RISC-V architektúrán hajtanak végre. A RISC-V egy nyílt forráskódú utasításkészlet architektúra (ISA) szabvány, amely egyre népszerűbb. A RISC (redukált utasításkészletű számítógép) filozófiája egy rendkívül egyszerű, minimális bonyolultságú utasításkészlet felépítése. Ez azt jelenti, hogy a verem magasabb szintjein lévő fejlesztők nagyobb terhelést kapnak az utasítások végrehajtása során ezzel az architektúrával, miközben egyszerűbbé teszik a hardveres megvalósítást.

Ez a filozófia az általános számítástechnikára is érvényes, az ARM chipek RISC-stílusú utasításkészleteket használnak, és elkezdték uralni a mobil chipek piacát. Kiderült, hogy az egyszerűbb utasításkészleteknek nagyobb az energia- és a szerszámterület-hatékonysága is.

Ez az analógia elég jól érvényesül a zk bizonyítások előállításának hatékonyságára. Amint azt korábban tárgyaltuk, a végrehajtási nyomkövetés zk-ban való bizonyításakor a nyomkövetés minden eleme után az összes utasítás költségének összegét kell fizetnie, így jobb az egyszerűbb és kevesebb összes utasítás.

Fejlesztői szemmel nézve a RISC Zero használata a zk-bizonyítások kezelésére olyan, mint az AWS Lambda függvények használata a háttérkiszolgáló-architektúra kezelésére. A fejlesztők egyszerűen kódírással lépnek kapcsolatba a RISC Zero-val vagy az AWS Lambdával, és a szolgáltatás kezeli a háttérrendszer összes bonyolultságát.

A RISC Zero-hoz a fejlesztők Rust vagy C++ nyelvet írnak (végül bármit, ami a RISC-V-t célozza meg). A rendszer ezután veszi a fordítás során generált ELF-fájlt, és azt használja a virtuálisgép-áramkör bemeneti kódjaként. A fejlesztők egyszerűen meghívják a prove-t, amely visszaad egy nyugtát (amely tartalmazza a végrehajtási nyomkövetés zk igazolását) objektumot, amelyet bárki bárhonnan meghívhat "verify"-ként. Fejlesztői szemmel nézve nem kell érteni a zk működéséhez, a mögöttes rendszer kezeli mindezt a bonyolultságot.

Néhány alapvető és újrafelhasználható áramkör esetében, amelyek különösen hasznosak a blokklánc-alkalmazásokban vagy máshol, a csapatok már elkészítették és optimalizálták ezeket az áramköröket. Csak megadhatja a bemenetet az adott használati esethez. A Merkle-bevonási bizonyíték például olyan dolog, amelyre általában szükség van a kriptoalkalmazásokban (airdrop listák, Tornado Cash stb.). Alkalmazásfejlesztőként bármikor újra felhasználhatja ezeket a harcban tesztelt szerződéseket, és egyszerűen módosíthatja a felül lévő rétegeket, hogy egyedi alkalmazást hozzon létre.

Például a Tornado Cash áramkörei újra felhasználhatók a privát airdrop alkalmazás vagy privát szavazási alkalmazás. A Manta és a Semaphore egy egész eszközkészletet készít az ehhez hasonló, általános áramköri kütyükből, amelyek felhasználhatók a Solidity szerződésekben, anélkül, hogy a mögöttes zk hold matematikai ismereteit vagy egyáltalán nem értik.

Amint azt hosszasan tárgyaltuk, számtalan különböző lehetőség létezik a zk-alkalmazások fejlesztésére, amelyek mindegyike saját egyedi kompromisszumokkal rendelkezik. Ez a diagram segít összefoglalni ezt a döntési mátrixot, így a zk szakértelme és teljesítményigényei alapján kiválaszthatja a feladathoz a legjobb eszközt. Ez nem egy átfogó lista, a jövőben tervezem kiegészíteni, amint tudomást szerezek a térben megjelenő további eszközökről.

A zk számos technológia élvonalában van, és megépítéséhez a matematika, a kriptográfia, a számítástechnika és a hardvertechnika mélyreható ismerete szükséges. Mégis, mivel minden nap egyre több absztrakciós réteg áll rendelkezésre, az alkalmazásfejlesztők Ph.D. fokozat nélkül is kihasználhatják a zk erejét. Mivel a bizonyítási idő korlátai az idő múlásával lassan feloldódnak az optimalizálás révén a verem minden szintjén, valószínűleg még egyszerűbb eszközöket fogunk látni az átlagos fejlesztők számára.

Remélem, sikerült meggyőzni Önt, a kíváncsi szoftverfejlesztőt, hogy már ma elkezdheti használni a zk-t az alkalmazásaiban. Boldog hackelést 🙂

közzétételek: A Blockchain Capital több fent említett protokoll befektetője.

Az egyes blogbejegyzésekben kifejtett nézetek az egyes szerzők személyes nézetei lehetnek, és nem feltétlenül tükrözik a Blockchain Capital és leányvállalatai nézeteit. Sem a Blockchain Capital, sem a szerző nem garantálja az egyes blogbejegyzésekben közölt információk pontosságát, megfelelőségét vagy teljességét. A Blockchain Capital, a szerző vagy bármely más személy nem vállal semmilyen kifejezett vagy hallgatólagos nyilatkozatot vagy garanciát a blogbejegyzésekben szereplő információk pontosságára, teljességére vagy tisztességére vonatkozóan, és semmilyen felelősséget vagy felelősséget nem vállalunk. minden ilyen információért. Az egyes blogbejegyzésekben semmi sem minősül befektetési, szabályozási, jogi, megfelelőségi, adózási vagy egyéb tanácsnak, és nem is lehet rá támaszkodni a befektetési döntés meghozatalakor. A blogbejegyzéseket nem szabad értékpapírok vételére vagy eladására, illetve befektetési stratégia elfogadására vonatkozó jelenlegi vagy korábbi ajánlásoknak vagy felkéréseknek tekinteni. A blogbejegyzések tartalmazhatnak előrejelzéseket vagy más előremutató állításokat, amelyek olyan hiedelmeken, feltételezéseken és várakozásokon alapulnak, amelyek számos lehetséges esemény vagy tényező hatására változhatnak. Ha változás történik, a tényleges eredmények lényegesen eltérhetnek az előretekintő nyilatkozatokban megfogalmazottaktól. Minden előretekintő állítás csak az ilyen kijelentések időpontjában szól, és sem a Blockchain Capital, sem a szerzők nem vállalnak semmilyen kötelezettséget az ilyen kijelentések frissítésére, kivéve a törvény által előírt eseteket. Amennyiben a Blockchain Capital által készített, közzétett vagy más módon terjesztett dokumentumokra, prezentációkra vagy egyéb anyagokra hivatkozás történik bármely blogbejegyzésben, az ilyen anyagokat figyelmesen kell elolvasni a benne foglalt felelősségkizárásokra.