Una guida per sviluppatori a zkGalaxy

Questa è un'euristica estremamente utile per differenziare gli approcci per il supporto di zkEVM. Tuttavia, gli zkEVM sono un sottoinsieme di tutti i modi possibili per creare applicazioni a conoscenza zero. Per un programmatore che desidera sfruttare le proprietà uniche del calcolo zk, vale a dire concisione, zero conoscenza e correttezza, zkEVM potrebbe non essere la scelta migliore. Disponendo l'intero set di strumenti per sviluppatori, spero di fornire una guida che aiuti nel processo decisionale attorno allo stack zk giusto per la tua applicazione.

Negli ultimi due anni, c'è stato un enorme progresso negli strumenti zk. Si stanno avvicinando a un punto in cui i normali sviluppatori di software possono sfruttare le potenti proprietà di zk senza una profonda comprensione della matematica e dell'ingegneria sottostanti intimidatori. D'altra parte, c'è stata una proliferazione di strumenti per utenti esperti che offre agli esperti di zk un controllo estremamente preciso sullo stack di zk.

Il software moderno è costruito su innumerevoli livelli di astrazione per massimizzare la produttività specialistica. Ci sono molti vantaggi nell'astrazione nell'ingegneria che sono in qualche modo intuitivi: uno sviluppatore web non ha bisogno di capire in profondità come funzionano i sistemi operativi. 

La chiave per creare livelli di astrazione buoni e riutilizzabili è incapsulare la complessità di un livello e quindi fornire interfacce semplici ma espressive per i livelli più in alto nello stack da utilizzare. Fatto correttamente, ciò consente agli sviluppatori con diverse aree di competenza e conoscenza di creare strumenti utili in tutto lo stack.

Non sorprende che questi stessi principi si applichino ai sistemi zk e questi livelli di astrazione stanno diventando abbastanza maturi da consentire a un principiante zk di iniziare a usarli e creare applicazioni oggi.

Arkworks-rs è un ecosistema di librerie Rust che fornisce implementazioni efficienti e sicure dei sottocomponenti di un'applicazione zkSNARK. Arkworks fornisce le interfacce necessarie agli sviluppatori per personalizzare lo stack software per un'applicazione zk senza dover reimplementare i punti in comune con altre librerie esistenti.

Prima di Arkworks, l'unico modo per creare una nuova applicazione zk era creare tutto da zero. I principali vantaggi di Arkworks-rs rispetto agli strumenti personalizzati e integrati verticalmente sono il livello di flessibilità, la riduzione dell'ingegneria duplicata e la riduzione dello sforzo di auditing. Le sensate linee di interfaccia di Arkworks tra i componenti consentono un ritmo di aggiornabilità che può mantenere lo stack rilevante nel ritmo vertiginoso dell'innovazione nelle tecnologie zk, senza costringere i team a ricostruire tutto da zero.

Arkworks è per progetti che necessitano di un controllo preciso sull'intero stack software zk, ma non vogliono costruire da zero tutti i pezzi ridondanti. Se stai valutando una versione personalizzata di un circuito DSL perché, ad esempio, stai prototipando un nuovo sistema di prova ma non sei sicuro dello schema di impegno o della corrispondente curva ellittica, arkworks ti consentirà di scambiare rapidamente tra diverse opzioni con interfacce condivise, piuttosto piuttosto che partire da zero.

Per creare una dimostrazione su un calcolo, prima questo calcolo deve essere espresso in una forma comprensibile per un sistema zkSNARK. Diversi linguaggi specifici del dominio hanno creato linguaggi di programmazione che consentono agli sviluppatori di applicazioni di esprimere i loro calcoli in questo modo. Questi includono Noir azteco, di Starknet Cairo, Circon, ZoKrates, e di Aleo Leone tra gli altri. Il sistema di dimostrazione sottostante e i dettagli matematici generalmente non sono esposti allo sviluppatore dell'applicazione.

Gli sviluppatori di zkApp devono diventare esperti nella scrittura dei loro programmi in linguaggi specifici del dominio. Alcuni di questi linguaggi assomigliano molto a linguaggi di programmazione familiari, mentre altri possono essere piuttosto difficili da imparare. Analizziamo alcuni di questi:

