
Aave kötü borçları: Tasfiye sonrası rezerv açığına kadar
Aave kötü borçlarının nasıl çalıştığı sonuç olarak basit, uygulama açısından karmaşıktır: bir tasfiye tüm teminatı satabilir ve yine de ödenmemiş borç bırakabilir. Aave v3.3'te, bu kalan borç hemen borçlunun kalan değişken borç token'larını yakarak kristalleştirilir ve eksiklik bir rezerv açığı olarak kaydedilir.
Ana Noktalar
- Aave kötü borcu, belirli bir sonrası-tasfiyesıfır bakiyeye sahip bir hesabın durumuteminatancak hala kalan borcu var.
- Aave v3.3, borçlunun kalan değişken borç tokenlerini yakarak ve açığı rezerv başına bir açık olarak kaydederek “zombi” yükümlülüklerin bileşmesini durdurur.
- Rezerv açıkları takip edilmektedir.varlıkReserveData'da yer alır ve bir Havuz getter'ı aracılığıyla açığa çıkar, kayıpları görünmez bir şekilde sürüklenmek yerine ölçülebilir hale getirir.
- Açıklar, yetkilendirilmiş bir Şemsiye varlığının aToken'ları yakmasıyla azaltılabilir ve Şemsiye staking'i, kötü borç belirli eşikleri aştığında varlık spesifik kasaları kesmek için tasarlanmıştır.
Aave'de 'kötü borç' ne anlama geliyor (sade İngilizce tanımı)
Aave'deki 'kötü borç nasıl çalışır' kesin bir tanımla başlar, bir hisle değil. Aave'de kötü borç, 'riskli bir borçlu' veya 'yanlış giden bir tasfiye' değildir. Bu, bir tasfiye sonrasında borçlunun teminatının tamamen tükendiği ve bazı borçların ödenmediği bir muhasebe son durumudur. O noktada, protokol, karşılanmamış bir yükümlülük taşımaktadır.
Bu önemlidir çünkü Aave, tasarım gereği bir aşırı teminatlı kredi vermeprotokolüdür. Tüm premis, teminat değerinin, bir pozisyon sağlıksız hale geldiğinde borcu kapatmak için defi tasfiyesi aracılığıyla yeterli olması gerektiğidir. Kötü borç, bu mekanizma fiyat boşlukları, likidite sınırları veya tasfiye hızlanması nedeniyle döngüyü tam olarak kapatamadığında geriye kalanlardır.
Aave v3 belgeleri, rahatsız edici bir kenar durumu açıkça kabul eder: bazı tasfiye senaryoları sıfır teminat ve kalan borçla sona erebilir ve bu borcun geri ödenmesi olası değildir. Pratik sorun sadece kayıp değildir. Drift'tir. Sistem, o kalanı normal değişken borç olarak değerlendirmeye devam ederse, arkasında teminat olmayan bir IOU üzerinde faiz birikir ve bu da protokolün görünür yükümlülüğünü zamanla şişirir. Bu, tüccarların gerçekten önemsemesi gereken 'kötü borç defi' başarısızlık modudur.
aave kötü borç nasıl çalışır
Pratikte, aave kötü borç nasıl çalışır, bir girdiler → süreç → çıktılar dizisidir.
Girdiler: bir borçlu teminat sunar, bir varlık borç alır ve fiyatlar hareket ettikçe pozisyon teminatsız hale gelir. Aave bunu bir sağlık faktörü ile izler. Sağlık faktörütasfiye eşiğiÜçüncü taraf tasfiye edicileri, borçlunun borcunun bir kısmını geri ödeyebilir ve tasfiye bonusu aracılığıyla teminatı indirimli olarak alabilirler.
Süreç: tasfiye tek bir temiz olay değildir. Bir dizi onchain işlemin birbirine karşı rekabet ettiği bir süreçtir.kehanetgüncellemeler, blok dahil etme,gaz maliyetlerive geri ödeme varlığını temin etmek ve el konulan teminatı satmak için mevcut piyasa likiditesine. Aave v2, tasfiye başına ne kadar borcun geri ödenebileceğini sınırlayan sabit bir kapama faktörü kullandı.
Aave v3, daha derin sıkıntı koşullarında %100'e kadar geri ödemeye izin verebilen değişken bir kapama faktörü tanıttı; bu, tasfiye edilmesi ekonomik olmayan kalan "toz" miktarını azaltmayı amaçlıyor.
Çıktılar: Eğer tasfiyeler tüm borcu geri öderse, sistem iyidir. Kötü borç, tasfiyelerin tüm teminatı tüketip yine de tam borcu geri ödeyemediği zaman ortaya çıkar. Bu, tanımlayıcı durumu üretir: teminat sıfıra eşit, borç hâlâ sıfırdan farklıdır. v3.3'ten önce, o kalan borç faiz biriktirmeye devam edebilir ve bir kerelik bir eksikliği büyüyen bir muhasebe sorununa dönüştürebilir.
v3.3'te, protokol, tasfiyeden hemen sonra kalan değişken borç token'larını yakarak ve o varlık için bir rezerv açığı kaydederek o kalanı protokol düzeyinde bir kayıp olarak ele alır.
Kötü borcun nasıl oluştuğu: tasfiye mekanikleri ve “yetersiz teminat” kenar durumu
Tasfiye genellikle “sağlık faktörü < 1, bu nedenle borç geri ödenir.” gerçek dünyadaki tasfiye akışı, katı sınırlarla kısıtlı bir açık artırmaya daha yakındır. Tasfiye edenler, yalnızca işlem gaz ve yürütme riski sonrası kârlı olduğunda harekete geçer ve protokolün kapanma faktörü kuralları, her işlem başına ne kadar geri ödenebileceğini sınırlar.
Bitget'in kılavuzu, temel mekanikleri yakalar: sağlık faktörü eşik değerinin altına düştüğünde tasfiye tetiklenir ve tasfiye edenler teminat karşılığında borcu indirimli olarak geri öder.
Ayrıca, versiyonlar arasındaki yakınlık faktörü farkını belirtir; Aave v2, her tasfiye başına %50'ye kadar geri ödeme izni verirken, Aave v3 sağlık faktörü daha da kötüleştiğinde %100'e kadar geri ödemeye izin verir (yaklaşık 0.95 civarında bir eşik değeri örnek olarak verilmektedir).
Kötü borç, likidasyon motoru işini yaparken, ancak piyasa motorun riski temizleyebileceğinden daha hızlı hareket ettiğinde oluşur. Fiyat boşlukları, teminatın oracle güncellemeleri arasında modellemeden daha az değerli olmasına neden olabilir.
İnce likidite, geri ödeme varlığını temin etmenin veya el konulan teminatı boşaltmanın maliyetli olmasına yol açabilir.kaymaKapatma faktörü mekanikleri, likidasyonun parçalar halinde gerçekleşmesini zorlayabilir; bu, yavaş piyasalarda sorun değilken, kesintili hareketlerde tehlikeli olabilir.
Aave v3.3 belgeleri, kenar durumu hakkında açıktır: tasfiye, toplam teminatın tüm borcun geri ödenmesini karşılamak için yetersiz olmasına neden olabilir, bu da sıfır teminat ve kalan borç bırakır. İşte bu, borçlu sorununu bir protokol muhasebe sorunu haline getirir.
Aave v3.3 kötü borç yönetimi: kalan borçları yak, bir rezerv açığı kaydet
Aave v3.3'ün ana değişikliği "kötü borcu önlemek" değil, "kötü borcun mutasyona uğramasını durdurmak"tır. Protokol, tasfiye sonrası yeni kötü borç hesaplarının oluşturulmasını azaltmak ve bu yükümlülükler üzerindeki faiz birikimini durdurmak için tasarlanmış bir tasfiye sonrası doğrulama adımı tanıtmaktadır.
Mekanik olarak, protokol tasfiye ve geri ödeme sonrasında hesabı kontrol eder. Eğer hesap sıfır teminat ve sıfırdan büyük bir borçla sonuçlanıyorsa, kalan borç yakılır ve ortaya çıkan açığı ilgili rezervde bir açık olarak kaydedilir. Belgeler bu temizliği, ticaret için doğru zihinsel model olan gerçek tasfiyeden sonra kavramsal olarak gerçekleşen bir durum olarak tanımlar. Tasfiye ticarettir. Temizlik ise uzlaştırmadır.
Bu, kod formundaki v3.3 tezidir: kötü borç artık bir kullanıcının üzerinde kalıp sonsuza dek birikmesine izin verilmez. Bu, her varlık için takip edilebilen bir rezerv düzeyinde açığa dönüştürülür. v3.3, rezerv verileri içinde açık takibi tanıtarak, kullanımdan kaldırılmış stableBorrowRate depolamasını yeniden kullanır ve bunu bir Havuz alıcısı olan getReserveDeficit aracılığıyla açığa çıkarır.
Bu, açığın her rezerv için işaretlenebilir hale gelmesini sağlar, böylece sürüklenen faiz matematiği içinde gömülmek yerine.
GHO için özel bir işlem de bulunmaktadır. v3.3, tasfiyeyi değişken bir borç yakma ve ücretleri indiren bir aGHO geri ödeme yöneticisine ayırır. GHO'daki kötü borçları yakarken, protokol vGHO üzerindeki birikmiş ücret depolamasını sıfırlar ve kötü borç kısmı için birikmiş ücretlerdeki kaybı kabul eder, böylece muhasebe tutarlı kalır. Bu detay önemlidir çünkü niyeti gösterir.
Hedef, eski ücret taleplerinin artık borç token'ları olmayan bir hesaba bağlı kalmaması için deterministik bir temizlik yapmaktır.
aave'nin güvenlik modülü nasıl çalışır
Eski Güvenlik Modülü, her zaman açık bir sigorta motoru yerine, yönetişim aracılığıyla bir destek mekanizması olarak en iyi şekilde anlaşılmaktadır. Blockworks bunu, teorik olarak stkAAVE ve AAVE-ETHLP pozisyonlarının kesilebileceği bir destek mekanizması olarak tanımlar, ancak kesme hiç gerçekleşmedi çünkü bu yönetişim oylamaları gerektiriyordu ve siyasi teşvikler etkinleştirilmesini olası kılmadı.
Pratik risk terimleriyle, bu, Güvenlik Modülü'nün değerinin otomasyondan ziyade güvenilirlik olduğunu gösterir. Bir yönetişim token'ı ile uyumlu bir grubun kayıpları yeniden sermayelendirebileceğini işaret etti, ancak hızlı bir piyasada hızlı, deterministik kayıp emilimini garanti etmedi.
Bu nedenle, v3.3'ün kötü borç muhasebesi, bir destek mekanizması olsa bile önemlidir. Kötü borcun kullanıcı hesaplarında kalmasına ve faiz birikmesine izin verilirse, protokol kaybı temiz bir şekilde ölçemez, bu da herhangi bir destek kararı almayı zorlaştırır. Açığı bir rezerv açığına dönüştürerek, Aave Güvenlik Modülü sorusunu daha somut hale getirir: ne kadar açık var, hangi varlıkta ve bunu nötralize etmek için hangi mekanizma yetkilidir.
aave kötü borç olduğunda kim öder
v3.3'te kötü borç tanındığında, ödenmemiş miktar artık ekonomik anlamda "borçlu tarafından" "borçlu" değildir. Borçlunun hiçbir teminatı kalmamıştır ve protokol, faiz birikimini durdurmak için kalan değişken borç token'larını yakmıştır. Kayıp, belirli rezerv üzerindeki bir açık olarak kaydedilir.
Bu çerçeve pratikte kimin ödeme yaptığını yanıtlar: rezerv eksik ve sistemin tam destek sağlamak için yeniden sermayelendirilmesi gerekiyor. v3.3, rezerv açığını azaltmak için, kayıtlı Umbrella'nın PoolAddressesProvider üzerindeki yetkilendirilmiş bir varlık tarafından aToken'ların yakılabileceği eliminateReserveDeficit'i tanıtır. Fonksiyon, mevcut açığı yakmakla sınırlıdır ve arayanın açık borç pozisyonu olmadığını doğrular.
Bu belirsiz bir "sigorta fonu bunu karşılayabilir" değildir. Bu, rezerv üzerindeki talepleri (aToken'lar) yok ederek izlenen bir açığı azaltan belirli bir onchain eylemidir. Ekonomik sonuç açıktır. Kapsama varlıklarını elinde tutan birisi, o rezervdeki mevduat sahiplerinin yeniden tam olarak karşılanması için kaybı üstlenmektedir.
Blockworks'ün Umbrella staking tanımı operasyonel katmanı ekler. Umbrella, belirli varlıklara bağlı otomatik bir güvenlik ağı olarak sunulmaktadır ve o varlık üzerindeki kötü borç önceden belirlenmiş bir eşiği aştığında, yapılandırılabilir bir ilk kayıp offseti ile gerçek zamanlı kesinti yapılmaktadır; bu, o zaman her varlık için 100.000 birim olarak rapor edilmiştir.
Bu, tasarlanmış bir sistemde "kimin ödediği" sorusuna pratik bir yanıt: etkilenen varlık kasasındaki stake edenler, offset tamponunun üzerinde, genel bir havuz yerine.
aave daha önce hiç kötü borç yaşadı mı
Evet, ve 2022 CRV olayı, "sadece tasfiye et" ifadesinin neden bir garanti olmadığının en temiz örneğidir. EigenPhi'nin vaka çalışması, tasfiyelerden sonra yaklaşık 2.456 milyon CRV'nin ödenmemiş olduğu bir CRV açığını tanımlar; bu, belirtilen CRV fiyatında yaklaşık 1.6 milyon dolar değerindedir.
Tasfiye etkinliği basit değildi. EigenPhi, 21 benzersiz adres tarafından 385 tasfiye rapor etmektedir. Buradaki nokta, tasfiye edenlerin yokluğunda değildir. Nokta, tasfiye verimliliği ve oracle zamanlamasının, piyasalar sıçramalarla hareket ettiğinde hala bir kalıntı borç kalıntısı bırakabileceğidir.
EigenPhi ayrıca Binance'a karşı yaklaşık 10 dakikalık bir oracle fiyat gecikmesi not eder ve gruplar halinde gelen tasfiye davranışını tanımlar. Bu kombinasyon, teminatın borcun tamamen geri ödenmeden önce tükenebileceği tam ortamdır. Aave v3.3'ün kötü borç tanımı "teminatın borç tamamen geri ödenmeden önce tükenmesi" teorik değildir. Bu, zaten stres altında gerçekleşmiş bir durumdur.
aave umbrella modülü nedir
Umbrella, kaybı hem otomatik hem de varlık-spesifik hale getirmeye çalışan Aave'nin daha yeni güvenlik tasarımıdır. Blockworks, Umbrella staking'i, doğrudan bireysel varlıklara bağlı otomatik bir onchain güvenlik ağı olarak tanımlar ve izole kasalar olarak uygulanır.
Bir açık meydana gelirse, protokol, yapılandırılabilir bir ilk kayıp offsetinden sonra, o varlıktan kasasından yakabilir; bu, o zaman her varlık için 100.000 birim olarak rapor edilmiştir.
“Varlık-spesifik” kısım gerçek tasarım değişikliğidir. Riskin geniş bir yönetişim tokeni desteklemesi aracılığıyla sosyalize edilmesi yerine, Umbrella gerçekten açık olan rezervi hedef alır. Bu, v3.3’ün her rezerv için açık izleme ile uyumludur. Protokol, USDC ile ETH ile GHO arasındaki bir açığı ölçebiliyorsa, varlık bazında da bölümlere ayrılmış bir destekleme operasyonel olarak daha temizdir.
Umbrella ayrıca zaman boyutunu değiştirir. Blockworks, bir yönetişim oyu olmadan, bir açık artırma olmadan ve eşiklerin aşılması durumunda kesme için gecikme olmadan vurgular. Bu önemlidir çünkü kötü borç genellikle hızlı piyasalarda doğar. Uzun bir yönetişim sürecinden sonra yalnızca etkinleşen bir destekleme, probleme yapısal olarak uyumsuzdur.
aave iflas edebilir mi
Aave, belirli bir piyasada yükümlülüklerin varlıkları aştığı rezerv seviyesinde iflasla karşılaşabilir; bu, tam olarak bir rezerv açığının temsil ettiği şeydir. Aave v3.3 başka türlü davranmaz. Açığı izlenebilir ve potansiyel olarak nötralize edilebilir hale getirmek için resmileştirir.
Ana nüans kapsamdır. v3.3, kötü borç durumunu dar bir şekilde, temel para biriminde sıfır teminatı ve temel para biriminde kalan borcu olan bir hesap olarak tanımlar. Herhangi bir kalan teminatı olan hesaplar kötü borç olarak değerlendirilmez çünkü tekrar aşırı teminatlı hale gelebilirler. Bu pratik bir çizgidir. İflas, teminatsız yükümlülükler ile ilgilidir, geçici olarak sağlıksız pozisyonlarla değil.
v3.3 ayrıca kuyruk riski modelleyen herkes için önemli olan sınırlamaları belgeler. Zaten mevcut olan kötü borç pozisyonlarını düzeltmez ve DAO temizliği için repayOnBehalf önerir. Açık giderme, Umbrella'nın yakacak tokenleri olduğu varsayımına dayanır ve tavanlar ve sanal muhasebe gibi operasyonel kısıtlamalar, teminat varlıklarının ne kadar hızlı konumlandırılabileceğini etkileyebilir.
Bu, sistemin yeni zombi borcun birikimini tanıyıp durdurabileceği anlamına gelir, ancak yeniden sermayelendirme hala destekleme yapılandırmasına ve mevcut teminata bağlıdır.
Yaygın yanlış anlamalar
İlk yanlış anlama, “kötü borç, tasfiyelerin başarısız olduğu anlamına gelir.” Tasfiyeler, tasarlandığı gibi tam olarak gerçekleştirilebilir ve yine de sıfır teminat ve kalan borçla sonuçlanabilir çünkü tasarım, yakın faktörler, gaz ekonomisi, oracle güncelleme sıklığı ve ikincil piyasa likiditesi gibi kısıtlamalarla sınırlıdır. CRV vaka çalışması, yoğun tasfiye faaliyetini gösterir ve yine de bir kalan ödenmemiş miktar vardır.
İkinci yanlış anlama, “kötü borç sadece bir borçlunun ödenmemiş kredisidir.” Aave v3.3'te, protokol borçlunun kalan değişken borç tokenlerini yaktığında, borçlu artık yükümlülüğün bulunduğu yer değildir. Kayıp, her varlık için bir rezerv açığı olarak kaydedilir ve soru, bu açığın eliminateReserveDeficit ve Umbrella'nın varlık-kasa kesme gibi mekanizmalar aracılığıyla nasıl azaltılacağıdır.
Üçüncü yanlış anlama, “Aave v3.3 tüm kötü borçları ortadan kaldırır.” v3.3, yeni tasfiye sonrası zombi hesapların faiz biriktirmesini, kalan borcu yakarak ve bir açık kaydederek engeller, ancak belgeler açıkça zaten mevcut olan kötü borç pozisyonlarını çözmediğini belirtir. Pratik sonuç, v3.3'ün determinism ve şeffaflığı artırdığı, piyasa boşluklarının yasalarını değil.
Bu konu, overcollateralization ve likidasyonun temel güvenlik önlemleri olduğu daha geniş defi mekanikleri içinde yer alıyor. Protokol riskini haritalayan okuyucular için, yararlı bir sonraki adım ana defi rehberine geri dönmek ve kötü borcu ölçülebilir bir rezerv açığı sorunu olarak ele almak, ahlaki bir hikaye olarak dikkatsiz borçlular hakkında değil.
Kaynaklar
Sıkça Sorulan Sorular
Aave'de sağlıksız bir pozisyon ile kötü borç arasındaki fark nedir?
Sağlıksız bir pozisyon hala teminata sahip olabilir ve fiyatlar lehine hareket ederse toparlanabilir. Aave v3.3, kötü borcu, teminatın temel para biriminde sıfır olduğu ancak bazı borçların kaldığı, tasfiye sonrası durumu olarak dar bir şekilde tanımlar. Kalan borç, geri ödenmesi olası olmayan bir borç olarak değerlendirilir ve borç yakma ve rezerv açığı muhasebesi yoluyla işlenir.
Aave v3.3, kötü borcun faiz birikmesini nasıl engeller?
Tasfiyeden sonra, v3.3, hesabın sıfır teminata ve sıfır olmayan bir borca sahip olup olmadığını kontrol eder. Eğer öyleyse, borçlunun kalan değişken borç tokenlerini yakar ve açığı bir rezerv açığı olarak kaydeder. Borç tokenlerinin yakılması, kurtarılamayan bir yükümlülük üzerinde daha fazla faizin birikmesini engeller.
Birinin belirli bir Aave pazarında bir açığın olup olmadığını nasıl görebilir?
Aave v3.3, rezerv başına açık verilerini ReserveData içinde depolar ve bunu getReserveDeficit adlı bir Havuz alıcısı aracılığıyla açığa çıkarır. Bu, açığın dolaylı olarak kayma bakiyelerinden çıkarılmak yerine, varlık varlık bazında gözlemlenmesini sağlar.
Umbrella, Aave'deki rezerv açıklarıyla nasıl ilişkilidir?
Aave v3.3, bir izinli Umbrella varlığının bir rezervin açığını azaltmak için aToken yakmasına izin veren eliminateReserveDeficit'i ekler, açığın miktarına kadar. Umbrella staking, o varlıkta kötü borç belirlenen bir eşiği aştığında, bir varlık özel kasasından varlıkları kesme veya yakma yeteneğine sahip otomatik bir sistem olarak tanımlanır.
Aave, CRV olayı gibi büyük tasfiyeler sırasında kötü borç yaşadı mı?
EigenPhi'nin 2022 CRV kısa raporuna göre, tasfiyelerden sonra yaklaşık 2.456 milyon CRV ödenmemiştir ve bu, belirtilen CRV fiyatında yaklaşık 1.6 milyon dolar değerindedir. Rapor ayrıca 21 benzersiz adres tarafından 385 tasfiye ve Binance'a karşı yaklaşık 10 dakikalık bir oracle gecikmesi olduğunu not eder; bu, aktif tasfiye katılımı olsa bile, kalan borcun nasıl kalabileceğini gösterir.
İlgili okumalar

DeFi likidite krizinde kripto çekme rehberi
Havuz likiditesi, kredi risk limitleri veya işlem yürütme tarafından engellenip engellenmediğinizi teşhis edin, ardından tasfiyeyi ve yanlış zincir hatalarını önlemek için çekimleri sıralayın.
8 dk okuma

DeFi çöküş riski: teminat ve likidasyonlar nasıl etkiler?
DeFi bulaşması, paylaşılan bağımlılıkların ve otomatik tasfiyelerin protokoller arasında stres iletimini insanların tepki verebileceğinden daha hızlı bir şekilde ilettiği mekanik bir zincirleme reaksiyondur.
10 dk okuma

DeFi protokolü hacklendiğinde: zincir üzerindeki zaman…
Bir DeFi hack'i genellikle protokol kontrolündeki kasaların hızlı bir şekilde boşaltılması, ardından acil bir duraklama, soruşturma ve kullanıcılar için belirsiz bir kurtarma süreci ile devam eder.
12 dk okuma