Autor: Kernel Ventures Jerry Luo

Recenzători: Kernel Ventures Mandy, Kernel Ventures Joshua

TLDR:

  1. Lanțurile publice timpurii au cerut tuturor nodurilor de rețea să mențină consistența datelor pentru a asigura securitatea și descentralizarea. Cu toate acestea, odată cu dezvoltarea ecosistemului blockchain, presiunea de stocare continuă să crească, ceea ce duce la o tendință de operațiuni centralizate de noduri. În această etapă, Stratul 1 trebuie să rezolve urgent problema costurilor de stocare cauzată de creșterea TPS.

  2. Confruntați cu această problemă, dezvoltatorii trebuie să propună noi soluții de stocare a datelor istorice, ținând cont în același timp de securitate, 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 noi și idei noi, inclusiv Sharding, DAS, Verkle Tree, componente intermediare DA etc. Au încercat să optimizeze soluția de stocare a stratului DA prin reducerea redundanței datelor și îmbunătățirea eficienței verificării datelor.

  4. Soluțiile actuale DA sunt în general împărțite în două categorii în funcție de locația de stocare a datelor, și anume lanțul principal DA și DA terță parte. Lanțul principal DA începe din perspectiva curățării regulate a datelor și a fragmentării stocării datelor pentru a reduce presiunea de stocare a nodului. Cerințele de proiectare DA terță parte sunt toate destinate serviciilor de stocare și au soluții rezonabile pentru cantități mari de date. Prin urmare, accentul principal este pe compromisul între compatibilitatea cu un singur lanț și compatibilitatea cu mai multe lanțuri și sunt propuse trei soluții: DA dedicată lanțului principal, DA modulară și DA lanțului public de stocare.

  5. Lanțurile publice de tip plată au cerințe extrem de ridicate pentru securitatea datelor istorice și sunt potrivite pentru utilizarea lanțului principal ca strat DA. Totuși, pentru lanțurile publice care funcționează de mult timp și au un număr mare de mineri care conduc rețeaua, ar fi mai indicat să se adopte un DA terță parte care să nu implice stratul de consens și să țină cont de securitate. Lanțurile publice cuprinzătoare sunt mai potrivite pentru utilizarea stocării DA dedicate lanțului principal cu capacitate de date mai mare, costuri și securitate mai mici. Dar având în vedere nevoile cross-chain-ului, modular DA este, de asemenea, o opțiune bună.

  6. În general, blockchain-ul se dezvoltă în direcția reducerii redundanței datelor și a diviziunii muncii în mai multe lanțuri.

1. Context

Ca registru distribuit, blockchain-ul trebuie să stocheze date istorice pe toate nodurile pentru a asigura securitatea și descentralizarea suficientă a stocării datelor. Deoarece corectitudinea fiecărei schimbări de stare este legată de starea anterioară (sursa tranzacției), pentru a asigura corectitudinea tranzacțiilor, un blockchain ar trebui, în principiu, să stocheze toate înregistrările istorice de la prima tranzacție până la tranzacția curentă. Luând Ethereum ca exemplu, chiar dacă dimensiunea medie a blocului este estimată la 20 kb, dimensiunea totală actuală a blocurilor Ethereum a ajuns la 370 GB Pe lângă blocul în sine, un nod complet trebuie să înregistreze, de asemenea, starea și încasările tranzacțiilor. . Numărând această parte, capacitatea totală de stocare a unui singur nod a depășit 1 TB, ceea ce concentrează funcționarea nodului la câteva persoane.

Cea mai recentă înălțime a blocului Ethereum, sursa imagine: Etherscan

Actualizarea recentă a Ethereum Cancun urmărește să crească TPS-ul Ethereum la aproximativ 1.000. Până atunci, creșterea anuală a stocării Ethereum va depăși suma capacității sale de stocare actuale. Printre diversele lanțuri publice de înaltă performanță care au devenit populare în ultima perioadă, viteza tranzacțiilor de zeci de mii de TPS poate aduce în medie sute de GB de date noi în fiecare zi. Metoda comună de redundanță de date a întregului nod de rețea nu se poate adapta la o astfel de presiune de stocare Layer1 trebuie să găsească o soluție adecvată pentru a echilibra creșterea TPS și costul de stocare al nodului.

2. Indicatori de performanță DA

2.1 Securitate

În comparație cu structurile de stocare a bazelor de date sau a listelor conectate, nemodificarea blockchain-ului provine din capacitatea de a verifica datele nou generate prin datele istorice. Prin urmare, asigurarea securității datelor istorice este prima problemă care trebuie luată în considerare. Atunci când judecăm securitatea datelor sistemelor blockchain, o analizăm adesea din cantitatea de redundanță a datelor și metoda de verificare a disponibilității datelor.

  • Cantitatea de redundanță: Pentru redundanța datelor din sistemul blockchain, acesta poate juca în principal următoarele roluri: În primul rând, dacă numărul de redundanțe în rețea este mai mare, atunci când verificatorul trebuie să verifice starea contului într-un anumit bloc istoric pentru a verifica Când o tranzacție este verificată, poate obține cele mai multe mostre pentru referință și poate selecta datele înregistrate de majoritatea nodurilor. În bazele de date tradiționale, deoarece datele sunt stocate doar sub formă de perechi cheie-valoare pe un anumit nod, modificările datelor istorice pot fi făcute doar pe un singur nod, iar costul atacului este extrem de mic, cu cât este mai mare numărul de concedieri, cu atât datele vor fi mai puțin probabile, cu cât gradul de credibilitate este mai mare. În același timp, cu cât sunt stocate mai multe noduri, cu atât este mai puțin probabil ca datele să se piardă. Acest lucru poate fi comparat și cu serverul centralizat care stochează jocurile Web2 Odată ce toate serverele backend sunt închise, serverul va fi complet închis. Totuși, cu cât mai mult, cu atât mai bine, deoarece fiecare redundanță va aduce spațiu suplimentar de stocare a datelor va aduce o presiune de stocare excesivă pentru sistem.

  • Verificarea disponibilității datelor: numărul de redundanțe asigură că există suficiente înregistrări ale datelor în rețea, dar trebuie verificată acuratețea și caracterul complet al datelor care urmează să fie utilizate. Metoda de verificare folosită în mod obișnuit în blockchain-ul actual este algoritmul de angajament criptografic, care păstrează un mic angajament criptografic pentru a înregistra întreaga rețea. Acest angajament este obținut prin amestecarea datelor de tranzacție. Când doriți să testați autenticitatea unei anumite date istorice, trebuie să restabiliți angajamentul criptografic prin intermediul datelor și să verificați dacă angajamentul criptografic obținut prin această restaurare este în concordanță cu înregistrările întregii rețele , verificarea este trecută. Algoritmii de verificare a criptografiei folosiți în mod obișnuit includ Merkle Root și Verkle Root. Algoritmul de verificare a disponibilității datelor de înaltă securitate necesită doar o cantitate mică de date de verificare și poate verifica rapid datele istorice.

