Meminjam di Ethereum: Membandingkan Evolusi Arsitektur MakerDAO, Yield, Aave, Compound, & Euler

Peminjaman adalah landasan aplikasi blockchain berbasis Ethereum. Dengan miliaran aset yang dipinjamkan, memahami cara kerja peminjaman sangatlah penting bagi pengembang, arsitek, atau peneliti.

Sama seperti evolusi paradigma pemrograman, aplikasi DeFi ini memiliki desain arsitektur yang beragam, yang mencerminkan perubahan prioritas mulai dari keamanan hingga efisiensi dan pengalaman pengguna.

Analisis ini melihat arsitektur aplikasi seperti MakerDAO, Compound, Aave, Euler, dan Yield. Kami akan menyoroti inovasi utama dan pola desain, yang merupakan pembelajaran penting untuk pengembangan aplikasi pinjaman di masa depan.

Jika Anda seorang pengembang, arsitek, atau peneliti keamanan, artikel ini cocok untuk Anda. Pada akhirnya, Anda akan dengan mudah memahami aplikasi peminjaman baru di Ethereum, memahami arsitekturnya dengan cepat dan komprehensif. Selami untuk melihat bagaimana raksasa DeFi ini dibangun dari awal.

Meminjam di DeFi

Sebagian besar pinjaman DeFi memiliki jaminan berlebihan. Seorang pengguna dapat meminjam aset tertentu jika mereka memberikan jaminan yang nilainya lebih dari pinjaman tersebut. Tidak seperti pinjaman konvensional, banyak dari pinjaman ini tidak memiliki pembayaran rutin atau tanggal akhir yang tetap. Intinya, Anda bisa meminjam dan tidak pernah membayar kembali.

Namun, ada kendalanya.

Nilai agunan harus selalu melebihi nilai pinjaman dengan margin yang telah ditentukan.

Jika nilai agunan turun di bawah ini, pinjaman dilikuidasi.

Selama likuidasi, orang lain membayar kembali sebagian atau seluruh pinjaman Anda, dan mereka menerima sebagian atau seluruh jaminan Anda sebagai imbalannya.

Semua permohonan peminjaman yang mengikuti struktur keuangan ini memerlukan landasan yang sama, yang kemudian dapat diatur dengan berbagai cara:

• Perbendaharaan untuk menyimpan jaminan pengguna dan aset pinjaman
• Sistem akuntansi yang melacak jaminan dan hutang setiap pengguna
• Fungsi yang menentukan tingkat bunga peminjam
• Sebuah mekanisme untuk memverifikasi apakah suatu pinjaman memiliki jaminan yang memadai, biasanya melibatkan peramalan harga eksternal
• Jalur likuidasi untuk pinjaman yang tidak dijaminkan
• Sistem manajemen risiko yang mencatat jumlah total pinjaman dan metrik keamanan lainnya, seperti batas pinjaman global dan per pengguna, minimum agunan, dan rasio kelebihan agunan tertentu
• Antarmuka bagi pengguna untuk menambah dan menghapus agunan, meminjam, dan membayar kembali pokoknya

Proses peminjaman di MakerDAO. Semua aplikasi berbagi langkah dan fungsi yang sama.

Pinjam meminjam dan meminjamkan dapat dianggap sebagai fitur yang terpisah. Di DeFi, kami menemukan kedua fitur tersebut di sebagian besar aplikasi peminjaman, tetapi keduanya tidak selalu terintegrasi dengan baik.

Di Compound, Aave dan Euler mereka. Suku bunga bagi peminjam dan pemberi pinjaman berkorelasi secara internal; sebenarnya, itulah yang membuat aplikasi tersebut bekerja dengan intervensi minimal.

Di sisi lain, MakerDAO dan Yield adalah pencetus aset yang mereka pinjamkan kepada peminjam.

Mereka tidak mengharuskan pengguna untuk menyediakan aset agar pengguna lain dapat meminjam.

Artikel ini akan fokus pada pinjaman on-chain dan sebagian besar mengabaikan pinjaman. Peminjaman jauh lebih rumit karena persyaratan agunan, dan memahami pola peminjaman biasanya membuka pemahaman yang lebih baik tentang keseluruhan protokol.

Evolusi Arsitektur MakerDAO

Logo PembuatDAO

MakerDAO, kuno dalam istilah Ethereum, diluncurkan dalam bentuknya yang sekarang pada bulan November 2019, dan memiliki jaminan sebesar $4,95 miliar. Meskipun memiliki arsitektur modular dengan kontrak berbeda untuk setiap fungsi dan terminologi unik, namun tetap mudah untuk dipahami dan diverifikasi.

Fungsi perbendaharaan di MakerDAO dikelola oleh kontrak Gabung .

Ada kontrak terpisah untuk setiap token yang disetujui sebagai aset jaminan.

Sebaliknya, MakerDAO tidak memiliki DAI apa pun, aset pinjaman.

Sebaliknya, ia hanya mencetak dan membakar DAI sesuai kebutuhan.

Akuntansi ditangani dalam kontrak vat.sol. Gabungan memperbarui kontrak ini ketika jaminan masuk atau keluar dari sistem. Jika pengguna meminjam, mereka berinteraksi langsung dengan kontrak vat.sol.

Tindakan ini memperbarui saldo utang pengguna dan memungkinkan mereka mencetak DAI di DAI Join.

Untuk membayarnya, pengguna membakar DAI di DAI Gabung. Proses ini kemudian memperbarui PPN, memungkinkan pengguna untuk melunasi pinjaman mereka.

Selain itu, kontrak vat.sol berfungsi sebagai mesin manajemen risiko . Ia mempertahankan batas pinjaman global, menetapkan ambang batas minimum per pengguna, dan mengawasi rasio agunan.

Ketika perubahan dilakukan pada saldo utang atau agunan pengguna, kontrak vat.sol mengevaluasi kurs dan spot.

Ini mengacu pada tingkat bunga berdasarkan agunan yang digunakan dan rasio harga DAI terhadap agunan yang berlaku. Menariknya, nilai-nilai ini dimasukkan ke dalam kontrak vat.sol oleh kontrak MakerDAO lainnya, sebuah metode yang berbeda dari kebanyakan aplikasi lainnya.

MakerDAO memprioritaskan keselamatan selama fase desainnya - saat faktor-faktor seperti biaya bahan bakar menjadi hal kedua, pengalaman pengguna tidak terlalu menjadi perhatian, dan persaingan dapat diabaikan.

Akibatnya, ini mungkin tampak unik, mahal untuk digunakan, dan sulit dinavigasi.

Namun, banyaknya aset yang dikelolanya dan catatan operasinya tanpa pelanggaran signifikan menggarisbawahi desain dan pelaksanaannya yang kuat.

Highlight:

• Setiap aset memiliki kontraknya masing-masing dalam fungsi perbendaharaan yang tersebar maksimal
• Fungsi akuntansi dipusatkan dalam satu kontrak yang juga mendokumentasikan dan menerapkan parameter risiko, termasuk pemeriksaan agunan
• Tidak seperti aplikasi lain, oracle memperbarui kontrak, mengawasi jaminan
• Oracle harga dan suku bunga menggunakan antarmuka yang berbeda
• Suku bunga berasal dari luar
• Untuk meminjam, pengguna harus berinteraksi dengan banyak kontrak

Evolusi Arsitektur Protokol Hasil

Yield v1 berfungsi sebagai bukti konsep untuk tarif tetap menggunakan YieldSpace. Versi ini membangun mesin utang yang dijaminkan di atas MakerDAO. Namun, Yield v1 mahal untuk digunakan dan sulit untuk ditambah dengan fitur-fitur baru.

Menyadari potensi YieldSpace, kami segera beralih ke pengembangan Yield v2. Masih mengambil inspirasi dari MakerDAO, tetapi sekarang sepenuhnya independen, Yield v2 diluncurkan pada Oktober 2021; Yield v2 memprioritaskan pengurangan biaya bahan bakar dan peningkatan pengalaman pengguna.

Proses peminjaman di Yield v2, sangat dipengaruhi oleh MakerDAO

Semua pemeriksaan akuntansi, manajemen risiko, dan agunan dikonsolidasikan ke dalam satu kontrak: Cauldron. Mencerminkan pendekatan MakerDAO, kami mendistribusikan fungsi perbendaharaan di seluruh kontrak Gabung , masing-masing didedikasikan untuk aset tertentu.

Kami mengubah integrasi oracle kami, menggabungkan oracle harga dan suku bunga ke dalam antarmuka umum. Kami membalikkan aliran oracle dari MakerDAO sehingga Cauldron berkonsultasi dengan oracle sesuai kebutuhan untuk pemeriksaan jaminan. Sepengetahuan saya, ini adalah aliran yang disukai di mana pun kecuali MakerDAO.

Penyimpangan signifikan lainnya dari pendekatan MakerDAO adalah pengenalan Ladle. Kontrak ini berfungsi sebagai satu-satunya perantara antara pengguna dan Yield. Ia mempunyai kendali luas atas perbendaharaan dan akuntansi, namun sebagai imbalannya, ia menawarkan fleksibilitas yang sangat besar untuk pengembangan fitur.

Singkatnya, peminjaman di Yield v2 berfungsi sebagai berikut:

• Setiap aset memiliki kontrak perbendaharaan khusus, yang memastikan distribusi fungsi perbendaharaan secara maksimal.
• Kontrak tunggal memusatkan fungsi akuntansi. Kontrak ini juga mengawasi langkah-langkah manajemen risiko dan melakukan pemeriksaan agunan.
• Fungsi agunan berkonsultasi dengan oracle untuk menentukan harga dan suku bunga.
• Oracle harga dan suku bunga berbagi antarmuka terpadu.
• Suku bunga dihasilkan secara eksternal.
• Pengguna dapat meminjam dengan membuat satu permintaan ke satu kontrak saja.

Evolusi Arsitektur Keuangan Majemuk

Versi pertama dari Compound adalah Bukti Konsep, yang menunjukkan bahwa pasar uang dapat dibangun di Ethereum. Oleh karena itu, kesederhanaan diutamakan dalam desainnya. Kontrak MoneyMarket.sol merangkum semua fungsi, termasuk peminjaman.

Proses peminjaman di Compound v1. Sederhana namun efektif.

• Tugas perbendaharaan, akuntansi, dan manajemen risiko, seperti pemeriksaan agunan, dikonsolidasikan ke dalam satu kontrak.
• Kontrak ini mengambil harga dari ramalan tetapi menentukan tingkat bunga berdasarkan pemanfaatan aset.
• Pengguna hanya berinteraksi dengan kontrak ini, meskipun mereka harus melakukan panggilan terpisah untuk memberikan jaminan dan meminjam aset.

Senyawa v2

Compound v2 diluncurkan pada Mei 2019, memicu era pertanian hasil panen dan menginspirasi banyak cabang. Ini juga berfungsi sebagai pasar uang, yang memungkinkan pengguna meminjamkan dan meminjam aset.

Berdasarkan whitepaper dan strukturnya, jelas bahwa tujuan utama Compound v2 adalah menggunakan standar ERC20 untuk mewakili posisi pinjaman. Hal ini memastikan komposisi yang memungkinkan pengguna untuk meminjamkan ke Compound dan kemudian menggunakan posisi berbunga tersebut dalam aplikasi blockchain lainnya.

Menariknya, whitepaper tersebut tidak menyoroti bahwa Compound v2 memasukkan imbalan ke dalam kontrak pintarnya. Mengingat kelalaian ini, dampak besar dari fitur ini mungkin tidak diperkirakan sebelumnya.

Proses peminjaman di Compound v2. Percobaan pertama pada posisi peminjaman yang diberi token.

• Setiap aset memiliki kontrak perbendaharaan masing-masing, yang memaksimalkan distribusi fungsi perbendaharaan.
• Fungsi akuntansi juga didistribusikan, dengan setiap cToken mencatat jaminan dan utang pengguna.
• Kontrak tunggal, Pengawas Keuangan, mencatat dan menerapkan parameter manajemen risiko, termasuk pemeriksaan agunan.
• Kontrak yang bertanggung jawab atas pemeriksaan jaminan merujuk pada ramalan untuk harga dan cToken untuk suku bunga.
• Oracle harga dan suku bunga beroperasi dengan antarmuka yang berbeda.
• Tingkat bunga berasal secara internal dari pemanfaatan aset.
• Pengguna harus berinteraksi dengan banyak kontrak untuk meminjam.

Senyawa v3

Dirilis pada tahun 2022, Compound v3 mengadopsi strategi manajemen risiko yang lebih konservatif, memisahkan likuiditas ke dalam kumpulan untuk setiap aset yang dapat dipinjam. Desain ini juga mengungkapkan kekhawatiran tentang kemudahan penggunaan dan biaya bahan bakar.

Proses peminjaman di Compound v3 (Comet). Kembali ke dasar, kembali ke keselamatan. Namun, dengan UX yang lebih baik.

Sistem ini lebih intuitif bagi pengembang dan pengguna karena pengurangan jumlah panggilan yang diperlukan. Selain itu, desain kontrak tunggal mengurangi biaya bahan bakar dengan meminimalkan panggilan antar kontrak. Pasar uang yang terpisah merupakan pertahanan terhadap serangan berbasis oracle, yang kini menjadi masalah keamanan utama.

Fitur relevan lainnya yang disebutkan dalam catatan rilis meliputi:

• Manajemen risiko dan mesin likuidasi yang sepenuhnya diperbarui. Desain ini meningkatkan keamanan dana sekaligus lebih ramah peminjam.
• Tetapkan batasan di seluruh pasar untuk aset agunan individual untuk memitigasi risiko.
• Model suku bunga untuk pendapatan dan pinjaman kini terpisah, dimana tata kelola mempunyai kendali penuh atas kebijakan ekonomi.

Menariknya, Compound v3 mencerminkan arsitektur Compound v1 dengan memiliki satu kontrak yang menangani semua fungsi untuk setiap aset yang dapat dipinjam. Fitur penting lainnya termasuk:

• Hanya aset yang dipinjamkan yang dapat dipinjam; aset jaminan tidak bisa.
• Agunan tidak menghasilkan keuntungan di Compound v3.

Larangan meminjam agunan meningkatkan keamanan bagi penyimpan agunan. Hal ini mengurangi kemungkinan kesalahan tata kelola atau serangan yang disengaja membahayakan agunan.

Menghilangkan pengembalian atas agunan yang diberikan mungkin disebabkan oleh pengelolaan Compound yang mengumpulkan banyak likuiditas di v2. Saya memiliki intuisi bahwa dalam Compound v2 batas peminjamannya berada di bawah atau tidak jauh lebih tinggi dari aset yang dipinjamkan ke aplikasi oleh pengguna.

Dengan asumsi mereka akan mengelola tingkat likuiditas yang sama untuk v3, melarang agunan untuk dipinjamkan membuat aplikasi aman, salah satu tujuan inti v3.

Dari sudut pandang arsitektur:

• Setiap pasar uang adalah kontrak individual dengan perbendaharaan, akuntansi, dan manajemen risikonya
• Setiap pasar uang mempertahankan aset yang dapat dipinjam beserta semua token aset agunan yang disetujui, menyebabkan aset tersebar ke seluruh aplikasi
• Umpan harga adalah satu-satunya masukan eksternal; suku bunga untuk pinjaman dan pinjaman dihasilkan secara internal
• Fungsi tradisional seperti pasokan/penarikan/pinjaman/pembayaran telah dikonsolidasikan dengan cerdas. Sekarang, penarikan aset yang dapat dipinjam dari pasar uang berarti peminjaman, sedangkan penyediaannya menunjukkan pembayaran kembali atau peminjaman berdasarkan utang pengguna.
• Kontrak perutean terintegrasi, memungkinkan beberapa operasi dalam satu panggilan

