L'ultima ricerca di Vocdoni sui processi di voto off-chain sicuri.
Ferran
· 11 min di lettura
Questo articolo propone una proof of concept che sfrutta gli zk-SNARKs per raggiungere la prossima frontiera della governance: una governance on-chain senza gas, verificata e vincolante.
Il contenuto tecnico di questa proposta è stato pubblicato anche sul forum Ethresear.ch, qui, per la discussione con la community.
Come progetto di riferimento nella governance digitale, Vocdoni investe molto nella ricerca e nell'innovazione dei modelli di governance. Abbiamo individuato diverse soluzioni di governance layer 2 promettenti, che però lasciano aperte varie questioni tecniche. Siamo riusciti a realizzare processi di voto senza gas sulla nostra blockchain di voto specializzata, Vochain, e a progettare e implementare un metodo che usa le Storage Proof di Ethereum per portare su Vochain censi basati su token ERC20 provenienti da Ethereum. Finora, però, la possibilità di riportare i risultati su Ethereum era rimasta una questione di ricerca aperta.
A questo scopo, Vocdoni ha condotto esperimenti su un nuovo design che permetterebbe di trasferire su Ethereum i risultati di un processo di voto off-chain, senza ricorrere a oracoli soggettivi né ad altri componenti fidati.
L'innovazione centrale di questa proposta è chiara: nessun sistema a noi noto è in grado di organizzare un processo di voto off-chain ed eseguire in modo trustless azioni su Ethereum in base ai suoi risultati. I casi d'uso includono potenzialmente tutti i processi di governance che eseguono azioni vincolanti in base ai risultati, come (ma non solo) le votazioni delle DAO sull'allocazione di asset o sulle modifiche agli smart contract. Oggi questi processi di governance devono svolgersi sulla mainnet di Ethereum, con costi di gas considerevoli per ogni elettore. In alternativa, il voto può avvenire off-chain, ma affidandosi a un componente esterno perché riporti i risultati su Ethereum in modo accurato e onesto.
La nostra proposta permetterebbe a processi di voto interamente off-chain di eseguire i risultati su Ethereum con la stessa integrità della governance on-chain, a una frazione del costo.
Prima di elaborare una soluzione tecnica, abbiamo definito i parametri della nostra proposta di ricerca.
I requisiti per il protocollo di voto erano i seguenti:
Trattandosi di un design proof of concept, abbiamo accettato le seguenti limitazioni:
Secondo il design di questa proposta, alla creazione di un nuovo processo di voto gli organizzatori inviano una transazione a Ethereum specificando l'indirizzo del contratto di un token ERC20 da usare come censo degli elettori. Lo Storage Root Hash di questo indirizzo, a una determinata altezza di blocco, diventa la radice del censo per il processo. Chiunque possieda il token può dimostrare la propria idoneità fornendo una prova di Merkle (tramite EIP1186) del proprio saldo. Può quindi esprimere il voto inviando la prova (siblings) e una firma a un relayer di rollup zk-SNARK, che calcolerà una prova dei risultati finali.
Un potenziale problema è che l'attore che calcola la prova zk-SNARK dei risultati (il coordinatore) potrebbe, in teoria, censurare il risultato decidendo di escludere dei voti. Affrontiamo questo problema consentendo a chiunque (non solo al coordinatore) di inviare nuovi voti: qualsiasi utente può generare e inviare un rollup contenente il proprio voto se rileva che un coordinatore non lo ha incluso.
La nostra proposta usa gli zk-SNARKs per i seguenti scopi:
Esecuzione vincolante su Ethereum con zkSNARKs: proposta idealizzata.
Nello schema qui sopra si possono individuare due problemi principali:
Le Storage Proof ERC20 sono molto complesse da verificare all'interno di uno SNARK. Ciò è dovuto in parte all'uso del parsing Recursive Length Prefix (RLP) e a molteplici verifiche di hash Keccak-256, entrambi inefficienti da calcolare con l'attuale stato dell'arte della tecnologia dei rollup SNARK. È un problema difficile da aggirare, quindi per il momento lo risolviamo con una validazione ottimistica.
Uno standard crittografico attuale che potremmo usare per verificare le firme degli utenti è ECDSA con una chiave BabyJubJub derivata da una firma Ethereum, usando la firma come chiave privata grezza, il che consente all'utente di recuperare il proprio indirizzo. Poiché questo metodo si basa su una firma dell'utente, è vulnerabile ad agenti malevoli che inducono gli utenti a firmare transazioni fraudolente nel loro wallet Web3. Questa vulnerabilità esiste ovunque si usi un wallet nel browser per firmare una transazione. Una possibile soluzione potrebbe essere derivare una chiave privata usando l'indirizzo web come percorso di derivazione.
Un'ulteriore sfida consiste nel dimostrare che l'indirizzo Ethereum di ciascun possessore di token approva la chiave BabyJubJub per il voto all'altezza di blocco della creazione del processo. Lo otteniamo con uno smart contract «singleton» che mappa gli indirizzi Ethereum sulle chiavi pubbliche BabyJubJub: l'utente deve aggiungere la propria chiave allo smart contract tramite una transazione standard. La mappatura tra un indirizzo e una chiave può essere contestata tramite una fraud proof ottimistica sullo storage (dato che abbiamo già aperto la porta alla validazione ottimistica delle Storage Proof). Questa soluzione risolve anche il problema della disponibilità dei dati con un design riutilizzabile, poiché è previsto che queste chiavi autorizzate vengano usate più volte in processi di voto diversi.
In sintesi, possiamo gestire la maggior parte delle verifiche all'interno di uno SNARK, ma non tutte:
Esecuzione vincolante su Ethereum con zkSNARKs: proposta
Uno zk-SNARK aggregherà una lista di voti espressi. La prova zk-SNARK è valida rispetto a una data lista di voti, una radice del censo, un identificatore dell'elezione (electionId) e un risultato aggregato.
Il circuito e il contratto
INPUT DELLO zk-SNARK
Gli input della chiamata alla funzione dello smart contract per il caricamento dei risultati del coordinatore sono:
Abbiamo implementato gli smart contract e i circuiti minimi necessari per verificare costi e fattibilità della soluzione, disponibili qui. Questa PoC include solo il registro degli utenti, l'aggregazione dei voti e la verifica delle fraud proof.
I nostri test hanno registrato i seguenti costi in gas:
user key registry
deployment 258,536
registration 68,956
voting
deployment 6,673,159
new voting 25,989
aggregate rollup 291,801
fraud proof-1 574,574 (babyjubjub key not registered)
fraud proof-2 908,822 (account ERC20 balance is zero)
Nelle misurazioni per stimare un numero fattibile di voti da aggregare, con un server standard con 32 GB di RAM / 8 CPU abbiamo riscontrato che è possibile aggregare fino a 300 voti (con un accumulatore ad albero di Merkle a 64 livelli e ~3,8 milioni di constraint), impiegando 450 secondi per creare la prova e consumando 30 GB di RAM. Per le prove abbiamo usato Groth16 con Circom, generazione del witness in C++ e rapidSNARK.
Sul fronte positivo, la prova da calcolare per generare una fraud proof è abbastanza piccola (50k) da poter essere generata in un browser. Questo permette agli utenti di contestare un lotto di voti senza scaricare alcun software specializzato.
Partendo da questa ricerca, vorremmo approfondire le seguenti idee:
Vocdoni ha sviluppato un nuovo protocollo DKG non interattivo per progettazione, operativamente asincrono nella pratica e costruito a partire da primitive crittografiche standard.
Jordi Pinyana
6 min di lettura
Negli ultimi anni Vocdoni ha gestito le votazioni su Vochain, la nostra blockchain L1 progettata specificamente per il voto. Come ogni blockchain, ci ha dato qualcosa di potente:…
Pau Escrich
4 min di lettura
Abbiamo raccolto con successo un round pre-seed da 1 milione di dollari da investitori angel per sviluppare DAVINCI. DAVINCI supera i limiti dei sistemi di voto esistenti, offrendo una soluzione resistente alla censura, gasless, anti-corruzione, scalabile e anonima per la governance digitale.
Pau Escrich
6 min di lettura