CryptoSlate
Solana'nın v1 işlem formatı, işlem başına payload tavanını 1.232 bayttan 4.096 bayta çıkarıyor; bu, yaklaşık 3,3 katlık bir sıçrama ve testnet ile devnet'te (epoch 1140) zaten çalışıyor. Ana ağ aktivasyonu Solana'nın canlı yükseltme sayfasında hâlâ beklemede, 28 Ağustos tarihli değişiklik günlüğünde v1 işlemlerinin "yakında geleceği" belirtiliyor. Bu pencere, çevreleyici altyapı için iki çok farklı uyumluluk tuzağına doğru son koşu niteliğinde: yükseltilmemiş RPC istemcileri bir v1 işlemiyle karşılaştığında doğrudan donabilirken, indeksleyiciler, relayer'lar ve ücret sponsorları çalışmaya devam edebilir ve yanlış kaynak limitlerini sessizce bildirebilir.
Neden önemli
Mançetelik payload artışı yükseltmenin satış noktası, ancak hata modları çoğu kullanıcının hiç görmediği tesisat katmanında. maxSupportedTransactionVersion: 1 parametresini geçemeyen RPC istemcileri, v1 getTransaction isteklerinde -32015 hatasını alır, bir blokta v1 işlemi yer aldığında getBlock'un tamamen başarısız olduğunu görür ve blockSubscribe'un block: null yayımlayıp ilk etkilenen slotta ilerlemeyi durdurduğunu izler. Daha sessiz olan risk ComputeBudget işleyişinde. V1, compute-unit limitlerini, yüklenmiş hesap verisi limitlerini ve öncelik ücretlerini bir transactionConfig nesnesine taşır; dolayısıyla hâlâ ComputeBudget talimatlarını tarayan her indeksleyici hata vermeden sıfır bütçe bildirir ve bu talimatları okuyarak ücret limiti uygulayan her relayer, onların no-op olarak yürütüldüğünü görerek uyguladığını sandığı bağlayıcı limiti sıyırır. Geyser ve gRPC tüketicileri, protobuf'taki versioned bayrağının hem v0 hem de v1 için true olması nedeniyle benzer bir sürüm etiketi tuzağıyla karşı karşıya; bu da eski stub'ların boş bir bütçeyi varmış gibi sürdürmesine olanak tanıyor.
Piyasa etkisi
Solana bunu bir konsensüs kusuru yerine uygulama kontrolü arızası olarak çerçeveliyor, dolayısıyla fonlar otomatik olarak risk altında değil. Ancak patlama yarıçapı, ComputeBudget'ı inceleyen her paymaster, gezgin, saklama yığını ve zincir üstü programı kapsıyor; çünkü mevcut hiçbir sysvar veya syscall v1 mesaj yapılandırmasını gün yüzüne çıkarmıyor.
Sıkça sorulan sorular
-
Solana'nın v1 işlem formatı nedir?
Solana'nın işlem başına payload tavanını 1.232 bayttan 4.096 bayta çıkaran, yaklaşık 3,3 katlık bir artış sağlayan yükseltilmiş işlem formatıdır. Eski ve v0 işlemleri mevcut limitlerini ve davranışlarını korur, dolayısıyla bu formatlarda kalan uygulamaların geçiş yapması gerekmez.
-
v1 donma hatası RPC istemcilerini nasıl etkiliyor?
maxSupportedTransactionVersion: 1 parametresini geçmeyen RPC istemcileri, v1 getTransaction isteklerinde -32015 hatasını alır, bir blokta v1 işlemi yer aldığında getBlock tamamen kırılır ve blockSubscribe'un block: null yayımlayıp ilk etkilenen slotta donduğu görülür.
-
v1 ücret limiti kontrolleri neden sessizce kırılıyor?
V1, compute-unit limitlerini, yüklenmiş hesap verisi limitlerini ve öncelik ücretlerini bir transactionConfig nesnesine taşır. ComputeBudget talimatlarını tarayarak ücret limiti uygulayan relayer'lar ve paymaster'lar, bu talimatların v1'de no-op olarak yürütüldüğünü görür; böylece limit herhangi bir hata vermeden…
-
Solana v1 yükseltmesinde kullanıcı fonları risk altında mı?
Hayır. Analiz bunu bir konsensüs kusuru yerine uygulama kontrolü arızası olarak çerçeveliyor ve kullanıcı fonları otomatik olarak risk altında değil. Risk, ComputeBudget'ı inceleyen ve v1 canlıya geçmeden önce yükseltilmesi gereken relayer'larda, gezginlerde, saklama yığınlarında ve zincir üstü programlarda…
-
Hangi yazılım sürümleri Solana v1'i doğru şekilde işliyor?
Okuyucu kapasiteli sürümler arasında @solana/kit 8.0.0, @solana/web3.js 3.0.0-rc.3, Rust solana-* 4.2.x, Python solders 0.29.0, solana-go 1.23.0, yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1 ve gRPC client 12.0.0 yer alıyor; seçim yığına göre değişiyor.
Crypto News
CoinTelegraph
TheBlock
WatcherGuru