Autore: Kernel Ventures Jerry Luo

Redattori: Kernel Ventures Rose, Kernel Ventures Mandy, Kernel Ventures Joshua

TLDR:

  1. Nella fase iniziale della blockchain, mantenere la coerenza dei dati è considerato estremamente importante per garantire sicurezza e decentralizzazione. Tuttavia, con lo sviluppo dell'ecosistema blockchain, anche la pressione di archiviazione sta aumentando, portando a una tendenza alla centralizzazione nell'operazione del nodo. Stando così le cose, il problema dei costi di archiviazione portato dalla crescita di TPS in Layer1 deve essere risolto urgentemente.

  2. Di fronte a questo problema, gli sviluppatori dovrebbero proporre una soluzione che tenga pienamente conto della sicurezza, dei costi di archiviazione, della velocità di lettura dei dati e della versatilità del livello DA.

  3. Nel processo di risoluzione di questo problema, sono emerse molte nuove tecnologie e idee, tra cui Sharding, DAS, Verkle Tree, componenti intermedi DA e così via. Cercano di ottimizzare lo schema di archiviazione del livello DA riducendo la ridondanza dei dati e migliorando l'efficienza della convalida dei dati.

  4. Le soluzioni DA sono ampiamente categorizzate in due tipi dal punto di vista della posizione di archiviazione dei dati, vale a dire, DA della catena principale e DA di terze parti. I DA della catena principale sono progettati dal punto di vista della pulizia regolare dei dati e dell'archiviazione dei dati suddivisa per ridurre la pressione di archiviazione sui nodi, mentre i DA di terze parti sono progettati per soddisfare le esigenze di archiviazione che hanno soluzioni ragionevoli per grandi quantità di dati. Di conseguenza, facciamo principalmente un compromesso tra compatibilità a catena singola e compatibilità multi-catena nei DA di terze parti e proponiamo tre tipi di soluzioni: DA specifici della catena principale, DA modularizzati e DA di archiviazione a catena pubblica.

  5. Le catene pubbliche di tipo pagamento hanno requisiti molto elevati per la sicurezza dei dati storici e, quindi, sono adatte all'uso della catena principale come strato DA. Tuttavia, per le catene pubbliche che sono in funzione da molto tempo e hanno un gran numero di miner che gestiscono la rete, è più adatto adottare una DA di terze parti che non comporti la modifica dello strato di consenso con una sicurezza relativamente elevata. Per le catene pubbliche complete, è più adatto utilizzare l'archiviazione DA dedicata della catena principale con una maggiore capacità di dati, costi inferiori e sicurezza. Tuttavia, considerando la domanda di DA cross-chain, anche la DA modulare è una buona opzione.

  6. Nel complesso, la blockchain si sta muovendo verso la riduzione della ridondanza dei dati e verso la divisione del lavoro multi-catena.

1. Contesto

Blockchain, come registro distribuito, deve effettuare una copia dei dati storici archiviati su tutti i nodi per garantire che l'archiviazione dei dati sia sicura e sufficientemente decentralizzata. Poiché la correttezza di ogni modifica di stato è correlata allo stato precedente (l'origine della transazione), per garantire la correttezza della transazione, una blockchain dovrebbe archiviare tutta la cronologia delle transazioni dalla generazione della prima transazione alla transazione corrente. Prendendo Ethereum come esempio, anche prendendo 20 kb per blocco come dimensione media, la dimensione totale dei dati correnti in Ethereum ha raggiunto i 370 GB. Per un nodo completo, oltre al blocco stesso, deve registrare lo stato e le ricevute delle transazioni. Includendo questa parte, la quantità totale di archiviazione di un singolo nodo ha superato 1 TB, il che rende gradualmente centralizzata l'operazione del nodo.

Fonte: Etherscan

Il recente upgrade di Ethereum di Cancun mira ad aumentare il TPS di Ethereum a quasi 1000, punto in cui la crescita annuale dello storage di Ethereum supererà la somma del suo storage attuale. Nelle catene pubbliche ad alte prestazioni, la velocità di transazione di decine di migliaia di TPS può portare centinaia di GB di dati in più al giorno. La ridondanza dei dati comune di tutti i nodi sulla rete ovviamente non può adattarsi a tale pressione di storage. Quindi, Layer1 deve trovare una soluzione adatta per bilanciare la crescita del TPS e il costo di storage dei nodi.

2. Indicatori di prestazione di DA

2.1 Sicurezza

Rispetto a un database o a una lista concatenata, l'immutabilità della blockchain deriva dal fatto che i suoi dati appena generati possono essere verificati da dati storici, garantendo così che la sicurezza dei suoi dati storici sia il primo problema da considerare nell'archiviazione del livello DA. Per giudicare la sicurezza dei dati dei sistemi blockchain, spesso analizziamo la quantità di ridondanza dei dati e il metodo di controllo della disponibilità dei dati.

  • Numero di ridondanza: la ridondanza dei dati nel sistema blockchain svolge principalmente questi ruoli: in primo luogo, una maggiore ridondanza nella rete può fornire più campioni di riferimento quando il verificatore deve controllare lo stato dell'account, il che può aiutare il nodo a selezionare i dati registrati dalla maggior parte dei nodi con maggiore sicurezza. Nei database tradizionali, poiché i dati vengono archiviati solo sotto forma di coppie chiave-valore in un determinato nodo, la modifica dei dati storici viene eseguita solo in un singolo nodo, con un basso costo dell'attacco e, teoricamente, maggiore è il numero di ridondanze, maggiore è il grado di credibilità dei dati. Teoricamente, maggiore è la ridondanza, più affidabili saranno i dati. Inoltre, più nodi ci sono, minore è la probabilità che i dati vengano persi. Questo punto può anche essere paragonato ai server centralizzati che archiviano i giochi Web2, una volta che tutti i server in background vengono spenti, ci sarà una chiusura completa del servizio. Ma non è meglio con più ridondanza, perché la ridondanza porterà ulteriore spazio di archiviazione, che porterà troppa pressione di archiviazione al sistema. Un buon livello DA dovrebbe scegliere un modo di ridondanza adatto per trovare un equilibrio tra sicurezza ed efficienza di archiviazione.

  • Controllo della disponibilità dei dati: la quantità di ridondanza può garantire sufficienti registrazioni di dati nella rete, ma i dati da utilizzare devono essere controllati per accuratezza e completezza. Le attuali blockchain utilizzano comunemente algoritmi di impegno crittografico come metodi di verifica, che mantengono solo un piccolo impegno crittografico ottenuto dalla miscelazione dei dati delle transazioni, affinché l'intera rete possa registrarlo. Per testare l'autenticità dei dati storici, dovremmo provare a recuperare l'impegno con i dati. Se l'impegno di recupero è identico all'impegno originale, la verifica passa. Gli algoritmi di verifica crittografica comunemente utilizzati sono Merkle Root e Verkle Root. Gli algoritmi di verifica della disponibilità dei dati ad alta sicurezza possono verificare rapidamente i dati storici con l'aiuto del minor numero possibile di dati di terze parti.

