Khám phá DeFi Lending: Thành phần, công thức và trường hợp sử dụng

Tiêu đề gốc: "Khái niệm cho vay DeFi Phần 1: Cho vay và vay"

Tác giả gốc: Tal

Bản tổng hợp gốc: Kxp, BlockBeats

Bài viết này là bài viết đầu tiên trong loạt bài gồm ba phần thảo luận về cách hoạt động của các giao thức cho vay DeFi – các thành phần chính, công thức và trường hợp sử dụng của chúng. Trong phần này, chúng tôi sẽ nhấn mạnh rằng mặc dù các giao thức sử dụng danh pháp khác nhau và sáng tạo nhưng chúng có xu hướng lặp lại, lặp lại và chia sẻ các khái niệm cốt lõi. Một trong những bài đăng trên blog này nêu chi tiết cách sử dụng Mã thông báo ERC20 để thể hiện phần chia sẻ của người dùng trong nhóm cho vay. Chúng tôi sẽ bắt đầu bằng cách phân tích các yếu tố độc đáo của các giao thức này và cung cấp các khái niệm kỹ thuật để phân biệt cách chúng hoạt động.

Nhóm cho vay

Trong tài chính truyền thống (hoặc TradFi), việc cho vay được thực hiện bởi bên thứ ba tài chính của đảng Tổ chức điều chỉnh. Các tổ chức tài chính này được giao hai nhiệm vụ trọng tâm: buộc người đi vay phải trả lãi cho người cho vay và đánh giá, ngăn chặn các bên được coi là không đáng tin cậy tham gia vào các hoạt động này.

Ngược lại, trong tài chính phi tập trung (hoặc DeFi), người đi vay và người cho vay bên thứ ba không đáng tin cậy. Sự thiếu tin tưởng này đã truyền cảm hứng cho một thiết kế sáng tạo nhằm tạo điều kiện thuận lợi cho quá trình cho vay trực tuyến.

Nhóm cho vay là một hợp đồng thông minh. Người dùng giao thức DeFi có thể gửi một tài sản (thường là Mã thông báo ERC20) với mục đích sử dụng hợp đồng để cho vay tài sản mà họ đã gửi. Những người dùng khác có thể tương tác với nhóm cho vay và tận hưởng các khoản vay tức thời, tức là vay bằng tài sản trong nhóm.

Các nhóm cho vay có một số lợi thế đáng kể khi cho vay so với các phương thức tài chính truyền thống, chẳng hạn như:

· Trong DeFi, các khoản vay không bị giới hạn bởi khả năng sẵn có 1:1 của vốn vay và số tiền đã vay. Thay vào đó, tiền từ tất cả người dùng giao thức sẽ được gửi vào nhóm, tạo ra một lượng token tồn kho đủ lớn để đáp ứng nhu cầu vay ngay lập tức.

· DeFi không yêu cầu kế hoạch trả nợ. Các khoản vay được thực hiện dựa trên tài sản thế chấp đã ký gửi trước đó và người dùng có thể chọn trả nợ bất kỳ lúc nào.

Tại thời điểm này, bạn có thể nghĩ: “Nếu tôi phải cung cấp một tài sản có giá trị tương đương (hoặc thậm chí được định giá quá cao) để thế chấp thì tại sao lại phải ký hợp đồng cho vay? Tài sản đi vay có nên bán tài sản thế chấp để mua tài sản đi vay không?”

Trên thực tế, giao thức cho vay DeFi này dường như chỉ cho phép các khoản vay được thế chấp hoàn toàn (hoặc được thế chấp quá mức), mở ra cơ hội cho một phương thức "giao dịch" thú vị: đòn bẩy.

