Autor: Kernel Ventures Jerry Luo

Editor(i): Kernel Ventures Rose, Kernel Ventures Mandy, Kernel Ventures Joshua

TLDR:

  1. În stadiul incipient al blockchain-ului, menținerea coerenței datelor este considerată extrem de importantă pentru a asigura securitatea și descentralizarea. Cu toate acestea, odată cu dezvoltarea ecosistemului blockchain, presiunea de stocare crește și ea, ceea ce duce la o tendință de centralizare în funcționarea nodurilor. Așa fiind, problema costului de stocare adusă de creșterea TPS în Layer1 trebuie rezolvată urgent.

  2. Confruntați cu această problemă, dezvoltatorii ar trebui să propună o soluție care să ia în considerare pe deplin securitatea, costul de stocare, viteza de citire a datelor și versatilitatea stratului DA.

  3. În procesul de rezolvare a acestei probleme, au apărut multe tehnologii și idei noi, inclusiv Sharding, DAS, Verkle Tree, componente intermediare DA și așa mai departe. Ei încearcă să optimizeze schema de stocare a stratului DA prin reducerea redundanței datelor și îmbunătățirea eficienței validării datelor.

  4. Soluțiile DA sunt clasificate în general în două tipuri din perspectiva locației de stocare a datelor, și anume, DA-uri de lanț principal și DA-uri terțe. DA-urile din lanțul principal sunt proiectate din perspectiva curățării periodice a datelor și a stocării de date segmentate pentru a reduce presiunea de stocare asupra nodurilor, în timp ce DA-urile terțe sunt proiectate pentru a satisface nevoile de stocare care au soluții rezonabile pentru cantități mari de date. Drept urmare, facem schimburi în principal între compatibilitatea cu un singur lanț și compatibilitatea cu mai multe lanțuri în DA-uri terțe și propunem trei tipuri de soluții: DA-uri specifice lanțului principal, DA-uri modulare și DA-uri de lanț public de stocare.

  5. Lanțurile publice de tip plată au cerințe foarte ridicate pentru securitatea datelor istorice și, prin urmare, sunt potrivite pentru a utiliza lanțul principal ca strat DA. Cu toate acestea, pentru lanțurile publice care funcționează de mult timp și au un număr mare de mineri care rulează rețeaua, este mai potrivit să se adopte un DA terță parte care să nu implice schimbarea stratului de consens cu securitate relativ ridicată. Pentru lanțurile publice cuprinzătoare, este mai potrivit să se utilizeze stocarea DA dedicată a lanțului principal cu capacitate de date mai mare, costuri mai mici și securitate. Cu toate acestea, având în vedere cererea de cross-chain, modular DA este, de asemenea, o opțiune bună.

  6. În general, blockchain se îndreaptă spre reducerea redundanței datelor, precum și diviziunea muncii în mai multe lanțuri.

1. Context

Blockchain, ca registru distribuit, trebuie să facă o copie a datelor istorice stocate pe toate nodurile pentru a se asigura că stocarea datelor este sigură și suficient de descentralizată. Deoarece corectitudinea fiecărei schimbări de stare este legată de starea anterioară (sursa tranzacției), pentru a asigura corectitudinea tranzacției, un blockchain ar trebui să stocheze tot istoricul tranzacțiilor de la generarea primei tranzacții până la cea curentă. tranzacţie. Luând Ethereum ca exemplu, chiar și luând 20 kb pe bloc ca dimensiune medie, dimensiunea totală a datelor curente din Ethereum a ajuns la 370 GB. Pentru un nod plin, pe lângă blocul în sine, trebuie să înregistreze starea și încasările tranzacției. Inclusiv această parte, cantitatea totală de stocare a unui singur nod a depășit 1 TB, ceea ce face ca funcționarea nodului să se centralizeze treptat.

Sursa: Etherscan

Actualizarea recentă a Ethereum din Cancun urmărește să crească TPS-ul Ethereum la aproape 1000, moment în care creșterea anuală a stocării Ethereum va depăși suma stocării sale actuale. În lanțurile publice de înaltă performanță, viteza tranzacției de zeci de mii de TPS poate aduce sute de GB de date suplimentare pe zi. Redundanța comună a datelor tuturor nodurilor din rețea, evident, nu se poate adapta la o astfel de presiune de stocare. Deci, Layer1 trebuie să găsească o soluție potrivită pentru a echilibra creșterea TPS și costul de stocare al nodurilor.

2. Indicatori de performanță ai DA

2.1 Siguranță

În comparație cu o bază de date sau cu o listă legată, imuabilitatea blockchain-ului provine din faptul că datele sale nou generate pot fi verificate prin date istorice, astfel asigurarea securității datelor sale istorice este prima problemă care trebuie luată în considerare în stocarea stratului DA. Pentru a judeca securitatea datelor sistemelor blockchain, analizăm adesea cantitatea redundantă de date și metoda de verificare a disponibilității datelor.

  • Număr de redundanță: redundanța datelor din sistemul blockchain joacă în principal astfel de roluri: în primul rând, mai multă redundanță în rețea poate oferi mai multe mostre de referință atunci când verificatorul trebuie să verifice starea contului, ceea ce poate ajuta nodul să selecteze datele înregistrate de către majoritatea nodurilor cu securitate mai mare. În bazele de date tradiționale, deoarece datele sunt stocate doar sub formă de perechi cheie-valoare într-un anumit nod, modificarea datelor istorice se realizează doar într-un singur nod, cu un cost scăzut al atacului și, teoretic, cu cât este mai mare. numărul de concedieri este, cu atât gradul de credibilitate al datelor este mai mare. Teoretic, cu cât există mai multă redundanță, cu atât datele vor fi mai demne de încredere. În plus, cu cât sunt mai multe noduri, cu atât este mai puțin probabil ca datele să se piardă. Acest punct poate fi comparat și cu serverele centralizate care stochează jocuri Web2, odată ce serverele de fundal sunt toate închise, va avea loc o închidere completă a serviciului. Dar nu este mai bine cu mai multă redundanță, deoarece redundanța va aduce spațiu suplimentar de stocare, ceea ce va aduce prea multă presiune de stocare în sistem. Un strat DA bun ar trebui să aleagă o modalitate adecvată de redundanță pentru a găsi un echilibru între securitate și eficiența stocării.

  • Verificarea disponibilității datelor: cantitatea de redundanță poate asigura suficiente înregistrări de date în rețea, dar datele care vor fi utilizate trebuie verificate pentru acuratețe și completitudine. Blockchain-urile actuale folosesc de obicei algoritmi de angajament criptografic ca metode de verificare, care păstrează doar un mic angajament criptografic obținut prin amestecarea datelor de tranzacție, pentru ca întreaga rețea să fie înregistrată. Pentru a testa autenticitatea datelor istorice, ar trebui să încercăm să recuperăm angajamentul cu datele. Dacă angajamentul de recuperare este identic cu angajamentul inițial, verificarea trece. Algoritmii de verificare criptografică folosiți în mod obișnuit sunt Merkle Root și Verkle Root. Algoritmii de verificare a disponibilității datelor de înaltă securitate pot verifica rapid datele istorice cu ajutorul cât mai puține date de la terți.

