Solana, doğrulayıcı oylarını işlem bloklarının dışına taşıyan Votor sistemine hazırlanıyor. SOL sahipleri için token değiştirme işlemi gerekmiyor; yazılım, oy hesabı bakiyesi ve veri akışlarına ilişkin hazırlıklar doğrulayıcılarla altyapı sağlayıcılarını ilgilendiriyor.
Solana, ana ağındaki TowerBFT konsensüsünden Alpenglow’un Votor sistemine bugün geçmeyi planlıyor. Agave istemcisini geliştiren Anza’nın 20 Ekim tarihli duyurusu, 21 Ekim için yaklaşık 17.00 TSİ’yi ve 459.653.000’inci slotu gösteriyor. Slot, ağda bir doğrulayıcıya blok üretme sırasının ayrıldığı zaman dilimi. Konsensüs, doğrulayıcıların geçerli işlem geçmişi üzerinde ortak karara varmasını sağlayan yöntem.
Solana Foundation’ın güncel geçiş sayfası, 1064. epoch’un başlangıcını yaklaşık 16.20 TSİ olarak tahmin ediyor. Epoch, doğrulayıcı ve ödül hesaplarının dönemidir. Özellik etkinleştirilse de ilk 5.000 slot boyunca TowerBFT çalışacak; Foundation yaklaşık 18 dakikalık bekleme öngörüyor. Anza’nın verdiği saat konsensüs değişimini hedefliyor. Geçiş, ağ belirtilen slota ulaştığında başlayacak; tahmini saat slotların ilerleme hızına göre değişebilir.
Anza, 19 Ekim’de slotların beklenenden hızlı ilerlediğini ve başlangıcın önceki tahminden erkene kaydığını bildirdi. Aşağıdaki 20 Ekim paylaşımı, güncellenen geçiş tahminini ve sınır slotunu içeriyor:
Anza — 20 Ekim Alpenglow geçiş duyurusu
Gönderi, açtığınızda X üzerinden yüklenir.
150 milisaniye hedefi neyi değiştirecek?
Anza’nın protokol açıklamasına göre Votor, doğrulayıcıların oylarını zincir üzerinde işlem olarak yazmak yerine birbirlerine doğrudan iletmesini sağlıyor. Oyların ağırlığı, doğrulayıcıya bağlı etkin stake miktarına göre belirleniyor; oylar birleştirilerek sertifika oluşturuluyor. Stake’in en az %80’inin desteğiyle tek turda; %60 eşiklerinin kullanıldığı iki turlu yolla da kesinleşme mümkün. İki yol eşzamanlı çalışıyor; blok, koşulları önce sağlayan yolla kesinleşiyor. Yaklaşık 150 milisaniye, her işlem için değişmez bir süre veya uygulamanın kullanıcıya yanıt verme garantisi olarak sunulmuyor.
İlk aşama Votor, bloklar üzerinde anlaşmaya varma yöntemini değiştiriyor. Blok verisini ağda dağıtan Turbine’ın yerini alması planlanan Rotor ise daha sonraki bir sürüme bırakıldı; tarihi açıklanmadı. Solana sanal makinesi, işlem biçimleri ve kullanıcı işlem ücretlerinin işleyişi korunuyor. Ayrı bir yükseltmeyle 200 milisaniyeye indirilen slot süresi, Alpenglow’un 150 milisaniyelik kesinleşme hedefiyle aynı ölçü değil.
Solana’nın resmî kanalındaki 28 Eylül 2026 tarihli videonun 22:32–24:44 bölümü, Jacob Creech ve Anza araştırma yöneticisi Roger Wattenhofer’ın stake ağırlıklı oyları ve BLS imzalarıyla sertifika oluşturulmasını anlattığı kaydı içeriyor. BLS, birden fazla doğrulayıcının imzasını ortak bir sertifikada birleştirmeye yarıyor.
Doğrulayıcıların yazılım ve bakiye koşulları
Foundation, geçiş öncesinde Agave, Jito-Solana veya Harmonic Salsa’nın 4.3.2 sürümünü istiyor. Anza da 16 Ekim’de performans ve kararlılık düzeltmelerini içeren Agave 4.3.2’yi önerdi. Firedancer ve Frankendancer geçiş sırasında desteklenmediği için ilgili operatörlerin Agave tabanlı istemciye geçmesi gerekiyor. Operatörlerin hazırlığı 1064. epoch başlamadan tamamlaması isteniyor.
Anza’nın oy hesabı belgesi, Validator Admission Ticket (VAT) ücretini her epoch için 0,8 SOL olarak belirliyor. Tutar, hesabın kira muafiyeti için tutması gereken asgari bakiyeye ek olarak oy hesabında bulunmalı. Önceki oy işlemlerinin masrafını ödeyen doğrulayıcı kimlik hesabına SOL koymak VAT koşulunu karşılamıyor. Ücret oy hesabından alınarak yakılacak.
| İşlem veya koşul | Geçerli dönem / sonuç |
|---|---|
| 1064. epoch başında ilk 0,8 SOL ödeme | 1065. epoch’ta doğrulayıcı katılımı |
| Sonraki her E epoch’u başında ödeme | E + 1 döneminde katılım |
| Oy hesabında yeterli bakiye bulunmaması | Sonraki epoch’ta oy verememe ve blok üretememe |
| Blok geliri alıcı hesabının E döneminde değiştirilmesi | Değişikliğin E + 2 döneminde uygulanması |
Operatör, blok gelirini oy hesabına yönlendirerek sonraki ücretlerin karşılanmasını kolaylaştırabilir. Ancak Anza, komisyon gelirinin VAT’ı karşılayacağının garanti olmadığını ve dönem sınırında gelen ödüllerin kontrol anındaki eksik bakiyeyi kurtarmayacağını belirtiyor. İlk ücret için önceden bakiye bulundurulması gerekiyor. Ödeme yapılamazsa takip eden dönemin doğrulayıcı ödülleri de kaybediliyor. Yeni SOL üretiminden gelen komisyonun varsayılan alıcısı oy hesabı; blok gelirinin varsayılan alıcısı ise doğrulayıcı kimlik hesabı.
Kısa geçiş aralığı ve veri hizmetlerindeki değişiklikler
SIMD-0384 geçiş tasarımı, sınır slotundan itibaren blokların yalnız doğrulayıcı oylarını taşımasını öngörüyor. Operatörler, stake’in en az %82’sinin katıldığı başlangıç sertifikası üzerinde anlaşınca Votor’a geçip kullanıcı işlemlerini yeniden alacak. Triton One’ın 20 Ekim güncellenen açıklaması, kullanıcı işlemlerinin bloklara girmediği aralığı normal koşullarda yaklaşık iki slot, yani 400 milisaniye olarak anlatıyor. Süre bir beklenti; ana ağda gerçekleşmiş kesinti ölçümü değil. Tasarım, geçişten önce onaylanmış kullanıcı işlemlerini korumayı amaçlıyor.
Ön onay akışlarını kullanan hizmetler için bekleme daha uzun olabilir. Triton, Harmonic’in blok paketleme ve ön onay hizmetlerinin geçişten yaklaşık bir saat önce durup ilk artımlı snapshot sonrasında dönmesini; Jito BAM’ın aynı hizmetlerinin ise yaklaşık 12 saat önce durup geçişten yaklaşık 12 saat sonra kademeli olarak açılmasını bekliyor. Süreler sağlayıcıların bakım planlarına bağlı. Jito’nun 9 Ekim’de duyurduğu BAM bakım planı, standart Block Engine işlem paketlerinin çalışmaya devam edeceğini belirtiyordu.
İşlem sayısını izleyenler, geçiş sonrasında saniyedeki toplam işlem sayısında (TPS) düşüş görebilir. Doğrulayıcı oyları bloklardan çıkarıldığı için eski sayaçların kapsadığı işlem kümesi değişiyor. Triton, yalnız toplam sayaca bakarak kullanıcı faaliyetinin azaldığı sonucuna varılmaması ve uyarı eşiklerinin yeniden düzenlenmesi gerektiğini belirtiyor.
“Tarihlere veya tweet’lere göre karar vermeyin. RPC düğümünüze sorun.”
Triton One, 20 Ekim 2026 — anlamı korunarak Türkçeye çevrildi
Geyser veya gRPC üzerinden blok verisi alan yazılımlar, aynı slot için birden fazla aday blokla karşılaşabilecekleri için akışı (slot, bank_id) ikilisiyle ayırmalı. bank_id her düğümün kendi sayacı olduğundan farklı sağlayıcılardan gelen verileri eşleştirmek için blok hash’i gerekiyor. Foundation, Agave 4.3’te nadir olan çoklu aday durumunun 4.4’teki hızlı lider devriyle daha sık görülebileceğini belirtiyor. Kesinleşmeden önceki processed durumu da kesin sonuç sayılmıyor.
Anza’nın konsensüs belgesi, oy veren doğrulayıcı kümesinin dışındaki RPC düğümlerinin kesinleşme bilgisini daha geç alabileceğini açıklıyor. Doğrudan Votor mesajları yerine sonraki bloğun sertifikasını bekleyen düğümde, üretilen bir blok aralığına kadar ek gecikme oluşabilir; atlanan veya geciken bloklar süreyi uzatabilir. RPC hizmeti, cüzdan ve uygulamaların ağdan veri aldığı arayüzdür; sertifikanın geç ulaşması, kesinleşmiş işlemin ekranda daha sonra görünmesine yol açabilir.
Geçiş nasıl doğrulanacak? Agave 4.3 ile gelen getAgGenesisCert çağrısı null döndürüyorsa sorgulanan küme TowerBFT kullanıyor. Sertifika nesnesi dönmesi Alpenglow’a geçildiğini gösteriyor. Method not found hatası ise eski RPC yazılımını gösterebilir; geçişin gerçekleşmediğine dair aynı kanıt değildir. Sorgunun hangi ağa yöneltildiği de kontrol edilmeli: test ağından alınan sertifika, ana ağdaki geçişi doğrulamaz.
