paint-brush
Ethereum'dan Borç Alma: MakerDAO, Yield, Aave, Compound ve Euler'in Mimari Gelişiminin Karşılaştırılmasıile@alcueca
4,442 okumalar
4,442 okumalar

Ethereum'dan Borç Alma: MakerDAO, Yield, Aave, Compound ve Euler'in Mimari Gelişiminin Karşılaştırılması

ile Alberto Cuesta Cañada 12m2023/09/26
Read on Terminal Reader
Read this story w/o Javascript

Çok uzun; Okumak

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.
featured image - Ethereum'dan Borç Alma: MakerDAO, Yield, Aave, Compound ve Euler'in Mimari Gelişiminin Karşılaştırılması
Alberto Cuesta Cañada  HackerNoon profile picture
0-item
1-item
2-item

Borçlanma, Ethereum tabanlı blockchain uygulamalarının temel taşıdır . İle milyarlarca varlık ödünç verildi Borçlanmanın nasıl çalıştığını anlamak geliştiriciler, mimarlar veya araştırmacılar için çok önemlidir.


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: MakerDAO , Birleştirmek , Aave , Euler , Ve Teslim olmak . Gelecekteki kredilendirme uygulamalarının geliştirilmesi için önemli dersler olan önemli yenilikleri ve tasarım modellerini vurgulayacağız.


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'de borç alma

DeFi borçlarının çoğu aşırı teminatlandırılmış . Bir kullanıcı, krediden daha değerli teminat sağlaması durumunda belirli bir varlığı ödünç alabilir. Geleneksel kredilerden farklı olarak bu kredilerin çoğunun düzenli geri ödemeleri veya sabit bitiş tarihleri yoktur. Aslında ödünç alabilirsiniz ve asla geri ödeyemezsiniz.


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 edilmiş .


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:


  • Kullanıcı teminatlarını ve ödünç alınan varlıkları depolamak için bir hazine
  • Her kullanıcının teminatını ve borcunu takip eden bir muhasebe sistemi
  • Borçlunun faiz oranını belirleyen işlevler
  • Bir kredinin yeterince teminat altına alınıp alınmadığını doğrulamaya yönelik, genellikle dış fiyat kehanetlerini içeren bir mekanizma
  • Teminatsız krediler için tasfiye yolu
  • Toplam borçlanma tutarlarını ve küresel ve kullanıcı bazında borçlanma limitleri, minimum teminat tutarları ve belirli aşırı teminat oranları gibi diğer güvenlik ölçütlerini kaydeden risk yönetimi sistemleri
  • Kullanıcıların teminat eklemesi ve kaldırması, ödünç alması ve altta yatan parayı geri ödemesi için bir arayüz

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'nun Mimari Evrimi

MakerDAO Logosu

MakerDAO Ethereum açısından eski, Kasım 2019'da mevcut haliyle lansmanı yapıldı , ve tutuyor 4,95 milyar dolar teminat . Her işlev için farklı sözleşmelere ve benzersiz terminolojiye sahip modüler mimarisine rağmen anlaşılması ve doğrulanması kolaydır.


MakerDAO'daki hazine işlevi, Katılmak sözleşmeler.


Var ayrı sözleşme Teminat varlığı olarak onaylanan her token için.


Aksine, MakerDAO'nun borçlanma varlığı olan herhangi bir DAI'si yoktur.


Bunun yerine yalnızca darphane ve yanıklar DAI gereğince, gerektiği gibi.