Giả sử bạn rất lạc quan về WBTC và khá chắc chắn rằng giá trị của nó sẽ tăng vọt! Bạn có thể gửi một số WBTC (trị giá 1000 USD) vào giao thức cho vay yêu thích của mình, sau đó sử dụng số tiền đó để vay một số stablecoin (ví dụ: USDC), sau đó sử dụng các stablecoin đó để mua thêm WBTC trên một sàn giao dịch (Đối với kịch bản của chúng tôi, giả sử một nửa số tiền gửi ban đầu của bạn, tức là 500 USD). Trong trường hợp này, khoản đầu tư WBTC của bạn trị giá 1500 USD và khoản tiền gửi ban đầu của bạn chỉ là 1000 USD.

Nhưng điều gì sẽ xảy ra nếu bạn gửi 500 USD tài sản thế chấp WBTC của mình vào giao thức để vay thêm USDC? Quá trình này được gọi là đòn bẩy quá mức và bạn có thể thực hiện việc này cho đến khi vượt quá khả năng vay của mình và các chính sách của giao thức ngăn cản bạn làm như vậy.

Trong tình huống tương tự, giả sử bạn bi quan về WBTC (dù sao thì đây cũng là mùa đông của tiền điện tử). Bạn có thể làm ngược lại với kịch bản trước đó của chúng tôi và gửi USDC làm tài sản thế chấp vào giao thức để vay WBTC, sau đó đổi ngay lấy thêm stablecoin. Nếu dự đoán của bạn trở thành sự thật và giá WBTC giảm, bạn có thể mở (và đóng) một vị thế bán WBTC bằng cách mua cùng một lượng WBTC với giá rẻ hơn trên sàn giao dịch, hoàn trả khoản vay và thu được số USDC dư thừa.

Mã thông báo chia sẻ

Tương tự như tài chính truyền thống, người dùng gửi tài sản vào nhóm cho vay sẽ Được khuyến khích giữ tiền của bạn trong thời gian dài và kiếm lãi từ khoản tiền gửi của bạn. Tiền lãi tích lũy theo thời gian và được tính bằng phần trăm số tiền gửi của người dùng trong giao thức và được khai báo bởi người dùng gửi tiền tương ứng. Người dùng giữ tài sản của họ trong nhóm cho vay càng lâu thì họ càng kiếm được nhiều tiền lãi.

Giao thức ghi lại phần chia sẻ của mỗi người dùng trong nhóm như thế nào? Khi người dùng gửi tài sản vào nhóm, "chia sẻ" của họ sẽ làm loãng cổ phần của tất cả người dùng và giao thức sẽ phản ánh điều này tương ứng. Tuy nhiên, thay vì trực tiếp theo dõi và cập nhật cổ phần của từng người dùng, giao thức chỉ xử lý các thay đổi về cổ phiếu của người gửi mà không chủ động cập nhật cổ phiếu của người dùng khác mỗi khi họ rút hoặc gửi tiền.

Bạn có thể nghĩ rằng thỏa thuận này cho phép bạn có được chiếc bánh của mình và ăn nó. Nhưng thực tế không phải như vậy:

Giao thức xử lý việc phát hành lãi bằng cách đúc và hủy Mã thông báo ERC20, mà chúng tôi gọi là "Mã thông báo chia sẻ", đại diện cho nhóm cho vay Phần của người cho vay (hoặc tỷ lệ tài sản tiền gửi) trong khoản vay. Thiết kế "mã thông báo chia sẻ" này tự động điều chỉnh mức độ pha loãng cổ phiếu của các "cổ đông" khác để phản ánh việc đúc và đốt "cổ phiếu" tương ứng với việc gửi hoặc rút tài sản cơ bản của họ.

Dưới đây, chúng tôi sẽ cung cấp các ví dụ thực tế về cách các giao thức khác nhau sử dụng "mã thông báo chia sẻ" và thảo luận về những điểm tương đồng của chúng.

aToken: “Mã thông báo chia sẻ” của AAVE

aToken là mã thông báo tạo doanh thu của AAVE. bị phá hủy bởi các nhóm cho vay khi tài sản được gửi và rút ra.

