Binawasan ng Solana ang target na slot time nito mula 400 milliseconds patungong 350ms sa unang pagkakataon mula nang ilunsad ang network, na nagsisimula ng four-stage plan na sa huli ay makapagpapababa ng mga slot sa 200ms.

Inanunsyo ni Jacob Creech, vice president of technology ng Solana Foundation, ang pagbabago noong Agosto 21, sinabing ang network ay pumasok na sa "bagong panahon ng 350ms" bago idinagdag, "Susunod na hinto, 300ms."

Ang average na slot times ay tumatakbo sa humigit-kumulang 360ms sa oras ng pagsulat, ayon sa slot time explorer ng Solana, kumpara sa orihinal na 400ms na target ng network.

Ang pagbabago ay ang unang hakbang sa ilalim ng SIMD-0525, isang panukalang pagpapabuti ng Solana na nagpapakilala ng apat na sunud-sunod na mas maikling slot configuration sa 350ms, 300ms, 250ms at 200ms. Ang panukala ay inaprubahan at isinama noong Mayo 14.

Sa halip na agad na lumipat sa huling target, plano ng Solana na i-activate ang bawat pagbabawas nang hiwalay, na nagbibigay sa mga validator operator at client developer ng pagkakataong subukan ang pag-uugali ng network habang bumibilis ang paggawa ng block.

Nagsisimula ang Solana slot time sa paglipat nito patungong 200ms

Sinabi ng Solana Foundation noong Hunyo na ang pagbabawas ng mga slot mula 400ms patungong 200ms ay magpapababa ng latency at magpapahintulot sa mga kumpirmasyon na maabot ang mga user nang mas mabilis.

Sa ilalim ng SIMD-0525, ang unang feature gate ay nagbabago sa slot target sa 350ms. Ang mga susunod na activation ay magdadala nito sa 300ms, pagkatapos ay 250ms at sa huli ay 200ms.

Ang lahat ng apat na yugto ay kasalukuyang tinatarget para sa Agave v4.2, ang validator client na binuo ng Anza, bagaman ang iskedyul ng paglulunsad ay nananatiling pansamantala at maaaring magbago depende sa pagsubok.

Ang mas maikling slot ay nangangahulugang ang mga pagkakataon sa paggawa ng block ay dumadaan sa pagitan ng mga validator nang mas madalas. Pinapanatili ng SIMD-0525 ang 64 ticks per slot ng network at ang four-slot leader window nito, ngunit ang dami ng real time na kinakatawan ng bawat leader window ay bumababa sa bawat pagbabawas.

Sa nakaraang 400ms target, ang apat na slot ay nagbigay sa isang lider ng nominal na 1.6-segundong window. Ang isang 350ms slot ay nagpapababa sa figure na iyon sa 1.4 segundo, habang ang 300ms ay magpapababa nito sa 1.2 segundo. Sa huling 200ms target, ang isang four-slot window ay tatagal ng humigit-kumulang 800ms.

Sinasabi ng panukala na ang pagbabawas ng dami ng oras na kinokontrol ng isang lider ay maaari ring magpababa sa panahon kung saan ang mga transaksyon ay maaaring maantala o ma-reorder bago makatanggap ang isa pang validator ng pagkakataong gumawa ng mga block.

Ang SIMD-0525 ay hindi lamang nagpapahintulot sa network na gumawa ng doble ng dami ng trabaho pagkatapos lumipat mula 400ms patungong 200ms. Ang mga limitasyon ng resource ay inaakma nang proporsyonal habang bumababa ang tagal ng slot upang ang mga pangangailangan sa pagpoproseso sa isang partikular na panahon ay hindi tumaas dahil lamang sa mas maraming slot ang ginagawa.

Sa orihinal na 60 milyong compute-unit baseline na ginamit sa panukala, ang per-slot limit ay bababa sa 52.5 milyong CUs sa 350ms, 45 milyon sa 300ms, 37.5 milyon sa 250ms at 30 milyon sa 200ms.

Binabago ng mas mabilis na slot ang mga kumpirmasyon at epoch timing

Ang confirmation latency ay isa sa mga pangunahing bahagi na tinatarget ng pagbabago dahil sinusukat ng Solana ang ilang bahagi ng operasyon ng network sa mga slot.

Sa mas mabilis na paglipat ng mga validator sa mga slot, ang slot-based confirmation thresholds ay maaaring maabot sa mas maikling real-world na oras. Ang mga application na gumagamit ng slot numbers upang matukoy kung gaano kareserba ang impormasyon ng blockchain ay maaari ring makatanggap ng mas pinong timing intervals.

Tinutukoy ng SIMD-0525 ang mga gumagamit ng oracle at automated market makers sa mga application na maaaring makinabang mula sa mas maikling interval, lalo na kapag ang mga desisyon ay nakasalalay sa edad ng on-chain data.

Bababa rin ang tagal ng epoch dahil plano ng Solana na panatilihin ang 432,000 slot per epoch.

Ang isang epoch na may 400ms slot ay may nominal na tagal na humigit-kumulang 48 oras. Ang paglipat sa 350ms ay nagpapababa nito sa humigit-kumulang 42 oras, habang ang 300ms ay magdadala ng isang epoch sa humigit-kumulang 36 oras. Sa 250ms, ang figure ay bumababa sa humigit-kumulang 30 oras, bago umabot sa humigit-kumulang 24 oras kung ang 200ms slot ay i-activate.

