Kiểm tra fuzz khác biệt trên thư viện điểm cố định Solidity

Đọc bài viết này mất 14 phút

Trong thế giới blockchain, mã là luật và việc đảm bảo tính bảo mật của mã là rất quan trọng.

Tiêu đề gốc: "Làm mờ vi phân trên các thư viện điểm cố định vững chắc"

Nguồn gốc: 0xNorman

Giới thiệu

Bảo mật là một trong những khía cạnh quan trọng nhất của việc viết hợp đồng thông minh. Các nhà phát triển có thể quen thuộc với các bài kiểm tra đơn vị truyền thống để kiểm tra mã của họ, nhưng điều này chỉ cung cấp phạm vi cơ bản để kiểm tra chức năng và logic nghiệp vụ của mã. Tuy nhiên, họ hoạt động dựa trên giả định rằng hợp đồng thông minh sẽ hoạt động như mong đợi trong các điều kiện nhất định. Để tăng cường hơn nữa tính bảo mật, chúng tôi cần áp dụng các phương pháp thử nghiệm nâng cao hơn, chẳng hạn như làm mờ vi phân.

Thử nghiệm fuzz khác biệt là một loại thử nghiệm bao gồm việc thực hiện các hoạt động triển khai khác nhau của cùng một chức năng hoặc các chức năng và so sánh kết quả. Loại thử nghiệm này cho phép chúng tôi xác minh rằng các cách triển khai khác nhau là tương đương và hoạt động nhất quán khi được cung cấp thông tin đầu vào không hợp lệ hoặc ngẫu nhiên. Điều này khác với thử nghiệm fuzz thông thường, thường được thực hiện bằng cách cung cấp cho một lần triển khai duy nhất nhiều loại đầu vào ngẫu nhiên và giám sát hành vi không mong muốn, sự cố hoặc lỗ hổng bảo mật.

Trong dự án này, chúng tôi sử dụng Foundry cho các thư viện điểm cố định khác nhau (OpenZeppelin, Solmate, Solady and Prbmath) để kiểm tra fuzz vi sai. Xin lưu ý rằng trong số một số phiên bản chính của thư viện Solmate, chúng tôi đã sử dụng cơ sở mã (v6) mới nhất vì chúng tôi tin rằng hầu hết các dự án mới chọn thư viện Solmate sẽ chọn phiên bản này. Chúng tôi muốn kiểm tra xem liệu có sự khác biệt đáng kể nào trong việc triển khai cùng một chức năng giữa các cơ sở mã khác nhau hay không. Sau khi chạy 10 triệu thử nghiệm, chúng tôi nhận thấy khả năng tương thích rộng rãi giữa các thư viện này, nhưng có một số khác biệt trong việc xử lý các trường hợp khó khăn và mức tiêu thụ gas.

Sự khác biệt cụ thể Chúng tôi sẽ minh họa sự khác biệt trong việc triển khai các thư viện này thông qua các ví dụ sau. Trong hàm Log2 (trả về logarit cơ số 2), việc triển khai OpenZeppelin và Solary trả về các kết quả khác nhau nếu đầu vào là 0. OpenZeppelin sẽ chỉ trả về 0, trong khi Solary sẽ trả về 0x5be3aa5c (chữ ký của Log2Und xác định()).

Vì vậy, chúng tôi thêm if (num != 0) vào trường hợp thử nghiệm để tránh sự khác biệt này. Sự khác biệt tương tự cũng xảy ra trong hàm mulDiv(). Chúng ta cần đảm bảo rằng số chia không bằng 0 và không có tràn. Nếu không, OZ và Solary sẽ báo lỗi. Ví dụ: Solady sẽ trả về 0xad251c27, đây là chữ ký của MulDivFailed(), vì vậy chúng tôi cũng đã thêm câu lệnh if. Nếu bạn muốn tái tạo một điều kiện lỗi trong thử nghiệm của mình, hãy nhận xét câu lệnh if và sử dụng một trường hợp thử nghiệm cụ thể.

Và hãy tham khảo cách triển khai thư viện để hiểu lý do tại sao họ lại xử lý theo cách này.

Báo cáo khí

Vì hầu hết các chức năng trong các thư viện này đều tương thích với nhau nên chúng tôi đã so sánh mức tiêu thụ gas của chúng để phát hiện cơ sở dữ liệu nào tiết kiệm nhất. Bạn có thể tìm thấy ảnh chụp nhanh chi phí gas trong tệp .gas-snapshot. Để dễ đọc hơn, chúng tôi đã đính kèm báo cáo hóa đơn gas đơn giản (mức tiêu thụ gas trung bình cho mỗi lệnh gọi chức năng).

Hoặc bạn có thể chạy lệnh này để lấy nó.

