Binawasan ng Solana ang target nitong oras ng slot mula 300 millisecond patungo sa 250 millisecond, na nagpapataas sa bilis ng paggawa ng network ng mga slot ng halos 17% nang hindi itinaas ang pangkalahatan nitong pinakamataas na kapasidad sa pagproseso ng parehong halaga.
Ayon sa data ng blockchain, ang bagong setting ay naging live noong Setyembre 18 at nagdadala sa Solana sa apat na target na slot bawat segundo, kumpara sa humigit-kumulang 3.3 sa ilalim ng nakaraang 300ms na configuration. Ang pagbabago ay ang ikatlong yugto ng SIMD-0525, na idinisenyo upang unti-unting bawasan ang mga oras ng slot mula sa orihinal na 400ms na setting ng network patungo sa isang huling target na 200ms.
Ang isang slot ay ang panahon kung saan ang isang itinalagang validator ay maaaring makagawa ng isang block. Ang pagpapaikli ng panahong iyon ay nagbibigay sa mga wallet, exchange, at trading application ng mas madalas na update sa estado ng network.
Ang mga validator ay patuloy na nagsisilbing mga leader sa loob ng apat na magkakasunod na slot. Dahil ang bawat slot ay target na ngayon sa 250ms, ang nominal leader window ng isang validator ay bumaba mula 1.2 segundo sa nakaraang setting patungo sa isang segundo.
Sinimulan ng Solana ang kasalukuyang pagpapatupad noong Agosto nang bawasan nito ang oras ng slot nito mula 400ms patungo sa 350ms sa unang pagkakataon mula nang ilunsad ang network, gaya ng iniulat ng crypto.news dati.
Hinati ng SIMD-0525 ang proseso sa apat na yugto sa 350ms, 300ms, 250ms, at 200ms sa halip na direktang lumipat sa huling target. Ang bawat pagbabawas ay nangangailangan ng hiwalay na pag-activate ng feature, na nagpapahintulot sa mga developer at validator operator na suriin ang performance ng network bago magpatuloy.
Sa 250ms, apat na pagkakataon ng slot ang dumarating bawat segundo. Ang mas maiikling agwat ay maaaring magbigay sa mga aplikasyon ng mas kasalukuyang pagtingin sa mga transaksyon at estado ng network habang ipinapasa ang produksyon ng block mula sa isang validator patungo sa isa pa nang mas maaga.
Ang mga pamilihan na batay sa oracle at automated market makers ay kabilang sa mga aplikasyong sakop ng panukala dahil ang kanilang mga operasyon ay maaaring nakadepende sa edad ng onchain data. Ang mas maikling agwat ay binabawasan ang dami ng oras sa pagitan ng mga update ng network, habang mas maaga makikita ng mga user ang mga pagbabago sa status ng transaksyon.
Para sa mga swap, ang mas maikling timing ay maaaring magpaliit ng panahon sa pagitan ng isang transaksyon na isinumite at pagdating sa network. Tinutukoy ng pinagbabatayan na panukala ang mas mabilis na kumpirmasyon at mas madalas na update bilang mga benepisyo ng pagbabawas ng tagal ng slot.
Ang pagbabago ay hindi nagpapataas ng raw transaction capacity ng Solana ng halos 17%.
Sa ilalim ng SIMD-0525, binabawasan ang mga limitasyon ng resource nang proporsyonal sa tagal ng slot. Mas maraming slot ang nagagawa sa isang partikular na panahon, ngunit ang bawat slot ay pinapayagan na magdala ng mas kaunting pag-compute at data, na pinapanatili ang dami ng trabaho na maaaring iproseso ng network sa totoong oras sa halos parehong antas.
Sa 60 milyong compute unit baseline na ginamit ng panukala, bumababa ang limitasyon sa bawat slot habang bumibilis ang orasan. Ang 250ms na configuration ay tumutugma sa isang 37.5 milyong compute unit limit, habang ang nakaplanong 200ms na yugto ay magpapababa nito sa 30 milyon.
Mas marami na ngayong indibidwal na block na ipoproseso at iimbak ang mga provider ng imprastraktura kahit na ang wall clock processing ceiling ay nananatiling halos hindi nagbabago.
Ang mga aplikasyon na nagkakalkula ng lumipas na oras sa pamamagitan ng pagpaparami ng mga numero ng slot sa isang nakapirming tagal ng slot ay maaaring kailanganing isaalang-alang ang mas mabilis na orasan. Ang mga blockhash ay mas maagang mawawalan ng bisa sa totoong oras habang mas mabilis ang pag-usad ng mga slot, na nag-iiwan ng mas kaunting oras para sa mga proseso ng transaksyon na kinasasangkutan ng offline na pagpirma o naantalang pag-apruba ng tao.
Nagbabago rin ang oras ng epoch sa parehong dahilan. Pinapanatili ng Solana ang bawat epoch na nakapirming 432,000 slot, ibig sabihin, nagiging mas maikli ang isang epoch habang bumababa ang tagal ng bawat slot.
Sa naunang target na 300ms, ang isang epoch ay tumatagal ng humigit-kumulang 36 oras. Ang setting na 250ms ay nagpapababa sa inaasahang tagal sa humigit-kumulang 30 oras. Ang paglipat sa huling target na 200ms ay magbabawas nito sa humigit-kumulang 24 oras.
Ang mga naka-stage na pagbabawas ng slot ng Solana ay bahagi ng Agave 4.2 rollout. Nagsimulang i-activate ng client release ang ilang pagbabago sa network noong Agosto, kabilang ang mas mababang onchain storage rent, mas malaking transaksyon, at ang landas patungo sa 200ms na mga slot.
Ang naka-stage na disenyo ay may kasamang safeguard na nakatali sa block skip rates. Ang pag-usad patungo sa susunod na setting ng slot ay maaaring ihinto kung tumaas ang skip rates nang higit sa antas na itinuturing na katanggap-tanggap ng mga developer, na nagbibigay ng oras sa mga validator upang gumana sa ilalim ng bawat configuration bago i-activate ang isa pang pagbabawas.
Wala pang itinakdang petsa ng mainnet para sa 200ms na yugto.
Ang slot timing ay isa lamang bahagi ng mga pagbabago sa network na ipinapatupad sa pamamagitan ng Agave.
Hiwalay na ipinakilala ng Solana ang Transaction V1, na nagpapataas sa maximum serialized transaction size mula 1,232 bytes patungo sa 4,096 bytes. Ang mas malaking format ng transaksyon ay kayang tumanggap ng mga operasyon na may mabigat na data tulad ng zero knowledge proofs at kumplikadong multisignature instructions sa loob ng isang transaksyon.
Ang Transaction V1 ay opsyonal, habang ang legacy at version zero na mga transaksyon ay nananatiling suportado. Kailangan ng mga aplikasyon na bumabasa ng mga block na suportahan ang mas bagong format upang mahawakan nang tama ang mga V1 na transaksyon.
Ang pagtaas ng laki ng transaksyon ay hiwalay sa SIMD-0525. Samakatuwid, ang mas malalaking indibidwal na transaksyon ay hindi nagtatakda ng slot clock, habang ang mas maikling slot ay hindi awtomatikong nagpapataas ng maximum na laki ng isang transaksyon.
Ang Solana ay nag-a-activate ng mga pagbabago nang independiyente sa pamamagitan ng feature gates. Ang istraktura ay nagpapahintulot sa isang upgrade na magpatuloy nang hindi nangangailangan ng iba pang mga feature na kasama sa Agave 4.2 na i-activate nang sabay.
Ang huling yugto sa ilalim ng SIMD-0525 ay magbabawas ng target na oras ng slot mula 250ms patungo sa 200ms, na magdadala sa network sa limang target na slot bawat segundo.
Ang apat na slot validator leader window ay magiging humigit-kumulang 800ms. Ang tagal ng epoch ay bababa mula humigit-kumulang 30 oras sa ilalim ng kasalukuyang 250ms setting patungo sa humigit-kumulang 24 oras.
Ang mga developer ng Solana ay hindi nagbigay ng petsa ng mainnet activation para sa huling pagbabawas. Ang pag-usad ay nakasalalay sa pag-uugali ng network sa ilalim ng kasalukuyang setting, kabilang ang kung mapapanatili ng mga validator ang katanggap-tanggap na block skip rates.
Ang mga pagbabawas ng slot ay hiwalay sa Alpenglow, ang nakaplanong consensus redesign ng Solana. Ang Alpenglow ay nilayon na palitan ang TowerBFT ng isang voting system na tinatawag na Votor at alisin ang mga onchain vote transactions mula sa pangunahing proseso ng consensus ng network.
Ang Alpenglow consensus upgrade ay nagta-target ng humigit-kumulang 150ms finality. Ang code nito ay isinama para sa pagsubok, habang ang mainnet deployment ay nakatali sa Agave 4.3 sa halip na ang slot time feature gates na ginamit para sa SIMD-0525.
Ang Alpenglow ay pumasok sa community validator testing mas maaga sa 2026, na nagpapahintulot sa mga operator na patakbuhin ang consensus design sa isang test cluster bago ang deployment sa mainnet. Inilarawan ng Anza ang sistema bilang pinakamalaking pagbabago sa consensus sa kasaysayan ng Solana.
Para sa SIMD-0525, ang network ay nananatili sa 250ms na yugto hanggang sa i-activate ng mga developer ang huling feature gate. Ang 200ms na configuration ay magkukompleto ng isang rollout na nagsimula sa 400ms at lumipat sa 350ms, 300ms, at 250ms habang binabawasan ang mga limitasyon ng resource sa bawat hakbang.
SOL