Een ontwikkelaarshandleiding voor de zkGalaxy

Dit is een uiterst nuttige heuristiek om benaderingen te onderscheiden voor het ondersteunen van een zkEVM. ZkEVM's zijn echter een subset van alle mogelijke manieren om zero-knowledge-applicaties te bouwen. Voor een programmeur die gebruik wil maken van de unieke eigenschappen van zk-berekening, namelijk beknoptheid, nul kennis en correctheid, is een zkEVM misschien niet de beste keuze. Door de volledige set ontwikkelaarstools te presenteren, hoop ik een gids te bieden die helpt bij het besluitvormingsproces rond de juiste zk-stack voor uw toepassing.

De afgelopen twee jaar is er enorm veel vooruitgang geboekt op het gebied van zk-tools. Ze naderen een punt waarop gewone softwareontwikkelaars de krachtige eigenschappen van zk kunnen benutten zonder een diep begrip van de intimiderende onderliggende wiskunde en techniek. Aan de andere kant is er een wildgroei aan tools voor power-users die zk-experts extreem fijne controle over de zk-stack geven.

Moderne software is gebouwd op talloze abstractielagen om de productiviteit van specialisten te maximaliseren. Er zijn veel voordelen aan abstractie in engineering die enigszins intuïtief zijn - een webontwikkelaar hoeft niet diepgaand te begrijpen hoe besturingssystemen werken. 

De sleutel tot het bouwen van goede, herbruikbare abstractielagen is om de complexiteit van een laag in te kapselen en vervolgens eenvoudige, maar expressieve interfaces te bieden die hogere lagen in de stapel kunnen gebruiken. Als dit op de juiste manier wordt gedaan, stelt dit ontwikkelaars met verschillende expertisegebieden en kennis in staat om nuttige tools voor de stapel te bouwen.

Het zal geen verrassing zijn dat dezelfde principes van toepassing zijn op zk-systemen, en deze abstractielagen worden volwassen genoeg voor een zk-beginner om ze te gaan gebruiken en vandaag nog applicaties te bouwen.

Arkworks-rs is een ecosysteem van Rust-bibliotheken dat efficiënte en veilige implementaties biedt van de subcomponenten van een zkSNARK-applicatie. Arkworks biedt de interfaces die ontwikkelaars nodig hebben om de softwarestack voor een zk-toepassing aan te passen zonder de overeenkomsten met andere bestaande bibliotheken opnieuw te hoeven implementeren.

Vóór Arkworks was de enige manier om een ​​nieuwe zk-applicatie te maken, alles vanaf nul te bouwen. De belangrijkste voordelen van Arkworks-rs ten opzichte van op maat gemaakte, verticaal geïntegreerde tools zijn de mate van flexibiliteit, de vermindering van dubbele engineering en de vermindering van auditinspanningen. De verstandige interfacelijnen van Arkworks tussen componenten zorgen voor een tempo van upgradebaarheid dat de stapel relevant kan houden te midden van het zinderende tempo van innovatie in zk-technologieën, zonder teams te dwingen alles vanaf nul opnieuw op te bouwen.

Arkworks is voor projecten die fijne controle over de volledige zk-softwarestack nodig hebben, maar niet alle overtollige stukken vanaf nul willen bouwen. Als u een aangepaste versie van een circuit-DSL overweegt, bijvoorbeeld omdat u een prototype maakt van een nieuw proefsysteem, maar niet zeker bent van het commitment-schema of de bijbehorende elliptische curve, kunt u met arkworks snel wisselen tussen verschillende opties met gedeelde interfaces. dan vanaf nul beginnen.

Om een ​​bewijs te leveren voor een bepaalde berekening, moet deze berekening eerst worden uitgedrukt in een vorm die een zkSNARK-systeem kan begrijpen. Verschillende domeinspecifieke talen hebben programmeertalen gecreëerd waarmee applicatieontwikkelaars hun berekeningen op een dergelijke manier kunnen uitdrukken. Deze omvatten Azteekse Noir, Starknet's Cairo, omtrek, ZoKrates, en die van Aleo Leeuw onder andere. Het onderliggende bewijssysteem en wiskundige details worden over het algemeen niet aan de applicatieontwikkelaar getoond.

zkApp-ontwikkelaars moeten bekwaam worden in het schrijven van hun programma's in domeinspecifieke talen. Sommige van deze talen lijken veel op bekende programmeertalen, terwijl andere behoorlijk moeilijk te leren zijn. Laten we er een paar opsplitsen:

