Stellar Development Foundation, Bell Protocol 30 Oylaması İçin Operatör Yazılım Gereksinimlerini Belirledi

Etkinleştirme Öncesi Üç İş Yükü

Stellar (XLM) Development Foundation, Bell yükseltme rehberini güncelleyerek ağın Bell Protocol 30 yükseltmesi oylamaya gitmeden önce hangi yazılımları çalıştırması gerektiğini operatör bazında netleştirdi. Rehberin bu güncellemesi borsa, cüzdan ve defter verisini doğrudan okuyan hizmetlerin ayrı birer iş yükü üstlenmesini zorunlu kılıyor. 23 Ekim Cuma günü yenilenen belge, altyapı ve geliştirici araçlarını desteklenen sürümlerle eşleştiriyor ve her operatörü kendi entegrasyon ortamını test etmeye çağırıyor. Vakıf, bu test adımını doğrulayıcı oyuyla (validator voting) bilinçli biçimde ayrı tutuyor: testnet oylaması 4 Kasım Çarşamba, ana ağ oylaması ise 24 Kasım Salı günü yapılacak. Her iki tarihin de değişebileceği ve yükseltmenin uygulanmasının doğrulayıcı onayına bağlı olduğu notu belgede açıkça yer alıyor. Güncellemenin kapattığı pratik boşluk şurada: doğrulayıcı onayı protocol 30'un etkinleşip etkinleşmeyeceğine karar verir, ama bir borsanın ya da cüzdanın günlük hayatta çalıştırdığı yazılım kullanıcıların değişikliği hiç hissetmeden geçip geçmeyeceğine karar verir. Rehberin kendisi ağda hiçbir şeyi değiştirmiyor; öneriyi hizmet bazında bir yazılım ve veri biçimi kontrol listesine çeviriyor.

Değişikliğin muhatabı olan taraflar için rehber üç sorumluluk çizgisi çiziyor. Sıcak cüzdan altyapısı işleten borsalar ve saklama hizmetleri, çekimleri yeni W biçimli sözleşme adreslerine gönderebildiklerini doğrulamak zorunda. Cüzdanlar ve varlık ihraççıları, adres girişini kabul eden ve aktarım kayıtlarını işleyen özellikleri test edecek. Defter verisini doğrudan okuyan hizmetlerin, yani indeksleyicilerin, blok gezginlerinin ve analitik araçların yükü ise daha ayrı bir noktada: protokol 30, defter başlıklarına yeni bir değer biçimi sokuyor ve mevcut XDR tanımlarına dayanan bir çözücü, etkinleştirme sonrasında defter verisini okuyamayabilir. XDR, Stellar ağının işlemleri ve defter verisini temsil etmek için kullandığı biçim; vakıf bu yüzden etkilenen ekiplerden tanımlarını oylamadan sonra değil, oylamadan önce yenilemesini istiyor.

W Adresleri ve XDR Çözücüleri

Gözle görülür değişiklik, 'W' ile başlayan sözleşme adresi biçimi. Her akıllı sözleşme adresi 64 bitlik bir tanımlayıcı taşıyor; böylece tek bir sözleşme, çok sayıda farklı müşteriden gelen yatırımları birbirinden ayırabiliyor. SDK güncellemeleri yeni adresleri okunur kılıyor, ancak bir cüzdan adresini denetleyen, görüntüleyen ya da saklayan uygulama kodunun ve havale hedefini okuyan kodun W biçimini kabul etmesi gerekiyor. Donanım cüzdanı ekranları da dahil olmak üzere cüzdan yazılımları bu gruba giriyor. Öte yandan mevcut akıllı sözleşmeler yükseltme sonrasında çalışmaya devam ediyor ve yeni sözleşme özelliklerini benimsemek her geliştiricicinin tercihinde kalıyor.

Vakfın zorunlu kıldığı sürümler şöyle: stellar-core v30.0.0; Horizon, RPC ve Galexie için v30.0.0; JavaScript SDK için v17.3.0 ve Go SDK için v0.8.0. 16.x bakım sürümü olan v16.4.0 yeni defteri okuyabiliyor ama W adreslerini işleyemiyor; dolayısıyla W desteğine ihtiyaç duyan her hizmet v17.3.0 üzerinde olmak zorunda. Horizon ve RPC ucu defteri uygulamalara açtığı için v30.0.0 hizalaması, ham XDR çözümlemek yerine bu arayüzler üzerinden zinciri sorgulayan servisler açısından belirleyici. Soroban Rust SDK 30.0.0-rc.1 de listede yer alıyor; ana ağ oylamasından önce kararlı bir sürüm bekleniyor ve rehber yenilendiğinde protokol 30 için Stellar (XLM) CLI derlemesi henüz beklemekteydi. Adreslemenin ötesinde Bell, akıllı sözleşmeler için ML-DSA imza doğrulaması ve milisaniye düzeyinde defter zaman kaydı taşıyor. Ağ işlem imzaları Ed25519 üzerinde kalıyor ve zaman damgası değişikliği tek başına defter oluşturma aralığını kısaltmıyor. İki hazırlık birbirinden bağımsız: aktarım testini geçmiş olmak, çözücünün yeni defter başlıklarına dayanıp dayanamayacağı hakkında hiçbir şey söylemiyor.

Sürüm notlarıyla karşılaştırıldığında protocol 30 ekleyici nitelikte: mevcut sözleşmeler etkinleştirmeden sorunsuz geçiyor ve yeni özellikleri almak geliştiricinin kararı. Gerçek risk zincir dışında, protokol değişikliğinin hiç dokunmadığı kodda yatıyor. Bu yüzden 24 Kasım oylamasına kadar geçmeyen bir çözücü ya da adres doğrulayıcı izlenecek hata modu; doğrulayıcı sayısı değil. Tek bir sözleşmenin çok sayıda müşteriden gelen yatırımları ayırt etmesini sağlayan W adres şeması, geleneksel finans (TradFi) mutabakatını Stellar (XLM) taşıyan saklama ve borsa koridoruna işaret ediyor. Bu, ağdaki ilk kurumsal repo mutabakatı ile 2027'ye planlanan ve DTCC'nin 30 trilyon dolarlık tokenizasyon hizmetini kapsayan koridorun aynısı. Bekleyen Stellar CLI derlemesi ve yayımlanmamış kararlı Soroban SDK, operatörlerin önünde ana ağ oylamasıyla kapanan bir pencere bırakıyor; etkinleştirmeden sonra göçe başlayan hizmetler, araçlarının hiç çözümlemek üzere tasarlanmadığı bir defteri okumakla karşılaşacak.