Nel dibattito sulla sicurezza crittografica, una soluzione potrebbe essere un wallet post-quantum progettato su Ethereum sfruttando account abstraction e chiavi ECDSA effimere, senza modificare il protocollo.
Summary
Il rischio quantistico per Ethereum ed ECDSA
La minaccia dei computer quantistici per la crittografia a curva ellittica non è più teorica. Shor ha descritto un algoritmo che risolve in modo efficiente il problema del logaritmo discreto e quindi compromette ECDSA.
Un calcolatore quantistico crittograficamente rilevante non esiste ancora, ma le previsioni indicano orizzonti temporali sempre più brevi. Per questo la Ethereum Foundation ha avviato linee di ricerca dedicate alle firme post-quantum e definito una roadmap specifica.
Su Ethereum, un EOA che non ha mai effettuato transazioni è di fatto resistente agli attacchi quantistici, perché la sua chiave pubblica resta nascosta dietro un hash. Tuttavia, al primo invio di una transazione, la chiave pubblica viene esposta onchain e quell’indirizzo diventa permanentemente vulnerabile a un futuro attacco.
Limiti delle firme post-quantum onchain
Sono in corso diversi sforzi per portare direttamente in EVM schemi di firma post-quantum come Falcon e Poqeth. Queste soluzioni sono cruciali nel lungo termine, ma oggi hanno costi di verifica molto elevati.
Su Ethereum, la verifica onchain di Falcon richiede oltre 1.000.000 gas, mentre le firme basate su hash si collocano intorno a 200.000 gas. In prospettiva, EIP-8051 ed EIP-8052 potrebbero ridurre tali costi una volta integrati nell’EVM.
Inoltre, i problemi non si esauriscono nel gas. Standardizzazione, compatibilità con gli hardware wallet e robustezza contro attacchi classici sono ostacoli importanti che un nuovo standard di firma per ETH deve superare. Anche con uno schema pronto, la sostituzione completa di ECDSA richiederebbe modifiche a livello di protocollo.
Detto ciò, esiste un approccio complementare: invece di sostituire ECDSA, renderla effimera, così che nessuna chiave resti esposta a lungo termine.
Design: chiavi effimere con account abstraction
La proposta sfrutta Account Abstraction per mantenere un’identità onchain stabile, rappresentata da uno smart account, cambiando però il firmatario dopo ogni transazione. L’indirizzo del portafoglio resta costante, il signer no.
In questo modo un eventuale computer quantistico potrebbe ancora ricavare la chiave privata usata, ma quella chiave sarebbe già inutilizzabile per firmare operazioni future. L’esposizione si limita a una singola transazione.
Lo schema operativo è lineare: l’utente aggiunge un nuovo indirizzo nella calldata della sua userOp; lo smart contract wallet valida la transazione; la userOp viene eseguita; infine il firmatario autorizzato sullo smart contract wallet viene aggiornato al nuovo indirizzo.
Una volta conclusa l’operazione, la vecchia chiave privata, anche se recuperata, è priva di valore pratico. Onchain è comunicato solo l’indirizzo, quindi solo una parte dell’hash della chiave pubblica è visibile. La nuova chiave rimane quindi resistente a un attacco quantistico fino alla transazione successiva.
Generazione degli indirizzi e flusso utente
Per semplificare l’esperienza, l’utente non deve scegliere indirizzi casuali a ogni operazione. Inoltre, può generare in anticipo una sequenza di indirizzi seguendo un percorso di derivazione BIP44, già supportato da molti wallet esistenti.
In questo scenario, la sicurezza dipende dalla rotazione costante del signer e non dalla complessità dell’interfaccia. L’utente continua a interagire con lo stesso indirizzo di smart contract, mentre il software gestisce la catena di chiavi effimere in background.
Implementazione pratica su Smart Contract Wallet
Per concretizzare questo wallet post-quantum bastano piccole modifiche a un contratto di base tipo SimpleWallet. Servono solo due funzioni aggiuntive: estrarre il prossimo caller dalla calldata e aggiornare l’owner dello smart contract wallet.
Una proof of concept è già stata realizzata. Inoltre, l’implementazione affronta un problema cruciale: la rotazione del signer deve avvenire anche se la userOp va in revert, altrimenti una transazione fallita lascerebbe l’attuale chiave ancora esposta.
In questo modello, se la userOp fallisce, il contratto emette un evento che segnala l’errore, ma completa comunque il cambio di firmatario. In questo modo l’indirizzo esposto non rimane attivo e non può essere riutilizzato.
Costi in gas e confronto con firme post-quantum
Le misurazioni mostrano che un trasferimento ERC20 con questa architettura consuma circa 136.000 gas. Si tratta di un overhead inferiore a 100.000 gas rispetto allo stesso trasferimento del token sulla stessa chain, senza rotazione delle chiavi.
Questo sovraccarico è già molto più basso dei costi attuali di verifica delle firme post-quantum onchain. Inoltre, porta con sé i vantaggi aggiuntivi dell’account abstraction, come la possibilità di sponsorizzare gas o introdurre policy avanzate.
Se la rotazione del signer viene integrata in un wallet basato su account abstraction già esistente, il costo extra specifico per il cambio di chiave è ancora più ridotto e quasi trascurabile nel quadro generale di una transazione complessa.
Uso della social recovery per la rotazione delle chiavi
Un’alternativa consiste nello sfruttare le funzioni di social recovery già presenti in molti smart contract wallet. In assenza di limitazioni specifiche, il recovery guardian può essere impostato sull’indirizzo dell’utente stesso.
Dopo ogni transazione si può avviare una procedura di recupero identità che, di fatto, aggiorna il firmatario. Questa scelta comporta un costo in gas leggermente superiore, perché riutilizza un meccanismo progettato per altro scopo, ma evita di distribuire nuove architetture onchain.
Gli esperimenti indicano un overhead di circa 30.000 gas per questa operazione. L’intera architettura usata, senza recovery, mostrava invece un sovraccarico intorno a 110.000 gas, confermando che la riproposizione della social recovery è relativamente efficiente.
La finestra di rischio nel mempool
Il principale punto debole riconosciuto riguarda il periodo di attesa nel mempool. In questa fase la chiave pubblica del firmatario è visibile e un avversario dotato di capacità quantistiche potrebbe, in teoria, ricavare la chiave privata e frontrunnare la transazione.
Al momento, tuttavia, l’attacco appare poco realistico. Il tempo estremamente limitato a disposizione dell’aggressore rende l’exploit molto difficile, se non impossibile, con le tecnologie quantistiche ipotizzate nel breve periodo.
Se si desidera eliminare completamente questa finestra di rischio, l’uso di mempool privati è la soluzione più immediata. Inoltre, nel contesto delle Layer 2 la vulnerabilità si riduce ulteriormente grazie ai tempi di conferma più brevi.
Prospettive della sicurezza quantistica su Ethereum
Nel complesso, questo schema offre una mitigazione pratica della minaccia quantistica sul livello di esecuzione, ruotando le coppie di chiavi ECDSA a ogni transazione e mantenendo un’identità onchain stabile tramite account abstraction.
Il modello non richiede modifiche al protocollo di Ethereum e introduce un overhead di gas limitato, nell’ordine di ~100.000 unità rispetto a un trasferimento standard. Rappresenta quindi una soluzione immediatamente adottabile con l’infrastruttura attuale.
Questa architettura non sostituisce le firme post-quantum, che restano indispensabili per una protezione completa nel lungo termine. Tuttavia, riduce drasticamente l’esposizione prolungata delle chiavi pubbliche e fornisce un percorso concreto per portafogli più robusti contro i futuri computer quantistici.
