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.
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 .
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:
| Funcţie | Stivă ipotetică de ArcadeRollup | Ce face componenta |
|---|---|---|
| Execuţie | ArcadeRollup | Rulează tranzacții în joc și actualizează starea aplicației. |
| Așezare | Un strat separat L1 sau strat de așezare | Rezolvă angajamentele de stare și sistemul de dovezi ale cumulării. |
| Consens | Set de validare Celestia | Este de acord asupra ordinii blocurilor Celestia. |
| Disponibilitatea datelor | Celestia | Publică datele cumulate, astfel încât participanții să poată verifica dacă au fost puse la dispoziție. |
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.
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.
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 .
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.
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 .
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:
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.
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.
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 .
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:
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.
Î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.
Expresia în sine nu este suficientă. Revenind la ArcadeRollup, o analiză tehnică utilă ar pune mai multe întrebări separate:
Aceste întrebări ajută la separarea sintagmei de marketing „integrare Celestia” de arhitectura propriu-zisă.
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ă.
O evaluare practică din 2026 a EVM paralel al Monad, a tracțiunii ecosistemului, a compromisurilor dezvoltatorilor și a modului în care se compară cu Ethereum, Sei și MegaETH.
O analiză practică și detaliată a Celestia, care explică blockchain-urile modulare, eșantionarea disponibilității datelor, spațiile de nume, Blobstream, utilitatea TIA și compromisurile pe care le moștenesc cumulările de opțiuni.
Explorează ecosistemul Base în 2026, de la Aerodrome și Morpho la Aave, Uniswap, Virtuals, Zora, Moonwell și plățile prin agenți x402.
Analizați tranziția Sonic a Fantom, migrarea de la FTM la S, arhitectura Sonic, tokenomica, stimulentele pentru dezvoltatori, impactul asupra ecosistemului și riscurile care contează în continuare în 2026.
O analiză practică din 2026 a randamentului nativ Blast L2, a mecanicii ETH și USDB, a modificărilor protocolului ecosistemului, a riscurilor actuale și a modului de verificare a oportunităților înainte de a angaja capital.
O analiză actuală a Polygon 2.0, actualizarea POL, Polygon PoS, AggLayer, închiderea zkEVM din 2026 și motivele pentru care s-a schimbat povestea originală a migrării ZK-rollup.
O analiză Arbitrum (ARB) actuală care acoperă furnizarea de tokenuri, acordarea drepturilor, utilitatea guvernanței, Stylus, lanțurile Arbitrum, actualizările ArbOS, riscurile și foaia de parcurs pentru 2026.
O analiză practică și detaliată a stivei de abstractizare a lanțurilor protocolului NEAR, a intențiilor NEAR, a semnăturilor în lanț, a inteligenței artificiale confidențiale, a agenților autonomi și a compromisurilor de urmărit în 2026.
Analiză practică a rețelei Sei care acoperă compatibilitatea EVM, execuția paralelă, foaia de parcurs Giga, lichiditatea DeFi, compromisurile și cui i s-ar putea potrivi lanțul.
O analiză practică EigenLayer care acoperă restaking-ul, AVS-urile, recompensele, seturile de operatori, slash-ul, întârzierile la retragere și due diligence ajustată la risc.
