ERC-4626 —— Tiêu chuẩn mới cho các kho bảo hiểm được mã hóa trong DeFi
Tuyển chọn TechFlowTuyển chọn TechFlow
ERC-4626 —— Tiêu chuẩn mới cho các kho bảo hiểm được mã hóa trong DeFi
ERC-4626 là một tiêu chuẩn cải thiện thông số kỹ thuật công nghệ cho các vault sinh lời, cung cấp API chuẩn cho các vault sinh lợi đại diện cho phần vốn sở hữu dưới dạng token ERC-20 đơn lẻ.
Chuyên sâu báo cáo Web3Tác giả: Sina Pilehchiha
Biên dịch: TechFlow
TÓM TẮT: ERC-4626 là tiêu chuẩn cho các vault (kho) được token hóa.
Trước khi có ERC-4626, mỗi vault đều có quy tắc và chi tiết triển khai riêng. Điều này khiến việc tích hợp trở nên khó khăn, dễ xảy ra lỗi và tốn kém tài nguyên.
ERC-4626 cố gắng giải quyết vấn đề này bằng cách đưa ra một bộ quy chuẩn thống nhất nhằm giảm khối lượng công việc tích hợp, đồng thời tạo ra các mô hình triển khai nhất quán và mạnh mẽ hơn, tương tự như ERC-20.
ERC-4626 là gì?
ERC-4626 là một tiêu chuẩn cải thiện thông số kỹ thuật của các kho kiếm lợi nhuận. Nó cung cấp API chuẩn cho các kho sinh lời đại diện cho phần sở hữu đơn lẻ của một token ERC-20 cơ bản.
Các kho được token hóa đã trở thành mô hình cực kỳ phổ biến trong DeFi. Các dApp như trình tổng hợp lợi nhuận, thị trường cho vay, phái sinh staking... đều tận dụng và phụ thuộc vào các kho được token hóa. Ví dụ điển hình về kho được token hóa bao gồm Yearn và Balancer. Với tư cách là một trình tổng hợp lợi nhuận, kho Yearn cho phép người dùng gửi tài sản kỹ thuật số để nhận lợi nhuận. Balancer là một trình quản lý danh mục tự động và nhà cung cấp thanh khoản, hoạt động kinh doanh của nó xoay quanh kho. Những kho này quản lý token trong nhiều nhóm khác nhau, đồng thời tách biệt việc quản lý token khỏi logic của chính nhóm đó.
Các giao thức tăng tính thanh khoản và linh hoạt bằng cách token hóa kho của họ. Các kho được token hóa có thể dễ dàng giao dịch và sử dụng tài sản trên các nền tảng DeFi. Ngoài ra, chúng còn có khả năng tạo ra các sản phẩm tài chính đa dạng và liên kết với nhau. Ngành công nghiệp thường gọi mô hình này là “lego tiền tệ”.
Tuy nhiên, tính kết hợp không phù hợp hoặc thiếu chuẩn hóa sẽ gây ra thách thức. Không chỉ khiến các nhà phát triển khó tuân thủ các tiêu chuẩn ngành như ERC-20, mà còn làm khó hiểu đối với những nhà phát triển mới. Nếu không có sự thích nghi hoặc chuẩn hóa thích hợp, sẽ rất khó để kiểm tra các thay đổi mới và xác minh chi tiết triển khai tích hợp.
Do đó, ERC-4626 được đề xuất nhằm giải quyết vấn đề này, đơn giản hóa việc tích hợp, đồng thời cho phép các bên tham gia DeFi cuối cùng áp dụng một tiêu chuẩn kho thống nhất, an toàn và mạnh mẽ hơn. Điều này cũng sẽ giảm diện tấn công mà các giao thức có thể gặp phải, đồng thời hỗ trợ tích hợp token giữa nhiều giao thức.
ERC-4626 có thể ngăn ngừa những vấn đề an toàn nào?
Bằng cách cung cấp một tiêu chuẩn thống nhất, ERC-4626 đẩy nhanh tốc độ xây dựng tích hợp xuyên giao thức. Một tiêu chuẩn quen thuộc và thống nhất cũng dễ hiểu hơn đối với các nhà phát triển, từ đó giảm khả năng mắc lỗi lập trình. Điều này giúp ngăn ngừa các vấn đề về tính kết hợp. Việc chuẩn hóa còn tránh lãng phí công sức vì cộng đồng chỉ cần thiết kế kho một lần duy nhất, thay vì thiết kế riêng cho từng giao thức. Vì công việc thiết kế này thường dễ sai sót, nên nó giúp tránh lặp lại những lỗi thiết kế vốn đã tồn tại nhưng phổ biến.
Chúng ta sẽ xem xét hai nghiên cứu điển hình dưới đây để minh họa những vấn đề mà ERC-4626 có thể ngăn ngừa.
Sự cố Rari Capital
Rari Capital bị đánh cắp khoảng 11 triệu USD giá trị token, tương đương 60% tổng số tiền của tất cả người dùng trong nhóm Ethereum của Rari Capital.
Nhìn chung, vụ tấn công Rari Capital xảy ra do việc triển khai giao thức không an toàn. Nhóm Ethereum của nó sử dụng chiến lược sinh lợi bằng cách gửi ETH vào hợp đồng token ibETH của Alpha Finance. Chiến lược cụ thể này theo dõi giá trị tỷ giá ibETH/ETH thông qua một số hợp đồng và công thức nhất định (ví dụ: hàm ibETH.totalETH / ibETH.totalSupply), tuy nhiên trong kịch bản tấn công này, đầu ra có thể bị sai lệch, ví dụ như khi gọi hàm ibETH.work(), giá trị nợ có thể bị thổi phồng nhân tạo.
Kẻ tấn công chỉ cần lặp đi lặp lại việc gọi các hàm deposit và withdraw trong hợp đồng RariFundManager để rút sạch quỹ. Các hàm deposit và withdraw cần truy vấn số dư nhóm để tính toán số lượng token REPT cần phát hành cho người gọi, hoặc số lượng ETH cần trả cho người gọi, thao tác này lần lượt gọi hàm getBalance của nhóm Alpha, gọi đến hợp đồng ibETH và hàm totalETH của nó. Rari không biết rằng hàm này có thể bị thao túng.
Hợp đồng ibETH còn có một hàm khác: ibETH.work. Hàm này có thể gọi bất kỳ hợp đồng nào do người dùng chỉ định. Điều này khiến các hàm deposit và withdraw của Rari có thể bị tái nhập (reentrant) và gọi nhiều lần.
Hàm work là một hàm có thể nhận ETH, nghĩa là người dùng có thể điều khiển lượng ETH trong hợp đồng ibETH thông qua hàm work, từ đó thay đổi giá trị mà hàm totalETH trả về. Tệ hơn nữa, hàm work còn hỗ trợ gọi bất kỳ hợp đồng nào khác, ví dụ như RariFundManager.
Thông qua hàm này, kẻ tấn công có thể gửi thêm ETH để tăng số lượng totalETH trong hợp đồng ibETH, đồng thời gọi hàm withdraw trong hợp đồng RariFundManager để rút thêm tài sản.
Sự kiện này làm nổi bật rủi ro lớn do tích hợp yếu kém và thiết kế không tương thích trong các hợp đồng DeFi. Nó nhấn mạnh rằng các tiêu chuẩn như ERC-4626 có thể ngăn chặn những cuộc tấn công như vậy bằng cách bổ sung lớp bảo mật và tính dự đoán, thúc đẩy hành vi thống nhất và sự thấu hiểu lẫn nhau.
Sự cố Cream Finance
Cream Finance đã bị tấn công bởi một cuộc tấn công phức tạp, khai thác hai điểm yếu cơ bản trong nền tảng: oracle lai có thể bị thao túng và nguồn cung token không giới hạn. Phần then chốt của cuộc tấn công là việc thao túng oracle lai, ảnh hưởng đến giá trị cảm nhận của token yUSD. Khi kẻ tấn công gửi một lượng lớn token Yearn 4-Curve vào kho yUSD, hắn đã làm thay đổi tỷ giá báo cáo bởi kho, từ đó ảnh hưởng đến giá trị cảm nhận của token yUSD bởi oracle.
Bài học cốt lõi ở đây là một oracle giá mạnh mẽ và không thể bị thao túng là cực kỳ quan trọng đối với sự ổn định của các giao thức DeFi. Oracle giá trung bình theo thời gian (TWAP) có thể giúp ngăn chặn các vụ tấn công như vậy, vì chúng kháng cự tốt hơn trước những thao túng giá đột ngột.
Những vấn đề này, cùng với các mô hình thiết kế yếu kém khác, có thể được giảm nhẹ thông qua việc áp dụng và triển khai cẩn trọng ERC-4626.
Các rủi ro an toàn tiềm tàng trong ERC-4626
Việc sử dụng giao thức mới luôn đi kèm với những sự đánh đổi nhất định. Đối với các kho được token hóa, việc tích hợp chúng vào các hợp đồng thông minh có thể tiềm ẩn những vấn đề cần đặc biệt lưu ý.
Quản lý token feeOnTransfer
Nếu kho được thiết kế để hỗ trợ token feeOnTransfer, hãy kiểm tra xem số lượng tài sản và cổ phần trong kho có nằm trong phạm vi mong đợi sau mỗi lần chuyển hay không.
Sử dụng đúng biến decimals
Mặc dù các hàm convertTo không nên cần đến biến decimals của vault EIP-4626, nhưng vẫn được khuyến nghị mạnh mẽ rằng nên phản chiếu lại số decimals của token cơ bản nếu có thể. Cách làm này giúp loại bỏ nguồn gây nhầm lẫn tiềm tàng và đơn giản hóa việc tích hợp cho nhiều frontend và người dùng ngoài chuỗi.
Làm tròn
Theo quy chuẩn, người triển khai vault cần lưu ý rằng trong các phương pháp biến đổi và phương pháp view khác nhau, cần có hướng làm tròn cụ thể và ngược chiều nhau, vì trong quá trình tính toán, an toàn hơn khi ưu tiên lợi ích của vault hơn là người dùng:
-
Nếu đang tính số cổ phần cần phát hành cho người dùng tương ứng với lượng token cơ bản họ cung cấp, hoặc đang xử lý việc chuyển lượng token cơ bản tương ứng với một số cổ phần nhất định cho người dùng, thì nên làm tròn xuống.
-
Nếu đang tính người dùng cần cung cấp bao nhiêu cổ phần để nhận được một lượng token cơ bản nhất định, hoặc đang tính người dùng cần cung cấp bao nhiêu token cơ bản để nhận được một số cổ phần nhất định, thì nên làm tròn lên.
Trường hợp làm tròn mơ hồ nhất là hàm convertTo. Để đảm bảo tính nhất quán trong mọi triển khai vault EIP-4626, các chức năng này phải luôn làm tròn xuống. Người tích hợp có thể tự tạo phiên bản làm tròn lên bằng cách, ví dụ, cộng thêm một Wei vào kết quả.
Số lượng tài sản cơ bản mà một người dùng nhận được khi hoàn vốn cổ phần của họ trong vault (previewRedeem) có thể rất khác so với số lượng họ phải trả khi mua cùng số cổ phần đó (previewMint). Những khác biệt này có thể nhỏ (ví dụ do lỗi làm tròn) hoặc rất lớn (ví dụ kho áp dụng phí rút hoặc phí gửi). Do đó, người tích hợp cần lưu ý sử dụng hàm preview phù hợp với trường hợp sử dụng của họ, và không bao giờ giả định rằng các hàm này có thể thay thế cho nhau.
Ghi đè chức năng cốt lõi
Để đạt được hoặc mở rộng chức năng mong muốn, nên sử dụng các hook (điểm gắn kết) hiện có thay vì thay đổi các chức năng cốt lõi. Cách tiếp cận này giúp việc theo dõi dễ quản lý hơn, thuận tiện cho kiểm thử và kiểm tra mã hiệu quả.
Cổ phần bằng không
Quy chuẩn ERC-4626 ban đầu không nêu rõ cách xử lý trường hợp cực đoan khi trong vault không có cổ phần — liệu vault có nên hoạt động bình thường hay revert. Điều này có thể trở thành nguồn gây nhầm lẫn và lỗi.
Vault làm oracle giá
Về rủi ro bị thao túng oracle giá, các giá trị trả về từ các phương pháp preview càng gần chính xác càng tốt. Do đó, chúng có thể bị thao túng bằng cách thay đổi điều kiện trên chuỗi, và không phải lúc nào cũng an toàn khi dùng làm oracle giá. Quy chuẩn ERC-4626 bao gồm các phương pháp convert và totalAssets cho phép không chính xác, do đó có thể được triển khai thành oracle giá mạnh mẽ. Ví dụ, khi chuyển đổi giữa tài sản và cổ phần, việc sử dụng giá trung bình theo thời gian (TWAP) để triển khai phương pháp convert là hợp lý.
Vấn đề triển khai cụ thể
Trước khi tích hợp sâu hơn, người tích hợp phải xem xét kỹ việc triển khai bất kỳ kho được token hóa nào, vì có thể tồn tại các triển khai ác ý trông có vẻ phù hợp với giao diện, nhưng các hàm cốt lõi lại được xây dựng theo quy chuẩn thiết kế hoàn toàn khác.
Truy cập trực tiếp từ EOA
Nếu truy cập trực tiếp vào một vault, triển khai của nó cần có chức năng xử lý tổn thất trượt giá hoặc các giới hạn gửi/rút không mong muốn. Khác với hợp đồng thông minh, EOA không có cơ chế bảo vệ sự cố rollback giao dịch, và nếu không đạt được đầu ra chính xác khi gọi các hàm cốt lõi, thì không thể hoàn tác.
Mở rộng vault
Khi ngày càng nhiều bên tham gia bắt đầu áp dụng tiêu chuẩn ERC-4626, chúng ta sẽ thấy nhiều mở rộng hơn được phát triển cho tiêu chuẩn này. Ví dụ, Superform đã phát triển một mở rộng Multi-vault thử nghiệm, hỗ trợ các phép tính khác nhau trong cùng một hợp đồng vault. Một cách tự nhiên, càng lệch xa khỏi tiêu chuẩn gốc, khả năng xuất hiện lỗ hổng mới càng cao. Các nhà phát triển và kiểm toán viên có thể tự tìm ra lựa chọn tối ưu dựa trên trường hợp sử dụng để xác định mức độ rủi ro thực tế.
Cần lưu ý rằng, không phải mỗi bổ sung nhỏ nào cũng dẫn đến sự kiện thảm họa, mà là tổng thể khi chúng được tích hợp với nhau.
Các vector tấn công tiềm tàng được đề cập ở trên là một số vấn đề thường được thảo luận xung quanh tiêu chuẩn ERC-4626. Khi tỷ lệ áp dụng tăng lên, chúng ta chắc chắn sẽ khám phá thêm nhiều trường hợp triển khai, cũng như nhiều tình huống tích hợp phù hợp hơn với các vault ERC-4626.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
zellic
