Analiză aprofundată a Celestia (TIA): Cum funcționează de fapt arhitectura modulară Blockchain

Celestia este cel mai bine înțeleasă ca un blockchain specializat pentru consens și disponibilitatea datelor, nu ca un lanț de execuție cu scop general. În loc să ceară fiecărui validator de nivel de bază să execute fiecare tranzacție a aplicației, Celestia permite ca seturile de date să se execute în altă parte, publicând în același timp datele tranzacțiilor către Celestia, astfel încât oricine să poată verifica dacă datele au fost puse la dispoziție.

Acest articol folosește un exemplu ipotetic clar etichetat pe tot parcursul lucrării: ArcadeRollup , un set imaginar de jocuri care procesează mii de acțiuni ale jucătorilor în afara căii de execuție Celestia, își stabilește starea pe un alt lanț și utilizează Celestia pentru disponibilitatea datelor. ArcadeRollup nu este o implementare reală, un benchmark de performanță, un caz de client sau o aprobare. Este pur și simplu un instrument didactic pentru înțelegerea stivei modulare.

Ideea centrală: joburi separate în blockchain în loc să facem un singur lanț să facă totul

Un blockchain monolitic tradițional tinde să grupeze mai multe responsabilități în același strat de bază: executarea tranzacțiilor, decontarea, consensul și disponibilitatea datelor. Arhitectura Celestia separă aceste funcții astfel încât straturile specializate să poată îndeplini sarcini diferite.

Documentația proprie a Celestia descrie rețeaua ca un strat modular de disponibilitate a datelor. Stratul său de bază gestionează consensul privind ordonarea datelor și face ca aceste date să fie disponibile. Execuția și decontarea pot avea loc deasupra sau în afara Celestia. Acest lucru este important deoarece execuția este adesea partea costisitoare, specifică aplicației, a unei stive blockchain. Un rollup își poate alege propria mașină virtuală, logică de secvențiere, sistem rezistent la fraudă sau validitate și mediu de decontare fără a fi nevoie ca validatorii Celestia să execute logica aplicației rollup-ului.

Pentru descrierea tehnică principală, consultați documentația oficială Celestia privind disponibilitatea datelor .

Exemplu ipotetic: ce trimite ArcadeRollup de fapt către Celestia

Imaginează-ți că ArcadeRollup rulează un joc de strategie în timp real. Jucătorii trimit mutări, schimburi, acțiuni de crafting și rezultate ale meciurilor. Secvențiatorul ArcadeRollup primește aceste tranzacții și le execută conform regulilor jocului. Această execuție modifică starea cumulului: soldurile se mișcă, stocurile se modifică și clasamentele se actualizează.

Celestia nu trebuie să ruleze din nou acele reguli de joc. În schimb, ArcadeRollup împachetează datele tranzacțiilor în blocuri (blobs) și le publică în Celestia. Celestia ordonează blocurile și pune la dispoziție datele aferente. Un strat separat de decontare poate primi angajamente de stare și dovezi de la ArcadeRollup, în funcție de designul cumulării.

Această diviziune poate fi rezumată astfel:

Punctul important din punct de vedere arhitectural este că utilizarea Celestia pentru DA nu înseamnă că Celestia execută și setul de date . Setul de date rămâne responsabil pentru mediul său de execuție și pentru propria logică de tranziție de stare.

De ce este disponibilitatea datelor atât de importantă

O acumulare poate fi verificată independent doar dacă datele necesare pentru reconstrucția stării sale sunt disponibile. Să presupunem că secvențiatorul ArcadeRollup publică o nouă stare rădăcină, dar reține tranzacțiile care au produs-o. Utilizatorii și verificatorii pot ști că există o angajament, dar nu pot reconstrui independent ce s-a întâmplat.

Aceasta este problema disponibilității datelor. Celestia este concepută astfel încât participanții să poată avea încredere că datele bloc au fost publicate fără ca fiecare nod de lumină să descarce blocul complet.

Eșantionarea disponibilității datelor

Celestia utilizează eșantionarea disponibilității datelor (DAS) . Datele bloc sunt extinse cu codare de ștergere bidimensională Reed-Solomon. Nodurile de lumină solicită apoi fragmente aleatorii, sau partajări, din pătratul de date extins, împreună cu dovezi criptografice. Dacă eșantioanele aleatorii repetate sunt returnate corect, nodul de lumină câștigă încredere că sunt disponibile suficiente date pentru reconstrucția întregului bloc.

Consecința practică este importantă: un nod ușor poate ajuta la verificarea disponibilității datelor fără a descărca fiecare octet din fiecare bloc. Prin urmare, modelul de scalare al Celestia se bazează parțial pe eșantionarea de porțiuni mici din date de către mulți participanți, în loc să solicite tuturor verificatorilor să reproducă complet totul.

Explicația oficială este disponibilă în documentația DAS a Celestia și în secțiunea Întrebări frecvente despre disponibilitatea datelor .

Spații de nume: cum mai multe cumulări partajează același strat DA