2.2 Costuri de depozitare

Pe premisa asigurării securității de bază, următorul obiectiv principal pe care trebuie să-l atingă nivelul DA este reducerea costurilor și creșterea eficienței. Primul este de a reduce costurile de stocare, indiferent de diferențele de performanță hardware, adică de a reduce utilizarea memoriei cauzată de stocarea datelor de dimensiunea unității. În această etapă, principalele modalități de a reduce costurile de stocare în blockchain sunt adoptarea tehnologiei sharding și utilizarea stocării bazate pe recompense pentru a se asigura că datele sunt stocate în mod eficient și pentru a reduce numărul de copii de siguranță ale datelor. Cu toate acestea, nu este dificil să vedem din metodele de îmbunătățire de mai sus că există o relație de joc între costul de stocare și securitatea datelor Reducerea ocupării stocării înseamnă adesea o scădere a securității. Prin urmare, un strat DA excelent trebuie să atingă un echilibru între costul de stocare și securitatea datelor. În plus, dacă stratul DA este un lanț public separat, trebuie să reducă costul prin reducerea la minimum a procesului intermediar de schimb de date. În fiecare proces de transfer, datele de index trebuie lăsate pentru apelurile de interogare ulterioare proces, cu atât vor rămâne mai multe date de index și costul de stocare va crește. În cele din urmă, costul stocării datelor este direct legat de durabilitatea datelor. În general, cu cât costul de stocare al 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ă obținerea reducerii costurilor, următorul pas este creșterea eficienței, care este capacitatea de a apela rapid date din stratul DA atunci când acestea trebuie utilizate. Acest proces implică doi pași. Primul este de a căuta noduri care stochează date. Acest proces este în principal pentru lanțurile publice care nu au atins coerența datelor în întreaga rețea poate fi ignorat consumul de timp al unui proces. În al doilea rând, în sistemele blockchain curente, inclusiv Bitcoin, Ethereum și Filecoin, metoda de stocare a nodurilor este baza de date Leveldb. În Leveldb, datele sunt stocate în trei moduri. În primul rând, datele scrise imediat vor fi stocate în fișiere de tip Memtable. Când stocarea Memtable este plină, tipul de fișier va fi schimbat din Memtable în Immutable Memtable. Ambele tipuri de fișiere sunt stocate în memorie, dar fișierele Immutable Memtable nu mai pot fi modificate, din ele pot fi citite doar date. Stocarea la cald folosită în rețeaua IPFS stochează date în această parte. Când este apelată, poate fi citită rapid din memorie. iar atunci când un nod se blochează sau apare o altă situație anormală, datele din memorie se vor pierde definitiv. Dacă doriți ca datele să fie stocate în mod persistent, trebuie să le stocați sub forma unui fișier SST pe o unitate SSD. Cu toate acestea, 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 sistemele care utilizează stocare fragmentată, restaurarea datelor necesită trimiterea cererilor de date către mai multe noduri și restaurarea acestora. Acest proces va reduce și viteza de citire a datelor.

Metoda de stocare a datelor Leveldb, sursa imagine: manualul Leveldb

2.4 Versatilitate stratului DA

Odată cu dezvoltarea DeFi și diversele probleme cu CEX, cerințele utilizatorilor pentru tranzacțiile în lanțuri încrucișate ale activelor descentralizate sunt, de asemenea, în creștere. Indiferent de mecanismul cross-chain de blocare hash, notar public sau lanț releu, determinarea simultană a datelor istorice pe ambele lanțuri nu poate fi evitată. Cheia acestei probleme constă în separarea datelor pe cele două lanțuri, iar comunicarea directă nu poate fi realizată în diferite sisteme descentralizate. Prin urmare, în această etapă se propune o soluție prin schimbarea metodei de stocare a stratului DA, care nu numai că stochează datele istorice ale mai multor lanțuri publice pe același lanț public de încredere, ci trebuie doar să apeleze datele din acest lanț public în timpul verificării . Acest lucru necesită ca stratul DA să poată stabili metode de comunicare sigure cu diferite tipuri de lanțuri publice, ceea ce înseamnă că stratul DA are o bună versatilitate.

3. Explorarea tehnologiilor legate de DA

