सोलाना का Alpenglow अपग्रेड उसके सार्वजनिक डेवलपर नेटवर्क तक पहुंच गया है, जिससे एप्लिकेशन टीमें ऐसे सिस्टम का परीक्षण कर सकती हैं, जिसे ट्रांजैक्शन फाइनलिटी को लगभग 12.8 सेकंड से घटाकर करीब 150 मिलीसेकंड करने के लिए डिजाइन किया गया है.

Solana Foundation के upgrade page के अनुसार, Alpenglow अब devnet और testnet पर सक्रिय है, लेकिन mainnet पर अभी इसे सक्रिय नहीं किया गया है. Solana के core validator software को विकसित करने वाली Anza ने 25 सितंबर को devnet switch की घोषणा की, testnet के transition पूरा होने के एक दिन बाद.

ये दोनों नेटवर्क rollout के अलग-अलग हिस्सों को सेवा देते हैं. एप्लिकेशन टीमें devnet का उपयोग यह जांचने के लिए कर सकती हैं कि उनका software ऐसे tokens के साथ कैसे व्यवहार करता है जिनकी कोई वास्तविक कीमत नहीं है, जबकि testnet validators और infrastructure operators को अधिक चुनौतीपूर्ण परिस्थितियों में network software का परीक्षण करने की जगह देता है.

डेवलपर्स के लिए, नए devnet चरण का मतलब है कि वे Alpenglow के साथ एप्लिकेशंस की जांच कर सकते हैं, बिना इस इंतजार के कि सिस्टम उस blockchain तक पहुंचे जो users के funds संभालता है. Solana का mainnet अभी भी TowerBFT का उपयोग कर रहा है, इसलिए 150-मिलीसेकंड का आंकड़ा फिलहाल प्रस्तावित अपग्रेड का लक्ष्य बना हुआ है, न कि आज users के लिए उपलब्ध कोई finality समय.

Solana का Alpenglow validators द्वारा blocks को final करने का तरीका बदलता है

TowerBFT के तहत, validators votes को ऐसे ट्रांजैक्शंस के रूप में submit करते हैं जो blocks के अंदर दिखाई देते हैं. किसी block के final होने से पहले 32 slots में पर्याप्त votes का जमा होना जरूरी होता है, जिसमें वर्तमान में लगभग 12.8 सेकंड लगते हैं, Foundation के अनुसार.

Alpenglow के पहले चरण, जिसे Votor कहा जाता है, में validators एक-दूसरे को सीधे votes भेजते हैं. Foundation का कहना है कि यदि stake के कम-से-कम 80% का प्रतिनिधित्व करने वाले validators किसी block को स्वीकार करने के लिए vote करें, तो वह एक voting round के बाद finality तक पहुंच सकता है. यदि पहला round उस threshold तक नहीं पहुंचता, तो दूसरा round एक वैकल्पिक रास्ता देता है.

Finality वह बिंदु है जहां network किसी ट्रांजैक्शन पर इतना मजबूत सहमति बना लेता है कि उसके consensus rules के तहत उसे अब पलटा नहीं जा सकता. तेज परिणाम एक अमेरिकी exchange के लिए महत्वपूर्ण हो सकता है जो यह तय कर रहा हो कि Solana deposit को कब credit किया जाए, या किसी payment provider के लिए जो यह तय कर रहा हो कि merchant की sale को कब complete माना जाए. फिर भी, प्रत्येक सेवा funds जारी करने या ग्राहक को payment confirm करने से पहले अपनी स्वयं की जांचें लागू कर सकती है.

Foundation, finality को block produce होने में लगने वाले समय से अलग मानता है. सितंबर में, Solana ने अपना target slot time 300 मिलीसेकंड से घटाकर 250 मिलीसेकंड कर दिया, और एक अलग अपग्रेड के तहत इसे आगे 200 मिलीसेकंड तक घटाने की योजना है. छोटे slots इस बात को बदलते हैं कि network उन्हें कितनी बार produce कर सकता है; Alpenglow यह बदलता है कि validators किस तरह सहमत होते हैं कि कोई block final है.

