TLDR: ERC-4626 là tiêu chuẩn cho các kho tiền được mã hóa.
Trước khi giới thiệu ERC-4626, mỗi vault 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 bằng một đặc điểm kỹ thuật tiêu chuẩn để giảm nỗ lực tích hợp và tạo ra một mô hình triển khai nhất quán và mạnh mẽ hơn, giống như ERC-20.
ERC-4626 là gì?
ERC-4626 là một tiêu chuẩn giúp cải thiện các thông số kỹ thuật của hầm năng suất. Nó cung cấp một API tiêu chuẩn cho các kho lợi nhuận đại diện cho các cổ phiếu của một mã thông báo ERC-20 cơ bản duy nhất.
Kho tiền được mã hóa đã trở thành một mô hình cực kỳ phổ biến trong DeFi. 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à nhiều ứng dụng dApp khác tận dụng và dựa vào kho tiền được mã hóa. Ví dụ về kho tiền 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à trình quản lý danh mục đầu tư tự động và nhà cung cấp thanh khoản dựa trên kho tiền là cốt lõi trong logic kinh doanh của mình. Các kho tiền này quản lý mã thông báo trong các nhóm khác nhau. Đồng thời, họ tách 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 các 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 cho phép tạo ra các sản phẩm tài chính đa dạng, kết nối với nhau. Ngành công nghiệp đã ủng hộ mô hình này, thường được gọi là "Lego tiền".
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ẽ đưa ra những thách thức. Nó không chỉ khiến các nhà phát triển gặp khó khăn trong việc tuân thủ các tiêu chuẩn ngành như ERC-20 mà còn có thể khiến các nhà phát triển mới bối rối. Nếu không có sự điều chỉnh hoặc tiêu chuẩn hóa phù hợp, rất khó để xem xét các thay đổi mới và xác minh 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 một đặc điểm kỹ thuật vault hợp nhất mạnh mẽ và an toàn hơn. Điều này đến lượt nó sẽ làm giảm bề mặt tấn công có thể có của giao thức trong 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 quá trình xây dựng tích hợp giao thức chéo. Các tiêu chuẩn quen thuộc, nhất quán cũng dễ hiểu hơn đối với các nhà phát triển, giảm khả năng mắc lỗi mã hóa. Điều này giúp ngăn ngừa các vấn đề về khả năng tổng hợp. Tiêu chuẩn hóa cũng ngăn chặn sự trùng lặp nỗ lực, vì cộng đồng chỉ cần thiết kế kho tiền một lần, thay vì riêng lẻ cho từng giao thức. Vì nỗ lực thiết kế này thường dễ bị lỗi nên nó giúp tránh lặp lại các lỗi thiết kế phổ biến nhưng đã được thiết lập.
Chúng tôi sẽ trình bày hai trường hợp nghiên cứu ở đây để chỉ ra những vấn đề mà ERC-4626 có thể ngăn chặn.
Sự kiện Rari Capital
Khoảng 11 triệu đô la mã thông báo đã bị đánh cắp từ Rari Capital, tương đương với 60% tổng số tiền của người dùng trong nhóm Ethereum của Rari Capital.
Nhìn chung, Rari Capital đã bị hack do triển khai giao thức chéo không an toàn. Nhóm Ethereum của nó đưa ETH vào hợp đồng mã thông báo ibETH của Alpha Finance như một chiến lược đầu ra. Chiến lược cụ thể này theo dõi giá trị của 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), có thể có kết quả sai trong kịch bản tấn công này, chẳng hạn như khi gọi ibETH.work ( ), giá trị khoản nợ có thể bị thổi phồng 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 tiền cần lấy số dư của nhóm để tính toán số lượng mã thông báo REPT sẽ được cấp cho người gọi hoặc số lượng ETH sẽ được cấp cho người gọi. Thao tác này sẽ gọi hàm getBalance của nhóm Alpha , hãy gọi hợp đồng ibETH và hàm totalETH của nó. 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 các chức năng gửi và rút tiền của Rari được cấp lại và được gọi nhiều lần.
Chức năng làm việc là một chức năng trả phí, có 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 chức năng làm việc, từ đó 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ũng 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ố lượng ETH trong hợp đồng ibETH, đồng thời gọi rút tiền trong hợp đồng RariFundManager để mua lại nhiều tài sản hơn.
Sự cố này làm nổi bật những rủi ro đáng kể do 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ó nêu bật 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ư vậ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.
Trường hợp tài chính kem
Cream Finance đã phải hứng chịu một cuộc tấn công tinh vi khai thác hai điểm yếu cơ bản trong nền tảng: một nhà tiên tri trộn lẫn bị thao túng và nguồn cung cấp mã thông báo chưa được khai thác. Một phần quan trọng của cuộc tấn công là sự thao túng của 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, kẻ tấn công đã thay đổi tỷ giá hối đoái được báo cáo bởi kho tiền và do đó cũng ảnh hưởng đến giá trị cảm nhận của mã thông báo yUSD đối với nhà tiên tri.
Bài học quan trọng ở đây là một lời tiên đoán về giá mạnh mẽ và không thể thao túng là rất quan trọng đối với sự ổn định của giao thức DeFi. Các nhà tiên tri về giá trung bình theo trọng số thời gian (TWAP) có thể giúp ngăn chặn các vụ hack như vậy vì chúng có khả năng chống thao túng giá đột ngột hơn.
Những vấn đề này và các mẫu thiết kế mong manh khác có thể được giảm thiểu thông qua việc áp dụng và triển khai cẩn thận ERC-4626.
Rủi ro bảo mật tiềm ẩn trong ERC-4626
Luôn có một số 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, có thể có các vấn đề tiềm ẩn khi tích hợp chúng vào các hợp đồng thông minh cần được chú ý đặc biệt.
Quản lý mã thông báo phíOnTransfer
Nếu kho tiền được thiết kế để hỗ trợ mã thông báo feeOnTransfer, hãy kiểm tra xem số tiền và cổ phần trong kho tiền có nằm trong phạm vi dự kiến khi chuyển tài sản hay không.
Sử dụng hợp lý biến số thập phân
Mặc dù chức năng convertTo không cần sử dụng biến số thập phân của kho tiền EIP-4626, nhưng vẫn nên phản ánh số thập phân của mã thông báo cơ bản nếu khả thi. Phương pháp 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 giao diện người dùng và người dùng ngoại tuyến.
làm tròn
Theo thông số kỹ thuật, những người triển khai vault nên biết rằng các hướng làm tròn cụ thể và ngược lại được yêu cầu trong các phương thức xem và có thể thay đổi khác nhau, vì sẽ an toàn hơn nếu ưu tiên bản thân vault hơn người dùng trong quá trình tính toán:
Nếu nó đang tính số lượng cổ phần sẽ được phát hành cho người dùng đối với số lượng mã thông báo cơ bản mà họ cung cấp hoặc nếu nó đang hoạt động để chuyển một phần cụ thể của mã thông báo cơ bản cho người dùng, thì nó sẽ được làm tròn xuống.
Nếu nó đang tính toán số lượng cổ phiếu 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 nếu nó đ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ố lượng cổ phần nhất định, thì nó nên được làm tròn lên.
Trường hợp 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, hãy chỉ định rằng các chức năng này phải luôn làm tròn xuống. Các nhà tích hợp có thể tự bắt chước phiên bản làm tròn, chẳng hạn bằng cách thêm một Wei vào kết quả.
Số lượng tài sản cơ bản mà người dùng nhận được bằng cách mua lại cổ phần của họ trong kho tiền (previewRedeem) có thể thay đổi đáng kể so với số tiền phải trả để phát hành cùng một lượng 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 lớn (ví dụ: kho tiền thực hiện phí rút tiền hoặc gửi tiền). Do đó, các nhà tích hợp nên cẩn thận sử dụng các chức năng xem trước phù hợp nhất với trường hợp sử dụng của họ và không bao giờ cho rằng chúng có thể hoán đổi cho nhau.
Ghi đè chức năng cốt lõi
Để triển khai hoặc mở rộng chức năng dự định, nên sử dụng các hook hiện có thay vì thay đổi chức năng cốt lõi. Thực tiễn này đảm bảo một lộ trình dễ quản lý hơn để kiểm tra và kiểm tra mã hiệu quả.
Không chia sẻ
Thông số kỹ thuật ban đầu cho ERC-4626 không phác thảo cách xử lý trường hợp góc không có phần chia sẻ trong vault và liệu vault sẽ hoạt động như bình thường hay quay trở lại. Đây có thể là một nguồn tiềm ẩn của sự nhầm lẫn và sai sót.
Vault như lời tiên tri về giá
Liên quan đến nguy cơ bị các cuộc tấn công thao túng giá của nhà tiên tri, các giá trị được trả về bởi các phương pháp xem trước này càng gần với độ 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 để sử dụng làm tiên tri về giá. Thông số kỹ thuật ERC-4626 bao gồm một phương thức chuyển đổi và một phương thức TotalAssets cho phép tính không chính xác và do đó 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 sử dụng giá bình quân gia quyền theo thời gian để thực hiện phương pháp chuyển đổi là đúng.
Vấn đề triển khai cụ thể
Các nhà tích hợp phải xem xét mọi triển khai vault được mã hóa trước khi tích hợp thêm, vì có thể có các triển khai độc hại có vẻ phù hợp với đặc tả giao diện, nhưng các chức năng cốt lõi của chúng bao gồm các đặc tả thiết kế hoàn toàn khác.
Truy cập trực tiếp EOA
Nếu muốn truy cập trực tiếp vào kho tiền, thì việc triển khai kho tiền đó cần phải có các tính năng có thể được sử dụng để bù đắp tổn thất do trượt giá hoặc các giới hạn gửi/rút ngẫu nhiên. Không giống như các hợp đồng thông minh, EOA không có cơ chế dự phòng an toàn để 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ì không có cách nào để khôi phục.
Vault mở rộng
Khi nhiều người chơi 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 được triển khai cho tiêu chuẩn. 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 tính toán khác nhau trong một hợp đồng Vault duy nhất. Đương nhiên, việc triển khai càng sai lệch so với tiêu chuẩn ban đầu thì khả năng đưa 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 thấy tùy chọn tốt nhất của họ dựa trên trường hợp sử dụng để xác định giá trị thực tế có nguy cơ.
Điều quan trọng cần lưu ý là không phải phần bổ sung nhỏ nhất của mỗi giao thức dẫn đến các sự kiện thảm khốc, mà là tổng của chúng khi được tích hợp.
Các vectơ tấn công tiềm năng đượ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 kho tiền ERC-4626.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Hiểu về ERC-4626 trong một bài viết: tiêu chuẩn mới cho kho tiền mã hóa DeFi
TLDR: ERC-4626 là tiêu chuẩn cho các kho tiền được mã hóa.
Trước khi giới thiệu ERC-4626, mỗi vault 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 bằng một đặc điểm kỹ thuật tiêu chuẩn để giảm nỗ lực tích hợp và tạo ra một mô hình triển khai nhất quán và mạnh mẽ hơn, giống như ERC-20.
ERC-4626 là gì?
ERC-4626 là một tiêu chuẩn giúp cải thiện các thông số kỹ thuật của hầm năng suất. Nó cung cấp một API tiêu chuẩn cho các kho lợi nhuận đại diện cho các cổ phiếu của một mã thông báo ERC-20 cơ bản duy nhất.
Kho tiền được mã hóa đã trở thành một mô hình cực kỳ phổ biến trong DeFi. 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à nhiều ứng dụng dApp khác tận dụng và dựa vào kho tiền được mã hóa. Ví dụ về kho tiền 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à trình quản lý danh mục đầu tư tự động và nhà cung cấp thanh khoản dựa trên kho tiền là cốt lõi trong logic kinh doanh của mình. Các kho tiền này quản lý mã thông báo trong các nhóm khác nhau. Đồng thời, họ tách 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 các 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 cho phép tạo ra các sản phẩm tài chính đa dạng, kết nối với nhau. Ngành công nghiệp đã ủng hộ mô hình này, thường được gọi là "Lego tiền".
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ẽ đưa ra những thách thức. Nó không chỉ khiến các nhà phát triển gặp khó khăn trong việc tuân thủ các tiêu chuẩn ngành như ERC-20 mà còn có thể khiến các nhà phát triển mới bối rối. Nếu không có sự điều chỉnh hoặc tiêu chuẩn hóa phù hợp, rất khó để xem xét các thay đổi mới và xác minh 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 một đặc điểm kỹ thuật vault hợp nhất mạnh mẽ và an toàn hơn. Điều này đến lượt nó sẽ làm giảm bề mặt tấn công có thể có của giao thức trong 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 quá trình xây dựng tích hợp giao thức chéo. Các tiêu chuẩn quen thuộc, nhất quán cũng dễ hiểu hơn đối với các nhà phát triển, giảm khả năng mắc lỗi mã hóa. Điều này giúp ngăn ngừa các vấn đề về khả năng tổng hợp. Tiêu chuẩn hóa cũng ngăn chặn sự trùng lặp nỗ lực, vì cộng đồng chỉ cần thiết kế kho tiền một lần, thay vì riêng lẻ cho từng giao thức. Vì nỗ lực thiết kế này thường dễ bị lỗi nên nó giúp tránh lặp lại các lỗi thiết kế phổ biến nhưng đã được thiết lập.
Chúng tôi sẽ trình bày hai trường hợp nghiên cứu ở đây để chỉ ra những vấn đề mà ERC-4626 có thể ngăn chặn.
Sự kiện Rari Capital
Khoảng 11 triệu đô la mã thông báo đã bị đánh cắp từ Rari Capital, tương đương với 60% tổng số tiền của người dùng trong nhóm Ethereum của Rari Capital.
Nhìn chung, Rari Capital đã bị hack do triển khai giao thức chéo không an toàn. Nhóm Ethereum của nó đưa ETH vào hợp đồng mã thông báo ibETH của Alpha Finance như một chiến lược đầu ra. Chiến lược cụ thể này theo dõi giá trị của 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), có thể có kết quả sai trong kịch bản tấn công này, chẳng hạn như khi gọi ibETH.work ( ), giá trị khoản nợ có thể bị thổi phồng 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 tiền cần lấy số dư của nhóm để tính toán số lượng mã thông báo REPT sẽ được cấp cho người gọi hoặc số lượng ETH sẽ được cấp cho người gọi. Thao tác này sẽ gọi hàm getBalance của nhóm Alpha , hãy gọi hợp đồng ibETH và hàm totalETH của nó. 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 các chức năng gửi và rút tiền của Rari được cấp lại và được gọi nhiều lần.
Chức năng làm việc là một chức năng trả phí, có 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 chức năng làm việc, từ đó 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ũng 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ố lượng ETH trong hợp đồng ibETH, đồng thời gọi rút tiền trong hợp đồng RariFundManager để mua lại nhiều tài sản hơn.
Sự cố này làm nổi bật những rủi ro đáng kể do 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ó nêu bật 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ư vậ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.
Trường hợp tài chính kem
Cream Finance đã phải hứng chịu một cuộc tấn công tinh vi khai thác hai điểm yếu cơ bản trong nền tảng: một nhà tiên tri trộn lẫn bị thao túng và nguồn cung cấp mã thông báo chưa được khai thác. Một phần quan trọng của cuộc tấn công là sự thao túng của 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, kẻ tấn công đã thay đổi tỷ giá hối đoái được báo cáo bởi kho tiền và do đó cũng ảnh hưởng đến giá trị cảm nhận của mã thông báo yUSD đối với nhà tiên tri.
Bài học quan trọng ở đây là một lời tiên đoán về giá mạnh mẽ và không thể thao túng là rất quan trọng đối với sự ổn định của giao thức DeFi. Các nhà tiên tri về giá trung bình theo trọng số thời gian (TWAP) có thể giúp ngăn chặn các vụ hack như vậy vì chúng có khả năng chống thao túng giá đột ngột hơn.
Những vấn đề này và các mẫu thiết kế mong manh khác có thể được giảm thiểu thông qua việc áp dụng và triển khai cẩn thận ERC-4626.
Rủi ro bảo mật tiềm ẩn trong ERC-4626
Luôn có một số 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, có thể có các vấn đề tiềm ẩn khi tích hợp chúng vào các hợp đồng thông minh cần được chú ý đặc biệt.
Quản lý mã thông báo phíOnTransfer
Nếu kho tiền được thiết kế để hỗ trợ mã thông báo feeOnTransfer, hãy kiểm tra xem số tiền và cổ phần trong kho tiền có nằm trong phạm vi dự kiến khi chuyển tài sản hay không.
Sử dụng hợp lý biến số thập phân
Mặc dù chức năng convertTo không cần sử dụng biến số thập phân của kho tiền EIP-4626, nhưng vẫn nên phản ánh số thập phân của mã thông báo cơ bản nếu khả thi. Phương pháp 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 giao diện người dùng và người dùng ngoại tuyến.
làm tròn
Theo thông số kỹ thuật, những người triển khai vault nên biết rằng các hướng làm tròn cụ thể và ngược lại được yêu cầu trong các phương thức xem và có thể thay đổi khác nhau, vì sẽ an toàn hơn nếu ưu tiên bản thân vault hơn người dùng trong quá trình tính toán:
Nếu nó đang tính số lượng cổ phần sẽ được phát hành cho người dùng đối với số lượng mã thông báo cơ bản mà họ cung cấp hoặc nếu nó đang hoạt động để chuyển một phần cụ thể của mã thông báo cơ bản cho người dùng, thì nó sẽ được làm tròn xuống.
Nếu nó đang tính toán số lượng cổ phiếu 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 nếu nó đ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ố lượng cổ phần nhất định, thì nó nên được làm tròn lên.
Trường hợp 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, hãy chỉ định rằng các chức năng này phải luôn làm tròn xuống. Các nhà tích hợp có thể tự bắt chước phiên bản làm tròn, chẳng hạn bằng cách thêm một Wei vào kết quả.
Số lượng tài sản cơ bản mà người dùng nhận được bằng cách mua lại cổ phần của họ trong kho tiền (previewRedeem) có thể thay đổi đáng kể so với số tiền phải trả để phát hành cùng một lượng 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 lớn (ví dụ: kho tiền thực hiện phí rút tiền hoặc gửi tiền). Do đó, các nhà tích hợp nên cẩn thận sử dụng các chức năng xem trước phù hợp nhất với trường hợp sử dụng của họ và không bao giờ cho rằng chúng có thể hoán đổi cho nhau.
Ghi đè chức năng cốt lõi
Để triển khai hoặc mở rộng chức năng dự định, nên sử dụng các hook hiện có thay vì thay đổi chức năng cốt lõi. Thực tiễn này đảm bảo một lộ trình dễ quản lý hơn để kiểm tra và kiểm tra mã hiệu quả.
Không chia sẻ
Thông số kỹ thuật ban đầu cho ERC-4626 không phác thảo cách xử lý trường hợp góc không có phần chia sẻ trong vault và liệu vault sẽ hoạt động như bình thường hay quay trở lại. Đây có thể là một nguồn tiềm ẩn của sự nhầm lẫn và sai sót.
Vault như lời tiên tri về giá
Liên quan đến nguy cơ bị các cuộc tấn công thao túng giá của nhà tiên tri, các giá trị được trả về bởi các phương pháp xem trước này càng gần với độ 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 để sử dụng làm tiên tri về giá. Thông số kỹ thuật ERC-4626 bao gồm một phương thức chuyển đổi và một phương thức TotalAssets cho phép tính không chính xác và do đó 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 sử dụng giá bình quân gia quyền theo thời gian để thực hiện phương pháp chuyển đổi là đúng.
Vấn đề triển khai cụ thể
Các nhà tích hợp phải xem xét mọi triển khai vault được mã hóa trước khi tích hợp thêm, vì có thể có các triển khai độc hại có vẻ phù hợp với đặc tả giao diện, nhưng các chức năng cốt lõi của chúng bao gồm các đặc tả thiết kế hoàn toàn khác.
Truy cập trực tiếp EOA
Nếu muốn truy cập trực tiếp vào kho tiền, thì việc triển khai kho tiền đó cần phải có các tính năng có thể được sử dụng để bù đắp tổn thất do trượt giá hoặc các giới hạn gửi/rút ngẫu nhiên. Không giống như các hợp đồng thông minh, EOA không có cơ chế dự phòng an toàn để 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ì không có cách nào để khôi phục.
Vault mở rộng
Khi nhiều người chơi 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 được triển khai cho tiêu chuẩn. 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 tính toán khác nhau trong một hợp đồng Vault duy nhất. Đương nhiên, việc triển khai càng sai lệch so với tiêu chuẩn ban đầu thì khả năng đưa 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 thấy tùy chọn tốt nhất của họ dựa trên trường hợp sử dụng để xác định giá trị thực tế có nguy cơ.
Điều quan trọng cần lưu ý là không phải phần bổ sung nhỏ nhất của mỗi giao thức dẫn đến các sự kiện thảm khốc, mà là tổng của chúng khi được tích hợp.
Các vectơ tấn công tiềm năng đượ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 kho tiền ERC-4626.