3.1 Sharding

  • Într-un sistem tradițional distribuit, un fișier nu este stocat într-o formă completă pe un anumit nod. În schimb, datele originale sunt împărțite în mai multe blocuri și un bloc este stocat în fiecare nod. Și blocurile nu sunt adesea stocate doar pe un singur nod, dar vor lăsa copii de rezervă adecvate pe alte noduri. Acest mecanism Sharding poate reduce presiunea de stocare a unui singur nod, poate extinde capacitatea totală a sistemului la suma capacității de stocare a fiecărui nod și, în același timp, poate asigura securitatea stocării printr-o redundanță adecvată a datelor. Schema Sharding adoptată în blockchain este în general similară, dar detaliile specifice vor fi diferite. În primul rând, deoarece fiecare nod din blockchain nu este de încredere în mod implicit, procesul de implementare a Sharding necesită o cantitate suficient de mare de copie de rezervă a datelor pentru evaluarea ulterioară a autenticității datelor, astfel încât numărul de copii de siguranță pentru acest nod trebuie să fie mult mai mare de 2. . În mod ideal, într-un sistem blockchain care utilizează această schemă de stocare, dacă numărul total de noduri de verificare este T și numărul de fragmente este N, atunci numărul de copii de rezervă ar trebui să fie T/N. Al doilea este procesul de stocare al blocului. Există puține noduri în sistemele distribuite tradiționale, astfel încât un nod se adaptează adesea la mai multe blocuri de date. blocuri numerotate într-un anumit interval și poate accepta că un nod nu alocă sarcini de stocare în timpul unei anumite stocări. Pe blockchain, dacă fiecărui nod i se atribuie un bloc nu mai este un eveniment aleator, ci un eveniment inevitabil. Fiecare nod va selecta aleatoriu un bloc pentru stocare hashingul datelor se completează prin luarea modulului numărului de fragmente. Presupunând că fiecare bucată de date este împărțită în N blocuri, dimensiunea reală de stocare a fiecărui nod este doar 1/N din cel original. Setând N în mod corespunzător, se poate obține un echilibru între creșterea TPS și presiunea de stocare a nodului.

Metoda de stocare a datelor după Sharding, sursa imaginii: Kernel Ventures

3.2 DAS（Eșantionarea disponibilității datelor）

Tehnologia DAS se bazează pe optimizarea ulterioară a metodelor de stocare Sharding. În timpul procesului de fragmentare, datorită stocării aleatorii simple a nodurilor, un anumit bloc se poate pierde. În al doilea rând, pentru datele fragmentate, este, de asemenea, foarte important să se confirme autenticitatea și integritatea datelor în timpul procesului de restaurare. În DAS, aceste două probleme sunt rezolvate prin codul Eraser și prin angajamentul polinomului KZG.

  • Cod de șters: Având în vedere numărul mare de noduri de verificare din Ethereum, probabilitatea ca un anumit Bloc să nu fie stocat de niciun nod este aproape 0, dar teoretic există încă posibilitatea ca o astfel de situație extremă să se întâmple. Pentru a atenua această posibilă amenințare de pierdere a stocării, în această schemă, datele originale nu sunt adesea împărțite direct în blocuri pentru stocare. În schimb, datele originale sunt mapate mai întâi la coeficienții unui polinom de ordin n, iar apoi 2n este. luate din punctele polinom și lăsați nodul să selecteze aleatoriu unul dintre ele pentru stocare. Pentru acest polinom de ordin n, sunt necesare doar n+1 puncte pentru a-l restaura. Prin urmare, doar jumătate din blocuri trebuie să fie selectate de noduri și putem restaura datele originale. Prin codul Eraser, securitatea stocării datelor și capacitatea rețelei de recuperare a datelor sunt îmbunătățite.

  • Angajamentul polinom KZG: O parte foarte importantă a stocării datelor este verificarea autenticității datelor. Într-o rețea care nu utilizează cod Eraser, pot fi utilizate diferite metode în procesul de verificare. Cu toate acestea, dacă este introdus codul Eraser de mai sus pentru a îmbunătăți securitatea datelor, atunci o metodă mai adecvată este utilizarea angajamentului polinom KZG. Angajamentul polinomului KZG poate verifica direct conținutul unui singur bloc sub formă de polinoame, eliminând astfel procesul de reducere a polinoamelor la date binare. Root Autenticitatea sa poate fi verificată cu datele Block.

3.3 Metoda de verificare a datelor stratului DA

Verificarea datelor asigură că datele apelate de la nod nu au fost manipulate și nu s-au pierdut. Pentru a minimiza cantitatea de date și costurile de calcul necesare în procesul de verificare, stratul DA utilizează în prezent o structură arborescentă ca metodă principală de verificare. Cea mai simplă formă este să utilizați Merkle Tree pentru verificare, care este înregistrat sub forma unui arbore binar complet. Trebuie doar să păstrați o rădăcină Merkle și valoarea hash a subarborelui pentru a verifica timpul de verificare este complicat. Deși procesul de verificare a fost mult simplificat, volumul total de date al procesului de verificare crește în continuare odată cu creșterea datelor. Pentru a rezolva problema volumului de verificare crescut, se propune în această etapă o altă metodă de verificare, Verkle Tree. Pe lângă stocarea valorii, fiecare nod din Verkle Tree vine și cu un angajament vectorial Prin valoarea nodului original și această dovadă de angajament, autenticitatea datelor poate fi verificată rapid fără a apela la valorile altei surori. noduri, care face de fiecare dată Numărul de calcule de verificare este legat doar de adâncimea Arborele Verkle și este o constantă fixă, ceea ce accelerează 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 și care trebuie doar citite, dar nu scrise, Verkle Tree este extrem de potrivit. În plus, Merkle Tree și Verkle Tree au variante în formă K-ary. Mecanismele lor specifice de implementare sunt similare, cu excepția faptului că numărul de subarbori de sub fiecare nod este modificat. O comparație a performanței lor specifice poate fi văzută în tabelul de mai jos.

Compararea performanței în timp a metodelor de verificare a datelor, sursă imagine: Verkle Trees

3.4 Middleware general DA

