XRP Ledger'ın Kredi Düzeltmesi Fazla Birimi Kesmek İçin Yüzde 80 Doğrulayıcı Oyu Bekliyor

Geri Ödeme Düzeltmesi 8698 Numaralı Talepte Ayrıntılandı

XRP Ledger'ın yerleşik kredi protokolünü kullanan kasa operatörleri ve borçlular, yeni yayımlanan bir kod değişikliğinin hedef kitlesini oluşturuyor. Değişiklik, kredi geri ödemelerinin yuvarlanma biçimini temize çıkarıyor ve XRP Ledger'ı çalıştıran referans sunucu yazılımı rippled'a açılan 8698 numaralı değişiklik talebinde ayrıntılarıyla tanımlanıyor. XRP'nin arkasındaki birinci katman ağın yazılımına yönelik bu düzeltme, yürürlüğe girdiğinde her ödeme sonrasındaki bakiye, borcun ömrü boyunca küçük miktarlarda sapmak yerine kredi çizelgesiyle tam olarak eşleşecek.

Teklifin tamamını iki muhasebe kavramı taşıyor. TotalValueOutstanding, borçlunun herhangi bir anda hâlâ ne kadar borcu kaldığını izleyen sürekli ölçüt; PeriodicPayment ise vadesinde ödenen her taksidin silmesi beklenen çizelgeli tutar. LendingProtocolV1_2 kapsamında vadesinde ödenen her LoanPay, TotalValueOutstanding'i çizelgelenmiş değere bir ödeme daha az sayıda ve yuvarlanmış PeriodicPayment'ın üzerine hiçbir zaman çıkmadan indirecek. Borçlu fazladan ödeme yaptığında ise TotalValueOutstanding, yeniden yapılandırılan PeriodicPayment için çizelgelenmiş tutara sıfırlanıyor. Küçük yuvarlama farkları önemsiz gibi dursa da kredileri programatik olarak takas eden bir defterde aritmetiğin belirleyici olması zorunlu: her düğüm, aynı işlemden sonra aynı bakiyeye varmak durumunda.

Değişiklik, defterin yerli kredi alanına yönelik hamlesini genişletiyor; bu alan genellikle DeFi başlığı altında sınıflandırılıyor ve Ripple'ın RLUSD stablecoin'i ile aynı zincir üzerinde duruyor; RLUSD'nin yarısı XRP Ledger üzerinde ihraç ediliyor. Kod düzeyinde bir düzeltme olduğu için bugünkü XRP fiyatına doğrudan etkisi bulunmuyor; gerçek etkisi, ihraççıların kredi koşullarını belirlediği ve borçluların çizelgeyi izlediği XRP ekosisteminin kredi altyapısına iniyor.

Yuvarlama Sapması Ödemeler Arasında Nasıl Birikiyor

Mevcut uygulama her ödemenin değer bileşenini kendi başına fiyatlandırıyor. Bunun sonucunda yuvarlama hataları kredinin ömrü boyunca birikıyor: son taksit, yuvarlanmış PeriodicPayment'dan bir birim fazla talep edebiliyor ve ardışık ödemelerin değer bileşenleri sabit kalması gereken yerde yukarı aşağı salınabiliyor. Talebin ilk taahhüdü, çizelgelenmiş değer hesaplamasını computeLoanProperties içinden çıkarıp ayrı bir scheduledValue fonksiyonuna taşıyor; bu başlı başına bir davranış değişikliği yaratmıyor. Tek bir ortak rutinden her iki tarafın geçirilmesi, kredi oluşturan işlem olan LoanSet ile ödemeyi kaydeden LoanPay'ın aynı figürü aynı biçimde yuvarlamasını sağlıyor.

Hiçbir APY olmadan yazılan kredilerde ayrıca anapara kısmına bir taban değeri gerekiyor, çünkü bu kredilerde değer en yakına yuvarlanırken anapara yukarı yuvarlanıyor. Düzeltmenin çekirdeğini geliştiricilerin teleskopik adını verdiği yöntem oluşturuyor: her vadesinde ödemeye denk gelen değerin bileşenini PeriodicPayment'ın tabanına ya da tavanına ayarlıyor ve hiçbir zaman bir birimin altına inmiyor. Son taksit böylece tam olarak yuvarlanmış PeriodicPayment'a oturuyor; çizelgenin sonunda eskiden yüzeye çıkan fark kapanıyor ve taksitler arasındaki salınım deseni de ortadan kalkıyor. Kasalar, defterin havuzlanmış kredi yapıları; testler Legacy, CashBasis ve FixedPrecision kasalarını, değişiklik aktifken ve pasifken ayrı ayrı koşarak gözden geçirenlerin etkisini izole edebilmesini sağladı.

Yüzde 80 Doğrulayıcı Oyu Nerede Duruyor

Bizim okumamız, değişikliğin günlük borçludan çok ihraççılara ve kasa araçlarına yöneldiğidir. Kullanıcılar ve yatırımcılar bugün bu değişikliği çok az ya da hiç hissetmiyor: son ödemedeki fazla birim uygulamada küçük bir fark yaratıyor ve çizelgesinin bir birim üzerinde kapanmış eski krediler bu birimi korumaya devam ediyor, dolayısıyla borçlu önce fazla ödeme yapmadıkça son taksitin PeriodicPayment artı tek bir birim olması gerekiyor. Küçük fazla ödemeler çoğunlukla yok sayılıyor, işlem yine başarılı oluyor ve ekstra XRP alınmıyor. PayFi mutabakatına da uzanan defterin kredi altyapısı, mevcut kredilere göç yükü bindirmeden daha temiz bir aritmetik kazanıyor.

Hareket etmeyen taraf ise doğrulayıcılar. Etkinleştirme, birbirini izleyen iki hafta boyunca doğrulayıcıların yüzde 80'inin mutabakatını gerektiriyor ve LendingProtocolV1_2 için henüz kamuya açık bir oylama duyurulmuş değil; etkinleştirme tarihi de belirsizliğini koruyor. Açık k honorable soru değerlendirme değil, zamanlama: kodu ve testleri mevcut, eksik kalan parça oylamanın kendisi.