In questa serie composta da tre parti, sveleremo i risultati tecnici in grado di migliorare significativamente l'elaborazione dei dati delle applicazioni che operano sul protocollo Internet Computer (ICP).
Questo aggiornamento è un traguardo nel roadmap di ICP di Stellarator, attualmente in fase di distribuzione su tutta la rete. Stellarator è una svolta nell'archiviazione dei dati on-chain, consentendo a ogni sottorete di supportare oltre 1 TB di memoria, portando opportunità per applicazioni ricche di dati precedentemente limitate dalla capacità di archiviazione.
Questo progresso consente agli sviluppatori di costruire applicazioni complesse che richiedono elaborazione di dati su larga scala, portando a nuovi livelli di utilità per la tecnologia blockchain.
Senza ulteriori indugi, iniziamo questa serie per vedere come ICP ora utilizza gli aggiornamenti Stellarator per archiviare i dati.
Persistenza dei dati su Internet Computer
Questo post del blog offre una panoramica su come funzionano le repliche delle macchine di Internet Computer, con un focus particolare sulle recenti modifiche all'archiviazione basata su LSMT, che consentono una maggiore archiviazione replicata nelle sottoreti di Internet Computer e le rendono più capaci di gestire carichi di lavoro pesanti.
Internet Computer è composto da sottoreti e macchine virtuali, queste macchine virtuali eseguono la stessa copia su 13-40 macchine replica. Ogni replica è responsabile dell'esecuzione di tutti i messaggi inviati ai contenitori su quella sottorete e memorizza tutti i dati dei contenitori, quindi tutte le repliche hanno uno stato completo e identico della sottorete.
Gli sviluppatori possono distribuire contenitori sull'Internet Computer. I contenitori sono simili ai contratti intelligenti su altre blockchain, ma possono eseguire calcoli più generali e memorizzare ordini di grandezza più elevati di dati rispetto ai contratti intelligenti su altre catene.
I dati memorizzati nel contenitore devono infine essere memorizzati su un certo hardware fisico. Grazie all'introduzione recente del livello di archiviazione basato su LSMT e a molte altre ottimizzazioni e miglioramenti, le sottoreti su Internet Computer possono memorizzare dati dei contenitori fino a 1 TB.
La maggior parte dei dati dei contenitori è memorizzata nella loro memoria heap (fino a 4 GB in scrittura) o nella loro memoria stabile (fino a 500 GB in scrittura), e ci sono anche altre forme di dati associate ai contenitori, come il codice del contenitore, messaggi in volo e varie informazioni come elenchi di controllori e saldi di cicli.
Il livello di archiviazione di ICP colma il divario tra l'archiviazione dei contenitori (ad esempio, memoria heap e memoria stabile) e l'hardware di archiviazione sottostante delle macchine replica (ad esempio, dischi e RAM).
Come parte del traguardo Stellarator, il livello di archiviazione è stato ampiamente ridisegnato e reimplementato per consentire a ICP di affrontare le sfide di scalabilità future e di risolvere i colli di bottiglia di scalabilità più significativi del vecchio livello di archiviazione. Tutte le modifiche rilevanti sono state completate di recente e Internet Computer sta ora eseguendo la nuova implementazione del livello di archiviazione da diversi mesi.
Il resto di questo blog tratta del processo di ridisegno del livello di archiviazione come struttura dati ad albero di fusione di log, progettato per eliminare i colli di bottiglia legati all'archiviazione e fornire un'esperienza migliore agli utenti e agli sviluppatori di contenitori a elevate esigenze di archiviazione.
Per gli utenti di ICP, la cosa più rilevante è che questo lavoro ha recentemente aumentato lo stato di replica su una singola sottorete fino a 1 TB. Inoltre, il ridisegno ha permesso a Internet Computer di gestire meglio i contenitori che scrivono grandi volumi di dati.
Checkpoint
In generale, il livello di archiviazione di Internet Computer combina l'archiviazione persistente su disco con l'archiviazione temporanea in RAM. Un concetto chiave su come Internet Computer memorizza il suo stato è quello dei checkpoint, che rappresentano un punto logico nel tempo in cui lo stato dell'intera sottorete è memorizzato su disco.
I checkpoint vengono creati ogni 500 blocchi o ogni pochi minuti in modo deterministico, il che significa che tutte le repliche scriveranno lo stesso checkpoint allo stesso livello. I checkpoint sono memorizzati su disco nella forma di una directory di file, la struttura della directory è la seguente (notevolmente semplificata):
In questa struttura, ogni contenitore è memorizzato nella propria sottodirectory, e ogni directory del contenitore contiene file separati per memoria heap, memoria stabile e altre informazioni (come i messaggi in volo). Ci sono molte ragioni per cui i dati vengono salvati su disco in forma di checkpoint.
1. Persistenza dei dati: le macchine replica possono riavviarsi in qualsiasi momento, ci possono essere bug nel codice della replica, oppure l'hardware potrebbe guastarsi, o potrebbero esserci problemi di alimentazione nel data center. Quando ciò accade, è possibile ricaricare l'ultimo checkpoint.
Si noti che, anche se i checkpoint vengono creati solo ogni 500 round, le repliche possono ricreare lo stato a un'altezza non di checkpoint. Le repliche hanno solo bisogno dell'ultimo checkpoint e di tutti i blocchi finali tra il checkpoint e lo stato più recente. Poiché tutte le esecuzioni sono deterministiche, questi blocchi possono essere riprodotti e si garantisce che lo stato ricreato sia esattamente lo stesso. I blocchi necessari possono essere memorizzati su disco separatamente dal checkpoint o possono essere ottenuti da altre repliche.
2. Sincronizzazione: tutti i messaggi (copia) sono eseguiti da tutte le repliche, quindi, per un dato livello h, tutte le repliche dovrebbero avere lo stesso stato. Il protocollo previene le divergenze (cioè quando alcune repliche oneste si trovano in uno stato diverso dallo stato di consenso) hashando prima lo stato e poi firmando con soglia l'hash generato. Solo quando almeno ⅔ (più precisamente 2f + 1) delle repliche concordano sullo stesso hash può essere creato un tale consenso di soglia e la sottorete può continuare a funzionare.
Tuttavia, le sottoreti di Internet Computer possono avere stati più grandi, al momento della scrittura, limitati a 1 TB. Mantenere un massimo di 2,5 blocchi al secondo (il più veloce attualmente ottenuto da una sottorete su Internet Computer) mentre si esegue l'hash di così tanti dati dopo ogni blocco è impraticabile, quindi Internet Computer esegue l'hash solo su alcune parti selezionate dello stato non di checkpoint, come alcune informazioni di base su ciascun contenitore, le risposte recenti ai messaggi in ingresso e i messaggi XNet inviati ad altre sottoreti.
Per i checkpoint, il protocollo esegue l'hash dell'intero stato per ottenere una struttura dati chiamata elenco. Questo elenco è calcolato hashando tutti i file nella directory del checkpoint e contiene gli hash di tutti i singoli file suddivisi in blocchi di 1 MB. Alla fine del calcolo dell'elenco, l'hash radice dell'elenco viene calcolato, coprendo tutti gli hash singoli nell'elenco, e poi viene firmato con soglia dalla sottorete. Il calcolo dell'elenco può richiedere decine di secondi, ma questo lavoro viene eseguito solo ogni 500 blocchi ed è eseguito in parallelo con l'esecuzione dei contenitori in background.
3. Sincronizzazione dello stato: Internet Computer consente di modificare la topologia della sottorete attraverso le proposte NNS. Quando i nodi replica entrano nella sottorete, possono ottenere l'ultimo checkpoint da altri nodi replica. Ricorda che un checkpoint è un insieme di file; quindi, dopo aver utilizzato l'hash radice e la verifica della firma soglia della sottorete, il protocollo di sincronizzazione dello stato può ottenere file pezzo per pezzo, confrontando l'hash dei blocchi ottenuti con quelli nell'elenco. Se tutti i controlli hanno successo, la replica può concludere che lo stato ottenuto corrisponde allo stato concordato delle varie sottoreti al livello del checkpoint. Se la replica è in ritardo per altri motivi e non può recuperare semplicemente ripetendo i blocchi, verrà anche attivata la sincronizzazione dello stato.
4. Dimensione massima dello stato: attualmente, la dimensione massima dello stato è di 1 TB, mentre la RAM della macchina dei nodi replica è di 512 GB, quindi non è possibile caricare l'intero stato in RAM. Internet Computer utilizza la RAM principalmente per conservare i dati più recenti che non sono stati ancora persistenti e per memorizzare nella cache i dati per migliorare le prestazioni.
PageMap e altezze non di checkpoint
Poiché i checkpoint vengono creati solo ogni 500 blocchi, ICP deve fornire diversi spazi di archiviazione per stati non di checkpoint. L'idea di base seguita dal livello di archiviazione è che questi dati sono memorizzati su disco nella forma combinata dell'ultimo checkpoint e qualsiasi modifica successiva è memorizzata in RAM.
PageMap è l'implementazione della maggior parte del contenuto dello stato della sottorete da parte delle repliche. La maggior parte dello stato della sottorete è rappresentato dallo stato dei contenitori, in particolare dalla memoria heap e stabile dei contenitori.
Attualmente, i contenitori possono avere fino a 4 GB di memoria heap, 500 GB di memoria stabile, e il limite totale dello stato della sottorete è di 1 TB, ma tutte queste limitazioni potrebbero cambiare in futuro. Entrambi i tipi di memoria possono essere letti tramite chiamate di contenitore di copia (aggiornamenti) e non copia (query) e possono essere modificati tramite chiamate di copia.
La struttura dati PageMap è progettata per consentire letture e scritture efficienti in memoria, oltre a supportare scritture efficienti di checkpoint. Un obiettivo specifico è rendere le prestazioni indipendenti dalla dimensione totale della memoria. Si noti che il nome PageMap deriva dal fatto che tutta la granularità di lettura e scrittura è di pagine di 4 KB, che è la stessa dimensione delle pagine utilizzate dal sistema operativo sottostante.
PageMap memorizza lo stato su due livelli: il primo livello è chiamato archiviazione e proviene dai file dell'ultimo checkpoint, che rappresentano lo stato all'altezza dell'ultimo checkpoint. Il secondo livello, cioè l'incremento delle pagine, rappresenta tutte le modifiche avvenute da quel checkpoint e sono memorizzate in RAM.
Quando si legge da PageMap, i dati restituiti provengono o dall'incremento delle pagine, oppure vengono letti dai file di checkpoint (se mancanti). La scrittura in PageMap viene effettuata modificando l'incremento delle pagine con i nuovi dati.
Ciclo di vita del checkpoint
Il compito principale del livello di archiviazione è scrivere i checkpoint su disco e mantenere aggiornato lo stato di tutti i PageMap. Quando si scrive un nuovo checkpoint, tutte le pagine incrementali vengono aggiornate su disco, aggiornando così la parte di archiviazione di tutti i PageMap.
Per garantire che tutti i dati siano salvati, le repliche devono sempre mantenere l'ultimo checkpoint firmato con soglia, il che significa che non è possibile semplicemente sovrascrivere i file di checkpoint precedenti, poiché qualsiasi modifica di questo tipo cambierebbe il precedente checkpoint prima che il nuovo checkpoint sia completamente scritto, con il rischio di perdita di dati. Allo stesso tempo, il costo di scrivere un checkpoint completo su disco (fino a 1 TB) ogni 500 round sarebbe estremamente elevato. Al contrario, creare un nuovo checkpoint comprende 3 passaggi fondamentali:
Copiare il vecchio checkpoint in una cartella temporanea, chiamata tip;
Modificare il tip per rappresentare i dati del nuovo checkpoint;
Rinominare il tip nella nuova directory del checkpoint (in modo da creare un nuovo checkpoint in modo atomico).
Il primo passo potrebbe essere il più costoso, poiché più grande è lo stato, più tempo ci vorrà per copiare i file, quindi i file di checkpoint saranno più grandi.
Tuttavia, è proprio qui che entra in gioco il formato dei file dei checkpoint e della struttura dati ad albero di fusione di log: utilizzando LSMT, questo passaggio è a basso costo e non si espande con la dimensione dello stato. Al contrario, prima del ridisegno LSMT del livello di archiviazione, questo passaggio era lento e imprevedibile.
Struttura dati ad albero di fusione di log
La struttura dati ad albero di fusione di log (LSMT) è una struttura dati ampiamente utilizzata, particolarmente adatta per i database. Su Internet Computer, vengono utilizzate come base per la parte di archiviazione dei PageMaps, risolvendo un problema particolare: semplificano il passaggio di "copia" nel ciclo di vita dei checkpoint, poiché tutti i file sono scritti solo una volta e non vengono mai modificati.
Utilizzando LSMT, modificare lo stato (logico) scrivendo file di sovrascrittura extra. Per leggere il valore di una pagina, l'algoritmo prima controlla i file di sovrascrittura più recenti per vedere se quella pagina è presente in esso. Se è presente, legge il valore della pagina da quel file di sovrascrittura; altrimenti, controlla il file di sovrascrittura successivo più vecchio. Nell'implementazione utilizzata su Internet Computer, se la pagina non è presente in alcun file di sovrascrittura, viene letta come zero.
La figura qui sotto mostra un insieme di tre file di sovrascrittura che rappresentano lo stato dei contenitori; le frecce verticali mostrano letture diverse dei dati e i file finali che leggono i dati.
Il ciclo di vita del checkpoint di LSMT è il seguente:
Collegare rigidamente tutti i file dell'ultimo checkpoint a una cartella temporanea, chiamata tip;
Scrivere un nuovo file di sovrascrittura che contiene tutte le modifiche dall'ultimo checkpoint;
Rinominare il tip nella nuova directory del checkpoint (per l'atomicità).
Il punto chiave è che ogni file di sovrascrittura viene scritto solo una volta e non viene mai modificato, rendendo sicuro impostare più checkpoint su disco e condividere alcuni file tra di essi tramite collegamenti rigidi. Si noti che se il ciclo di vita del checkpoint tenta di modificare un file, questo stesso processo non funzionerà: se un file ha più collegamenti rigidi, la modifica di uno qualsiasi di essi cambierà i dati in tutti i collegamenti rigidi, compromettendo i checkpoint precedentemente certificati.
La struttura dati ad albero di fusione di log può memorizzare più versioni dello stesso intervallo di dati, il che porta a costi di archiviazione, definiti come il rapporto tra la dimensione di tutti i file di sovrascrittura e la dimensione logica dei dati rappresentati. Inoltre, i dati possono essere distribuiti su più file.
Con l'aumento dei costi di archiviazione o del numero di file di sovrascrittura, l'implementazione del livello di archiviazione programmerà fusioni, che riorganizzano i dati acquisendo un insieme di file di sovrascrittura e sostituendoli con un singolo file che contiene solo l'ultima versione di ciascun dato. Le fusioni vengono programmate per PageMap con costi di archiviazione o numero di file eccezionalmente elevati e vengono eseguite in background in modo che non interferiscano con l'esecuzione dei messaggi del contenitore.
Design precedente che utilizzava Reflinks
Il livello di archiviazione iniziale di Internet Computer non si basava su LSMT. Dal 2021, quando è nato Internet Computer, fino al 2024, il livello di archiviazione ha fatto un uso intensivo del nuovo collegamento.
Il nuovo collegamento, a volte chiamato scrittura al momento della copia, è un'operazione del file system utilizzata per copiare file. Alcuni file system supportano questa operazione; le repliche di Internet Computer utilizzano il file system XFS che supporta questa operazione. La differenza tra il nuovo collegamento e la copia di file normali è che non copia l'intero contenuto del file. Invece, il file system ricorda quali dati sono condivisi tra il file originale e il nuovo file. La differenza tra il nuovo collegamento e il collegamento rigido è che i due file possono essere modificati indipendentemente l'uno dall'altro.
Nella progettazione del vecchio livello di archiviazione, il ciclo di vita del checkpoint funzionava come segue:
Ricollegare tutti i file dell'ultimo checkpoint a una cartella temporanea, chiamata tip;
Modificare i file nel tip in base a tutte le modifiche dall'ultimo checkpoint;
Rinominare il tip nella nuova directory del checkpoint.
Un potenziale vantaggio è che PageMap sarà rappresentato da un singolo file nel checkpoint, evitando così costi di archiviazione. Tuttavia, per modificare il file per adattarlo a una nuova altezza di checkpoint, è necessario ricollegare i file corrispondenti dall'ultimo checkpoint, anziché usare collegamenti rigidi.
Vantaggi di LSMT rispetto ai Reflinks
In linea di principio, il nuovo collegamento garantisce la velocità dei collegamenti rigidi e la disponibilità della copia. Sfortunatamente, con l'aumento delle richieste di dati su Internet Computer (sia in termini di throughput I/O che di quantità totale di dati), per vari motivi il nuovo collegamento è diventato un collo di bottiglia delle prestazioni.
1. Lentezza del nuovo collegamento: il tempo necessario per collegare rigidamente i file può variare notevolmente; in alcuni casi potrebbe richiedere solo pochi secondi, ma negli esperimenti abbiamo anche osservato che il nuovo collegamento di 370 GB richiede fino a 10 ore. Nella logica dei checkpoint vecchi di Internet Computer, un passaggio di nuovo collegamento di 10 ore porterebbe a un'interruzione dell'intera sottorete per 10 ore.
La frammentazione può portare a una scarsa velocità di nuovo collegamento. Internamente, il file system XFS mantiene una struttura dati che mappa le varie parti di un file ai blocchi di dati reali su disco. Quando il costo di attraversare queste strutture dati diventa elevato, si verifica la frammentazione e una riduzione della velocità di nuovo collegamento.
La frammentazione è particolarmente suscettibile a essere innescata dalla seguente sequenza: molte scritture in file, quindi un nuovo collegamento, molte scritture in una delle copie, quindi di nuovo un nuovo collegamento, e così via. Sfortunatamente, considerando il flusso di lavoro dei checkpoint su Internet Computer, l'uso massiccio dei contenitori tende a innescare questo comportamento.
D'altra parte, i collegamenti rigidi offrono prestazioni coerenti, non influenzate da alcun problema di frammentazione.
Prima dell'introduzione della struttura dati ad albero di fusione di log, sono state implementate molte soluzioni temporanee, tra cui la deframmentazione manuale dei file (leggendo i file e riscrivendoli) e la scrittura dei file in porzioni continue più grandi, entrambe a scapito di un ampio ingrandimento della scrittura e che potevano comunque portare a pause di 30 minuti.
2. Dimensione massima dello stato: oltre al tempo di nuovo collegamento molto lungo causato da troppa frammentazione, anche un grado moderato di frammentazione può far sì che il tempo di nuovo collegamento sia proporzionale alla quantità totale di dati memorizzati nella sottorete. Nella precedente implementazione del livello di archiviazione, Internet Computer ha stabilito che la quantità di archiviazione per ciascuna sottorete non deve superare i 700 GB, questo numero dipende in gran parte da quanto dati moderatamente frammentati possono essere ricollegati in 20-30 secondi.
Quando si utilizzano collegamenti rigidi, il tempo di checkpoint non si espande allo stesso modo con la dimensione dei dati, eliminando così questo collo di bottiglia.
3. Prestazioni scadenti in multithreading: uno degli obiettivi della logica dei checkpoint è evitare, per quanto possibile, operazioni di sincronizzazione, poiché durante il checkpoint l'esecuzione dei contenitori si arresta. Naturalmente, è da considerare se sia possibile eseguire in background il nuovo collegamento mentre l'esecuzione continua (anche se lentamente). Sfortunatamente, l'esperienza dimostra che non è possibile ricollegare e leggere i file simultaneamente, quindi eseguire il nuovo collegamento in parallelo con l'esecuzione porta solo a un rallentamento dell'esecuzione.
Nella nuova progettazione del livello di archiviazione, il nuovo collegamento e l'esecuzione avvengono in parallelo e non si rallentano a vicenda.
4. Cache: Come accennato in precedenza, leggere i dati dalla memoria del contenitore comporta la lettura dei dati sia dalla RAM sia dai file di checkpoint sottostanti. La lettura ripetuta dello stesso file di solito non richiede più letture dai dischi rigidi o SSD reali. Al contrario, questi dati vengono memorizzati nella cache dal sistema operativo. Sfortunatamente, il nuovo collegamento interferisce con la cache, poiché prima il file viene ricollegato e poi letto dalla nuova replica, non utilizza la cache. Quindi, su Internet Computer, dopo la scrittura del checkpoint, si osserva un picco significativo (e lento) nelle letture su disco, poiché tutte le letture passano ai nuovi file. Inoltre, il calcolo esplicito (cioè calcolare l'hash di tutti i file di checkpoint per raggiungere il consenso) beneficia notevolmente di una cache migliore.
Al contrario, quando si collegano rigidamente i file, tutte le cache vengono mantenute. Qualsiasi dato letto o scritto di recente, anche se accaduto durante l'intervallo di checkpoint precedente, sarà ancora memorizzato nella cache, quindi può essere recuperato rapidamente.
Risultati
Il livello di archiviazione LSMT è stato implementato su tutte le sottoreti di Internet Computer nelle settimane del secondo trimestre 2024. La figura sottostante mostra le metriche prima e dopo l'aggiornamento del codice replica, dove la linea verticale rossa indica il momento in cui è stato attivato il livello di archiviazione LSMT.
La prima figura mostra il tempo di checkpoint della sottorete w4rem, che ospita i contenitori per l'integrazione Bitcoin. Rispetto a molte altre sottoreti, i contenitori ospitati dalla sottorete Bitcoin hanno carichi di lavoro di scrittura pesanti sia per la memoria heap che per quella stabile, quindi la frammentazione è un problema particolarmente preoccupante per questa sottorete.
Dal punto di vista delle metriche, il tempo di checkpoint è stato ridotto da oltre 20 secondi a soli 1-2 secondi, principalmente grazie all'eliminazione del passaggio di nuovo collegamento, che occupava la maggior parte di quei 20 secondi.
Per gli utenti del contenitore Bitcoin, il vantaggio è una risposta più rapida. Durante il checkpoint, la sottorete non gestisce alcuna chiamata di aggiornamento o query di copia. Se un utente invia una chiamata di aggiornamento o una query di copia al contenitore Bitcoin all'inizio del checkpoint, ci vorranno almeno 20 secondi per ricevere una risposta. Utilizzando il livello di archiviazione LSMT, è possibile eliminare fondamentalmente tali tempi di risposta incoerenti.
La seconda figura mostra il tasso di completamento della sottorete k44fs. Il tasso di completamento o il tasso di blocco è il numero di blocchi prodotti dalla sottorete al secondo.
Internet Computer limita il numero di istruzioni eseguite per round a un valore che corrisponde approssimativamente al lavoro che può completare in un secondo, in modo che il tasso di completamento possa rimanere superiore a 1 blocco al secondo.
Prima dell'aggiornamento al livello di archiviazione LSMT, il tasso di completamento diminuiva regolarmente, correlato ai checkpoint. I checkpoint influenzano il tasso di completamento per due motivi principali: prima di tutto, il tempo necessario per creare un checkpoint, durante il quale non vengono eseguiti blocchi. Dopo l'aggiornamento, questo impatto si riduce, poiché il tempo di checkpoint è generalmente molto più breve.
Il secondo motivo è che il comportamento di caching del livello di archiviazione LSMT è migliore; in particolare, il passaggio di nuovo collegamento nella precedente implementazione del livello di archiviazione causava invalidazioni della cache. Quindi, dopo il checkpoint, qualsiasi contenitore che leggeva dalla sua memoria faceva sì che le repliche recuperassero quei dati dal disco, che era significativamente più lento rispetto ai dati disponibili nella cache in RAM. Questo problema non esiste nel nuovo livello di archiviazione LSMT.
Come indicano le metriche, la diminuzione del tasso di completamento dopo l'aggiornamento è visibilmente ridotta, poiché il checkpoint stesso è più veloce, non è più necessario il nuovo collegamento e la cache dei file non viene più invalidata.
Per gli utenti del contenitore su questa sottorete, questo si traduce in tempi di risposta più rapidi e maggiore throughput.
Conclusione
Ridefinire il livello di archiviazione dell'Internet Computer attorno alla struttura dati ad albero di fusione di log è un investimento importante nella scalabilità e nelle prestazioni della piattaforma. Non solo rende possibili alcuni carichi di lavoro ad alta intensità di memoria, ma consente anche all'Internet Computer di fornire stati più grandi ai contenitori.
In un contesto di intelligenza artificiale e modelli di linguaggio di grandi dimensioni in esecuzione su blockchain, i contenitori che operano su grandi volumi di dati sono particolarmente interessanti. Questi contenitori non solo dipendono da una grande archiviazione di dati, ma fanno anche un uso intensivo della larghezza di banda I/O.
Inoltre, stabilisce le basi per miglioramenti futuri, come ridurre il carico di lavoro critico sfruttando meglio la concorrenza, rendendo Internet Computer più reattivo. L'esperienza del livello di archiviazione originale dimostra che evitare il nuovo collegamento è cruciale per raggiungere questo obiettivo, e la struttura dati LSMT può farlo.
Ti è piaciuto questo articolo? Condividi le tue opinioni sul canale DFINITY Developers X e unisciti a noi domani per la seconda parte del nostro viaggio Stellarator, esplorando la persistenza ortogonale migliorata con Luc Bläser.
Contenuti IC che ti interessano
Progressi tecnologici | Informazioni sul progetto | Eventi globali
Segui il canale Binance di IC
Rimanere aggiornati