Dacă sute de seturi de date postează date într-o singură rețea DA, un set de date nu ar trebui să fie nevoie să descarce datele fiecărei alte aplicații doar pentru a-și găsi propriile date. Celestia abordează acest lucru cu arbori Merkle cu spațiu de nume .

Datele fiecărei aplicații pot fi asociate cu un spațiu de nume. În exemplul ArcadeRollup, blocurile sale ar fi plasate sub spațiul de nume utilizat de acel rollup. Un nod interesat de ArcadeRollup poate apoi solicita datele relevante din spațiul de nume, împreună cu dovezi că răspunsul este complet pentru acel spațiu de nume.

Acesta este unul dintre motivele practice pentru care modelul modular poate suporta mai multe medii de execuție pe același strat DA: pot partaja spațiul de blocuri Celestia în timp ce preiau datele relevante pentru propria aplicație.

Ce face o tranzacție PayForBlobs

Semările publică date către Celestia folosind tranzacții blob. Documentația actuală descrie o tranzacție blob ca conținând o tranzacție standard Cosmos SDK, MsgPayForBlobsplus unul sau mai multe date blob. Tranzacția de plată include un angajament față de datele blob, în ​​timp ce datele propriu-zise sunt organizate în bloc sub spațiul de nume relevant.

În cazul nostru ipotetic, ArcadeRollup procesează periodic tranzacțiile jucătorilor, creează unul sau mai multe bulete (blob-uri) și plătește pentru publicarea lor. Celestia include apoi tranzacția și buletele asociate într-un bloc, aplică codificarea de disponibilitate a datelor și se confirmă asupra datelor rezultate.

Pentru structura și limitele actuale ale tranzacțiilor, consultați documentația oficială de trimitere a fișierelor blob de la Celestia și explicația acesteia privind plata pentru spațiul blob .

Unde se încadrează TIA în arhitectură

TIA este activul nativ al Celestiei, dar rolul său este mai amplu decât a fi un token speculativ de piață. Conform documentației actuale a Celestiei, TIA este utilizat în mai multe funcții de protocol:

• Taxe Blobspace: seturile plătesc taxe exprimate în TIA la trimiterea datelor prin tranzacții PayForBlobs.
• Securitate Proof-of-stake: TIA poate fi delegată validatorilor care participă la consensul Celestia.
• Guvernanță: TIA deținută în staking participă la guvernanța parametrilor rețelei și a fondului comunitar.
• Monedă opțională de cumul: o nouă cumulare poate alege să utilizeze TIA ca token sau monedă de gaz, în loc să emită imediat un token separat.

Prezentarea oficială TIA a Celestia documentează aceste roluri. Dintr-o perspectivă analitică, însă, utilitatea token-ului nu trebuie confundată cu o relație garantată față de prețul token-ului. Cererea de blobspace, economia mizării, emiterea, stimulentele validatorilor, adoptarea ecosistemului și condițiile mai largi ale pieței pot afecta rezultatele economice în mod diferit.

Blobstream: conectarea Celestia DA la mediile de decontare EVM

O provocare într-o stivă modulară este demonstrarea unui contract la nivelul de decontare că datele au fost de fapt publicate pe Celestia. Blobstream este conceput pentru această legătură între nivelul DA al Celestia și mediile EVM.

Documentația Celestia descrie Blobstream ca un sistem în care validatorii Celestia atestă angajamente asupra datelor, aceste atestări sunt transmise către un lanț EVM țintă, iar un contract inteligent poate verifica dacă a fost inclus un anumit angajament de date Celestia.

Pentru ArcadeRollup, imaginați-vă că decontarea are loc pe un lanț EVM. Contractul de decontare al cumulului necesită dovezi că datele tranzacției din spatele unei actualizări de stare au fost publicate pe Celestia. Blobstream poate furniza calea de verificare relevantă fără a forța lanțul de decontare să stocheze toate datele brute ale tranzacțiilor ArcadeRollup.

Consultați prezentarea oficială Blobstream de la Celestia pentru mecanismul actual și modelul de securitate.

Disponibilitatea nu este același lucru cu stocarea istorică permanentă

Aceasta este una dintre cele mai importante nuanțe în înțelegerea Celestia. Un strat DA dovedește că datele au fost publicate și disponibile în timpul ferestrei de verificare relevante. Asta nu înseamnă automat că fiecare element de date istorice va fi stocat pentru totdeauna de fiecare nod Celestia.

Documentația actuală de recuperare a datelor de la Celestia precizează că, începând cu celestia-app v6, eșantionarea nodurilor ușoare utilizează o fereastră continuă de șapte zile. Datele mai vechi pot fi eliminate de nodurile care nu sunt arhivabile. Prin urmare, aplicațiile care necesită o reconstrucție istorică pe termen lung au nevoie de o strategie explicită de recuperare, cum ar fi nodurile arhivabile sau furnizorii de date externi.

Pentru ArcadeRollup, aceasta înseamnă că echipa nu poate spune pur și simplu: „Celestia are datele noastre, așa că sincronizarea istorică este rezolvată pentru totdeauna”. Trebuie să decidă cum vor recupera noile noduri istoricul vechi de cumulare luni sau ani mai târziu.

