Disponibilità dei dati

"Non fidarti, verifica" è una massima comune in Ethereum. L'idea è che il tuo nodo possa verificare in modo indipendente che le informazioni che riceve siano corrette eseguendo tutte le transazioni nei blocchi che riceve dai peer per assicurarsi che le modifiche proposte corrispondano esattamente a quelle calcolate in modo indipendente dal nodo. Ciò significa che i nodi non devono fidarsi che i mittenti del blocco siano onesti. Questo non è possibile se mancano dei dati.

La disponibilità dei dati si riferisce alla sicurezza che un utente può avere che i dati richiesti per verificare un blocco siano realmente disponibili per tutti i partecipanti alla rete. Per i nodi completi sul layer 1 (l1) di Ethereum questo è relativamente semplice; il nodo completo scarica una copia di tutti i dati in ogni blocco: i dati devono essere disponibili affinché il download sia possibile. Un blocco con dati mancanti verrebbe scartato anziché essere aggiunto alla blockchain. Questa è la "disponibilità dei dati onchain" ed è una caratteristica delle blockchain monolitiche. I nodi completi non possono essere ingannati per accettare transazioni non valide perché scaricano ed eseguono ogni transazione da soli. Tuttavia, per le blockchain modulari, i rollup di layer 2 (l2) e i client leggeri, il panorama della disponibilità dei dati è più complesso e richiede procedure di verifica più sofisticate.

Prerequisiti

Dovresti avere una buona comprensione dei fondamenti della blockchain, specialmente dei meccanismi di consenso. Questa pagina presuppone inoltre che il lettore abbia familiarità con i blocchi, le transazioni, i nodi, le soluzioni di ridimensionamento e altri argomenti pertinenti.

Il problema della disponibilità dei dati

Il problema della disponibilità dei dati è la necessità di dimostrare all'intera rete che la forma riassunta di alcuni dati di transazione che vengono aggiunti alla blockchain rappresenta realmente un insieme di transazioni valide, ma facendolo senza richiedere a tutti i nodi di scaricare tutti i dati. I dati completi della transazione sono necessari per verificare i blocchi in modo indipendente, ma richiedere a tutti i nodi di scaricare tutti i dati della transazione è un ostacolo alla scalabilità. Le soluzioni al problema della disponibilità dei dati mirano a fornire garanzie sufficienti che i dati completi della transazione siano stati resi disponibili per la verifica ai partecipanti alla rete che non scaricano e archiviano i dati per se stessi.

I nodi leggeri e i rollup di layer 2 (l2) sono esempi importanti di partecipanti alla rete che richiedono forti garanzie di disponibilità dei dati ma non possono scaricare ed elaborare i dati delle transazioni da soli. Evitare di scaricare i dati delle transazioni è ciò che rende leggeri i nodi leggeri e consente ai rollup di essere soluzioni di ridimensionamento efficaci.

La disponibilità dei dati è anche una preoccupazione fondamentale per i futuri client Ethereum "senza stato" che non hanno bisogno di scaricare e archiviare i dati di stato per verificare i blocchi. I client senza stato devono comunque avere la certezza che i dati siano disponibili da qualche parte e che siano stati elaborati correttamente.

Soluzioni per la disponibilità dei dati

Campionamento della disponibilità dei dati (DAS)

Il campionamento della disponibilità dei dati (DAS) è un modo per la rete di verificare che i dati siano disponibili senza mettere troppo sotto sforzo alcun singolo nodo. Ogni nodo (inclusi i nodi non in staking) scarica un piccolo sottoinsieme selezionato casualmente dei dati totali. Il download corretto dei campioni conferma con elevata sicurezza che tutti i dati sono disponibili. Questo si basa sulla codifica a cancellazione dei dati, che espande un determinato set di dati con informazioni ridondanti (il modo in cui viene fatto è adattare una funzione nota come polinomio sui dati e valutare quel polinomio in punti aggiuntivi). Ciò consente di recuperare i dati originali dai dati ridondanti quando necessario. Una conseguenza di questa creazione di dati è che se qualsiasi dei dati originali non è disponibile, mancherà metà dei dati espansi! La quantità di campioni di dati scaricati da ciascun nodo può essere regolata in modo che sia estremamente probabile che manchi almeno uno dei frammenti di dati campionati da ciascun client se meno della metà dei dati è realmente disponibile.