Expansiunea continuă a ecosistemului blockchain a dus la creșterea continuă a numărului de lanțuri publice. Datorită avantajelor și a caracterului de neînlocuit al fiecărui lanț public în domeniile lor respective, este aproape imposibil ca lanțurile publice de nivel 1 să se unifice într-o perioadă scurtă de timp. Cu toate acestea, odată cu dezvoltarea DeFi și diversele probleme cu CEX, cerințele utilizatorilor pentru activele de tranzacționare descentralizate cross-chain cresc și ele. Prin urmare, stocarea datelor cu mai multe lanțuri la nivel DA, care poate elimina problemele de securitate în interacțiunile de date încrucișate, a primit din ce în ce mai multă atenție. Cu toate acestea, pentru a accepta date istorice din diferite lanțuri publice, nivelul DA trebuie să ofere un protocol descentralizat pentru stocarea standardizată și verificarea fluxurilor de date. De exemplu, kvye, un middleware de stocare bazat pe Arweave, preia în mod activ datele din lanț și poate toate. Datele din lanț sunt stocate în Arweave într-o formă standard pentru a minimiza diferențele în procesul de transmitere a datelor. Relativ vorbind, Layer2, care oferă în mod specific stocarea datelor la nivel DA pentru un anumit lanț public, interacționează cu datele prin noduri partajate interne Deși reduce costul interacțiunii și îmbunătățește securitatea, are limitări relativ mari și poate furniza date numai unui anumit public. lanțurile oferă servicii.

4. Soluție de stocare a stratului DA

4.1 Lanțul principal DA

4.1.1 Clasa DankSharding

Acest tip de soluție de stocare nu are încă un nume definit, iar cel mai proeminent reprezentant este DankSharding pe Ethereum, așa că acest articol folosește clasa DankSharding pentru a se referi la acest tip de soluție. Acest tip de soluție folosește în principal cele două tehnologii de stocare DA menționate mai sus, Sharding și DAS. Mai întâi, datele sunt împărțite în partajări corespunzătoare prin Sharding, iar apoi fiecare nod extrage un bloc de date sub formă de DAS pentru stocare. Dacă există suficiente noduri în întreaga rețea, putem alege un număr mai mare de fragmente N, astfel încât presiunea de stocare a fiecărui nod să fie de numai 1/N față de cea originală, realizând astfel extinderea de N ori a spațiului de stocare total. În același timp, pentru a preveni situația extremă în care un anumit Bloc nu este stocat în niciun bloc, DankSharding codifică datele folosind Eraser Code și doar jumătate din date pot fi complet restaurate. Ultimul pas este procesul de verificare a datelor, care utilizează structura arborelui Verkle și angajamentul polinom pentru a realiza o verificare rapidă.

4.1.2 Depozitare pe termen scurt

Pentru DA din lanțul principal, una dintre cele mai simple metode de prelucrare a datelor este stocarea datelor istorice pe termen scurt. În esență, blockchain-ul joacă rolul unui registru public, permițând ca modificările aduse conținutului registrului să fie asistate de întreaga rețea, fără a fi nevoie de stocare permanentă. Luând ca exemplu Solana, deși datele sale istorice sunt sincronizate cu Arweave, nodul mainnet reține doar datele tranzacțiilor din ultimele două zile. Pe lanțul public bazat pe înregistrările contului, datele istorice în fiecare moment păstrează starea finală a contului pe blockchain, ceea ce este suficient pentru a oferi o bază de verificare pentru modificări în momentul următor. Pentru proiectele care au nevoi speciale de date înainte de această perioadă de timp, acestea le pot stoca ei înșiși pe alte lanțuri publice descentralizate sau de către o terță parte de încredere. Cu alte cuvinte, cei care au nevoie de date suplimentare trebuie să plătească pentru stocarea datelor istorice.

4.2 DA terță parte

4.2.1 DA specific lanțului principal: EthStorage

  • DA dedicat pentru lanțul principal: Cel mai important lucru despre nivelul DA este securitatea transmisiei de date. Cel mai sigur în acest moment este DA-ul lanțului principal. Cu toate acestea, stocarea în lanț principal este supusă limitărilor de spațiu de stocare și concurenței pentru resurse. Prin urmare, atunci când cantitatea de date din rețea crește rapid, DA terță parte va fi o alegere mai bună dacă se dorește să se realizeze stocarea pe termen lung. Dacă DA terță parte are o compatibilitate mai mare cu rețeaua principală, poate realiza partajarea nodurilor și va avea, de asemenea, o securitate mai mare în timpul procesului de interacțiune a datelor. Prin urmare, sub premisa luării în considerare a securității, DA specifică lanțului principal va avea avantaje uriașe. Luând Ethereum ca exemplu, o cerință de bază pentru DA specific lanțului principal este să fie compatibil cu EVM și să asigure interoperabilitatea cu datele și contractele Ethereum. Proiectele reprezentative includ Topia, EthStorage etc. Dintre acestea, EthStorage este în prezent cel mai bine dezvoltat în ceea ce privește compatibilitatea, deoarece, pe lângă compatibilitatea la nivel EVM, a creat special și interfețe relevante pentru a se conecta cu instrumentele de dezvoltare Ethereum precum Remix și Hardhat pentru a obține compatibilitate la nivel de Nivelul instrumentului de dezvoltare Ethereum.

  • EthStorage: EthStorage este un lanț public independent de Ethereum, dar nodurile care rulează pe acesta sunt superioare nodurilor Ethereum, adică nodurile care rulează EthStorage pot rula și Ethereum în același timp. Prin codurile de operare de pe Ethereum, puteți accesa direct EthStorage EthStorage efectuează operațiuni. În modelul de stocare al EthStorage, doar o mică cantitate de metadate este reținută pe rețeaua principală Ethereum pentru indexare, creând în esență o bază de date descentralizată pentru Ethereum. În soluția actuală, EthStorage implementează interacțiunea dintre rețeaua principală Ethereum și EthStorage prin implementarea unui Contract EthStorage în rețeaua principală Ethereum. Dacă Ethereum dorește să stocheze date, trebuie să apeleze funcția put() din contract. Parametrii de intrare sunt cheia și data variabilelor de doi octeți, unde datele reprezintă datele de stocat, iar cheia este locația acesteia în rețeaua Ethereum. Identificarea 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 și îl va returna în rețeaua principală Ethereum, corespunzătoare cheii de pe Ethereum. Această valoare corespunde adresei de stocare a datelor de pe EthStorage , așa că este posibil inițial Problema necesității de a stoca cantități mari de date devine acum stocarea unei singure perechi (cheie, kvldx), reducând astfel 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. Puteți căuta rapid datele pe EthStorage prin kvldx stocate în Ethereum.

