Discorso di Gavin Wood: stato di avanzamento di JAM e strategia a medio-lungo termine per l’introduzione di ZK in JAM!

Questo articolo è la versione in cinese del discorso tenuto da Gavin Wood al Web3 Summit del mese scorso! Poiché la serie è piuttosto lunga, la pubblicheremo in quattro parti. Questo è il primo capitolo, che tratta principalmente i seguenti argomenti:

• Stato di avanzamento della consegna di JAM
• Le prestazioni ZK sono migliorate, ma sono ancora lontane dalla commercializzazione
• 33 ricalcoli vs prova matematica: il vero costo di due modelli di sicurezza
• Quanto costa un nodo ZK-JAM? La risposta è dieci volte più cara di quanto pensi!
• Percorso evolutivo a breve, medio e lungo termine di ZK in JAM

Vediamo insieme quali punti di vista interessanti ha condiviso Gavin!

Dunque, senza ulteriori indugi, di cosa parlerò in questo intervento?

Per prima cosa, vorrei condividere la mia visione generale su Polkadot, ovvero il punto di riflessione in cui mi trovo attualmente, che può essere inteso come uno “snapshot della situazione attuale”. Probabilmente avete già sentito parlare di JAM: è un progetto su cui lavoro da tempo e che è strettamente collegato a Polkadot. Speriamo che possa sostenere la prossima fase di sviluppo di Polkadot. Oltre a questo, parlerò anche di tecnologie di crittografia a conoscenza zero (ZK), in particolare della loro applicazione nell'espansione delle funzionalità della blockchain.

Inoltre, discuterò il modello economico del token DOT. Successivamente, presenterò alcune nuove ricerche a cui mi sto dedicando, volte a migliorare le capacità esistenti e persino a portare nuove possibilità a Polkadot e al più ampio mondo Web3. Questa parte copre diversi aspetti: alcuni saranno trattati in dettaglio, altri solo accennati. Bene, ora iniziamo ufficialmente.

Stato attuale della consegna di JAM

La versione iniziale di JAM era la 0.1, e ora si sta avvicinando gradualmente alla 1.0. Quando raggiungerà la 1.0, significherà che il protocollo JAM sarà pronto per essere adottato da Polkadot tramite aggiornamento. Con la progressiva stabilizzazione del protocollo, la nostra attenzione si sta spostando sull’ottimizzazione, in particolare sulla modellazione del gas. All’inizio di quest’anno, ho tenuto una presentazione specifica su questo argomento all’Ethereum Summit di Praga (East Prague). La modellazione del gas è un tema molto interessante, ma anche estremamente complesso.

JAM prevede di avviare l’audit del protocollo quest’anno. Nella serie di versioni 0.7 non resta molto lavoro da fare; ma nella versione 0.8 verrà introdotta ufficialmente la modellazione del gas, il che comporterà un aumento significativo del carico di lavoro. Mi aspetto che riusciremo a passare alla versione 0.9 quest’anno e a quel punto inizieremo ufficialmente l’audit.

Ovviamente, avere un protocollo core è una cosa, ma poterci sviluppare sopra è un’altra. Servono SDK, documentazione e altri strumenti di sviluppo. Questa parte è ancora agli inizi. Anche se ora è già possibile sviluppare software su JAM, in Parity sono principalmente io a guidare la costruzione e il rilascio dell’SDK. Tuttavia, realisticamente, serviranno ancora mesi o anni di lavoro continuo e perfezionamento. Naturalmente, lo sviluppo dell’SDK non sarà limitato a Parity. Mi aspetto che altri team si uniranno per costruire i propri JAM SDK.

Abbiamo già iniziato a definire lo standard per la messaggistica cross-service, che può essere visto come la versione JAM di XCM/XCMP. Nel frattempo, CoreVM sta diventando gradualmente parte dell’SDK e nei prossimi mesi sarà continuamente perfezionato e potenziato. CoreVM supporta già molte funzionalità, come output audio, output video, input/output dati, elaborazione delle transazioni e servizi interni in arrivo. Attualmente non supporta ancora EVM, ma è una funzionalità che intendiamo aggiungere. Inoltre, il meccanismo che in passato chiamavo coreplay (coordinamento centrale) è previsto per i prossimi 12–24 mesi.

