Catching the Fly: Practical Challenges in Making Blockchain FlyClient Real

1. Enunciato del Problema

FlyClient è un protocollo teorico progettato per abilitare la verifica ultra-leggera delle blockchain Proof-of-Work (PoW). Consente ai client (ad esempio, portafogli mobili, dispositivi IoT, contratti intelligenti) di verificare la validità di una blockchain con complessità dei dati logaritmica ($O(\log n)$) invece che lineare, utilizzando il campionamento probabilistico delle intestazioni dei blocchi e gli impegni della Gamma di Montagne di Merkle (MMR).

Nonostante la sua promessa teorica, FlyClient affronta barriere significative per il dispiegamento nel mondo reale:

• Mancanza di Implementazioni di Produzione: Non esistevano implementazioni di prover per le principali blockchain di produzione (in particolare Zcash, che supporta nativamente FlyClient tramite un hard fork).
• Modelli di Avversario Astratti: Il modello di sicurezza originale si basa su un avversario $(c, L)$ (un attaccante che non può produrre una forcella di lunghezza $L$ con un rapporto di validità $c$). Questo modello è matematicamente comodo ma manca di un'interpretazione economica diretta, rendendo difficile per i praticanti configurare i verificatori in base ai budget di attacco reali.
• Inefficienza delle Dimensioni delle Prove: Le dimensioni attuali delle prove sono dominate da grandi componenti dell'intestazione del blocco (in particolare le soluzioni Equihash in Zcash), rendendo la verifica on-chain (ad esempio, nei bridge cross-chain) proibitivamente costosa in termini di costi del gas.
• Divari nelle Prestazioni: Mancavano dati empirici riguardanti l'overhead delle risorse necessario per eseguire un prover FlyClient e i reali requisiti di banda/archiviazione in diverse condizioni di rete.

2. Metodologia

Gli autori hanno colmato il divario tra teoria e pratica attraverso tre pilastri metodologici principali:

A. Raffinamento Teorico: Il Modello dell'Avversario $w_a$

• Gli autori hanno introdotto il modello dell'avversario $w_a$, che sostituisce i parametri astratti $(c, L)$ con un singolo parametro concreto: il budget di lavoro avversario ($w_a$).
• Questo modello definisce la capacità di un attaccante in base al lavoro cumulativo massimo che può produrre dato un budget monetario specifico (ad esempio, costo dell'elettricità e dell'hardware).
• Hanno derivato una procedura di ottimizzazione matematica per mappare questo budget economico ai parametri ottimali del protocollo ($n_{det}$ e $n_{prob}$), minimizzando il numero di intestazioni campionate mantenendo al contempo un livello di sicurezza target ($\lambda$).

B. Implementazione: Prover FlyClient per Zcash

• Il team ha esteso Zebrad, l'implementazione ufficiale del full node in Rust di Zcash, per funzionare come prover FlyClient.
• Hanno implementato specifiche funzioni di chiamata a procedura remota (RPC) per servire intestazioni di blocchi, nodi MMR e dati sul lavoro totale.
• Hanno condotto benchmark delle prestazioni per misurare l'impatto del mantenimento di un database di nodi MMR sui tempi di sincronizzazione del nodo e sui requisiti di archiviazione.

C. Strategie di Ottimizzazione

Gli autori hanno proposto e valutato due ottimizzazioni distinte per ridurre le dimensioni delle prove:

1. Prove Cumulative: Un'ottimizzazione a livello software in cui il verificatore scarica una singola prova MMR che copre tutti i blocchi campionati simultaneamente, invece di prove individuali per ogni blocco. Questo elimina il download ridondante di nodi senza richiedere cambiamenti al consenso.
2. Prove Distillate: Un'ottimizzazione a livello di consenso che richiede un hard fork. Questa prevede:
   • Sostituire l'algoritmo memory-hard Equihash (che richiede di memorizzare soluzioni di 1344 byte nelle intestazioni) con un PoW più efficiente in termini di spazio (ad esempio, Ethash/RandomX) o una variante con soluzioni piccole.
   • "Distillare" le intestazioni dei blocchi per includere solo i campi necessari per la verifica FlyClient (rimuovendo i dati delle transazioni e le radici non necessarie).
   • "Distillare" i nodi MMR per memorizzare solo i campi essenziali e gli hash del resto.