2.2 Costi di stoccaggio

Dopo aver garantito la sicurezza di base, l'obiettivo successivo del livello DA è ridurre i costi e aumentare l'efficienza. Il primo passo è ridurre il costo di archiviazione presentato dal consumo di memoria causato dall'archiviazione dei dati per unità di dimensione, indipendentemente dalla differenza nelle prestazioni hardware. Oggigiorno, i modi principali per ridurre i costi di archiviazione nella blockchain sono adottare la tecnologia di sharding e utilizzare l'archiviazione di ricompensa per ridurre il numero di backup dei dati mantenendone la sicurezza. Tuttavia, non è difficile vedere dai metodi di miglioramento di cui sopra che esiste una relazione di gioco tra costo di archiviazione e sicurezza dei dati e che la riduzione dell'occupazione dell'archiviazione spesso significa una diminuzione della sicurezza. Pertanto, un eccellente livello DA deve realizzare l'equilibrio tra costo di archiviazione e sicurezza dei dati. Inoltre, se il livello DA è una catena pubblica separata, deve anche ridurre i costi riducendo al minimo il processo intermedio di scambio di dati, in cui ogni processo di transito deve lasciare dati di indice per il successivo recupero. Quindi, più lungo è il processo di chiamata, più dati di indice saranno lasciati, il che aumenterà il costo di archiviazione. Infine, il costo di archiviazione dei dati è direttamente collegato alla persistenza dei dati. In generale, più alto è il costo dell'archiviazione dei dati, più difficile è per la catena pubblica archiviare i dati in modo persistente.

2.3 Velocità di lettura dei dati

Dopo aver ottenuto la riduzione dei costi, il passo successivo è l'efficienza, ovvero la capacità di richiamare rapidamente i dati dal livello DA quando necessario. Questo processo prevede due passaggi, il primo è la ricerca di nodi in cui archiviare i dati, principalmente per le catene pubbliche che non hanno raggiunto la coerenza dei dati in tutta la rete, se la catena pubblica ha raggiunto la sincronizzazione dei dati dei nodi in tutta la rete, il consumo di tempo di questo processo può essere ignorato. Quindi, nei sistemi blockchain mainstream in questa fase, inclusi Bitcoin, Ethereum e Filecoin, il metodo di archiviazione dei nodi è tutto il database Leveldb. In Leveldb, i dati vengono archiviati in tre modi. Innanzitutto, i dati scritti al volo vengono archiviati in file di tipo Memtable finché Memtable non è pieno, quindi il tipo di file viene modificato da Memtable a Immutable Memtable. Entrambi i due tipi vengono archiviati nella memoria, ma i file Immutable Memtable sono di sola lettura. L'archiviazione a caldo utilizzata nella rete IPFS memorizza i dati in questa parte della rete, in modo che possano essere letti rapidamente dalla memoria quando viene chiamata, ma un nodo medio ha solo GB di memoria rimovibile, che può essere facilmente rallentata e quando un nodo si arresta, i dati in memoria vengono persi in modo permanente. Se si desidera un'archiviazione dati persistente, è necessario memorizzare i dati sotto forma di file SST sul disco a stato solido (SSD), ma quando si leggono i dati, è necessario leggere prima i dati nella memoria, il che riduce notevolmente la velocità di indicizzazione dei dati. Infine, per un sistema con sharding dell'archiviazione, il ripristino dei dati richiede l'invio di richieste di dati a più nodi e il loro ripristino, un processo che rallenta anche la lettura dei dati.

Fonte: Leveldb-handbook

2.4 Generalizzazione del livello DA

Con lo sviluppo di DeFi e vari problemi di CEX, i requisiti degli utenti per le transazioni cross-chain di asset decentralizzati stanno crescendo. Sia che adottiamo il meccanismo cross-chain di hash-locking, notary o relay chain, non possiamo evitare la determinazione simultanea di dati storici su due catene. La chiave di questo problema risiede nella separazione dei dati sulle due catene, che non possono essere comunicati direttamente in diversi sistemi decentralizzati. Pertanto, viene proposta una soluzione modificando il metodo di archiviazione del livello DA, che archivia i dati storici di più catene pubbliche sulla stessa catena pubblica attendibile e deve solo chiamare i dati su questa catena pubblica durante la verifica. Ciò richiede che il livello DA sia in grado di stabilire una comunicazione sicura con diversi tipi di catene pubbliche, il che significa che il livello DA ha una buona versatilità.

3. Tecniche relative alla DA

3.1 Frammentazione

Nei sistemi distribuiti tradizionali, un file non viene archiviato in forma completa su un nodo, ma per dividere i dati originali in più blocchi e archiviarli in ciascun nodo. Inoltre, il blocco spesso non viene archiviato solo in un nodo, ma lascia un backup appropriato in altri nodi. Nei sistemi distribuiti tradizionali esistenti, il numero di backup è solitamente impostato su 2. Questo meccanismo di sharding può ridurre la pressione di archiviazione dei singoli nodi, espandere la capacità totale del sistema alla somma della capacità di archiviazione di ciascun nodo e allo stesso tempo garantire la sicurezza dell'archiviazione tramite un'adeguata ridondanza dei dati. Lo schema di sharding adottato nella blockchain è generalmente simile ai sistemi distribuiti tradizionali, ma ci sono differenze in alcuni dettagli. In primo luogo, poiché i nodi predefiniti nella blockchain non sono affidabili, il processo di realizzazione dello sharding richiede una quantità sufficientemente grande di backup dei dati per il successivo giudizio di autenticità dei dati, quindi il numero di backup di questo nodo deve essere molto più di 2. Idealmente, nel sistema blockchain che adotta questo schema di archiviazione, se il numero totale di nodi di autenticazione è T e il numero di shard è N, il numero di backup dovrebbe essere T/N. In secondo luogo, per quanto riguarda il processo di archiviazione di un blocco, un sistema distribuito tradizionale con meno nodi ha spesso la modalità in cui un nodo si adatta a più blocchi di dati. In primo luogo, i dati vengono mappati sull'hash ring dall'algoritmo hash coerente, quindi ogni nodo archivia un certo intervallo di blocchi numerati con le assegnazioni dell'hash ring. Nel sistema può essere accettato che un singolo nodo non abbia un'attività di archiviazione in un determinato archivio. Mentre sulla blockchain, il blocco di archiviazione non è più un evento casuale ma inevitabile per i nodi. Ogni nodo selezionerà casualmente un blocco per l'archiviazione nella blockchain, con il processo completato dal risultato dell'hashing dei dati mescolati con le informazioni del nodo per modulo numero di slice. Supponendo che ogni dato sia diviso in N blocchi, la dimensione effettiva dell'archiviazione di ogni nodo è solo 1/N.Impostando N in modo appropriato, possiamo raggiungere un equilibrio tra la crescita di TPS e la pressione sullo storage dei nodi.

