Các dự án trên NEAR được kiểm toán như thế nào?

Hôm nay chúng ta sẽ cùng tìm hiểu một số cách thức mà một đội ngũ chuyên nghiệp áp dụng trong việc kiểm toán(audit) các hợp đồng thông minh triển khai trên blockchain NEAR. Trong bài viết này, chúng ta sẽ chỉ tập trung vào những điểm chính cần lưu ý khi kiểm toán các dự án trên NEAR. Mọi thứ bạn đọc dưới đây đều dựa trên kinh nghiệm cá nhân của đội ngũ Pessimistic!

Trước hết, chúng tôi muốn bày tỏ lòng biết ơn chân thành tới những người đã và đang xây dựng nên NEAR Protocol và các dự án trên hệ sinh thái NEAR, cùng với đó là tất cả những người đã hỗ trợ, soạn thảo các tài liệu nguồn và tất nhiên là các kiểm toán viên xuất sắc, những người đã giúp phát hiện và chia sẻ những thông tin hữu ích về cách kiểm toán một dự án trên NEAR. Và hôm nay, độc giả thân mến, những thông tin này sẽ được cung cấp tới bạn.

Những mẹo mà chúng tôi sắp chia sẻ dưới đây cũng được công khai ở một số nguồn khác, ví dụ như blog của chúng tôi. Đây là những mẹo và thủ thuật được tích lũy dựa trên sự quan sát và kinh nghiệm từ các kiểm toán viên giỏi nhất của chúng tôi, chúng ta hãy cùng bắt đầu thôi nào!

1 phút quảng cáo, nếu như dự án của các bạn cần được kiểm toán, vui lòng gửi yêu cầu tới chúng tôi, bạn có thể theo dõi báo cáo kiểm toán của các dự án mà chúng tôi đã thực hiện tại đây.

1. Tìm hiểu về blockchain NEAR

• NEAR là một blockchain layer 1, sử dụng cơ chế đồng thuận Proof of Stake và lưu trữ theo kiến trúc phân đoạn (sharding). Bằng việc áp dụng công nghệ sharding, NEAR cung cấp các giải pháp cho các vấn đề như tốc độ xử lý chậm, tắc nghẽn mạng và phí gas cao, cho phép khả năng mở rộng đáng kể mà không ảnh hưởng đến độ bảo mật của giao thức.
• Điều quan trọng cần lưu ý là NEAR là một sharded blockchain có thể mở rộng, có nghĩa là các hợp đồng thông minh đã triển khai được biên dịch thành định dạng WebAssembly (WASM) và có thể được viết bằng các ngôn ngữ:
  • Rust
  • AssemblyScript (ngôn ngữ giống với TypeScript có thể biên dịch ra WebAssembly)
  • Solidity (hoạt động trên Aurora EVM)
  • Javascript (hoạt động trên máy ảo Javascript JS-VM)

• Việc sử dụng WASM giúp tối ưu phí gas, tạo khối nhanh và phí giao dịch thấp hơn. Hợp đồng thông minh trong NEAR có thể được coi là micro-service chứa dữ liệu và mã thực thi. Tương tác giữa các hợp đồng được thực hiện bất đồng bộ.
• Với tất cả các yếu tố trên, theo quan điểm của chúng tôi, hệ sinh thái NEAR phần lớn được xây dựng dựa trên ngôn ngữ lập trình Rust.
• NEAR cũng là nền tảng tập hợp hàng ngàn thành viên cộng đồng, mang lại trải nghiệm người dùng thoải mái nhất, cũng như một hệ sinh thái rộng lớn.