Recentemente, nella chat di JAM, qualcuno ha sollevato una domanda interessante: come evitare che io stesso diventi un single point of failure per JAM? Attualmente, l’evoluzione del protocollo JAM dipende interamente da ciò che scrivo nella Gray Paper. Questo significa che, se mi succedesse qualcosa, l’intero progetto potrebbe bloccarsi. Ovviamente, non sarebbe positivo né per JAM né per me.

Pertanto, consideriamo il contenuto della Gray Paper come la specifica tecnica di JAM. L’ultima versione della Gray Paper corrisponde all’ultima versione di JAM. Se una versione della Gray Paper è stata auditata, il protocollo JAM che definisce può essere considerato maturo a livello produttivo, il che è molto diretto.

Quindi, in futuro, se l’aggiornamento della Gray Paper non dipenderà più solo da me, come evolverà?

La mia idea è di istituire un comitato editoriale. I membri iniziali saranno coloro che hanno realmente partecipato alla stesura della Gray Paper, la comprendono a fondo e hanno dato contributi sostanziali. Mi aspetto che questi membri mantengano un alto livello di partecipazione tecnica nell’implementazione di JAM. Io non mi ritirerò completamente, continuerò a essere il caporedattore, ma vorrei ridurre il mio carico di lavoro e dare ad altri il potere di proporre, revisionare e unire le modifiche.

Con JAM che supera la versione 1.0, questo comitato editoriale assumerà responsabilità di livello superiore:

• Non solo gestire piccoli cambiamenti, ma decidere la direzione di sviluppo e le priorità di JAM;
• Quando ci sono opinioni diverse, il giudizio collettivo del comitato dovrebbe essere la voce più autorevole.

Ho intenzione di nominare un vice, che possa subentrare in caso di mia assenza, ferie o altre situazioni. A lungo termine, i vice saranno anche responsabili della selezione, invito e decisione dei nuovi membri del comitato editoriale, per garantire che il meccanismo possa funzionare autonomamente. Alla fine, spero che questo sistema di governance possa diventare gradualmente indipendente, includendo anche la partecipazione di alcune organizzazioni esterne, come la Polkadot Fellowship.

Ho effettivamente intenzione di mettere la Gray Paper sotto una licenza open, anche se non ho ancora deciso quale, ma è molto probabile che sceglierò una licenza copyleft, con alcune clausole per prevenire l’abuso di brevetti.

Per quanto riguarda la governance di Polkadot, ha piena autorità di decidere quale protocollo eseguire. Polkadot è un protocollo sovrano e il meccanismo di governance ne è la manifestazione. Attualmente, la governance di Polkadot ha già espresso chiaramente la volontà di adottare JAM. Questo è positivo. Allo stesso tempo, anche altre reti possono scegliere di usare JAM, perché JAM è un protocollo aperto.

In futuro, se JAM continuerà a evolversi, Polkadot potrà scegliere di rimanere sincronizzato, seguendo sempre l’ultima versione; se non sarà soddisfatto della direzione di sviluppo di JAM, potrà anche fissarsi su una versione specifica, modificare il protocollo core o addirittura biforcare la Gray Paper. Questo dimostra che JAM è un sistema indipendente, e io personalmente spero che possa mantenere una relazione di reciproco beneficio con Polkadot a lungo termine. Ovviamente, se un giorno dovessero separarsi e svilupparsi indipendentemente, sarebbe comunque possibile.

Finché entrambe le parti saranno allineate, mi aspetto che la governance di Polkadot partecipi attivamente e supporti il funzionamento del comitato editoriale della Gray Paper. E se in futuro altri protocolli adotteranno JAM, spero che possano partecipare allo stesso modo.

Bene, questo è lo stato attuale di JAM, o meglio la fase che sta per raggiungere. Ora vorrei parlare delle prove a conoscenza zero (ZK).

Le prestazioni ZK sono migliorate, ma sono ancora lontane dalla commercializzazione

Molti mi chiedono: quando le ZK (prove a conoscenza zero) saranno davvero pronte per l’uso commerciale?

Ethereum è molto entusiasta delle ZK, e la loro roadmap ruota quasi interamente attorno a queste. In JAM, in realtà, usiamo un po’ di ZK solo in alcuni meccanismi di consenso speciali nella costruzione dei blocchi, ma nel complesso non ne dipendiamo. Tuttavia, è comunque una questione che va affrontata seriamente:

• Quando le ZK potranno essere una tecnologia realmente utilizzabile per espandere la capacità computazionale e commercialmente sostenibile?
• Siamo già arrivati a quel punto?
• Se no, quanto manca?