2.2 Costul de stocare

După asigurarea securității de bază, următorul obiectiv al stratului DA este reducerea costurilor și creșterea eficienței. Primul pas este reducerea costului de stocare prezentat de consumul de memorie cauzat de stocarea datelor pe dimensiunea unității, indiferent de diferența de performanță hardware. În zilele noastre, principalele modalități de a reduce costurile de stocare în blockchain sunt adoptarea tehnologiei sharding și utilizarea stocării recompense pentru a reduce numărul de copii de siguranță a datelor, păstrând în același timp securitatea. Cu toate acestea, nu este greu de observat din metodele de îmbunătățire de mai sus că există o relație de joc între costul de stocare și securitatea datelor, iar reducerea ocupării stocării înseamnă adesea o scădere a securității. Prin urmare, un strat DA excelent trebuie să realizeze echilibrul între costul de stocare și securitatea datelor. În plus, dacă stratul DA este un lanț public separat, acesta trebuie, de asemenea, să reducă costurile prin reducerea la minimum a procesului intermediar de schimb de date, în care fiecare proces de tranzit trebuie să lase date de index pentru recuperarea ulterioară. Deci, cu cât procesul de apelare este mai lung, cu atât vor rămâne mai multe date de index, ceea ce va crește costul de stocare. În cele din urmă, costul stocării datelor este direct legat de persistența datelor. În general, cu cât costul stocării datelor este mai mare, cu atât este mai dificil pentru lanțul public să stocheze datele în mod persistent.

2.3 Viteza de citire a datelor

După ce s-a realizat reducerea costurilor, următorul pas este eficiența, ceea ce înseamnă abilitatea de a retrage rapid datele din stratul DA atunci când este necesar. Acest proces implică doi pași, primul este căutarea nodurilor pentru stocarea datelor, în principal pentru lanțurile publice care nu au atins consistența datelor în rețea, dacă lanțul public a realizat sincronizarea datelor nodurilor din rețea, consumul de timp al acestui procesul poate fi ignorat. Apoi, în sistemele blockchain mainstream în această etapă, inclusiv Bitcoin, Ethereum și Filecoin, metoda de stocare a nodurilor este baza de date Leveldb. În Leveldb, datele sunt stocate în trei moduri. Mai întâi, datele scrise din mers sunt stocate în fișiere de tip Memtable până când Memtable este plin, apoi tipul de fișier este schimbat din Memtable în Immutable Memtable. Ambele două tipuri sunt stocate în memorie, dar fișierele Immutable Memtable sunt doar pentru citire. Stocarea la cald folosită în rețeaua IPFS stochează date în această parte a rețelei, astfel încât să poată fi citite rapid din memorie atunci când este apelată, dar un nod mediu are doar GB de memorie amovibilă, care poate fi ușor încetinită și când un nod scade, datele din memorie se pierd definitiv. Dacă doriți să stocați date persistente, trebuie să stocați datele sub formă de fișiere SST pe discul cu stare solidă (SSD), dar atunci când citiți datele, trebuie să citiți mai întâi datele în memorie, ceea ce reduce foarte mult viteza. de indexare a datelor. În cele din urmă, pentru un sistem cu fragmentare de stocare, restaurarea datelor necesită trimiterea cererilor de date către mai multe noduri și restaurarea acestora, proces care încetinește și citirea datelor.

Sursa: manualul Leveldb

2.4 Generalizarea stratului DA

Odată cu dezvoltarea DeFi și diversele probleme ale CEX, cerințele utilizatorilor pentru tranzacții încrucișate cu active descentralizate sunt în creștere. Indiferent dacă adoptăm mecanismul încrucișat de blocare hash, notar sau lanț releu, nu putem evita determinarea simultană a datelor istorice pe două lanțuri. Cheia acestei probleme constă în separarea datelor pe cele două lanțuri, care nu pot fi comunicate direct în diferite sisteme descentralizate. Prin urmare, se propune o soluție prin schimbarea metodei de stocare a stratului DA, care stochează datele istorice ale mai multor lanțuri publice pe același lanț public de încredere și trebuie doar să apeleze datele din acest lanț public atunci când verifică. Acest lucru necesită ca stratul DA să poată stabili o comunicare sigură cu diferite tipuri de lanțuri publice, ceea ce înseamnă că stratul DA are o bună versatilitate.

3. Tehnici privind DA

3.1 Sharding

În sistemele tradiționale distribuite, un fișier nu este stocat într-o formă completă pe un nod, ci pentru a împărți datele originale în mai multe blocuri și a le stoca în fiecare nod. De asemenea, blocul este adesea stocat nu numai într-un nod, dar lasă o copie de rezervă adecvată în alte noduri. În sistemele distribuite curente existente, numărul de copii de rezervă este de obicei setat la 2. Acest mecanism de fragmentare poate reduce presiunea de stocare a nodurilor individuale, poate extinde capacitatea totală a sistemului la suma capacității de stocare a fiecărui nod și la asigură în același timp securitatea stocării prin redundanță adecvată a datelor. Schema de fragmentare adoptată în blockchain este în general similară cu sistemele tradiționale distribuite, dar există diferențe în unele detalii. În primul rând, deoarece nodurile implicite din blockchain nu sunt demne de încredere, procesul de realizare a fragmentării necesită o cantitate suficient de mare de copii de siguranță ale datelor pentru evaluarea ulterioară a autenticității datelor, astfel încât numărul de copii de siguranță ale acestui nod trebuie să fie mult mai mare de 2. În mod ideal , în sistemul blockchain care adoptă această schemă de stocare, dacă numărul total de noduri de autentificare este T și numărul de fragmente este N, numărul de copii de siguranță ar trebui să fie T/N. În al doilea rând, în ceea ce privește procesul de stocare al unui bloc, un sistem tradițional distribuit cu mai puține noduri are adesea modul pe care un nod l-a adaptat la mai multe blocuri de date. În primul rând, datele sunt mapate la inelul hash de către algoritmul hash consistent, apoi fiecare nod stochează un anumit interval de blocuri numerotate cu atribuirile inelului hash. Se poate accepta în sistem că un singur nod nu are o sarcină de stocare într-un anumit stocare. În timp ce se află pe blockchain, blocul de stocare nu mai este un eveniment aleatoriu, ci inevitabil pentru noduri. Fiecare nod va selecta aleatoriu un bloc pentru stocare în blockchain, procesul fiind finalizat prin rezultatul hashing al datelor amestecat cu informațiile nodului la numărul secțiunii modulo. Presupunând că fiecare dată este împărțită în N blocuri, dimensiunea reală de stocare a fiecărui nod este doar 1/N. Setând N în mod corespunzător, putem obține un echilibru între creșterea TPS și presiunea asupra stocării nodurilor.

