XRP Ledger(XRPL) 3.3.0'da değişiklik önerisini yüzde 80 destek ve 2 hafta belirleyecek

XRP Ledger (XRPL) sunucu yazılımı 'xrpld' 3.3.0 sürümü yayınlandı ve değişiklik önerilerinin (amendment) devreye girip girmeyeceğini gösteren asıl gösterge güvenilir doğrulayıcı listesinin (UNL) güncelleme oranı oldu. Ağdaki tüm düğümlerin yeni sürüme geçiş oranıyla, değişiklik oylamasına katılan güvenilir doğrulayıcıların destek oranı aslında birbirinden farklı iki veri.

XRP Ledger, 6'sında (yerel saatle) xrpld 3.3.0'ı duyurdu. Yeni sürümde BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor ve fixCleanup3_3_0 değişiklik önerileri yer aldı.

BatchV1_1, birden fazla işlemi tek seferde gruplandırıp işleyen bir toplu işlem (batch transaction) düzenlemesi. ConfidentialTransfer, transfer bilgilerini koruyan bir işlev olarak öne çıkıyor. DynamicMPT ise çok amaçlı token (MPT) kullanım alanını genişleten bir değişiklik önerisi.

Uzun süredir beklemede olan Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve ve fixUniversalNumber ise bu sürümle birlikte protokolün kalıcı bileşenlerine dönüştü. TokenPost, 3.3.0'ın gizli transfer dahil birçok değişiklik önerisini içerdiğini daha önce duyurmuştu.

Sunucu yazılımına bir değişiklik önerisinin kodunun eklenmiş olması, ilgili özelliğin ağda hemen devreye girdiği anlamına gelmiyor. Yazılım dağıtımı ile protokol değişikliğinin etkinleştirilmesi ayrı süreçler olarak ilerliyor.

XRPL'nin resmi dokümantasyonuna göre bir değişiklik önerisinin etkinleşmesi için güvenilir doğrulayıcıların yüzde 80'ini aşan desteğin 2 hafta boyunca kesintisiz sürmesi gerekiyor. Destek oranı bu eşiğin altına düşerse süre sıfırdan başlıyor; bu yüzden yalnızca kurulu düğüm sayısına bakarak etkinleşme zamanını tahmin etmek güç.

UNL, her sunucunun konsensüs sürecinde güvendiği doğrulayıcılar kümesi. Sıradan düğümler de defter verisini saklayabiliyor ya da işlemleri iletebiliyor, ama değişiklik önerisinin etkinleşmesi güvenilir doğrulayıcıların oylama durumuna göre belirleniyor.

RippleX yazılım mühendisi Mayukha Vadari (Mayukha Vadari), X'teki bir tartışmada yüzde 80 UNL güncellemesinin asıl operasyonel eşik olduğunu vurguladı. Buna karşılık başka bir katılımcı, ağ genelindeki sürüm dağılımının da göz önünde bulundurulması gerektiğini savundu; bu tartışmayı U.Today aktardı.

İki gösterge farklı tabloları yansıtıyor. Tüm düğümlerin sürüm dağılımı yazılımın ağ genelinde ne kadar yayıldığını gösterirken, UNL bazlı destek oranı değişiklik önerisinin etkinleşme koşuluna ne kadar yaklaştığını ortaya koyuyor.

U.Today'in aktardığı XRPScan verilerine göre 3.3.0 sürümünü kullanan 74, 3.2.1 sürümünü kullanan ise 58 düğüm bulunuyor. Aynı kaynakta bu rakamlardan yola çıkılarak ağın yalnızca yaklaşık yüzde 32'sinin 3.3.0'a geçtiği yorumu da yer aldı.

Ne var ki toplam düğüm sayısıyla güvenilir doğrulayıcı sayısını aynı paydada değerlendirmek güncelleme sürecinin yanlış okunmasına yol açabilir. Değişiklik önerisinin etkinleşmesini değerlendirirken yalnızca düğümün sürümüne değil, o düğümün güvenilir doğrulayıcı kümesinde yer alıp almadığına ve önerilere hangi yönde oy verdiğine de bakmak gerekiyor.

Operatörlerin art arda gelen güncelleme yükü de bu tartışmanın arka planında duruyor. xrpld 3.2.1, 31 Temmuz'da (yerel saatle) doğrulayıcı manifestosu yayılımında ortaya çıkan bir güvenlik sorununu gidermek için yayınlanmıştı ve herhangi bir yeni özellik ya da değişiklik önerisi içermiyordu.

Bunun üzerinden 6 gün geçtikten sonra özellik ve değişiklik önerilerini bir araya getiren 3.3.0 geldi. Sunucu operatörleri güvenlik yamasını uyguladıktan hemen sonra yeniden yeni bir sürüme geçmek zorunda kaldı.

TokenPost, 3.2.1 dağıtımının manifesto akışı (manifest flood) sorununa karşı alınan bir önlem olduğunu daha önce aktarmıştı. 3.2.0'a geçiş sırasında da eski sürümdeki düğüm oranı, değişiklik önerisi uygulama sürecinde operasyonel bir risk olarak gündeme gelmişti.

3.3.0'da yer alan değişiklik önerilerinin etkinleşmesi için güvenilir doğrulayıcıların yüzde 80'ini aşan desteğin 2 hafta boyunca korunması gerekiyor. Bu dağıtımın ardından da her bir değişiklik önerisinin oylama durumu ile UNL bazlı güncelleme oranının ayrı ayrı takip edilmesi gerekecek.