4.096 bayt: Solana'da v1 işlem formatıyla boyut limiti büyüyor

Solana(SOL), tek bir işlemin taşıyabileceği maksimum veri boyutunu 1.232 bayttan 4.096 bayta çıkaran v1 işlem format güncellemesini hazırlıyor. Mevcut sınırdan yaklaşık 3,3 kat daha büyük işlemlerin tek seferde ağa gönderilmesine imkan tanıyan teknik bir değişiklik bu.

Solana Vakfı(Solana Foundation), resmi yükseltme belgesinde 'Larger Transaction Sizes' başlıklı değişikliği 'Pending Feature Activation', yani etkinleştirme bekleyen özellik olarak sınıflandırdı. Güncelleme SIMD-0296 ve SIMD-0385 tekliflerine dayanıyor. Resmi yükseltme panosu Agave 4.2 sürümünü Ağustos 2026 dağıtım sürümü olarak gösterirken, işlem boyutu genişletme özelliğini hâlâ etkinleştirme bekleyen durumda listeliyor.

Güncellemenin merkezinde işlem limiti var. Solana'nın mevcut işlem boyutu sınırı 1.232 bayttı ve SIMD-0296 belgesine göre bu sınır IPv6 MTU tasarımındaki 1.280 baytlık üst sınırdan geliyordu. Başlık gibi alanlar çıkarıldığında gerçek işlem yüküne 1.232 bayt kalıyordu.

Solana, QUIC protokolüne geçişle birlikte daha büyük işlemlerin gönderilebileceği bir altyapı oluştuğunu değerlendirerek yeni limiti 4.096 bayt olarak belirledi. Ağın veri iletim yapısı değiştikçe, eski paket boyutu kısıtına göre belirlenmiş işlem limiti de yeniden ayarlanıyor.

v1 formatı, mevcut v0 ve eski (legacy) işlem türlerinin yerini almıyor. Daha büyük işlem boyutunu kullanmak isteyen uygulamaların, cüzdanların ve indeksleyicilerin yeni formata uyum sağlaması gerekiyor. Solana RPC belgelerine göre v1 mesajlarını alabilmek için isteğe maxSupportedTransactionVersion: 1 parametresinin eklenmesi gerekiyor.

RPC belgelerine göre v1 mesajlarında hesaplama limiti, veri boyutu sınırı ve öncelik ücretini taşıyan bir transactionConfig nesnesi yer alıyor. Bu nesnenin içinde computeUnitLimit, loadedAccountsDataSizeLimit ve priorityFee alanları bulunuyor. Bu yapı, kaynak talebinin ayrı bir talimatla (instruction) iletildiği eski yöntemden farklı.

Teknik yapı da değişiyor. SIMD-0385'e göre v1 işlemleri 129 sürüm baytını kullanıyor ve kaynak talebini mevcut ComputeBudgetProgram talimatı yerine işlem başlığındaki bir yapılandırma maskesiyle taşıyor. Adres arama tabloları (ALT) ise v1 tarafından desteklenmiyor.

Adres arama tabloları, tüm adresleri işlemin içine doğrudan yazmak yerine harici bir tabloya referans vererek yer tasarrufu sağlayan bir yöntem. v1'in dayandığı varsayım, 4.096 baytlık limit içinde adres listesinin çoğu durumda doğrudan taşınabileceği yönünde. Ancak ALT'ye yoğun şekilde bağımlı iş yüklerinde limit artışının etkisi sınırlı kalabilir.

Bu değişiklik geliştiricilere tek bir atomik işlem içinde daha fazla alan tanıyor. Solana Vakfı, sıfır bilgi kanıtlarının (zero-knowledge proof), büyük çoklu imza (multisig) yapılarının, toplu işlemlerin ve bazı zincir üstü imza yapılarının mevcut 1.232 baytlık limitte tek işleme sığdırılmasının zor olduğunu belirtti. Atomik işlem, birden fazla adımın birlikte başarılı olduğu ya da birlikte başarısız olduğu bir yapı.

Karmaşık DeFi işlemlerinde ya da kurumsal çoklu imza süreçlerinde işlemi birden çok parçaya bölme zorunluluğu azalabilir. TokenPost'un önceki haberinde aktarıldığı üzere, Solana'da haftalık işlem sayısındaki artışın ücret geliri, geliştirici aktivitesi ve token talebiyle ilişkisi ayrı göstergelerle takip edilmesi gereken bir konu; bu nedenle ağ işlem verileri altyapı değişiklikleriyle birlikte değerlendirilmeli.

Yine de v1, tüm darboğazları ortadan kaldırmıyor. Solana'nın resmi açıklamasına göre v1, doğrulayıcılara (validator) ve istemci ekiplerine ücret ve kaynak taleplerini daha erken okuma imkanı sunuyor. Buna karşılık uygulama geliştiricileri açısından 64 hesap limiti hâlâ bir kısıt olarak kalabiliyor.

Geliştirici tartışmalarında hem olumlu hem temkinli görüşler var. GitHub'daki tartışmada, karmaşık takaslar (swap), tek tıkla DeFi işlemleri ve atomik tasfiye (liquidation) işlemleri için daha büyük işlem boyutunun faydalı olacağı görüşü dile getirildi. Buna karşılık ağ performansı, paket bölünmesi, doğrulayıcı bant genişliği ve ücret tasarımının daha kritik olduğunu vurgulayan yorumlar da yapıldı.

Yerel test ortamında deneme imkanı şimdiden açık. Solana örnek deposu, solana-test-validator üzerinde enable_tx_v1 özellik kapısının zaten etkin olduğunu belirtiyor. Buna karşılık çalışma zamanı (runtime) kodu, özellik kapısı kapalıyken v1 işlemlerini UnsupportedVersion hatasıyla reddedecek şekilde tasarlanmış; bu nedenle her ağ kümesinde (cluster) etkinleştirme durumunun ayrıca kontrol edilmesi gerekiyor.

Crypto Briefing, v1 işlemlerinin önümüzdeki haftalar içinde test ağına (testnet) alınabileceğini aktardı. Ancak Solana'nın resmi belgelerindeki durum hâlâ etkinleştirme bekliyor şeklinde. Ana ağa (mainnet) ne zaman uygulanacağı, resmi özellik etkinleştirme durumu üzerinden teyit edilmesi gereken bir konu.

Bu güncelleme bir fiyat beklentisinden çok geliştirici altyapısında bir değişiklik. Cüzdanların, RPC sağlayıcılarının, indeksleyicilerin ve geliştirme araçlarının v1 işlem ayrıştırma (parsing) ve transactionConfig desteğini gözden geçirmesi gerekiyor. Mevcut v0 ve eski işlemler çalışmaya devam edecek; ancak 4.096 baytlık işlemleri kullanmak isteyen servislerin yeni formatı desteklemesi ön koşul olacak.