ارتقای Alpenglow سولانا به شبکه عمومی توسعه‌دهندگان آن رسیده و به تیم‌های اپلیکیشن اجازه می‌دهد سیستمی را آزمایش کنند که برای کاهش نهایی‌شدن تراکنش‌ها از حدود 12.8 ثانیه به تقریباً 150 میلی‌ثانیه طراحی شده است.

بر اساس صفحه ارتقا در بنیاد سولانا، Alpenglow اکنون روی devnet و testnet فعال است اما هنوز روی mainnet فعال نشده است. Anza که نرم‌افزار اصلی اعتبارسنج سولانا را توسعه می‌دهد، در 25 سپتامبر، یک روز پس از تکمیل انتقال testnet، این تغییر در devnet را اعلام کرد.

این دو شبکه بخش‌های متفاوتی از فرایند عرضه را پوشش می‌دهند. تیم‌های اپلیکیشن می‌توانند از devnet برای بررسی رفتار نرم‌افزار خود با توکن‌هایی که ارزش واقعی ندارند استفاده کنند، در حالی که testnet به اعتبارسنج‌ها و اپراتورهای زیرساخت فضایی می‌دهد تا نرم‌افزار شبکه را تحت شرایط سخت‌گیرانه‌تر آزمایش کنند.

برای توسعه‌دهندگان، مرحله جدید devnet به این معناست که می‌توانند اپلیکیشن‌ها را در برابر Alpenglow بررسی کنند، بدون آنکه منتظر بمانند سیستم به بلاک‌چینی برسد که سرمایه کاربران را مدیریت می‌کند. mainnet سولانا همچنان از TowerBFT استفاده می‌کند، بنابراین عدد 150 میلی‌ثانیه فعلاً یک هدف برای ارتقای برنامه‌ریزی‌شده است، نه زمان نهایی‌شدن در دسترس کاربران در حال حاضر.

Alpenglow سولانا نحوه نهایی‌سازی بلاک‌ها توسط اعتبارسنج‌ها را تغییر می‌دهد

در TowerBFT، اعتبارسنج‌ها رأی‌های خود را به‌صورت تراکنش‌هایی ارسال می‌کنند که داخل بلاک‌ها ظاهر می‌شوند. طبق اعلام بنیاد، باید تعداد کافی رأی در 32 اسلات انباشته شود تا یک بلاک نهایی شود؛ فرایندی که در حال حاضر حدود 12.8 ثانیه طول می‌کشد.

در فاز نخست Alpenglow که Votor نام دارد، اعتبارسنج‌ها به‌جای این کار، رأی‌ها را مستقیماً برای یکدیگر ارسال می‌کنند. بنیاد می‌گوید اگر اعتبارسنج‌هایی که دست‌کم 80 درصد از استیک را نمایندگی می‌کنند به پذیرش یک بلاک رأی دهند، آن بلاک می‌تواند پس از یک دور رأی‌گیری به نهایی‌شدن برسد. اگر دور اول به این آستانه نرسد، دور دوم مسیر دیگری برای نهایی‌سازی فراهم می‌کند.

نهایی‌شدن نقطه‌ای است که در آن شبکه بر سر یک تراکنش به اندازه کافی به توافق رسیده که دیگر بر اساس قواعد اجماع آن قابل بازگشت نباشد. نتیجه سریع‌تر می‌تواند برای یک صرافی آمریکایی در تصمیم‌گیری درباره زمان واریز موجودی سپرده سولانا، یا برای یک ارائه‌دهنده پرداخت در تصمیم‌گیری درباره کامل تلقی‌کردن فروش یک پذیرنده اهمیت داشته باشد. با این حال، هر سرویس ممکن است پیش از آزادسازی وجوه یا تأیید پرداخت برای مشتری، همچنان بررسی‌های خاص خود را اعمال کند.

بنیاد میان نهایی‌شدن و زمانی که برای تولید یک بلاک لازم است تفاوت قائل می‌شود. در سپتامبر، سولانا زمان هدف اسلات را از 300 میلی‌ثانیه به 250 میلی‌ثانیه کاهش داد و کاهش بیشتر تا 200 میلی‌ثانیه نیز در قالب یک ارتقای جداگانه برنامه‌ریزی شده است. اسلات‌های کوتاه‌تر، تعداد دفعاتی را که شبکه می‌تواند بلاک تولید کند تغییر می‌دهند؛ Alpenglow اما نحوه توافق اعتبارسنج‌ها بر نهایی‌بودن یک بلاک را تغییر می‌دهد.

گزارش قبلی crypto.news در 23 سپتامبر به آمادگی‌های testnet پرداخت؛ زمانی که توسعه‌دهندگان در حال آماده‌سازی Agave 4.3 برای آزمایش عمومی بودند. انتقال به devnet اکنون به تیم‌های اپلیکیشن دسترسی به سیستم اجماع ارتقایافته را در شبکه‌ای می‌دهد که معمولاً برای توسعه از آن استفاده می‌کنند.