Fonte: Kernel Ventures

3.2 DAS (campionamento della disponibilità dei dati)

La tecnologia DAS è un'ulteriore ottimizzazione del metodo di archiviazione basato sullo sharding. Nel processo di sharding, a causa della semplice archiviazione casuale dei nodi, potrebbe verificarsi una perdita di blocchi. In secondo luogo, per i dati dopo lo sharding, è molto importante anche come confermare l'autenticità e l'integrità dei dati durante il processo di ripristino. In DAS, questi due problemi sono risolti dal codice Eraser e dall'impegno polinomiale KZG.

  • Codice Eraser: dato il gran numero di nodi verificati in Ethereum, è possibile che un blocco non venga archiviato da nessun nodo, nonostante si tratti di un evento di probabilità. Per mitigare la minaccia di archiviazione mancante, invece di suddividere e tagliare a cubetti i dati grezzi in blocchi, questo schema mappa i dati grezzi sui coefficienti di un polinomio di grado n, quindi prende 2n punti sul polinomio e lascia che i nodi ne scelgano casualmente uno da archiviare. Per questo polinomio di grado n, sono necessari solo n+1 punti per la riduzione e quindi solo metà dei blocchi deve essere selezionata dai nodi per realizzare la riduzione dei dati originali. Il codice Eraser migliora la sicurezza dell'archiviazione dei dati e la capacità della rete di recuperare i dati.

  • Impegno polinomiale KZG: un aspetto molto importante dell'archiviazione dei dati è la verifica dell'autenticità dei dati. Nelle reti che non utilizzano il codice Eraser, possono essere utilizzati vari metodi per la verifica, ma se il codice Eraser sopra riportato viene introdotto per migliorare la sicurezza dei dati, allora è più appropriato utilizzare l'impegno polinomiale KZG, che può verificare il contenuto di un singolo blocco direttamente sotto forma di polinomio, eliminando così la necessità di ridurre il polinomio a dati binari. L'impegno polinomiale KZG può verificare direttamente il contenuto di un singolo blocco sotto forma di polinomi, eliminando così la necessità di ridurre i polinomi a dati binari, e la forma complessiva di verifica è simile a quella di Merkle Tree, ma non richiede dati specifici del nodo Path e richiede solo i dati KZG Root e del blocco per verificare l'autenticità del blocco.

3.3 Metodo di convalida dei dati in DA

La convalida dei dati assicura che i dati richiamati da un nodo siano accurati e completi. Per ridurre al minimo la quantità di dati e il costo computazionale richiesti nel processo di convalida, il livello DA ora utilizza una struttura ad albero come metodo di convalida principale. La forma più semplice è quella di utilizzare Merkle Tree per la verifica, che utilizza la forma di record di albero binario completi, è necessario solo mantenere una radice Merkle e il valore hash del sottoalbero sull'altro lato del percorso del nodo può essere verificato, la complessità temporale della verifica è di livello O(logN) (il logN è log2(N) predefinito). Sebbene il processo di convalida sia stato notevolmente semplificato, la quantità di dati per il processo di convalida in generale continua a crescere con l'aumento dei dati. Per risolvere il problema dell'aumento del volume di convalida, in questa fase viene proposto un altro metodo di convalida, Verkle Tree, in cui ogni nodo nel Verkle Tree non solo memorizza il valore, ma allega anche un Vector Commitment, che può convalidare rapidamente l'autenticità dei dati utilizzando il valore del nodo originale e la prova di impegno, senza la necessità di chiamare i valori di altri nodi fratelli, il che rende il calcolo di ogni convalida più semplice e veloce. Ciò rende il numero di calcoli per ogni verifica correlato solo alla profondità del Verkle Tree, che è una costante fissa, accelerando così notevolmente la velocità di verifica. Tuttavia, il calcolo del Vector Commitment richiede la partecipazione di tutti i nodi fratelli nello stesso livello, il che aumenta notevolmente il costo di scrittura e modifica dei dati. Tuttavia, per dati come i dati storici, che sono memorizzati in modo permanente e non possono essere manomessi, inoltre, possono essere solo letti ma non scritti, il Verkle Tree è estremamente adatto. Inoltre, Merkle Tree e Verkle Tree stessi hanno una forma K-aria di varianti, l'implementazione specifica del meccanismo è simile, basta cambiare il numero di sottoalberi sotto ogni nodo, il confronto delle prestazioni specifiche può essere visto nella tabella seguente.

Fonte: Verkle Alberi

3.4 Middleware DA generico

La continua espansione dell'ecosistema blockchain ha portato a un numero crescente di catene pubbliche. A causa dei vantaggi e dell'insostituibilità di ogni catena pubblica nei rispettivi campi, è impossibile che le catene pubbliche Layer1 diventino unificate in breve tempo. Tuttavia, con lo sviluppo di DeFi e i problemi di CEX, la domanda degli utenti di asset di trading cross-chain decentralizzati sta crescendo. Pertanto, l'archiviazione dati multi-chain del livello DA, che può eliminare i problemi di sicurezza nell'interazione dei dati cross-chain, ha guadagnato sempre più attenzione. Tuttavia, per accettare dati storici da diverse catene pubbliche, è necessario che il livello DA fornisca protocolli decentralizzati per l'archiviazione standardizzata e la convalida del flusso di dati. Ad esempio, kvye, un middleware di archiviazione basato su Arweave, adotta il metodo di scansione attiva dei dati dalle catene principali e può archiviare i dati da tutte le catene in una forma standardizzata su Arweave per ridurre al minimo le differenze nel processo di trasmissione dei dati. Comparativamente parlando, Layer2, che è specializzato nel fornire storage di dati di livello DA per una determinata catena pubblica, esegue l'interazione dei dati tramite nodi condivisi interni. Sebbene riduca il costo dell'interazione e migliori la sicurezza, ha maggiori limitazioni e può fornire servizi solo a catene pubbliche specifiche.