Sursa: Kernel Ventures

3.2 DAS (Eșantionarea disponibilității datelor)

Tehnologia DAS este o optimizare suplimentară a metodei de stocare bazată pe sharding. În procesul de sharding, datorită stocării aleatorii simple a nodurilor, poate apărea o pierdere de bloc. În al doilea rând, pentru datele după sharding, modul de confirmare a autenticității și integrității datelor în timpul procesului de restaurare este, de asemenea, foarte important. În DAS, aceste două probleme sunt rezolvate prin codul Eraser și angajamentul polinomului KZG.

  • Cod de șters: Având în vedere numărul mare de noduri verificate în Ethereum, este posibil ca un bloc să nu fie stocat de niciun nod, deși este un eveniment probabil. Pentru a atenua amenințarea lipsei de stocare, în loc să divizeze și să divizeze datele brute în blocuri, această schemă mapează datele brute la coeficienții unui polinom de gradul al n-lea, apoi ia 2n puncte pe polinom și permite nodurilor să aleagă aleatoriu unul dintre să le depoziteze. Pentru acest polinom de gradul al n-lea, sunt necesare doar n+1 puncte pentru reducere și, astfel, doar jumătate din blocuri trebuie selectate de noduri pentru ca noi să realizăm reducerea datelor originale. Codul Eraser îmbunătățește securitatea stocării datelor și capacitatea rețelei de a recupera datele.

  • Angajamentul polinom KZG: Un aspect foarte important al stocării datelor este verificarea autenticității datelor. În rețelele care nu folosesc cod Eraser, pentru verificare pot fi folosite diverse metode, dar dacă codul Eraser de mai sus este introdus pentru a îmbunătăți securitatea datelor, atunci este mai indicat să se folosească angajamentul polinom KZG, care poate verifica conținutul unui singur bloc direct sub forma unui polinom, eliminând astfel nevoia de a reduce polinomul la date binare. Angajamentul polinomului KZG poate verifica direct conținutul unui singur bloc sub formă de polinoame, eliminând astfel nevoia de a reduce polinoamele la date binare, iar forma generală de verificare este similară cu cea a Merkle Tree, dar nu necesită specific Datele nodului de cale și necesită numai rădăcina KZG și datele de bloc pentru a verifica autenticitatea blocului.

3.3 Metoda de validare a datelor în DA

Validarea datelor asigură că datele apelate de la un nod sunt exacte și complete. Pentru a minimiza cantitatea de date și costul de calcul necesar în procesul de validare, stratul DA utilizează acum o structură arborescentă ca metodă de validare principală. Cea mai simplă formă este să utilizați Merkle Tree pentru verificare, care utilizează forma înregistrărilor complete ale arborelui binar, trebuie doar să păstrați o rădăcină Merkle și valoarea hash a subarborelui de pe cealaltă parte a căii nodului poate fi verificată, complexitatea de timp a verificării este nivelul O(logN) (logN este implicit log2(N)). Deși procesul de validare a fost mult simplificat, cantitatea de date pentru procesul de validare în general crește în continuare odată cu creșterea datelor. Pentru a rezolva problema creșterii volumului de validare, se propune în această etapă o altă metodă de validare, Verkle Tree, în care fiecare nod din Verkle Tree nu numai că stochează valoarea, ci și atașează un Vector Commitment, care poate valida rapid autenticitatea date prin utilizarea valorii nodului original și a dovezii de angajament, fără a fi nevoie să apelați valorile altor noduri surori, ceea ce face ca calculul fiecărei validări să fie mai ușor și mai rapid. Acest lucru face ca numărul de calcule pentru fiecare verificare să fie raportat doar la adâncimea arborelui Verkle, care este o constantă fixă, accelerând astfel foarte mult viteza de verificare. Cu toate acestea, calculul Vector Commitment necesită participarea tuturor nodurilor surori în același strat, ceea ce crește foarte mult costul scrierii și modificării datelor. Cu toate acestea, pentru date precum datele istorice, care sunt stocate permanent și nu pot fi modificate, de asemenea, pot fi doar citite, dar nu scrise, Verkle Tree este extrem de potrivit. În plus, Merkle Tree și Verkle Tree în sine au o formă K-ary de variante, implementarea specifică a mecanismului este similară, trebuie doar să schimbați numărul de subarbori de sub fiecare nod, comparația specifică a performanței poate fi văzută în tabelul următor.

Sursa: Verkle Trees

3.4 Middleware generic DA

Expansiunea continuă a ecosistemului blockchain a dus la un număr tot mai mare de lanțuri publice. Datorită avantajelor și de neînlocuit al fiecărui lanț public în domeniile lor respective, este imposibil ca lanțurile publice Layer1 să devină unificate într-un timp scurt. Cu toate acestea, odată cu dezvoltarea DeFi și cu problemele CEX, cererea utilizatorilor pentru active de tranzacționare inter-lanț descentralizate este în creștere. Prin urmare, stocarea datelor cu mai multe lanțuri în strat DA, care poate elimina problemele de securitate în interacțiunea cu datele încrucișate, a câștigat din ce în ce mai multă atenție. Cu toate acestea, pentru a accepta date istorice din diferite lanțuri publice, este necesar ca stratul DA să ofere protocoale descentralizate pentru stocarea standardizată și validarea fluxului de date. De exemplu, kvye, un middleware de stocare bazat pe Arweave, adoptă metoda de accesare cu crawlere a datelor din lanțurile principale și poate stoca datele din toate lanțurile într-o formă standardizată în Arweave pentru a minimiza diferențele de transmisie a datelor. proces. Comparativ vorbind, Layer2, care este specializată în furnizarea de stocare a datelor la nivel DA pentru un anumit lanț public, realizează interacțiunea datelor prin intermediul nodurilor partajate interne. Deși reduce costul interacțiunii și îmbunătățește securitatea, are limitări mai mari și poate furniza servicii doar unor lanțuri publice specifice.