Muhasebe, bünyesinde gerçekleştirilir. KDV .sol sözleşme. Birleşmeler bu sözleşmeyi güncelle Teminat sisteme girdiğinde veya sistemden çıktığında. Bir kullanıcı ödünç alırsa, vat.sol sözleşmesiyle doğrudan etkileşimde bulunun .


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, risk yönetimi motor. Küresel borçlanma limitlerini korur, kullanıcı başına minimum eşikleri belirler ve teminat oranlarını denetler.

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:

  • Maksimum yayılmış hazine fonksiyonunda her varlığın kendi sözleşmesi vardır.
  • Muhasebe işlevi, teminat kontrolleri de dahil olmak üzere risk parametrelerini belgeleyen ve uygulayan tek bir sözleşme içerisinde merkezileştirilmiştir.
  • Diğer uygulamaların aksine oracles, teminatlandırmayı denetleyerek sözleşmeyi günceller
  • Fiyat ve faiz oranı kahinleri farklı arayüzler kullanır
  • Faiz oranı dışarıdan kaynaklanır
  • Ödünç almak için kullanıcıların birden fazla sözleşmeyle etkileşimde bulunması gerekir

Verim Protokolünün Mimari Evrimi

Verim v1 kullanılarak sabit oranlar için bir kavram kanıtı olarak kullanılmıştır. YieldSpace . Bu sürüm, teminatlandırılmış borç motorunu MakerDAO'nun üzerine kurdu. Ancak Yield v1'in kullanımı hem pahalıydı hem de yeni özelliklerle zenginleştirilmesi zordu.


YieldSpace'in potansiyelinin farkına vararak hızla geliştirme sürecine geçtik Verim v2 . Halen MakerDAO'dan ilham alan ancak artık tamamen bağımsız olan Yield v2 Ekim 2021'de piyasaya sürüldü ; Yield v2, daha düşük gaz maliyetlerine ve gelişmiş kullanıcı deneyimine öncelik verdi.

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: kazan . MakerDAO'nun yaklaşımını yansıtarak hazine fonksiyonlarını genel olarak dağıttık. Katılmak Her biri belirli bir varlığa adanmış sözleşmeler.


Fiyat ve faiz oranı kehanetlerini birleştirerek kehanet entegrasyonumuzu yeniledik. ortak arayüz . MakerDAO'dan gelen kehanet akışını Cauldron'ın sağlayacak şekilde tersine çevirdik. kahinlere danışır Teminat kontrolleri için gerektiği gibi. Bildiğim kadarıyla MakerDAO dışında her yerde tercih edilen akış bu.


MakerDAO'nun yaklaşımından bir diğer önemli sapma da, Kepçe . Bu sözleşme, kullanıcılar ile Yield arasındaki tek aracı görevi görür. Hazine ve muhasebe üzerinde kapsamlı bir kontrole sahiptir, ancak bunun karşılığında özellik geliştirme için muazzam bir esneklik sunar .


Özetle, Yield v2'de borç alma şu şekilde çalışır:

  • Her varlığın, hazine fonksiyonunun maksimum dağılımını sağlayan kendine özel bir hazine sözleşmesi vardır.
  • Tek bir sözleşme muhasebe fonksiyonunu merkezileştirir. Bu sözleşme aynı zamanda risk yönetimi önlemlerini de denetler ve teminatlandırma kontrollerini gerçekleştirir.
  • Teminatlandırma işlevi, fiyatları ve faiz oranlarını belirlemek için kahinlere danışır.
  • Hem fiyat hem de faiz oranı oracle'ları birleşik bir arayüzü paylaşır.
  • Faiz oranları dışarıdan oluşturulur.
  • Kullanıcılar tek bir sözleşmeye tek talepte bulunarak ödünç alabilirler.

Bileşik Finansın Mimari Evrimi


Compound'un ilk versiyonu bir Kavramın ispatı Ethereum üzerinde bir para piyasası kurulabileceğini gösteriyor. Bu nedenle tasarımında sadelik ön planda tutuldu. MoneyMarket.sol Sözleşme, borç verme de dahil olmak üzere tüm işlevleri kapsar.

Bileşik v1'de ödünç alma süreci. Basit ama etkili.


  • Teminat kontrolleri gibi hazine, muhasebe ve risk yönetimi görevleri tek bir sözleşmede birleştirilir.
  • Bu sözleşme kahinlerden fiyatları alır ancak faiz oranlarını varlık kullanımına göre belirler.
  • Kullanıcılar yalnızca bu sözleşmeyle etkileşimde bulunur, ancak teminat sağlamak ve varlıkları ödünç almak için ayrı çağrılar yapmaları gerekir.

