Solana ปัจจุบันใช้ Proof of History หรือ PoH เป็นกลไกจัดลำดับเวลาเชิงคริปโต โดย leader node จะประทับเวลาให้บล็อกด้วยหลักฐานที่ validator ตรวจสอบได้ จากนั้น Tower BFT จะทำหน้าที่สร้างฉันทามติด้วยการซ้อน vote ของ validator พร้อมระบบ lockout ซึ่งแต่ละ vote เป็นการยืนยัน fork และเพิ่ม lockout ให้ vote ก่อนหน้า
โมเดลนี้ช่วยให้ Solana ให้ประสบการณ์ยืนยันธุรกรรมได้เร็วแบบ optimistic confirmation แต่ Alpenglow เล็งไปที่อีกชั้นที่หนักแน่นกว่า นั่นคือ finality หรือจุดที่เครือข่าย consensus ถือว่าธุรกรรมสรุปผลแล้วอย่างเด็ดขาด แผนงานของ Anza ระบุว่า Solana วันนี้มี optimistic finality ประมาณ 1 วินาที ขณะที่ SIMD-0326 เปรียบเทียบ finality ของ Tower BFT ที่ 12.8 วินาทีกับเป้าหมายของ Alpenglow ที่ 100–150 มิลลิวินาที
พูดง่าย ๆ คือ ธุรกรรมอาจดูเหมือนเร็วอยู่แล้วในประสบการณ์ผู้ใช้ แต่ finality คือชั้นความมั่นใจที่แข็งแรงกว่า โดยเฉพาะสำหรับแอปที่ต้องการรู้ว่า settlement เกิดขึ้นจริงแล้ว ไม่ใช่แค่มีแนวโน้มสูงว่าจะไม่ย้อนกลับ
Votor คือส่วนของ Alpenglow ที่เข้ามารับหน้าที่ด้านการโหวตและการสรุปบล็อกแทนระบบเดิม ในข้อเสนอ SIMD-0326 Votor ถูกอธิบายว่าเป็นโปรโตคอลแบบ direct vote ที่เบาและสามารถ finalize บล็อกได้ผ่านกระบวนการโหวตแบบรอบเดียวหรือสองรอบ ขึ้นกับสภาพเครือข่ายในเวลานั้น
นี่เป็นการเปลี่ยนแกนคิดจาก Tower BFT ที่ใช้ vote tower และ lockout ต่อเนื่อง แทนที่จะรอชุด vote หลายชั้นเพื่อยืนยันความมั่นคงของ fork Votor ถูกออกแบบให้ไปถึง finality ได้ใน 1 หรือ 2 รอบเมื่อมี stake เข้าร่วมเพียงพอ บทสรุปเชิงเทคนิคจากบุคคลที่สามบางแห่งอธิบายว่าเกี่ยวข้องกับ threshold ของ stake แถว 60%–80% แต่ใจความที่ปลอดภัยที่สุดจากแหล่งต้นทางคือโมเดล finalization แบบรอบเดียวหรือสองรอบตามที่ระบุใน SIMD-0326
Anza ยังระบุว่า Alpenglow ใช้ primitive ทางคริปโตแบบ BLS เพื่อช่วยลดเวลา finalization โดยยังรักษาความปลอดภัยของระบบ ดังนั้นเป้าหมายของ Votor จึงไม่ใช่แค่ทำให้มีข้อความยืนยันเร็วขึ้น แต่คือการย่นเส้นทางไปสู่ deterministic finality ให้สั้นลงจริง
Rotor คือโปรโตคอลกระจายข้อมูลของ Alpenglow Anza อธิบายว่า Rotor นำแนวทางของ Turbine ซึ่งเป็นระบบส่งบล็อกเดิมของ Solana มาปรับและขัดเกลาเพิ่มเติม
บทบาทของ Rotor ฟังดูพื้นฐาน แต่สำคัญมาก เพราะ Votor จะ finalize ได้เร็วก็ต้องอาศัยเงื่อนไขง่าย ๆ คือ validator ต้องได้รับข้อมูลบล็อกเร็วพอที่จะตรวจสอบและโหวตได้ทันเวลา
บทวิเคราะห์จากบุคคลที่สามอธิบายว่า Rotor ใช้เส้นทาง relay ที่มีโครงสร้างมากขึ้นและถ่วงน้ำหนักตาม stake สำหรับการส่งต่อบล็อก โดยมีบางการประเมินชี้ไปที่เป้าหมายการกระจายบล็อกต่ำกว่า 100 มิลลิวินาที และมีแหล่งหนึ่งอ้างตัวเลข 18 มิลลิวินาทีภายใต้สภาพเครือข่ายทั่วไป ตัวเลขเหล่านี้ควรอ่านเป็นเป้าหมายหรือการประเมิน ไม่ใช่ผลวัดจริงบน mainnet แล้ว แต่ช่วยอธิบายว่าทำไม Rotor ต้องมาคู่กับ Votor: การส่งบล็อกที่เร็วและคาดเดาได้มากขึ้นคือฐานรองรับ finality ที่เร็วขึ้น
| ด้าน | สิ่งที่คาดว่าจะเปลี่ยน | ข้อควรระวัง |
|---|---|---|
| Finality | เป้าหมายหลักคือจาก 12.8 วินาทีใน Tower BFT เหลือราว 100–150 มิลลิวินาทีภายใต้ Alpenglow | Solana มี optimistic confirmation ที่ Anza อธิบายว่าอยู่ระดับประมาณ 1 วินาทีอยู่แล้ว ดังนั้นการเปลี่ยนแปลงใหญ่คือ finality ที่แข็งแรงกว่า ไม่ใช่แค่ความรู้สึกว่าเร็วขึ้น |
| การกระจายบล็อก | Rotor ตั้งใจทำให้การส่งบล็อกเร็วและคาดเดาได้มากขึ้น โดยมีการประเมินจากบุคคลที่สามว่าการกระจายอาจต่ำกว่า 100 มิลลิวินาที และมีตัวเลข 18 มิลลิวินาทีในบางสภาพแวดล้อม | ยังไม่ใช่ตัวเลขที่พิสูจน์แล้วบน mainnet |
| Throughput และ blockspace | Alchemy ระบุว่า vote ของ validator ปัจจุบันกินพื้นที่บล็อกของ Solana ราว 75% และการย้ายการโหวตออกนอกเชนอาจคืนพื้นที่ส่วนใหญ่ให้ธุรกรรมของผู้ใช้ | Alpenglow เป็นอัปเกรด consensus/finality เป็นหลัก ดังนั้นผลต่อ throughput เป็นผลทางอ้อม ไม่ใช่คำรับประกันว่า TPS ดิบจะเพิ่มทันที |
| ต้นทุน validator | หาก vote ด้าน consensus ไม่ต้องถูกโพสต์เป็นธุรกรรม on-chain จำนวนมากเหมือนเดิม validator ก็น่าจะเจอแรงกดดันด้านค่าธรรมเนียมโหวตประจำลดลง และมีบทสรุปหนึ่งกล่าวถึงโมเดล Validator Admission Ticket ที่เกี่ยวข้องกับต้นทุน | เงินที่ประหยัดได้จริงขึ้นกับ implementation สุดท้าย ค่าธรรมเนียม และเศรษฐศาสตร์ของเครือข่าย |
| ภาระเครือข่าย | บทสรุปเชิงเทคนิคบางแห่งประเมินว่าภาระการสื่อสารระหว่าง validator อาจลดลง รวมถึงข้ออ้างลดลงราว 40% | ยังเป็นการคาดการณ์จนกว่าจะมีข้อมูลหลัง deploy จริง |
สรุปแบบสั้นที่สุด Alpenglow สัญญาโดยตรงเรื่อง finality ที่ latency ต่ำลง ส่วนประโยชน์ด้าน throughput และต้นทุน validator มาจากการลด traffic ของ consensus โดยเฉพาะ overhead จาก vote มากกว่าการเปลี่ยนทุกส่วนของ execution บน Solana
แนวคิด Alpenglow ถูก Anza นำเสนอในฐานะ consensus protocol ใหม่ และถูกอธิบายว่าเป็นการเปลี่ยนแปลงครั้งใหญ่ที่สุดของ core protocol ของ Solana ต่อมา SIMD-0326 ถูกโพสต์ในเดือนสิงหาคม 2025 โดยระบุว่า Alpenglow เป็นการยกเครื่อง consensus protocol หลักของ Solana ครั้งสำคัญ
กระบวนการโหวตเริ่มช่วงปลายเดือนเดียวกัน โดย SolanaFloor รายงานว่าหน้าต่างโหวตเริ่มจาก epoch 840 ถึง epoch 842
การโหวต governance ผ่านในต้นเดือนกันยายน 2025 รายงานที่เผยแพร่มีตัวเลขสนับสนุนต่างกันเล็กน้อย: Alchemy ระบุว่าเห็นชอบ 98.27% ส่วน Blockworks ระบุว่า 98.94% ของผู้เข้าร่วมโหวตเห็นชอบ และทั้งสองรายงานพูดถึงการมีส่วนร่วมของ stake ราว 52% ใจความสำคัญที่ตรงกันคือข้อเสนอผ่าน governance ด้วยแรงสนับสนุนจาก validator อย่างท่วมท้น
ส่วนไทม์ไลน์จากการทดสอบไป mainnet ยังไม่นิ่ง แผนงานของ Anza เคยคาดว่า Alpenglow จะเข้าสู่ mainnet ในต้นปี 2026 ขณะที่สรุปจาก Alchemy ในเดือนเมษายน 2026 ระบุว่า Alpenglow อยู่ในขั้น private cluster testing และคาดว่าจะขึ้น mainnet ช่วงปลายปี 2026 Anza ยังบอกด้วยว่าโฟกัสในปี 2026 คือการพา Alpenglow ออกจาก development cluster ไปสู่การ deploy ที่กว้างขึ้น
ดังนั้นไทม์ไลน์ที่ระมัดระวังที่สุดจากข้อมูลที่มีคือ: เสนอและผ่าน governance ในไตรมาส 3 ปี 2025, พัฒนาและทดสอบใน private cluster ตลอดปี 2026, และอาจ rollout บน mainnet ภายในปี 2026 โดยปลายปี 2026 เป็นสมมติฐานที่อนุรักษนิยมกว่า หากการทดสอบยังเป็นด่านหลัก
หาก deploy ได้ตามที่เสนอ Alpenglow จะเป็นการเปลี่ยน consensus ของ Solana ที่มีนัยสำคัญที่สุดครั้งหนึ่ง Votor มีหน้าที่บีบขั้นตอนการโหวตและ finality ให้เหลือ 1 หรือ 2 รอบที่รวดเร็ว ส่วน Rotor มีหน้าที่ส่งข้อมูลบล็อกผ่านเครือข่าย validator ให้เร็วพอที่จะรองรับเส้นทาง consensus แบบ latency ต่ำ
ตัวเลข headline อย่าง finality ราว 100–150 มิลลิวินาทีถือว่าน่าจับตา แต่ยังควรอ่านในฐานะเป้าหมายทางวิศวกรรมจนกว่าจะพิสูจน์บน mainnet จริง อัปเกรดนี้มีแรงสนับสนุนด้าน governance แล้ว แต่การเปิดใช้งานจริงยังขึ้นกับการทดสอบ ความพร้อมของไคลเอนต์ และการพิสูจน์ว่าการลด overhead จาก vote รวมถึงต้นทุน validator จะยืนระยะได้ภายใต้สภาพเครือข่ายจริง