Se guardate le informazioni nell’ecosistema Ethereum (ad esempio ethprovers.com), vedrete numeri sorprendenti che affermano che le ZK sono già economicamente sostenibili. Ma abbiamo indagato e questi numeri non sono reali. La buona notizia è che, anche se non sono ancora del tutto fattibili, il divario rispetto a 18 mesi fa si è ridotto molto.

Per esempio: attualmente la macchina virtuale PVM di JAM (equivalente alla EVM di JAM) è circa il 34% più lenta nell’eseguire codice rispetto all’esecuzione nativa. In altre parole, se in ambiente nativo un programma impiega 34 minuti, su PVM ne servono circa 100.

Questo risultato è già piuttosto buono, siamo soddisfatti e c’è ancora margine di miglioramento.

Ovviamente, in alcuni casi il divario è maggiore, ad esempio 50% o più. Soprattutto per compiti come l’hash SHA-1, l’esecuzione su PVM è più lenta. Questo probabilmente perché in ambiente nativo il compilatore può usare istruzioni SIMD o altre ottimizzazioni, mentre PVM per ora non può.

Vediamo ora un altro dato chiave: questo riguarda il costo di generare una prova di esecuzione usando il miglior prover che abbiamo trovato, Succinct SP1, ovvero il sovraccosto rispetto all’esecuzione diretta su PVM. Attenzione, il confronto è con PVM, non con l’ambiente nativo. PVM è già circa il 34% più lento del nativo.

I risultati attuali dei test sono questi: abbiamo usato l’ultima versione del software e ipotizzato l’uso di una sola GPU (perché il codice pubblico supporta solo una GPU). Se fosse una versione commerciale closed source, forse si potrebbe scalare su cluster di GPU, ma in ambiente open source, si può solo così. Il test è sempre su SHA-1 hash, per garantire la coerenza del confronto.

Allora, dov’è il cambiamento?

18 mesi fa, abbiamo fatto esperimenti simili e i dati erano molto più alti, circa tra 60 milioni e 64 milioni. Ora il costo è molto più basso.

Le ragioni sono due:

• Da un lato, il prezzo del noleggio GPU è diminuito;
• Dall’altro, il software è stato enormemente ottimizzato, forse di un ordine di grandezza o più.

Va aggiunto che 18 mesi fa usavamo il prover RISC-0, non SP1. In ogni caso, il risultato dimostra che la tecnologia di frontiera sta progredendo rapidamente, e il progresso è notevole.

Fino a luglio 2025, generare una prova di una execution trace con SP1 (il prover di Succinct) costa 306.451 volte di più che eseguire in sicurezza lo stesso calcolo direttamente su PVM. Negli ultimi 18 mesi, il costo della prova è sceso di circa 200 volte, ma il valore resta molto alto. La tecnologia ZK sta davvero progredendo rapidamente, ma resta ancora molto più costosa dell’esecuzione diretta.

Ora parliamo della misurazione del Gas.

Far girare il codice velocemente è una cosa, ma la chiave è potersi fidare. E se qualcuno scrive apposta un codice che “rallenta” il sistema? Nei meccanismi di consenso, se il sistema deve raggiungere un accordo entro un tempo stabilito, ma il codice è progettato per essere lento, tutto il sistema può bloccarsi o andare in crash.

Su Polkadot, questo problema non è così grave, perché abbiamo le aste degli slot delle parachain. Cioè, chi può inserire codice nel sistema è noto, ha pagato per lo slot, quindi difficilmente farà danni che non convengono a nessuno.

Ma se allarghiamo lo scenario a un ambiente più aperto e generale, il problema diventa serio.

Qual è la soluzione?

Bisogna poter stimare in anticipo il tempo massimo di esecuzione di un codice, cioè quanto ci metterà nel peggiore dei casi. E assicurarsi che, comunque vada, il tempo di esecuzione non superi mai questa stima. Altrimenti, se qualcuno riesce a rallentare il codice 10 volte più del previsto, è un grosso problema.

Allora, a che punto siamo con la stima del caso peggiore?

Prendiamo SHA-1 hash come esempio: attualmente, per sicurezza, dobbiamo ipotizzare che possa essere 4,5 volte più lento del normale. Cioè, se normalmente un codice impiega 1 secondo, nella stima del caso peggiore lo consideriamo 4,5 secondi. Solo così possiamo essere sicuri che nessun attaccante possa rallentarlo di più.