Bileşik v2

Compound v2, Mayıs 2019'da piyasaya sürüldü , verimli tarım çağını ateşliyor ve sayısız çatallanmaya ilham veriyor. O da kullanıcıların varlıkları hem ödünç almasına hem de ödünç almasına olanak tanıyan bir para piyasası işlevi görüyordu.


Buna dayanarak Beyaz kağıt ve yapı açısından önemli bir hedefin olduğu açıktır. Bileşik v2 kullanmaktı Borç verme pozisyonlarını temsil eden ERC20 standardı . Bu, şekillendirilebilirliği sağlayarak kullanıcıların Compound'a borç vermesine ve daha sonra bu faiz getiren pozisyonları diğer blockchain uygulamalarında kullanmasına olanak tanıdı.


İlginç bir şekilde teknik inceleme, Compound v2'nin dahil olduğunu vurgulamıyordu. ödüller akıllı sözleşmelerine dahil ediyor. Bu ihmal göz önüne alındığında, bu özelliğin büyük etkisi öngörülememiş olabilir.

Bileşik v2'de ödünç alma süreci. Tokenize borç verme pozisyonlarına ilk adım.


  • Her varlığın kendi hazine sözleşmesi vardır ve bu da hazine fonksiyonunun dağılımını maksimuma çıkarır.
  • Muhasebe fonksiyonu da her cToken'ın kullanıcı teminatını ve borcunu belirtmesiyle dağıtılır.
  • Tek bir sözleşme olan Kontrolör, teminat kontrolleri de dahil olmak üzere risk yönetimi parametrelerini günlüğe kaydeder ve uygular.
  • Teminat kontrollerinden sorumlu sözleşme, fiyatlar için kahinlere ve faiz oranları için cToken'a atıfta bulunur.
  • Fiyat ve faiz oracle'ları farklı arayüzlerle çalışır.
  • Faiz oranı dahili olarak varlık kullanımından kaynaklanır.
  • Kullanıcıların ödünç almak için birden fazla sözleşmeyle etkileşime girmesi gerekir.


Bileşik v3

2022'de yayınlandı , Bileşik v3 Likiditeyi ayrı bölümlere ayıran daha muhafazakar bir risk yönetimi stratejisi benimser. havuz Her ödünç alınabilir varlık için. Tasarım aynı zamanda kullanım kolaylığı ve gaz maliyetleriyle ilgili endişeleri de ortaya koyuyor. 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 sürüm notları katmak:

  • Tamamen yenilenmiş bir risk yönetimi ve tasfiye motoru. Bu tasarım, fon güvenliğini artırırken aynı zamanda borç alan dostu olmayı da sağlar.
  • Riskleri azaltmak amacıyla bireysel teminat varlıkları için piyasa genelinde limitler belirleyin.
  • Kazanç ve borçlanmaya ilişkin faiz oranı modelleri artık ayrıdır; yönetişim ekonomi politikaları üzerinde tam kontrole sahiptir.


İ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:

  • Yalnızca ödünç verilen varlıklar ödünç alınabilir; teminat varlıkları olamaz.
  • Bileşik v3'te teminat getiri sağlamaz.


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:

  • Her para piyasası hazine, muhasebe ve risk yönetimi ile bireysel bir sözleşmedir
  • Her para piyasası, ödünç alınabilir varlığı tüm onaylı teminat varlık token'larıyla birlikte elinde tutar ve bu da varlıkların uygulama genelinde dağılmasına neden olur
  • Fiyat feed'leri tek harici girdidir; Borçlanma ve borç verme faiz oranları dahili olarak oluşturulur
  • Tedarik/çekme/ödünç alma/geri ödeme gibi geleneksel işlevler akıllıca birleştirildi. Artık, borç alınabilir bir varlığın para piyasasından çekilmesi borçlanma anlamına gelirken, bu varlığın sağlanması kullanıcının borcuna dayalı olarak geri ödeme veya borç verme anlamına gelir.
  • Tek bir çağrıda birden fazla işleme izin veren bir yönlendirme sözleşmesi entegre edilmiştir

