Solana, Çarşamba'da Transaction v1'i aktifleştiriyor
Eski formatlar geçerliliğini korur, ancak indeksleyicilerin ve gezginlerin başarısız okumaları ve sıfır ücretli görüntülemeleri önlemek için güncellenmesi gerekir.
Solana, maksimum işlem boyutunu 1,232 bayttan 4,096 bayta çıkarmak için Çarşamba gününü hedefliyor. Bu değişiklik, atomik olarak onchain'de neyin sığabileceğini genişletiyor, ancak aynı zamanda veri okuma altyapısının güncellenmesini zorunlu kılıyor ya da başarısız talepler ve yanıltıcı öncelik ücreti gösterimleri riskiyle karşı karşıya kalıyor.
Ana Noktalar
- SolanaÇarşamba günü ana ağ aktivasyonunu hedefliyor ve Transaction v1 aracılığıyla maksimum işlem boyutunu 1,232 bayttan 4,096 bayta çıkarıyor.
- Eski işlem formatları desteklenmeye devam ediyor, bu nedenle çoğu cüzdan ve uygulama, ek alana ihtiyaç duymadıkça geçiş yapmadan çalışmaya devam edebilir.
- Keşif araçlarını, cüzdanları ve ticaret uygulamalarını destekleyen blok ve işlem okuyucuları, Transaction v1 desteğine ihtiyaç duyar; yeni format ortaya çıktığında fetch istekleri başarısız olabilir.
- v1'de öncelik ücreti meta verileri hareket ediyor, bu da eski araçların bir kullanıcının bir öncelik ücreti ödediği durumlarda bile sıfır öncelik ücreti gösterebileceği anlamına geliyor.
İşlem v1 Canlı Yayına Geçti: 1,232 Bayttan 4,096 Bayta
Solana, maksimum işlem boyutunu 1,232 bayttan 4,096 bayta çıkarmak için Çarşamba gününü hedefliyor ve bunu yeni bir Transaction v1 formatı aracılığıyla gerçekleştirecek. Bu, tek bir işlemde ne kadar talimat ve veri yükünün sığabileceğinde 3 katından fazla bir artış anlamına geliyor.
Pratik kazanç atomikliktir. Daha önce birden fazla işlem arasında bölünmesi gereken iş akışları, giderek daha fazla bir işlemde gerçekleştirilebilmektedir; bu da karmaşık bir eylemi tamamlamak için gereken ayrı imza, yayın ve hata noktası sayısını azaltmaktadır.
Yeni format, Solana'nın test ve geliştirme ağlarında zaten çalışıyor. Paket, Çarşamba için kesin bir etkinleştirme zamanı belirtmiyor ve hedefin ötesinde nihai ana ağ etkinleştirmesini de doğrulamıyor.
Değişiklik, Jacob Creech ve Andrew Fitzgerald tarafından ortaklaşa yazılan iki Solana İyileştirme Belgesinde, SIMD-0296 ve SIMD-0385'te tanımlanmıştır.
İşlem ve Ücret Optiği: Daha Büyük İşlemler, Farklı Öncelik Ücret Meta Verileri
Büyük işlemler, talimat yoğunluğu yüksek Solana uygulamaları için tasarım alanını genişletir. Artık tek bir işlemde daha rahat bir şekilde yer alabilen örnekler arasında büyük kriptografik kanıtlar, birçok onay gerektiren ödemeler (büyükçok imzalıişlemler) ve bazı gizli transferler.
Tüccarlar için, hemen etkisi daha az çoklu işlem dizisi gerektiren karmaşık eylemlerdir. Bu, zincir yoğun olduğunda ve kısmi yürütme maliyetli olduğunda en önemlidir. Bir işlem ya başarılı olur ya da olmaz. Aynı niyeti birkaç işlem arasında bölmek, bir ayağın başarısız olma, geç gerçekleşme veya farklı bir ücret rejiminde temizlenme olasılığını artırır.
Ücret durumu daha karmaşık. Güncelleme, yeni bir byte başına ücret getirmiyor, ancak daha büyük işlemler daha fazla ağ bant genişliği tüketiyor. Geliştiriciler, kullanıcıların daha büyük işlemler alan için rekabet ederken daha yüksek öncelikli ücretler sunmaları gerekebileceğini öngörüyor.
Öncelik ücretleri, kullanıcıların bir işlemin daha hızlı işlenmesi için yapabilecekleri isteğe bağlı ek ödemelerdir. Sorun şu ki, Transaction v1 öncelik ücreti bilgilerini başka bir yerde saklar, bu da eski düzeni varsayan herhangi bir araç için yeni bir hata modu oluşturur.
İndeksleyici ve Keşif Riski: Başarısız Okumalar ve 'Sıfır Ücret' Yanlış Raporları
En acil yükseltme baskısı cüzdanlar üzerinde değil. Mevcut işlem formatları desteklenmeye devam edecek ve cüzdanlar ile uygulamalar, ek alana ihtiyaç duymadıkça v1'e geçmek zorunda değiller.
Baskı, Solana'yı okuyan altyapı üzerindedir. Blokları ve işlemleri getiren hizmetlerin, İşlem v1'i tanıyacak şekilde güncellenmesi gerekmektedir. Aksi takdirde, yeni formatla karşılaştıklarında istekler başarısız olabilir.
Bu başarısızlık sadece bir operasyon sıkıntısı değildir. Cüzdanlar, gezginler ve ticaret uygulamaları genellikle zincir üzerinde ne olduğunu göstermek için bu hizmetlere güvenir. Eğer arka uç v1'i ayrıştıramazsa, kullanıcıya yansıyan belirti, kaybolan işlemler, bozuk geçmiş görüntüleri veya farklı indeksleyicilerden veri çeken uygulamalar arasında tutarsız yürütme raporlaması olabilir.
Ücret optikleri daha keskin bir kenardır. Çünkü v1, öncelik ücreti verilerini farklı bir konumda sakladığı için, güncel olmayan yazılımlar, bir ücret ödenmiş olsa bile sıfır öncelik ücreti gösterebilir. Yoğunluk sırasında, bu tür bir yanlış raporlama, yürütmeyi olduğundan daha ucuz göstererek veya gezginler ve terminaller arasında çelişkili 'gerçekler' oluşturarak trader UX'ini bozabilir.
Tüccarlar ve Geliştiriciler için Aktivasyon Sonrası Kontrol Listesi
İlk kontrol noktası, kesin Çarşamba aktivasyon zamanının onaylanması ve geçişten hemen sonra herhangi bir dağıtım sorununu ortaya çıkarıp çıkarmadığıdır. Paket, kesin bir zaman damgası içermemektedir.
İkinci kontrol noktası altyapı durumudur. Büyük indeksleyiciler, gezginler ve cüzdan arka uçları, doğru öncelik ücreti ayrıştırması da dahil olmak üzere İşlem v1 desteğini onaylamalıdır. Karışık hazır olma durumu, bir format değişikliği geldiğinde temel durumdur ve burada trader'lar araçlar arasında tutarsız ücret görüntüleri görür.
Üçüncü kontrol noktası, sahadaki hata telemetrisidir. Başarısız blok veya işlem alma talepleri, kaybolan geçmiş veya gezginler ve ticaret uygulamaları arasında gösterilen öncelik ücretlerinde ani tutarsızlıklar hakkında raporlar, bazı arka uçların hala eski varsayımlarla zinciri okuduğuna dair en temiz sinyal olacaktır.
Son kontrol noktası davranışsal, mekanik değildir. Daha büyük işlemler alan için rekabet etmeye başladığında, piyasa yoğunluk sırasında 'daha yüksek öncelik ücretleri gerektirebilir' ifadesinin pratikte ne anlama geldiğini keşfedecektir. Paket, yalnızca yönsel bir beklenti sunar, sayısal bir tahmin sağlamaz.
Benim Okumam: Bu, Bir Üretkenlik Yükseltmesi Kadar Bir UX ve Güvenilirlik Yükseltmesidir.
Önemli olan eşik, cüzdanların "v1'i destekleyip desteklemediği" değil. Eski formatlar geçerliliğini koruyor, bu nedenle çoğu ön yüz iyi görünecek. Asıl test, tüccarların örtük olarak güvendiği indeksleyicilerin ve keşif araçlarının v1'i tutarlı bir şekilde çözümleyip çözümleyemeyeceğidir, çünkü başarısız okumalar ve sıfır ücretli yanlış raporlar, format güncellemelerinin yürütme karmaşasına dönüşmesinin yoludur.
Eğer öncelik ücreti gösterimleri aktivasyondan sonra büyük araçlar arasında tutarlı kalırsa, kurulum anlatı odaklı olmaktan çok yapısal görünmeye başlar: daha karmaşık işlemler, tüccarın maliyet ve onay görüşünü bozmadan atomik olarak gerçekleştirilebilir. Eğer ücret optikleri parçalanırsa, güncelleme ekstra kapasite gibi değil, kötü verilerle ödenen geçici bir güvenilirlik vergisi gibi hissedilecektir.