Questo metodo di “moltiplicare per sicurezza” è proprio ciò che serve per garantire la sicurezza nei meccanismi di consenso con vincoli di tempo.

In futuro, questo fattore dovrebbe scendere, cioè la stima diventerà più precisa ed efficiente. Ora 4,5 volte è il miglior risultato ottenuto dopo una o due settimane di lavoro. Ottimisticamente, forse si potrà scendere a 3 volte, ma non molto di più.

33 ricalcoli vs prova matematica: il vero costo di due modelli di sicurezza

Su Polkadot e JAM, usiamo un protocollo chiamato elves per garantire la sicurezza del calcolo. Serve a determinare che un certo calcolo sia stato eseguito correttamente.

In sostanza, elves e le prove a conoscenza zero (ZK) sono simili:

• Le ZK usano una prova matematica, una “prova schiacciante”;
• Elves invece è più un gioco di cripto-economia: i partecipanti usano firme e regole per dimostrare che il risultato è corretto, assumendo che “i cattivi non superino un terzo”.

Quando si esegue elves, il calcolo viene ripetuto. I partecipanti decidono casualmente se rifare il calcolo.

Il risultato è che, in media, il lavoro viene rifatto circa 33 volte. Quindi il costo è circa 33 volte quello dell’esecuzione normale.

Così possiamo calcolare la differenza di costo tra ZK ed elves. La risposta è: ZK costa circa 4000 volte più di elves. In altre parole, usare le prove a conoscenza zero per verificare la correttezza è molto più costoso che usare elves, il sistema cripto-economico. Puoi pensarlo come un confronto tra diversi tipi di Rollup.

Nota PolkaWorld: puoi immaginare elves come 33 studenti in classe che copiano tutti i compiti e poi confrontano le risposte per essere sicuri che non ci siano errori; ZK invece è come chiedere a un dottore in matematica di scrivere una “prova assolutamente corretta”, ma il dottore ci mette giorni a scriverla.

Una differenza di 4000 volte è enorme: per rendere ZK conveniente nell’uso reale, il suo costo deve scendere drasticamente. Naturalmente, possiamo anche continuare a ottimizzare elves per renderlo più efficiente.

Tuttavia, il problema dei costi non riguarda solo l’hardware. Ci sono altri punti chiave:

• Costo di gestione (sysadmin): qualunque hardware tu usi, il costo del personale è simile. E spesso la gestione costa più dell’hardware.
• Costo dello staking: per garantire che i cattivi non superino un terzo, serve un meccanismo di filtro. Su Polkadot, questo avviene tramite “staking + penalità”. Cioè, i partecipanti devono mettere a rischio una parte dei loro fondi (capitale di rischio), così si distinguono i “buoni validatori” dai “cattivi”.

Il problema è che anche lo staking è costoso, è un costo extra (ne parlerò più avanti).

Al contrario, ZK non ha il peso dello staking. La logica di ZK è semplice: o la prova è corretta, o è sbagliata, si vede subito.

Ma il problema è che generare la prova ZK è troppo lento. Se usi una sola GPU, può servire qualche ora; mentre su PVM (o una normale CPU) lo stesso calcolo richiede solo millisecondi o secondi. Il divario è enorme.

Però, qualcuno ha già dimostrato che si può ridurre la latenza parallelizzando su cluster di GPU. Se hai abbastanza GPU collegate, puoi abbassare la latenza. Ma il problema è:

L’efficienza della parallelizzazione non è trasparente: cioè, non si sa quanto aumenterà il costo. Chi ha fatto esperimenti non ha pubblicato questi dati, forse non vuole. Quindi dobbiamo progettare esperimenti segreti, sviluppare codice da soli, o cercare ricerche non ancora scoperte.

Oltre a questo, ci sono i problemi di verifica e settlement.

Ad esempio, su Ethereum L1, la verifica costa addirittura più della generazione della prova. Abbiamo stimato che generare una prova costa circa 1–1,20 dollari, ma verificarla su Ethereum L1 costa 1,25 dollari. Ovviamente, se hai una tua chain, la verifica può costare molto meno, ma comunque servono:

• Verifica (verification)
• Settlement
• Finalità (finality)
• Storage

Questi passaggi non possono essere eliminati da ZK. Quindi, alla fine, devi comunque assicurarti che i partecipanti malintenzionati non superino un terzo, cioè serve comunque lo staking, proprio come su Ethereum L1, Polkadot e la maggior parte delle chain.