Cairo – Starkware DSL necessario per creare app su Starknet. Compila in un linguaggio assembly specifico di Cairo che può essere interpretato da Cairo zkVM.

ZoKrates — ZoKrates è un toolkit per le esigenze comuni di SNARK, incluso un linguaggio di alto livello per scrivere circuiti. ZoKrates ha anche una certa flessibilità riguardo alle curve, allo schema di prova e al back-end, consentendo agli sviluppatori di eseguire l'hot-swap tramite un semplice argomento della CLI.

Circon — Circom è un linguaggio creato appositamente per la costruzione di circuiti. Attualmente è il linguaggio de facto per i circuiti in produzione. Il linguaggio non è particolarmente ergonomico. Il linguaggio stesso ti rende acutamente consapevole del fatto che stai scrivendo circuiti.

Leone — Leo è stato sviluppato come linguaggio per la blockchain Aleo. Leo ha una sintassi simile a Rust ed è creato appositamente per le transizioni di stato all'interno di una blockchain.

Nero – Sintassi ispirata a Rust. Architettato attorno all'IR piuttosto che al linguaggio stesso, il che significa che può avere un frontend arbitrario. 

Qualsiasi sviluppatore di applicazioni che desidera sfruttare le proprietà uniche di zk nella propria applicazione. Alcuni di questi linguaggi sono stati testati in battaglia con miliardi di dollari che si sono spostati su di essi tramite catene come ZCash e Starknet. Sebbene alcuni dei progetti di cui parleremo non siano ancora pronti per l'uso in produzione, scrivere i tuoi circuiti in uno di questi linguaggi è attualmente la migliore strategia, a meno che tu non abbia bisogno dei controlli più precisi forniti da un toolkit come Arkworks.

L'obiettivo principale di uno zkEVM è prendere una transizione di stato Ethereum e dimostrarne la validità utilizzando una breve prova di correttezza a conoscenza zero. Come accennato nel post di Vitalik, ci sono diversi modi per farlo con sottili differenze e corrispondenti compromessi. 

La principale differenza tecnica tra tutti questi è esattamente dove nello stack linguistico il calcolo viene convertito in una forma (aritmetizzazione) che può essere utilizzata in un sistema di dimostrazione. In alcuni zkEVM, ciò accade nei linguaggi di alto livello (Solidity, Vyper, Yul), mentre altri approcci tentano di dimostrare l'EVM fino al livello del codice operativo. I compromessi tra questi approcci sono stati trattati in modo approfondito nel post di Vitalik, ma lo riassumerò in una frase: più bassa è la conversione/aritmetizzazione nello stack, maggiore è la penalizzazione delle prestazioni.

La sfida principale con la creazione di prove per una macchina virtuale è che la dimensione del circuito cresce proporzionalmente alla dimensione di TUTTE le istruzioni possibili per ogni istruzione eseguita. Ciò si verifica perché il circuito non sa quali istruzioni verranno eseguite in ciascun programma, quindi deve supportarle tutte.

Ciò significa in pratica che paghi (in termini di costo delle prestazioni) per l'istruzione più costosa possibile, anche quando stai eseguendo solo l'istruzione più semplice. Ciò porta a un compromesso diretto tra generalizzabilità e prestazioni: man mano che aggiungi più istruzioni per la generalizzabilità, paghi per questo su ogni istruzione si dimostra!

Questo è un problema fondamentale con i circuiti universali, ma con nuovi sviluppi nelle tecnologie come IVC (calcolo verificabile incrementale), questa limitazione può essere migliorata suddividendo il calcolo in blocchi più piccoli che hanno ciascuno sottocircuiti specializzati e più piccoli.

Le odierne implementazioni di zkEVM utilizzano diverse strategie per mitigare l'impatto di questo problema... Ad esempio, zkSync estrae le operazioni più costose (principalmente precompilazioni crittografiche come hash ed ECDSA) dal circuito di prova dell'esecuzione principale in circuiti separati che vengono aggregati insieme al terminare tramite snark ricorsione. zkSync ha adottato questo approccio dopo aver realizzato che la maggior parte dei costi proveniva da poche istruzioni complesse.

