iZiFinance là một giao thức tài chính phi tập trung sử dụng zkSync, một giải pháp mở rộng lớp 2 cho Ethereum. zkSync cho phép giao dịch nhanh và chi phí thấp trên Ethereum trong khi vẫn giữ được tính bảo mật và khả năng kết hợp của mạng lớp 1. Tuy nhiên, tối ưu hóa gas vẫn là một khía cạnh quan trọng khi thực hiện phát triển hợp đồng thông minh trên zkSync, vì nó ảnh hưởng đến hiệu suất và lợi nhuận của giao thức.
Trong phân tích này, chúng tôi sẽ kiểm tra một trong những hợp đồng cốt lõi của iZiFinance, iZiSwapPool.sol và tìm ra một cách đơn giản để giảm mức tiêu thụ gas bằng cách loại bỏ biểu thức dư thừa.
hợp đồng iZiSwapPool
Hợp đồng iZiSwapPool thực hiện logic của nhóm thanh khoản và trao đổi mã thông báo trên iZiFinance. Nó tuân theo giao diện IiZiSwapPool, giao diện này xác định các chức năng và sự kiện của hợp đồng. Một trong những chức năng này là modifyFeeChargePercent, cho phép chủ sở hữu hợp đồng điều chỉnh tỷ lệ phần trăm phí tính trên mỗi nhóm. Tỷ lệ phần trăm thu phí là một tham số xác định việc phân phối phí trao đổi giữa các nhà cung cấp thanh khoản và giao thức. Mã của hàm modifyFeeChargePercent như sau:
Hàm này chấp nhận một tham số thuộc loại uint24 được gọi là newFeeChargePercent, đại diện cho tỷ lệ phần trăm tính phí mới sẽ được đặt. Nó cũng có một số công cụ sửa đổi và câu lệnh yêu cầu để đảm bảo rằng chỉ chủ sở hữu mới có thể gọi hàm và newFeeChargePercent là hợp lệ. Phân tích mã Mã hợp đồng này được viết bằng Solidity, đại diện cho chức năng sửa đổi tỷ lệ phần trăm thu phí. Có vẻ như nó đã được thiết kế theo cách an toàn, có tính đến các hạn chế được áp dụng trước khi sửa đổi thực tế (dòng 534-536).
Tuy nhiên, dòng 535 require(newFeeChargePercent >= 0, "FP0"); thực sự không cần thiết. Điều này là do trong Solidity, kiểu dữ liệu uint (unsigned integer) không được âm. uint24 là một loại số nguyên không dấu nằm trong khoảng từ 0 đến 2^24 - 1.
Do đó, việc kiểm tra xem newFeeChargePercent có lớn hơn hoặc bằng 0 hay không là một phép lặp, bởi vì một số nguyên không dấu không thể nhỏ hơn 0 theo định nghĩa. Do đó, dòng này tạo thành một tautology và có thể được gỡ bỏ một cách an toàn mà không ảnh hưởng đến chức năng của mã hoặc tạo ra bất kỳ lỗ hổng bảo mật nào. Dòng ngay sau nó, require(newFeeChargePercent <= 100, "FP0");, đủ để đảm bảo rằng newFeeChargePercent nằm trong phạm vi dự kiến (0-100).
rủi ro tập trung
Chúng tôi cũng đã xác định một số rủi ro tập trung có thể ảnh hưởng đến tính bảo mật của giao thức và tính bảo mật của tài sản người dùng.
rủi ro tập trung
Chúng tôi cũng đã xác định một số rủi ro tập trung có thể ảnh hưởng đến tính bảo mật của giao thức và tính bảo mật của tài sản người dùng.
Lời khuyên an toàn
Đối với nhóm dự án iZiFinance, đây là 10 mẹo an toàn để bảo vệ tài sản trên chuỗi của người dùng khỏi rủi ro tập trung.
- Khóa thời gian được áp dụng cho các chức năng chính như setFarm() và setWrapToken(), chỉ cho phép sửa đổi tại một thời điểm xác định trong tương lai, giúp cộng đồng có thời gian thảo luận và đạt được sự đồng thuận
- Yêu cầu phê duyệt nhiều chữ ký của nhiều địa chỉ ví để gọi các chức năng như enableFeeAmount() và newPool() ảnh hưởng đến phí và phần thưởng
- Triển khai kiểm soát truy cập dựa trên vai trò cho các chức năng như expandObservationQueue() và CollectFeeCharged(), hạn chế chỉ gọi các vai trò được chỉ định
- Khi hợp đồng được triển khai, hãy đặt các tham số cốt lõi như startBlock, endBlock, bonusPerBlock không thay đổi và các thay đổi tiếp theo không được phép
- Thiết lập cấu trúc quản trị DAO yêu cầu cộng đồng đề xuất và bỏ phiếu cho các cuộc gọi đến các chức năng nhạy cảm
- Áp dụng kiến trúc mô-đun để phân tách trách nhiệm và tránh tập trung quá mức vào bất kỳ mô-đun đơn lẻ nào
- Thiết lập cơ chế dừng khẩn cấp với xác thực đa chữ ký, có thể tạm dừng thỏa thuận nếu xảy ra sự cố
- Thường xuyên tiến hành kiểm toán bảo mật bên ngoài và xử lý các vấn đề được phát hiện kịp thời để giảm rủi ro kiểm soát tập trung
- Trong quá trình phát triển, sử dụng fuzzing và các phương pháp khác để xác định và loại bỏ các lỗ hổng kiểm soát tập trung
- Tuân thủ nguyên tắc đặc quyền tối thiểu và chỉ cấp cho vai trò và tài khoản những quyền tối thiểu cần thiết
Những rủi ro tập trung hóa này xuất phát từ thực tế là chủ sở hữu hợp đồng có thể có quyền kiểm soát quá mức đối với các tham số và chức năng của hợp đồng, điều này có thể cho phép chủ sở hữu thao túng giao thức hoặc gây hại cho người dùng. Chúng tôi cũng hy vọng phân tích này có thể cung cấp một số hiểu biết hữu ích và đề xuất bảo mật để cải thiện hợp đồng thông minh của iZiFinance.
Theo chúng tôi
Twitter: @MetaTrustLabs
Trang web: metatrust.io
Tất cả bình luận