4. Metode de păstrare a DA

4.1 Lanțul principal DA

4.1.1 DankSharding-like

Nu există un nume definitiv pentru acest tip de schemă de stocare, dar cea mai proeminentă este Dank Sharding pe Ethereum, așa că în această lucrare, folosim termenul Dank Sharding-like pentru a ne referi la acest tip de schemă. Acest tip de schemă utilizează în principal cele două tehnici de stocare DA menționate mai sus, sharding și DAS, în primul rând, datele sunt împărțite într-un număr adecvat de partajări prin sharding, iar apoi fiecare nod extrage un bloc de date sub formă de DAS pentru stocare. În cazul în care există suficiente noduri în întreaga rețea, putem lua un număr mai mare de felii N, astfel încât presiunea de stocare a fiecărui nod să fie de numai 1/N față de cea originală, realizând astfel o expansiune de N ori a stocării totale. spaţiu. În același timp, pentru a preveni situația extremă în care un bloc nu este stocat de niciun bloc, Dank Sharding codifică datele folosind Eraser Code, care necesită doar jumătate din date pentru restaurarea completă. În cele din urmă, datele sunt verificate folosind o structură Verkle Tree cu angajamente polinomiale pentru sume de control rapide.

4.1.2 Depozitare temporară

Pentru DA din lanțul principal, una dintre cele mai simple moduri de a gestiona datele este stocarea datelor istorice pentru o perioadă scurtă de timp. În esență, blockchain-ul acționează ca un registru public, unde se fac modificări la conținutul registrului în prezența întregii rețele și nu este nevoie de stocare permanentă. În cazul Solana, de exemplu, deși datele sale istorice sunt sincronizate cu Arweave, nodurile principale ale rețelei rețin doar datele tranzacțiilor din ultimele două zile. Pe un lanț public bazat pe înregistrările de cont, fiecare moment al datelor istorice păstrează starea finală a contului pe blockchain, ceea ce este suficient pentru a oferi o bază pentru verificarea modificărilor în momentul următor. Cei care au nevoi speciale de date înainte de această oră, le pot stoca pe alte lanțuri publice descentralizate sau le pot preda unei terțe părți de încredere. Cu alte cuvinte, cei care au nevoi suplimentare de date vor trebui să plătească pentru stocarea datelor istorice.

4.2 Terțul DA

4.2.1 DA pentru lanțul principal: EthStorage

  • DA pentru lanțul principal: Cel mai important lucru pentru stratul DA este securitatea transmisiei de date, iar DA cu cea mai mare securitate este DA al lanțului principal, dar stocarea lanțului principal este limitată de spațiul de stocare și concurența dintre resurse, astfel încât atunci când volumul de date al rețelei crește rapid, DA terță parte este o alegere mai bună dacă dorește să realizeze stocarea pe termen lung a datelor. Dacă DA terță parte are o compatibilitate mai mare cu rețeaua principală, poate realiza partajarea nodurilor, iar procesul de interacțiune a datelor va avea o securitate mai mare. Prin urmare, sub premisa luării în considerare a securității, un DA dedicat pentru lanțul principal va avea un avantaj uriaș. Luând Ethereum ca exemplu, una dintre cerințele de bază pentru un DA dedicat lanțului principal este că poate fi compatibil cu EVM pentru a asigura interoperabilitatea cu datele și contractele Ethereum, iar proiectele reprezentative includ Topia, EthStorage etc. Printre acestea, EthStorage este cel mai compatibil DA în ceea ce privește compatibilitatea. Proiectele reprezentative includ Topia, EthStorage și așa mai departe. Dintre acestea, EthStorage este cel mai bine dezvoltat în ceea ce privește compatibilitatea, deoarece, pe lângă compatibilitatea EVM, a configurat și interfețe relevante pentru a interfața cu Remix, Hardhat și alte instrumente de dezvoltare Ethereum pentru a realiza compatibilitatea cu instrumentele de dezvoltare Ethereum.

  • EthStorage: EthStorage este un lanț public independent de Ethereum, dar nodurile care rulează pe acesta sunt un supergrup de noduri Ethereum, ceea ce înseamnă că nodurile care rulează EthStorage pot rula și Ethereum în același timp. În plus, putem opera direct EthStorage prin opcode-urile de pe Ethereum. Modelul de stocare EthStorage reține doar o cantitate mică de metadate pentru indexare în rețeaua principală Ethereum, creând în esență o bază de date descentralizată pentru Ethereum. În soluția actuală, EthStorage implementează un Contract EthStorage pe Ethereum principal pentru a realiza interacțiunea dintre Ethereum principal și EthStorage. Dacă Ethereum dorește să depună date, trebuie să apeleze funcția put() din contract, iar parametrii de intrare sunt variabile de doi octeți cheie, date, unde datele reprezintă datele care trebuie depuse, iar cheia este identitatea acesteia în Rețeaua Ethereum, care poate fi considerată similară cu existența CID în IPFS. După ce perechea de date (cheie, date) este stocată cu succes în rețeaua EthStorage, EthStorage va genera un kvldx care va fi returnat rețelei gazdă Ethereum, care corespunde cheii din rețeaua Ethereum, iar această valoare corespunde adresei de stocare a datele de pe EthStorage, astfel încât problema inițială de stocare a unei cantități mari de date poate fi acum schimbată la stocarea unei singure (cheie, kvldx). pereche (cheie, kvldx), care reduce foarte mult costul de stocare al rețelei principale Ethereum. Dacă trebuie să apelați datele stocate anterior, trebuie să utilizați funcția get() în EthStorage și să introduceți parametrul cheie, apoi puteți face o căutare rapidă a datelor pe EthStorage folosind kvldx stocat în Ethereum.

