Solana işlem limitini 4.096 bayta çıkarıyor, ancak v1 işlemlerini okumak mevcut uygulamaları bozabilir

UDP'den miras kalan bir üst sınır

Solana'nın 1.232 baytlık işlem limiti, zincirin kullanıma açıldığı günden beri değişmedi ve dev.to üzerindeki teknik bir yazıya göre bu hiçbir zaman bir tasarım hedefi değildi — tamamen altyapı gereğiydi. İşlemler başlangıçta tek UDP datagramları olarak taşındığından, 48 baytlık başlıklar düştükten sonra minimum IPv6 MTU'su olan 1.280 bayta sığmak zorundaydılar. Solana'nın ağı artık QUIC üzerinde çalışıyor ve QUIC açık bir stream boyutu sınırı dayatmadığı için bu üst sınırın fiziksel gerekçesi ortadan kalktı. İki proposal bu sınırı kaldırıyor: SIMD-0296 tavanı 4.096 bayta yükseltiyor ve SIMD-0385 bunu taşıyan v1 işlem formatını tanımlıyor.

Yazının yazarı, her iddianın proposal metinleriyle karşılaştırıldığını ve yerel bir Agave 4.2 validator'ünde test edildiğini belirtiyor. 4.096 rakamı, gerçek bundle trafiğinin ölçülmesinden — Jito bundle'larının kabaca yarısı 2.048 bayta, %65'i 6.144 bayta sığıyor — ve validator'lerin zaten yönettiği 4 KiB bellek sayfalarıyla uyumlu olma hedefinden geldi. Eski zarfa hiç sığmayan iş yükleri arasında Confidential Transfers için zero-knowledge proof'lar, Winternitz tek kullanımlık imzalar, iç içe kurumsal multisig'ler ve BLS gibi precompile edilmemiş imza şemaları var; ekipler bu limite daha önce protokol düzeyinde atomik olmayan Jito bundle'larıyla çözüm buluyordu. SIMD-0296 bayt başına ücret eklemiyor — beklenti, büyük işlemlerin priority fee'ler üzerinden fiyatlanacağı yönünde.

Esnetilmiş bir v0 değil, yeni bir wire formatı

SIMD-0385 eski zarfı büyütmüyor; onu yeniden tasarlıyor. Bir v1 işlem, 129 (0x81) sürüm baytıyla kendini belli ediyor ve yapısal olarak ayrışıyor. Kaynak istekleri — compute unit limiti, loaded-accounts veri boyutu, heap boyutu ve priority fee — ComputeBudget instruction'larından çıkıp mesaj içinde sabit konumlu bir transactionConfig bitmask'ine taşınıyor. Address lookup table'lar tamamen kaldırılıyor: en fazla 64 tam 32 baytlık account satır içine gömülüyor, tekrarlar sanitizasyon sırasında reddediliyor. Instruction başlıkları sabit genişlikli hale gelip değişken uzunluktaki payload'larından ayrılıyor ve imzalar uzunluk öneki olmadan sona taşınıyor. Bir v1 işlem içindeki ComputeBudget instruction'ları hâlâ çalıştırılıyor ama compute unit yakıp hiçbir şey yapılandırmayan no-op'lar olarak.

v1'deki sert sınırlar: 4.096 bayt, 64 account, 64 instruction, 12 imza ve instruction başına 255 account. İki birim değişikliğine dikkat etmek gerekiyor. Priority fee'ler v0'daki compute unit başına micro-lamporttan v1'de lamport cinsinden mutlak toplama geçiyor; dolayısıyla sürümler arasında ücret ortalaması alan veya karşılaştıran her pipeline önce normalizasyon yapmalı. Ayrıca v1 kaynak varsayılanları sıfır: legacy ve v0, instruction başına örtük olarak 200.000 compute unit ve 64 MiB loaded-account verisi verirken, açıkça compute unit limiti ve loaded-accounts boyutu istemeyen bir v1 işlem, çalıştırma aşamasında — ve chain'e girmek için ödeme yaptıktan sonra — başarısız oluyor. @solana/kit kütüphanesi 8.0.0 sürümünden itibaren her limiti açık kılan setter'lar sunuyor.