Evolusi Arsitektur Aave

Aave v1 diluncurkan pada Oktober 2019, menggantikan ETHLend. Alih-alih pendekatan peer-to-peer ETHLend, Aave v1 memperkenalkan kumpulan likuiditas bersama.

Proses peminjaman di Aave v1. Likuiditas yang dikumpulkan berarti efisiensi finansial dan komputasi.

Seperti pada Yield v2, kontrak router juga memiliki logika bisnis. LendingPoolCore menerapkan fungsi akuntansi, manajemen risiko, dan perbendaharaan. Menggabungkan perbendaharaan dalam satu kontrak merupakan titik pembeda dari Compound v2.

Keputusan untuk meninggalkan pemeriksaan agunan dalam kontraknya sendiri, yang dipanggil dari router dan bukan kontrak akuntansi tampaknya lemah, tetapi mungkin sesuai dengan tujuan karena Aave v2 hanya dirilis dua tahun setelah rilis v1

• Kontrak LendingPoolCore menangani perbendaharaan dan akuntansi
• LendingPoolDataProvider mengelola pemeriksaan agunan dan berinteraksi dengan oracle
• LendingPool berfungsi sebagai titik masuk pengguna dan mengimplementasikan logika bisnis
• Suku bunga untuk pinjam meminjam ditentukan secara internal, hanya mengandalkan umpan harga

Aave v2

Aave v2 dirilis pada Desember 2021. Meskipun mempertahankan fitur yang mirip dengan Aave v1, ia memperkenalkan arsitektur yang lebih baik dan lebih sederhana dibandingkan dengan Aave v1 dan Compound v2. Dengan rilis ini, Aave juga memperkenalkan aTokens (mirip dengan cTokens Compound) dan vTokens, yang mewakili hutang yang diberi token.

Aave v2 memiliki arsitektur yang sangat bersih, sepenuhnya diberi token.

Fitur tertentu dari Aave v1, yang penggunaannya terbatas, dihilangkan demi kesederhanaan. Masalah di Aave v1, seperti representasi kompleks dari bunga yang masih harus dibayar, telah diatasi di Aave v2.

• Kontrak LendingPool mengkonsolidasikan fungsi akuntansi dan manajemen risiko global, seperti pemeriksaan agunan. Ini berfungsi sebagai titik akses utama bagi pengguna
• aToken menandakan jaminan dan mirip dengan posisi pinjaman. Jaminan pengguna tercermin melalui kepemilikan aToken mereka, dan fungsi perbendaharaan didistribusikan ke seluruh aToken
• vToken digunakan untuk mewakili posisi utang. Hutang pengguna diwakili oleh vToken yang mereka miliki

Aave v3

Aave v3 dirilis pada Januari 2023 dengan dukungan multi-rantai dan fitur lainnya. Penambahan ini tidak mengubah arsitektur inti. Pembaruan ini juga menawarkan peningkatan manajemen risiko dan efisiensi gas.

Meskipun banyak kemajuan, untuk tujuan penelitian ini, Aave v3 tidak berbeda secara signifikan dari Aave v2. Faktanya, hal ini mungkin menunjukkan bahwa arsitektur Aave v2 tetap kokoh pada tahun 2023.

Evolusi Arsitektur Euler

Euler diluncurkan pada bulan Desember 2022, bertujuan untuk menawarkan pasar uang dengan fitur tanpa izin dan tata kelola minimal.

Ciri khas desainnya adalah polanya yang seperti berlian . Satu kontrak menampung seluruh penyimpanan aplikasi. Penyimpanan ini dapat diakses melalui proxy yang berbeda, masing-masing mengelola elemen konseptual sistem yang berbeda.

Meskipun satu kontrak menyimpan semua data aset, akuntansi, dan manajemen risiko, masih ada eToken untuk jaminan dan pinjaman, dan dToken untuk utang, mirip dengan Aave v2. Namun, kontrak token ini hanyalah tampilan dari kontrak penyimpanan pusat.

