Dopo aver trascorso del tempo a osservare da vicino come si comportano le applicazioni su Walrus, un modello continua a ripetersi. I team spesso dicono che i caricamenti sembrano più pesanti del previsto, ma le letture sembrano semplici e fluide. All'inizio, sembra un problema di prestazioni, ma in realtà è solo il modo in cui è progettato il protocollo.
Una volta che ho iniziato a scomporlo passo dopo passo, la differenza ha avuto un senso completo. Scrivere dati su Walrus e leggere dati da Walrus fanno due lavori molto diversi sotto il cofano.
E la parte pesante avviene al momento della scrittura, non al momento della lettura.
Quando un'app carica un blob su Walrus, il sistema non sta solo salvando un file da qualche parte. Sta coordinando l'archiviazione attraverso una rete di nodi di archiviazione che devono concordare di mantenere disponibili i pezzi di quei dati nel tempo.
Quindi quando carico qualcosa, diverse cose accadono contemporaneamente.
Il blob viene suddiviso in frammenti. Questi frammenti sono distribuiti su più nodi di archiviazione. Ogni nodo si impegna a memorizzare la sua parte assegnata. I pagamenti WAL finanziano per quanto tempo quei nodi devono mantenere i dati. E il protocollo registra gli impegni in modo che i controlli di verifica successivi sappiano chi è responsabile di cosa.
Tutta questa coordinazione deve concludersi prima che il caricamento sia considerato riuscito.
Se non ci sono abbastanza nodi che accettano i frammenti, o se il finanziamento non è sufficiente, la scrittura non si finalizza. L'archiviazione è considerata valida solo quando abbastanza fornitori si impegnano in essa.
Quindi le scritture sembrano più pesanti perché il protocollo sta negoziando la responsabilità di archiviazione in tempo reale.
Le letture non devono fare di nuovo quel lavoro.
Una volta che i frammenti sono già archiviati e i nodi vengono pagati per mantenerli, leggere diventa più semplice. Il cliente richiede semplicemente abbastanza frammenti per ricostruire il blob.
Nessuna negoziazione. Nessuna ridistribuzione. Nessun nuovo impegno.
Solo recupero e ricostruzione.
E la matematica rende questo efficiente. Il sistema non ha bisogno di ogni frammento di nuovo. Ha solo bisogno di abbastanza frammenti per ricostruire i dati. Anche se alcuni nodi sono lenti o temporaneamente non disponibili, il recupero funziona finché abbastanza pezzi rispondono.
Quindi le letture sembrano normali perché la difficile coordinazione è già avvenuta in precedenza.
Un altro dettaglio che conta qui è il tempo WAL.
Quando i dati vengono scritti, i pagamenti WAL definiscono per quanto tempo i fornitori di archiviazione devono mantenere disponibili i frammenti. Le decisioni sulla durata dell'archiviazione avvengono durante il caricamento. I fornitori si impegnano per lo spazio su disco aspettandosi un pagamento nel tempo.
Le letture non cambiano lo stato economico. Il recupero non crea nuove obbligazioni o nuovi pagamenti. I nodi servono semplicemente i dati che sono già finanziati per essere archiviati.
Quindi il coordinamento economico si trova anche dal lato della scrittura, non dal lato della lettura.
Penso che la confusione derivi spesso dall'aspettativa che il caricamento e il recupero si comportino in modo simile. Nei sistemi tradizionali, salvare e caricare file sembra simmetrico. In Walrus, non lo sono.
Le scritture stabiliscono obbligazioni di archiviazione. Le letture le consumano.
Questo aiuta anche a chiarire quali garanzie offre Walrus e cosa lascia alle applicazioni.
Il protocollo impone la distribuzione dei frammenti, gli impegni di archiviazione e i controlli di verifica per confermare che i nodi memorizzino ancora i dati. Finché l'archiviazione rimane finanziata e i frammenti sono disponibili, i blob rimangono recuperabili.
Ma il protocollo non decide per quanto tempo i dati devono vivere. Non gestisce i rinnovi né decide quando i dati diventano obsoleti. Le applicazioni devono monitorare la scadenza, rinnovare l'archiviazione quando necessario o migrare i dati altrove.
Se le applicazioni dimenticano questa responsabilità del ciclo di vita, i problemi si presentano più tardi quando i blob scadono o WAL continua a essere speso per memorizzare dati inutilizzati.
Ci sono anche realtà pratiche per i nodi di archiviazione. I fornitori mantengono continuamente i dati, rispondono alle sfide di verifica e servono frammenti ai clienti. Lo spazio su disco e la larghezza di banda sono costi continui. L'archiviazione è un lavoro attivo, non un'archiviazione passiva.
La verifica stessa introduce latenza e sovraccarico operativo. I pagamenti WAL compensano i nodi per fare questo lavoro.
Oggi, Walrus è utilizzabile in ambienti di produzione per team che comprendono queste meccaniche. I caricamenti di blob funzionano, il recupero funziona e i dati finanziati rimangono disponibili. Ma gli strumenti per il monitoraggio del ciclo di vita e l'automazione del rinnovo stanno ancora migliorando. Molti costruttori stanno ancora imparando che l'archiviazione decentralizzata richiede la stessa disciplina delle infrastrutture tradizionali.
Strumenti migliori potrebbero ridurre l'attrito nella coordinazione della scrittura o automatizzare il timing del rinnovo. Ma questi miglioramenti non dipendono da cambiamenti a Walrus. Dipendono dagli strumenti dell'ecosistema e dai livelli di integrazione.
A livello di protocollo, il comportamento è già coerente.
Le scritture sembrano pesanti perché coordinano la responsabilità di archiviazione e il finanziamento attraverso la rete. Le letture sembrano facili perché ricostruiscono semplicemente i dati dagli impegni già in atto.
E una volta che comprendi quella differenza, le prestazioni di Walrus smettono di essere sorprendenti e cominciano a avere senso operativo.