Contract EthStorage, sursa imagine: Kernel Ventures

  • În ceea ce privește modul în care nodurile stochează în mod specific datele, EthStorage se bazează pe modelul Arweave. În primul rând, un număr mare de perechi (k, v) de la ETH sunt fragmentate. Fiecare fragment conține un număr fix de perechi de date (k, v). În acest fel, este asigurată corectitudinea sarcinii de lucru ulterioare pentru mineri în procesul de recompensare a stocării. Pentru emiterea recompenselor, este necesar să se verifice mai întâi dacă nodul stochează date. În timpul acestui proces, EthStorage va împărți un Sharding (dimensiunea nivelului TB) în mai multe bucăți și va păstra o rădăcină Merkle în rețeaua principală Ethereum pentru verificare. Apoi, minerul trebuie să furnizeze mai întâi un nonce pentru a genera adresele mai multor bucăți printr-un algoritm aleator cu hash-ul blocului anterior pe EthStorage. Minerul trebuie să furnizeze datele acestor bucăți pentru a dovedi că într-adevăr stochează întregul Sharding. Dar acest nonce nu poate fi selectat în mod arbitrar, altfel nodul va selecta un nonce adecvat care corespunde doar bucății sale stocate și va trece verificarea. Prin urmare, acest nonce trebuie să fie astfel încât valoarea de dificultate a fragmentului generat să poată îndeplini cerințele rețelei după amestecare și hashing și Numai primul nod care a trimis dovada nonce și acces aleatoriu poate obține recompensa.

4.2.2 Modular DA: Celestia

  • Modul Blockchain: În această etapă, tranzacțiile care trebuie efectuate de către lanțul public Layer1 sunt în principal împărțite în următoarele patru părți: (1) Proiectați logica de bază a rețelei, selectați nodurile de verificare într-un anumit mod, scrieți blocuri și alocați recompense pentru menținerii rețelei; (2) Împachetați și procesați tranzacțiile și publicați aspectele conexe (3) Verificați tranzacțiile care vor fi încărcate în lanț și determinați starea finală; În funcție de diferitele funcții finalizate, putem împărți blockchain-ul în patru module, și anume stratul de consens, stratul de execuție, stratul de decontare și stratul de disponibilitate a datelor (stratul DA).

  • Design blockchain modular: de mult timp, aceste patru module au fost integrate într-un lanț public. Un astfel de blockchain se numește un singur blockchain. Această formă este mai stabilă și mai ușor de întreținut, dar pune și o presiune uriașă asupra unui singur lanț public. În timpul funcționării efective, aceste patru module se constrâng reciproc și concurează pentru resursele limitate de calcul și stocare ale lanțului public. De exemplu, pentru a crește viteza de procesare a stratului de procesare, va aduce o presiune mai mare de stocare a stratului de disponibilitate a datelor pentru a asigura securitatea stratului de execuție, este necesar un mecanism de verificare mai complex, dar încetinește viteza de procesare a tranzacției; Prin urmare, dezvoltarea lanțurilor publice se confruntă adesea cu compromisuri între aceste patru module. Pentru a depăși blocajul îmbunătățirii performanței lanțului public, dezvoltatorii au propus o soluție blockchain modulară. Ideea de bază a blockchain-ului modular este de a separa unul sau mai multe dintre cele patru module menționate mai sus și de a le implementa într-un lanț public separat. În acest fel, lanțul public se poate concentra doar 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 deficiențelor.

  • Modular DA: Metoda complexă de separare a stratului DA de afacerea blockchain și de a-l preda unui lanț public este considerată o soluție fezabilă pentru datele istorice în creștere ale Layer1. Explorarea în această zonă este încă în faze incipiente în această etapă, iar cel mai reprezentativ proiect în prezent este Celestia. În ceea ce privește metoda de stocare specifică, Celestia se bazează pe metoda de stocare a Danksharding, care împarte și datele în mai multe blocuri, iar fiecare nod extrage o parte pentru stocare și folosește angajamentul polinom KZG pentru a verifica integritatea datelor. În același timp, Celestia folosește un cod avansat de ștergere RS bidimensional pentru a rescrie datele originale sub forma unei matrice k*k În cele din urmă, doar 25% din datele originale pot fi recuperate. Cu toate acestea, stocarea de fragmentare a datelor în esență multiplică presiunea de stocare a întregului nod de rețea cu un coeficient asupra volumului total de date. Presiunea de stocare a nodului și volumul de date mențin în continuare o creștere liniară. Pe măsură ce stratul 1 continuă să-și îmbunătățească viteza tranzacțiilor, presiunea de stocare a nodurilor poate ajunge la un nivel critic inacceptabil într-o zi. Pentru a rezolva această problemă, componenta IPLD este introdusă în Celestia pentru procesare. Datele din matricea k*k nu sunt stocate direct pe Celestia, ci sunt stocate în rețeaua LL-IPFS și doar codul CID al datelor de pe IPFS este reținut în nod. Când un utilizator solicită o bucată de date istorice, nodul va trimite CID-ul corespunzător la componenta IPLD, iar datele originale vor fi apelate pe IPFS prin acest CID. Dacă datele există pe IPFS, acestea vor fi returnate prin componenta și nodul IPLD, dacă nu există, datele nu pot fi returnate.