4. Metodi di conservazione di DA

4.1 Catena principale DA

4.1.1 Simile a DankSharding

Non esiste un nome definitivo per questo tipo di schema di archiviazione, ma il più importante è Dank Sharding su Ethereum, quindi in questo articolo utilizziamo il termine simile a Dank Sharding per riferirci a questo tipo di schema. Questo tipo di schema utilizza principalmente le due tecniche di archiviazione DA menzionate sopra, sharding e DAS, in primo luogo, i dati vengono suddivisi in un numero appropriato di condivisioni tramite sharding, quindi ogni nodo estrae un blocco di dati sotto forma di DAS per l'archiviazione. Nel caso in cui ci siano abbastanza nodi nell'intera rete, possiamo prendere un numero maggiore di slice N, in modo che la pressione di archiviazione di ogni nodo sia solo 1/N dell'originale, realizzando così un'espansione N-fold dello spazio di archiviazione complessivo. Allo stesso tempo, per evitare il caso estremo in cui un blocco non venga archiviato da nessun blocco, Dank Sharding codifica i dati utilizzando Eraser Code, che richiede solo metà dei dati per il ripristino completo. Infine, i dati vengono verificati utilizzando una struttura Verkle Tree con impegni polinomiali per checksum rapidi.

4.1.2 Archiviazione temporanea

Per il DA della catena principale, uno dei modi più semplici per gestire i dati è quello di archiviare i dati storici per un breve periodo di tempo. In sostanza, la blockchain funge da registro pubblico, in cui vengono apportate modifiche al contenuto del registro in presenza dell'intera rete, e non c'è bisogno di archiviazione permanente. Nel caso di Solana, ad esempio, sebbene i suoi dati storici siano sincronizzati con Arweave, i nodi della rete principale conservano solo i dati delle transazioni degli ultimi due giorni. Su una catena pubblica basata sui record degli account, ogni momento dei dati storici conserva lo stato finale dell'account sulla blockchain, il che è sufficiente per fornire una base per la verifica delle modifiche nel momento successivo. Coloro che hanno esigenze particolari di dati prima di questo momento, possono archiviarli su altre catene pubbliche decentralizzate o consegnarli a una terza parte fidata. In altre parole, coloro che hanno esigenze aggiuntive di dati dovranno pagare per l'archiviazione dei dati storici.

4.2 DA di terze parti

4.2.1 DA per la catena principale: EthStorage

  • DA per Main Chain: la cosa più importante per il livello DA è la sicurezza della trasmissione dei dati e il DA con la massima sicurezza è il DA della main chain, ma l'archiviazione della main chain è limitata dallo spazio di archiviazione e dalla competizione delle risorse, quindi quando il volume dei dati della rete cresce rapidamente, il DA di terze parti è una scelta migliore se si desidera realizzare l'archiviazione a lungo termine dei dati. Se il DA di terze parti ha una maggiore compatibilità con la rete principale, può realizzare la condivisione dei nodi e il processo di interazione dei dati avrà una maggiore sicurezza. Pertanto, in base alla premessa di considerare la sicurezza, un DA dedicato per la main chain avrà un enorme vantaggio. Prendendo Ethereum come esempio, uno dei requisiti di base per un DA dedicato alla main chain è che possa essere compatibile con EVM per garantire l'interoperabilità con i dati e i contratti di Ethereum e progetti rappresentativi includono Topia, EthStorage, ecc. Tra questi, EthStorage è il DA più compatibile in termini di compatibilità. Progetti rappresentativi includono Topia, EthStorage e così via. Tra questi, EthStorage è il più sviluppato in termini di compatibilità, perché oltre alla compatibilità con EVM, ha anche impostato interfacce pertinenti per interfacciarsi con Remix, Hardhat e altri strumenti di sviluppo Ethereum per realizzare la compatibilità con gli strumenti di sviluppo Ethereum.

  • EthStorage: EthStorage è una catena pubblica indipendente da Ethereum, ma i nodi in esecuzione su di essa sono un supergruppo di nodi Ethereum, il che significa che i nodi che eseguono EthStorage possono anche eseguire Ethereum contemporaneamente. Inoltre, possiamo anche gestire direttamente EthStorage tramite gli opcode su Ethereum. Il modello di archiviazione di EthStorage conserva solo una piccola quantità di metadati per l'indicizzazione sulla rete Ethereum principale, creando essenzialmente un database decentralizzato per Ethereum. Nella soluzione attuale, EthStorage distribuisce un contratto EthStorage sull'Ethereum principale per realizzare l'interazione tra l'Ethereum principale ed EthStorage. Se Ethereum vuole depositare dati, deve chiamare la funzione put() nel contratto e i parametri di input sono variabili a due byte key, data, dove data rappresenta i dati da depositare e key è la sua identità nella rete Ethereum, che può essere considerata simile all'esistenza di CID in IPFS. Dopo che la coppia di dati (key, data) è stata archiviata correttamente nella rete EthStorage, EthStorage genererà un kvldx da restituire alla rete host Ethereum, che corrisponde alla chiave sulla rete Ethereum e questo valore corrisponde all'indirizzo di archiviazione dei dati su EthStorage in modo che il problema originale di archiviare una grande quantità di dati possa ora essere modificato nell'archiviazione di una singola coppia (key, kvldx). (key, kvldx), il che riduce notevolmente i costi di archiviazione della rete Ethereum principale. Se è necessario richiamare i dati memorizzati in precedenza, è necessario utilizzare la funzione get() in EthStorage e immettere il parametro chiave, dopodiché è possibile effettuare una rapida ricerca dei dati su EthStorage utilizzando il kvldx memorizzato in Ethereum.