Cairo – Starkware DSL nodig voor het bouwen van apps op Starknet. Compileert naar Cairo-specifieke assembleertaal die kan worden geïnterpreteerd door de Cairo zkVM.

ZoKrates - ZoKrates is een toolkit voor algemene SNARK-behoeften, inclusief een taal op hoog niveau om circuits te schrijven. ZoKrates heeft ook enige flexibiliteit rond de curves, het bewijsschema en de backend, waardoor ontwikkelaars kunnen hot-swappen door middel van een eenvoudig CLI-argument.

omtrek — Circom is een speciaal gebouwde taal voor het bouwen van circuits. Momenteel is het de de-facto taal voor circuits in productie. De taal is niet bijzonder ergonomisch. De taal zelf maakt je scherp bewust van het feit dat je circuits schrijft.

Leeuw — Leo is ontwikkeld als de taal voor de Aleo-blockchain. Leo heeft een Rust-achtige syntaxis en is speciaal gemaakt voor toestandsovergangen binnen een blockchain.

Noir - Roest-geïnspireerde syntaxis. Ontworpen rond de IR in plaats van de taal zelf, wat betekent dat het een willekeurige frontend kan hebben. 

Elke applicatieontwikkelaar die wil profiteren van de unieke eigenschappen van zk in zijn applicatie. Sommige van deze talen zijn op de proef gesteld met miljarden dollars die er doorheen zijn gegaan via ketens zoals ZCash en Starknet. Hoewel sommige van de projecten die we zullen bespreken nog niet helemaal klaar zijn voor productiegebruik, is het schrijven van je circuits in een van deze talen momenteel de beste strategie, tenzij je de fijnere controles nodig hebt die een toolkit zoals Arkworks biedt.

Het primaire doel van een zkEVM is om een ​​Ethereum-statusovergang te maken en de geldigheid ervan te bewijzen met behulp van een beknopt nulkennisbewijs van correctheid. Zoals vermeld in de post van Vitalik, zijn er een aantal manieren om dit te doen met subtiele verschillen en overeenkomstige compromissen. 

Het belangrijkste technische verschil tussen al deze is precies waar in de taalstapel de berekening wordt omgezet in een vorm (rekenen) die kan worden gebruikt in een bewijssysteem. In sommige zkEVM's gebeurt dit bij de talen op hoog niveau (Solidity, Vyper, Yul), terwijl andere benaderingen proberen de EVM helemaal tot op het opcode-niveau te bewijzen. De compromissen tussen deze benaderingen werden uitgebreid besproken in de post van Vitalik, maar ik zal het in één zin samenvatten: hoe lager de conversie/rekenbewerking in de stapel, hoe groter de prestatieboete.

De grootste uitdaging bij het maken van bewijzen voor een virtuele machine is dat de grootte van het circuit evenredig groeit met de grootte van ALLE mogelijke instructies voor elke uitgevoerde instructie. Dit gebeurt omdat het circuit niet weet welke instructies in elk programma zullen worden uitgevoerd, dus het moet ze allemaal ondersteunen.

In de praktijk betekent dit dat u (in uitvoeringskosten) betaalt voor de duurst mogelijke instructie, ook al voert u alleen de eenvoudigste instructie uit. Dit leidt tot een directe wisselwerking tussen generaliseerbaarheid en prestaties. Naarmate u meer instructies voor generaliseerbaarheid toevoegt, betaalt u hiervoor elk instructie bewijst u!

Dit is een fundamenteel probleem met universele circuits, maar met nieuwe ontwikkelingen in technologieën net als IVC (incremental verifiable compute), kan deze beperking worden verbeterd door de berekening op te splitsen in kleinere stukjes die elk gespecialiseerde, kleinere subcircuits hebben.

De huidige zkEVM-implementaties gebruiken verschillende strategieën om de impact van dit probleem te verminderen... Zo haalt zkSync bijvoorbeeld de duurdere bewerkingen (meestal cryptografische pre-compilaties zoals hashes en ECDSA) uit het hoofdcircuit voor het bewijzen van de uitvoering in afzonderlijke circuits die bij elkaar worden geaggregeerd. eindigen via snark-recursie. zkSync koos voor deze aanpak nadat ze zich realiseerden dat het grootste deel van hun kosten voortkwam uit een paar complexe instructies.