Metoda de citire a datelor Celestia, sursa imaginii: Celestia Core

  • Celestia: Luând Celestia ca exemplu, putem obține o privire asupra aplicării blockchain-ului modular în rezolvarea problemei de stocare a Ethereum. Nodul Rollup va trimite datele de tranzacție împachetate și verificate către Celestia și va stoca datele pe Celestia În timpul acestui proces, Celestia stochează doar datele fără o conștientizare excesivă. Tokenurile tia corespunzătoare vor fi plătite către Celestia ca taxe de stocare. Stocarea din Celstia utilizează coduri DAS și de ștergere similare cu cele din EIP4844, dar codurile de ștergere polinomiale din EIP4844 sunt actualizate și codurile de ștergere bidimensionale RS sunt folosite pentru a îmbunătăți din nou securitatea stocării. Doar 25% dintre fracturi pot restabili datele întregii tranzacții. În esență, este doar un lanț public POS cu costuri reduse de stocare. Dacă urmează să fie utilizat pentru a rezolva problema de stocare a datelor istorice a Ethereum, sunt necesare multe alte module specifice pentru a coopera cu Celestia. De exemplu, în ceea ce privește rollup-ul, un mod de rollup foarte recomandat pe site-ul oficial Celestia este Sovereign Rollup. Spre deosebire de Rollup obișnuit pe Layer 2, tranzacțiile sunt doar calculate și verificate, adică operațiunile de la nivelul de execuție sunt finalizate. Sovereign Rollup include întregul proces de execuție și decontare, ceea ce minimizează procesarea tranzacțiilor pe Celestia Când securitatea generală a Celestia este mai slabă decât Ethereum, această măsură poate maximiza securitatea procesului general de tranzacție. În ceea ce privește asigurarea securității datelor numite de Celestia, rețeaua principală a Ethereum, cea mai populară soluție în acest moment este contractul inteligent al podului gravitațional cuantic. Pentru datele stocate pe Celestia, acesta va genera o rădăcină Merkle (dovada disponibilității datelor) și o va păstra pe contractul de punte gravitațională cuantică a rețelei principale Ethereum De fiecare dată când Ethereum apelează datele istorice pe Celestia, rezultatul său hash va fi comparat cu Merkle Root este folosit pentru comparație, iar dacă se potrivește, înseamnă că este într-adevăr date istorice reale.

4.2.3 Stocarea lanțului public DA

În ceea ce privește principiile tehnice ale lanțului principal DA, multe tehnologii similare cu Sharding sunt împrumutate din lanțul public de stocare. Printre DA terți, unii folosesc direct lanțul public de stocare pentru a finaliza unele sarcini de stocare. De exemplu, datele specifice ale tranzacțiilor din Celestia sunt plasate în rețeaua LL-IPFS. În soluția DA terță parte, 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 cu Layer1 pentru a stoca datele istorice uriașe pe Layer1. Pentru blockchain-urile de înaltă performanță, volumul datelor istorice este și mai mare Când rulează la 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. Soluția pe care a ales-o Solana este să stocheze datele istorice pe rețeaua de stocare descentralizată Arweave și să rețină doar 2 zile de date pe nodurile principale ale rețelei pentru verificare. Pentru a asigura securitatea procesului stocat, Solana și Arweave Chain au conceput special un protocol de punte de stocare, Solar Bridge. Datele verificate de nodul Solana vor fi sincronizate cu Arweave și va fi returnată eticheta corespunzătoare. Doar prin această etichetă, nodul Solana poate vizualiza oricând datele istorice ale blockchain-ului Solana. Pe Arweave, nu este nevoie ca toate nodurile din rețea să mențină consistența datelor și să utilizeze acest prag pentru a participa la operarea rețelei. În primul rând, Arweave nu folosește o structură tradițională în lanț pentru a construi blocuri, ci este mai asemănătoare cu o structură grafică. În Arweave, un nou bloc nu va indica doar blocul anterior, ci și în mod aleatoriu către un bloc generat Recall Block. Locația specifică a blocului de retragere este determinată de rezultatul hash al blocului său anterior și de înălțimea blocului său. Locația blocului de retragere este necunoscută până când blocul anterior este extras. Cu toate acestea, în procesul de generare a unui nou bloc, nodul trebuie să aibă date Recall Block pentru a utiliza mecanismul POW pentru a calcula hash-ul de dificultate specificată Numai primul miner care calculează hash-ul care îndeplinește dificultatea poate obține recompensa. care îi încurajează pe mineri să stocheze cât mai multe date istorice. În același timp, cu cât sunt mai puține persoane care stochează un anumit bloc istoric, nodurile vor avea mai puțini concurenți atunci când vor genera non-uri care îndeplinesc dificultatea, încurajând minerii să stocheze mai puține blocuri în rețea.În cele din urmă, pentru a se asigura că nodurile stochează permanent date în Arweave, introduce mecanismul de notare a nodurilor WildFire. Nodurile vor avea tendința de a comunica mai rapid cu noduri care pot furniza mai multe date istorice, în timp ce nodurile cu evaluări mai scăzute nu pot obține cele mai recente date despre blocuri și tranzacții cât mai curând posibil și, prin urmare, nu pot profita de concurența POW.

Metoda de construcție a blocului Arweave, sursa imagine: Arweave Yellow-Paper

5. Comparație cuprinzătoare