Quanto costa un nodo ZK-JAM? La risposta è dieci volte più cara di quanto pensi!

Ora cambiamo prospettiva: supponiamo di avere un nodo garante ZK-JAM (guarantor node), quanto costa farlo funzionare?

Spiego brevemente: in JAM, c’è un ruolo chiamato garante (guarantor), che fa da “guardiano” del sistema. Tutte le transazioni o i compiti passano prima da loro, che li elaborano e impacchettano i risultati, poi li passano agli altri validatori. I validatori possono ricontrollare i risultati, ma non è detto che lo facciano.

Ora ipotizziamo uno scenario:

• Eliminiamo il ricontrollo (nessun altro ricontrolla il lavoro del garante);
• Riduciamo i requisiti di staking (perché non ci affidiamo completamente alla reputazione del garante);
• Ma obblighiamo il garante a usare un cluster GPU per generare prove ZK.

Quanto costa tutto questo?

Secondo le stime: generare una prova ZK costa circa 1,18 dollari (per SHA-1, equivalente a 6 secondi di calcolo e 12MB di I/O). Questo corrisponde al lavoro che un JAM core può fare in uno slot. JAM ha in totale 341 core, e questo è il costo per un singolo core.

Ovviamente, questa è una stima approssimativa. Il costo può variare a seconda del compito: per altri calcoli può essere più alto o più basso, ma siamo su questo ordine di grandezza.

Se lo annualizziamo: il costo di un core per un anno è circa 9,5 milioni di dollari.

Qui si ipotizza che la parallelizzazione su cluster GPU comporti un sovraccosto del 50%, principalmente per ridurre la latenza. Ma questo 50% è solo una stima: nella realtà potrebbe essere solo il 5% o anche il 200%. Di sicuro ci sarà un sovraccosto, e potrebbe essere significativo.

Come si confronta questo con il meccanismo di staking attuale di Polkadot?

Nel meccanismo attuale, per offrire una sicurezza equivalente a elves (o circa l’80% della sicurezza di elves), il costo per core è meno di 1 milione di dollari.

Parlo di 80% perché: anche passando a ZK, serve comunque un po’ di staking per garantire la sicurezza di altre parti chiave, come:

• Funzionamento della chain principale
• Settlement
• Finalità
• Storage

Tutto questo è importante, ma la correttezza del calcolo è il cuore, e rappresenta circa l’80% del costo dello staking.

Supponiamo di gestire 341 core e mantenere l’attuale modello economico di staking di Polkadot, il costo è questo. Se il numero di core diminuisce, il costo per core aumenta, perché il “piatto” dello staking resta lo stesso, ma ci sono meno partecipanti a dividerlo.

Quindi, in sintesi: attualmente il costo di ZK è circa 10 volte quello di elves.

Ovviamente, se riuscissimo a ridurre il costo della sicurezza (e credo sia possibile), ad esempio da 9,16 milioni a 2,7 milioni, o addirittura, combinando nuovi meccanismi in sviluppo, a 1,44 milioni, allora la differenza di costo tra ZK ed elves si ridurrebbe. Ma attenzione, 1,44 milioni è già una stima ottimistica.

Qual è la conclusione finale?

Il costo di ZK sta effettivamente scendendo, ma anche così, ora è ancora 10–100 volte più caro di elves. Inoltre, ci sono costi extra incerti, come settlement, storage e finalità: JAM li supporta nativamente, o elves può sfruttarli, ma ZK no.

Inoltre, elves ha un vantaggio: può scalare in modo superlineare. Cioè, si possono collegare più reti JAM e condividere lo stesso set di validatori, aumentando l’efficienza complessiva. ZK non ha questa capacità: cresce solo linearmente—per ogni nuovo core, bisogna pagare di nuovo lo stesso costo, senza possibilità di fusione o riutilizzo.

Percorso evolutivo a breve, medio e lungo termine di ZK in JAM

Quindi, da un punto di vista strategico, quale strada seguire dipende dalla situazione specifica.

Credo che una strategia ragionevole sia:

