Hello. I design and build blockchain solutions. I like to make the complex simple.
Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.
This story contains new, firsthand information uncovered by the writer.
The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.
Borçlanma, Ethereum tabanlı blockchain uygulamalarının temel taşıdır . İle
Programlama paradigmalarının evrimi gibi, bu DeFi uygulamaları da güvenlikten verimliliğe ve kullanıcı deneyimine kadar değişen öncelikleri yansıtan çeşitli mimari tasarımlara sahiptir.
Bu analiz aşağıdaki gibi uygulamaların mimarisine bakar:
Geliştirici, mimar veya güvenlik araştırmacısıysanız bu makale tam size göre. Sonunda, Ethereum'daki yeni borçlanma uygulamalarını kolayca anlayacak, mimarilerini hızlı ve kapsamlı bir şekilde kavrayacaksınız. Bu DeFi devlerinin sıfırdan nasıl oluşturulduğunu görmek için dalın.
DeFi borçlarının çoğu
Ancak bir sorun var.
Teminatın değeri her zaman kredi değerini önceden belirlenmiş bir marj kadar aşmalıdır .
Teminat değerinin bunun altına düşmesi durumunda kredi
Tasfiye sırasında başkası kredinizin bir kısmını veya tamamını geri öder ve karşılığında teminatınızın bir kısmını veya tamamını alır.
Bu mali yapıyı takip eden tüm borçlanma uygulamaları aynı yapı taşlarına ihtiyaç duyar ve bunlar daha sonra birçok şekilde düzenlenebilir:
MakerDAO'da borç alma işlemi. Tüm uygulamalar aynı adımları ve işlevleri paylaşır.
Borç alma ve borç verme ayrı özellikler olarak düşünülebilir. DeFi'de, çoğu borç alma uygulamasında her iki özelliği de görüyoruz, ancak bunlar her zaman iyi bir şekilde entegre edilmiyor .
Compound, Aave ve Euler'de bunlar . Borç alanlar ve borç verenler için faiz oranları dahili olarak ilişkilidir; aslında bu uygulamaların minimum müdahaleyle çalışmasını sağlayan da budur.
Öte yandan MakerDAO ve Yield, borçlulara ödünç verdikleri varlıkların yaratıcılarıdır.
Kullanıcıların diğer kullanıcıların ödünç alabilmesi için varlık sağlamasını gerektirmezler .
Bu makale zincir içi borçlanmaya odaklanacak ve borç vermeyi büyük ölçüde göz ardı edecektir. Borçlanma, teminatlandırma gerekliliği nedeniyle çok daha karmaşıktır ve borçlanma modelini anlamak, genellikle tüm protokolün daha iyi anlaşılmasını sağlar.
MakerDAO Logosu
MakerDAO'daki hazine işlevi,
Var
Aksine, MakerDAO'nun borçlanma varlığı olan herhangi bir DAI'si yoktur.
Bunun yerine yalnızca
Muhasebe, bünyesinde gerçekleştirilir.
Bu eylem, kullanıcının borç bakiyesini günceller ve DAI Katılımında DAI oluşturmasına olanak tanır.
Kullanıcılar geri ödeme yapmak için DAI Katılımında DAI'yi yakarlar. Bu işlem daha sonra KDV'yi güncelleyerek kullanıcının kredisini kapatmasını sağlar .
Ek olarak vat.sol
sözleşmesi,
Kullanıcının borcunda veya teminat bakiyesinde değişiklik yapıldığında vat.sol sözleşmesi hem oranı hem de spotu değerlendirir.
Bunlar, kullanılan teminata ve geçerli DAI-teminat fiyat oranına dayalı faiz oranını ifade eder. İlginç bir şekilde, bu değerler diğer uygulamaların çoğundan farklı bir yöntem olan diğer MakerDAO sözleşmeleri tarafından vat.sol sözleşmesine beslenir.
MakerDAO , gaz maliyetleri gibi faktörlerin ikinci planda olduğu , kullanıcı deneyiminin küçük bir endişe kaynağı olduğu ve rekabetin göz ardı edilebilir olduğu tasarım aşamasında güvenliğe öncelik verdi.
Sonuç olarak ilginç, kullanımı maliyetli ve gezinmesi zor görünebilir.
Ancak yönettiği geniş varlıklar ve önemli ihlaller olmadan çalışma geçmişi, sağlam tasarımının ve uygulamasının altını çiziyor.
Öne çıkanlar:
YieldSpace'in potansiyelinin farkına vararak hızla geliştirme sürecine geçtik
Yield v2'deki borçlanma süreci MakerDAO'dan büyük ölçüde etkileniyor
Tüm muhasebe, risk yönetimi ve teminat kontrolleri tek bir sözleşmede birleştirildi:
Fiyat ve faiz oranı kehanetlerini birleştirerek kehanet entegrasyonumuzu yeniledik.
MakerDAO'nun yaklaşımından bir diğer önemli sapma da,
Özetle, Yield v2'de borç alma şu şekilde çalışır:
Bileşik v1'de ödünç alma süreci. Basit ama etkili.
Buna dayanarak
İlginç bir şekilde teknik inceleme, Compound v2'nin dahil olduğunu vurgulamıyordu.
Bileşik v2'de ödünç alma süreci. Tokenize borç verme pozisyonlarına ilk adım.
Bileşik v3'teki (Comet) ödünç alma işlemi. Temellere, güvenliğe geri dönelim. Ancak daha iyi bir kullanıcı deneyimiyle.
Gerekli çağrı sayısındaki azalma nedeniyle sistem hem geliştiriciler hem de kullanıcılar için daha sezgiseldir. Ayrıca tekil sözleşme tasarımı, sözleşmeler arasındaki çağrıları en aza indirerek gaz maliyetlerini azaltır. Ayrılmış para piyasaları, şu anda büyük bir güvenlik endişesi olan kehanet tabanlı saldırılara karşı bir savunmadır.
Bahsedilen diğer ilgili özellikler
İlginç bir şekilde Compound v3, her ödünç alınabilir varlık için tüm fonksiyonları tek bir sözleşmeyle yöneterek Compound v1'in mimarisini yansıtıyor. Diğer dikkate değer özellikler şunları içerir:
Teminat ödünç alma yasağı, teminatı yatıranların güvenliğini artırıyor. Bu, yönetişim hatalarının veya kasıtlı saldırıların teminatı tehlikeye atma olasılığını azaltır.
Sağlanan teminatlardan elde edilen getirilerin ortadan kaldırılması, Compound'un v2'de çok fazla likidite biriktirmeyi başarmasının bir sonucu olabilir. Bileşik v2'de borçlanma limitlerinin kullanıcılar tarafından uygulamaya ödünç verilen varlıkların ya altında olduğu ya da çok da yüksek olmadığı yönünde bir izlenimim var.
V3 için benzer likidite seviyelerini yöneteceklerini varsayarsak, teminatların ödünç verilmesine izin verilmemesi, v3'ün temel hedeflerinden biri olan uygulamayı güvenli hale getirir.
Mimari açıdan bakıldığında:
Aave v1.0 sürümünde ödünç alma işlemi Birleştirilmiş likidite, finansal ve hesaplama verimliliği anlamına geliyordu.
Verim v2'de olduğu gibi,
Teminat kontrollerini bırakma kararı
Aave v2, tamamen tokenize edilmiş, çok temiz bir mimariye sahiptir.
Aave v1'in sınırlı kullanıma sahip bazı özellikleri basitlik amacıyla çıkarılmıştır. Aave v1'de tahakkuk eden faizin karmaşık temsili gibi sorunlar Aave v2'de giderildi.
Pek çok ilerlemesine rağmen bu çalışmanın amaçları açısından Aave v3, Aave v2'den maddi olarak farklı değildir. Aslında bu, Aave v2 mimarisinin 2023'te de sağlam kalacağını gösterebilir.
Tasarımının ayırt edici özelliği,
Tek bir sözleşme tüm varlıkları, muhasebe ve risk yönetimi verilerini saklasa da, Aave v2'ye benzer şekilde teminat ve borç verme için eToken'lar ve borç için dToken'lar hâlâ mevcuttur. Ancak bu token sözleşmeleri yalnızca merkezi depolama sözleşmesinin görünümleridir.
Kodun analizi, minimum gaz maliyetinin bir öncelik olduğunu ortaya koyuyor ve bu da monolitik tasarımın sözleşmeler arası çağrı ihtiyacını ortadan kaldırmasına yol açıyor. Güvenlik, sıkı test ve denetimlerle sağlandı. Yalnızca mantık çeşitli modüllere dağıtıldı ve öncelikle bir vekil sözleşme görevi gören depolama sözleşmesinin uygulaması olarak hizmet verdi.
Bu birleşik tasarım aynı zamanda kolay yükseltmeleri de destekler. Herhangi bir depolama değişikliği gerekmiyorsa, modüller hızlı bir şekilde değişiklik yapmak veya özellikler eklemek için değiştirilebilir.
Euler, piyasaya sürülmesinden on beş ay sonra ve yükseltmenin istismar edilen güvenlik açığını ortaya çıkarmasından altı ay sonra saldırıya uğradı.
Varlıkların tükenmesinde yekpare mimarinin bir rol oynadığını düşünmüyorum; daha doğrusu, kod güncellemelerinin denetimi yetersizdi .
Zor iş tamamlandı, hadi öğrendiklerimizi gözden geçirelim
MakerDAO, Compound ve Aave gibi ilk Ethereum uygulamaları, Ethereum üzerinde aşırı teminatlandırılmış borçlanma potansiyelini ortaya çıkardı. Bu konsept kanıtlarının başarılı olduğu kanıtlandıktan sonra odak noktası, pazar payını yakalamak için yeni özelliklerin bir karışımını sunmaya yöneldi. Compound ve Aave'nin sonraki versiyonları, özellikle yükselişli piyasa koşullarında gelişen getiri çiftçiliği, şekillendirilebilirlik ve havuzlanmış likiditeyi tanıttı.
Önemli bir gelişme, Compound v2'nin, bu pozisyonların diğer uygulamalar tarafından standart varlıklar olarak tanınmasını sağlayan tokenize borç verme pozisyonlarını tanıtmasıydı. Aave v2 ve Euler, daha geniş faydası tartışma konusu olmaya devam eden tokenize edilmiş borç pozisyonlarını uygulayarak bunu bir adım daha ileri götürdü.
Boğa piyasasında yüksek gas maliyetleri önemli bir endişe kaynağı olarak ortaya çıktı ve Yield v2, Aave v2 ve Euler'de görüldüğü gibi kullanıcı deneyimi değişikliklerine yol açtı. Yönlendirici sözleşmeleri ve yekpare uygulamalar, kullanıcıların işlemler için katlandığı maliyetlerin azaltılmasına yardımcı oldu. Ancak bu, daha karmaşık ve dolayısıyla daha riskli kod pahasına gerçekleşti.
Compound v3, finansal verimliliğin önünde güvenliğe öncelik vererek bir emsal teşkil ediyor gibi görünüyor. Potansiyel saldırılara karşı daha iyi koruma sağlamak için geleneksel likidite havuzu modelinden farklıdır. Gaz maliyetlerinin giderek ihmal edilebilir hale geldiği L2 ağlarının yükselişi, muhtemelen gelecekteki teminatlı borçlanma uygulamalarının tasarımını şekillendirecektir.
Bu makalede, Ethereum'daki önemli teminatlı borçlanma uygulamalarına kapsamlı bir genel bakış sundum. Her başvuruyu analiz etmek için kullandığım yaklaşım, diğer teminatlı borçlanma uygulamalarının karmaşıklıklarını hızla kavramak için de uygulanabilir.
Bir blockchain borçlanma uygulaması geliştirirken her zaman varlıkların depolanmasını, muhasebe kayıtlarının yerleştirilmesini ve risk ve teminat değerlendirme yöntemlerini göz önünde bulundurun. Bu hususlar üzerinde çalışırken, önceki uygulamaların geçmişinden ve bu genel bakıştan elde edilen bilgilerden yararlanarak kararlarınızı şekillendirin.
Okuduğunuz için teşekkür eder, iyi şanslar dileriz.
Sayesinde
Yazar, Yield Protokolünün Kurucu Ortağı ve Teknik Lideridir.
Ethereum'dan Borç Alma: MakerDAO, Yield, Aave, Compound ve Euler'in Mimari Gelişiminin Karşılaştırılması | HackerNoon