Fondamentalmente, il motivo per cui dimostrare un set di istruzioni più equivalente a EVM è più costoso è che l'EVM non è stato progettato per i calcoli zk. L'abbandono dell'EVM in precedenza nello stack consente agli zkEVM di essere eseguiti su set di istruzioni più ottimizzati per zk e quindi più economici da provare.

I clienti ideali per uno zkEVM sono applicazioni di contratti intelligenti che richiedono transazioni di ordini di grandezza più economiche rispetto a quelle disponibili su L1 Ethereum. Questi sviluppatori non hanno necessariamente l'esperienza o la larghezza di banda per scrivere applicazioni zk da zero. Pertanto, preferiscono scrivere le loro applicazioni in linguaggi di livello superiore con cui hanno familiarità, come Solidity. 

Scalare Ethereum è attualmente l'applicazione più richiesta della tecnologia zk.

Una zkEVM è una soluzione di ridimensionamento di Ethereum che mitiga senza problemi il problema di congestione che limita gli sviluppatori di dApp L1.

L'obiettivo di zkEVM è supportare un'esperienza di sviluppo che sia il più vicino possibile all'attuale sviluppo di Ethereum. Il supporto Full Solidity significa che i team non devono creare e mantenere più codebase. Questo è in qualche modo poco pratico da fare perfettamente perché gli zkEVM devono compromettere una certa compatibilità per essere in grado di generare prove di dimensioni ragionevoli in un ragionevole lasso di tempo.

La differenza principale tra zkSync e Scroll è dove/quando nello stack eseguono l'aritmetizzazione, ovvero dove convertono dai normali costrutti EVM in una rappresentazione compatibile con SNARK. Per zkSync, ciò accade quando convertono il bytecode YUL nel proprio set di istruzioni zk personalizzato. Per Scroll, ciò accade alla fine, quando la traccia di esecuzione effettiva viene generata con i codici operativi EVM effettivi.

Quindi, per zkSync, tutto è come interagire con l'EVM fino a quando non viene generato il bytecode zk. Per Scroll, tutto è uguale finché non viene eseguito il bytecode effettivo. Questa è una sottile differenza, che compromette le prestazioni con il supporto. Ad esempio, zkSync non supporterà strumenti bytecode EVM come un debugger pronto all'uso, perché è un bytecode completamente diverso. Mentre Scroll avrà più difficoltà a ottenere buone prestazioni da un set di istruzioni, che non è stato progettato per zk. Ci sono pro e contro in entrambe le strategie e alla fine ci sono molti fattori esogeni che influiranno sul loro relativo successo.

💡 Nonostante la sua denominazione, LLVM non è una VM (macchina virtuale). LLVM è il nome di un set di strumenti del compilatore ancorato da una rappresentazione intermedia (IR) indipendente dal linguaggio.