aToken là một Token giống ERC20 được tích hợp vào giao thức AAVE, do đó, có một loại Token tương ứng cho từng thị trường khác nhau mà người dùng có thể nhập (để gửi tài sản thế chấp) aToken.

Nếu nhìn vào hợp đồng nhóm cho vay AAVE, chúng ta có thể thấy các hoạt động cơ bản xảy ra khi người dùng gửi tài sản vào nhóm:

Chúng ta có thể thấy rằng thị trường tương ứng với số tiền gửi của người dùng aToken sẽ được gọi trong chức năng "truyền".

Chúng ta có thể thấy, số lượng thực tế được đúc là:

Như được hiển thị trong hình trên, trong ví dụ này, người dùng tham gia vào một thị trường đã kiếm được một số tiền lãi từ khoản tiền gửi trước đó. Phương trình trên giúp chúng ta hiểu điều này vì nó cho thấy cách tính lãi tích lũy cho tất cả người dùng bằng cách sử dụng chỉ số chung được cập nhật theo các hoạt động khác nhau (gửi tiền, rút tiền, v.v.).

Khi người dùng rút tài sản cơ bản của họ, chỉ số thanh khoản sẽ được sử dụng làm hệ số nhân để tính số lượng Token còn nợ trong giao dịch.

Sau đây là đoạn mã có liên quan từ hợp đồng nhóm cho vay:

Ở đây, chức năng BalanceOf của hợp đồng aToken hơi lạ. Rốt cuộc, chúng tôi vừa xác định rằng số lượng aToken được đúc không giống với số lượng tài sản cơ bản được gửi. Việc gọi IAToken(aToken).balanceOf(address(user)) tạo ra số lượng tài sản cơ bản mà người dùng sắp rút như thế nào (như hiển thị ở cuối hàm)? Đây là lý do:

· Khi người dùng rút tài sản của họ, aTokens của họ sẽ bị hủy. Các aToken bị đốt này giữ tổng số aToken mà người dùng khác sở hữu tỷ lệ thuận với phần chia của họ sau khi tài sản của người dùng bị rút.

· Lãi suất thị trường dành cho người dùng rút tiền sẽ được cập nhật sau mỗi lần rút tiền.

Như chúng tôi đã trình bày trước đó, aToken là một Token tương tự như ERC20. Chúng tôi nhấn mạnh rằng chúng "tương tự" với Mã thông báo ERC20 vì các hàm BalanceOf của chúng có các thuộc tính duy nhất. Trong Mã thông báo ERC20 thông thường, hàm BalanceOf trả về số lượng Mã thông báo mà một địa chỉ sở hữu.

Vì aToken đại diện cho một phần của nhóm chứ không phải là giá trị trực tiếp nên hàm BalanceOf của aToken trả về số lượng Token cơ bản mà giao thức nợ người dùng để gửi tiền . đền bù.

Ở đây, hàm BalanceOf sẽ ghi đè hàm BalanceOf trong hợp đồng aToken được kế thừa. Kết quả là, logic BalanceOf trong logic ví dụ này được thực thi thay vì tra cứu ánh xạ (kế thừa) thông thường số mã thông báo của người dùng.

Số lượng Token được đề cập ở trên sau đó được nhân với kết quả của getReserveNormalizedIncome. Hàm này thực hiện logic sau:

Chúng ta có thể xác định các nhánh ở đây:

· Nếu dữ liệu giữ lại đã được cập nhật trong khối này: Trả về giá trị chỉ số thanh khoản cho thị trường này khi nó được cập nhật.

·  Mặt khác: chúng ta cần xem điều gì xảy ra trong CalculateLinearInterest để tìm ra quy trình tiếp theo.

Trong đối tượng ReserveData của thị trường hiện tại CurrentLiquidityRate và LastUpdateTimestamp được chuyển vào hàm này và kết quả của hàm này là:

Hãy chia nhỏ các thành phần của phương trình này để hiểu rõ hơn ý chính của giá trị LinearInterest: 

