Đọc ERC-4626 trong một bài viết: Tiêu chuẩn mới cho kho tiền mã hóa DeFi

Tác giả gốc: Sina Pilehchiha

Bản tổng hợp gốc: Shenchao TechFlow

TLDR: ERC-4626 được sử dụng cho bảo hiểm token hóa Standard for Vault .

Trước khi giới thiệu ERC-4626, mỗi vault đều có thông số kỹ thuật và chi tiết triển khai riêng. Điều này làm cho việc tích hợp trở nên khó khăn, dễ xảy ra lỗi và lãng phí tài nguyên.

ERC-4626 cố gắng giải quyết vấn đề này thông qua đặc tả tiêu chuẩn nhằm giảm nỗ lực tích hợp và tạo ra một mô hình triển khai mạnh mẽ và nhất quán hơn, giống như ERC-20. .

ERC-4626  là gì?

ERC-4626 là tiêu chuẩn cải thiện các thông số kỹ thuật của vault dựa trên lợi nhuận. Nó cung cấp một API tiêu chuẩn cho kho lợi nhuận đại diện cho cổ phần của một mã thông báo ERC-20 cơ bản.

Kho tiền được mã hóa đã trở thành một mô hình cực kỳ phổ biến trong DeFi. Nhiều dApp như công cụ tổng hợp lợi nhuận, thị trường cho vay, công cụ phái sinh đặt cược, v.v. sử dụng và dựa vào kho tiền được mã hóa. Ví dụ về kho tiền được mã hóa bao gồm Yearn và Balancer. Là một công cụ tổng hợp lợi nhuận, Yearn Vault cho phép người dùng gửi tài sản kỹ thuật số và kiếm lợi nhuận. Balancer là một nhà cung cấp thanh khoản và quản lý danh mục đầu tư tự động dựa vào kho tiền làm cốt lõi cho logic kinh doanh của mình. Những kho tiền này quản lý mã thông báo trong nhiều nhóm khác nhau. Đồng thời, họ tách việc quản lý mã thông báo khỏi logic của chính nhóm.

Giao thức tăng cường tính thanh khoản và tính linh hoạt bằng cách mã hóa kho tiền của nó. Kho tiền được mã hóa giúp dễ dàng giao dịch và sử dụng tài sản trên nền tảng DeFi. Ngoài ra, chúng còn cho phép tạo ra các sản phẩm tài chính đa dạng, có tính kết nối. Ngành công nghiệp này từ lâu đã ủng hộ mô hình này, thường được gọi là “Lego tiền tệ”.

Tuy nhiên, khả năng kết hợp mà không có khả năng thích ứng hoặc tiêu chuẩn hóa thích hợp sẽ tạo ra những thách thức. Nó không chỉ gây khó khăn cho các nhà phát triển trong việc tuân thủ các tiêu chuẩn ngành như ERC-20 mà còn có thể gây nhầm lẫn cho các nhà phát triển mới. Nếu không có khả năng thích ứng hoặc tiêu chuẩn hóa phù hợp thì rất khó để xem xét các thay đổi mới và xác thực các chi tiết triển khai tích hợp.

Vì vậy, ERC-4626 được đề xuất để giải quyết vấn đề này và đơn giản hóa việc tích hợp, đồng thời cho phép những người tham gia DeFi cuối cùng áp dụng thông số kỹ thuật vault thống nhất an toàn và mạnh mẽ hơn. Ngược lại, điều này cũng sẽ làm giảm bề mặt tấn công mà giao thức có thể gặp phải khi tích hợp mã thông báo trên nhiều giao thức.

ERC-4626 có thể ngăn chặn những vấn đề bảo mật nào?