Lookup table'ların kaldırılması en çok DeFi routing'i vuruyor. Mevcut v0 işlemlerinin yaklaşık %62'si en az bir lookup table'a referans veriyor; satır içi adreslere dönüştürüldüğünde yarısı 420 bayttan az, %90'ı ise 1.400 bayttan az büyüyor — yeni zarfa rahatça sığıyor. Ancak yoğun çok tablolu route'lar 1.500+ bayt büyüyor ve 64 account sınırı kalkmıyor, dolayısıyla geniş kapsamlı çok havuzlu aggregator stratejileri bayt değil account sınırına takılmaya devam ediyor. Taslak bir proposal olan SIMD-0596 bu sınırı 96'ya çıkarıyor.

Okumanın bozulduğu üç yol

Göndermek opt-in: legacy ve v0 süresiz olarak geçerli kalıyor ve v1'e hiç dokunmayan programlar için hiçbir şey değişmiyor. Okumak bambaşka bir hikaye ve yazı sonuçları üç başarısızlık moduna grupluyor.

İlki gürültülü olan. Feature gate aktifleştiğinde getTransaction, getBlock ve blockSubscribe, çağıran maxSupportedTransactionVersion: 1 parametresini — string "1" değil, tam sayıyı — geçmedikçe v1 olan her şey için JSON-RPC hatası -32015 döndürüyor. Bir bloktaki tek bir v1 işlem, yalnızca o işlemi değil, getBlock yanıtının tamamını düşürüyor. Yazı bunu 2022 v0 geçişinin tekrarı olarak nitelendiriyor ve parametrenin geriye dönük uyumlu olduğunu, aktifleştirmeden önce yayına alınabileceğini belirtiyor. v1 yanıtları mesaj içinde bir transactionConfig nesnesi taşıyor; v0 ve legacy yanıtları değişmiyor.

İkincisi sessiz. Indexer'lar genellikle priority fee'leri ve compute limitlerini ComputeBudget instruction'larını tarayarak çıkarır. Bu tarama bir v1 işlemde hiçbir şey bulamıyor ve hata vermeden sıfır döndürüyor — pipeline'lar çalışmaya devam ederken yanlış fee ve compute-unit verisi yazıyor.

Üçüncüsü stream'lerde gizli. Geyser ve gRPC stream'lerinde hiçbir sürüm kapısı yok, dolayısıyla v1 işlemler aynen geliyor. 15.1.1 öncesi Yellowstone build'leri v1'i wire üzerinde sessizce v0'a düşürüyor ve yellowstone-grpc-proto 12.6.0 öncesi üretilmiş protobuf stub'larında decode edecek bir Message.config alanı yok. Çözüm: stub'ları yeniden üretmek ve sürümü yapısal olarak tespit etmek — v1 mesajı da versioned sayıldığından, versioned bayrağından önce mesajda config alanının varlığını kontrol edin.

Neden önemli

Bu, hiç işlem göndermeyen yazılımlar için bile breaking bir değişiklik. Block explorer'lar, indexer'lar, fee tahmincileri ve izleme araçları yalnızca chain verisi okur ve her v1 işlemi RPC çağrılarını çökertebilir ya da daha kötüsü, veri kümelerini görünmez şekilde bozabilir. Tek bir yeni formatlı işlem tüm blok yanıtını düşürebilir ve sessizce yanlış fee verisi bir hatadan daha zor yakalanır. Pratik yol şimdi maxSupportedTransactionVersion: 1'i yayına almak, indexer'lara instruction taramasına geri dönüşle birlikte transactionConfig okumayı öğretmek, sürümler arasında fee birimlerini normalize etmek ve feature gate aktifleşmeden önce gRPC stub'larını yeniden üretmek. Aktifleştiğinde ise Solana verisinin salt-okur bir tüketicisi olmak artık varsayılan olarak güvenli değil.