Il DAS verrà utilizzato per garantire che gli operatori dei rollup rendano disponibili i dati delle loro transazioni dopo l'implementazione del danksharding completo. I nodi Ethereum campioneranno casualmente i dati delle transazioni forniti nei blob utilizzando lo schema di ridondanza spiegato sopra per garantire che tutti i dati esistano. La stessa tecnica potrebbe anche essere impiegata per garantire che i produttori di blocchi rendano disponibili tutti i loro dati per proteggere i client leggeri. Allo stesso modo, con la separazione proponente-costruttore (PBS), solo il costruttore di blocchi sarebbe tenuto a elaborare un intero blocco: gli altri validatori verificherebbero utilizzando il campionamento della disponibilità dei dati.

Comitati per la disponibilità dei dati

I comitati per la disponibilità dei dati (DAC) sono parti fidate che forniscono o attestano la disponibilità dei dati. I DAC possono essere utilizzati al posto di, o in combinazione con (opens in a new tab) il DAS. Le garanzie di sicurezza che derivano dai comitati dipendono dalla configurazione specifica. Ethereum utilizza sottoinsiemi di validatori campionati casualmente per attestare la disponibilità dei dati per i nodi leggeri, ad esempio.

I DAC sono utilizzati anche da alcuni validium. Il DAC è un insieme fidato di nodi che archivia copie di dati offline. Al DAC è richiesto di rendere disponibili i dati in caso di controversia. I membri del DAC pubblicano anche attestazioni onchain per dimostrare che i suddetti dati sono effettivamente disponibili. Alcuni validium sostituiscono i DAC con un sistema di validatori Proof-of-Stake (PoS). Qui, chiunque può diventare un validatore e archiviare dati offchain. Tuttavia, devono fornire una "cauzione", che viene depositata in uno smart contract. In caso di comportamento dannoso, come il validatore che trattiene i dati, la cauzione può subire lo slashing. I comitati per la disponibilità dei dati Proof-of-Stake sono notevolmente più sicuri dei normali DAC perché incentivano direttamente un comportamento onesto.

Disponibilità dei dati e nodi leggeri

I nodi leggeri devono convalidare la correttezza delle intestazioni del blocco che ricevono senza scaricare i dati del blocco. Il costo di questa leggerezza è l'incapacità di verificare in modo indipendente le intestazioni del blocco rieseguendo le transazioni localmente nel modo in cui fanno i nodi completi.

I nodi leggeri di Ethereum si fidano di insiemi casuali di 512 validatori che sono stati assegnati a un comitato di sincronizzazione. Il comitato di sincronizzazione agisce come un DAC che segnala ai client leggeri che i dati nell'intestazione sono corretti utilizzando una firma crittografica. Ogni giorno, il comitato di sincronizzazione si aggiorna. Ogni intestazione del blocco avvisa i nodi leggeri su quali validatori aspettarsi che firmino il blocco successivo, in modo che non possano essere ingannati a fidarsi di un gruppo dannoso che finge di essere il vero comitato di sincronizzazione.

Tuttavia, cosa succede se un utente malintenzionato in qualche modo riesce a passare un'intestazione del blocco dannosa ai client leggeri e a convincerli che è stata firmata da un comitato di sincronizzazione onesto? In tal caso, l'utente malintenzionato potrebbe includere transazioni non valide e il client leggero le accetterebbe ciecamente, poiché non controlla in modo indipendente tutte le modifiche di stato riassunte nell'intestazione del blocco. Per proteggersi da questo, il client leggero potrebbe utilizzare le prove di frode.

Il modo in cui funzionano queste prove di frode è che un nodo completo, vedendo una transizione di stato non valida diffusa nella rete, potrebbe generare rapidamente un piccolo pezzo di dati che dimostra che una transizione di stato proposta non potrebbe in alcun modo derivare da un determinato insieme di transazioni e trasmettere quei dati ai peer. I nodi leggeri potrebbero raccogliere quelle prove di frode e usarle per scartare le intestazioni del blocco errate, assicurandosi di rimanere sulla stessa catena onesta dei nodi completi.

Questo si basa sul fatto che i nodi completi abbiano accesso ai dati completi della transazione. Un utente malintenzionato che trasmette un'intestazione del blocco errata e non riesce a rendere disponibili i dati della transazione sarebbe in grado di impedire ai nodi completi di generare prove di frode. I nodi completi potrebbero essere in grado di segnalare un avviso su un blocco errato, ma non potrebbero supportare il loro avviso con prove, perché i dati non sono stati resi disponibili per generare la prova!

La soluzione a questo problema di disponibilità dei dati è il DAS. I nodi leggeri scaricano frammenti casuali molto piccoli dei dati di stato completi e utilizzano i campioni per verificare che l'intero set di dati sia disponibile. L'effettiva probabilità di presumere erroneamente la piena disponibilità dei dati dopo aver scaricato N frammenti casuali può essere calcolata (per 100 frammenti la probabilità è 10^-30 (opens in a new tab), ovvero incredibilmente improbabile).