• Ridurre il costo delle prove: serve ancora un calo di 1–2 ordini di grandezza. In base all’esperienza, potrebbero servire da 18 mesi a 5 anni.
• Servono strumenti open source: che permettano di generare prove in modo efficiente su cluster GPU. Attualmente non esistono strumenti maturi, o comunque non i migliori. Senza questi strumenti, le nostre stime di costo non reggono.
• Problema del prezzo dei core: se il prezzo di mercato dei core è già in una fascia che rende ragionevole il modello elves, ZK non ha più vantaggi.
• Scelta della sicurezza: il mercato deve poter distinguere tra due tipi di sicurezza: ZK offre “sicurezza perfetta”, elves offre “sicurezza sotto vincoli economici”. Il problema è: il mercato ci tiene davvero a quale usare? Non è chiaro.
• Eliminare la dipendenza dallo staking massiccio: dobbiamo poter svolgere le altre funzioni di JAM/elves (storage, settlement, finalità) senza dipendere dallo staking. Se serve ancora tanto staking, non c’è vantaggio, solo costi maggiori per ZK.

In base a questo, la strategia ZK che consiglio è:

• Iniziare dalle direzioni più facili: ad esempio sviluppare un framework di servizi ZK-JAM, ma continuando a usare il meccanismo cripto-economico di JAM (elves) per la sicurezza.
• Sfruttare i vantaggi di JAM: un core JAM ha grande potenza di calcolo (CPU) e buon I/O (12MB), e l’efficienza di esecuzione di PVM è alta. Questo significa che possiamo fare molta verifica ZK direttamente nel core JAM, senza dover ricorrere a processi di prova esterni costosi e complessi.
• Ottimizzare la fase di prova: di solito il processo di prova ZK ha diverse fasi, e alla fine c’è una “compressione della prova” per renderla più piccola e facile da verificare. Ma nel core JAM, grazie alla potenza di calcolo, forse non serve questa fase, risparmiando costi.
• Dare priorità alle prove di storage: perché il core JAM è molto potente nel calcolo, ma meno nell’I/O, e le prove di storage possono compensare questa debolezza, permettendo al sistema di gestire molte transazioni rapidamente.
• Altri compiti semplici: come la verifica delle firme, sono facili e non rappresentano un collo di bottiglia.

In altre parole, la vera difficoltà è garantire che i dati su cui si basano le transazioni siano corretti. Questo è il problema principale da risolvere.

A medio termine, la soluzione più ragionevole è:

Abbiamo già una nuova visione per Kusama: costruire una rete che supporti ZK. Quindi, usare questo budget e collaborare con altri team per investire nello sviluppo di strumenti efficienti e distribuiti per la generazione di prove è molto appropriato.

• Se nessun team lo sta facendo, avviamo un nuovo progetto;
• Se c’è già un team che lo fa, o è disposto a farlo, collaboriamo e li supportiamo per fare un buon lavoro.

Particolare attenzione va data alle prove di esecuzione PVM, perché sono la chiave per mantenere la compatibilità tra ZK-JAM e JAM normale in futuro, e la generazione distribuita delle prove è indispensabile.

L’obiettivo è mantenere il sistema modulare e aperto, così da restare al passo con la ricerca più avanzata. Solo tenendo il passo con il progresso tecnologico potremo abbassare ancora di diversi ordini di grandezza il costo delle prove, rendendole davvero commercialmente sostenibili.

A lungo termine, se vogliamo davvero che ZK diventi la soluzione principale, dobbiamo trovare un modo per sostituire lo staking. Perché finché c’è staking, i costi resteranno molto alti.

Come realizzare un JAM completamente basato su ZK?

Prima di tutto, questo ha senso solo se il costo di ZK scende abbastanza e se è certo che l’utilizzo dei core nel modello attuale non è economicamente sostenibile. Ora non è ancora certo, quindi è un’ipotesi condizionata.

Una volta soddisfatte le condizioni, possiamo far evolvere JAM in un modello di sicurezza multi-modale:

• Da un lato, offrire sicurezza economica ma limitata (tipo elves, a basso costo);
• Dall’altro, offrire sicurezza perfetta ma costosa (basata su ZK, con costo lineare crescente).

La questione chiave è: dobbiamo trovare un modo per ottenere finalità (finality) e storage senza dipendere dallo staking.

Una possibile direzione è la Proof of Personhood. Se riusciamo a integrare questo meccanismo nel protocollo core, potremo aumentare molto l’efficienza e l’utilizzo dei fondi.

Tuttavia, per farlo serve un meccanismo anti-sybil molto potente. Attualmente la maggior parte delle soluzioni non è abbastanza forte: o si basa su un’autorità centrale, o su un’organizzazione che raccoglie dati degli utenti per decidere chi è reale e chi no. Questo è chiaramente un problema di centralizzazione, e solo pochissime soluzioni sono quasi fattibili.