Această distincție este documentată în ghidul Celestia privind recuperarea datelor și eliminarea acestora .

Ce îmbunătățește modularitatea - și ce aduce în altă parte

Arhitectura modulară este atractivă deoarece permite specializarea. ArcadeRollup își poate optimiza motorul de execuție pentru un joc, își poate alege propria politică de secvențiere și poate evita concurența cu aplicații fără legătură pentru capacitatea de execuție pe un lanț de bază monolitic. Celestia se poate specializa în consens și DA.

Însă modularitatea nu elimină complexitatea. O redistribuie. O agregare de producție trebuie să ia în continuare decizii cu privire la:

• proiectarea secvențiatorului și rezistența la cenzură;
• dovezi de fraudă, dovezi de validitate sau alte verificări de stat;
• stratul de decontare și ipotezele de finalitate;
• păstrarea datelor istorice și sincronizarea nodurilor;
• punți și mesagerie inter-lanț;
• modernizarea guvernanței și a procedurilor de urgență;
• expunerea la comisioane pentru spațiul de blob Celestia și orice costuri ale stratului de decontare.

Cu alte cuvinte, Celestia poate simplifica o problemă majoră de infrastructură – disponibilitatea scalabilă a datelor – dar nu oferă automat fiecare componentă necesară pentru o securizare a soluțiilor.

Starea actuală a rețelei Celestia în 2026

Începând cu septembrie 2026, documentația oficială a rețelei Celestia listează Mainnet Beta ca fiind activă și încă experimentală. Pagina actuală Mainnet Beta listează timpi de bloc de aproximativ trei secunde, o dimensiune maximă a tranzacției de 8 MiB și versiuni de software celestia-node v0.32.1. celestia-app v9.0.6Mainnet Beta a activat actualizarea v9 pe 1 iulie 2026, iar pagina oficială de actualizare precizează că v10 nu a fost încă programată.

Rețeaua s-a schimbat substanțial de la lansare, așa că articolele mai vechi despre Celestia pot descrie parametri care nu mai sunt actuali. De exemplu, actualizarea Matcha a crescut limitele și a introdus o cale către blocuri mult mai mari, în timp ce versiunile ulterioare au continuat dezvoltarea protocolului. Verificați întotdeauna parametrii actuali ai Mainnet Beta și istoricul oficial al actualizărilor de rețea înainte de a proiecta în jurul unei anumite limite.

Cum se evaluează o listare care spune că „folosește Celestia”

Expresia în sine nu este suficientă. Revenind la ArcadeRollup, o analiză tehnică utilă ar pune mai multe întrebări separate:

1. Ce se postează de fapt în Celestia? Date complete despre tranzacții, loturi comprimate, angajamente sau altceva?
2. Cât de des sunt postate datele? Cadența postării afectează latența, procesarea în loturi și comportamentul taxelor.
3. Unde are loc execuția? Celestia nu răspunde la această întrebare pentru cumul.
4. Unde are loc decontarea? O rollup suverană și o rollup cu decontare către un L1 extern au modele diferite de încredere și dispută.
5. Cum se verifică disponibilitatea? Se bazează stiva pe verificarea nativă a Celestia DA, Blobstream, o punte sau alt mecanism?
6. Cum sunt păstrate datele vechi? Un design credibil ar trebui să explice recuperabilitatea istorică, mai degrabă decât să presupună că toate nodurile luminoase sunt arhivabile.
7. Ce eșuează dacă Celestia este temporar indisponibilă? Cumularea ar trebui să aibă un model documentat de funcționare și recuperare.

Aceste întrebări ajută la separarea sintagmei de marketing „integrare Celestia” de arhitectura propriu-zisă.

Concluzie

Designul modular al Celestia este mai ușor de înțeles odată ce responsabilitățile sunt separate. Un rollup execută tranzacții. Un strat de decontare poate rezolva starea și dovezile rollup-ului. Celestia oferă consens asupra propriilor blocuri și un strat specializat de disponibilitate a datelor unde rollup-urile pot publica blocuri. Eșantionarea disponibilității datelor permite nodurilor ușoare să verifice probabilistic disponibilitatea fără a descărca blocuri întregi, în timp ce spațiile de nume permit aplicațiilor să își recupereze propriile date eficient.

În exemplul ipotetic ArcadeRollup, Celestia nu este motorul jocului și nu este neapărat instanța de soluționare. Este stratul de publicare și disponibilitate partajat care permite verificarea independentă a datelor tranzacționale ale cumulului de tranzacții, așa cum au fost publicate.

Această specializare este teza centrală din spatele Celestiei: blockchain-urile nu trebuie să fie o singură mașină care face fiecare sarcină. Ele pot fi stive de componente specializate. Compromisul este că dezvoltatorii și analiștii trebuie să înțeleagă interfețele - și ipotezele de securitate - dintre aceste componente, în loc să trateze „modular” ca o prescurtare pentru scalabilitate sau securitate automată.