Solana și-a redus timpul țintă de slot de la 300 milisecunde la 250 milisecunde, crescând rata cu care rețeaua produce sloturi cu aproape 17% fără a-și crește plafonul general de procesare cu aceeași valoare.
Conform datelor blockchain, noua setare a fost activată pe 18 septembrie și aduce Solana la patru sloturi țintă pe secundă, comparativ cu aproximativ 3,3 în configurația anterioară de 300ms. Modificarea reprezintă a treia etapă a SIMD-0525, care este concepută pentru a reduce treptat timpii de slot de la setarea inițială de 400ms a rețelei la o țintă finală de 200ms.
Un slot este perioada în care un validator desemnat poate produce un bloc. Scurtarea acestei perioade oferă portofelelor (wallets), schimburilor (exchanges) și aplicațiilor de tranzacționare actualizări mai frecvente privind starea rețelei.
Validatorii continuă să servească drept lideri pentru patru sloturi consecutive. Cu fiecare slot vizat acum la 250ms, fereastra nominală de lider a unui validator a scăzut de la 1,2 secunde, la setarea anterioară, la o secundă.
Solana a început implementarea actuală în august, când și-a redus timpul de slot de la 400ms la 350ms pentru prima dată de la lansarea rețelei, așa cum a raportat anterior crypto.news.
SIMD-0525 a împărțit procesul în patru etape: 350ms, 300ms, 250ms și 200ms, în loc să treacă direct la ținta finală. Fiecare reducere necesită o activare separată a unei funcții, permițând dezvoltatorilor și operatorilor de validatori să evalueze performanța rețelei înainte de a avansa.
La 250ms, patru oportunități de slot apar în fiecare secundă. Intervalele mai scurte pot oferi aplicațiilor o imagine mai actualizată a tranzacțiilor și a stării rețelei, transferând producția de blocuri de la un validator la altul mai repede.
Piețele bazate pe oracole și creatorii de piață automatizați (automated market makers) se numără printre aplicațiile vizate de propunere, deoarece operațiunile lor pot depinde de vechimea datelor on-chain. Un interval mai scurt reduce timpul dintre actualizările rețelei, în timp ce utilizatorii pot vedea modificările stării tranzacțiilor mai repede.
Pentru swap-uri, temporizarea mai scurtă poate restrânge perioada dintre momentul în care o tranzacție este trimisă și momentul în care ajunge la rețea. Propunerea subiacentă identifică confirmările mai rapide și actualizările mai frecvente ca beneficii ale reducerii duratei slotului.
Modificarea nu mărește capacitatea brută de tranzacții a Solana cu aproape 17%.
Conform SIMD-0525, limitele de resurse sunt reduse proporțional cu durata slotului. Mai multe sloturi sunt produse într-o perioadă dată, dar fiecărui slot i se permite să transporte mai puțină putere de calcul și mai puține date, menținând cantitatea de muncă pe care rețeaua o poate procesa în timp real la aproximativ același nivel.
La valoarea de bază de 60 de milioane de unități de calcul (compute unit) utilizată în propunere, limita pe slot scade pe măsură ce ceasul devine mai rapid. Configurația de 250ms corespunde unei limite de 37,5 milioane de unități de calcul, în timp ce etapa planificată de 200ms ar reduce-o la 30 de milioane.
Furnizorii de infrastructură au acum mai multe blocuri individuale de procesat și stocat, chiar dacă plafonul de procesare în timp real rămâne în mare parte neschimbat.
Aplicațiile care calculează timpul scurs prin înmulțirea numerelor de slot cu o durată fixă a slotului ar putea trebui să țină cont de ceasul mai rapid. Blockhash-urile expiră mai repede în timp real pe măsură ce sloturile avansează mai rapid, lăsând mai puțin timp pentru procesele de tranzacție care implică semnarea offline sau aprobări umane întârziate.
Temporizarea epocilor se modifică din același motiv. Solana menține fiecare epocă fixată la 432.000 de sloturi, ceea ce înseamnă că o epocă devine mai scurtă pe măsură ce durata fiecărui slot scade.
La ținta anterioară de 300ms, o epocă dura aproximativ 36 de ore. Setarea de 250ms reduce durata așteptată la aproximativ 30 de ore. O trecere la ținta finală de 200ms ar reduce-o la aproximativ 24 de ore.
Reducerea eșalonată a sloturilor Solana face parte din implementarea Agave 4.2. Lansarea clientului a început să activeze mai multe modificări de rețea în august, inclusiv chirie de stocare on-chain mai mică, tranzacții mai mari și calea către sloturi de 200ms.
Designul eșalonat include o măsură de siguranță legată de ratele de omisiune a blocurilor (block skip rates). Progresul către următoarea setare a slotului poate fi oprit dacă ratele de omisiune depășesc nivelul considerat acceptabil de dezvoltatori, oferind validatorilor timp să opereze sub fiecare configurație înainte ca o altă reducere să fie activată.
Nu a fost stabilită nicio dată pentru rețeaua principală (mainnet) pentru etapa de 200ms.
Temporizarea sloturilor este doar o parte a modificărilor de rețea implementate prin Agave.
Solana a introdus separat Tranzacția V1, care mărește dimensiunea maximă a tranzacției serializate de la 1.232 de octeți la 4.096 de octeți. Formatul de tranzacție mai mare poate găzdui operațiuni intensive în date, cum ar fi dovezile cu zero cunoștințe (zero knowledge proofs) și instrucțiuni complexe de multisemnare într-o singură tranzacție.
Tranzacția V1 este opțională, în timp ce tranzacțiile vechi și de versiune zero rămân suportate. Aplicațiile care citesc blocuri trebuie să suporte noul format pentru a gestiona corect tranzacțiile V1.
Creșterea dimensiunii tranzacțiilor este separată de SIMD-0525. Prin urmare, tranzacțiile individuale mai mari nu determină ceasul slotului, în timp ce sloturile mai scurte nu măresc automat dimensiunea maximă a unei tranzacții.
Solana a activat modificările independent prin intermediul "feature gates". Structura permite ca o actualizare să progreseze fără a necesita activarea simultană a celorlalte caracteristici incluse în Agave 4.2.
Etapa finală conform SIMD-0525 ar reduce timpul țintă de slot de la 250ms la 200ms, aducând rețeaua la cinci sloturi țintă pe secundă.
Fereastra de lider a validatorului de patru sloturi ar scădea, în consecință, la aproximativ 800ms. Durata epocilor ar scădea de la aproximativ 30 de ore, la setarea actuală de 250ms, la aproximativ 24 de ore.
Dezvoltatorii Solana nu au furnizat o dată de activare pe rețeaua principală (mainnet) pentru reducerea finală. Progresul depinde de comportamentul rețelei în setarea actuală, inclusiv de capacitatea validatorilor de a menține rate acceptabile de omisiune a blocurilor.
Reducerea sloturilor este separată de Alpenglow, redesignul de consens planificat al Solana. Alpenglow este destinat să înlocuiască TowerBFT cu un sistem de vot numit Votor și să elimine tranzacțiile de vot on-chain din procesul de consens central al rețelei.
Actualizarea consensului Alpenglow vizează o finalitate de aproximativ 150ms. Codul său a fost inclus pentru testare, în timp ce implementarea pe rețeaua principală (mainnet) a fost legată de Agave 4.3, mai degrabă decât de "feature gates" pentru timpul de slot utilizate pentru SIMD-0525.
Alpenglow a intrat în testarea de către validatorii comunității mai devreme în 2026, permițând operatorilor să ruleze designul consensului pe un cluster de test înainte de implementarea pe rețeaua principală (mainnet). Anza a descris sistemul ca fiind cea mai mare modificare de consens din istoria Solana.
Pentru SIMD-0525, rețeaua rămâne la etapa de 250ms până când dezvoltatorii activează ultimul "feature gate". Configurația de 200ms ar finaliza o implementare care a început la 400ms și a trecut prin 350ms, 300ms și 250ms, reducând în același timp limitele de resurse la fiecare pas.
SOL