BB84, un rollup OP Stack attivo sulla mainnet di Ethereum con chain ID 42069000, ha rimosso completamente le firme delle transazioni dalla propria rete, sostituendole con catene hash in stile Lamport in un progetto pensato per attenuare la minaccia quantistica di lungo termine alla crittografia convenzionale. Il network è in funzione sulla mainnet dal 30 settembre. Il suo fondatore, che pubblica con lo pseudonimo Hadamard, ha descritto il sistema in un post del 24 ottobre su Ethereum Research chiedendo feedback critici.

Gli account Ethereum ordinari autorizzano le transazioni con firme ECDSA, che un computer quantistico sufficientemente potente che esegua l'algoritmo di Shor potrebbe violare. Oggi non esiste alcuna macchina in grado di farlo, ma gli avvertimenti sulle chiavi dei wallet esposte hanno spinto gli sviluppatori a cercare alternative — una chiave diventa pubblicamente visibile una volta che un account ha inviato una transazione. Le costruzioni basate su hash sono anche tra i più antichi candidati post-quantistici: Leslie Lamport propose uno schema di firma basato su hash nel 1979, e gli standard post-quantistici del NIST del 2024 includono uno schema basato su hash, SLH-DSA.

Account a catena hash, un passo alla volta

Ogni account BB84 è costruito a partire da un segreto che viene sottoposto ripetutamente ad hashing con keccak-256 — la stessa funzione hash usata da Ethereum stesso — creando una catena di valori in cui solo l'ultimo è pubblico. Per pagare, il wallet rivela il valore precedente alla posizione attuale, che chiunque può verificare con un singolo hashing. La rete registra quindi quel valore e sposta l'account di un passo lungo la catena.

Il valore predefinito del protocollo è 1.000 pagamenti per catena hash, mentre la CLI per sviluppatori di BB84 crea catene da 10 passi per ogni address monouso. Un passo viene consumato anche se il pagamento stesso fallisce, e la catena rigetta qualsiasi transazione firmata in modo convenzionale.

I pagamenti avvengono solo in USDC ed EURC pontati. Sia le transazioni di commit che quelle di reveal sono gratuite per gli utenti, e chi paga crea un nuovo address monouso per ogni destinatario.

Il compromesso di sicurezza

Il post espone i limiti del progetto. All'interno della rete, tutto si basa sulla difficoltà di invertire keccak-256, e l'algoritmo di ricerca quantistica di Grover ridurrebbe tale difficoltà solo a circa 2^128 operazioni. Gli address, tuttavia, sono accorciati a 160 bit, il che lascia circa 2^80 di resistenza quantistica sull'address stesso.La documentazione di BB84]() pubblicizza una sicurezza post-quantistica a 128 bit senza questa avvertenza. Anche la mainnet di Ethereum è ancora basata su ECDSA: i depositi partono da wallet Ethereum ordinari, e i prelievi vi vengono pagati.

Una vulnerabilità di front-running scoperta durante la stesura del post

Rivelare un segreto lo rende pubblico, quindi chiunque stia osservando potrebbe copiarlo in una transazione a proprio favore. Per prevenirlo, il wallet invia prima una transazione di commit che blocca il segreto a un pagamento esatto senza mostrarlo. Il reveal deve seguire entro cinque blocchi per impostazione predefinita.

Il punto debole era che i commit non portano alcuna firma, perché non c'è nulla con cui firmare. Nella prima versione, un nuovo commit semplicemente sostituiva quello in sospeso. Un attacker che individuava un segreto in un reveal in sospeso poteva inserire un commit che legava quel segreto a un pagamento a proprio favore. Hadamard afferma che il team ha scoperto la vulnerabilità durante la stesura del post e l'ha corretta con una nuova regola entrata in vigore il 21 ottobre. Secondo la regola rivista, vince il primo commit, lo slot si libera solo dopo il reveal corrispondente o la scadenza, il wallet attende che il proprio commit venga incluso in un blocco prima di effettuare il reveal, e l'RPC pubblico non espone le transazioni in sospeso.

Ciò che la correzione lascia scoperto

Il griefing rimane possibile: chiunque può inviare un commit inutile e bloccare un address fino a cinque blocchi, pur non potendone spostare i fondi. Un sequencer malintenzionato è un altro rischio residuo: se un commit onesto scade o viene riorganizzato fuori mentre il suo reveal è in sospeso, il segreto non è più bloccato. Oggi solo il sequencer di BB84 stesso vede le transazioni in sospeso.

Hadamard suggerisce una regola più rigorosa in stile "Guy Fawkes", in cui i commit vengono aggiunti invece che sostituiti, ma dice che non è stata realizzata. La documentazione va oltre il post, affermando che commit e reveal implicano che un sequencer non possa sottrarre un prelievo.

Un wallet che non deve perdere il conteggio

Poiché ogni catena ha un numero fisso di passi, il wallet deve rinnovarla proprio sull'ultimo, includendo un nuovo impegno nel pagamento finale. Se salta quel passo, l'address è morto. Mantenere il conteggio è altrettanto importante: Hadamard afferma che l'app e la catena sono andate fuori sincronizzazione in produzione, quindi i wallet devono poter risincronizzarsi dai dati della catena.

I segreti devono comunque essere protetti come chiavi. La CLI avverte che il suo file wallet memorizza le chiavi di spesa senza crittografia e indica la crittografia come elemento della roadmap. Rimuovere le firme cambia il modo in cui la spesa viene autorizzata, non la necessità di mantenere i segreti al sicuro.

I prelievi si basano su un operatore fidato

BB84 non ha fault proof. Un proposer permissionato pubblica lo stato della rete su Ethereum attraverso un dispute game personalizzato che si risolve immediatamente, e in assenza di un sistema di prova, Hadamard scrive che secondo il framework di L2BEAT la catena "non sarebbe nemmeno Stage 0." Il framework classifica i rollup dallo Stage 0 allo Stage 2 in base a quanto gli utenti debbono fidarsi di un operatore anziché di un sistema di prova. I prelievi si affidano quindi al proposer. La documentazione descrive ancora i prelievi come seguenti il flusso di fault proof dell'OP Stack con un ritardo di maturità di sette giorni, ma come spiegato nell'explainer di Optimism, le fault proof esistono perché lo stato errato possa essere contestato — e qui nulla può essere contestato durante quell'attesa. Anche il sequencer è gestito da BB84.

Cosa cambierebbe il quadro

Il post si chiude con domande che vanno oltre una singola catena. La più grande è se gli account a catena hash potrebbero diventare una modalità di validazione in stile EIP-7702 o nativa dell'account abstraction sulle reti layer-2 di uso generale, il che renderebbe l'idea disponibile senza dover migrare a una catena dedicata. L'EIP-7702, attivo dall'aggiornamento Pectra di Ethereum di maggio 2025, consente agli account ordinari di adottare codice smart contract. Hadamard aggiunge che i controlli aggiuntivi sono abbastanza semplici da poter essere dimostrati con l'esistente tooling Cannon di Optimism, che una regola di commit append-only chiuderebbe sia le lacune di griefing che quelle del sequencer, e che una trattazione più completa con le regole integrale è in preparazione per arXiv. Il più ampio percorso di migrazione di Ethereum, descritto nella sua roadmap quantistica, copre anche le firme dei validator, gli impegni dei dati e i sistemi di prova.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza finanziaria o di investimento. Le reti sperimentali comportano rischi tecnici e di custodia.

Fonte: Coindoo