Bằng cách cung cấp một tiêu chuẩn thống nhất, ERC-4626 đẩy nhanh việc xây dựng tích hợp đa giao thức. Các tiêu chuẩn quen thuộc, thống nhất cũng giúp các nhà phát triển dễ hiểu hơn, giảm khả năng xảy ra lỗi mã hóa. Điều này giúp ngăn ngừa các vấn đề về khả năng kết hợp. Tiêu chuẩn hóa cũng ngăn ngừa sự trùng lặp nỗ lực, vì cộng đồng chỉ phải thiết kế vault một lần, thay vì thiết kế riêng cho từng giao thức. Vì loại công việc thiết kế này thường dễ mắc lỗi nên nó giúp tránh lặp lại các lỗi thiết kế đã có nhưng phổ biến.

Ở đây chúng tôi sẽ trình bày hai nghiên cứu điển hình để chứng minh những vấn đề mà ERC-4626 có thể ngăn ngừa.

Sự cố Rari Capital

Rari Capital đã bị đánh cắp số token trị giá khoảng 11 triệu đô la. tương đương với 60 % tổng số tiền của người dùng trong nhóm Rari Capital Ethereum.

Tóm lại, Rari Capital đã bị tấn công do triển khai giao thức chéo không an toàn. Nhóm Ethereum của nó đóng vai trò như một chiến lược lợi nhuận bằng cách gửi ETH vào hợp đồng mã thông báo ibETH của Alpha Finance. Chiến lược cụ thể này theo dõi giá trị tỷ giá hối đoái ibETH/ETH của nó thông qua các hợp đồng và công thức nhất định (cụ thể là hàm ibETH.totalETH / ibETH.totalSupply). Trong kịch bản tấn công này, có thể có kết quả đầu ra không chính xác, chẳng hạn như khi gọi ibETH .work (), giá trị nợ có thể bị thổi phồng một cách giả tạo.

Kẻ tấn công có thể làm cạn kiệt Trình quản lý quỹ Rari chỉ bằng cách liên tục gọi các chức năng gửi và rút tiền trong hợp đồng RariFundManager. Các chức năng gửi và rút cần lấy số dư của nhóm để tính toán số lượng token REPT sẽ được cấp cho người gọi hoặc số lượng ETH được cấp cho người gọi. Thao tác này sẽ gọi hàm getBalance của nhóm Alpha , gọi hợp đồng ibETH và hàm TotalETH của nó tương ứng. . Rari không biết về khả năng thao túng chức năng này.

Có một chức năng khác trong hợp đồng ibETH: 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 cho phép chức năng gửi và rút tiền của Rari được đăng ký lại và được gọi nhiều lần.

Hàm công việc là hàm phải trả, nghĩa là người dùng có thể kiểm soát số lượng ETH trong hợp đồng ibETH thông qua hàm công việc, do đó thay đổi giá trị được trả về bởi hàm TotalETH  . Tệ hơn nữa, chức năng công việc còn hỗ trợ gọi bất kỳ hợp đồng nào khác, chẳng hạn như RariFundManager.

Thông qua chức năng này, kẻ tấn công có thể gửi lại ETH và tăng tổng số ETH trong hợp đồng ibETH, đồng thời yêu cầu rút tiền trong hợp đồng RariFundManager để đổi thêm tài sản.

Sự cố này nêu bật những rủi ro đáng kể do sự tích hợp không đầy đủ và thiết kế không tương thích trong các hợp đồng DeFi. Nó nhấn mạnh cách các tiêu chuẩn như ERC-4626 có thể ngăn chặn các cuộc tấn công như thế này bằng cách thêm một lớp bảo mật và khả năng dự đoán quan trọng, đồng thời thúc đẩy hành vi thống nhất và hiểu biết lẫn nhau.

Sự cố Cream Finance

Cream Finance hứng chịu một cuộc tấn công tinh vi khai thác nền tảng Hai điểm yếu cơ bản : các oracle lai bị thao túng và nguồn cung cấp token chưa được khai thác. Một phần quan trọng của cuộc tấn công là việc thao túng nhà tiên tri trộn, điều này ảnh hưởng đến giá trị cảm nhận của mã thông báo yUSD. Khi kẻ tấn công gửi một lượng lớn mã thông báo Yearn 4-Curve đến kho tiền yUSD, hắn đã thay đổi tỷ giá hối đoái được kho tiền báo cáo và do đó cũng ảnh hưởng đến giá trị cảm nhận của oracle về mã thông báo yUSD.