Fonte: Kernel Ventures

  • In termini di come i nodi archiviano i dati, EthStorage impara dal modello Arweave. Innanzitutto, un gran numero di coppie (k,v) da ETH vengono suddivise in shard e ogni sharding contiene un numero fisso di coppie (k, v), di cui c'è un limite alla dimensione di ogni coppia (k, v) per garantire l'equità del carico di lavoro nel processo di archiviazione delle ricompense per i minatori. Per l'emissione delle ricompense, è necessario verificare se il nodo archivia i dati per iniziare. In questo processo, EthStorage dividerà uno sharding (dimensione TB) in molti blocchi e manterrà una radice Merkle sulla mainnet di Ethereum per la verifica. Quindi il miner deve fornire un nonce per generare alcuni blocchi tramite un algoritmo casuale con l'hash del blocco precedente su EthStorage, e il miner deve fornire i dati di questi blocchi per dimostrare di aver archiviato l'intero sharding, ma questo nonce non può essere scelto arbitrariamente, altrimenti il ​​nodo sceglierà il nonce appropriato corrispondente ai blocchi da lui archiviati e supererà la verifica. Tuttavia, questo nonce non può essere scelto casualmente, altrimenti il ​​nodo sceglierà un nonce adatto che corrisponda solo ai suoi blocchi archiviati e supererà quindi la verifica, quindi questo nonce deve creare i blocchi generati dopo la miscelazione e l'hashing in modo che il valore di difficoltà soddisfi i requisiti della rete e solo il primo nodo che invia il nonce e la prova di accesso casuale può ottenere la ricompensa.

4.2.2 Modularizzazione DA: Celsetia

  • Modulo Blockchain: le transazioni da eseguire sulla catena pubblica Layer1 sono divise nelle seguenti quattro parti: (1) progettazione della logica sottostante della rete, selezione dei nodi di convalida in un certo modo, scrittura dei blocchi e assegnazione delle ricompense per i manutentori della rete; (2) confezionamento ed elaborazione delle transazioni e pubblicazione delle transazioni correlate; (3) convalida delle transazioni da caricare sulla blockchain e determinazione dello stato finale; (4) archiviazione e mantenimento dei dati storici sulla blockchain. In base alle diverse funzioni eseguite, possiamo dividere la blockchain in quattro moduli, livello di consenso, livello di esecuzione, livello di regolamento e livello di disponibilità dei dati (livello DA).

  • Design Blockchain modulare: per molto tempo, questi quattro moduli sono stati integrati in un'unica catena pubblica, una tale blockchain è chiamata blockchain monolitica. Questa forma è più stabile e più facile da mantenere, ma esercita anche una pressione enorme sulla singola catena pubblica. In pratica, i quattro moduli si limitano a vicenda e competono per le limitate risorse di elaborazione e archiviazione della catena pubblica. Ad esempio, aumentare la velocità di elaborazione del livello di elaborazione porterà una maggiore pressione di archiviazione al livello di disponibilità dei dati; garantire la sicurezza del livello di esecuzione richiede un meccanismo di verifica più complesso ma rallenta la velocità di elaborazione delle transazioni. Pertanto, lo sviluppo di una catena pubblica spesso affronta un compromesso tra questi quattro moduli. Per superare questo collo di bottiglia del miglioramento delle prestazioni della catena pubblica, gli sviluppatori hanno proposto una soluzione blockchain modulare. L'idea centrale della blockchain modulare è quella di eliminare uno o più dei quattro moduli sopra menzionati e darli a una catena pubblica separata per l'implementazione. In questo modo, la catena pubblica può concentrarsi sul miglioramento della velocità delle transazioni o della capacità di archiviazione, superando le precedenti limitazioni sulle prestazioni complessive della blockchain dovute all'effetto short board.

  • DA modulare: l'approccio complesso di separare il livello DA dal business blockchain e posizionarlo su una catena pubblica separata è considerato una soluzione praticabile per i crescenti dati storici di Layer1. In questa fase, l'esplorazione in quest'area è ancora in una fase iniziale e il progetto più rappresentativo è Celestia, che utilizza il metodo di archiviazione di Sharding, che divide anche i dati in più blocchi e ogni nodo ne estrae una parte per l'archiviazione e utilizza l'impegno polinomiale KZG per verificare l'integrità dei dati. Allo stesso tempo, Celestia utilizza codici correttivi RS bidimensionali avanzati per riscrivere i dati originali sotto forma di una matrice k*k, che alla fine richiede solo il recupero del 25% dei dati originali. Tuttavia, l'archiviazione dei dati suddivisi sostanzialmente moltiplica semplicemente la pressione di archiviazione dei nodi sulla rete per un fattore del volume totale dei dati e la pressione di archiviazione dei nodi continua a crescere linearmente con il volume dei dati. Man mano che Layer1 continua a migliorare per la velocità delle transazioni, la pressione di archiviazione sui nodi potrebbe ancora raggiungere una soglia inaccettabile un giorno. Per risolvere questo problema, in Celestia viene introdotto un componente IPLD. Invece di memorizzare i dati nella matrice k*k direttamente su Celestia, i dati vengono memorizzati nella rete LL-IPFS, con solo il codice CID dei dati mantenuto nel nodo. Quando un utente richiede un pezzo di dati storici, il nodo invia il CID corrispondente al componente IPLD, che viene utilizzato per chiamare i dati originali su IPFS. Se i dati esistono su IPFS, vengono restituiti tramite il componente IPLD e il nodo. Se non esistono, i dati non possono essere restituiti.

