Giới thiệu ngắn gọn về thiết kế kiến trúc ứng dụng DeFi

星球君

Odaily资深编辑

2022-01-09 12:00

Bài viết này có khoảng 4280 từ, đọc toàn bộ bài viết mất khoảng 7 phút

Dựa trên bản tóm tắt kinh nghiệm của tác giả, hãy nói về cách anh ấy hiểu về thiết kế kiến trúc ứng dụng DeFi.

chữ

tiêu đề phụ

lời tựa

Sự khác biệt giữa ứng dụng DeFi và ứng dụng truyền thống là khá lớn, mô hình kinh doanh khác nhau, mô hình sản phẩm cũng khác nhau và thậm chí cả kho công nghệ được triển khai cũng rất khác nhau. Nói chung, các ứng dụng truyền thống còn được gọi là ứng dụng Web2, trong khi các ứng dụng DeFi có thể được phân loại là Web3.

Thay vì nói về mô hình kinh doanh và mô hình sản phẩm, chúng ta chỉ nói về ngăn xếp công nghệ. Các ngăn xếp công nghệ hiện đang tham gia vào các ứng dụng DeFi chủ yếu bao gồm: Solidity, Subgraph, Price Oracle, Hardhat, Ethers, v.v. Hầu hết các ngăn xếp công nghệ này thậm chí còn chưa được một số người chơi lớn ở cấp P9 trong các công ty Internet lớn như Ali, Tencent và Byte nghe đến. Kiến trúc microservice phổ biến, kiến trúc dữ liệu lớn và kiến trúc dựa trên đám mây trong các kiến trúc ứng dụng truyền thống về cơ bản là vô dụng trong các ứng dụng DeFi.

Tôi đã nghiên cứu về blockchain từ giữa năm 2017. Sau vài năm chuyên sâu trong ngành này, tôi đã thực hiện một số ứng dụng DeFi và cuối cùng tôi đã có một số nền tảng. Dựa trên kinh nghiệm của tôi, hãy để tôi nói về cách tôi hiểu về thiết kế kiến trúc của các ứng dụng DeFi.

tiêu đề phụ

Cấu trúc tổng thể

Hãy cùng xem kiến trúc chung của hệ thống ứng dụng DeFi:

Hãy để tôi giới thiệu từng mô-đun tiếp theo:
Blockchain: mạng blockchain cơ bản, một ứng dụng DeFi thường được triển khai cho nhiều mạng blockchain khác nhau
Hợp đồng thông minh: Hợp đồng thông minh là hoạt động kinh doanh cốt lõi của các ứng dụng DeFi và cũng là linh hồn
Price Oracle: tiên tri giá, được sử dụng để cung cấp thông tin về giá, thường có thể được chia thành tiên tri ngoài chuỗi và tiên tri trên chuỗi
Keeper Services: Trình kích hoạt tác vụ và trình thực thi hợp đồng thông minh, vì bản thân hợp đồng thông minh không có khả năng tự động kích hoạt tác vụ thực thi nên cần có trình kích hoạt tác vụ bên ngoài để hỗ trợ.
Đồ thị con: Đồ thị con, còn được gọi là bộ chỉ mục, chủ yếu tập hợp lại dữ liệu trên chuỗi thành dữ liệu thuận tiện cho các truy vấn phía trước
Graph Node: Môi trường mà Subgraph chạy sẽ đồng bộ dữ liệu khối trên chain về Subgraph để xử lý
Wallet: ứng dụng ví, chủ đạo nhất là MetaMask
WebUI: Trang giao diện người dùng được hiển thị ở giao diện người dùng, thường sử dụng các khung giao diện người dùng như Vue và React

SDK: Đóng gói truy vấn của Subgraph, lệnh gọi của hợp đồng thông minh, kết nối của ví, v.v., để tạo điều kiện thuận lợi cho lệnh gọi của giao diện người dùng phía trước

Tôi tin rằng nhiều người sẽ thắc mắc: tại sao một hệ thống ứng dụng DeFi lại có nhiều thành phần khác nhau như vậy?