Sursa: Kernel Ventures

  • În ceea ce privește modul în care nodurile stochează datele, EthStorage învață din modelul Arweave. În primul rând, un număr mare de perechi (k,v) de la ETH sunt fragmentate, iar fiecare fragmentare conține un număr fix de perechi (k,v), dintre care există o limită a dimensiunii fiecărei (k,v) pereche pentru a asigura corectitudinea volumului de muncă în procesul de stocare a recompenselor pentru mineri. Pentru emiterea recompenselor, este necesar să se verifice dacă nodul stochează date pentru început. În acest proces, EthStorage va împărți o fragmentare (dimensiunea TB) în mai multe bucăți și va păstra o rădăcină Merkle pe rețeaua principală Ethereum pentru verificare. Apoi, minerul trebuie să furnizeze un nonce pentru a genera câteva bucăți printr-un algoritm aleatoriu cu hash-ul blocului anterior pe EthStorage, iar minerul trebuie să furnizeze datele acestor bucăți pentru a dovedi că a stocat întregul fragment, dar acest nonce nu poate fi ales în mod arbitrar, altfel nodul va alege nonce-ul corespunzător corespunzător bucăților stocate de el/ea și va trece verificarea. Totuși, acest nonce nu poate fi ales aleatoriu, în caz contrar nodul va alege un nonce potrivit care să corespundă doar bucăților sale stocate și astfel să treacă verificarea, așa că acest nonce trebuie să facă bucățile generate după amestecare și hashing, astfel încât valoarea dificultății să îndeplinească cerințele. al rețelei și doar primul nod care trimite nonce și dovada de acces aleatoriu poate primi recompensa.

4.2.2 Modularizare DA: Celsetia

  • Modulul Blockchain: Tranzacțiile care urmează să fie efectuate pe lanțul public Layer1 sunt împărțite în următoarele patru părți: (1) proiectarea logicii de bază a rețelei, selectarea nodurilor de validare într-un anumit mod, scrierea blocurilor și alocarea recompenselor pentru întreținerii rețelei; (2) ambalarea și procesarea tranzacțiilor și publicarea tranzacțiilor aferente; (3) validarea tranzacțiilor care urmează să fie încărcate în blockchain și determinarea stării finale; (4) stocarea și menținerea datelor istorice pe blockchain. În funcție de diferitele funcții îndeplinite, putem împărți blockchain-ul în patru module, strat de consens, strat de execuție, strat de decontare și strat de disponibilitate a datelor (stratul DA).

  • Design Blockchain modular: de mult timp, aceste patru module au fost integrate într-un singur lanț public, un astfel de blockchain fiind numit blockchain monolitic. Această formă este mai stabilă și mai ușor de întreținut, dar pune și o presiune enormă asupra lanțului public unic. În practică, cele patru module se constrâng reciproc și concurează pentru resursele limitate de calcul și stocare ale lanțului public. De exemplu, creșterea vitezei de procesare a stratului de procesare va aduce mai multă presiune de stocare la nivelul de disponibilitate a datelor; asigurarea securității stratului de execuție necesită un mecanism de verificare mai complex, dar încetinește viteza de procesare a tranzacțiilor. Prin urmare, dezvoltarea unui lanț public se confruntă adesea cu un compromis între aceste patru module. Pentru a trece peste acest blocaj de îmbunătățire a performanței lanțului public, dezvoltatorii au propus o soluție blockchain modulară. Ideea de bază a blockchain-ului modular este de a elimina unul sau mai multe dintre cele patru module menționate mai sus și de a le oferi unui lanț public separat pentru implementare. În acest fel, lanțul public se poate concentra pe îmbunătățirea vitezei tranzacțiilor sau a capacității de stocare, depășind limitările anterioare ale performanței generale a blockchain-ului din cauza efectului short board.

  • Modular DA: Abordarea complexă de separare a stratului DA de afacerea blockchain și plasarea lui într-un lanț public separat este considerată o soluție viabilă pentru datele istorice în creștere ale Layer1. În această etapă, explorarea în această zonă este încă într-un stadiu incipient, iar cel mai reprezentativ proiect este Celestia, care folosește metoda de stocare Sharding, care, de asemenea, împarte datele în mai multe blocuri, iar fiecare nod extrage o parte din ele pt. stocare și utilizează angajamentul polinom KZG pentru a verifica integritatea datelor. În același timp, Celestia folosește coduri corective RS bidimensionale avansate pentru a rescrie datele originale sub forma unei matrice k*k, care în cele din urmă necesită doar 25% din datele originale pentru a fi recuperate. Cu toate acestea, stocarea de date în felii este în esență doar înmulțirea presiunii de stocare a nodurilor din rețea cu un factor al volumului total de date, iar presiunea de stocare a nodurilor crește în continuare liniar cu volumul de date. Pe măsură ce Layer1 continuă să se îmbunătățească pentru viteza tranzacțiilor, presiunea de stocare asupra nodurilor poate atinge în continuare un prag inacceptabil într-o zi. Pentru a rezolva această problemă, în Celestia este introdusă o componentă IPLD. În loc să stocheze datele în matricea k*k direct pe Celestia, datele sunt stocate în rețeaua LL-IPFS, cu doar codul CID al datelor păstrat în nod. Când un utilizator solicită o bucată de date istorice, nodul trimite CID-ul corespunzător la componenta IPLD, care este folosită pentru a apela datele originale pe IPFS. Dacă datele există pe IPFS, acestea sunt returnate prin componenta IPLD și nodul. Dacă nu există, datele nu pot fi returnate.