Fonte: Celestia Core

  • Celestia: Prendendo Celestia come esempio, possiamo vedere l'applicazione della blockchain modulare nella risoluzione del problema di archiviazione di Ethereum, il nodo Rollup invierà i dati delle transazioni confezionati e verificati a Celestia e memorizzerà i dati su Celestia, durante il processo, Celestia memorizza solo i dati senza avere troppa percezione. In questo processo, Celestia memorizza solo i dati senza rilevarli e alla fine, in base alle dimensioni dello spazio di archiviazione, il nodo Rollup pagherà i token tia corrispondenti a Celestia come commissione di archiviazione. L'archiviazione in Celestia utilizza un DAS e un codice di debug simili a quelli di EIP4844, ma il codice di debug polinomiale in EIP4844 viene aggiornato per utilizzare un codice di debug RS bidimensionale, che aggiorna nuovamente la sicurezza dell'archiviazione e solo il 25% delle frazioni è necessario per recuperare tutti i dati della transazione. Si tratta essenzialmente di una catena pubblica POS con bassi costi di archiviazione e, se deve essere realizzata come soluzione al problema di archiviazione dei dati storici di Ethereum, sono necessari molti altri moduli specifici per lavorare con Celestia. Ad esempio, in termini di rollup, uno dei modelli di rollup altamente raccomandati dal sito Web ufficiale di Celestia è Sovereign Rollup, che è diverso dal comune rollup su Layer2, che può solo calcolare e verificare le transazioni, completando solo il livello di esecuzione e include l'intero processo di esecuzione e regolamento, il che riduce al minimo la necessità del processo di esecuzione e regolamento su Celestia. Ciò riduce al minimo l'elaborazione delle transazioni su Celestia, il che massimizza la sicurezza complessiva del processo di transazione quando la sicurezza complessiva di Celestia è più debole di quella di Ethereum. Per quanto riguarda la sicurezza dei dati chiamati da Celestia sulla rete principale di Ethereum, la soluzione più diffusa è lo smart contract Quantum Gravity Bridge. Per i dati archiviati su Celestia, verrà generato un Merkle Root (certificato di disponibilità dei dati) e lo conserverà nel contratto Quantum Gravity Bridge sulla rete principale di EtherCenter.Ogni volta che EtherCenter richiama i dati storici su Celestia, confronta il risultato hash con la Merkle Root e, se corrisponde, significa che si tratta effettivamente di dati storici reali.

4.2.3 Catena di Stoccaggio DA

In termini di principi tecnici delle DA mainchain, molte tecniche simili allo sharding sono state prese in prestito dalle catene pubbliche di storage. Nelle DA di terze parti, alcune di esse svolgono persino parte delle attività di storage direttamente con l'aiuto delle catene pubbliche di storage, ad esempio, i dati specifici delle transazioni in Celestia vengono inseriti nella rete LL-IPFS. Nelle soluzioni delle DA di terze parti, oltre a creare una catena pubblica separata per risolvere il problema di storage di Layer1, un modo più diretto è quello di collegare direttamente la catena pubblica di storage a Layer1 per archiviare gli enormi dati storici su Layer1. Per la blockchain ad alte prestazioni, il volume di dati storici è ancora maggiore, in condizioni di funzionamento a piena velocità, il volume di dati della catena pubblica ad alte prestazioni Solana è vicino a 4 PG, che è completamente al di là dell'intervallo di storage dei nodi ordinari. Solana sceglie una soluzione per archiviare i dati storici sulla rete di storage decentralizzata Arweave e conserva solo 2 giorni di dati sui nodi della rete principale per la verifica. Per garantire la sicurezza del processo di archiviazione, Solana e la catena Arweave hanno progettato un protocollo di storage bridge, Solar Bridge, che sincronizza i dati convalidati dai nodi Solana ad Arweave e restituisce il tag corrispondente, che consente ai nodi Solana di visualizzare i dati storici della blockchain Solana in qualsiasi momento. Il nodo Solana può visualizzare i dati storici da qualsiasi momento sulla blockchain Solana. Su Arweave, invece di richiedere ai nodi della rete di mantenere la coerenza dei dati come una necessità per la partecipazione, la rete adotta un approccio di archiviazione di ricompensa. Innanzitutto, Arweave non utilizza una struttura a catena tradizionale per creare blocchi, ma più una struttura a grafico. In Arweave, un nuovo blocco non solo punterà al blocco precedente, ma punterà anche casualmente a un blocco Recall generato, la cui posizione esatta è determinata dal risultato hash del blocco precedente e dalla sua altezza di blocco, e la posizione del blocco Recall è sconosciuta fino a quando il blocco precedente non viene estratto.Tuttavia, nel processo di generazione di nuovi blocchi, i nodi devono avere i dati del blocco Recall per utilizzare il meccanismo POW per calcolare l'hash della difficoltà specificata e solo il miner che è il primo a calcolare l'hash che soddisfa la difficoltà può essere premiato, il che incoraggia i miner a memorizzare quanti più dati storici possibili. Allo stesso tempo, meno persone memorizzano un particolare blocco storico, meno concorrenti avrà un nodo quando genera un nonce conforme alla difficoltà, incoraggiando i miner a memorizzare blocchi con meno backup nella rete. Infine, per garantire che i nodi memorizzino i dati in modo permanente, il meccanismo di punteggio dei nodi di WildFire è introdotto in Arweave. I nodi preferiranno comunicare con nodi che possono fornire dati storici in modo più rapido e di più, mentre i nodi con valutazioni inferiori non saranno in grado di ottenere i dati più recenti sui blocchi e sulle transazioni la prima volta, non riuscendo così a ottenere un vantaggio nella competizione POW.

Fonte: Arweave Yellow-Paper

5. Confronto sintetizzato

