Solana(SOL) slot süresini 350 milisaniyeye indiriyor, işlem limitini de düşürüyor

Solana(SOL), blok üretim birimi olan slot süresini 400 milisaniyeden kademeli olarak azaltırken slot başına hesaplama limitini de aynı anda düşüren bir protokol güncellemesi üzerinde çalışıyor. Güncelleme sadece hızı artırmıyor; ağın tek seferde işlemesi gereken iş yükünü de ayarlayarak doğrulayıcılar üzerindeki baskıyı dengelemeyi hedefliyor.

Solana Vakfı, 6 Ağustos'ta (yerel saatle) yayımlanan değişiklik kaydında 400 milisaniyelik slotu 350 milisaniyeye indiren özellik kapısının devnet ve testnet ortamlarına ulaştığını duyurdu. 13'ünde yayımlanan bir sonraki kayıtta ise 350 milisaniyeden 300 milisaniyeye geçişin testnet ve devnette, 300 milisaniyeden 250 milisaniyeye geçişin ise yalnızca testnette devreye alındığı belirtildi.

Mainnet tarafında Agave v4.2 özelliğinin etkinleştirilmesi 17'sinde başlayacak şekilde planlandı. Ancak Agave v4.2 yayın takvimi belgesi, bu tarihin geçici olduğunu ve değişebileceğini özellikle vurguluyor. Dolayısıyla bu aşamayı mainnette 350 milisaniyelik geçişin tamamlandığı bir nokta değil, mainnet özellik etkinleştirmesinin başladığı bir eşik olarak okumak gerekiyor.

Buradaki asıl nokta, slot süresindeki kısalmanın hesaplama limitindeki düşüşle birlikte hareket etmesi. Solana geliştirme önerisi SIMD-0525 taslağı, slot süresini 400 milisaniyeden sırasıyla 350, 300, 250 ve 200 milisaniyeye indiren dört aşamalı bir geçiş öneriyor. Her aşamada 64 tick, 4 slotluk lider penceresi ve 432.000 slotluk epoch yapısı korunurken, slot başına iş limiti hedeflenen slot süresiyle orantılı biçimde azaltılıyor.

Slot, doğrulayıcılara blok üretme hakkının tanındığı zaman birimi. Slot süresi kısaldıkça blok üretme fırsatı daha sık geliyor, ancak her slot içinde işlenmesi, yayılması ve doğrulanması gereken yük de artıyor. Bu yüzden kısaltma oranı ile iş limiti birlikte ayarlanmazsa atlama oranında (skip rate) artış ya da dış sistemlerin zaman hesaplamalarında hatalar ortaya çıkabiliyor.

Solana daha önce mainnette blok başına hesaplama limitini 60 milyon CU'dan 100 milyon CU'ya yükseltmişti. 100M CU Blocks belgesine göre bu özellik 29 Temmuz'da mainnette etkinleştirildi ve o dönemde 400 milisaniyelik blok süresi korundu. SIMD-0525 tablosunda, 100 milyon CU baz alındığında 350 milisaniyelik aşamada maksimum blok CU'su 87,5 milyon, 300 milisaniyelik aşamada 75 milyon, 250 milisaniyelik aşamada 62,5 milyon, 200 milisaniyelik aşamada ise 50 milyon olarak veriliyor.

Bu yapı, saniyedeki teorik işlem tavanını sert biçimde yükseltmekten çok, slotları daha sık üretip her slotun taşıdığı iş yükünü azaltmaya yakın bir tasarım. Solana Vakfı'nın belgelerine göre kısa slotlar onay ve kesinleşme (finality) gecikmesini düşürüyor; 4 slotluk lider penceresi korunduğunda liderin blok üretme süresi 400 milisaniyelik yapıda 1,6 saniyeden, 350 milisaniyelik yapıda 1,4 saniyeye iniyor.