crypto.news की एक पिछली रिपोर्ट में 23 सितंबर को testnet की तैयारियों को कवर किया गया था, जब डेवलपर्स public test के लिए Agave 4.3 तैयार कर रहे थे. devnet पर यह कदम अब एप्लिकेशन टीमों को उस upgraded consensus system तक पहुंच देता है, जिसका वे आम तौर पर development के लिए उपयोग करते हैं.

Mainnet से पहले block-data सेवाओं को बदलावों का सामना करना होगा

ऐसे एप्लिकेशन के लिए जो ट्रांजैक्शंस भेजता है और account balances पढ़ता है, Foundation का कहना है कि Alpenglow के लिए किसी migration की जरूरत नहीं है. Consensus upgrade के तहत transaction execution, fees और ट्रांजैक्शन भेजने के लिए उपयोग किए जाने वाले formats समान रहते हैं.

जो सेवाएं transaction histories बनाती हैं, उन्हें अधिक काम करना होगा. Network के किसी एक को चुनने से पहले Alpenglow उसी slot के लिए competing candidate blocks को उजागर कर सकता है. Foundation data providers से कहता है कि वे उन candidates को अलग-अलग रखें, फिर उस block को बनाए रखें जो confirmation तक पहुंचता है. अलग-अलग candidates के ट्रांजैक्शंस को मिलाने से किसी explorer या अन्य सेवा के रिकॉर्ड में गलती आ सकती है.

Validator votes भी blocks से गायब हो जाएंगे क्योंकि उन्हें अब ट्रांजैक्शंस के रूप में submit नहीं किया जाएगा. परिणामस्वरूप, ऐसा chart जो user transactions और validator votes दोनों को गिनता है, activation के बाद कम transaction total दिखाएगा, भले ही users समान संख्या में payments और trades करें. Foundation ने data providers से कहा है कि वे पुराने आंकड़ों पर आधारित comparisons और alerts को reset करें.

कुछ सेवाएं vote transactions से validator participation भी पढ़ती हैं. Alpenglow के तहत, Foundation का कहना है कि यह जानकारी block data से जुड़े certificates में स्थानांतरित हो जाती है, जिससे उन सेवाओं को यह बदलना होगा कि वे इसे कहां से प्राप्त करती हैं. Solana के Geyser या gRPC data streams का उपयोग करने वाले operators को उन identifiers का भी ध्यान रखना होगा जो किसी slot के भीतर candidate blocks को अलग करते हैं.

ये बदलाव devnet testing को exchanges, explorers और अन्य उन फर्मों के लिए प्रासंगिक बनाते हैं जो transaction records पर निर्भर हैं, जिनमें Solana से जुड़ी अमेरिकी सेवाएं भी शामिल हैं. उनके deposit rules उनका अपना operational निर्णय बने रहते हैं; network upgrade अपने-आप यह नहीं बदलता कि कोई platform funds कब उपलब्ध कराता है.

Mainnet activation की अभी भी कोई निश्चित तारीख नहीं है

Solana के पहले के Alpenglow roadmap ने प्रस्तावित mainnet rollout को Agave 4.3 और अक्टूबर के लक्ष्य से जोड़ा था. न तो testnet transition और न ही devnet activation live-network switch के लिए कोई पुष्टि की गई तारीख तय करते हैं.

Anza के software schedule के अनुसार, mainnet feature activations अस्थायी रूप से 28 सितंबर से फिर शुरू हो सकते हैं. Schedule उस दिन को Alpenglow की activation date के रूप में चिन्हित नहीं करता, और Foundation के status page पर भी यह upgrade अभी mainnet पर inactive सूचीबद्ध है.

Foundation, Votor को Alpenglow का पहला चरण बताता है. बाद का एक चरण, Rotor, network में blocks फैलाने के लिए उपयोग किए जाने वाले सिस्टम को बदलने के लिए योजनाबद्ध है. वर्तमान rollout voting और finality में बदलावों से संबंधित है, जबकि लगभग 150-मिलीसेकंड का लक्ष्य live-market conditions में settled ट्रांजैक्शंस के बजाय testing और simulations से आता है.