Bài học quan trọng ở đây là lời tiên tri về giá mạnh mẽ và không thể bị thao túng là rất quan trọng đối với sự ổn định của giao thức DeFi. Các oracle về giá trung bình theo trọng số theo thời gian (TWAP) có thể giúp ngăn chặn những vụ hack như vậy vì chúng có khả năng phục hồi tốt hơn trước những thao túng giá đột ngột.

Những vấn đề này cũng như các mẫu thiết kế dễ hỏng khác có thể được giảm thiểu thông qua việc áp dụng và triển khai ERC-4626 một cách cẩn thận.

Rủi ro bảo mật tiềm ẩn trong ERC-4626

Luôn có một số đánh đổi khi sử dụng một giao thức mới. Đối với các kho tiền được mã hóa, việc tích hợp chúng vào hợp đồng thông minh có thể tiềm ẩn các vấn đề cần được chú ý đặc biệt.

Quản lý mã thông báo chargeOnTransfer

Nếu kho tiền được thiết kế để hỗ trợ mã thông báo chargeOnTransfer, vui lòng Khi chuyển tài sản, kiểm tra xem số lượng và cổ phần trong kho có nằm trong phạm vi dự kiến hay không.

Sử dụng số thập phân biến một cách thích hợp

Mặc dù hàm ConvertTo không cần sử dụng các biến thập phân của EIP-4626 vault, nhưng chúng tôi vẫn khuyên bạn nên phản chiếu các số thập phân của Token cơ bản ở những nơi khả thi. Cách thực hành này giúp loại bỏ các nguồn gây nhầm lẫn tiềm ẩn và đơn giản hóa việc tích hợp cho nhiều người dùng front-end và off-chain khác nhau.

Làm tròn

Theo đặc tả, người triển khai vault cần nắm rõ các phương pháp và xem yêu cầu một hướng làm tròn cụ thể và ngược lại vì sẽ an toàn hơn nếu ưu tiên chính vault hơn là người dùng của nó trong quá trình tính toán:

- Nếu tính số lượng cổ phiếu cần được cấp cho người dùng với số lượng mã thông báo cơ sở mà họ đã cung cấp hoặc nó đang hoạt động để chuyển một phần mã thông báo cơ sở cụ thể cho người dùng, số tiền này sẽ được làm tròn xuống.

- Nếu nó đang tính toán số lượng chia sẻ mà người dùng phải cung cấp để nhận được một lượng mã thông báo cơ sở nhất định hoặc đang tính toán số lượng mã thông báo cơ sở mà người dùng phải cung cấp để nhận được một số tiền chia sẻ nhất định thì số tiền đó phải được làm tròn lên.

Một trong đó hướng làm tròn ưa thích sẽ không rõ ràng là hàm ConvertTo. Để đảm bảo tính nhất quán trên tất cả các triển khai vault EIP-4626, việc chỉ định các chức năng này phải luôn được làm tròn xuống. Các nhà tích hợp có thể tự mô phỏng phiên bản làm tròn lên, chẳng hạn bằng cách thêm Wei vào kết quả.

Người dùng nhận được một lượng tài sản cơ bản bằng cách mua lại cổ phần của họ trong kho tiền (previewRedeem), có thể với cùng số lượng cổ phiếu đã phát hành (previewMint) Số tiền yêu cầu rất khác nhau. Những khác biệt này có thể nhỏ (ví dụ do lỗi làm tròn) hoặc lớn (ví dụ: kho tiền thực hiện phí rút tiền hoặc phí gửi tiền). Do đó, các nhà tích hợp nên cẩn thận để sử dụng chức năng xem trước phù hợp nhất với trường hợp sử dụng của mình và đừng bao giờ cho rằng chúng có thể thay thế cho nhau.