Đầu tiên, bản thân hợp đồng thông minh thiếu cơ chế thực thi tự động. Vì các ứng dụng Web2 có bộ hẹn giờ nên nhiều tác vụ có thể được thực thi tự động với bộ hẹn giờ. Tuy nhiên, hợp đồng thông minh không có bộ đếm thời gian nên một số tác vụ không thể được thực thi tự động và cần có một chương trình bên ngoài để kích hoạt việc thực thi các tác vụ này. Một chương trình bên ngoài như vậy được gọi là Keeper.Ví dụ: bộ thanh lý thực hiện nhiệm vụ thanh lý Hợp chất là một loại Keeper.

Hầu hết Keepers là các chương trình tập trung ngoài chuỗi. Trong năm qua, một số mạng Keeper phi tập trung đã lần lượt xuất hiện, những mạng mà tôi biết bao gồm keep3r.network, Chainlink Keepers và KeeperDAO.

Thứ hai, cũng do những hạn chế của chính hợp đồng thông minh, không thể chủ động khởi tạo yêu cầu mạng tới một chương trình bên ngoài để lấy dữ liệu như ứng dụng Web2. Mặt khác, nếu hợp đồng thông minh có thể gửi yêu cầu mạng đến các sàn giao dịch tập trung như Coinbase và Binance để lấy dữ liệu về giá, thì các nút khác nhau sẽ không thể đạt được sự đồng thuận do thời gian yêu cầu khác nhau và giá thu được khác nhau. Nhưng các hợp đồng thông minh cần phải có được thông tin về giá, do đó, có một Price Oracle.

Giá Oracle chủ yếu có thể được chia thành hai loại: oracle ngoài chuỗi và oracle trên chuỗi.

Nhà tiên tri ngoài chuỗi được đại diện bởi Chainlink. trực tiếp đọc thông tin về giá của các hợp đồng thông minh trên chuỗi.Tiên tri trên chuỗi dựa trên TWAP của Uniswap (giá trung bình theo thời gian), nguyên tắc mà tôi đã đề cập trong bài viết trước"Phân tích Uniswap cho các sản phẩm giao dịch DeFi: Phần 2 của V2"

Nó đã được thảo luận, vì vậy tôi sẽ không lặp lại nó.

Ngoài ra, dữ liệu được lưu trữ trong hợp đồng thông minh hoàn toàn khác với cơ sở dữ liệu Web2 truyền thống, không thể lập chỉ mục và truy vấn dữ liệu như cơ sở dữ liệu MySQL và MongoDB, cũng như không thể nhóm, sắp xếp hoặc kết hợp dữ liệu. Và nhu cầu này cũng là một nhu cầu cứng nhắc, để đáp ứng nhu cầu này, The Graph, một giao thức chỉ số dữ liệu blockchain đã xuất hiện. Subgraph là thành phần cốt lõi của giao thức và Graph Node là môi trường hoạt động của nó.

Cụ thể đối với từng ứng dụng DeFi khác nhau, kiến trúc thực tế có thể khác một chút, chẳng hạn như Uniswap không yêu cầu Keeper Services hoặc Price Oracle. Nhưng hầu hết các ứng dụng DeFi phức tạp hơn một chút về cơ bản đều cần những thành phần này và do đó, kiến trúc này đã trở thành kiến trúc chung của hầu hết các ứng dụng DeFi.

tiêu đề phụ

Thiết kế hợp đồng thông minh

Trong toàn bộ hệ thống ứng dụng DeFi, cốt lõi và phức tạp nhất là hợp đồng thông minh, và hợp đồng thông minh vẫn cần phải là mã nguồn mở và tính bảo mật của nó cũng rất quan trọng.Do đó, thiết kế của hợp đồng thông minh đương nhiên là một phần rất quan trọng.

Mặc dù thiết kế cụ thể khác nhau giữa các sản phẩm cụ thể, nhưng vẫn có một số nguyên tắc thiết kế chung giúp chúng tôi thiết kế các sản phẩm hợp đồng thông minh tương đối thanh lịch. Theo tôi, cái gọi là tương đối sang trọng, quan trọng nhất là phải đáp ứng một số đặc điểm: bảo mật, chức năng và khả năng mở rộng.