În continuare, vom compara avantajele și dezavantajele celor cinci soluții de stocare pe baza celor patru dimensiuni ale indicatorilor de performanță DA.

  • Securitate: Cea mai mare sursă de probleme de securitate a datelor este pierderea cauzată în timpul procesului de transmitere a datelor și manipularea rău intenționată de la nodurile necinstite. zonele cele mai afectate. În plus, Layer 1, care necesită în prezent un strat DA dedicat, are adesea un grup de consens puternic, iar propria sa securitate 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. Dacă sunt luate în considerare doar datele istorice pe termen scurt utilizate pentru verificarea tranzacțiilor, aceleași date sunt susținute de întreaga rețea în rețeaua de stocare temporară numărul de noduri din întreaga rețea, mai multă redundanță a datelor poate face mai puțin probabil ca datele să fie pierdute și, de asemenea, poate oferi mai multe mostre de referință în timpul verificării. Prin urmare, stocarea temporară va avea relativ o securitate mai mare a datelor. În soluția DA terță parte, DA specifică lanțului principal utilizează noduri publice cu lanțul principal, iar datele pot fi transmise direct prin aceste noduri releu în timpul procesului de lanț încrucișat, astfel încât va avea o securitate relativ mai mare decât alte soluții DA .

  • Costuri de stocare: Cel mai mare factor care afectează costurile de stocare este cantitatea de redundanță a datelor. În soluția de stocare pe termen scurt a lanțului principal DA, aceasta este stocată sub formă de sincronizare a datelor întregului nod de rețea. Orice date nou stocate trebuie să fie salvate în toate nodurile rețelei, care are cel mai mare cost de stocare. Costul mare de stocare determină, la rândul său, că această metodă este potrivită doar pentru stocarea temporară în rețele TPS înalt. A doua este metoda de stocare a Sharding, inclusiv Sharding în lanțul principal și Sharding în DA terță parte. Deoarece lanțul principal are adesea mai multe noduri, un bloc corespunzător va avea și mai multe copii de rezervă, astfel încât soluția de Sharding a lanțului principal va avea costuri mai mari. Cel mai mic cost de stocare este lanțul public de stocare DA care adoptă o metodă de stocare a recompensei În cadrul acestei scheme, cantitatea de redundanță a datelor fluctuează adesea în jurul unei constante fixe. În același timp, în lanțul public de stocare DA este introdus și un mecanism de ajustare dinamică pentru a atrage noduri care să stocheze mai puține date de rezervă prin creșterea recompenselor pentru a asigura securitatea datelor.

  • Viteza de citire a datelor: viteza de stocare a datelor este afectată în principal de locația de stocare a datelor în spațiul de stocare, calea indexului de date și distribuția datelor în noduri. Printre acestea, locația de stocare a datelor pe nod are un impact mai mare asupra vitezei, deoarece stocarea datelor în memorie sau SSD poate face ca viteza de citire să difere de zeci de ori. Stocarea lanțului public DA folosește în cea mai mare parte stocarea SSD, deoarece încărcarea pe acest lanț nu include doar datele stratului DA, ci include și date personale cu utilizare mare a memoriei, cum ar fi videoclipuri și imagini încărcate de utilizatori. Dacă rețeaua nu folosește SSD ca spațiu de stocare, va fi dificil să suportați o presiune uriașă de stocare și să satisfacă nevoile de stocare pe termen lung. În al doilea rând, pentru DA terță parte și DA din lanțul principal care utilizează starea memoriei pentru a stoca date, DA terță parte trebuie mai întâi să caute datele de index corespunzătoare în lanțul principal și apoi să transfere datele de index de-a lungul lanțului la al treilea. -partă DA și returnează-l prin datele de punte de stocare. În schimb, lanțul principal DA poate interoga direct datele de la noduri și, prin urmare, are o viteză mai rapidă de recuperare a datelor. În cele din urmă, în cadrul lanțului principal DA, metoda Sharding necesită apelarea Block de la mai multe noduri și restaurarea datelor originale. Prin urmare, în comparație cu stocarea pe termen scurt fără stocare fragmentată, viteza va fi mai mică.

  • Universalitatea stratului DA: Universalitatea DA a lanțului principal este aproape de zero, deoarece este imposibil să transferați date dintr-un lanț public cu spațiu de stocare insuficient către un alt lanț public cu spațiu de stocare insuficient. În DA terță parte, versatilitatea unei soluții și compatibilitatea acesteia cu un anumit lanț principal sunt indicatori contradictori. De exemplu, în soluția DA specifică lanțului principal concepută pentru un anumit lanț principal, s-au făcut o mulțime de îmbunătățiri la nivel de consens de tip de nod și de rețea pentru a se adapta la lanțul public. Prin urmare, aceste îmbunătățiri vor juca un rol în comunicare cu alte lanţuri publice o piedică uriaşă. În cadrul DA terță parte, lanțul public de stocare DA are performanțe mai bune în ceea ce privește versatilitatea, comparativ cu DA modular. Lanțul public de depozitare DA are o comunitate de dezvoltatori mai mare și mai multe facilități de expansiune, care se pot adapta la condițiile diferitelor lanțuri publice. În același timp, lanțul public de stocare DA achiziționează date mai activ prin captarea pachetelor, mai degrabă decât să primească pasiv informații transmise de la alte lanțuri publice. Prin urmare, poate codifica datele în felul său, poate realiza stocarea standardizată a fluxurilor de date, poate facilita gestionarea informațiilor de date din diferite lanțuri principale și poate îmbunătăți eficiența stocării.

Comparația performanței soluției de stocare, sursă imagine: Kernel Ventures

6. Rezumat

Actualul blockchain trece de la Crypto la Web3 mai incluziv. Acest proces aduce nu numai o bogăție de proiecte pe blockchain. Pentru a permite funcționarea simultană a atâtor proiecte pe Layer1, asigurând în același timp experiența proiectelor Gamefi și Socialfi, Layer1 reprezentat de Ethereum a adoptat metode precum Rollup și Blobs pentru a îmbunătăți TPS. Printre noile blockchain-uri, numărul de blockchain-uri de înaltă performanță este, de asemenea, în creștere. Dar TPS mai mare nu înseamnă doar performanță mai mare, ci și o presiune mai mare de stocare în rețea. Pentru date istorice masive, sunt propuse în prezent diferite metode DA bazate pe lanțul principal și terți pentru a se adapta la creșterea presiunii de stocare în lanț. Fiecare metodă de îmbunătățire are avantaje și dezavantaje și are aplicabilitate diferită în diferite situații.

