Giải thích toàn diện về cho vay DeFi: thành phần, công thức, trường hợp sử dụng

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

Tác giả gốc: Tal

Biên soạn gốc: Kxp, Blockbeats

tiêu đề cấp đầu tiên

nhóm cho vay

Trong tài chính truyền thống (hoặc TradFi), việc vay và cho vay được điều phối bởi các tổ chức tài chính bên thứ ba. Các tổ chức tài chính này được giao hai nhiệm vụ chính: thực thi các khoản thanh toán lãi từ người vay cho người cho vay, đồng thời đánh giá và 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 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 để tạo điều kiện thuận lợi cho quy 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ể ký gửi tài sản (thường là Mã thông báo ERC 20) với mục đích sử dụng hợp đồng để cho vay tài sản ký gửi của họ. 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 ngay lập tức, tức là thế chấp tài sản trong nhóm để vay.

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, việc cho vay không bị giới hạn bởi tỷ lệ 1:1 khả dụng của các khoản vay và số tiền vay. Thay vào đó, tiền từ tất cả người dùng của giao thức được gộp lại, tạo ra kho lưu trữ mã thông báo đủ lớn để đáp ứng nhu cầu cho 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 đối với tài sản thế chấp đã gửi trước đó và người dùng có thể chọn hoàn trả bất cứ lúc nào.

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

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 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 đô la) trên 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ố 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, là $500). Trong trường hợp này, mức độ tiếp xúc với WBTC của bạn trị giá 1500 đô la và khoản tiền gửi ban đầu của bạn chỉ là 1000 đô la.

Nhưng điều gì sẽ xảy ra nếu bạn gửi 500 đô la 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à sử dụng đòn bẩy quá mức và bạn có thể tiếp tục thực hiện việc này cho đến khi bạn vượt quá khả năng vay của mình và chính sách của giao thức ngăn cản bạn làm như vậy.

tiêu đề cấp đầu tiên

chia sẻ mã thông báo

Cũng giống 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 được khuyến khích giữ tiền lâu dài và kiếm lãi từ tiền gửi của họ. Tiền lãi tích lũy theo thời gian, được tính bằng tỷ lệ phần trăm của khoản tiền gửi của người dùng trong giao thức và được xác nhận bởi người dùng tiền gửi tương ứng của họ. Người dùng giữ tài sản 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 theo dõi chia sẻ của từng 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, "phần" của họ sẽ pha loãng phần chia sẻ 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 nhóm của từng người dùng, giao thức chỉ xử lý các thay đổi đối với cổ phần của người gửi tiền mà không chủ động cập nhật cổ phần của người dùng khác mỗi khi họ rút tiền 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ó chiếc bánh của mình và ăn nó. Nhưng nó không thực sự trông như thế này:

Giao thức xử lý các khoản thanh toán lãi bằng cách đúc và đốt các mã thông báo ERC 20 mà chúng tôi gọi là "mã thông báo chia sẻ", đại diện cho phần của người cho vay (hoặc tỷ lệ tài sản tiền gửi) trong nhóm cho vay. Thiết kế "Mã thông báo chia sẻ" này tự động điều chỉnh để pha loãng cổ phần của "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ọ.

tiêu đề cấp đầu tiên

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

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

aToken là một mã thông báo giống như ERC 20 được tích hợp vào giao thức AAVE, do đó, mỗi thị trường khác nhau mà người dùng có thể truy cập (tài sản thế chấp ký gửi) đều có một mã thông báo tương ứng.

Nếu chúng ta xem xét 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 aToken tương ứng với thị trường mà người dùng đã gửi sẽ được gọi trong chức năng "đúc tiền".

Chúng ta có thể thấy rằng số tiền thực tế được đúc là:

Như thể hiện trong hình trên, trong ví dụ này, người dùng tham gia thị trường đã kiếm được một số tiền lãi từ các 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 hạch toán tiền lãi tích lũy cho tất cả người dùng bằng cách sử dụng chỉ mục toàn cầu, chỉ số này được cập nhật trên 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 toán số lượng token nợ trong giao dịch.

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

Ở đây, hàm balanceOf của hợp đồng aToken hơi lạ. Rốt cuộc, chúng tôi chỉ 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 ký gửi. Làm cách nào để gọi IAToken(aToken).balanceOf(address(user)) mang lại số lượng tài sản cơ bản mà người dùng sắp rút (như được hiển thị ở cuối hàm)? Những lý do như sau:

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

· Tỷ giá thị trường để người dùng rút tiền sẽ được cập nhật với mỗi lần rút tiền.

Như chúng tôi đã nêu trước đó, aToken là mã thông báo giống như ERC 20. Chúng tôi nhấn mạnh rằng chúng "tương tự" với mã thông báo ERC 20 vì chức năng balanceOf của chúng có các thuộc tính độc đáo. Trong Mã thông báo ERC 20 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à một giá trị ngay lập tức, nên hàm balanceOf của aToken trả về số lượng Mã thông báo cơ sở mà giao thức nợ người dùng để bù đắp cho khoản tiền gửi của họ.

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