• Một số điểm nổi bật khác của blockchain NEAR:
  • Về vấn đề sản xuất khối một cách bảo mật, NEAR sử dụng cơ chế được gọi là Doomslug. Doomslug thật ra khá đơn giản, cơ chế này dựa trên giả định rằng các trình xác thực khác nhau thay phiên nhau tạo ra các khối dựa trên số lượng token NEAR mà họ đã stake.
  • Chúng tôi sẽ không đi vào chi tiết trong bài viết này vì chúng tôi cho rằng bạn, độc giả thân mến, đã có đủ hiểu biết về hệ sinh thái NEAR, vì vậy chúng tôi thực sự khuyên bạn nên truy cập cơ sở kiến thức của họ và nghiên cứu tài liệu dự án để hiểu rõ hơn: https://near.org/learn/

2. Quy trình đánh giá một dự án trên NEAR của Pessimistic.io

• Những trở ngại chính mà kiểm toán viên có thể gặp phải khi thực hiện kiểm toán các dự án trên NEAR là tính logic của mã nguồn, nên lời khuyên đầu tiên của chúng tôi cho bất kỳ nhóm kiểm toán nào là hãy phát triển năng lực chuyên môn, từ đó nắm chắc các tài liệu kỹ thuật và tạo ra các bản thử nghiệm có độ tin cậy cao. Điều này có vẻ khá hiển nhiên, nhưng hãy chắc chắn rằng các bạn có quy trình tốt và đã hoạt động ổn định trong một thời gian nhất định.
• Sau đây, nhóm kiểm toán xuất sắc của chúng tôi muốn giới thiệu cho bạn bộ quy tắc riêng của mình, được tích lũy qua nhiều năm làm việc, trong đó chúng tôi sẽ cố gắng truyền đạt mọi thứ thật ngắn gọn và súc tích. Cụ thể, chúng tôi thực hiện việc kiểm toán theo các thủ tục sau:

1. Phân tích tự động:

   • Biên dịch các hợp đồng thông minh
   • Chạy các bộ unit test mà dự án đã dựng sẵn và kiểm tra xem bộ test này có bao quát đầy đủ các trường hợp có thể xảy ra không
   • Chạy các công cụ phân tích và xác minh một cách thủ công (từ chối hoặc xác nhận) từng vấn đề được báo cáo (chi tiết bên dưới)

2. Kiểm toán thủ công

   • Xem xét cẩn thận mã nguồn và đánh giá chất lượng
   • Kiểm tra xem trong mã nguồn có các lỗ hổng thường gặp không
   • Kiểm tra mã nguồn sau khi được biên dịch có chạy đúng theo logic đã được nêu trong tài liệu của dự án không
   • Đề xuất các giải pháp tối ưu phí gas và phí lưu trữ on-chain

3. Các vấn đề mà dự án thường gặp

   • Các sự cố liên quan tới việc kiểm soát truy cập tới hợp đồng thông minh (xác định/ủy quyền quản trị viên hoặc người dùng không chính xác);
   • Các vấn đề về tài sản bị mất/bị đánh cắp (tài sản bị mắc kẹt trong hợp đồng hoặc bị gửi tới sai tài khoản);
   • DoS do các vấn đề logic (deadlock, lỗi máy trạng thái, v.v.);
   • DoS do sự cố kỹ thuật (Lỗi hết phí gas, các hạn chế khác);
   • Các vấn đề về tương tác hợp đồng (lỗ hổng reentrancy, gọi hàm không an toàn, giả định của người gọi);
   • Các vấn đề số học (tràn số, làm tròn số);
   • Sử dụng NEAR SDK không hợp lý
   • Các vấn đề khác.

4. Phí Gas

Chúng tôi kiểm tra xem các hoạt động tương tác với hợp đồng thông minh sử dụng nhiều gas có được thực hiện hiệu quả hay không

