Aave Labs đã làm rõ rằng bản nâng cấp bảo mật V3.8 được đề xuất sẽ duy trì các giao dịch thanh lý flash-loan. Phản hồi ngày 23 tháng 10 giải thích cách bộ bảo vệ reentrancy sẽ tương tác với các tích hợp hiện có.
TL;DR: Biện pháp bảo vệ V3.8 được đề xuất của Aave loại bỏ các điểm nhập flash-loan. Việc phê duyệt của chính phủ và các cuộc kiểm tra bảo mật vẫn đang chờ xử lý.
Đề xuất, được đăng vào ngày 21 tháng 10 thêm một lớp bảo vệ cho các hoạt động của Pool. Các lớp bảo vệ này hạn chế khả năng của một hàm gọi lại bên ngoài nhập lại vào các hàm hợp đồng được bảo vệ trước khi cuộc gọi trước đó hoàn tất. Aave Labs cho biết flashLoan() và flashLoanSimple() sẽ được loại trừ, cho phép các hàm gọi lại của chúng tiếp tục kích hoạt các hành động của Pool, bao gồm cả thanh lý.
Tại sao hàm gọi lại lại quan trọng
Một hợp đồng thông minh nhận khoản vay chớp nhoáng cần thời gian trong giao dịch để thực hiện một số hành động với tài sản được vay. Hướng dẫn dành cho nhà phát triển của Aave mô tả một chuỗi trong đó Pool chuyển tài sản, gọi hợp đồng người nhận và sau đó kiểm tra các điều kiện thanh toán.
Đối với một khoản vay chớp nhoáng đơn giản, người nhận phải sẵn sàng trả lại số tiền đã vay cùng phí yêu cầu. Nếu giao dịch không đáp ứng được các điều kiện của nó, nó sẽ bị hoàn lại. Giao diện vay chớp nhoáng rộng hơn có thể bao gồm nhiều tài sản và, trong các điều kiện được phép, mở một vị thế nợ có tài sản đảm bảo.
Những cơ chế này giải thích tại sao phạm vi của bộ bảo vệ lại quan trọng. Một tích hợp thanh lý có thể cần vay một tài sản, hoàn trả một vị thế không lành mạnh và hoàn thành phần còn lại của giao dịch trước khi thanh toán. Việc chặn tất cả các tương tác tiếp theo với Pool một cách tùy tiện sẽ can thiệp vào chuỗi này.
Câu hỏi thiết kế quan trọng là những con đường quay trở lại giao thức nào là có chủ ý. Một ranh giới bảo mật hữu ích phải tính đến các mẫu giao dịch mà các tích hợp phụ thuộc vào, bao gồm các cuộc gọi xảy ra sau khi tài sản đã rời khỏi Pool nhưng trước khi kiểm tra việc hoàn trả.
Một khóa độ dài giao dịch
Việc triển khai được đề xuất sử dụng bộ lưu trữ tạm thời được giới thiệu thông qua Ethereum’s EIP-1153. Bộ lưu trữ này vẫn khả dụng trong suốt giao dịch và bị xóa khi giao dịch kết thúc. Do đó, nó có thể truyền trạng thái khóa tạm thời để theo dõi xem một thao tác được bảo vệ đã đang chạy hay chưa.
Thông số kỹ thuật xác định các khóa tái nhập là một trường hợp sử dụng và giải thích tại sao bộ nhớ tạm thời có thể tốn ít chi phí hơn so với việc ghi trạng thái tạm thời vào bộ nhớ vĩnh viễn. Đối với một giao thức DeFi được sử dụng rộng rãi, câu hỏi thiết kế bao gồm chi phí gây ra cho các giao dịch thông thường cũng như mức độ bảo vệ được thêm vào bởi bộ bảo vệ.
Con đường được đề xuất của Aave bao gồm phản hồi, bỏ phiếu qua Snapshot, đánh giá bảo mật và một đề xuất cải tiến trên chuỗi. Certora và các nhà đánh giá khác dự kiến sẽ đánh giá các thay đổi trước bước cuối cùng.
Đối với các nhà tích hợp trên Ethereum và các mạng bị ảnh hưởng khác, sự làm rõ này cung cấp một điểm tương thích cụ thể để kiểm tra với mã cuối cùng. Việc triển khai được xem xét phải duy trì trình tự giao dịch dự định đồng thời thực thi ranh giới mới. Một tuyên bố về ý định thiết kế là hữu ích trong quá trình đó; hành vi đã triển khai sẽ phụ thuộc vào quản trị triển khai mà cuối cùng được chấp nhận.
Được viết bởi Ban Biên tập Tin tức và hiệu đính bởi Samuel Rae.