Confronteremo i vantaggi e gli svantaggi di ciascuna delle cinque soluzioni di storage in termini di quattro dimensioni delle metriche delle prestazioni DA.

  • Sicurezza: la principale fonte di problemi di sicurezza dei dati è la perdita di dati causata dal processo di trasmissione dati e manomissioni dannose da nodi disonesti, e il processo cross-chain è l'area più colpita della sicurezza della trasmissione dati a causa dell'indipendenza delle due catene pubbliche e lo stato non è condiviso. Inoltre, Layer1, che richiede un livello DA specializzato in questa fase, ha spesso un forte gruppo di consenso e la sua sicurezza sarà molto più elevata di quella delle normali catene pubbliche di archiviazione. Pertanto, la soluzione DA della catena principale ha una sicurezza maggiore. Dopo aver garantito la sicurezza della trasmissione dati, il passo successivo è garantire la sicurezza dei dati di chiamata. Considerando solo i dati storici a breve termine utilizzati per verificare la transazione, gli stessi dati vengono sottoposti a backup dall'intera rete nella rete di archiviazione temporanea, mentre il numero medio di backup dei dati nello schema simile a DankSharding è solo 1/N del numero di nodi nell'intera rete, il che significa che una maggiore ridondanza dei dati può rendere i dati meno inclini alla perdita e, allo stesso tempo, può fornire più campioni di riferimento per la verifica. Pertanto, l'archiviazione temporanea avrà una maggiore sicurezza dei dati. Nello schema DA di terze parti, a causa dei nodi pubblici utilizzati nella catena principale, i dati possono essere trasmessi direttamente tramite questi nodi relay nel processo di cross-chaining e quindi avrà anche una sicurezza relativamente più elevata rispetto ad altri schemi DA.

  • Costo di archiviazione: il fattore che ha il maggiore impatto sul costo di archiviazione è la quantità di ridondanza nei dati. Nello schema di archiviazione a breve termine della DA della catena principale, che utilizza la forma di sincronizzazione dei dati dei nodi di rete per l'archiviazione, tutti i dati appena archiviati devono essere sottoposti a backup nei nodi di rete, con il costo di archiviazione più elevato. L'elevato costo di archiviazione a sua volta determina che in una rete TPS elevata, questo approccio è adatto solo per l'archiviazione temporanea. Il successivo è il metodo di archiviazione sharding, che include lo sharding nella catena principale e lo sharding nella DA di terze parti. Poiché la catena principale ha spesso più nodi e quindi il blocco corrispondente avrà più backup, lo schema di sharding della catena principale avrà un costo più elevato. Il costo di archiviazione più basso è nella DA della catena pubblica di archiviazione che adotta il metodo di archiviazione di ricompensa e la quantità di ridondanza dei dati in questo schema tende a fluttuare attorno a una costante fissa. Allo stesso tempo, la catena pubblica di archiviazione DA introduce anche un meccanismo di adeguamento dinamico, che induce i nodi ad archiviare meno dati di backup aumentando la ricompensa per garantire la sicurezza dei dati.

  • Velocità di lettura dei dati: la velocità di archiviazione dei dati è influenzata principalmente da dove i dati sono archiviati nello spazio di archiviazione, dal percorso dell'indice dei dati e dalla distribuzione dei dati tra i nodi. Tra questi, dove i dati sono archiviati nei nodi ha un impatto maggiore sulla velocità, perché l'archiviazione dei dati in memoria o SSD può portare a una differenza di decine di volte nella velocità di lettura. I DA della catena pubblica di archiviazione utilizzano principalmente l'archiviazione SSD perché il carico su quella catena include non solo i dati dal livello DA ma anche dati personali altamente affamati di memoria come video e immagini caricati dagli utenti. Se la rete non utilizza SSD come spazio di archiviazione, è difficile sopportare l'enorme pressione di archiviazione e soddisfare la domanda di archiviazione a lungo termine. In secondo luogo, per i DA di terze parti e i DA della catena principale che utilizzano lo stato della memoria per archiviare i dati, i DA di terze parti devono prima cercare i dati indicizzati corrispondenti nella catena principale, quindi trasferire i dati indicizzati attraverso la catena ai DA di terze parti e restituire i dati tramite il bridge di archiviazione. Al contrario, la DA mainchain può interrogare i dati direttamente dai nodi e quindi ha una velocità di recupero dati più rapida. Infine, all'interno della DA mainchain, l'approccio di sharding richiede di chiamare blocchi da più nodi e ripristinare i dati originali. Pertanto, è più lento del metodo di archiviazione a breve termine senza sharding.

  • Universalità del livello DA: l'universalità della DA della mainchain è prossima allo zero perché non è possibile trasferire dati da una catena pubblica con spazio di archiviazione insufficiente a un'altra catena pubblica con spazio di archiviazione insufficiente. Nelle DA di terze parti, la generalità di una soluzione e la sua compatibilità con una particolare mainchain sono metriche contraddittorie. Ad esempio, nel caso di una soluzione DA specifica della mainchain progettata per una particolare mainchain, ha apportato molti miglioramenti a livello di tipi di nodi e consenso di rete per adattarsi a quella particolare catena pubblica, e quindi questi miglioramenti possono agire come un enorme ostacolo quando si comunica con altre catene pubbliche. Nelle DA di terze parti, le DA della catena pubblica di archiviazione hanno prestazioni migliori in termini di generalizzabilità rispetto alle DA modulari. Le DA della catena pubblica di archiviazione hanno una comunità di sviluppatori più ampia e più strutture di espansione per adattarsi a diverse catene pubbliche. Allo stesso tempo, la DA della catena pubblica di archiviazione può ottenere dati in modo più attivo tramite l'acquisizione di pacchetti piuttosto che ricevere passivamente le informazioni trasmesse da altre catene pubbliche. Pertanto, può codificare i dati a suo modo, ottenere un'archiviazione standardizzata del flusso di dati, facilitare la gestione delle informazioni sui dati provenienti da diverse catene principali e migliorare l'efficienza di archiviazione.

Fonte: Kernel Ventures

6. Conclusion

Blockchain sta attraversando il processo di conversione da Crypto a Web3 e porta con sé un'abbondanza di progetti sulla blockchain, ma anche problemi di archiviazione dei dati. Per accogliere il funzionamento simultaneo di così tanti progetti su Layer1 e garantire l'esperienza dei progetti Gamefi e Socialfi, Layer1 rappresentato da Ethereum ha adottato Rollup e Blobs per migliorare il TPS. Inoltre, anche il numero di blockchain ad alte prestazioni nella neonata blockchain sta crescendo. Ma un TPS più elevato non significa solo prestazioni più elevate, ma anche una maggiore pressione di archiviazione nella rete. Per l'enorme quantità di dati storici, in questa fase vengono proposti più approcci DA, sia basati sulla catena principale che su terze parti, per adattarsi alla crescita della pressione di archiviazione sulla catena. I miglioramenti hanno i loro vantaggi e svantaggi e hanno una diversa applicabilità in contesti diversi. Nel caso di blockchain basate sui pagamenti, che hanno requisiti molto elevati per la sicurezza dei dati storici e non perseguono TPS particolarmente elevati, sono ancora nella fase preparatoria, possono adottare un metodo di archiviazione simile a DankSharding, che può garantire sicurezza e un enorme aumento della capacità di archiviazione allo stesso tempo. Tuttavia, se si tratta di una catena pubblica come Bitcoin, che è già stata formata e ha un gran numero di nodi, c'è un enorme rischio di migliorare avventatamente il livello di consenso, quindi può adottare un DA speciale per la catena principale con maggiore sicurezza nell'archiviazione off-chain per bilanciare i problemi di sicurezza e archiviazione. Tuttavia, vale la pena notare che la funzione della blockchain sta cambiando nel tempo. Ad esempio, nei primi giorni, la funzionalità di Ethereum era limitata ai pagamenti e alla semplice elaborazione automatizzata di asset e transazioni tramite contratti intelligenti, ma con l'espansione del panorama blockchain, vari progetti Socialfi e Defi sono stati aggiunti a Ethereum, spingendolo verso una direzione più completa. Con la recente esplosione dell'ecosistema di iscrizione su Bitcoin, le commissioni di transazione sulla rete Bitcoin sono aumentate di quasi 20 volte da agosto, a dimostrazione del fatto che le velocità di transazione della rete non sono in grado di soddisfare la domanda di transazioni in questa fase.I trader devono aumentare le commissioni per far sì che le transazioni vengano elaborate il più rapidamente possibile. Ora, la comunità Bitcoin deve fare un compromesso tra accettare commissioni elevate e velocità di transazione lenta o ridurre la sicurezza della rete per aumentare la velocità delle transazioni, vanificando al contempo lo scopo del sistema di pagamento in primo luogo. Se la comunità Bitcoin sceglie quest'ultima, allora la soluzione di archiviazione dovrà essere adeguata di fronte alla crescente pressione dei dati.