سرویس‌های داده بلاک پیش از mainnet با تغییرات روبه‌رو هستند

برای اپلیکیشنی که تراکنش ارسال می‌کند و موجودی حساب‌ها را می‌خواند، بنیاد می‌گوید Alpenglow نیازی به مهاجرت ندارد. اجرای تراکنش‌ها، کارمزدها و فرمت‌های مورد استفاده برای ارسال تراکنش‌ها تحت این ارتقای اجماع بدون تغییر باقی می‌مانند.

سرویس‌هایی که تاریخچه تراکنش‌ها را می‌سازند، کار بیشتری در پیش دارند. Alpenglow می‌تواند پیش از آنکه شبکه یکی را انتخاب کند، بلاک‌های کاندیدای رقیب برای یک اسلات یکسان را آشکار کند. بنیاد به ارائه‌دهندگان داده توصیه می‌کند این کاندیداها را از هم جدا نگه دارند و سپس بلاکی را که به تأیید می‌رسد حفظ کنند. ترکیب‌کردن تراکنش‌های متعلق به کاندیداهای مختلف می‌تواند باعث شود یک اکسپلورر یا سرویس دیگر، سابقه‌ای نادرست ثبت کند.

رأی‌های اعتبارسنج‌ها نیز از بلاک‌ها حذف خواهند شد، زیرا دیگر به‌صورت تراکنش ارسال نمی‌شوند. در نتیجه، نموداری که هم تراکنش‌های کاربران و هم رأی‌های اعتبارسنج‌ها را می‌شمارد، پس از فعال‌سازی مجموع تراکنش کمتری را نشان خواهد داد، حتی اگر کاربران همان تعداد پرداخت و معامله را انجام دهند. بنیاد به ارائه‌دهندگان داده گفته است مقایسه‌ها و هشدارهایی را که بر مبنای ارقام قدیمی ساخته شده‌اند بازتنظیم کنند.

برخی سرویس‌ها همچنین مشارکت اعتبارسنج‌ها را از روی تراکنش‌های رأی استخراج می‌کنند. بنیاد می‌گوید در Alpenglow این اطلاعات به گواهی‌های پیوست‌شده به داده‌های بلاک منتقل می‌شود و این موضوع مستلزم آن است که این سرویس‌ها محل دریافت این داده را تغییر دهند. اپراتورهایی که از استریم‌های داده Geyser یا gRPC سولانا استفاده می‌کنند نیز باید شناسه‌هایی را که بلاک‌های کاندیدا را درون یک اسلات از هم متمایز می‌کنند، در نظر بگیرند.

این تغییرات باعث می‌شود آزمایش روی devnet برای صرافی‌ها، اکسپلوررها و دیگر شرکت‌هایی که به سوابق تراکنش متکی هستند، از جمله سرویس‌های آمریکایی متصل به سولانا، اهمیت پیدا کند. قواعد واریز آن‌ها همچنان یک تصمیم عملیاتی مختص خودشان باقی می‌ماند؛ ارتقای شبکه به‌طور خودکار زمان در دسترس قرار گرفتن وجوه در یک پلتفرم را تغییر نمی‌دهد.

فعال‌سازی روی mainnet هنوز تاریخ قطعی ندارد

نقشه راه قبلی Alpenglow در سولانا، عرضه پیشنهادی روی mainnet را به Agave 4.3 و هدف‌گذاری برای ماه اکتبر گره زده بود. نه انتقال testnet و نه فعال‌سازی devnet هیچ‌کدام تاریخ تأییدشده‌ای برای سوییچ روی شبکه زنده تعیین نمی‌کنند.

برنامه زمانی نرم‌افزار Anza به‌طور موقت امکان ازسرگیری فعال‌سازی قابلیت‌ها روی mainnet را از 28 سپتامبر فراهم می‌کند. این برنامه آن روز را به‌عنوان تاریخ فعال‌سازی Alpenglow معرفی نمی‌کند و صفحه وضعیت بنیاد نیز همچنان این ارتقا را روی mainnet غیرفعال نشان می‌دهد.

بنیاد، Votor را فاز نخست Alpenglow توصیف می‌کند. فاز بعدی که Rotor نام دارد، قرار است جایگزین سیستمی شود که برای انتشار بلاک‌ها در سراسر شبکه به کار می‌رود. عرضه فعلی مربوط به تغییرات رأی‌گیری و نهایی‌شدن است، در حالی که هدف حدوداً 150 میلی‌ثانیه‌ای بر پایه آزمایش‌ها و شبیه‌سازی‌ها مطرح شده، نه تراکنش‌هایی که در شرایط واقعی بازار تسویه شده باشند.