Bởi vì tất cả các hợp đồng thông minh cần phải là nguồn mở, nên bảo mật phải là ưu tiên hàng đầu để tránh các lỗ hổng bảo mật khác nhau, đặc biệt là để ngăn chặn các cuộc tấn công cho vay nhanh, tấn công vào lại, lỗ hổng cấp phép, v.v. Trước khi chính thức ra mắt mạng chính, cần tiến hành đầy đủ các cuộc kiểm tra an ninh nội bộ và kiểm toán bên ngoài, cũng như thử nghiệm đầy đủ, bao gồm thử nghiệm nội bộ và thử nghiệm mở bên ngoài, thậm chí là khen thưởng công khai, để nhiều chuyên gia hơn có thể cùng nhau tìm ra ẩn sơ hở.

Đáp ứng chức năng là một yêu cầu cơ bản. Ví dụ: một sản phẩm cho vay có thể gửi, rút và vay là một yêu cầu cơ bản phải được đáp ứng; một DEX phái sinh có thể phóng đại các giao dịch có đòn bẩy cũng là một yêu cầu cơ bản phải được đáp ứng. Nhưng mức độ thỏa mãn của nó có thể bị hạn chế bởi các ràng buộc khác. Ví dụ: để ngăn chặn các cuộc tấn công cho vay chớp nhoáng, DEX phái sinh có thể cấm cùng một tài khoản mở và đóng các vị trí trong cùng một khối.

Khả năng mở rộng cũng là một tính năng rất quan trọng, xét cho cùng, việc chỉ phát hành một phiên bản của một hệ thống ứng dụng là không đủ mà luôn cần phải bổ sung các chức năng mới một cách lặp đi lặp lại. Ví dụ: đối với DEX phái sinh, phiên bản đầu tiên chỉ có thể thực hiện chức năng giao dịch giá thị trường, phiên bản thứ hai cần thêm chức năng giao dịch giới hạn giá và phiên bản thứ ba cần thêm chức năng dừng lãi và cắt lỗ.

Các tính năng này không phải tất cả đều có mối tương quan tích cực. Ví dụ: tăng cường bảo mật hơn nữa có thể làm giảm chức năng và khả năng mở rộng. Lựa chọn là đạt đến trạng thái cân bằng.

Để đạt được mục tiêu, các nguyên tắc thiết kế cần tuân theo và các ý tưởng thiết kế thiết yếu đằng sau chúng thực sự là những ý tưởng mà các kiến trúc sư đã quen thuộc, chẳng hạn như nguyên tắc trách nhiệm duy nhất, nguyên tắc mở và đóng, nguyên tắc đảo ngược phụ thuộc, cách ly giao diện nguyên tắc, v.v., và các ý tưởng Kiến trúc trọng tâm như sự tách biệt, khớp nối thấp, sự gắn kết cao và thiết kế vừa phải.

Cốt lõi của thiết kế kiến trúc là đơn giản hóa các vấn đề phức tạp, điều này thậm chí còn quan trọng hơn khi áp dụng cho các hợp đồng thông minh mã nguồn mở.

tiêu đề phụ

thực hành thiết kế

Hãy lấy ứng dụng DeFi mà tôi hiện đang phụ trách làm ví dụ để nói về một số tóm tắt thực hành của tôi.

Trước tiên, hãy để tôi giới thiệu sơ qua về thông tin cơ bản. Một số ít bạn bè biết rằng gần đây tôi đã tham gia một nhóm mới và phụ trách một sản phẩm DeFi, chính xác là một DEX phái sinh. Chế độ giao dịch chủ yếu áp dụng chế độ AMM, nhưng không phải AMM cung cấp tính thanh khoản cho hai loại tiền tệ như Uniswap, mà là AMM cung cấp tính thanh khoản cho một loại tiền tệ, mà chúng tôi gọi là AMM đàn hồi. Công việc kinh doanh cụ thể sẽ không được đưa ra, và tôi sẽ nói chi tiết về nó sau, lần này tôi sẽ chủ yếu nói về những lưu ý trong thiết kế kiến trúc.