• Các cấu trúc dữ liệu — các cấu trúc dữ liệu từ thư viện std::collections khi được đọc cùng nhau, làm tăng mức tiêu thụ gas. Bạn nên sử dụng near_sdk::collections hoặc near_sdk::store;
• Các cấu trúc dữ liệu có mối quan hệ trực tiếp với bộ nhớ được lưu trữ trên blockchain và bạn có thể vô tình quên đồng bộ hóa chúng;
• Các cấu trúc dữ liệu dạng key-value: LookupMap / UnorderedMap / TreeMap — Bạn cần chọn theo chức năng cần thiết (LookupMap có phí gas rẻ nhất, trong khi TreeMap hỗ trợ nhiều tính năng nhất);
• LazyOption — dành cho “dữ liệu lớn” và hiếm khi được sử dụng (chỉ có thể được sử dụng trong hàm khởi tạo constructor);
• Borsh/JSON để tuần tự hóa các gói tin được truyền đi hay trả về trên blockchain (tham số/giá trị trả về) — ảnh hưởng đến mức tiêu thụ gas;
• Hãy tham khảo kỹ Cuộc tấn công “hàng triệu lượt bổ sung dữ liệu giá rẻ” để tránh gặp phải vấn đề tương tự.

5. Các công cụ

Sau đây là các công cụ phân tích tự động mà bạn có thể sử dụng trong công việc của mình:

• Valgrind — có thể được sử dụng nếu mã nguồn bao gồm các block không an toàn gây nguy hiểm trong cấp phát bộ nhớ. Tuy nhiên, việc sử dụng các đoạn mã nguồn không an toàn này vốn dĩ đã là dấu hiệu cho thấy dự án có nhiều lỗ hổng. Nói chung, Valgrind không có quá nhiều công dụng
• Cargo Geiger là một công cụ hiển thị số liệu thống kê về việc sử dụng mã Rust không an toàn trong một thư viện Rust và các đoạn mã phụ thuộc của nó. Công cụ này giúp phát hiện các vấn đề có thể xảy ra do các đoạn mã nguồn nguy hiểm của dự án và từ đó giúp chúng ta tập trung giải quyết các lỗ hổng lớn
• Cargo Audit — kiểm tra các tệp để tìm thư viện Rust chứa lỗ hổng bảo mật. Công cụ này giúp hiển thị các thư viện đã lâu chưa được cập nhật mà mọi người vẫn sử dụng. Bạn nên sử dụng nó cho mục đích kiểm toán.
• Trình phân tích tĩnh Clippy là một công cụ tuyệt vời để phát hiện các lỗi cú pháp phổ biến và cải thiện mã nguồn Rust của bạn.
• Cargo Tarpaulin — dành cho việc kiểm tra độ phủ của test case — một công cụ rất tiện dụng cho biết số lượng code chưa được kiểm thử.

3. Các bản báo cáo kiểm toán công khai của Pessimistic

   • Các báo cáo kiểm toán công khai của các dự án trên hệ sinh thái NEAR của chúng tôi được cấu trúc theo sơ đồ luồng kiểm toán được trình bày ở trên, vì vậy chúng tôi khuyên bạn hãy xem qua các báo cáo này, đặc biệt là kết quả của chúng, với quy trình được trình bày ở phần trước:
     • Phân tích bảo mật dự án Sweat Economy – Audit bởi Pessimistic
     • Phân tích bảo mật dự án Neartar – Audit bởi Pessimistic
       • Chúng tôi hy vọng rằng bài viết đã cung cấp nhiều thông tin hữu ích cho bạn! Cảm ơn bạn đã đọc! Và đừng quên cho chúng tôi biết chúng tôi nên tham khảo thêm những công cụ nào, bạn quan tâm đến điều gì khi đọc blog của chúng tôi?
       • Nếu bạn vẫn còn thắc mắc, hãy liên hệ! Chúng tôi luôn sẵn lòng trả lời mọi câu hỏi của bạn! Các câu trả lời và câu hỏi hay nhất có thể được đưa vào bài đăng blog tiếp theo!
       • 5 phút nữa cho quảng cáo :)), nếu dự án của bạn cần được kiểm toán, hãy liên hệ ngay với chúng tôi! Bạn có thể xem danh sách các dự án được Pessimistic kiểm toán tại đây.