= nullo; Fondazione (a proposito del nome, è a Scherzo sull'iniezione SQL se ti stai chiedendo) sta costruendo un compilatore in grado di convertire qualsiasi linguaggio frontend LLVM in una rappresentazione intermedia che può essere dimostrata all'interno di uno SNARK. zkLLVM è progettato come un'estensione dell'infrastruttura LLVM esistente, una toolchain standard del settore che supporta molti linguaggi di alto livello come Rust, C, C++ ecc.

Un utente che vuole provare un calcolo dovrebbe semplicemente implementare quel calcolo in C++. zkLLVM prende questo codice sorgente di alto livello che è supportato dal loro compilatore clang modificato (attualmente C++) e genera una rappresentazione intermedia del circuito. A questo punto, il circuito è pronto per essere provato, ma l'utente potrebbe voler provare il circuito sulla base di alcuni input dinamici. Per gestire gli input dinamici, zkLLVM ha un componente aggiuntivo denominato assegnatore, che genera una tabella di assegnazione con tutti gli input e i testimoni completamente pre-elaborati e pronti per essere provati insieme al circuito.

Questi 2 componenti sono tutto ciò che è necessario per generare una prova. Un utente può teoricamente generare una dimostrazione da solo, ma poiché si tratta di un'attività computazionale in qualche modo specializzata, potrebbe voler pagare qualcun altro, che abbia l'hardware, per farlo per loro. Per questo meccanismo di scoperta della controparte, =nil; La Fondazione ha anche istituito un "mercato delle prove" in cui i dimostratori competono per dimostrare il calcolo per gli utenti che li pagheranno per farlo. Questa dinamica del libero mercato porterà i prover a ottimizzare i compiti di proving più preziosi.

Poiché ogni attività computazionale da dimostrare è unica e genera un circuito diverso, esiste un numero infinito di circuiti che i dimostratori dovranno essere in grado di gestire. Questa generalizzabilità forzata rende difficile l'ottimizzazione dei singoli circuiti. L'introduzione di un mercato di prova consente la specializzazione sui circuiti che il mercato ritiene di valore. Senza questo mercato, sarebbe difficile convincere un prover a ottimizzare questo circuito a causa di questo naturale problema di avviamento a freddo.

L'altro compromesso è la classica astrazione contro il controllo. Gli utenti che sono disposti a utilizzare questa interfaccia di facile utilizzo stanno rinunciando al controllo sulle primitive crittografiche sottostanti. Per molti utenti, questo è un compromesso molto valido da fare, poiché spesso è meglio lasciare che siano gli esperti di crittografia a prendere queste decisioni per te.

Una zkVM descrive il superset di tutte le macchine virtuali zk, mentre una zkEVM è un tipo specifico di zkVM, che valeva la pena discutere come argomento separato a causa della sua prevalenza oggi. Ci sono alcuni altri progetti che stanno lavorando alla creazione di zkVM più generalizzate basate su ISA oltre alle VM crittografiche su misura.

Invece di provare l'EVM, il sistema potrebbe dimostrare un'architettura del set di istruzioni (ISA) diversa, come RISC-V o WASM in una nuova VM. Due progetti che stanno lavorando su queste zkVM generalizzate sono RISC Zero e zkWASM. Immergiamoci un po' in RISC Zero qui per dimostrare come funziona questa strategia e alcuni dei suoi vantaggi/svantaggi. 

RISC Zero è in grado di dimostrare qualsiasi calcolo eseguito su un'architettura RISC-V. RISC-V è uno standard ISA (Instruction Set Architecture) open source che sta guadagnando popolarità. La filosofia RISC (Reduced Instruction Set Computer) è quella di costruire un set di istruzioni estremamente semplice con una complessità minima. Ciò significa che gli sviluppatori ai livelli più alti dello stack finiscono per assumersi un carico maggiore nell'implementare le istruzioni utilizzando questa architettura, semplificando al contempo l'implementazione dell'hardware.

Questa filosofia si applica anche all'informatica generale, i chip ARM hanno sfruttato i set di istruzioni in stile RISC e hanno iniziato a dominare il mercato dei chip mobili. Si scopre che i set di istruzioni più semplici hanno anche una maggiore efficienza energetica e dell'area della matrice.

Questa analogia vale abbastanza bene per l'efficienza della generazione di dimostrazioni zk. Come discusso in precedenza, quando si dimostra una traccia di esecuzione in zk, si paga la somma del costo di tutte le istruzioni per ogni elemento nella traccia, quindi è meglio istruzioni più semplici e meno totali.

Dal punto di vista di uno sviluppatore, l'utilizzo di RISC Zero per gestire le prove zk è molto simile all'utilizzo delle funzioni AWS Lambda per gestire l'architettura del server back-end. Gli sviluppatori interagiscono con RISC Zero o AWS Lambda semplicemente scrivendo codice e il servizio gestisce tutta la complessità del back-end.

Per RISC Zero, gli sviluppatori scrivono Rust o C++ (eventualmente tutto ciò che prende di mira RISC-V). Il sistema quindi prende il file ELF generato durante la compilazione e lo utilizza come codice di input per il circuito VM. Gli sviluppatori chiamano semplicemente prove che restituisce un oggetto di ricevuta (che contiene la prova zk della traccia di esecuzione) che chiunque può chiamare "verifica" da qualsiasi luogo. Dal punto di vista dello sviluppatore, non c'è bisogno di capire come funziona zk, il sistema sottostante gestisce tutta questa complessità.

Per alcuni circuiti di base e riutilizzabili che sono particolarmente utili per le applicazioni blockchain o altrove, i team potrebbero aver già creato e ottimizzato questi circuiti per te. Puoi semplicemente fornire l'input per il tuo particolare caso d'uso. Una prova di inclusione di Merkle, ad esempio, è qualcosa che è comunemente necessario nelle applicazioni crittografiche (liste di airdrop, Tornado Cash, ecc.). In qualità di sviluppatore di applicazioni, puoi sempre riutilizzare questi contratti collaudati e modificare semplicemente i livelli in cima per creare un'applicazione unica.

Ad esempio, i circuiti di Tornado Cash possono essere riutilizzati per a applicazione airdrop privata o domanda di voto privato. Manta e Semaphore stanno costruendo un intero toolkit di gadget di circuito comuni come questo che possono essere utilizzati nei contratti Solidity con poca o nessuna comprensione della matematica zk moon sottostante.

Come discusso a lungo, ci sono una miriade di diverse opzioni per lo sviluppo di un'applicazione zk, tutte con il proprio insieme unico di compromessi. Questo grafico aiuterà a riassumere questa matrice decisionale in modo che, in base al tuo livello di esperienza zk e alle tue esigenze di prestazioni, tu possa scegliere lo strumento migliore per il lavoro. Questo non è un elenco completo, ho intenzione di aggiungerlo in futuro man mano che vengo a conoscenza di altri strumenti in arrivo nello spazio.

zk è all'avanguardia in diverse tecnologie e la sua costruzione richiede una profonda conoscenza della matematica, della crittografia, dell'informatica e dell'ingegneria hardware. Tuttavia, con sempre più livelli di astrazione disponibili ogni giorno, gli sviluppatori di app possono sfruttare la potenza di zk senza un dottorato di ricerca. Poiché i limiti dei tempi di prova vengono lentamente eliminati nel tempo tramite ottimizzazioni a tutti i livelli dello stack, probabilmente vedremo strumenti ancora più semplici per lo sviluppatore medio.

Spero di aver convinto te, il curioso sviluppatore di software, che puoi iniziare a utilizzare zk nelle tue applicazioni oggi. Buon Hacking 🙂

Informazioni integrative: Blockchain Capital è un investitore in molti dei protocolli sopra menzionati.

Le opinioni espresse in ciascun post del blog possono essere le opinioni personali di ciascun autore e non riflettono necessariamente le opinioni di Blockchain Capital e dei suoi affiliati. Né Blockchain Capital né l'autore garantiscono l'accuratezza, l'adeguatezza o la completezza delle informazioni fornite in ogni post del blog. Nessuna dichiarazione o garanzia, esplicita o implicita, è fatta o fornita da o per conto di Blockchain Capital, l'autore o qualsiasi altra persona in merito all'accuratezza, completezza o correttezza delle informazioni contenute in qualsiasi post del blog e nessuna responsabilità è accettata per tali informazioni. Nulla di quanto contenuto in ciascun post del blog costituisce consiglio di investimento, normativo, legale, di conformità o fiscale o di altro tipo, né è su cui fare affidamento per prendere una decisione di investimento. I post del blog non devono essere visti come raccomandazioni o sollecitazioni attuali o passate di un'offerta per l'acquisto o la vendita di titoli o per l'adozione di strategie di investimento. I post del blog possono contenere proiezioni o altre dichiarazioni previsionali, che si basano su convinzioni, ipotesi e aspettative che possono cambiare a seguito di molti possibili eventi o fattori. Se si verifica un cambiamento, i risultati effettivi possono variare materialmente da quelli espressi nelle dichiarazioni previsionali. Tutte le dichiarazioni previsionali parlano solo alla data in cui tali dichiarazioni sono state fatte e né Blockchain Capital né ciascun autore si assume alcun obbligo di aggiornare tali dichiarazioni ad eccezione di quanto richiesto dalla legge. Nella misura in cui qualsiasi documento, presentazione o altro materiale prodotto, pubblicato o altrimenti distribuito da Blockchain Capital sia citato in qualsiasi post del blog, tale materiale deve essere letto con particolare attenzione a qualsiasi esclusione di responsabilità ivi fornita.