Nakon tri godine razvoja, Firedancer je u prosincu 2024. počeo raditi na glavnoj mreži Solana, nakon što je već proizveo 50 000 blokova tijekom 100 dana testiranja na nekoliko validatora.
Prekretnica, objavljena 12. prosinca na Solaninom službenom računu, označava više od poboljšanja performansi. To predstavlja prvi stvarni pokušaj mreže da eliminira arhitektonsko usko grlo koje je poduprlo njezine najštetnije ispade: gotovo potpuno oslanjanje na jednog klijenta validatora.
Solana je proveo godine reklamirajući konačnost ispod sekunde i propusnost transakcija po sekundi od četiri znamenke, ali brzina malo znači kada 70% do 90% konsenzusne snage mreže pokreće isti softver.
Kritični bug u tom dominantnom klijentu može zaustaviti cijeli lanac, bez obzira koliko brzo teoretski radi. Ethereum je naučio ovu lekciju rano u prijelazu na proof-of-stake i sada tretira različitost klijenata kao infrastrukturnu higijenu o kojoj se ne može pregovarati.
Solana pokušava istu promjenu, ali kreće s daleko koncentriranije pozicije.
Firedancer nije zakrpa ili fork postojećeg Agave klijenta temeljenog na Rustu. To je temeljito prerađeno u C/C++, koje je napravio Jump Crypto s modularnom arhitekturom inspiriranom visokofrekventnim trgovanjem.
Dva klijenta nemaju zajednički kod, jezik i tim za održavanje. Ta neovisnost stvara posebnu domenu kvara: greška u Agaveovom upravljanju memorijom ili raspoređivaču transakcija, u teoriji, ne bi trebala srušiti validator koji pokreće Firedancer.
Za mrežu koja je doživjela sedam prekida rada u pet godina, od kojih je pet uzrokovano greškama na strani klijenta, to razdvajanje je bit.
Problem monokulture kojem Solana nije mogao pobjeći
Solanina povijest ispada čita se kao studija slučaja rizika jednog klijenta. Zaustavljanje u lipnju 2022. trajalo je četiri i pol sata nakon što je pogreška u značajci dugotrajnih jednokratnih transakcija uzrokovala neusklađenost validatora, što je zahtijevalo koordinirano ponovno pokretanje.
Ostali incidenti povezani su s curenjem memorije, prekomjernim dvostrukim transakcijama i uvjetima utrke u blok proizvodnji. Heliusova analiza cjelokupne povijesti ispada pripisuje pet od sedam kvarova greškama validatora ili klijenta, a ne greškama konsenzusnog dizajna.
Propusnost koju mreža oglašava postaje nevažna kada jedna pogreška u implementaciji može zamrznuti proizvodnju blokova.
Brojke potvrđuju izloženost. Izvješće o zdravstvenom stanju mreže Zaklade Solana iz lipnja 2025. pokazalo je da Agave i njezina Jito-modificirana varijanta kontroliraju otprilike 92% uloženog SOL-a.
Do listopada 2025. ta je brojka pala. Međutim, samo skromno: pregled udjela Cherry Servera i vodiči za višestruke validatore izvijestili su da Jito-Agave klijent i dalje drži preko 70% udjela, čak i kada je hibridni Frankendancer klijent narastao na oko 21% mreže.
Frankendancer koristi Firedancerov mrežni sloj s Agaveovim konsenzusnim backendom.
Unatoč tome što je i dalje manjina, podaci Cherry Servers pokazuju da je Frankendancerov udio porastao s otprilike 8% u lipnju. Ti dobici predstavljaju postojano usvajanje djelomičnog rješenja, ali puni Firedancer klijent koji stiže na mainnet u prosincu mijenja jednadžbu.
Validatori sada mogu pokrenuti potpuno neovisan skup, eliminirajući zajedničku ovisnost koja je prošle pogreške klijenta pretvorila u događaje na cijeloj mreži.
Ethereumovo iskustvo daje referentni model.
Dokumentacija o raznolikosti klijenata Zaklade Ethereum upozorava da svaki klijent koji kontrolira više od dvije trećine snage konsenzusa može jednostrano finalizirati netočne blokove. Osim toga, klijent iznad jedne trećine može u potpunosti spriječiti konačnost ako ode s mreže ili se ponaša nepredvidivo.
Zajednica Ethereuma držanje svih klijenata ispod 33% smatra strogim sigurnosnim zahtjevom, a ne optimizacijom. Solanina početna pozicija jednog klijenta koji se približava 90% sudjelovanja nalazi se daleko izvan te sigurnosne zone.
| Klijent | Jezik | Status | Udio udjela (listopad 2025.) | Validatori | Prava neovisnost |
|---|---|---|---|---|---|
| Jito | hrđati | Glavna mreža | ~72% | ~700+ | ❌ Vilica od agave |
| Frankendancer | C + hrđa | Glavna mreža | ~21% | 207 | ✅ Neovisan o hibridu |
| Agava | hrđati | Glavna mreža | ~7% | ~85 | ✅ Original |
| vatrogasac | C | Glavna mreža bez prava glasa | 0% | 0 | ✅ Potpuno neovisan |
Što Firedancer zapravo mijenja
Firedancer ponovno implementira Solanin validator cjevovod s arhitekturom posuđenom iz sustava trgovanja s niskom latencijom: pločice paralelne obrade, prilagođene mrežne primitive i upravljanje memorijom podešeno za determinističke performanse pod opterećenjem.
Referentne vrijednosti iz prezentacija na tehničkim konferencijama pokazale su da klijent obrađuje 600.000 do više od 1.000.000 transakcija u sekundi u kontroliranim testovima, znatno iznad Agaveove demonstrirane propusnosti.
Ali gornja granica izvedbe manje je važna od odvajanja domene kvara. Dokumentacija Firedancer i vodiči za postavljanje validatora opisuju klijenta kao modularnog dizajna, s različitim komponentama koje upravljaju umrežavanjem, sudjelovanjem u konsenzusu i izvršavanjem transakcija.
Greška oštećenja memorije u Agaveovom Rust allocatoru ne bi se proširila na Firedancerovu C++ bazu koda. Logička pogreška u Agaveovom blok rasporedu ne bi utjecala na Firedancerov model izvršenja temeljen na pločicama.
Dva klijenta mogu pasti neovisno, što znači da mreža može preživjeti katastrofalnu pogrešku u bilo kojem od njih sve dok raspodjela uloga sprječava da se supervećina istovremeno isključi iz mreže.
Implementacija hibridnog Frankendancera služila je kao postupno uvođenje. Operatori su zamijenili Agave komponente za umrežavanje i proizvodnju blokova s Firedancerovim ekvivalentima, zadržavajući Agaveov konsenzus i izvedbene slojeve.
Taj je pristup omogućio validatorima da prihvate poboljšanja performansi Firedancera bez riskiranja cijele mreže na neprovjerenom konsenzusnom kodu.
Frankendancer s 21% udjela koji je osvojen do listopada potvrdio je hibridni model, ali je također istaknuo njegovu granicu: sve dok se svi validatori i dalje oslanjaju na Agave za konsenzus, greška u tom zajedničkom sloju još uvijek može zaustaviti lanac.
Prosinačko glavno mrežno pokretanje potpunog klijenta uklanja tu zajedničku ovisnost.
Nekoliko validatora koji su pokretali Firedancer 100 dana i proizveli 50 000 blokova pokazali su da klijent može sudjelovati u konsenzusu, proizvesti valjane blokove i održavati stanje bez oslanjanja na komponente Agave.
Dosadašnja proizvodnja je mala, 100 dana na nekoliko čvorova, ali dovoljna da otvori vrata za šire usvajanje. Validatori sada imaju pravu alternativu, a otpornost mreže izravno ovisi o tome koliko ljudi odluči migrirati.
Zašto je institucijama stalo do softvera validatora
Veza između različitosti klijenata i institucionalnog usvajanja nije spekulativna.
Levexov Firedancer objašnjava da se klijent “adresira na ključne probleme koje su institucionalni investitori izrazili o Solaninoj pouzdanosti i skalabilnosti” i da višeklijentska redundantnost “pruža robusnost koju poduzeća trebaju za kritične aplikacije”.
Rujanski Binance Square esej o institucionalnoj spremnosti Solane uokviruje prošle prekide rada kao primarnu prepreku angažmanu poduzeća i pozicionira Firedancer kao “potencijalni lijek”.
Analiza tvrdi da je pouzdanost “ključni diferencijator” u Solaninoj konkurenciji s Ethereumom i drugim mrežama sloja 1, te da bi uklanjanje rizika od jednog klijenta “moglo ukloniti Solaninu najveću slabost” u predstavljanju institucijama koje ne mogu tolerirati zastoj na razini mreže.
Logika odražava okvir uspostavljen za Ethereumovu kampanju raznolikosti klijenata.
Institucionalni timovi za rizik koji procjenjuju blockchain infrastrukturu žele znati što se događa kada se nešto pokvari.
Mreža u kojoj 90% validatora pokreće istog klijenta ima jednu točku kvara, bez obzira na to koliko decentralizirana distribucija tokena ili skup validatora izgleda na papiru.
Mreža u kojoj nijedan klijent ne kontrolira više od 33% udjela može izgubiti cijelog klijenta zbog katastrofalne greške i nastaviti s radom. Ta je razlika binarna za upravitelje rizikom koji odlučuju hoće li izgraditi regulirane proizvode u određenom lancu.
Solaninih približno 767 milijuna dolara u tokeniziranoj imovini iz stvarnog svijeta predstavlja uporište, a ne usvajanje u velikom opsegu. Prema podacima rwa.xyz, Ethereum ima 12,5 milijardi dolara u tokeniziranim trezorima, stabilnim kovanicama i tokeniziranim fondovima.
Jaz ne odražava samo mrežne učinke ili razmišljanje programera, već i povjerenje u vrijeme neprekidnog rada.
Firedancerov dolazak na mainnet daje Solani put da zatvori taj jaz ispunjavanjem istog praga raznolikosti klijenata koji Ethereumova zajednica tretira kao uloge u stolu za proizvodnu infrastrukturu.
Predstoji krivulja usvajanja
Prijelaz sa 70% dominacije agave na uravnoteženu mrežu s više klijenata neće se dogoditi brzo. Validatori se suočavaju s troškovima prebacivanja: Firedancer zahtijeva drugačije podešavanje hardvera, drugačije operativne runbookove i drugačije karakteristike performansi od Agavea.
Klijentova 100-dnevna proizvodna evidencija, iako uspješna, plitka je u usporedbi s Agaveovim godinama rada na glavnoj mreži. Operatori skloni riziku čekat će više podataka prije nego što prebace udio.
Ipak, struktura poticaja sada favorizira diverzifikaciju. Zdravstvena izvješća validatora Zaklade Solana javno prate distribuciju klijenata, stvarajući reputacijski pritisak na velike operatere da izbjegnu koncentrirane pozicije u bilo kojoj pojedinačnoj implementaciji.
Povijest prekida rada mreže daje visceralni podsjetnik na lošu stranu. A priča o institucionalnom usvajanju, sa špekulacijama ETF-a, izdavanjem RWA-a i pilot-programima plaćanja poduzeća, ovisi o dokazivanju da je Solana prevazišla svoje probleme s pouzdanošću.
Arhitektura je sada postavljena. Solana ima dva proizvodna klijenta, na različitim jezicima, s neovisnim bazama koda i odvojenim načinima kvarova. Otpornost mreže ovisi o tome koliko brzo udio migrira iz monokulture s kojom je započeo u distribuciju gdje niti jedan klijent ne može isključiti lanac.
Za institucije koje procjenjuju može li Solana funkcionirati kao proizvodna infrastruktura i ima li realan put da preživi sljedeću pogrešku klijenta bez koordiniranog ponovnog pokretanja.