Blockchain-urile care se concentrează pe plată au cerințe extrem de ridicate pentru securitatea datelor istorice și nu urmăresc TPS deosebit de ridicat. Dacă acest tip de lanț public este încă în stadiu de pregătire, se poate adopta o metodă de stocare asemănătoare DankSharding, care poate realiza o creștere uriașă a capacității de stocare, asigurând în același timp securitatea. Cu toate acestea, dacă este un lanț public precum Bitcoin care a prins deja contur și are un număr mare de noduri, există riscuri uriașe în îmbunătățirile erupții la nivelul consensului. Prin urmare, lanțul principal a dedicat DA cu o securitate mai mare în stocarea off-chain poate fi folosit pentru a echilibra problemele de securitate și stocare. Dar este de remarcat faptul că funcțiile blockchain nu sunt statice, ci se schimbă constant. De exemplu, funcțiile timpurii ale Ethereum s-au limitat în principal la plăți și la procesarea automată simplă a activelor și a tranzacțiilor folosind contracte inteligente într-o direcție mai cuprinzătoare. Recent, odată cu explozia ecologiei de inscripție pe Bitcoin, taxele de tranzacție ale rețelei Bitcoin au crescut de aproape 20 de ori din august. Acest lucru reflectă faptul că viteza de tranzacție a rețelei Bitcoin în această etapă nu poate satisface cererea de tranzacții, iar comercianții pot doar Creșterea taxelor face ca tranzacțiile să fie procesate cât mai repede posibil. Acum, comunitatea Bitcoin trebuie să facă un compromis, fie să accepte comisioane mari și viteze reduse de tranzacție, fie să reducă securitatea rețelei pentru a crește vitezele de tranzacție, dar să învingă intenția inițială a sistemului de plăți. Dacă comunitatea Bitcoin o alege pe cea din urmă, atunci, în fața presiunii în creștere a datelor, soluția de stocare corespunzătoare va trebui și ea ajustată.

Taxele de tranzacție pe rețeaua principală Bitcoin fluctuează, sursa imagine: OKLINK

Pentru lanțurile publice cu funcții cuprinzătoare, aceștia au o căutare mai mare pentru TPS, iar creșterea datelor istorice este și mai mare. Este dificil să se adapteze la creșterea rapidă a TPS pe termen lung prin adoptarea unei soluții precum DankSharding. Prin urmare, o modalitate mai adecvată este migrarea datelor către un DA terță parte pentru stocare. Dintre acestea, DA specifică lanțului principal are cea mai mare compatibilitate și poate avea mai multe avantaje dacă sunt luate în considerare doar problemele de stocare ale unui singur lanț public. Dar astăzi, când lanțurile publice de nivel 1 înfloresc, transferul de active încrucișat și interacțiunea datelor au devenit o activitate comună a comunității blockchain. Dacă se ia în considerare dezvoltarea pe termen lung a întregului ecosistem blockchain, stocarea datelor istorice ale diferitelor lanțuri publice pe același lanț public poate elimina multe probleme de securitate în procesul de schimb și verificare a datelor. Prin urmare, diferența dintre DA modular și stocare Lanțul public DA mod ar putea fi o alegere mai bună. Pe premisa unei versatilități apropiate, modular DA se concentrează pe furnizarea de servicii de nivel blockchain DA, introducând date istorice de gestionare a datelor de index mai rafinate, care pot clasifica în mod rezonabil diferite date din lanțul public și să stocheze date din lanțul public. Are mai multe avantaje. Cu toate acestea, soluția de mai sus nu ia în considerare costul ajustării stratului de consens pe lanțul public existent. Acest proces este extrem de riscant, odată ce apar probleme, poate duce la vulnerabilități sistemice și poate duce la pierderea consensului comunității. Prin urmare, dacă este o soluție de tranziție în timpul procesului de expansiune blockchain, cea mai simplă stocare temporară a lanțului principal poate fi mai potrivită. În cele din urmă, discuția de mai sus se bazează pe performanța în timpul funcționării efective. Cu toate acestea, dacă scopul unui anumit lanț public este de a-și dezvolta propria ecologie și de a atrage mai multe părți și participanți la proiect, poate prefera, de asemenea, proiectele care sunt susținute și finanțate de propriile sale ecologie. fundație. De exemplu, atunci când performanța generală este echivalentă sau chiar puțin mai mică decât cea a soluțiilor de stocare în lanț public, comunitatea Ethereum va avea tendința, de asemenea, de proiecte de Layer 2 susținute de Fundația Ethereum, cum ar fi EthStorage, pentru a continua să dezvolte ecosistemul Ethereum.

Una peste alta, funcțiile blockchain-ului de astăzi devin din ce în ce mai complexe, ceea ce aduce și cerințe mai mari de spațiu de stocare. Când există suficiente noduri de verificare Layer1, datele istorice nu trebuie să fie copiate de toate nodurile din întreaga rețea Numai atunci când numărul de copii de siguranță atinge o anumită valoare poate fi garantată securitatea relativă. În același timp, diviziunea muncii în lanțul 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 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 altor părți. Cu toate acestea, cât de mult să stocați sau ce proporție de noduri pentru a stoca datele istorice poate atinge un echilibru între securitate și eficiență și cum să se asigure interoperabilitatea în siguranță între diferitele blockchain-uri. Pentru investitori, puteți acorda atenție proiectului DA specific lanțului principal pe Ethereum, deoarece Ethereum are deja destui susținători în această etapă și nu trebuie să se bazeze pe alte comunități pentru a-și extinde influența. Ceea ce este mai necesar este să vă îmbunătățiți și să vă dezvoltați propria comunitate și să atrageți mai multe proiecte în ecosistemul Ethereum. Cu toate acestea, pentru lanțurile publice aflate în poziție de recuperare, cum ar fi Solana și Aptos, lanțul unic în sine nu are o ecologie atât de completă, așa că poate fi mai înclinat să-și unească forțele cu alte comunități pentru a construi o ecologie uriașă încrucișată. pentru a extinde influența. Prin urmare, pentru stratul emergent 1, DA generală terță parte merită mai multă atenție.

Kernel Ventures este un fond de capital de risc cripto condus de comunitatea de cercetare și dezvoltare, cu peste 70 de investiții în stadiu incipient concentrate pe infrastructură, middleware, dApps, în special ZK, Rollup, DEX, blockchain modulare și zone verticale pentru miliarde de utilizatori cripto în viitor, cum ar fi abstracția contului, disponibilitatea datelor, scalabilitate 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țe

  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. Site-ul oficial Arweave: https://www.arweave.org/

  9. Arweave Yellow Paper: https://www.arweave.org/yellow-paper.pdf