Anche in questo scenario, gli attacchi che trattengono solo pochi byte potrebbero plausibilmente passare inosservati dai client che effettuano richieste di dati casuali. La codifica a cancellazione risolve questo problema ricostruendo piccoli pezzi di dati mancanti che possono essere utilizzati per controllare le modifiche di stato proposte. Una prova di frode potrebbe quindi essere costruita utilizzando i dati ricostruiti, impedendo ai nodi leggeri di accettare intestazioni errate.

Nota: Il DAS e le prove di frode non sono ancora stati implementati per i client leggeri Ethereum Proof-of-Stake, ma sono sulla roadmap, molto probabilmente assumendo la forma di prove basate su ZK-SNARK. I client leggeri di oggi si basano su una forma di DAC: verificano le identità del comitato di sincronizzazione e quindi si fidano delle intestazioni del blocco firmate che ricevono.

Disponibilità dei dati e rollup di layer 2

Le soluzioni di ridimensionamento di layer 2 (l2), come i , riducono i costi di transazione e aumentano la capacità transazionale di Ethereum elaborando le transazioni offchain. Le transazioni dei rollup vengono compresse e pubblicate su Ethereum in lotti. I lotti rappresentano migliaia di singole transazioni offchain in un'unica transazione su Ethereum. Ciò riduce la congestione sul livello di base e riduce le commissioni per gli utenti.

Tuttavia, è possibile fidarsi delle transazioni "riassuntive" pubblicate su Ethereum solo se la modifica di stato proposta può essere verificata in modo indipendente e confermata come il risultato dell'applicazione di tutte le singole transazioni offchain. Se gli operatori dei rollup non rendono disponibili i dati delle transazioni per questa verifica, potrebbero inviare dati errati a Ethereum.

I rollup ottimistici pubblicano i dati delle transazioni compressi su Ethereum e attendono un certo periodo di tempo (in genere 7 giorni) per consentire a verificatori indipendenti di controllare i dati. Se qualcuno identifica un problema, può generare una prova di frode e usarla per contestare il rollup. Ciò causerebbe il rollback della catena e l'omissione del blocco non valido. Questo è possibile solo se i dati sono disponibili. Attualmente, ci sono due modi in cui i rollup ottimistici pubblicano i dati delle transazioni sul layer 1 (l1). Alcuni rollup rendono i dati permanentemente disponibili come CALLDATA che risiedono permanentemente onchain. Con l'implementazione dell'EIP-4844, alcuni rollup pubblicano invece i dati delle loro transazioni su un'archiviazione blob più economica. Questa non è un'archiviazione permanente. I verificatori indipendenti devono interrogare i blob e sollevare le loro contestazioni entro circa 18 giorni prima che i dati vengano eliminati dal layer 1 (l1) di Ethereum. La disponibilità dei dati è garantita dal protocollo Ethereum solo per quella breve finestra fissa. Dopodiché, diventa responsabilità di altre entità nell'ecosistema Ethereum. Qualsiasi nodo può verificare la disponibilità dei dati utilizzando il DAS, ovvero scaricando piccoli campioni casuali dei dati del blob.

I rollup a conoscenza zero (ZK) non hanno bisogno di pubblicare i dati delle transazioni poiché le garantiscono la correttezza delle transizioni di stato. Tuttavia, la disponibilità dei dati è ancora un problema perché non possiamo garantire la funzionalità del rollup ZK (o interagire con esso) senza accedere ai suoi dati di stato. Ad esempio, gli utenti non possono conoscere i propri saldi se un operatore trattiene i dettagli sullo stato del rollup. Inoltre, non possono eseguire aggiornamenti di stato utilizzando le informazioni contenute in un blocco appena aggiunto.

Disponibilità dei dati vs. recuperabilità dei dati

La disponibilità dei dati è diversa dalla recuperabilità dei dati. La disponibilità dei dati è la garanzia che i nodi completi siano stati in grado di accedere e verificare l'intero set di transazioni associate a un blocco specifico. Non ne consegue necessariamente che i dati siano accessibili per sempre.

La recuperabilità dei dati è la capacità dei nodi di recuperare informazioni storiche dalla blockchain. Questi dati storici non sono necessari per verificare nuovi blocchi, sono richiesti solo per la sincronizzazione dei nodi completi dal blocco genesi o per servire specifiche richieste storiche.

Il protocollo principale di Ethereum si occupa principalmente della disponibilità dei dati, non della recuperabilità dei dati. La recuperabilità dei dati può essere fornita da una piccola popolazione di nodi di archivio gestiti da terze parti, oppure può essere distribuita attraverso la rete utilizzando l'archiviazione di file decentralizzata come il Portal Network (opens in a new tab).