Il machine learning a zero conoscenza (zkML) è una fusione di magia crittografica e intelligenza artificiale; immagina di provare che un modello di machine learning ha prodotto un risultato specifico senza rivelare l'input del modello, il suo funzionamento interno o i risultati: questo è il sogno di zkML - attualmente ci sono vari metodi all'avanguardia che si contendono per trasformarlo in realtà.
In questo articolo, esploreremo tre paradigmi leader di zkML - JOLT (modificato per operazioni di machine learning e dotato di funzionalità di pre-compilazione: JOLTx), EZKL (basato su Halo2) e DeepProve (basato su GKR), confrontando come funzionano e le loro prestazioni, e spiegando perché l'approccio incentrato sulla ricerca di JOLT scuoterà l'intero settore come una palla di neve su un taxi.
Che cos'è zkML?
Il machine learning a zero conoscenza (zkML) è un campo emergente che combina le prove a zero conoscenza (ZKP) con il machine learning (ML) per realizzare calcoli ML verificabili e protetti da privacy; zkML consente ai dimostratori di provare che i modelli di ML sono stati eseguiti correttamente senza rivelare input sensibili o richiedere ai verificatori di rieseguire i calcoli; puoi anche usarlo per nascondere i pesi e i modelli.
Questo è cruciale per applicazioni come la finanza decentralizzata, l'intelligenza artificiale a protezione della privacy e il calcolo sicuro off-chain; garantendo la privacy e la fiducia nelle inferenze di ML, zkML apre la strada a applicazioni AI trasparenti e scalabili in blockchain, Web3 e oltre.
Le basi tecniche di zkML
Basato su JOLT, zkML (JOLTx) è una zkVM, una macchina virtuale a conoscenza zero in grado di dimostrare l'esecuzione di qualsiasi programma (documento JOLT, blog di JOLT).
JOLT è mirato all'insieme di istruzioni RISC-V, il che significa che puoi compilare qualsiasi programma (scritto in linguaggi ad alto livello come Rust o C++) in linguaggio assembly RISC-V e quindi generare una prova che il codice assembly funzioni correttamente.
JOLT introduce un nuovo front-end basato sul concetto di "singolarità di ricerca": non impone più vincoli algebrici pesanti per ogni operazione, ma trasforma le istruzioni CPU in ricerche in una enorme tabella di risultati di istruzioni predefiniti, ogni passo di calcolo (come addizione, moltiplicazione, persino operazioni bitwise) viene verificato confrontandosi con questa tabella tramite parametri di ricerca rapidi chiamati Lasso o Shout.
I circuiti di JOLT devono solo eseguire operazioni di ricerca in queste tabelle, semplificando notevolmente il processo di generazione della prova; ad esempio, operazioni "o" e "e" a 64 bit (che comportano costi elevati sotto vincoli aritmetici normali) possono essere completate in JOLT con una sola ricerca su tabella.
Questo design garantisce che il dimostratore in ogni istruzione CPU esegua principalmente il lavoro di inviare un numero ridotto di elementi di campo (circa 6 numeri da 256 bit per passaggio) e dimostrare la correttezza di queste ricerche, rendendo JOLT un metodo generale e scalabile: qualsiasi modello di machine learning può essere visto come un programma e provato con un design di circuito personalizzato minimo.
Pianifichiamo di contribuire con alcune funzionalità di pre-compilazione dedicate per operazioni di machine learning nella pila JOLT; le non linearità possono essere gestite in modo efficiente tramite ricerca, mentre altre proprietà comuni possono essere gestite tramite somma e verifica e alcune tecniche uniche di JOLT zkVM.
Estendiamo questo a JoltX, ma in realtà stiamo solo aggiungendo alcuni strumenti e funzionalità di pre-compilazione dedicate sulla base di JOLT, ci aspettiamo di rilasciarlo tra qualche mese, rimanete sintonizzati!
Quali altri progetti eccellenti di zkML ci sono?
EZKL (basato su Halo2) - EZKL adotta un approccio più tradizionale ai circuiti SNARK costruito su Halo2.
EZKL non simula la CPU, ma opera a livello del grafo di calcolo del modello di machine learning; gli sviluppatori esportano reti neurali (o qualsiasi grafo di calcolo) in file ONNX, e il toolkit EZKL li compila in un insieme di vincoli polinomiali personalizzati per quel modello (circuiti aritmetici).
Ogni strato di una rete neurale - ad esempio convoluzioni, operazioni matriciali, funzioni di attivazione - è trasformato in vincoli che il dimostratore Halo2 può risolvere; per gestire operazioni non naturali polinomiali (come attivazioni ReLU o operazioni su numeri interi grandi), Halo2 utilizza anche parametri di ricerca, ma in modo più limitato.
Ad esempio, tabelle di grandi dimensioni (come tutte le $2^{64}$ possibilità per operazioni a 64 bit) devono essere suddivise o "bloccate" in tabelle più piccole (come blocchi a 16 bit), e richiedono più ricerche insieme a vincoli di ricombinazione per simulare le operazioni originali; questa suddivisione aumenta il sovraccarico e la complessità del circuito.
Pertanto, la generazione di prove di EZKL implica la creazione di molti di questi vincoli e l'uso dell'algoritmo di prova di Halo2 (solitamente KZG o impegni basati su Halo) per generare la prova; il vantaggio dell'approccio EZKL è che ha una capacità di percezione del modello - può essere ottimizzato specificamente per i livelli delle reti neurali, e può persino potare o quantificare i pesi per migliorare l'efficienza.
Tuttavia, ogni nuovo modello o tipo di livello potrebbe richiedere la scrittura di vincoli personalizzati o almeno rigenerare il circuito, e il dimostratore deve affrontare sistemi di vincoli di grandi dimensioni, il che potrebbe essere lento per modelli di grandi dimensioni.
DeepProve (basato su GKR) - DeepProve proposto da Lagrange ha seguito un percorso diverso, utilizzando un protocollo di prova interattivo chiamato GKR (Goldwasser–Kalai–Rotblum).
In sostanza, GKR tratta l'intero processo di calcolo (simile alla propagazione in avanti di un modello di machine learning) come un circuito aritmetico gerarchico, e prova la sua correttezza attraverso protocolli di somma e verifica anziché complicate operazioni polinomiali. Il flusso di lavoro di DeepProve consiste nell'estrarre il modello (anche attraverso ONNX) e quindi generare automaticamente la sequenza di calcolo corrispondente a ciascun strato della rete neurale.
Non sta semplicemente convertendo in circuiti SNARK statici, ma utilizza GKR per verificare ogni livello in modo interattivo, controllando l'output di ciascun livello con il suo input con il minimo sovraccarico di hash criptografici/impegni; il provatore nello schema GKR esegue realmente il calcolo del modello e poi fornisce una prova interattiva (utilizzando l'algoritmo di Fiat-Shamir per renderla non interattiva) per garantire al verificatore che ogni strato sia stato calcolato correttamente.
Il vantaggio di GKR è che la complessità del dimostratore è lineare rispetto alle dimensioni del circuito (O(n)), rallentando solo di un fattore costante rispetto all'esecuzione normale; infatti, per alcuni compiti (come la moltiplicazione di matrici di grandi dimensioni), i moderni sistemi basati su GKR possono essere più lenti di meno di 10 volte rispetto all'esecuzione normale. DeepProve combina questo con tecnologie moderne di impegno polinomiale, producendo prove concise dopo il giro di verifica e creando così zkSNARK per l'inferenza delle reti neurali in modo efficace.
Uno svantaggio di GKR è che è più adatto a calcoli strutturati (come i livelli statici delle reti neurali) e comporta logiche di protocollo crittografico più complesse, ma il suo vantaggio risiede nella velocità grezza nella dimostrazione di calcoli profondi.
Vantaggi e svantaggi
Ogni metodo ha i suoi vantaggi unici e potenziali svantaggi.
JOLTx (zkVM pre-compilato basato sulla ricerca)
Vantaggi: estremamente flessibile (può dimostrare qualsiasi codice, non solo reti neurali), e beneficia dell'ottimizzazione della "singolarità di ricerca" di JOLT, rendendo anche le operazioni a livello di bit a basso costo.
Non ha bisogno di circuiti personalizzati per ogni modello - basta compilare per eseguire - questo migliora notevolmente l'esperienza degli sviluppatori e riduce la probabilità di bug.
L'uso di Lasso per la ricerca significa dimostrare che i vincoli si espandono principalmente in base al numero delle operazioni eseguite piuttosto che alla loro complessità, fornendo così a JOLT un modello di costo coerente.
Svantaggi: come macchina virtuale generale, potrebbe comportare un certo sovraccarico per ogni istruzione; per modelli enormi contenenti milioni di operazioni semplici, metodi specializzati come GKR possono raggiungere tempi di prova assoluti più bassi attraverso calcoli in streaming.
Inoltre, JOLT è relativamente nuovo - si basa su un nuovo parametro di ricerca e su una tabella ISA complessa, che rappresentano tecnologie all'avanguardia e richiedono tempo per maturare, ma considerando il suo design, anche il prototipo attuale di JOLT supera in efficienza le precedenti zkVM.
EZKL (Halo2 / PLONK)
Vantaggi: è costruito su un framework SNARK ampiamente utilizzato, il che significa che può beneficiare di strumenti esistenti, audit e supporto per validatori on-chain (le prove di Halo2 possono essere verificate utilizzando tecniche crittografiche amichevoli per Ethereum).
EZKL è piuttosto facile da usare per i data scientist: puoi utilizzare modelli PyTorch o TensorFlow, esportarli in ONNX e ottenere prove che l'inferenza del modello è stata completata correttamente.
Ha già realizzato integrazioni reali (da modelli di rischio DeFi a AI nei giochi, di cui parleremo più avanti), indicando che può provare compiti di machine learning reali.
Svantaggi: con la crescita del modello, le prestazioni potrebbero diventare un collo di bottiglia; i circuiti SNARK tradizionali tendono a comportare enormi sovraccarichi - storicamente, il carico di lavoro del dimostratore è stato mille volte superiore a quello di semplicemente eseguire il modello.
L'approccio di Halo2 cerca di ottimizzare, ma operazioni come la moltiplicazione di grandi matrici o attivazioni non lineari si traducono comunque in molti vincoli, aumentando la necessità di suddividere le ricerche di grandi dimensioni (ad esempio, aritmetica a 32 bit o funzioni non lineari) che aggiungono vincoli e tempo di prova extra.
In sostanza, EZKL potrebbe avere difficoltà a gestire reti molto grandi (in termini di tempo di prova e memoria), a volte richiedendo di suddividere circuiti o utilizzare tecniche speciali per adattarsi ai vincoli pratici; è un buon metodo SNARK generale, ma non è il più veloce quando si tratta di scalabilità.
DeepProve (GKR)
Vantaggi: offre velocità di generazione di prove estremamente elevate per modelli profondi. Evitando il sovraccarico di codificare ogni moltiplicazione come vincolo polinomiale, GKR consente al dimostratore di eseguire quasi solo calcoli numerici regolari, quindi aggiunge uno strato sottile di verifica crittografica. Il team di DeepProve riporta che, su reti neurali equivalenti, la velocità di prova di GKR è da 54 a 158 volte più veloce di EZKL.
Infatti, più grande è il modello, maggiore è il vantaggio di GKR: man mano che la complessità del modello aumenta, i vantaggi di DeepProve crescono, poiché la sua espansione lineare rimane controllabile, mentre i costi dei metodi basati su circuiti continuano ad espandersi.
Svantaggi: questo approccio è in qualche modo limitato a calcoli simili a circuiti (fortunatamente, questi calcoli coprono la maggior parte del machine learning feedforward); se il vostro carico di lavoro include molta logica condizionale o operazioni irregolari, la sua flessibilità diminuirà - tali operazioni sono più facili da gestire in macchine virtuali come JOLT.
Inoltre, impostare le prove GKR come prove a zero conoscenza e concise porta a prove più grandi rispetto alle tradizionali prove SNARK e ai programmi di verifica; sebbene queste ultime siano molto più veloci nel rieseguire l'intero modello, non sono immediate.
Il tempo di verifica delle prove di DeepProve per le CNN è di circa 0,5 secondi, il che è molto buono per modelli grandi, ma i tradizionali verificatori SNARK possono completare le verifiche in millisecondi.
Pertanto, DeepProve si concentra sulle prestazioni, il che potrebbe avvenire a costo della complessità del protocollo di prova e di compiti di verifica leggermente più pesanti rispetto alle prove di Halo2; è un potente metodo per scalare zkML, specialmente in ambienti server o cloud, anche se potrebbe non essere adatto per client leggeri o verifiche on-chain senza ulteriori ottimizzazioni.
Confronto di prestazioni ed efficienza
In termini di prestazioni grezze, ogni metodo zkML ha priorità diverse; il tempo di generazione della prova è spesso un indicatore chiave. Attualmente, il dimostratore di DeepProve basato su GKR è in cima alla classifica in termini di velocità: i benchmark indicano che, con lo stesso modello, genera prove da 50 a 150 volte più velocemente di EZKL.
Questo salto deriva dall'algoritmo di tempo quasi lineare di GKR, che evita le pesanti operazioni algebriche polinomiali dei circuiti SNARK; in effetti, inferenze di reti neurali che EZKL potrebbe richiedere ore per dimostrare, usando DeepProve richiedono solo pochi minuti, e man mano che la scala del modello aumenta (più livelli, più parametri), questo divario si allarga ulteriormente, poiché il sovraccarico di GKR rimane basso mentre quello di Halo2 continua a crescere.
Gli obiettivi di prestazione di JOLT sono altrettanto ambiziosi: mira a essere un ordine di grandezza più veloce dei framework SNARK esistenti; il team di a16z ha dimostrato che Lasso (il motore di ricerca di JOLT) è 10 volte più veloce della meccanica di ricerca di Halo2, e prevede di aumentare la velocità fino a 40 volte.
Ciò significa che operazioni che un tempo erano colli di bottiglia (come quelle fastidiose operazioni bitwise o operazioni su grandi campi) diventano molto più economiche; JOLT scambia essenzialmente calcoli per ricerche di tabelle, e grazie a Lasso, il costo di cercare valori in enormi tabelle virtuali è molto basso, non aumenta con l'aumentare delle dimensioni della tabella (no, non memorizzano effettivamente 2^{128} righe di dati in memoria!) - cresce principalmente con il numero di ricerche eseguite.
Pertanto, se il vostro modello di machine learning esegue un milione di ReLU, il costo del dimostratore crescerà con queste milioni di operazioni, ma ogni operazione è solo un rapido controllo di tabella; i risultati preliminari indicano che il dimostratore di JOLT gestisce solo un numero ridotto di impegni di elementi di campo per ogni istruzione, con un sovraccarico estremamente basso. In breve, JOLT sta massimizzando il carico computazionale di ogni operazione, saltando i complessi calcoli matematici dinamici attraverso l'uso della conoscenza pre-calcolata (tabelle di ricerca), riducendo così notevolmente il sovraccarico tradizionale di SNARK.
La combinazione di EZKL con Halo2, sebbene più lenta, non è nemmeno stagnante; beneficia delle ottimizzazioni di Halo2, come porte personalizzate e ricerche parziali; EZKL è completamente utilizzabile per modelli di dimensioni moderate e si è dimostrato migliore di alcune prime alternative; su Cairo, è circa 3 volte più veloce dei metodi basati su STARK, e in un benchmark del 2024, è stato 66 volte più veloce di RISC-V STARK.
Ciò indica che circuiti SNARK ben ottimizzati possono superare le macchine virtuali con implementazioni più semplici, mentre il rovescio della medaglia è che per raggiungere tali velocità, EZKL e Halo2 devono ottimizzare tutto con attenzione, e continuano a ereditare i costi fondamentali degli impegni polinomiali, delle FFT e degli algoritmi di prova.
Al contrario, i nuovi metodi di JOLT e DeepProve evitano gran parte del sovraccarico delle FFT o dei polinomi di ordine superiore - JOLT limitandosi a operazioni di ricerca (insieme a un nuovo parametro per gestire in modo efficiente le operazioni di ricerca), mentre DeepProve utilizza somma e verifica (che si applicano a polinomi multilineari e richiedono solo impegni hash leggeri).
Nei circuiti SNARK classici, molto tempo viene speso nel calcolo di operazioni come grandi FFT o moltiplicazioni scalari multiple; GKR evita in gran parte le FFT eseguendo operazioni su ipercubi booleani e estensioni multilineari, mentre JOLT evita le grandi FFT necessarie per le ricerche non implementando tabelle gigantesche sin dall'inizio.
In termini di dimensioni della prova e verifica, ci sono compromessi; JOLT e EZKL (Halo2) generano infine prove SNARK standard (solitamente di pochi KB) che possono essere verificate rapidamente (alcuni abbinamenti o alcune valutazioni polinomiali).
L'approccio di DeepProve è simile a STARK, e potrebbe generare prove più grandi (da decine a centinaia di KB, a seconda del modello), e la verifica, sebbene molto più veloce rispetto alla riesecuzione del modello, potrebbe comportare più passaggi rispetto a verificare prove KZG concise.
Il team di DeepProve sottolinea che la loro velocità di verifica è 671 volte più veloce rispetto al semplice ricalcolo di un MLP utilizzando una GPU; per modelli piuttosto complessi, il tempo di verifica può essere ridotto a circa 0,5 secondi.
Questo è un risultato potente che dimostra che anche se la scala della prova è più grande, verificarla è molto più facile rispetto a eseguire il calcolo dell'intelligenza artificiale originale (questo è particolarmente importante se il verificatore è un contratto intelligente o un client leggero con capacità computazionali limitate); le prove di Halo2 sono più piccole e la verifica è più veloce, ma se la velocità di prova è troppo lenta per la tua applicazione fin dall'inizio, questa differenza diventa irrilevante.
Un aspetto importante dell'efficienza è come queste strutture gestiscono operazioni speciali; ad esempio, nell'inferenza di machine learning, ci troviamo spesso di fronte a passaggi non lineari (come ArgMax, ReLU o Sigmoid); EZKL può gestire ReLU forzando i vincoli tramite selettori booleani (che possono essere gestiti tramite ricerca o altri vincoli).
Al contrario, JOLT può implementare ReLU nei programmi (come alcune istruzioni CPU basate su bit) e dimostrare questi rami a basso costo tramite ricerca, sfruttando essenzialmente la capacità di confronto della CPU.
DeepProve può adattarsi a funzioni lineari segmentate integrando queste nel circuito aritmetico che GKR deve verificare, ma funzioni altamente non lineari (come Sigmoid) potrebbero richiedere approssimazioni polinomiali o di ricerca; in generale, l'idea di JOLT è quella di rendere tutto ciò che è strano normale, eseguendo codice reale (compresi istruzioni condizionali, cicli, ecc.) e utilizzando parametri di ricerca per coprire la logica di qualsiasi operazione.
L'idea di Halo2 è di limitare tutto in equazioni polinomiali (a volte può essere complicato per operazioni complesse), mentre l'idea di GKR è di decomporre il calcolo in somme e prodotti verificabili in modo ricorsivo; l'efficienza con cui ciascun metodo affronta questi problemi si rifletterà nel tempo di prova: JOLT potrebbe eccellere nel controllare la logica, GKR nell'eseguire grandi operazioni di algebra lineare, e Halo2 si trova a metà strada, equilibra entrambi ma con un sovraccarico maggiore.
Per verificare la prova Kinic, utilizziamo la blockchain di Internet Computer, poiché gestisce verifiche di prove su scala più grande più rapidamente rispetto ad altre blockchain L1, e non siamo limitati dalla pre-compilazione, poiché questa richiede lavoro complesso per mettere JOLTx on-chain.
Scalabilità per modelli su larga scala
Quando parliamo di scalabilità in zkML, potremmo riferirci a due cose: gestire modelli grandi (multilivello, con molti parametri) e gestire modelli diversificati (architetture diverse o persino modelli dinamici); consideriamo prima la distribuzione su larga scala - supponiamo che tu voglia verificare l'inferenza su un grande CNN o su un Transformer con milioni di parametri.
DeepProve è progettato per questo scenario e le sue prestazioni raddoppiano man mano che aumenta la scala del modello; ad esempio, se un piccolo modello (come un MLP micro) dimostrato con DeepProve è 50 volte più veloce rispetto a EZKL, un modello più grande potrebbe essere più veloce di 100 volte.
Il team ha notato che man mano che ci si espande a modelli contenenti milioni di parametri, la velocità di DeepProve sarà più veloce rispetto ad altre soluzioni; pianificano di aumentare ulteriormente questa velocità attraverso tecniche di prova parallela e distribuita, GKR è facilmente parallelizzabile poiché molti sottocampioni (come tutti i neuroni in uno strato) possono essere verificati in batch.
Inoltre, GKR non richiede un gigantesco "chiave di prova" monolitico che cresca con la dimensione del circuito - è in grado di operare in tempo reale, quindi occupa meno memoria, rendendo DeepProve promettente per la verifica di reti neurali di grandi dimensioni su scala cloud o persino on-chain in futuro.
EZKL (Halo2) può gestire reti piuttosto grandi, ma ha anche delle limitazioni; costruire un singolo circuito gigante per modelli di grandi dimensioni può richiedere una quantità significativa di memoria e tempo (in alcuni casi, decine di GB di RAM e ore di tempo di calcolo); il team di EZKL sta esplorando metodi di miglioramento come la suddivisione e l'aggregazione dei circuiti (verificando le singole parti del modello e poi combinando le prove), insieme a strategie di quantizzazione per ridurre la complessità aritmetica.
Tuttavia, algoritmi SNARK generali come Halo2 continueranno a affrontare sfide dopo un certo livello di scala, a meno che non siano ottimizzati specificamente; potrebbe essere più adatto per modelli di medie dimensioni o in situazioni in cui le prove vengono fatte offline e non frequentemente (o dove sono disponibili hardware potenti).
Il vantaggio è che una volta generata la prova, anche per modelli grandi, verificarla è facile - questo è estremamente utile per scenari on-chain, poiché i contratti intelligenti potrebbero verificare prove di modelli con 100 milioni di parametri, il che sarebbe assolutamente impraticabile calcolare nuovamente on-chain.
JOLT si trova in una posizione interessante in termini di scalabilità: da un lato, è un metodo basato su SNARK, quindi il suo carico di lavoro deve anche essere linearmente correlato al numero di operazioni eseguite (come Halo2 e GKR).
D'altra parte, a causa dell'adozione di tecniche basate sulla ricerca, il costo di ogni operazione di JOLT è estremamente basso; se consideriamo un "distribuzione su larga scala", come eseguire un modello che contiene 10 milioni di operazioni, JOLT deve eseguire queste 10 milioni di ricerche e i relativi impegni, il che è gravoso, ma in sostanza non è più pesante di GKR o addirittura di un circuito semplice - rimane lineare.
La domanda è: quanto bene può JOLT ottimizzare e parallelizzare? Poiché JOLT considera ogni istruzione come un passaggio, se il sistema di prove supporta la tracciabilità divisa, può parallelizzare le prove eseguendo più istruzioni (simile a più core CPU).
La ricerca attuale indica che si concentrano inizialmente sulle prestazioni in singolo nucleo (il costo per passaggio è di circa 6 elementi di campo), ma poiché questo metodo è una macchina virtuale, è possibile immaginare in futuro di distribuire diverse parti della traccia del programma tra i dimostratori (questo è solo speculativo, ma considerando che i parametri di ricerca possono essere combinati, non è impossibile).
Anche senza distribuzioni elaborate, JOLT può sfruttare le tecniche di impegno polinomiale esistenti - ad esempio, supportando configurazioni generali per circuiti di qualsiasi dimensione, quindi non è necessario fornire nuove configurazioni affidabili per modelli più grandi.
Quando si tratta di gestire diverse architetture ML, JOLT si comporta eccellentemente: non importa se il tuo modello è un CNN, un RNN con cicli, un ensemble di alberi decisionali o un nuovo modello ibrido; finché puoi eseguirlo su CPU, JOLT può dimostrarlo, rendendolo altamente scalabile in termini di sviluppo - non è necessario riprogettare il metodo di prova per ogni nuovo tipo di modello.
DeepProve e altri metodi basati su GKR sono attualmente personalizzati per reti neurali profonde tipiche (livelli di operazioni matriciali e funzioni elemento), e possono scalare in modo eccellente con la profondità e la larghezza della rete; ma se si impongono carichi di lavoro molto irregolari (ad esempio, un modello che decide dinamicamente di saltare livelli o ha cicli di dipendenza dai dati), il framework potrebbe necessitare di aggiustamenti o potrebbe perdere un po' di efficienza.
Tuttavia, la maggior parte dei modelli di machine learning su larga scala già implementati (visioni, elaborazione del linguaggio naturale, ecc.) ha una struttura regolare, quindi questo non è un problema.
Ci si potrebbe chiedere: quale metodo è più adatto per l'uso in tempo reale o su dispositivo, piuttosto che su scala cloud? In tempo reale significa che anche per modelli più piccoli, vogliamo che le prove abbiano una latenza molto bassa.
L'approccio di JOLT è un SNARK, che potrebbe consentire di dimostrare modelli più piccoli in pochi secondi o meno su un dispositivo decente, soprattutto nel caso in cui la tecnologia sia matura; EZKL su CPU mobili potrebbe essere più lento (le prove di Halo2 non sono ancora completamente ottimizzate per i dispositivi mobili, anche se ci sono sforzi per accelerarlo).
DeepProve può sfruttare efficacemente le GPU - se un dispositivo ha una GPU, potrebbe effettivamente dimostrare molto rapidamente un piccolo modello (GKR ama l'hardware parallelo), ma DeepProve su CPU potrebbe non essere ottimizzato per scenari in tempo reale come JOLT su CPU.
Di conseguenza, la scalabilità non riguarda solo la gestione di modelli più grandi - riguarda anche la gestione efficace delle dimensioni appropriate nel contesto corretto; l'obiettivo di JOLT è di diventare un pilastro universale attraverso gli ambienti, rendendolo un forte candidato per il deployment sia nel cloud che ai margini.
JOLTx: ridefinire le capacità di zkML tramite verifica e ricerca
Ora che ci sono così tante innovazioni, perché dovremmo ancora sottolineare che zkML basato su JOLT è la migliore scelta per il futuro? La risposta risiede nella sua versatilità, prestazioni e applicazioni pratiche - questa combinazione è difficile da superare.
In primo luogo, JOLT introduce un nuovo paradigma per costruire SNARK: JOLT non incapsula più programmi ad alto livello nel circuito porta per porta, ma realizza la visione di circuiti progettati per eseguire solo operazioni di ricerca, il che significa che la complessità viene gestita nella fase di pre-calcolo (definendo quelle enormi tabelle di istruzioni), mentre nella fase online è molto semplice: è sufficiente dimostrare di aver eseguito una ricerca valida.
È come trasformare ogni operazione complessa nel circuito in passi "O(1)"; questo riduce notevolmente il sovraccarico che il dimostratore deve affrontare nell'eseguire compiti tradizionalmente molto complessi in SNARK (ad esempio, operazioni bitwise, logica ramificata arbitraria).
Per i modelli di machine learning, che di solito mescolano algebra lineare (gestita bene da SNARK) e decisioni non lineari o trasformazioni di dati (gestite male da SNARK), JOLT offre una soluzione bilanciata: l'algebra lineare deve ancora essere completata passo dopo passo, ma ogni operazione aritmetica è semplice. Qualsiasi decisione non lineare (ad esempio "se il neurone > 0 allora...") è anch'essa semplice, poiché la VM può semplicemente ramificare, e la prova della ramificazione corretta è solo un controllo di ricerca.
In secondo luogo, JOLT è veloce e la velocità continua a migliorare; la ricerca dietro di esso indica che la velocità del dimostratore può immediatamente aumentare di oltre 10 volte rispetto agli strumenti SNARK mainstream, e suggerisce che l'ottimizzazione possa portare a 40 volte.
Ha anche ereditato molti miglioramenti anticipati di SNARK: ha adottato moderne soluzioni di impegno polinomiale e può sfruttare librerie crittografiche esistenti; il suo core Lasso è incentrato sull'efficienza e ha già dimostrato prestazioni migliori rispetto alle prove tradizionali basate su ricerca (che rappresentano un collo di bottiglia per sistemi come Halo2).
Per il machine learning in tempo reale o locale, ciò significa che l'idea di generare prove su uno smartphone o un laptop improvvisamente non sembra più così folle; se il vostro modello di inferenza richiede tipicamente 100 millisecondi, JOLT potrebbe essere in grado di dimostrare questo in pochi secondi - è una grande cosa!
Al contrario, le prove nei metodi precedenti potrebbero richiedere diversi minuti o ore, rendendole inattuabili al di fuori delle sale server; il miglioramento dell'efficienza di JOLT avvicina zkML all'uso interattivo.
Ad esempio, possiamo immaginare un'estensione per browser che utilizza JOLT per dimostrare in tempo reale "Ho eseguito un modello visivo sull'immagine che hai appena caricato, e non contiene contenuti NSFW", prima di consentire la pubblicazione dell'immagine.
Oppure il computer di bordo dell'auto potrebbe dimostrare al server assicurativo che ha utilizzato un modello di guida verificato durante la guida autonoma; queste situazioni richiedono un rapido turnover, e la velocità di JOLT lo rende possibile.
Un altro fattore importante è l'esperienza degli sviluppatori e degli utenti; JOLT consente agli sviluppatori di utilizzare i linguaggi e i modelli con cui sono familiari (attraverso la compilazione RISC-V e la prossima conversione ONNX), senza dover comprendere la complessità dei circuiti SNARK per utilizzarli.
Per il campo del machine learning, questo è cruciale: la maggior parte degli ingegneri di machine learning non sono esperti di crittografia e non dovrebbero diventarlo; utilizzando JOLT, possono scrivere o compilare codice esistente e ottenere prove; questo approccio è simile alle prime GPU - inizialmente, solo esperti di grafica scrivevano codice GPU, ma alla fine i framework generali hanno consentito a qualsiasi programmatore di utilizzare l'accelerazione GPU.
In questo senso, JOLT è come una "GPU per le prove a zero conoscenza": un motore dedicato accessibile tramite catene di strumenti standard, il che riduce notevolmente la barriera all'adozione; è molto probabile che vedremo alcune librerie impacchettare compiti comuni di machine learning (come inferenza di modelli, prove di accuratezza dei modelli, ecc.) sopra JOLT per facilitare l'uso plug-and-play.
L'auditabilità di JOLT è un altro cambiamento sottile; poiché in sostanza si tratta di dimostrare l'esecuzione di un ISA standard, è più facile da dedurre e audire rispetto ai circuiti personalizzati: puoi fare affidamento sulla correttezza delle specifiche RISC-V ben definite e delle tabelle di ricerca, senza dover verificare migliaia di vincoli scritti a mano. Questo significa che le prove per i modelli di machine learning critici hanno una maggiore credibilità.
Ad esempio, se un modello è utilizzato per decisioni legali o mediche, avere una traccia chiara ("questo programma è stato eseguito correttamente") è molto più rassicurante rispetto a "questo circuito personalizzato, comprensibile solo a pochi esperti, è stato soddisfatto"; se necessario, gli auditor possono anche eseguire passo passo la traccia di esecuzione della macchina virtuale, cosa impossibile nelle prove dei circuiti monolitici.
Le prove a zero conoscenza basate su JOLT (zkML) combinano perfettamente l'eleganza teorica con implementazioni pratiche - offrono sia le innovazioni necessarie per la scalabilità, sia la flessibilità necessaria per un'ampia gamma di applicazioni, trasformando le prove a zero conoscenza in utilità ad alta velocità e amichevoli per gli sviluppatori.
Sebbene i metodi basati su Halo2 e GKR abbiano già aperto la strada, dimostrando le loro possibilità (e continueranno ad essere applicati con i loro vantaggi specifici), JOLT ha il potenziale di unificare e innalzare il campo di zkML, come un salto dall'assemblaggio manuale alla programmazione ad alto livello - una volta che una soluzione universale ed efficiente sarà disponibile, potrà consentire all'intero ecosistema di prosperare.
Per chiunque desideri implementare machine learning verificabile nella pratica, JOLT offre un chiaro e attraente percorso da seguire: prove rapide, adatte a qualsiasi modello, ovunque e in qualsiasi momento; il futuro di zkML appartiene anche a zkVM progettati con attenzione e al loro codice pre-compilato!
Contenuti IC di tuo interesse
Progresso tecnologico | Informazioni sul progetto | Attività globali
Collezioni e canale Binance IC
Rimani aggiornato