Một báo cáo kiểm toán smart contract không nên được đọc như giấy chứng nhận an toàn. Đây là kết quả đánh giá một phạm vi mã nguồn xác định, tại một thời điểm và phiên bản cụ thể, theo phương pháp của đơn vị audit.
Điều quan trọng nhất không phải logo công ty kiểm toán hay số lượng phát hiện, mà là trả lời được ba câu hỏi: mã nào đã được kiểm tra, các lỗ hổng đã được xử lý đến đâu và hợp đồng đang chạy trên blockchain có đúng là phiên bản đã audit hay không.
Báo cáo audit smart contract cho biết điều gì?
Báo cáo audit thường mô tả:
- Dự án, giao thức hoặc nhóm hợp đồng được đánh giá.
- Phạm vi kiểm toán, gồm repository, thư mục, tệp hoặc contract cụ thể.
- Git commit, tag hoặc phiên bản mã nguồn tại thời điểm kiểm tra.
- Phương pháp đánh giá như rà soát thủ công, kiểm thử, phân tích tĩnh hoặc kiểm tra thuộc tính.
- Các phát hiện và mức độ nghiêm trọng tương ứng.
- Phản hồi của đội ngũ phát triển.
- Trạng thái khắc phục của từng phát hiện.
- Giả định, phần loại trừ và giới hạn trách nhiệm của đơn vị audit.
Audit có thể giúp phát hiện lỗi logic, sai sót kiểm soát truy cập, rủi ro thao túng giá, vấn đề tính toán hoặc hành vi không mong muốn. Tuy nhiên, audit không chứng minh rằng hợp đồng không còn lỗ hổng, không bị quản trị lạm dụng và sẽ luôn hoạt động an toàn trong mọi điều kiện thị trường.
Khi đánh giá một dự án blockchain, nên kết hợp báo cáo audit với khung kiểm tra whitepaper dự án crypto, mô hình quản trị, tokenomics, dữ liệu on-chain và quyền kiểm soát hợp đồng.
Cách đọc báo cáo audit smart contract theo từng bước
1. Xác nhận tên dự án và thời điểm kiểm toán
Trước tiên, kiểm tra tên giao thức, phiên bản sản phẩm, ngày bắt đầu và ngày hoàn tất đánh giá. Một dự án có thể trải qua nhiều lần audit cho các phiên bản khác nhau, nên báo cáo cũ chưa chắc còn phù hợp với mã hiện tại.
Cũng cần phân biệt:
- Audit trước khi triển khai mainnet.
- Audit sau khi hợp đồng đã hoạt động.
- Audit cho bản nâng cấp hoặc module mới.
- Đánh giá lại sau khi đội ngũ sửa lỗi.
Ngày phát hành báo cáo không tự động cho biết ngày của phiên bản mã được audit. Git commit và lịch sử thay đổi mới là căn cứ quan trọng hơn.
2. Đọc phạm vi kiểm toán trước phần kết luận
Phạm vi kiểm toán, thường được ghi là “scope”, cho biết chính xác phần mã nào nằm trong cuộc đánh giá. Hãy tìm các thông tin như:
- URL repository hoặc tên kho mã nguồn.
- Nhánh, tag hoặc Git commit.
- Danh sách thư mục và tệp Solidity, Vyper hoặc ngôn ngữ liên quan.
- Các contract, thư viện và interface được kiểm tra.
- Những thành phần bị loại trừ.
Ví dụ giả định: báo cáo chỉ kiểm tra contract staking nhưng ứng dụng còn sử dụng token, cầu nối và oracle. Khi đó, không thể suy rộng kết luận của báo cáo sang toàn bộ hệ thống.
Các thành phần ngoài chuỗi như website, API, bot quản trị, máy chủ ký giao dịch và giao diện ví thường không nằm trong phạm vi audit smart contract, trừ khi báo cáo nói rõ. Vì vậy, hợp đồng an toàn hơn không đồng nghĩa website hoặc tài khoản quản trị không thể bị tấn công.
3. Kiểm tra commit mã nguồn
Git commit là dấu vết giúp xác định phiên bản mã đã được kiểm toán. Commit thường xuất hiện dưới dạng một chuỗi ký tự đại diện cho trạng thái cụ thể của repository.
Khi đọc báo cáo, cần xác định:
- Commit ban đầu được dùng để audit.
- Commit chứa các bản sửa lỗi, nếu có.
- Commit cuối cùng được đơn vị audit xem xét lại.
- Có thay đổi nào sau commit cuối hay không.
Chỉ ghi tên nhánh như main hoặc master là chưa đủ chắc chắn vì nội dung nhánh có thể tiếp tục thay đổi. Tag cũng cần được đối chiếu với commit mà nó trỏ tới.
Bạn có thể áp dụng quy trình đánh giá GitHub dự án crypto để xem lịch sử commit, người đóng góp và các thay đổi sau thời điểm audit. Repository riêng tư hoặc không còn truy cập được sẽ làm giảm khả năng xác minh độc lập.
4. Đọc phương pháp và giả định kiểm toán
Đơn vị audit có thể sử dụng rà soát thủ công, unit test, fuzzing, phân tích tĩnh, kiểm tra bất biến hoặc formal verification. Mỗi phương pháp có phạm vi và giới hạn khác nhau.
Không nên kết luận chất lượng audit chỉ từ danh sách công cụ. Cần xem báo cáo có mô tả các thuộc tính quan trọng đã kiểm tra hay không, chẳng hạn:
- Chỉ tài khoản hợp lệ mới được thực hiện thao tác đặc quyền.
- Tổng tài sản hoặc số dư được hạch toán nhất quán.
- Người dùng không thể rút nhiều hơn quyền lợi của mình.
- Giá từ oracle không thể bị sử dụng trong điều kiện không hợp lệ.
- Quy trình nâng cấp không vượt ngoài quyền đã công bố.
Các giả định cũng rất quan trọng. Chẳng hạn, kiểm toán viên có thể giả định quản trị viên đáng tin cậy, oracle hoạt động đúng hoặc token tích hợp tuân theo chuẩn thông thường. Nếu giả định không còn đúng trong thực tế, kết luận của audit có thể không còn áp dụng đầy đủ.
Cách hiểu mức độ nghiêm trọng của lỗ hổng
Báo cáo audit smart contract thường phân loại phát hiện thành Critical, High, Medium, Low và Informational. Một số đơn vị dùng tên gọi hoặc thang đánh giá khác, vì vậy phải đọc định nghĩa ngay trong báo cáo thay vì mặc định mọi công ty chấm giống nhau.
Thông thường, mức độ nghiêm trọng lỗ hổng được cân nhắc dựa trên hai yếu tố:
- Tác động: tài sản có thể bị mất hay đóng băng, quyền quản trị có thể bị chiếm, hoặc hoạt động giao thức có thể bị gián đoạn hay không.
- Khả năng khai thác: kẻ tấn công cần điều kiện gì, có cần đặc quyền, vốn lớn, thời điểm đặc biệt hoặc sự phối hợp từ bên khác hay không.
Critical và High
Đây thường là các vấn đề có khả năng gây hậu quả lớn, như rút tài sản trái phép, chiếm quyền kiểm soát hoặc phá vỡ chức năng cốt lõi. Tuy nhiên, tên mức độ không thay thế việc đọc mô tả kỹ thuật và kịch bản khai thác.
Một lỗi có tác động rất lớn nhưng chỉ xuất hiện dưới điều kiện hiếm gặp vẫn cần được xem xét nghiêm túc. Ngược lại, một lỗi dễ kích hoạt nhưng chỉ gây ảnh hưởng nhỏ có thể được xếp thấp hơn.
Medium và Low
Các phát hiện này không nên bị bỏ qua. Lỗi Medium có thể trở nên đáng kể khi kết hợp với lỗi khác, thay đổi điều kiện thị trường hoặc một bản nâng cấp sau này. Lỗi Low đôi khi phản ánh kiểm tra đầu vào chưa đầy đủ, hành vi biên hoặc thiết kế dễ gây nhầm lẫn.
Informational và gas optimization
Informational thường là khuyến nghị về chất lượng mã, tính rõ ràng, khả năng bảo trì hoặc thực hành phát triển. Gas optimization tập trung vào chi phí thực thi. Hai nhóm này thường không được coi là lỗ hổng trực tiếp, nhưng vẫn có thể chỉ ra khu vực mã phức tạp hoặc cần cải thiện.
Đừng chỉ đếm số phát hiện để so sánh hai dự án. Một báo cáo có nhiều khuyến nghị nhỏ chưa chắc kém hơn báo cáo không ghi nhận lỗi, vì phạm vi, độ sâu và cách phân loại của mỗi đơn vị có thể khác nhau.
Kiểm tra lỗ hổng đã được khắc phục hay chưa
Mỗi phát hiện thường đi kèm một trạng thái. Các cách ghi phổ biến gồm:
- Resolved hoặc Fixed: đội ngũ đã sửa và kiểm toán viên đã xem xét bản sửa theo phạm vi được nêu.
- Partially resolved: mới xử lý một phần hoặc vẫn còn trường hợp chưa được giải quyết.
- Mitigated: rủi ro được giảm bằng biện pháp kỹ thuật hoặc vận hành nhưng chưa bị loại bỏ hoàn toàn.
- Acknowledged: đội ngũ thừa nhận vấn đề nhưng chấp nhận rủi ro hoặc chưa sửa.
- Unresolved hoặc Open: phát hiện vẫn tồn tại tại thời điểm báo cáo hoàn tất.
- Disputed: đội ngũ và kiểm toán viên không thống nhất về tác động hoặc cách phân loại.
Cụm từ “lỗ hổng đã khắc phục” chỉ đáng tin trong phạm vi commit được kiểm tra lại. Hãy đọc cả phần phản hồi của dự án và phần xác nhận của kiểm toán viên. Việc đội ngũ tự tuyên bố đã sửa không đồng nghĩa bản sửa đã được tái kiểm toán.
Với từng lỗi đáng chú ý, nên ghi lại:
- Nguyên nhân kỹ thuật.
- Điều kiện khai thác.
- Tài sản hoặc chức năng bị ảnh hưởng.
- Bản sửa nằm ở commit nào.
- Kiểm toán viên có xác nhận lại hay không.
- Bản sửa đó có xuất hiện trong hợp đồng đang vận hành không.
Đối chiếu báo cáo audit với hợp đồng đang vận hành
Đây là bước thường bị bỏ qua nhất. Báo cáo kiểm toán một repository không tự chứng minh rằng địa chỉ contract người dùng đang tương tác được triển khai từ đúng mã đó.
Xác định đúng mạng và địa chỉ hợp đồng
Trước hết, lấy địa chỉ contract từ kênh chính thức của dự án và xác nhận đúng blockchain, chẳng hạn Ethereum hoặc BNB Chain. Cùng một giao thức có thể có nhiều địa chỉ trên mainnet, mạng lớp hai hoặc testnet.
Sau đó, kiểm tra địa chỉ trên trình khám phá khối phù hợp. Mã nguồn được xác minh giúp việc đối chiếu dễ hơn, nhưng trạng thái “verified” chỉ cho biết mã công bố có thể tái tạo bytecode theo cấu hình liên quan; nó không tự chứng minh mã đã được audit.
Nếu dự án tuyên bố đã hoạt động, quy trình kiểm tra mainnet của dự án crypto giúp phân biệt giữa thông báo ra mắt và hợp đồng thực sự có giao dịch on-chain.
So sánh mã triển khai với commit đã audit
Cần đối chiếu mã nguồn đã xác minh của contract với commit cuối được kiểm toán viên chấp nhận. Một số khác biệt nhỏ có thể đến từ metadata, phiên bản compiler, thư viện liên kết, constructor arguments hoặc cấu hình tối ưu hóa. Vì vậy, chỉ so sánh bằng mắt không phải lúc nào cũng đủ.
Tối thiểu, hãy kiểm tra:
- Tên và nội dung contract có nằm trong scope không.
- Phiên bản compiler và cấu hình biên dịch có phù hợp không.
- Các thư viện phụ thuộc có đúng phiên bản không.
- Có thay đổi logic sau commit audit không.
- Địa chỉ triển khai có được tài liệu dự án công bố nhất quán không.
Nếu không thể tái tạo hoặc đối chiếu mã triển khai, nên ghi nhận đây là giới hạn xác minh thay vì mặc định hai phiên bản giống nhau.
Kiểm tra proxy và implementation
Nhiều giao thức dùng proxy để cho phép nâng cấp logic. Trong trường hợp đó, địa chỉ người dùng tương tác có thể chỉ giữ trạng thái và chuyển lời gọi đến implementation.
Cần xác định:
- Địa chỉ proxy.
- Địa chỉ implementation hiện tại.
- Loại proxy và cơ chế nâng cấp.
- Tài khoản hoặc hợp đồng có quyền nâng cấp.
- Timelock, multisig hoặc quy trình quản trị liên quan.
- Implementation hiện tại có đúng phiên bản đã audit không.
Một implementation từng được audit vẫn có thể bị thay thế sau đó. Hướng dẫn kiểm tra hợp đồng proxy và quyền nâng cấp giúp nhận diện rủi ro này trước khi tương tác.
Những giới hạn cần đọc kỹ trong báo cáo kiểm toán
Phần disclaimer, limitations hoặc out of scope không phải nội dung thủ tục. Đây là nơi cho biết những gì kết luận audit không bao phủ.
Các giới hạn thường gặp gồm:
- Chỉ kiểm tra phiên bản mã tại commit được nêu.
- Không đánh giá website, giao diện, API hoặc hạ tầng ngoài chuỗi.
- Không bảo đảm phát hiện mọi lỗ hổng.
- Không đánh giá rủi ro kinh tế trong mọi điều kiện thị trường.
- Không kiểm tra đầy đủ dependency hoặc giao thức bên thứ ba.
- Giả định khóa quản trị, multisig hoặc oracle hoạt động đúng.
- Không chịu trách nhiệm cho thay đổi sau thời điểm kiểm toán.
Một giao thức còn có thể gặp rủi ro từ tích hợp composability. Contract riêng lẻ có thể hoạt động theo thiết kế nhưng phát sinh vấn đề khi kết nối với oracle, cầu nối, AMM, lending protocol hoặc token có hành vi đặc biệt.
Audit cũng không loại bỏ các rủi ro phía người dùng như website giả mạo, chữ ký độc hại hoặc cấp quyền chi tiêu quá rộng. Trước khi tương tác, người dùng nên hiểu rủi ro token approval vô hạn và kiểm tra địa chỉ spender thực tế.
Dấu hiệu cảnh báo khi đánh giá audit dự án crypto
Nên thận trọng nếu gặp một hoặc nhiều dấu hiệu sau:
- Dự án chỉ đăng logo đơn vị audit nhưng không công bố báo cáo đầy đủ.
- Báo cáo không ghi rõ repository, commit hoặc danh sách contract trong phạm vi.
- Địa chỉ hợp đồng đang vận hành không xuất hiện trong tài liệu chính thức.
- Mã nguồn trên trình khám phá khối chưa được xác minh.
- Báo cáo đã cũ nhưng repository có nhiều thay đổi logic sau đó.
- Phát hiện nghiêm trọng vẫn ở trạng thái Open, Acknowledged hoặc Partially resolved.
- Dự án tuyên bố “đã audit nên an toàn tuyệt đối”.
- Contract dùng proxy nhưng không công bố implementation hoặc quyền nâng cấp.
- Bản sửa do dự án tự xác nhận, không có dấu hiệu được kiểm toán viên xem xét lại.
- Phạm vi audit chỉ bao phủ một phần nhỏ nhưng nội dung quảng bá áp dụng kết luận cho toàn hệ thống.
Không có dấu hiệu nào tự nó chứng minh dự án là lừa đảo. Chúng cho thấy người đọc cần thu thập thêm bằng chứng trước khi gửi tài sản hoặc cấp quyền cho hợp đồng.
Checklist đọc báo cáo kiểm toán smart contract
Có thể dùng danh sách sau để rà soát nhanh:
- ☐ Đúng tên dự án và đúng sản phẩm cần đánh giá.
- ☐ Có ngày kiểm toán và phiên bản báo cáo.
- ☐ Có repository cùng Git commit cụ thể.
- ☐ Scope liệt kê rõ contract, tệp và phần bị loại trừ.
- ☐ Phương pháp, giả định và giới hạn được công bố.
- ☐ Đã đọc nội dung từng phát hiện, không chỉ xem bảng tổng hợp.
- ☐ Hiểu định nghĩa Critical, High, Medium, Low của chính đơn vị audit.
- ☐ Phân biệt Fixed, Mitigated, Acknowledged và Unresolved.
- ☐ Có commit sửa lỗi và xác nhận tái kiểm tra nếu báo cáo đề cập.
- ☐ Đúng địa chỉ contract và đúng mạng blockchain.
- ☐ Mã triển khai có thể đối chiếu với phiên bản đã audit.
- ☐ Nếu dùng proxy, implementation hiện tại đã được xác định.
- ☐ Quyền admin, nâng cấp, tạm dừng và rút tài sản đã được xem xét.
- ☐ Các dependency, oracle và tích hợp ngoài scope đã được đánh giá riêng.
- ☐ Không dùng audit làm căn cứ duy nhất cho quyết định tài chính.
Câu hỏi thường gặp
Dự án có audit nghĩa là an toàn không?
Không. Audit làm tăng khả năng phát hiện một số lỗi trong phạm vi và phiên bản được kiểm tra, nhưng không bảo đảm an toàn tuyệt đối. Mã có thể được thay đổi sau audit, lỗ hổng có thể bị bỏ sót hoặc rủi ro có thể đến từ quản trị, oracle, giao diện và hệ thống bên thứ ba.
Báo cáo không có lỗi Critical có phải là tín hiệu tốt?
Đây có thể là một thông tin tích cực trong phạm vi báo cáo, nhưng chưa đủ để kết luận. Cần xem độ rộng của scope, commit, phương pháp kiểm tra, các lỗi High hoặc Medium, giới hạn và sự tương đồng giữa mã audit với hợp đồng đang chạy.
“Acknowledged” có nghĩa là lỗ hổng đã khắc phục không?
Thông thường là không. Trạng thái này thường cho biết đội ngũ đã biết và chấp nhận rủi ro, hoặc quyết định chưa sửa. Cần đọc giải thích cụ thể của cả dự án và kiểm toán viên.
Một dự án cần bao nhiêu báo cáo audit?
Không có số lượng cố định bảo đảm an toàn. Nhiều báo cáo có thể cung cấp thêm góc nhìn, nhưng chất lượng, phạm vi, phiên bản mã và trạng thái khắc phục quan trọng hơn số logo kiểm toán được công bố.
Làm sao biết hợp đồng đang chạy đúng phiên bản đã audit?
Cần xác định địa chỉ trên đúng mạng, kiểm tra mã nguồn đã xác minh, đối chiếu với commit cuối được audit và xem cấu hình biên dịch. Nếu contract dùng proxy, phải kiểm tra cả implementation hiện tại và lịch sử nâng cấp. Khi không đủ dữ liệu để đối chiếu, nên coi đây là một rủi ro chưa được xác minh.