Kiến trúc tổng thể của toàn bộ hệ thống ứng dụng đại khái giống như đã đề cập ở trên, vì vậy tôi không có ý định nhắc lại kiến trúc tổng thể mà chủ yếu muốn nói về thiết kế của hợp đồng thông minh.

Ở cấp độ hợp đồng thông minh, nó thực sự được chia thành thỏa thuận chính và thỏa thuận ngoại vi. **Và điều tôi chủ yếu muốn nói đến là thiết kế của thỏa thuận chính.Hình dưới đây là cấu trúc của thỏa thuận chính:

Màu xanh lá cây chỉ đại diện cho một số vai trò tham gia vào hệ thống và các màu khác là các mô-đun phụ trong hợp đồng thông minh.

Đầu tiên, tôi lấy ý tưởng về kiến trúc phân lớp và chia hệ thống thành các lớp, lớp trên phụ thuộc vào lớp dưới, nhưng lớp dưới không thể phụ thuộc vào lớp trên. Thứ hai, các mô-đun chỉ phụ thuộc vào giao diện, không phụ thuộc vào việc triển khai cụ thể. Bằng cách này, có thể đạt được sự ghép nối thấp giữa các mô-đun.

Với tư cách là người dùng Trader và LP, tất cả họ đều tương tác với Bộ định tuyến một cách thống nhất và Bộ định tuyến tương đương với việc đóng vai trò của một cổng định tuyến. Hơn nữa, vì lớp bên dưới không có phụ thuộc vào nó nên rất dễ nâng cấp và thay thế.

Mỗi cặp giao dịch có một hợp đồng Amm và một hợp đồng Margin, và Amm và Margin ràng buộc với nhau. Do đó, việc sử dụng mô hình nhà máy để tạo các cặp giao dịch khác nhau là điều tự nhiên. Trong thiết kế ban đầu, thực tế chỉ có một hợp đồng nhà máy, nhưng trong quá trình triển khai thực tế, người ta thấy rằng hợp đồng nhà máy cuối cùng đã vượt quá số byte tối đa của hợp đồng thông minh, vì vậy hợp đồng nhà máy được chia thành ba.

Trách nhiệm của Amm là chịu trách nhiệm về các giao dịch trao đổi cơ bản, trong khi trách nhiệm của Margin là quản lý vị trí của người dùng. LiquidityERC20 là hợp đồng mã thông báo thanh khoản, được kế thừa bởi Amm. Vault quản lý các tài sản thực tế trong thỏa thuận chính, được kế thừa bởi Margin. Mô-đun này là cốt lõi của toàn bộ giao thức và chỉ thực hiện các chức năng cơ bản của lớp dưới cùng, chẳng hạn như cộng và trừ ký quỹ, mở và đóng các vị trí, thêm và xóa thanh khoản, v.v. Các chức năng có thể mở rộng có thể được thực hiện bởi các mô-đun lớp trên, chẳng hạn như hỗ trợ trao đổi ETH và WETH được Bộ định tuyến thực hiện, sau đó thêm các hợp đồng lớp trên để hỗ trợ các lệnh giới hạn giá, dừng lãi và dừng lỗ, v.v.

tiêu đề phụ

tóm tắt

Độ phức tạp tổng thể của hệ thống ứng dụng DeFi thực sự kém hơn nhiều so với hệ thống ứng dụng Web2, nhưng do nền tảng công nghệ gần như hoàn toàn khác biệt và tư duy sản phẩm cũng khá khác biệt và các ứng dụng DeFi đều là mã nguồn mở, chúng có trở thành ngưỡng cửa của ngành công nghiệp này. Vì vậy, những người chưa có kinh nghiệm thực sự không dễ dàng để bắt đầu bây giờ, ngay cả những tài năng cao cấp của Web2 cũng cần một thời gian để tìm hiểu và tích lũy sau khi vào Web3.