SIMD-0525 taslağı, özellik kapısı etkinleştirildikten sonra bile yeni limitin 1 epoch gecikmeyle uygulanacağını belirtiyor. Yani etkinleştirmenin hemen ardından kısaltılmış slot standardı devreye girmiyor; ağın yeni limiti bir sonraki epoch'ta kabul etmesine izin veren bir mekanizma söz konusu. Bu düzenleme, Turbine ve shred işleme sürecinde limitin çok erken uygulanmasından doğabilecek geçerlilik hatalarını azaltmayı amaçlıyor.

Bu düzenleme, Agave 4.2 hedef tarihinin ardından da mainnet özellik kapısının etkinleştirilmesinin ayrı bir süreç olarak kaldığına dair önceki haberle bağlantılı. Yazılım dağıtımı ile protokol özellik kapısının etkinleştirilmesi aynı şey değil. Doğrulayıcılar yeni istemciyi hazırlasa bile ağ kurallarının fiilen değiştiği an, özellik kapısı ve epoch gecikme kuralları birlikte değerlendirilerek anlaşılabiliyor.

Değişiklik cüzdanları, RPC'leri ve gezginleri (explorer) de etkileyebilir. SIMD-0525 taslağı, SDK sabitlerinin ve slot-zaman dönüştürme mantığının bir süre 400 milisaniye esasına dayalı kalabileceği konusunda uyarıyor. Ağ 350, 300, 250 ve 200 milisaniye esasına göre işlerken dış sistemler eski zaman hesaplamasını kullanmaya devam ederse, geçerlilik süreleri ya da ekranda görünen değerlerde sapmalar yaşanabilir.

Doğrulayıcı maliyeti de tartışma konusu. GitHub'daki bir tartışmada, slotların hızlanması durumunda gerçek zaman (wall-clock) bazında oy verme maliyetinin artabileceği görüşü dile getirildi. Slot sayısı arttıkça aynı gerçek zaman diliminde yapılması gereken oylama ve doğrulama sıklığının da artabileceği belirtildi.

Brennan Watt(Brennan Watt), Anza yetkilisi, aynı tartışmada “SIMD #525 birleştirildi ve Agave tarafındaki uygulama tamamlandı” dedi. Bu açıklama, önerinin kod tabanına işlendiğini ve Agave uygulamasının bittiğini gösteriyor; ancak işletme maliyeti ve uyumluluk kontrollerinin hâlâ ayrı bir başlık olarak beklediği anlamına geliyor.

Agave v4.2 yayın özeti, slot süresindeki kısalmanın yanı sıra işlem boyutunun büyütülmesi ve kira (rent) maliyetlerinin düşürülmesinin de aynı sürümde yer aldığını belirtiyor. Bu da güncellemenin tek başına bir hız iyileştirmesi değil, istemci ve protokol tarafında birden fazla özelliği bir araya getiren paket bir yükseltme olduğu anlamına geliyor.

Türkiye'deki kullanıcılar açısından, hissedilen hız kadar cüzdanların, borsaların ve altyapı sağlayıcılarının yeni slot süresi standardını doğru şekilde yansıtıp yansıtmadığı da önem taşıyor. Slot süresi kısalsa bile dış servislerin geçerlilik süreleri, ekran değerleri ve işlem takip mantığı 400 milisaniye esasında kalırsa, gerçek kullanımda karışıklık yaşanabilir.

Agave v4.2 takvim belgesi, mainnet özellik etkinleştirmesinin başlangıç tarihini 17 Ağustos, teslim tarihini ise 18 Ağustos olarak gösteriyor. Takvim geçici olarak sunulduğu için sonraki aşamaların özellik kapısı etkinleştirmesi ve epoch uygulama durumuna bakılarak teyit edilmesi gerekiyor.

Doğrulama kaynakları: SIMD-0525, Solana Changelog 6 Ağustos, Solana Changelog 13 Ağustos, Agave v4.2 takvimi, 100M CU Blocks, Agave 4.2 genel bakış.