Analiz: Solana ödül kayıtlarında komisyon oranlarının yer almaması ücret kontrollerini zorlaştırıyor

Solana'nın Agave yazılımı, staking ödemeleri görünür kalabilse de özel tahsilat hesapları etkin olduğunda ödül üst verilerinde komisyon oranlarını göstermiyor. P2P.org, 30 Ekim tarihli bir raporunda, oy ve staking ödül kayıtlarında 8 Eylül'den bu yana komisyon bilgilerinin bulunmadığını söyledi. P2P.org, doğrulayıcıların komisyon almaya devam ettiğini ve ödül tutarlarının örtüştüğünü belirtti. Sorun, tespit edilmiş bir ödeme açığıyla değil, ödemelerin açıklanması için gereken kanıtlarla ilgili. Sağlayıcı staking ve raporlama hizmetlerini pazarladığı için P2P.org'un konuyla ilgili ticari çıkarı bulunuyor.

Agave'nin 12588 numaralı pull request'i 20 Mayıs'ta birleştirildi ve özel tahsilat hesapları etkinleştikten sonra, birikmiş doğrulayıcı komisyonları ve tekil stake ödülleri dahil, bu bilgilerin kayıtlarda yer almadığını belirtiyor. Etkilenen ödül bilgileri kullanıcılara blok sorguları ve abonelikler üzerinden ulaşıyor. Agave'nin hesaplama kodu, oranı ortaya çıkan kayıttan çıkarmadan önce ödül hesabında kullanmaya devam ediyor. Dolayısıyla oranın bulunmaması, komisyonun sıfır olduğu değil, üst verilerin eksik olduğu anlamına geliyor. SIMD-0232, doğrulayıcıların komisyon gelirlerini belirlenmiş tahsilat hesaplarına yönlendirmesine izin verirken enflasyon komisyonunun hesaplanma biçimini değiştirmiyor.

Pull request, birikmiş ödüllerin tahsilat hesabına yönlendirilen geliri bir araya getirebileceğini, dolayısıyla tek bir komisyon oranının toplamı yeterince açıklamayabileceğini belirtiyor. Ancak uygulama, tekil stake ödüllerindeki oranı da kaldırarak tek bir stake hesabının kontrolü için kullanılabilecek kanıtları azaltıyor. Solana'da komisyon değişikliklerinin gecikmeli uygulanması, doğrulama için geçmiş oranları gerekli kılıyor. SIMD-0249 kapsamında E epoch'unda kazanılan ödüllerde normalde E-1 başladığında kaydedilmiş oran kullanılıyor; hesaplama ise E+1 başladığında yapılıyor. Gerekli önceki geçmişin bulunmadığı yeni oluşturulmuş oy hesaplarında daha sonraki hesap durumu kullanılabiliyor. Bu nedenle bir doğrulayıcının en güncel ayarı, geçmişteki bir ödeme için geçerli olan orandan farklı olabilir.

16 Temmuz'daki bir mühendislik tartışmasında, normal hesap okumalarının gösteremediği etkin komisyon ve tahsilat bilgileri önbelleğe alınmış çalışma zamanı durumunda tespit edildi. Geliştiriciler, komisyon gecikmesi kuralının mainnet'te zaten uygulandığını söyledi ve önbelleğe alınmış duruma bağımlılığın ayrı olarak nasıl çözülebileceğini ele aldı. Agave'ye katkıda bulunan ax-x2, 18 Ekim'de, getVoteAccounts ve ayrıştırılmış oy hesabı verilerinin en güncel ayarı gösterdiğini, ancak ödül hesaplamalarında kaydedilmiş bir oranın kullanılabildiğini açıklayan bir RPC talebi sundu. Talep, etkin enflasyon komisyonunu, ilgili epoch'u ve bank slotunu gösteren isteğe bağlı bir yanıt öneriyor. Talep 30 Ekim itibarıyla hâlâ açıktı ve bağlantılı bir uygulama içermiyordu. Talepteki örnek, ekranda düşük, kaydedilmiş durumda ise yüksek bir oran gösteriyor; ancak gözlemlenmiş bir doğrulayıcı vakası belirtmiyor ve fazla komisyon alındığını ortaya koymuyor.

Geçmiş bir komisyonu kontrol etmek için ödül dönemini, stake hesabının doğrulayıcı delegasyonunu ve geçerli geçmiş kural uyarınca seçilen oranı eşleştirmek gerekiyor. Jito'nun Validator History Program'ı, doğrulayıcı başına 512 epoch'a kadar komisyon ve diğer doğrulayıcı geçmişi bilgilerini belgeleyip saklıyor. Jito'nun kopyalama talimatı, oy hesabının komisyonunu epoch ve slot bilgileriyle birlikte kaydediyor; ancak bu gözlem tek başına belirli bir ödeme için gecikmeli olarak geçerli olan oranı kanıtlamıyor. Marinade'in anlık görüntü ayrıştırıcısı, epoch stake anlık görüntülerinden enflasyon komisyonunu çıkarıp değerin hangi döneme ait olduğunu ve yedekleme sayaçlarını yayımlayarak önbelleğe alınmış bilgilere daha doğrudan erişiyor. Marinade, arşiv sınırlarının ve dönem bilgisi içermeyen eski çıktı dosyalarının saklanan oranların yorumlanmasını kısıtladığı uyarısında bulunuyor. Ayrıştırıcı bir yeniden oluşturma tekniği sunuyor; her hesap ve epoch için eksiksiz arşiv bulunduğunu garanti etmiyor.

Trillium'un APY metodolojisi, 1070 numaralı epoch'tan itibaren stake hesabındaki büyümeyi izleyerek enflasyon getirilerini ölçüyor; görüntülenen komisyon yerine uygunluk kontrolleri ve RPC yedekleme yöntemlerini uyguluyor. Trillium daha eski epoch'lar için başka yöntemler kullanıyor. Bu nedenle net kazançlar ölçülebilir durumda kalırken, bu kazançları sağlayan komisyon bağımsız olarak doğrulanamayabilir. Trillium, uygun hesap kanıtının bulunmamasını sıfır değil, bilinmeyen sonuç olarak değerlendiriyor. SOL sahipleri veya staking ürünleri için yararlı bir gelir kaydı; net ödülleri ilgili dönem, doğrulayıcı delegasyonu ve etkin komisyon kanıtlarıyla ilişkilendirirken yeniden oluşturma ya da örnekleme sınırlamalarını da açıklamalı.

Ekim ayındaki bir oy durumu tartışmasında, komisyon oranlarının yürürlüğe girdikleri epoch'larla birlikte saklanması önerildi. Oy durumu önerisi ve açık RPC talebi, devreye alınmış bir çözümün kanıtı değil, önerilen iyileştirmeler olarak kalıyor. Enflasyon komisyonu, MEV komisyonu ve blok geliri paylaşımı ayrı bileşenler olduğundan, tek bir oranın görünür hâle gelmesi staking getirisinin tamamını açıklamaz. Eylül ayında ödülle bağlantılı oy kredileri üzerine yapılan değerlendirmeler de performans ölçümlerinin tek başına, hesap düzeyinde kanıt olmadan tek bir kullanıcının SOL ödemesindeki kaybı ölçemeyeceğini ortaya koymuştu. Komisyon oranları görünmeyen kullanıcıların ödemeleri kontrol etmek için zamanlaması ve kapsamı doğrulanabilen geçmiş kanıtları bulması gerekiyor.