3. Contributi Chiave

1. Modello di Avversario Economico: L'introduzione del modello dell'avversario $w_a$ consente una configurazione intuitiva, basata sul budget, dei verificatori FlyClient. È stato dimostrato che questo modello soddisfa le garanzie di sicurezza del modello originale $(c, L)$ offrendo al contempo riduzioni delle dimensioni delle prove fino al 37% attraverso la selezione ottimizzata dei parametri.
2. Primo Prover di Livello Produttivo: Il documento presenta la prima implementazione funzionante di un prover FlyClient per Zcash (integrata in Zebrad). Dimostra che l'aggiunta della funzionalità FlyClient ha un impatto trascurabile sui tempi di sincronizzazione (l'aggiornamento del database richiede circa 10 ore per una catena di 3 milioni di blocchi, mentre la sincronizzazione completa richiede circa 40 ore).
3. Ottimizzazioni delle Dimensioni delle Prove:
   • Prove Cumulative: Hanno ottenuto una riduzione del 9,16% nelle dimensioni delle prove non interattive con zero cambiamenti al consenso.
   • Prove Distillate: Hanno ottenuto una massiccia riduzione del 71,33% nelle dimensioni delle prove non interattive, riducendo la dimensione da circa 1,2 MiB a circa 320 KiB per una catena di 3 milioni di blocchi.

4. Risultati Sperimentali

• Dimensioni delle Prove e Costi:
  • Baseline: Una prova FlyClient non interattiva standard per una catena Zcash di 3 milioni di blocchi è di circa 1,2 MiB. Passare questa prova a un contratto intelligente (tramite EIP-7623) costa circa 13,21 USD.
  • Ottimizzazione Cumulativa: Riduce il costo a 12,00 USD (-9,16%).
  • Ottimizzazione Distillata: Riduce il costo a 3,44 USD (-71,33%), rendendo i bridge cross-chain trustless economicamente fattibili per transazioni più frequenti.
• Overhead delle Risorse:
  • L'implementazione del prover FlyClient non degrada significativamente le prestazioni del nodo. Il tempo per aggiornare il database di un nodo esistente per memorizzare i nodi MMR è lineare e gestibile.
  • È stato scoperto che la rappresentazione "binario compresso" (zipped binary) è la più efficiente per la trasmissione dei dati, riducendo le dimensioni delle prove in modo significativo rispetto ai formati JSON o binari grezzi.
• Analisi di Sicurezza: Il modello dell'avversario $w_a$ ha confermato che un attaccante con un budget di circa 20.000 USD (sufficiente per produrre circa 50 blocchi di lavoro) non può attaccare con successo un verificatore configurato con i parametri ottimizzati, anche se l'attaccante tenta di creare una forcella con un rapporto di validità inferiore.

5. Significato

Questo documento è un passo critico verso l'industrializzazione di FlyClient.

• Bridge Trustless: Riducendo drasticamente il costo del gas per la verifica di blockchain estere sui contratti intelligenti, l'ottimizzazione delle prove distillate rende economicamente fattibili i bridge cross-chain trustless (senza parti terze federate o fidate).
• Fattibilità per IoT e Mobile: I risultati confermano che i client leggeri possono verificare blockchain massive con una minima larghezza di banda e archiviazione, abilitando transazioni sicura macchina-a-macchina in ambienti con risorse limitate.
• Sicurezza Pratica: Il passaggio da modelli matematici astratti a modelli di budget economici fornisce un quadro più realistico per la sicurezza dei sistemi blockchain nel mondo reale.
• Roadmap Futura: Gli autori suggeriscono che combinare FlyClient con SNARKs (Argomenti Succinti Non Interattivi della Conoscenza) potrebbe comprimere ulteriormente le prove, sebbene ciò rimanga un lavoro futuro.

In conclusione, il documento dimostra che FlyClient non è più solo un concetto teorico, ma una soluzione deployabile, sicura e ottimizzata per l'infrastruttura blockchain di prossima generazione.