بدأ فريق Anza في تفعيل Alpenglow في شبكة الاختبار العامة لـ Solana. التحديث، الذي تم تقديمه في إطار SIMD-0326، من المفترض أن يستبدل آلية التوافق الحالية المستندة إلى TowerBFT وProof-of-History ويقلل الوقت المستهدف لإنهاء الكتل من حوالي 12.8 ثانية إلى 150 مللي ثانية. ستكون المرحلة الأولى هي Votor، التي تندرج ضمن Agave 4.3 وتغير طريقة تبادل الأصوات بين المدققين. بدلاً من الأصوات في شكل معاملات منفصلة، سيتبادل المشاركون في الشبكة الرسائل مباشرة ويجمعونها في شهادات مع توقيعات BLS. في الظروف المواتية، يمكن للكتلة أن تحصل على النهاية في جولة تصويت واحدة. إذا لم يكن ذلك كافياً، سينتقل البروتوكول إلى جولة إضافية ويستخدم نوعاً آخر من الشهادات. مع ذلك، فإن الـ 150 مللي ثانية المعلنة تتعلق بإنهاء الكتل وليس مدة الفتحة، التي يتم تنظيمها من خلال تغييرات بروتوكول منفصلة.
بالنسبة للمستخدمين العاديين، لا ينبغي أن يغير الانتقال المعايير الأساسية لعمل الشبكة: Alpenglow لا يؤثر على SVM، أو تنسيق المعاملات، أو الرسوم، أو نموذج الحسابات. التغييرات الأكثر وضوحاً ستؤثر على الخدمات التي تعمل مباشرة مع بيانات البلوكشين. يضيف Agave 4.3 إلى تدفقات Geyser وgRPC معرف bank_id، مما يسمح بتمييز عدة بنوك مرشحة ضمن فتحة واحدة. لذلك، سيتعين على المفهرسين والمستعرضين والأنظمة التحتية الأخرى مراعاة زوج slot وbank_id عند تخزين الأحداث مؤقتاً. بعد تنفيذ آلية التوافق الجديدة، يجب أن تقل الفروق بين حالتي confirmed وfinalized بشكل كبير. ستظل كلا الحالتين في API، لكن من المخطط إزالة confirmed لاحقاً. لن يتم تضمين معاملات التصويت في الكتل، ولن يحدد Proof-of-History بعد الآن وتيرة إنتاجها. آلية منفصلة تسمى Rotor، التي من المفترض أن تحل محل Turbine لنشر البيانات، ليست جزءاً من الإصدار الحالي من التحديث وسيتم تنفيذها لاحقاً.
سيتم الانتقال إلى آلية التوافق الجديدة على مراحل. حتى الحدود الانتقالية، ستستمر الشبكة في استخدام TowerBFT، وبعد تفعيل feature gate سيتم حساب 5000 فتحة. بعد ذلك، ستتوقف المعاملات الموجهة للمستخدمين مؤقتاً عن التضمين في الكتل حتى يصل المدققون إلى الحالة المطلوبة للتبديل. بعد ظهور كتلة بتأكيد متفائل من 82% من الحصة، سيصبح سلفها حتى الحدود الانتقالية نقطة البداية للسلسلة الجديدة. سيجمع المدققون شهادة BLS، ويتراجعون عن الكتل الأحدث وينقلون التوافق إلى Votor، وبعد ذلك ستستأنف معالجة معاملات المستخدمين. قبل الإطلاق في شبكة الاختبار العامة، تم اختبار الانتقال لعدة أشهر في مجموعة مجتمع منفصلة. بعد ذلك، يجب أن تمر الشبكة المطورة وإصدار بيتا من الشبكة الرئيسية بمراحل مماثلة. يهدف هذا الترتيب إلى الحفاظ على العمليات المؤكدة بالفعل أثناء تغيير آلية التوافق.