Fonte: OKLINK

Per quanto riguarda la catena pubblica con funzioni complete, la sua ricerca di TPS è più elevata, con l'enorme crescita dei dati storici, è difficile adattarsi alla rapida crescita di TPS a lungo termine adottando la soluzione simile a DankSharding. Pertanto, un modo più appropriato è migrare i dati su un DA di terze parti per l'archiviazione. Tra questi, i DA specifici della catena principale hanno la massima compatibilità e possono essere più vantaggiosi se si considera solo l'archiviazione di una singola catena pubblica. Tuttavia, al giorno d'oggi, quando le catene pubbliche Layer1 stanno fiorendo, anche il trasferimento di asset tra catene e l'interazione dei dati sono diventati una ricerca comune della comunità blockchain. Se consideriamo lo sviluppo a lungo termine dell'intero ecosistema blockchain, l'archiviazione di dati storici da diverse catene pubbliche sulla stessa catena pubblica può eliminare molti problemi di sicurezza nel processo di scambio e convalida dei dati, quindi il DA modularizzato e il modo di archiviare i DA della catena pubblica potrebbero essere una scelta migliore. Sulla base della premessa di una generalità ravvicinata, la DA modulare si concentra sulla fornitura di servizi di livello DA blockchain, introduce dati di indice più raffinati per gestire i dati storici e può effettuare una categorizzazione ragionevole di diversi dati di catene pubbliche, il che presenta maggiori vantaggi rispetto alle catene pubbliche di archiviazione. Tuttavia, la proposta di cui sopra non considera il costo dell'adeguamento del livello di consenso sulla catena pubblica esistente, il che è estremamente rischioso. Una piccola scappatoia sistematica potrebbe far perdere il consenso della comunità alla catena pubblica. Pertanto, se si tratta di una soluzione transitoria nel processo di trasformazione della blockchain, l'archiviazione temporanea sulla catena principale potrebbe essere più appropriata. Infine, tutte le discussioni di cui sopra si basano sulle prestazioni durante l'operazione effettiva, ma se l'obiettivo di una determinata catena pubblica è sviluppare la sua ecologia e attrarre più parti e partecipanti al progetto, potrebbe anche tendere a favorire progetti supportati e finanziati dalla sua fondazione. Ad esempio, se le prestazioni complessive sono uguali o anche leggermente inferiori a quelle della soluzione di storage della catena pubblica, la comunità Ethereum favorirà anche EthStorage, un progetto Layer2 supportato dalla Ethereum Foundation, per continuare a sviluppare l'ecosistema Ethereum.

Tutto sommato, la crescente complessità delle blockchain odierne comporta una maggiore necessità di spazio di archiviazione. Con un numero sufficiente di nodi di convalida Layer1, i dati storici non devono essere sottoposti a backup da tutti i nodi dell'intera rete, ma possono garantire la sicurezza oltre una certa soglia. Allo stesso tempo, la divisione del lavoro della catena pubblica è diventata sempre più dettagliata, Layer1 è responsabile del consenso e dell'esecuzione, Rollup è responsabile del calcolo e della verifica e quindi viene utilizzata una blockchain separata per l'archiviazione dei dati. Ogni parte può concentrarsi su una determinata funzione senza essere limitata dalle prestazioni delle altre parti. Tuttavia, il numero specifico di archiviazione o la proporzione di nodi autorizzati a memorizzare dati storici al fine di raggiungere un equilibrio tra sicurezza ed efficienza, nonché il modo per garantire un'interoperabilità sicura tra diverse blockchain è un problema che deve essere preso in considerazione dagli sviluppatori di blockchain. Gli investitori possono prestare attenzione al progetto DA principale specifico della catena su Ethereum, perché Ethereum ha già abbastanza sostenitori in questa fase, senza la necessità di utilizzare il potere di altre comunità per espandere la sua influenza. È più importante migliorare e sviluppare la sua comunità per attrarre più progetti nell'ecosistema Ethereum. Tuttavia, per le catene pubbliche che stanno recuperando terreno, come Solana e Aptos, la singola catena in sé non ha un ecosistema così perfetto, quindi potrebbero preferire unire le forze con altre comunità per costruire un grande ecosistema cross-chain per espandere la loro influenza. Pertanto, per l'emergente Layer1, una DA di terze parti di uso generale merita più attenzione.

Kernel Ventures è un fondo di VC crittografico guidato dalla comunità di ricerca e sviluppo con oltre 70 investimenti in fase iniziale, focalizzato su infrastrutture, middleware, dApp, in particolare ZK, Rollup, DEX, Blockchain modulare e verticali che accoglieranno il prossimo miliardo di utenti in criptovaluta come Account Abstraction, Data Availability, Scalability e così via. Negli ultimi sette anni, ci siamo impegnati a supportare la crescita delle principali comunità di sviluppo e delle associazioni universitarie di blockchain in tutto il mondo.

Riferimento

  1. Celestia: Il mare stellato della blockchain modulare: https://foresightnews.pro/article/detail/15497

  2. Utilizzo del DHT e lavori futuri: https://github.com/celestiaorg/celestia-node/issues/11

  3. Celestia-core: https://github.com/celestiaorg/celestia-core

  4. Laboratori Solana: https://github.com/solana-labs/solana?source=post_page-----cf47a61a9274----------------------- - -------

  5. Annuncio del ponte SOLAR: https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2

  6. manuale di leveldb: https://leveldb-handbook.readthedocs.io/zh/latest/sstable.html

  7. Kuszmaul J. Verkle alberi[J]. Verkle Trees, 2019, 1: 1.: https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

  8. Rete Arweave: https://www.arweave.org/

  9. Libro giallo di Arweave: https://www.arweave.org/yellow-paper.pdf