Số lượng Mã thông báo được đề cập ở trên sau đó được nhân với kết quả của getReserveNormalizedIncome, thực hiện logic sau:

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

· Nếu dữ liệu dành riêng đã được cập nhật trong khối này: trả về giá trị chỉ số thanh khoản của 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 tính toánLinearInterest để tìm ra quy trình tiếp theo.

currentLiquidityRate và lastUpdateTimestamp từ đối tượng ReserveData của thị trường hiện tại được chuyển vào hàm này và kết quả của hàm 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:

Tỷ lệ thanh khoản hiện tại: Hãy coi đây là lãi suất hàng năm (APY) cho thị trường của chúng ta

block_{timestamp} - lastUpdatedTimestamp: 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 giá trị được đảm bảo là dương tại thời điểm này.

Do đó, chúng ta có thể coi cơ chế tích lũy lãi này như một cơ chế gộp lãi đơn giản, được gộp trong mỗi khối. Bây giờ chúng ta đã xác định số tiền lãi 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 và sau đó thực hiện phép 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, chúng ta vẫn cần giải đáp bí ẩn về cách thức hoạt động của chỉ số thanh khoản.

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

Nhớ lại biến số thanh khoản đã đề 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 Tỷ lệ thanh khoản 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 trong thị trường đó. Nó có ý nghĩa.

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

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

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

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

Tỷ lệ vay chung (overallBorrowRate) được định nghĩa ở đây là:

Chúng ta có thể viết điều này như sau:

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

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

Bây giờ chúng ta có thể viết phương trình cho chỉ số thanh khoản bằng hai định nghĩa sau:

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

tiêu đề cấp đầu tiên

cToken: "Mã thông báo chia sẻ" của Compound

Hãy chuyển sang ví dụ về giao thức cho vay tiếp theo của chúng tôi, Compound.

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

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 Compound được đúc và sử dụng để mua lại tài sản cơ bản.

Hợp chất 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 sẽ được đúc. Tỷ giá hối đoái là một chức năng như thế này:

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

·totalCash: Số lượng Mã thông báo cơ bản ERC 20 thuộc sở hữu của tài khoản cToken.

· TotalBorrows: Số lượng mã thông báo cơ bản ERC 20 trên thị trường được người vay mượn.

· TotalReserves: Dự trữ một số lượng nhất định mã thông báo cơ bản ERC 20, có thể được trích xuất hoặc chuyển giao thông qua quản trị.

· TotalSupply: Một hàm ERC 20 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 Compound:

Khi người dùng gửi Mã thông báo ERC 20, tỷ giá hối đoái sẽ xác định số lượng cToken sẽ được đúc để đổi lại:

tiêu đề cấp đầu tiên

eToken: "Mã thông báo chia sẻ" của Euler

Để củng cố thêm những điểm tương đồng giữa các giao thức này, hãy cùng phân tích một giao thức cho vay khác, Euler và xem cách nó xử lý hoạt động cho vay.

Trong ví dụ bên dưới, chức năng gửi tiền cho phép người dùng gửi Mã thông báo ERC 20 để đổi lấy Mã thông báo điện tử.

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

Một lần nữa, có sự trùng lặp trực tiếp với tên và hàm ExchangeRate của Hợp chất.

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

· poolSize: Trong hợp đồng ERC 20 sử dụng nội dung cơ bản, kết quả của việc gọi hàm balanceOf(address) với địa chỉ hợp đồng nhóm.

· TotalBorrows: Tổng số lượng ERC 20 mã thông báo cơ bản được cho vay, hiện không có trong nhóm.

· TotalBalances: Tổng số dư của tất cả những người nắm giữ eToken.

tóm tắt

tóm tắt

Chúng tôi đã đề cập đến 3 giao thức cho vay:

· AAVE V2 

· Compound 

· Euler

Chúng tôi đã xem xét cách đúc “Mã thông báo chia sẻ” và cách chúng được trao đổi để lấy tài sản tiền gửi thông qua nhóm cho vay.

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 mà giao thức xác định. Các tỷ giá hối đoái tùy ý này có thể tăng số lượng mã thông báo được đúc (nếu nhỏ hơn 1) và giảm số lượng nếu lớn hơn 1.

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

Đối với AAVE V2, someRate được định nghĩa như sau:

Chỉ số thanh khoản được định nghĩa là:

Mặc dù chúng tôi không thể khái quát tỷ giá hối đoái của từng giao thức thành một công thức duy nhất, nhưng đối với AAVE 2 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 trở lại phương trình của chúng tôi, với điều kiện TotalLiquidity là tổng số lượng mã thông báo cơ sở ERC 20 trên thị trường, thì tử số trong biểu thức ExchangeRate và mẫu số trong biểu thức LiquidRate giống hệt nhau về mặt chức năng.

liên kết gốc

liên kết gốc