• Kontrak Penyimpanan mengelola variabel akuntansi.
• Kontrak BaseLogic berfungsi sebagai perbendaharaan.
• Kontrak RiskManager mengawasi variabel dan fungsi manajemen risiko, termasuk pemeriksaan agunan.

Analisis terhadap kode tersebut mengungkapkan bahwa biaya bahan bakar minimal merupakan prioritas, sehingga desain monolitik menghilangkan kebutuhan akan panggilan antar-kontrak. Keamanan terjamin melalui pengujian dan audit yang ketat. Hanya logika yang didistribusikan ke berbagai modul, yang berfungsi sebagai implementasi untuk kontrak penyimpanan, yang terutama bertindak sebagai kontrak proksi.

Desain terpadu ini juga mendukung peningkatan yang mudah. Modul dapat dengan cepat diganti untuk mengubah atau memperkenalkan fitur jika tidak diperlukan perubahan penyimpanan.

Euler diretas lima belas bulan setelah dirilis dan enam bulan setelah pemutakhiran menyebabkan kerentanan yang dieksploitasi.

Saya tidak berpikir arsitektur monolitik berperan dalam pengurasan aset; sebaliknya, pengawasan terhadap pembaruan kode tidak memadai.

Kesimpulan

Kerja keras telah selesai, mari kita tinjau apa yang telah kita pelajari

Aplikasi Ethereum awal seperti MakerDAO, Compound, dan Aave menunjukkan potensi pinjaman dengan jaminan berlebihan pada Ethereum. Setelah pembuktian konsep ini terbukti berhasil, fokusnya beralih ke pengenalan gabungan fitur-fitur baru untuk meraih pangsa pasar. Versi Compound dan Aave yang lebih baru memperkenalkan pertanian hasil, komposisi, dan kumpulan likuiditas, yang berkembang pesat terutama selama kondisi pasar bullish.

Perkembangan yang signifikan adalah pengenalan posisi pinjaman tokenized Compound v2, yang memungkinkan posisi ini diakui sebagai aset standar oleh aplikasi lain. Aave v2 dan Euler mengambil langkah lebih jauh dengan menerapkan posisi utang yang diberi token, yang kegunaannya secara lebih luas masih menjadi bahan perdebatan.

Biaya bahan bakar yang tinggi muncul sebagai kekhawatiran utama selama pasar bullish, mendorong modifikasi pengalaman pengguna seperti yang terlihat pada Yield v2, Aave v2, dan Euler. Kontrak router dan implementasi monolitik membantu mengurangi biaya yang dikeluarkan pengguna untuk bertransaksi. Namun, hal ini harus mengorbankan kode yang lebih rumit dan berisiko.

Compound v3 tampaknya menjadi preseden, memprioritaskan keselamatan daripada efisiensi finansial. Ini menyimpang dari model kumpulan likuiditas tradisional untuk memberikan perlindungan yang lebih baik terhadap potensi peretasan. Munculnya jaringan L2, dimana biaya gas menjadi semakin dapat diabaikan, kemungkinan besar akan membentuk desain permohonan pinjaman yang dijaminkan di masa depan.

Pada artikel ini, saya telah memberikan ikhtisar komprehensif tentang aplikasi pinjaman utama yang dijaminkan di Ethereum. Pendekatan yang saya gunakan untuk menganalisis setiap permohonan juga dapat diterapkan untuk memahami seluk-beluk permohonan pinjaman agunan lainnya dengan cepat.

Saat mengembangkan aplikasi peminjaman blockchain, selalu pertimbangkan penyimpanan aset, penempatan catatan akuntansi, dan metode evaluasi risiko dan agunan. Saat Anda memikirkan pertimbangan-pertimbangan ini, manfaatkan riwayat permohonan sebelumnya dan wawasan dari ikhtisar ini untuk menginformasikan keputusan Anda.

Terima kasih telah membaca, dan semoga sukses.

Terima kasih kepada Calnix yang telah meninjau dan mengedit artikel ini.

Penafian:

1. Artikel ini dicetak ulang dari [hackernoon]. Semua hak cipta milik penulis asli [alcueca]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.