· currentLiquidityRate: Hãy coi đó là tỷ lệ phần trăm hàng năm (APY) của thị trường của chúng tôi

· block_{timestamp} - LastUpdatedTimestamp: từ phía trên Thời gian đã trôi qua kể từ lần cập nhật cuối cùng

Lưu ý: Vì chúng tôi đã chọn nhánh thứ hai trong getNormalizedIncome nên đây Giá trị này được đảm bảo là dương.

Do đó, chúng ta có thể coi cơ chế tích lũy lãi suất này như một cơ chế lãi kép đơn giản được gộp trong mỗi khối. Bây giờ chúng ta đã xác định được số tiền lãi sẽ tích lũy cho người dùng, chúng ta chỉ cần nhân giá trị đó với chỉ số thanh khoản rồi nhân thu nhập chuẩn hóa của người dùng trong hàm BalanceOf:

Bây giờ chúng ta đã hiểu logic đằng sau aToken, nhưng chúng ta vẫn cần tính toán chỉ số thanh khoản Bí ẩn của nguyên tắc.

Trong ví dụ sau, chỉ số thanh khoản có thể được định nghĩa là tiền lãi tích lũy từ khoản dự trữ trong một khoảng thời gian nhất định:

Nhắc lại biến LiquidityRate được đề cập trước đó - bây giờ chúng ta sẽ thảo luận về việc sử dụng nó trong việc tính toán chỉ số thanh khoản Tiền lãi sẽ chỉ tích lũy nếu LiquidityRate lớn hơn 0 - nói cách khác, tiền lãi sẽ chỉ tích lũy nếu có bất kỳ APY nào trên thị trường đó. Điều này thật ý nghĩa.

Hãy nhanh chóng xem lại tính toánLinearInterest hoạt động:

Logic trên có thể được chuyển thành phương trình sau:

Như chúng ta có thể thấy trong hợp đồng DefaultReserveInterestRateStrategy.sol, LiquidityRate được xác định theo cách sau:

Do đó, nó có thể được viết là:

Tỷ lệ vay tổng thể (tổng thểBorrowRate) được xác định ở đây là:

Chúng ta có thể viết nó dưới dạng :

Sử dụng Tỷ lệ sử dụng có thể được định nghĩa là:

Khi xác định mức sử dụng, sẽ dễ dàng hơn khi xem xét tỷ lệ giữa tính thanh khoản dự trữ (thanh khoản hiện đang cho vay) và tổng thanh khoản trên thị trường, có thể đơn giản hóa thành:

Bây giờ chúng ta có thể sử dụng hai định nghĩa này để viết Phương trình chỉ số thanh khoản:

Vì TotalBorrows tồn tại ở cả tử số và mẫu số, chúng ta có thể viết:

Bây giờ đã nói đủ về phương trình chỉ số thanh khoản, chúng ta sẽ quay lại định nghĩa này sau.

cToken: “share token” của Hợp chất

Hãy chuyển sang thỏa thuận cho vay tiếp theo của chúng ta Ví dụ , Hợp chất.

Compound sử dụng "mã thông báo chia sẻ" được gọi là cTokens để xử lý việc vay và cho vay. Mã thông báo này chiếm tất cả tài sản trong giao thức Hợp chất có thể được sử dụng để cho người dùng vay.

Tương tự như những gì chúng ta đã thảo luận trong AAVE V2, “mã thông báo chia sẻ” của Hợp chất được đúc và sử dụng để mua lại các tài sản cơ bản.

Compound sử dụng tỷ giá hối đoái tương tự như Chỉ số thanh khoản của AAVE V2 để xác định số lượng cToken cần được đúc. Tỷ giá hối đoái là một hàm như sau:

Hãy để tôi giải thích các thuật ngữ chính ở đây:

·totalCash: mã thông báo cơ sở ERC20 do cToken sở hữu số lượng tài khoản.  

· totalBorrows: Số lượng Token cơ bản ERC20 mà người vay cho vay trên thị trường.  

