4.096 bayta geçiş öncesi Solana(SOL) v1 formatında uyumluluk kontrolü

Solana(SOL)'ın yeni işlem formatı v1, mainnet aktivasyonu öncesinde altyapı uyumluluk denetiminden geçiyor. Tek işlemin azami boyutunu 1.232 bayttan 4.096 bayta çıkaran değişiklik, zincir konsensüsünden çok RPC, indeksleyici, gRPC ve komisyon sponsorlarının yeni formatı doğru okuyup okumadığına odaklanıyor.

Solana Vakfı(Solana Foundation), ağ yükseltme sayfasında Agave 4.2'nin mainnette devreye girdiğini, ancak 'Larger Transaction Sizes' özelliğinin 4'ünde (yerel saatle) itibarıyla etkinleştirilmeyi beklediğini açıkladı. Aynı özellik, v1 işlem formatı üzerinden mevcut işlem limitini yaklaşık 3,3 kat büyütüyor.

Bu değişiklik yalnızca boyut büyütmekten ibaret değil. SIMD-0296 ve SIMD-0385, büyük çoklu imza (multisig), sıfır bilgi kanıtı (ZK proof) ve toplu transfer gibi kullanım alanlarını gerekçe gösteriyor. v1'de mevcut işlemlerde kullanılan adres arama tablosuna (address lookup table) bağımlılık azalırken, komisyon ve kaynak limiti bilgisi transactionConfig adlı ayrı bir yapılandırmaya taşınıyor.

Mevcut sistemlerin okuma yöntemi tam da bu noktada sorun yaratabilir. İndeksleyici ve komisyon sponsorları yalnızca ComputeBudget instruction'ını tarayarak öncelik komisyonunu ya da hesaplama birimi limitini hesaplarsa, v1 işlemin fee cap değerini kaçırabilir ya da sıfır olarak okuyabilir. Solana Vakfı'nın transaction-v1 örnek deposu, v1 mesajlarının ComputeBudget instruction yerine TransactionConfig taşıdığını belirtiyor.

Solana RPC dokümantasyonu, getTransaction, getBlock ve blockSubscribe çağrılarına maxSupportedTransactionVersion: 1 değerinin eklenmesi gerektiğini bildiriyor. Bu değer atlanır ya da 0 bırakılırsa, v1 işlem geldiğinde getTransaction hata verebilir, getBlock ise ilgili bloğun tamamını okumakta başarısız olabilir.

Websocket abonelikleri de istisna değil. blockSubscribe, ayar uyumsuz olduğunda block: null döndürebilir. Solana geliştirici dokümantasyonu, bunun boş blok değil bir hata olarak ele alınması gerektiğini belirtiyor. v1 işlemler, serileştirilmiş işlemin ilk baytı olan 129, yani 0x81 ile tanımlanıyor.

gRPC ve Geyser tarafında ise daha sessiz hatalar yaşanabiliyor. Solana geliştirici dokümantasyonuna göre gRPC'de maxSupportedTransactionVersion gibi bir opt-in değer bulunmuyor, eski protobuf stub'ları da Message.config alanını atabiliyor. Bu durumda sistem durmuyor, ancak v1 işlemi v0 gibi işleyip komisyon ayarını gözden kaçırabiliyor.

Solana Vakfı'nın örnek deposu, @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0 ve yellowstone-grpc geyser 15.1.1 sürümlerini asgari sürüm olarak sunuyor. Okuma, gönderme, blok indeksleme ve gRPC için ayrı örnekler de paylaşılıyor.

Çekirdek araç tarafında doğrulama süreci de devam ediyor. anza-xyz'in solana-sdk deposundaki #831 numaralı sorun kaydı, v1 azami boyutu olan 4.096 baytın deserializer ve sanitizer bileşenlerinde tam olarak zorunlu kılınmadığını ortaya koyuyor. Buna karşın Solana durum sayfası, 4'ü itibarıyla Mainnet Beta RPC Nodes'un çalışır durumda olduğunu ve o gün bildirilen bir olay bulunmadığını gösteriyor.

Bu gelişme, Solana'daki v1 işlem limiti genişlemesiyle ilgili bir altyapı uyumluluk denetimi niteliği taşıyor. Önceki tartışma 4.096 baytlık limit ve küme bazlı özellik etkinleştirmesiyken, bu kez asıl mesele gerçek v1 işlemleri geldiğinde arka uç sistemlerin yeni yapıyı okuyup okuyamayacağı.

Solana yükseltme sayfası, 4'ü itibarıyla 'Larger Transaction Sizes' özelliğinin etkinleştirilmeyi beklediğini gösteriyor. Söz konusu takvim, Solana'nın işleme yapısını tek seferde değiştiren bir olaydan çok; cüzdanların, RPC'lerin, indeksleyicilerin ve geliştirme araçlarının sırayla hazırlanması gereken teknik bir yol haritasına benziyor.

Teknik açıdan v1 işlemler, mevcut v0 ve eski (legacy) işlemlerin yerini almıyor. Eski format çalışmaya devam ediyor, ancak daha büyük işlem boyutu ve transactionConfig kullanan uygulamalar için yeni format desteği şart koşuluyor. Blok zinciri altyapı yükseltmelerinde genellikle konsensüs kurallarının yanı sıra, veriyi okuyan ve saklayan çevre sistemlerin uyumluluğu asıl operasyonel riski belirliyor.

Komisyon sponsorları ve indeksleyiciler bu süreçten özellikle etkilenebilir. Komisyon tavanı ya da hesaplama birimi limiti yanlış okunursa, kullanıcı adına maliyeti üstlenen servisler beklenenden farklı bir maliyet yapısına maruz kalabilir; işlem analiz sistemleri de v1 işlemin kaynak ayarını hatalı kaydedebilir. Bu durum zincirin tamamen durmasıyla aynı türde bir arıza değil, ama servis operatörleri için ayrı bir kontrol gerektiriyor.

Solana üzerinden para yatırma/çekme ve zincir üstü izleme işleten yerel borsa ya da cüzdan sağlayıcıları da aynı sorundan bağımsız değil. Asıl işlemden çok blok/işlem sorgulama, indeksleme, risk izleme ve komisyon hesaplama yollarının v1 mesaj yapısını işleyip işlemediğinin kontrol edilmesi gerekiyor. Özellikle dış düğüm sağlayıcıları ya da Geyser tabanlı veri kullanılıyorsa, protobuf yeniden üretimi ve kütüphane sürüm kontrolü gerekiyor.

Solana v1 işlemleri fiilen gelmeden önce temel kontrol kalemleri şöyle sıralanıyor: △RPC çağrı seçeneklerinde maxSupportedTransactionVersion: 1 ayarı △transactionConfig kayıt yolunun yansıtılması △gRPC protobuf stub'larının yeniden üretilmesi △0x81 sürüm ön ekinin tanınması. Solana yükseltme sayfasına göre 'Larger Transaction Sizes' özelliği, 4 Eylül 2026 itibarıyla halen etkinleştirilmeyi bekliyor durumda.