In wezen is de reden dat het bewijzen van een meer EVM-equivalente instructieset duurder is, dat de EVM niet is ontworpen voor zk-berekeningen. Door de EVM eerder in de stapel op te geven, kunnen zkEVM's worden uitgevoerd op instructiesets die meer zijn geoptimaliseerd voor zk, en dus goedkoper om te bewijzen.

De ideale klanten voor een zkEVM zijn slimme contracttoepassingen die veel goedkopere transacties nodig hebben dan wat beschikbaar is op L1 Ethereum. Deze ontwikkelaars hebben niet noodzakelijkerwijs de expertise of bandbreedte om zk-applicaties helemaal opnieuw te schrijven. Daarom geven ze er de voorkeur aan om hun applicaties te schrijven in talen van een hoger niveau waarmee ze vertrouwd zijn, zoals Solidity. 

Ethereum schalen is momenteel de meest gevraagde toepassing van zk-technologie.

Een zkEVM is een Ethereum-schaaloplossing die probleemloos het congestieprobleem vermindert dat L1 dApp-ontwikkelaars beperkt.

Het doel van een zkEVM is om een ​​ontwikkelaarservaring te ondersteunen die zo dicht mogelijk bij de huidige Ethereum-ontwikkeling ligt. Volledige Solidity-ondersteuning betekent dat teams niet meerdere codebases hoeven te bouwen en onderhouden. Dit is enigszins onpraktisch om perfect te doen, omdat zkEVM's enige compatibiliteit moeten inruilen om in een redelijke tijd bewijzen van redelijke omvang te kunnen genereren.

Het belangrijkste verschil tussen zkSync en Scroll is waar/wanneer in de stapel ze rekenen - dat wil zeggen, waar ze converteren van normale EVM-constructies naar een SNARK-vriendelijke weergave. Voor zkSync gebeurt dit wanneer ze de YUL-bytecode converteren naar hun eigen aangepaste zk-instructieset. Voor Scroll gebeurt dit aan het einde, wanneer de daadwerkelijke uitvoeringstracering wordt gegenereerd met daadwerkelijke EVM-opcodes.

Dus voor zkSync is alles hetzelfde als interactie met de EVM totdat de zk bytecode is gegenereerd. Voor Scroll is alles hetzelfde totdat de daadwerkelijke bytecode wordt uitgevoerd. Dit is een subtiel verschil, dat prestaties inruilt voor ondersteuning. ZkSync ondersteunt bijvoorbeeld geen EVM bytecode-tools zoals een out-of-the-box debugger, omdat het een compleet andere bytecode is. Hoewel Scroll meer moeite zal hebben om goede prestaties uit een instructieset te halen, is dat niet ontworpen voor zk. Er zijn voor- en nadelen aan beide strategieën en uiteindelijk zijn er veel exogene factoren die hun relatieve succes zullen beïnvloeden.

👏  Ondanks de naamgeving is LLVM geen VM (virtuele machine). LLVM is de naam van een set compilertools die is verankerd door een intermediaire representatie (IR) die taalonafhankelijk is.

=nihil; Stichting (over de naam, het is een SQL injectie grap als je het je afvraagt) bouwt een compiler die elke LLVM-frontend-taal kan converteren naar een tussenliggende weergave die kan worden bewezen binnen een SNARK. De zkLLVM is ontworpen als een uitbreiding op de bestaande LLVM-infrastructuur, een industriestandaard toolchain die veel talen op hoog niveau ondersteunt, zoals Rust, C, C++ enz.

Een gebruiker die wat berekeningen wil bewijzen, implementeert die berekening gewoon in C ++. De zkLLVM neemt deze broncode op hoog niveau die wordt ondersteund door hun aangepaste clang-compiler (momenteel C++) en genereert een tussenliggende weergave van het circuit. Op dit punt is het circuit klaar om te worden bewezen, maar de gebruiker wil misschien het circuit bewijzen op basis van enkele dynamische invoer. Om dynamische invoer te verwerken, heeft de zkLLVM een extra component die de toewijzer wordt genoemd, die een toewijzingstabel genereert met alle invoer en getuigen volledig voorverwerkt en klaar om naast het circuit te worden bewezen.

Deze 2 componenten zijn alles wat nodig is om een ​​bewijs te genereren. Een gebruiker kan in theorie zelf een bewijs genereren, maar aangezien dit een enigszins gespecialiseerde rekentaak is, willen ze misschien iemand anders betalen, die over de hardware beschikt, om het voor hen te doen. Voor dit tegenpartijdetectiemechanisme = nihil; Foundation heeft ook een 'bewijsmarkt' opgezet waar bewijsbewijzen wedijveren om berekeningen te bewijzen voor gebruikers die hen daarvoor zullen betalen. Deze vrije marktdynamiek zal ertoe leiden dat rijskasten de meest waardevolle rijstaken optimaliseren.

Aangezien elke te bewijzen rekentaak uniek is en een ander circuit genereert, is er een oneindig aantal circuits dat bewijsmiddelen nodig hebben om aan te kunnen. Deze geforceerde generaliseerbaarheid maakt het optimaliseren van individuele circuits moeilijk. De introductie van een proefmarkt maakt specialisatie mogelijk op de circuits die de markt waardevol acht. Zonder deze markt zou het een uitdaging zijn om een ​​testrijder te overtuigen om dit circuit te optimaliseren vanwege dit natuurlijke koudestartprobleem.

De andere wisselwerking is de klassieke abstractie versus controle. Gebruikers die bereid zijn om deze gebruiksvriendelijke interface te gebruiken, geven de controle over de onderliggende cryptografische primitieven op. Voor veel gebruikers is dit een zeer geldige afweging, omdat het vaak beter is om de cryptografie-experts deze beslissingen voor u te laten nemen.

Een zkVM beschrijft de superset van alle virtuele zk-machines, terwijl een zkEVM een specifiek type zkVM is, dat de moeite waard was om als apart onderwerp te bespreken vanwege de prevalentie ervan tegenwoordig. Er zijn een paar andere projecten die werken aan het bouwen van meer algemene zkVM's die zijn gebaseerd op ISA's naast de op maat gemaakte crypto-VM's.

In plaats van de EVM te bewijzen, zou het systeem een ​​andere instructiesetarchitectuur (ISA) kunnen bewijzen, zoals RISC-V of WASM in een nieuwe VM. Twee projecten die werken aan deze gegeneraliseerde zkVM's zijn RISC Zero en zkWASM. Laten we hier een beetje in RISC Zero duiken om te demonstreren hoe deze strategie werkt en enkele van de voor- en nadelen ervan. 

RISC Zero kan elke berekening bewijzen die wordt uitgevoerd op een RISC-V-architectuur. RISC-V is een open-source ISA-standaard (Instructions Set Architecture) die steeds populairder wordt. De RISC-filosofie (gereduceerde instructiesetcomputer) is het bouwen van een uiterst eenvoudige instructieset met minimale complexiteit. Dit betekent dat de ontwikkelaars in de hogere lagen van de stack uiteindelijk een grotere taak op zich nemen bij het implementeren van instructies met behulp van deze architectuur, terwijl de hardware-implementatie eenvoudiger wordt.

Deze filosofie is ook van toepassing op algemeen computergebruik, ARM-chips maken gebruik van instructiesets in RISC-stijl en beginnen de markt van mobiele chips te domineren. Het blijkt dat de eenvoudigere instructiesets ook een grotere energie- en matrijsruimte-efficiëntie hebben.

Deze analogie geldt redelijk goed voor de efficiëntie van het genereren van zk-bewijzen. Zoals eerder besproken, betaalt u bij het bewijzen van een uitvoeringspoor in zk voor de som van de kosten van alle instructies per item in het spoor, dus eenvoudiger en minder totale instructies is beter.

Vanuit het perspectief van een ontwikkelaar lijkt het gebruik van RISC Zero om zk-bewijzen af ​​te handelen veel op het gebruik van AWS Lambda-functies om de backend-serverarchitectuur te verwerken. Ontwikkelaars communiceren met RISC Zero of AWS Lambda door simpelweg code te schrijven en de service handelt alle backend-complexiteit af.

Voor RISC Zero schrijven ontwikkelaars Rust of C++ (uiteindelijk alles dat gericht is op RISC-V). Het systeem neemt vervolgens het ELF-bestand dat tijdens de compilatie is gegenereerd en gebruikt dat als de invoercode voor het VM-circuit. Ontwikkelaars noemen eenvoudigweg proof dat een ontvangstbewijs retourneert (dat het zk-bewijs van de uitvoeringstracering bevat) dat iedereen overal vandaan 'verify' kan noemen. Vanuit het oogpunt van de ontwikkelaar is het niet nodig om te begrijpen hoe zk werkt, het onderliggende systeem kan al deze complexiteit aan.