· totalReserves: Một số lượng token cơ bản ERC20 dành riêng nhất định có thể được trích xuất hoặc chuyển giao thông qua quản trị.  

· totalSupply: Hàm ERC20 trả về tổng nguồn cung cToken.

Với nền tảng này, chúng ta có thể viết phương trình tỷ giá hối đoái của Hợp chất:

Khi người dùng gửi tiền cho ERC20 Token, tỷ giá hối đoái xác định số lượng cToken sẽ được tạo ra để đổi lại:

Số lượng cToken được tạo ra được xác định theo phương trình sau:

eToken: “Share Token” của Euler

Để tiếp tục phát triển củng cố mối quan hệ giữa các thỏa thuận này Với những điểm tương đồng, hãy phân tích một giao thức cho vay khác, Euler, và xem nó xử lý việc vay và cho vay như thế nào.

Trong ví dụ bên dưới, chức năng gửi tiền cho phép người dùng gửi Token ERC20 để đổi lấy eTokens.

Như chúng ta có thể thấy, InternalAmount là số lượng eToken được đúc cho lần chuyển này.

Với tên của Hợp chất và The chức năng ExchangeRate lại chồng chéo trực tiếp.

Hãy để tôi giải thích Các thông số chính được sử dụng để tính tỷ giá hối đoái:

· poolSize: Trong hợp đồng ERC20 sử dụng tài sản cơ bản, hãy gọi nó bằng pool địa chỉ hợp đồng Kết quả của hàm BalanceOf(address).

· totalBorrows: Tổng số lượng token cơ bản ERC20 được cho vay, hiện không có trong nhóm.

· tổng số dư: Tổng số dư của tất cả chủ sở hữu eToken.

Do đó, phương trình sẽ là:

Tóm tắt

Chúng tôi đã bao gồm 3 giao thức cho vay: 

· AAVE V2 

·  ; Hợp chất 

· Euler

Chúng tôi đã kiểm tra cách tạo ra "mã thông báo chia sẻ" và cách chúng được trao đổi thông qua nhóm cho vay Tiền gửi tài sản.

Ba phương trình chúng tôi đề xuất có thể được rút gọn thành một phương trình đơn giản:

Hãy nhớ rằng tỷ giá hối đoái có thể được xác định theo bất kỳ cách nào được xác định bởi giao thức. Các tỷ giá hối đoái tùy ý này có thể tăng số lượng token được đúc (nếu nhỏ hơn 1) hoặc giảm số lượng nếu lớn hơn 1.

Trong AAVE V2 và Hợp chất, chúng tôi đã thấy một số điểm tương đồng với biến someRate. Trong Hợp chất, someRate là:

Và đối với AAVE V2, định nghĩa của someRate Như sau:

Định nghĩa chỉ số thanh khoản là:

Mặc dù chúng tôi không thể gộp tỷ giá hối đoái của từng giao thức thành một công thức, nhưng đối với AAVE2 và Hợp chất, chúng tôi biết rằng tỷ giá hối đoái là một hàm của tổng thanh khoản trên thị trường. Quay lại phương trình của chúng ta, vì TotalLiquidity là tổng số lượng token cơ sở ERC20 trên thị trường, khi đó tử số trong biểu thức ExchangeRate có chức năng giống như tử số trong mẫu số của LiquidityRate.

Tóm lại: các giao thức này về cơ bản là tương tự nhau. Mặc dù đôi khi chúng có thể sử dụng các thuật ngữ khác nhau nhưng khi chia thành các phương trình, mỗi thành phần đều có mục đích triển khai tương tự. Chúng tôi mời độc giả chọn ngẫu nhiên một giao thức cho vay và kiểm tra xem liệu các quy nạp mà chúng tôi thảo luận ở đây cũng áp dụng cho giao thức đó hay không. Xin vui lòng cho chúng tôi biết nếu điều này áp dụng.

Liên kết gốc 

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia