بنیاد سولانا در آخرین گزارش مهندسی خود، انتشار نسخه‌های جدیدی از نرم‌افزار ولیدیتور و ابزارهای توسعه‌دهنده را همراه با اقداماتی که پس از فعال‌سازی به‌روزرسانی Alpenglow صورت گرفته، اعلام کرده است. این گزارش جزئیات مشخصی از محدودیت‌ها یا گام‌های آتی را نیز مشخص می‌کند، بنابراین تأثیر پیاده‌سازی و بازار نباید از پیش فرض شود.
**انتشار به‌روزرسانی‌های فنی**
گزارش تغییرات ۲۲ اکتبر، انتشار Agave v4.3.2، Firedancer mainnet v26.10.4 و Web3.js v3.1.1 را در میان آخرین نسخه‌های منتشر شده ذکر می‌کند. این بنیاد، Alpenglow را به عنوان یک ویژگی فعال شده در شبکه اصلی (mainnet) ثبت کرده و Firedancer نیز در حال کنار گذاشتن کد TowerBFT است.
توسعه‌دهندگان Agave در حال بهبود ورودی/خروجی سیستم فایل و ارتباطات ولیدیتورها هستند و همچنین بر روی بررسی زودهنگام استقرار برنامه‌های sBPF که پشتیبانی نمی‌شوند، کار می‌کنند. توسعه‌دهندگان کلاینت، تراکنش V1 را به عنوان یک جهت‌گیری بلندمدت بررسی می‌کنند، اما کنار گذاشتن تراکنش‌های قدیمی همچنان یک پیشنهاد است و نه یک حذف نهایی.
**اهمیت برای بازارهای رمزارز**
اغلب تیترهای پروتکل بر روی یک تاریخ فعال‌سازی واحد تمرکز می‌کنند، در حالی که کار عملی توسعه‌دهندگان پس از آن ادامه می‌یابد. کتابخانه‌ها باید رفتار شبکه را منعکس کنند، پیاده‌سازی‌های ولیدیتور به مدیریت منابع قابل اعتماد نیاز دارند و کیف پول‌ها باید با تکامل فرمت‌های تراکنش سازگار شوند. تیم‌های مستقل متعدد کلاینت اهمیت دارند زیرا یک شبکه با عملکرد بالا همچنان به تنوع عملیاتی و مسیری برای ارتقا نیاز دارد که برنامه‌های موجود را از رده خارج نکند.
زیرساخت بلاک‌چین در خلاء بهبود نمی‌یابد. مهندسان باید برنامه‌های موجود، اپراتورهای نود، سازگاری کلاینت و نحوه رفتار خطاها در شرایط تحت فشار را در نظر بگیرند. تغییری که در سطح پروتکل ساده به نظر می‌رسد، می‌تواند یک مشکل هماهنگی پیچیده ایجاد کند. این تمایز برای سرمایه‌گذارانی که سعی در جداسازی یک تغییر ساختاری قابل قبول از تیتر خبری دارند که ممکن است بلافاصله بر قیمت یا فعالیت درون زنجیره‌ای تأثیر نگذارد، اهمیت دارد.
**محدودیت‌های گزارش**
فهرست تغییرات، نسخه‌های منتشر شده، پیشنهادات و کارهای در حال انجام را با هم مخلوط می‌کند. نادرست خواهد بود که هر ایده ذکر شده — به ویژه کنار گذاشتن فرمت‌های قدیمی تراکنش — را به عنوان فعال شده در شبکه اصلی در نظر گرفت.
ادعاهای مربوط به عملکرد نیز نیازمند تعاریف دقیق است. توان عملیاتی، قطعیت، پاسخگویی، هزینه و تحمل خطا، معیارهای متفاوتی هستند. بهبود یکی، لزوماً همه آن‌ها را بهبود نمی‌بخشد، به خصوص زمانی که یک کیف پول، صرافی یا برنامه، تأییدیه‌های خاص خود را اضافه می‌کند.
**بستر گسترده‌تر**
فهرست تغییرات توسعه‌دهندگان سولانا در ۲۲ اکتبر، در چارچوب تغییر گسترده‌تر به سمت نرم‌افزار ولیدیتور قرار می‌گیرد. این حوزه یک چالش تکرارشونده دارد: مزایا را قبل از تکمیل جزئیات عملیاتی آسان‌تر می‌توان توصیف کرد. ذینفعان مختلف، موفقیت را به شیوه‌های متفاوتی اندازه‌گیری می‌کنند. کاربر خواهان وضوح و دسترسی قابل پیش‌بینی است؛ اپراتور خواهان کنترل‌های قابل اعتماد و هزینه‌های قابل مدیریت است؛ یک موسسه در صورت بروز مشکل، خواهان پاسخگویی است. این دیدگاه‌ها می‌توانند در تضاد باشند و اعلامیه منبع باید با در نظر گرفتن این موضوع خوانده شود.
این تمایز همچنین شکل خواندن به‌روزرسانی‌های آینده را تعیین می‌کند. یک همکاری جدید، پیشنهاد یا نسخه نرم‌افزار یک نقطه عطف قابل تأیید است. پذیرش، عملکرد مداوم و اثرات مالی نیازمند شواهد اضافی است. به همین دلیل است که گزارش‌های بعدی باید ویژگی‌های منتشر شده، ویژگی‌های برنامه‌ریزی شده و استفاده اندازه‌گیری شده را تفکیک کنند، به جای اینکه آن‌ها را در یک ادعا ترکیب کنند.
**آنچه باید در آینده رصد کرد**
به پذیرش پایدار کلاینت، حاکمیت فرمت تراکنش، تأیید رفع اشکالات و انتشار به‌روزرسانی‌های بعدی که نشان می‌دهد آیا انتقال برای یکپارچه‌سازان هموار است یا خیر، توجه کنید.
آزمون عملیاتی پس از پیشنهاد یا یادداشت انتشار فرا می‌رسد: آیا تیم‌های مختلف کلاینت می‌توانند آن را پیاده‌سازی کنند، آیا توسعه‌دهندگان می‌توانند به طور ایمن ارتقا دهند و آیا کاربران می‌توانند هنگام افزایش فعالیت به آن اعتماد کنند؟ این همان تفاوت بین یک طرح جذاب و یک زیرساخت بادوام است. شواهد بعدی باید از به‌روزرسانی‌های پیاده‌سازی رسمی و نتایج قابل اندازه‌گیری حاصل شود، نه از فرض اینکه یک اطلاعیه خبری، پذیرش یا واکنش به قیمت توکن را تضمین می‌کند.