Chúng tôi nhận thấy rằng mức tiêu thụ gas của OpenZeppelin cao hơn nhiều so với các hàm trong các thư viện mã khác. Đặc biệt, các hàm như OzLog2, OzLog2Up, OzMulDivDown, OzMulDivUp và OzSqrt tiêu thụ nhiều gas hơn so với các hàm tương ứng trong các thư viện khác. Trong số các thư viện còn lại, năng lượng mặt trời có chi phí gas tốt nhất.

Mức tiêu thụ gas của tất cả các chức năng được so sánh trong thư viện solady tương đối thấp và nó cung cấp chức năng toàn diện nhất, khiến nó trở thành lựa chọn hàng đầu cho các nhà phát triển nâng cao. Tuy nhiên, điều đáng chú ý là chỉ và Solmate ;Được kiểm tra bởi nhóm bảo mật bên ngoài.

Ngay cả Solmate cũng không được thiết kế để dễ sử dụng, vì vậy bạn nên đọc kỹ tài liệu và hiểu rõ về cơ sở mã trước khi tự bắn vào chân mình. Tin vui là Cantina đã quyết định kiểm tra thư viện Solady như một dự án công cộng và bạn có thể theo dõi quá trình kiểm tra của họ tại đây trạng thái.

Kiểm tra mờ đầy đủ

Để đảm bảo tính mờ Để kiểm tra Để đảm bảo tính chính xác, chúng tôi đã tiến hành thử nghiệm lông tơ 9999999 lần. Thông thường, không cần phải chạy chương trình này nhiều lần trong quá trình phát triển, nhưng với tư cách là nhà nghiên cứu bảo mật, chúng tôi muốn đề cập đến càng nhiều thông tin đầu vào ngẫu nhiên càng tốt. Bạn có thể thay đổi tần suất chạy trong [foundry.toml] . Nhiều lần chạy hơn có nghĩa là có nhiều đầu vào ngẫu nhiên hơn cho hàm. Nếu bạn muốn chạy thử nghiệm nhanh, chẳng hạn như để tích hợp liên tục, hãy điều chỉnh cấu hình theo nhu cầu của bạn.

Được xây dựng trên nền tảng của chúng tôi

Bên trong thư viện Solidity rộng lớn, điểm cố định số học chỉ là một khía cạnh. Để mở rộng phạm vi nghiên cứu này, chúng ta có thể so sánh các thư viện xử lý các chức năng khác nhau, sử dụng các phiên bản pragma khác nhau. Điều này sẽ giúp chúng ta hiểu biết rộng hơn về bảo mật trong các trường hợp sử dụng và phiên bản Solidity khác nhau. Ngoài ra, chúng tôi có thể ghi lại dữ liệu đầu vào ngẫu nhiên được Foundry sử dụng và phân tích nó. Điều này sẽ cho phép chúng tôi đánh giá xem những đầu vào này có thực sự ngẫu nhiên hay không và đảm bảo đánh giá thư viện một cách công bằng và toàn diện.

Kết luận

Chúng tôi thực hiện việc làm mờ sự khác biệt Mục đích chính của thử nghiệm là tìm ra sự khác biệt đáng kể trong kết quả đầu ra của thư viện điểm cố định Solidity của OpenZeppelin, Solmate, Solary và PRB-Math. Mặc dù các thư viện này hoạt động tốt về mặt khả năng tương thích nhưng thử nghiệm của chúng tôi đã tìm thấy những khác biệt nhỏ trong cách chúng xử lý các trường hợp khó khăn, đặc biệt là trong các hàm Log2 và mulDiv.

Mặc dù những khác biệt này có vẻ nhỏ nhưng chúng có thể dẫn đến hành vi không mong muốn trong hợp đồng thông minh và do đó rất đáng kể. Thông qua công việc này, chúng tôi hy vọng sẽ cung cấp cho các nhà phát triển những hiểu biết chi tiết để hướng dẫn họ đưa ra quyết định khi chọn thư viện cho các ứng dụng hợp đồng thông minh. Nghiên cứu của chúng tôi không tìm thấy sự sai lệch đáng kể nào giữa các thư viện này.

Tuy nhiên, những khác biệt tinh tế mà chúng tôi quan sát được đóng vai trò như một lời nhắc nhở về tầm quan trọng của việc kiểm tra đầy đủ và hiểu rõ mã đang được sử dụng. Trong thế giới blockchain, mã là luật và việc đảm bảo tính bảo mật của mã là rất quan trọng. Thử nghiệm fuzz khác biệt của các thư viện Solidity là một bước hướng tới mục tiêu này và cung cấp mức độ đảm bảo cao hơn so với thử nghiệm đơn vị. Chúng tôi mong muốn được thấy một hệ sinh thái mã hóa an toàn hơn.