Bao gồm chức năng cốt lõi

Để triển khai hoặc mở rộng chức năng dự kiến, bạn nên sử dụng Hook hiện có thay vì thay đổi chức năng cốt lõi. Cách thực hành này đảm bảo việc theo dõi dễ quản lý hơn để kiểm tra và đánh giá mã hiệu quả.

Không có lượt chia sẻ

Thông số kỹ thuật ban đầu cho ERC-4626 không nêu rõ cách xử lý số 0 chia sẻ trong vault Chia sẻ các trường hợp biên và liệu vault sẽ hoạt động như bình thường hay quay trở lại. Đây có thể là nguồn gây nhầm lẫn và sai sót.

Vault như nhà tiên tri về giá

Liên quan đến nguy cơ xảy ra các cuộc tấn công thao túng giá oracle, các giá trị được trả về bởi các phương pháp xem trước này càng gần chính xác càng tốt. Do đó, chúng có thể hoạt động bằng cách thay đổi các điều kiện trên chuỗi và không phải lúc nào cũng an toàn khi được sử dụng làm lời tiên tri về giá. Thông số kỹ thuật ERC-4626 bao gồm việc cho phép các phương thức chuyển đổi và tổng tài sản không chính xác, do đó nó có thể được triển khai như một lời tiên tri về giá mạnh mẽ. Ví dụ: khi chuyển đổi giữa tài sản và cổ phiếu, việc triển khai phương pháp chuyển đổi bằng cách sử dụng giá trung bình theo thời gian là đúng.

Các vấn đề triển khai cụ thể

Nhà tích hợp phải xem xét mọi mã thông báo trước khi tích hợp thêm Việc triển khai vault, do khả năng triển khai độc hại, dường như tuân thủ đặc tả giao diện, nhưng chức năng cốt lõi của nó bao gồm các thông số thiết kế hoàn toàn khác nhau.

Truy cập trực tiếp EOA

Nếu bạn muốn truy cập trực tiếp vào vault, việc triển khai nó cần phải có sẵn các Tính năng để ứng phó với tổn thất do trượt giá hoặc giới hạn gửi/rút tiền ngoài dự kiến. Không giống như hợp đồng thông minh, EOA không có cơ chế bảo vệ lỗi khi khôi phục giao dịch. Nếu không đạt được đầu ra chính xác khi gọi chức năng cốt lõi thì sẽ không có cách nào để khôi phục.

Hầm mở rộng

Khi ngày càng có nhiều người tham gia bắt đầu áp dụng tiêu chuẩn ERC-4626, chúng tôi sẽ thấy nhiều tiện ích mở rộng hơn được triển khai cho tiêu chuẩn này. Ví dụ: Superform đã phát triển tiện ích mở rộng Multi vault thử nghiệm hỗ trợ việc sử dụng các phép tính khác nhau trong hợp đồng vault. Đương nhiên, việc triển khai càng khác xa với tiêu chuẩn ban đầu thì khả năng tạo ra các 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ìm ra điểm phù hợp của riêng mình dựa trên các trường hợp sử dụng để xác định giá trị rủi ro thực tế.

Điều quan trọng cần lưu ý là không phải sự bổ sung nhỏ nhất vào mỗi giao thức sẽ dẫn đến một sự kiện thảm khốc, mà là tổng của chúng khi được tích hợp với nhau.

Các vectơ tấn công tiềm ẩn được đề cập ở trên là một số vấn đề được thảo luận nhiều hơn xung quanh tiêu chuẩn ERC-4626. Khi việc áp dụng tăng lên, chúng tôi chắc chắn sẽ khám phá nhiều trường hợp sử dụng triển khai hơn và các kịch bản phù hợp hơn để tích hợp với vault ERC-4626.

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