
Inilipat na ng Solana ang Alpenglow consensus upgrade nito patungo sa deployment sa pampublikong testnet habang naghahanda ang mga developer na subukan ang isang disenyo na naglalayong pababain ang transaction finality mula sa humigit-kumulang 13 segundo tungo sa mga 150 millisecond.
Ayon sa github, pahihintulutan ng yugto ng testnet ang mga developer na subukan ang migration sa loob ng nakapirming testing environment ng Solana bago maaaring ikonsidera ang consensus system para sa pangunahing network.
Ang finality ay tumutukoy sa punto kung kailan nagiging hindi na mababawi ang isang transaksyon sa ilalim ng mga consensus rule ng network. Karaniwang naghihintay ang mga exchange ng finality bago i-credit ang mga deposit, habang ginagamit naman ito ng mga blockchain bridge bago maglabas ng mga asset sa ibang network.
Sa kasalukuyan, umaasa ang Solana sa TowerBFT para sa consensus, kung saan nagtatala ang mga validator ng mga boto onchain at nag-iipon ng sapat na boto sa loob ng 32 slot bago maabot ng isang block ang finality. Pinapalitan ng Alpenglow ang prosesong iyon ng isang protocol na tinatawag na Votor, na nagpapahintulot sa mga validator na direktang magpalitan ng mga boto.
Sa ilalim ng bagong disenyo, maaaring magkasundo ang mga validator matapos ang isa o dalawang voting round. Inaalis ng pagbabagong ito ang mas mahabang sunod-sunod na onchain consensus vote na kailangan sa ilalim ng TowerBFT habang nananatiling halos hindi nagbabago ang execution ng transaksyon para sa mga application at user.
Mahigit apat na buwan nang tumatakbo ang Alpenglow sa isang mas maliit na community cluster na sadyang ginawa para subukan ang consensus system. Ang paglipat ng upgrade sa nakapirming pampublikong testnet ng Solana ay maglalantad dito sa mas malaking grupo ng mga validator, infrastructure provider, at mga serbisyong nakakonekta na sa network.
Gumagamit ang pampublikong testnet ng mga token na walang halagang pinansyal, na nagbibigay-daan sa mga developer na i-restart ang network, subukan ang mga migration procedure, at siyasatin ang mga problema nang hindi nalalagay sa panganib ang mga pondo sa mainnet.
Unang inilipat ng Anza ang Alpenglow sa community validator testing noong Mayo, at inilarawan ang upgrade bilang pinakamalaking pagbabago sa consensus sa kasaysayan ng Solana. Gaya ng naunang iniulat ng crypto.news, pinahintulutan ng community cluster ang mga validator operator na subukan ang bagong consensus design bago ito ideploy sa umiiral na test infrastructure ng Solana.
Dinisenyo ang Votor upang maabot ang finality sa pamamagitan ng isa sa dalawang voting path depende sa partisipasyon ng validator. Ipinahiwatig ng mga naunang specification na maaaring ma-settle ang isang block matapos ang isang round kapag sapat ang stake na nakikilahok, habang nagbibigay naman ang ikalawang round ng isa pang daan patungo sa finality kapag mas mababa ang partisipasyon.
Ang inaasahang resulta ay isang matinding pagbawas mula sa kasalukuyang finality time ng Solana. Tinataya ng Anza ang median finality sa humigit-kumulang 150 millisecond, habang ipinakita ng mga naunang simulation na maaari itong bumaba hanggang 100 millisecond sa mga paborableng kondisyon.
Hindi binago ng mga developer kung paano nagsasagawa ng mga transaksyon ang mga application bilang bahagi ng upgrade. Magpapatuloy ang mga user ng wallet sa pagpapadala ng mga transaksyon sa parehong mga interface, habang ang pangunahing mga pagbabago ay magaganap sa kung paano nakikipag-ugnayan ang mga validator at nagkakasundo sa permanenteng estado ng blockchain.
Kailangang patakbuhin ng mga validator na kalahok sa Alpenglow test ang Agave 4.3, ang pinakabagong branch ng pangunahing validator software na pinapanatili ng Anza.
Inirekomenda ng Anza ang Agave 4.3 para sa pangkalahatang paggamit sa mga mainnet validator noong Set. 21. Dumaan dati ang rollout sa mga kontroladong yugto, kung saan unang hiniling sa mga operator na responsable sa 10% ng mainnet stake na mag-upgrade bago pinalawak ang rekomendasyon sa 25%.
Matagal nang naka-ugnay ang development ng Alpenglow sa mga release ng Agave sa loob ng ilang buwan. Noong Agosto, inaasahang darating ang target na 150 millisecond finality sa pamamagitan ng Agave 4.3 matapos maisama na para sa testing ang pinagbabatayang Alpenglow code sa naunang software branch.
Ang petsang Set. 28 na nakalista sa iskedyul ng Agave 4.3 ng Anza ay tumutukoy sa pansamantalang pagpapatuloy ng mainnet feature activation. Ayon sa Anza, maaari pang magbago ang mga petsa ng release nito, habang nakalista pa rin sa feature gate tracker nito ang activation ng Alpenglow testnet bilang pending noong maagang Miyerkules.
Samakatuwid, ang Set. 28 ay hindi kumakatawan sa kumpirmadong petsa para magsimulang tumakbo ang Alpenglow sa Solana mainnet.
Mahalaga ang pagkakaibang ito dahil ilang Solana performance upgrade ang dumaraan sa magkakahiwalay na activation schedule. Ang transaction finality, slot production, at transaction capacity ay pinamamahalaan ng magkakaibang pagbabago sa network kahit na bawat isa ay maaaring makaapekto sa bilis ng pakikipag-ugnayan ng mga application sa Solana.
Kamakailan ay binawasan ng Solana ang target slot time nito mula 300 millisecond tungo sa 250 millisecond sa ilalim ng SIMD-0525, na nagdala sa network sa target na apat na slot bawat segundo.
Binawasan ng 250 millisecond slot upgrade ang apat na slot leader window ng bawat validator mula 1.2 segundo tungo sa isang segundo. Inayos din ang mga limitasyon sa pagproseso ng network kasabay ng mas maiikling slot, na nangangahulugang hindi itinaas ng pagbabagong ito ang kabuuang processing capacity sa parehong proporsyon.
Ang huling yugto sa ilalim ng SIMD-0525 ay nagta-target ng 200 millisecond slots, na magdadala sa network sa limang target na slot bawat segundo. Hindi pa nagtakda ang mga developer ng kumpirmadong petsa ng activation sa mainnet para sa yugtong iyon.
Magkaibang bahagi ng network ang sinusukat ng slot time at finality. Tinutukoy ng slot time kung gaano kadalas makakagawa ang Solana ng mga bagong slot, habang binabago naman ng Alpenglow kung paano nagkakasundo ang mga validator na ang isang block ay hindi na mababawi.
Sinimulan ng Solana ang kasalukuyang serye ng mga pagbawas sa slot noong Agosto, nang bumaba ang target nito sa 350 millisecond mula sa 400 millisecond na setting na ginagamit mula nang ilunsad ang network. Inilatag ng SIMD-0525 ang sunod-sunod na target na 350, 300, 250, at kalaunan ay 200 millisecond.
Sumusunod ang Alpenglow sa hiwalay na landas sa pamamagitan ng SIMD-0326 at pinapalitan ang TowerBFT ng Votor sa halip na baguhin ang haba ng bawat indibidwal na slot.
Ang Firedancer at Frankendancer, mga validator client na binuo ng Jump Crypto, ay kasalukuyang hindi sumusuporta sa Alpenglow test, kaya ang unang migration ay nakadepende sa Agave.
Ang pagkakaiba-iba ng client ay nagbibigay sa mga validator ng Solana ng magkakaibang software implementation para sa paglahok sa iisang network. Kung may magkakahiwalay na client na available, ang software fault na nakaapekto sa isang implementation ay hindi kinakailangang makaapekto sa bawat validator.
Nagsimulang gumawa ng mga mainnet block ang Firedancer mas maaga ngayong taon matapos ang ilang taong development ng Jump Crypto. Noong una, inirekomenda ng team ang unti-unting rollout habang nagpapatuloy ang mga security audit, kung saan ang independiyenteng binuong client ay nilalayong magpababa ng pagdepende sa umiiral na mga validator implementation ng Solana.
Ang Frankendancer ay nagsisilbing hybrid implementation na pinagsasama ang mga bahagi mula sa Firedancer at umiiral na Solana software. Wala sa dalawang implementation ang nakalistang sumusuporta sa nakabinbing SIMD-0326 Alpenglow feature sa kasalukuyang feature gate tracker ng Anza.
Samakatuwid, ang Agave 4.3 ang suportadong client para sa unang migration sa pampublikong testnet. Inililista ng tracker ng Anza ang Alpenglow bilang pending testnet activation sa ilalim ng SIMD-0326, habang nananatiling minarkahan bilang unavailable ang mga support field para sa Firedancer at Frankendancer.








