Solana (SOL) ağında Alpenglow öncesi ve sonrası yazılım güncellemeleri

Solana Foundation (Solana Vakfı), Alpenglow mutabakat geçişi öncesinde ve sonrasında doğrulayıcı yazılımı ile geliştirici araçlarının yeni sürümlerini yayımladı. Güncellemeler doğrulayıcıların çalışma koşullarını ve blok verilerinin işlenmesini de etkiliyor.

Vakıf, 22 Ekim tarihli geliştirici değişiklik günlüğünde Agave v4.3.2, Firedancer ana ağ v26.10.4, Web3.js v3.1.1 ve çeşitli JavaScript SDK güncellemelerini listeledi. Güncellemeler arasında adres arama tabloları ile stake, sistem ve token programları için SDK’lar yer alıyor. SDK’lar, uygulama ve program geliştirmek için kullanılan araç setleridir.

Sürümlerin yayımlandığı tarihler farklı. Agave v4.3.2, 15 Ekim’de; Web3.js v3.1.1, 19 Ekim’de; Firedancer v26.10.4 ise 21 Ekim’de yayımlandı. Agave ve Web3.js, Alpenglow etkinleştirilmeden önce çıktı. Firedancer’ın yayımlanma tarihi etkinleştirmeyle aynı olduğundan, yalnızca tarihlere bakarak hangisinin önce gerçekleştiği belirlenemiyor.

Solana ana ağında Alpenglow, 21 Ekim saat 22.36’da (Kore saatiyle) başlayan 1064. epokta etkinleştirildi. Geçiş, doğrulayıcıların işlem sırası ve nihai durum üzerinde uzlaşma biçimini değiştirdi.

Solana Vakfı’nın geçiş duyurusunda, eski TowerBFT’nin yaklaşık 5.000 slot boyunca kullanılacağı ve yeni mutabakatın 459.653.000 numaralı slottan itibaren çalışmaya başlayacağı belirtildi. Vakıf, 21 Ekim’deki geçiş duyurusunda nihai kesinleşme süresini yaklaşık 12,8 saniyeden 150 milisaniyeye indirmeyi hedeflediğini açıkladı.

150 milisaniye ölçülmüş bir sonuç değil. TokenPost daha önce ana ağın ilk döneminde kesinleşme süresinin 6,6 saniye olduğunu ve 0,15 saniyelik hedefe henüz ulaşılmadığını bildirmişti.

Alpenglow geçişi programların yürütülmesini, işlem biçimini veya ücret sistemini değiştirmedi. Buna karşılık doğrulayıcıların oy işlemleri bloklardan çıkarıldı; işlem durumları olan ‘confirmed’ ve ‘finalized’ aynı durumu ifade etmeye başladı. Proof of History’deki (PoH) tick öğeleri de veri akışından kaldırıldı.

Bloklardaki işlem sayısını hesaplayan veya veri akışlarını indeksleyen geliştiricilerin mevcut işleme ölçütlerini gözden geçirmesi gerekiyor. Oy işlemlerini de sayan göstergeleri geçiş öncesi ve sonrası için aynı ölçütle karşılaştırmak zorlaşabilir. Bu değişiklikler SDK güncellemelerinden bağımsız olarak Alpenglow’un etkinleştirilmesiyle gerçekleşti.

Firedancer v26.10.4 sürüm notlarında, Agave ile Firedancer arasındaki gossip tablolarının uyuşmamasının yol açtığı trafik ve işlem yükü sorununun giderildiği belirtildi. Düğüm geride kaldığında kullanılan kurtarma algoritması da düzenlendi. Vakfın değişiklik günlüğü Firedancer’ın yeni mutabakata katıldığını kaydetti.

Ancak geçiş sırasındaki destek koşulları ayrı değerlendirilmeli. Solana Vakfı’nın duyurusunda, o sırada Firedancer ve Frankendancer’ın geçişi desteklemediği, bu nedenle doğrulayıcıların Agave tabanlı istemci kullanması gerektiği belirtildi. Daha sonraki sürümlerin yayımlanması veya yeni mutabakata katılım kayıtları, geçiş anında hangi istemcinin kullanıldığını göstermez.

Doğrulayıcıların oy hesaplarında muafiyet için gereken asgari bakiyenin 0,8 SOL üzerinde tutması gerekiyordu. Vakıf, bu bakiyenin doğrulayıcı katılım maliyeti olan ‘Validator Admission Ticket’ için kullanıldığını ve koşulu karşılamayanların sonraki epokta oylama ve blok üretimine katılamayacağını bildirdi.

Agave değişiklik günlüğünde, üzerinde çalışılmaya devam edilen iyileştirmeler de yer aldı. Bunlar arasında dosya sistemi girdi/çıktısında sayfa hatalarını azaltmaya yönelik tampon ayarları, stake miktarını hesaba katan gossip mesajı işleme ve hesapların stake listelerine daha az bağımlı anlık görüntü yükleme çalışmaları bulunuyor. Desteklenmeyen sBPF program sürümlerini yükleme öncesinde saptayan bir CLI denetimi de hazırlanıyor.

Web3.js v3.1.1, mevcut v3 sürümünün devamı niteliğinde. TokenPost, 6 Ekim’de Web3.js v3’ün yayımlanmasının mevcut uygulamalardaki asenkron kodda değişiklik gerektirdiğini bildirmişti.

Web3.js değişiklik günlüğünde yalnızca Transaction V1’i destekleme seçeneği de tartışıldı. Bu değerlendirme, eski ve V0 işlem biçimlerini sınırlayacak ayrı bir SIMD önerisinin sunulması ihtimaline dayanıyor. Dolayısıyla eski işlem biçimlerinin kullanımdan kaldırıldığı anlamına gelmiyor.