Sursa: Celestia Core

  • Celestia: Luând Celestia ca exemplu, putem vedea aplicarea blockchain-ului modular în rezolvarea problemei de stocare a Ethereum, nodul Rollup va trimite datele tranzacției împachetate și verificate către Celestia și va stoca datele pe Celestia, în timpul procesului, Celestia stochează doar datele fără a avea prea multă percepție. În acest proces, Celestia doar stochează datele fără să le detecteze și, în final, în funcție de dimensiunea spațiului de stocare, nodul Rollup va plăti jetoanele tia corespunzătoare către Celestia ca taxă de stocare. Stocarea din Celestia utilizează un cod DAS și de depanare similare ca în EIP4844, dar codul de depanare polinomial din EIP4844 este actualizat pentru a utiliza un cod de depanare RS bidimensional, care îmbunătățește din nou securitatea stocării și doar 25% din fracții. sunt necesare pentru a recupera toate datele tranzacției. Este, în esență, un lanț public POS cu costuri reduse de stocare și, dacă urmează să fie realizat ca o soluție la problema de stocare a datelor istorice a Ethereum, sunt necesare multe alte module specifice pentru a lucra cu Celestia. De exemplu, în ceea ce privește rollup-ul, unul dintre modelele de roll-up foarte recomandate de site-ul oficial al Celestia este Sovereign Rollup, care este diferit de rollup-ul obișnuit de pe Layer2, care poate doar calcula și verifica tranzacțiile, doar completând stratul de execuție, și include întregul proces de execuție și decontare, ceea ce minimizează necesitatea procesului de execuție și decontare pe Celestia. Acest lucru reduce la minimum procesarea tranzacțiilor pe Celestia, ceea ce maximizează securitatea generală a procesului de tranzacție atunci când securitatea generală a Celestia este mai slabă decât cea a Ethereum. În ceea ce privește securitatea datelor apelate de Celestia pe rețeaua principală a Ethereum, cea mai populară soluție este contractul inteligent Quantum Gravity Bridge. Pentru datele stocate pe Celestia, acesta va genera un Merkle Root (certificat de disponibilitate a datelor) și îl va păstra pe contractul Quantum Gravity Bridge pe rețeaua principală a EtherCenter. Când EtherCenter apelează datele istorice despre Celestia de fiecare dată, va compara rezultatul hash cu Merkle Root și, dacă se potrivește, înseamnă că este într-adevăr datele istorice reale.

4.2.3 Lanțul de stocare DA

În ceea ce privește principiile tehnice ale DA-urilor mainchain, multe tehnici similare sharding-ului au fost împrumutate de la lanțurile publice de stocare. În DA-urile terților, unii dintre aceștia îndeplinesc chiar o parte din sarcinile de stocare direct cu ajutorul lanțurilor publice de stocare, de exemplu, datele specifice tranzacțiilor din Celestia sunt plasate în rețeaua LL-IPFS. În soluțiile DA-urilor terțe, pe lângă construirea unui lanț public separat pentru a rezolva problema de stocare a Layer1, o modalitate mai directă este conectarea directă a lanțului public de stocare la Layer1 pentru a stoca datele istorice uriașe pe Layer1. Pentru blockchain-ul de înaltă performanță, volumul de date istorice este și mai mare, în condiții de funcționare cu viteză maximă, volumul de date al lanțului public de înaltă performanță Solana este aproape de 4 PG, ceea ce este complet dincolo de intervalul de stocare al nodurilor obișnuite. Solana alege o soluție de stocare a datelor istorice pe rețeaua de stocare descentralizată Arweave și reține doar 2 zile de date pe nodurile rețelei principale pentru verificare. Pentru a asigura securitatea procesului de stocare, Solana și lanțul Arweave au conceput un protocol de punte de stocare, Solar Bridge, care sincronizează datele validate de la nodurile Solana la Arweave și returnează eticheta corespunzătoare, care permite nodurilor Solana să vizualizeze datele istorice ale blockchain-ul Solana în orice moment. Nodul Solana poate vizualiza date istorice din orice moment al blockchain-ului Solana. Pe Arweave, în loc să solicite nodurilor din rețea să mențină consistența datelor ca o necesitate pentru participare, rețeaua adoptă o abordare de stocare a recompenselor. În primul rând, Arweave nu folosește o structură tradițională în lanț pentru a construi blocuri, ci mai degrabă ca o structură grafică. În Arweave, un bloc nou nu va indica doar blocul anterior, ci și în mod aleatoriu către un bloc generat Recall bloc, a cărui locație exactă este determinată de rezultatul hash al blocului anterior și de înălțimea blocului acestuia și de locația Recall-ului. blocul este necunoscut până când blocul anterior este minat. Cu toate acestea, în procesul de generare de noi blocuri, nodurilor li se cere să aibă datele blocului Recall pentru a utiliza mecanismul POW pentru a calcula hash-ul de dificultate specificată și numai minerul care este primul care calculează hash-ul care îndeplinește dificultatea poate fi recompensată, ceea ce îi încurajează pe mineri să stocheze cât mai multe date istorice. În același timp, cu cât mai puțini oameni stochează un anumit bloc istoric, cu atât mai puțini concurenți va avea un nod atunci când generează un nonce conform cu dificultatea, încurajând minerii să stocheze blocuri cu mai puține copii de siguranță în rețea. În cele din urmă, pentru a se asigura că nodurile stochează datele în mod permanent, mecanismul de scorare al nodurilor WildFire este introdus în Arweave. Nodurile vor prefera să comunice cu noduri care pot furniza date istorice mai mult și mai rapid, în timp ce nodurile cu evaluări mai scăzute nu vor putea obține cele mai recente date privind blocurile și tranzacțiile de prima dată, nereușind astfel să obțină un avans în competiția POW.

Sursa: Arweave Yellow-Paper

5. Comparație sintetizată