Ang mga taunang kalkulasyon ng slot ng Solana ay inaakma kasabay ng pagbabago upang ang protocol issuance ay manatiling batay sa real-world time sa halip na tumaas lamang dahil mas maraming slot ang nagaganap bawat taon.

Ang Validator Admission Ticket na iminungkahi sa ilalim ng Alpenglow consensus system ng Solana ay idinisenyo din upang mag-scale habang lumiliit ang mga epoch. Tinukoy ng SIMD-0525 na ang 1.6 SOL na gastos per epoch sa 400ms ay bababa sa 1.4 SOL sa 350ms, na susundan ng 1.2 SOL, 1 SOL at 0.8 SOL sa mga susunod na yugto.

Sinasabi ng panukala na ang mga pagsasaayos ay nilayon upang panatilihin ang gastos ng validator sa humigit-kumulang 0.8 SOL kada araw sa kabila ng mas maikling epoch.

Ang mga pagpapabuti sa performance ng Solana ay lumalampas sa slot times

Ang paglulunsad ng slot-time ay nagaganap habang ang mga developer ng Solana ay nagtatrabaho sa ilang pagbabago sa validator at consensus infrastructure ng network.

Tulad ng naunang naiulat ng crypto.news, ang Alpenglow ay pumasok sa community validator testing noong Mayo matapos ilagay ng Anza ang disenyo ng consensus sa isang test cluster.

Ang Alpenglow ay idinisenyo upang dalhin ang mga confirmation time sa humigit-kumulang 150ms habang tinatanggal ang Proof of History at on-chain vote transactions mula sa core consensus process ng Solana. Tinawag ng Anza ang planong upgrade na pinakamalaking pagbabago sa consensus sa kasaysayan ng Solana.

Ang sistema ay nagpapakilala ng isang disenyo ng pagboto na tinatawag na Votor, na gumagamit ng off-chain validator communication at signature aggregation upang makamit ang consensus. Ang pagbuo nito ay hiwalay sa SIMD-0525, bagaman ang parehong proyekto ay nakatuon sa pagbabawas ng dami ng oras na kinakailangan para sa operasyon ng network.

Ang validator software ay naging mas magkakaiba rin noong 2026. Ang paglulunsad ng Firedancer mainnet ng Jump Crypto ay nagsimulang gumawa ng mga block noong Mayo matapos ang mga taon ng pagbuo, na nagbibigay ng isang independiyenteng binuong alternatibo sa umiiral na mga implementasyon ng validator ng Solana.

Pinayuhan ng Jump Crypto ang mga validator noong panahong iyon na huwag lumipat sa Firedancer nang malawakan hanggang matapos ang security audits. Ang client ay binuo upang mapabuti ang performance at upang mabawasan ang panganib na nilikha kapag ang isang blockchain ay lubos na nakasalalay sa isang implementasyon ng validator software.

Kalaunan sa buwang iyon, inihayag ng Coinbase ang isang multi-client setup gamit ang Jito at Firedancer sa buong imprastraktura ng validator ng Solana nito. Ang arkitektura ng validator nito ay sumuporta sa humigit-kumulang 40.48 milyong staked SOL noong panahong iyon, o humigit-kumulang 9.52% ng staked supply ng network, ayon sa Q1 validator performance report ng exchange.

Nagpakilala ang Solana ng isa pang pagbabago sa antas ng network noong Hulyo nang ilunsad nito ang isang on-chain governance framework na nagpapahintulot sa mga validator na kumuha ng stake-weighted votes sa Solana Governance Proposals. Sa ilalim ng bagong proseso ng pamamahala, ang mga panukala na nakatanggap ng 15% paunang suporta ay dumaan sa isang 11-epoch na proseso na naglalaman ng diskusyon, isang stake snapshot at pormal na pagboto.

Ang isang panukala ay naipapasa kapag ang mga boto na pabor ay umabot sa hindi bababa sa 66.67% ng mga lumalahok na "Para" at "Laban" na stake, habang ang mga teknikal na pagbabago ay maaari pa ring dumaan sa umiiral na proseso ng SIMD nang hindi muna nakakatanggap ng boto sa panukala ng pamamahala.

Ang susunod na pagbabawas ng slot ay magdadala sa Solana sa 300ms

Sa aktibo na ngayon na 350ms setting, tinukoy ng SIMD-0525 ang 300ms bilang susunod na yugto sa pagkakasunud-sunod.

Ang pagbabago ay magpapababa sa nominal na four-slot leader window mula 1.4 segundo patungong 1.2 segundo at magpapababa ng isang epoch mula humigit-kumulang 42 oras patungong 36 oras.

Ang karagdagang feature activations ay maglilipat pagkatapos ng Solana sa 250ms at 200ms. Ang bawat configuration ay kinakalkula mula sa baseline values ng network sa halip na gamitin ang mga rounded limit mula sa nakaraang yugto, isang disenyo na nilayon upang maiwasan ang pagkaipon ng mga pagkakaiba sa rounding sa magkakasunod na pagbabawas.

Nagpatuloy ang pagsubok sa imprastraktura ng Solana habang inihahanda ang mga yugtong iyon. Noong Hulyo, umabot din sa record levels ang aktibidad ng network habang lumalawak ang mga tokenized asset sa Solana, kung saan ang aktibidad ng tokenized stock ay nag-ambag sa pagtaas ng paggamit sa buong chain.

Para sa SIMD-0525, gayunpaman, ang bawat natitirang slot reduction ay nangangailangan pa rin ng kaukulang feature activation nito. Kasunod ng bagong activated 350ms setting, tinukoy ni Creech ang 300ms bilang susunod na target ng network.