Aave'nin Mimari Evrimi

Aave v1 öyleydi Ekim 2019'da piyasaya sürüldü ETHLend'in yerini aldı. Aave v1, ETHLend'in eşler arası yaklaşımı yerine ortak bir likidite havuzu sundu.

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, yönlendirici sözleşmesi aynı zamanda iş mantığını da barındırıyordu. Borç VermeHavuzuÇekirdek uygulanan muhasebe, risk yönetimi ve hazine fonksiyonları. Hazineyi tek bir sözleşmede toplamak, Bileşik v2'den farklı bir noktaydı.


Teminat kontrollerini bırakma kararı kendi sözleşmesi , yönlendiriciden çağrıldı ve muhasebe sözleşmesi zayıf görünmüyor, ancak Aave v2, v1 sürümünden yalnızca iki yıl sonra piyasaya sürüldüğü için muhtemelen amaca uygundu.

  • LendingPoolCore sözleşmesi hazine ve muhasebeyi yönetir
  • LendingPoolDataProvider teminatlandırma kontrollerini yönetir ve oracle ile etkileşime girer
  • LendingPool, kullanıcı giriş noktası görevi görür ve iş mantığını uygular
  • Borçlanma ve borç verme faiz oranları, yalnızca fiyat beslemelerine dayanarak dahili olarak belirlenir

Aave v2

Aave v2 öyleydi Aralık 2021'de yayınlandı . Aave v1'e benzer özellikleri korurken, hem Aave v1 hem de Compound v2'ye kıyasla gelişmiş ve daha basit bir mimari sundu. Bu sürümle birlikte Aave şunları da tanıttı: aJetonlar (Compound'un cToken'larına benzer) ve vTokenlar tokenleştirilmiş borcu temsil eden.

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.

  • LendingPool sözleşmesi, teminat kontrolleri gibi küresel muhasebe ve risk yönetimi işlevlerini birleştirir. Kullanıcılar için birincil erişim noktası görevi görür
  • aTokenlar teminat anlamına gelir ve borç verme pozisyonlarına benzer. Kullanıcıların teminatları aToken varlıkları aracılığıyla yansıtılır ve hazine işlevi tüm aToken'lara dağıtılır.
  • vToken'lar borç pozisyonlarını temsil etmek için kullanılır. Bir kullanıcının borcu, sahip oldukları vToken'larla temsil edilir

Aave v3

Aave v3 öyleydi Ocak 2023'te yayınlandı çoklu zincir desteği ve diğer özelliklerle. Bu eklemeler çekirdek mimariyi değiştirmez. Güncelleme aynı zamanda iyileştirilmiş risk yönetimi ve gaz verimliliğine de sahiptir.


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.

Euler'in Mimari Evrimi

Euler öyleydi Aralık 2022'de piyasaya sürüldü , izin gerektirmeyen özelliklere ve minimum yönetime sahip para piyasaları sunmayı amaçlıyor.


Tasarımının ayırt edici özelliği, elmas benzeri model. A tek bir sözleşme uygulamanın tüm depolama alanını tutar . Bu depolamaya farklı yollarla erişilebilir vekiller her biri sistemin farklı bir kavramsal öğesini yönetir.

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.

  • Depolamak Sözleşme muhasebe değişkenlerini yönetir.
  • BaseLogic sözleşme hazine görevi görmektedir.
  • Risk Yöneticisi Sözleşme, teminatlandırma kontrolleri de dahil olmak üzere risk yönetimi değişkenlerini ve işlevlerini denetler.


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 .

Çözüm

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 Calnix Bu makaleyi incelediğiniz ve düzenlediğiniz için.


Yazar, Yield Protokolünün Kurucu Ortağı ve Teknik Lideridir.