Vom compara avantajele și dezavantajele fiecăreia dintre cele cinci soluții de stocare în ceea ce privește cele patru dimensiuni ale parametrilor de performanță DA.

  • Siguranță: Cea mai mare sursă de probleme de securitate a datelor este pierderea de date cauzată de procesul de transmitere a datelor și falsificarea rău intenționată de la nodurile necinstite, iar procesul încrucișat este zona cea mai afectată a securității transmisiei de date din cauza independenței celor doi public. lanțuri și statul nu este împărțit. În plus, Layer1, care necesită un strat DA specializat în această etapă, are adesea un grup de consens puternic, iar securitatea sa va fi mult mai mare decât cea a lanțurilor publice de stocare obișnuite. Prin urmare, soluția DA din lanțul principal are o securitate mai mare. După asigurarea securității transmiterii datelor, următorul pas este asigurarea securității datelor de apelare. Luând în considerare doar datele istorice pe termen scurt utilizate pentru verificarea tranzacției, aceleași date sunt susținute de întreaga rețea în rețeaua de stocare temporară, în timp ce numărul mediu de copii de siguranță a datelor în schema de tip DankSharding este doar 1/N din numărul de noduri din întreaga rețea, ceea ce înseamnă mai multă redundanță a datelor poate face ca datele să fie mai puțin predispuse la pierdere și, în același timp, poate oferi mai multe mostre de referință pentru verificare. Prin urmare, stocarea temporară va avea o securitate mai mare a datelor. În schema DA terță parte, datorită nodurilor publice utilizate în lanțul principal, datele pot fi transmise direct prin aceste noduri releu în procesul de înlănțuire încrucișată și, astfel, vor avea și o securitate relativ mai mare decât alte DA scheme.

  • Costul de stocare: Factorul care are cel mai mare impact asupra costului de stocare este cantitatea de redundanță a datelor. În schema de stocare pe termen scurt a lanțului principal DA, care utilizează forma de sincronizare a datelor nodurilor la nivel de rețea pentru stocare, orice date nou stocate trebuie să fie salvate în nodurile la nivel de rețea, având cel mai mare cost de stocare. Costul mare de stocare determină, la rândul său, că într-o rețea TPS mare, această abordare este potrivită doar pentru stocarea temporară. Urmează metoda de stocare sharding, inclusiv sharding în lanțul principal și sharding în DA terță parte. Deoarece lanțul principal are adesea mai multe noduri și astfel blocul corespunzător va avea mai multe copii de rezervă, schema de fragmentare a lanțului principal va avea un cost mai mare. Cel mai mic cost de stocare este în lanțul public de stocare DA care adoptă metoda de stocare a recompensei, iar cantitatea de redundanță a datelor din această schemă tinde să fluctueze în jurul unei constante fixe. În același timp, lanțul public de stocare DA introduce și un mecanism de ajustare dinamică, care atrage noduri pentru a stoca mai puține date de backup prin creșterea recompensei pentru a asigura securitatea datelor.

  • Viteza de citire a datelor: viteza de stocare a datelor este afectată în primul rând de locul în care sunt stocate datele în spațiul de stocare, calea indexului de date și distribuția datelor între noduri. Printre acestea, acolo unde datele sunt stocate în noduri are un impact mai mare asupra vitezei, deoarece stocarea datelor în memorie sau SSD poate duce la o diferență de zeci de ori în viteza de citire. Lanțurile publice de stocare DA au în mare parte spațiu de stocare SSD, deoarece încărcarea acelui lanț include nu numai date din stratul DA, ci și date cu caracter personal care necesită mult memorie, cum ar fi videoclipuri și imagini încărcate de utilizatori. Dacă rețeaua nu utilizează SSD-uri ca spațiu de stocare, este dificil să suportați presiunea uriașă de stocare și să satisfaceți cererea de stocare pe termen lung. În al doilea rând, pentru DA terți și DA din lanțul principal care utilizează starea memoriei pentru a stoca date, DA terți trebuie mai întâi să caute datele indexate corespunzătoare în lanțul principal și apoi să transfere datele indexate de-a lungul lanțului către terți. partiți DA-urile și returnați datele prin puntea de stocare. În contrast, DA mainchain poate interoga datele direct de la noduri și, astfel, are o viteză mai rapidă de recuperare a datelor. În cele din urmă, în cadrul DA din lanțul principal, abordarea sharding necesită apelarea blocurilor de la mai multe noduri și restaurarea datelor originale. Prin urmare, este mai lentă decât metoda de stocare pe termen scurt fără fragmentare.

  • Universalitatea stratului DA: Universalitatea DA Mainchain este aproape de zero deoarece nu este posibil să transferați date dintr-un lanț public cu spațiu de stocare insuficient la un alt lanț public cu spațiu de stocare insuficient. În DA terți, generalitatea unei soluții și compatibilitatea acesteia cu un anumit mainchain sunt metrici contradictorii. De exemplu, în cazul unei soluții DA specifice mainchain-ului proiectată pentru un anumit mainchain, aceasta a adus o mulțime de îmbunătățiri la nivel de tipuri de noduri și consens de rețea pentru a se adapta la acel lanț public anume și, astfel, aceste îmbunătățiri pot acționa ca un obstacol imens în comunicarea cu alte lanțuri publice. În cadrul DA-urilor terță parte, DA-urile din lanțul public de stocare au rezultate mai bune în ceea ce privește generalizarea decât DA-urile modulare. AD lanțurile publice de stocare au o comunitate de dezvoltatori mai mare și mai multe facilități de extindere pentru a se adapta la diferite lanțuri publice. În același timp, lanțul public de stocare DA poate obține date mai activ prin captarea pachetelor, mai degrabă decât prin primirea pasivă a informațiilor transmise de la alte lanțuri publice. Prin urmare, poate codifica datele în felul său, poate realiza stocarea standardizată a fluxului de date, poate facilita gestionarea informațiilor de date din diferite lanțuri principale și poate îmbunătăți eficiența stocării.

Sursa: Kernel Ventures

6. Concluzie

Blockchain trece prin procesul de conversie de la Crypto la Web3, și aduce o abundență de proiecte pe blockchain, dar și probleme de stocare a datelor. Pentru a permite funcționarea simultană a atâtor proiecte pe Layer1 și pentru a asigura experiența proiectelor Gamefi și Socialfi, Layer1 reprezentat de Ethereum a adoptat Rollup și Blobs pentru a îmbunătăți TPS. În plus, numărul de blockchain-uri de înaltă performanță din blockchain-ul nou-născutului este, de asemenea, în creștere. Dar TPS mai mare nu înseamnă doar performanță mai mare, ci înseamnă și mai multă presiune de stocare în rețea. Pentru cantitatea uriașă de date istorice, în această etapă sunt propuse mai multe abordări DA, atât pe lanțul principal, cât și pe terțe părți, pentru a se adapta la creșterea presiunii de stocare a lanțului. Îmbunătățirile au avantajele și dezavantajele lor și au aplicabilitate diferită în contexte diferite. În cazul blockchain-urilor bazate pe plăți, care au cerințe foarte mari pentru securitatea datelor istorice și nu urmăresc TPS deosebit de ridicat, acestea sunt încă în stadiu pregătitor, pot adopta o metodă de stocare asemănătoare DankSharding, care poate asigura securitatea și o creștere uriașă a capacității de stocare în același timp realizează. Totuși, dacă este un lanț public precum Bitcoin, care a fost deja format și are un număr mare de noduri, există un risc uriaș de a îmbunătăți brusc stratul de consens, astfel încât să poată adopta un DA special pentru lanțul principal cu o securitate mai mare. în stocarea în afara lanțului pentru a echilibra problemele de securitate și stocare. Cu toate acestea, merită remarcat faptul că funcția blockchain-ului se schimbă în timp. De exemplu, în primele zile, funcționalitatea Ethereum a fost limitată la plăți și la procesarea automată simplă a activelor și tranzacțiilor folosind contracte inteligente, dar pe măsură ce peisajul blockchain s-a extins, diferite proiecte Socialfi și Defi au fost adăugate la Ethereum, împingându-l la o mai mare măsură. direcție cuprinzătoare. Odată cu explozia recentă a ecosistemului de inscripții pe Bitcoin, taxele de tranzacție pe rețeaua Bitcoin au crescut de aproape 20 de ori din august, reflectând faptul că vitezele de tranzacție ale rețelei nu sunt capabile să satisfacă cererea de tranzacții în această etapă. Comercianții trebuie să majoreze comisioane pentru ca tranzacțiile să fie procesate cât mai repede posibil. Acum, comunitatea Bitcoin trebuie să facă un compromis între acceptarea de comisioane mari și viteza scăzută a tranzacțiilor sau reducerea securității rețelei pentru a crește vitezele de tranzacție, învingând în primul rând scopul sistemului de plată. Dacă comunitatea Bitcoin o alege pe cea din urmă, atunci soluția de stocare va trebui ajustată în fața presiunii în creștere a datelor.