Voor sommige basis- en herbruikbare circuits die bijzonder nuttig zijn voor blockchain-applicaties of elders, hebben teams deze circuits mogelijk al voor u gebouwd en geoptimaliseerd. U kunt alleen de invoer leveren voor uw specifieke use-case. Een Merkle-opnamebewijs is bijvoorbeeld iets dat vaak nodig is in crypto-applicaties (airdrop-lijsten, Tornado Cash, enz.). Als applicatieontwikkelaar kun je deze beproefde contracten altijd opnieuw gebruiken en gewoon de bovenste lagen aanpassen om een ​​unieke applicatie te creëren.

De circuits van Tornado Cash kunnen bijvoorbeeld worden hergebruikt voor een privé airdrop-applicatie of privé stemtoepassing. Manta en Semaphore bouwen een hele toolkit met gemeenschappelijke circuitgadgets zoals deze die kunnen worden gebruikt in Solidity-contracten met weinig of geen begrip van de onderliggende zk moon-wiskunde.

Zoals uitvoerig besproken, zijn er talloze verschillende opties voor het ontwikkelen van een zk-applicatie, allemaal met hun eigen unieke set afwegingen. Deze grafiek helpt deze beslissingsmatrix samen te vatten, zodat u op basis van uw niveau van zk-expertise en prestatiebehoeften de beste tool voor de klus kunt kiezen. Dit is geen uitgebreide lijst, ik ben van plan hier in de toekomst aan toe te voegen naarmate ik me bewust word van meer tools die in de ruimte komen.

zk bevindt zich op het snijvlak van verschillende technologieën en het bouwen ervan vereist een grondige kennis van wiskunde, cryptografie, informatica en hardware-engineering. Maar nu er elke dag meer en meer abstractielagen beschikbaar zijn, kunnen app-ontwikkelaars de kracht van zk benutten zonder een Ph.D. Aangezien de beperkingen van testtijden in de loop van de tijd langzaam worden opgeheven via optimalisaties op alle niveaus van de stapel, zullen we waarschijnlijk nog eenvoudigere tools zien voor de gemiddelde ontwikkelaar.

Ik hoop dat ik u, de nieuwsgierige softwareontwikkelaar, ervan heb overtuigd dat u zk vandaag nog in uw toepassingen kunt gaan gebruiken. Veel plezier met hacken 🙂

informatieverschaffing: Blockchain Capital is een investeerder in verschillende van de bovengenoemde protocollen.

De standpunten die in elke blogpost worden uitgedrukt, kunnen de persoonlijke mening van elke auteur zijn en weerspiegelen niet noodzakelijkerwijs de mening van Blockchain Capital en zijn gelieerde ondernemingen. Noch Blockchain Capital, noch de auteur garandeert de juistheid, geschiktheid of volledigheid van de informatie die in elk blogbericht wordt verstrekt. Geen verklaring of garantie, expliciet of impliciet, wordt gemaakt of gegeven door of namens Blockchain Capital, de auteur of enige andere persoon met betrekking tot de juistheid en volledigheid of eerlijkheid van de informatie in een blogbericht en er wordt geen verantwoordelijkheid of aansprakelijkheid aanvaard voor dergelijke informatie. Niets in elk blogbericht vormt advies op het gebied van investeringen, regelgeving, juridische zaken, naleving of belasting of ander advies, noch kan er op worden vertrouwd bij het nemen van een investeringsbeslissing. Blogposts mogen niet worden gezien als huidige of vroegere aanbevelingen of verzoeken om een ​​aanbod om effecten te kopen of te verkopen of om een ​​beleggingsstrategie te volgen. De blogposts kunnen projecties of andere toekomstgerichte verklaringen bevatten, die gebaseerd zijn op overtuigingen, veronderstellingen en verwachtingen die kunnen veranderen als gevolg van vele mogelijke gebeurtenissen of factoren. Als er zich een verandering voordoet, kunnen de daadwerkelijke resultaten wezenlijk verschillen van die uitgedrukt in de toekomstgerichte verklaringen. Alle toekomstgerichte verklaringen gelden alleen vanaf de datum waarop dergelijke verklaringen zijn gedaan, en noch Blockchain Capital, noch elke auteur neemt enige plicht op zich om dergelijke verklaringen bij te werken, behalve zoals vereist door de wet. Voor zover er naar documenten, presentaties of ander materiaal geproduceerd, gepubliceerd of anderszins gedistribueerd door Blockchain Capital wordt verwezen in een blogpost, moet dergelijk materiaal worden gelezen met zorgvuldige aandacht voor eventuele disclaimers die daarin worden vermeld.