Negli ultimi anni, l'interesse per le soluzioni di archiviazione dei dati nel mondo Web3 è aumentato, e Walrus Finance (WAL) si distingue come uno dei progetti che offre un approccio decentralizzato a questo bisogno. Fornisce in particolare soluzioni per archiviare in modo sicuro grandi volumi di file sulla blockchain, posizionandosi non solo come strumento per l'archiviazione dei dati, ma anche come protocollo economico potenziato da incentivi tokenomici. Costruito sulla blockchain Sui, il progetto mira a creare un'infrastruttura scalabile e sostenibile integrando la gestione dei dati off-chain con processi di verifica on-chain.
Una caratteristica unica del Materiale Rosso è la sua capacità di funzionare in una rete asincrona mentre supporta le sfide di archiviazione, rendendolo il primo di questo tipo. Ciò è possibile grazie alla codifica bidimensionale che consente soglie di codifica diverse per ogni dimensione. La dimensione a bassa soglia può essere utilizzata da nodi che non hanno ricevuto i simboli durante il flusso di scrittura per recuperare ciò che hanno perso, mentre la dimensione a alta soglia può essere utilizzata per il flusso di lettura per impedire all'avversario di rallentare i nodi onesti durante i periodi di sfida e raccogliere informazioni sufficienti per rispondere alle sfide.
Un ultimo problema per Walrus, e in generale per qualsiasi sistema decentralizzato basato sulla codifica per l'archiviazione, è operare in modo sicuro attraverso epoch gestite da comitati diversi di nodi di archiviazione. Questo è complesso perché vogliamo garantire un'accessibilità ininterrotta per la lettura e la scrittura dei blob durante il naturale cambiamento dei nodi in un sistema senza autorizzazione, ma se continuiamo a scrivere dati nei nodi che stanno per andarsene, questi devono continuare a trasferire i dati ai nodi che li sostituiscono. Ciò crea una corsa per le risorse di quei nodi, che potrebbero smettere di accettare scritture o non riuscire mai a trasferire la responsabilità. Walrus affronta questo problema tramite il suo innovativo protocollo a più fasi per il cambiamento di epoch, che si adatta naturalmente ai principi dei sistemi decentralizzati di archiviazione.
Materiale Rosso
Il protocollo di codifica sopra descritto raggiunge l'obiettivo di un basso fattore di sovraccarico con un'alta garanzia, ma non è ancora adatto a un'implementazione a lungo termine. La principale sfida è che in un sistema su larga scala in esecuzione a lungo termine, i nodi di archiviazione sperimentano regolarmente guasti, perdono i loro slivers e devono essere sostituiti. Inoltre, in un sistema senza autorizzazione, c'è
5Potrebbe esserci un costo aggiuntivo di O(logn) a seconda dello schema di impegno.
S11
S21
S31
S41
un certo grado naturale di cambiamento nei nodi di archiviazione anche quando sono ben incentivati a partecipare.
Entrambi questi casi porterebbero a una quantità enorme di dati trasferiti sulla rete, pari alla dimensione totale dei dati archiviati per recuperare i slivers per i nuovi nodi di archiviazione. Questo è proibitivamente costoso. Vorremmo invece che il sistema fosse autoguaritore, in modo che il costo del recupero in caso di cambiamento sia proporzionale solo ai dati che devono essere recuperati e cresca inversamente con n.
Per raggiungere questo obiettivo, il Materiale Rosso codifica i blob in due dimensioni (codifica 2D). La dimensione principale è equivalente alla codifica RS utilizzata nei sistemi precedenti. Tuttavia, per consentire un recupero efficiente dei slivers di B, codifichiamo anche su una seconda dimensione. Il Materiale Rosso si basa sulla codifica lineare per errore (vedi sezione II) e sul framework Twin-code, che fornisce archiviazione codificata per errore con un recupero efficiente in un ambiente tollerante ai guasti con scrittori fidati. Adattiamo questo framework per renderlo adatto a un ambiente tollerante a guasti di tipo byzantino con un singolo insieme di nodi di archiviazione, aggiungendo ulteriori ottimizzazioni che descriviamo più avanti.
Codifica: Il nostro punto di partenza è la seconda proposta iniziale che suddivide i blob in f + 1 slivers. Invece di codificare semplicemente i slivers di riparazione, aggiungiamo prima un'altra dimensione al processo di suddivisione: il blob originale viene diviso in f + 1 slivers primari (verticali nella figura) e in 2f + 1 slivers secondari (orizzontali nella figura). La Figura 2 illustra questo processo. Di conseguenza, il file viene ora diviso in (f + 1)(2f + 1) simboli che possono essere visualizzati in una matrice [f + 1, 2f + 1].