Sursa: OKLINK

În ceea ce privește lanțul public cu funcții cuprinzătoare, urmărirea sa de TPS este mai mare, odată cu creșterea enormă a datelor istorice, este dificil să se adapteze la creșterea rapidă a TPS pe termen lung prin adoptarea soluției de tip DankSharding. Prin urmare, o modalitate mai adecvată este migrarea datelor către un DA terță parte pentru stocare. Dintre acestea, DA-urile specifice lanțului principal au cea mai mare compatibilitate și pot fi mai avantajoase dacă se ia în considerare doar stocarea unui singur lanț public. Cu toate acestea, în zilele noastre, când lanțurile publice Layer1 înfloresc, transferul de active încrucișat și interacțiunea datelor au devenit, de asemenea, o activitate comună a comunității blockchain. Dacă luăm în considerare dezvoltarea pe termen lung a întregului ecosistem blockchain, stocarea datelor istorice din diferite lanțuri publice pe același lanț public poate elimina multe probleme de securitate în procesul de schimb și validare a datelor, astfel încât DA modularizat și modul de stocare public lanțurile DA pot fi o alegere mai bună. Sub premisa unei generalități apropiate, modular DA se concentrează pe furnizarea de servicii blockchain DA layer, introduce date de index mai rafinate pentru a gestiona datele istorice și poate face o clasificare rezonabilă a diferitelor date din lanțul public, ceea ce are mai multe avantaje în comparație cu lanțurile publice de stocare. Cu toate acestea, propunerea de mai sus nu ia în considerare costul ajustării stratului de consens pe lanțul public existent, ceea ce este extrem de riscant. O mică breșă sistematică poate face ca lanțul public să piardă consensul comunității. Prin urmare, dacă este o soluție de tranziție în procesul de transformare blockchain, stocarea temporară pe lanțul principal poate fi mai potrivită. În cele din urmă, toate discuțiile de mai sus se bazează pe performanța în timpul funcționării efective, dar dacă scopul unui anumit lanț public este de a-și dezvolta ecologia și de a atrage mai multe părți și participanți la proiect, acesta poate, de asemenea, tinde să favorizeze proiectele care sunt susținute și finanțate de fundamentul acesteia. De exemplu, dacă performanța generală este egală sau chiar puțin mai mică decât cea a soluției de stocare în lanț public de stocare, comunitatea Ethereum va favoriza și EthStorage, care este un proiect Layer2 susținut de Fundația Ethereum, pentru a continua dezvoltarea ecosistemului Ethereum. .

Una peste alta, complexitatea tot mai mare a blockchain-urilor de astăzi aduce cu sine o nevoie mai mare de spațiu de stocare. Cu suficiente noduri de validare Layer1, datele istorice nu trebuie să fie susținute de toate nodurile din întreaga rețea, dar pot asigura securitatea după un anumit prag. În același timp, diviziunea muncii a lanțului public a devenit din ce în ce mai detaliată, Layer1 este responsabil pentru consens și execuție, Rollup este responsabil pentru calcul și verificare, iar apoi un blockchain separat este utilizat pentru stocarea datelor. Fiecare parte se poate concentra pe o anumită funcție fără a fi limitată de performanța celorlalte părți. Cu toate acestea, numărul specific de stocare sau proporția de noduri permise să stocheze date istorice pentru a atinge un echilibru între securitate și eficiență, precum și modul de asigurare a interoperabilității securizate între diferitele blockchains este o problemă care trebuie luată în considerare de dezvoltatorii de blockchain. Investitorii pot acorda atenție proiectului DA specific lanțului principal pe Ethereum, deoarece Ethereum are deja destui susținători în această etapă, fără a fi nevoie să folosească puterea altor comunități pentru a-și extinde influența. Este mai important să-și îmbunătățească și să-și dezvolte comunitatea pentru a atrage mai multe proiecte către ecosistemul Ethereum. Cu toate acestea, pentru lanțurile publice care ajung din urmă, cum ar fi Solana și Aptos, lanțul unic în sine nu are un ecosistem atât de perfect, așa că ar putea prefera să își unească forțele cu alte comunități pentru a construi un ecosistem mare încrucișat pentru a-și extinde influența. . Prin urmare, pentru stratul emergent 1, un DA terță parte cu scop general merită mai multă atenție.

Kernel Ventures este un fond de cripto VC condus de comunitatea de cercetare și dezvoltare, cu peste 70 de investiții în stadiu incipient, concentrându-se pe infrastructură, middleware, dApps, în special ZK, Rollup, DEX, Modular Blockchain și verticale, care vor integra următorul miliard de utilizatori în cripto. cum ar fi abstracția contului, disponibilitatea datelor, scalabilitate și etc. În ultimii șapte ani, ne-am angajat să sprijinim creșterea comunităților de dezvoltare de bază și a asociațiilor Blockchain universitare din întreaga lume.

Referinţă

  1. Celestia: Marea înstelată a blockchain-ului modular: https://foresightnews.pro/article/detail/15497

  2. Utilizarea DHT și lucrările viitoare: https://github.com/celestiaorg/celestia-node/issues/11

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

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

  5. Anunțând Podul SOLAR: https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2

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

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

  8. Rețeaua Arweave: https://www.arweave.org/

  9. Cartea galbenă Arweave: https://www.arweave.org/yellow-paper.pdf