Hook
Bạn đã xác thực nguồn này chưa? Trong thị trường tăng, không gì dễ bán hơn một huy hiệu Audited đặt ngay trên trang chủ. Nó khiến nhà đầu tư quên rằng huy hiệu đó chỉ là một tấm ảnh chụp mã nguồn tại một thời điểm, không phải bảo hiểm toàn diện. Tôi đã thấy nhiều quỹ nhỏ bước vào pool thanh khoản chỉ vì một dòng chữ audited, rồi mất tiền vì một lỗ hổng nằm ngoài phạm vi kiểm toán. Nếu không thể kiểm tra, đừng đầu tư.
Bối cảnh
Ngày 21 tháng 2 năm 2025, Bybit mất khoảng 1,46 tỷ USD. Safe, nền tảng ví đa chữ ký, xác nhận nguyên nhân ban đầu: một máy tính của nhà phát triển bị nhiễm độc. Kẻ tấn công thao túng giao diện ký. Người ký nhìn thấy địa chỉ ví đúng, tin rằng mình đang phê duyệt giao dịch bình thường, nhưng giao dịch cơ bản bên dưới đã trao quyền kiểm soát ví cho kẻ tấn công. Đây không phải lỗi của hợp đồng thông minh. Đây là lỗi của lớp vận hành, thiết bị, giao diện con người - những lớp mà một bản smart contract audit thông thường không chạm tới.
Phân tích trên CryptoSlate đã đặt đúng vấn đề: huy hiệu audited đang tạo ra cảm giác an toàn giả. Dữ liệu từ bản thảo nghiên cứu của Oak Security, dù chưa qua bình duyệt đầy đủ, cho thấy khoảng một phần sáu số phát hiện kiểm toán được xếp loại nghiêm trọng hoặc cao. Trong khi đó, rò rỉ private key và lừa đảo chiếm 43,9 phần trăm giá trị tài sản bị đánh cắp trong các sự kiện được thống kê. Những con số này không nằm trong cùng một phép quy đổi, nhưng chúng nói lên một điều: rủi ro lớn nhất thường không nằm trong mã nguồn.
Core: Ranh giới thật sự của smart contract audit
Smart contract audit là kiểm tra mã nguồn tại một commit cụ thể. Các công ty nghiêm túc như OpenZeppelin ghi rõ commit hash, danh sách hợp đồng được kiểm tra, thời gian rà soát, và mức độ nghiêm trọng của từng lỗ hổng. Họ không khẳng định toàn bộ hệ thống an toàn. Họ chỉ nói rằng tại commit X, các hợp đồng Y và Z không có lỗ hổng đã biết trong phạm vi phân tích. Nhưng khi báo cáo được đưa lên website dự án, phần giới hạn bị cắt bỏ. Huy hiệu audited được phóng to, đặt cạnh logo, và trở thành một tuyên bố tuyệt đối.
Dựa trên kinh nghiệm audit của tôi, năm 2017 tôi từng phát hiện một hàm transferFrom trong hợp đồng ICO cho phép double-spend vì không kiểm tra số dư. Lỗi đó có thể gây thiệt hại khoảng 1,2 triệu USD nếu không được sửa trước khi ra mắt. Đó là một lỗi nằm gọn trong mã nguồn, đúng thứ audit được thiết kế để tìm. Nhưng vụ Bybit lại khác. Kẻ tấn công không khai thác hợp đồng. Kẻ tấn công khai thác chiếc máy tính của nhà phát triển, quy trình ký, và một màn hình đang nói dối. Hợp đồng có thể sạch sẽ, nhưng người ký vẫn có thể bị qua mặt.
Một điểm quan trọng nữa: huy hiệu audit có hạn sử dụng. Mã nguồn có thể được nâng cấp, cấu hình proxy có thể thay đổi, front-end có thể được chỉnh sửa, và nhân sự vận hành có thể thay đổi. Báo cáo audit không tự động cập nhật. Nếu đội ngũ deploy một bản vá sau khi audit, kết luận cũ không còn giá trị. Nếu một admin thay đổi quyền kiểm soát, kết luận cũ không bao phủ. Nhà đầu tư không nhìn thấy điều này, bởi vì họ chỉ nhìn thấy logo trên website. Họ không biết rằng logo đó có thể đã lỗi thời từ nhiều tháng trước.
Để hiểu rõ hơn, cần tách hai khái niệm: phát hiện kiểm toán và sự kiện mất mát. Ba hạng mục phát hiện hàng đầu trong các báo cáo audit có thể chiếm tới 37,6 phần trăm tổng số phát hiện. Nhưng điều đó không có nghĩa là ba hạng mục đó gây ra 37,6 phần trăm tổn thất thực tế. Một phát hiện audit chỉ là một lỗ hổng tiềm năng trong mã, có thể không bao giờ bị khai thác. Một sự kiện mất mát là kết quả của toàn bộ chuỗi vận hành: con người, thiết bị, quyền truy cập, giao diện ký, và thời điểm kẻ tấn công chọn ra tay. Gộp hai nhóm dữ liệu này vào một phép tính là một sai lầm phương pháp luận.
Cũng cần nhắc đến khái niệm blind signing. Nhiều vụ tấn công ví đa chữ ký gần đây dựa trên việc người ký không thể đọc hết dữ liệu giao dịch phức tạp trên thiết bị nhỏ. Họ chỉ thấy một địa chỉ ngắn và một nút xác nhận. Kẻ tấn công lợi dụng khoảng trống giữa những gì người dùng nhìn thấy và những gì thực sự được ký. Một bản audit không thể giải quyết vấn đề này. Nó không nằm trong mã nguồn. Nó nằm trong thiết kế quy trình xác nhận, trong khả năng hiển thị của thiết bị, và trong nhận thức của người ký. Đó là lý do tại sao tôi nói rằng audit chỉ là một lớp, không phải toàn bộ bức tường.
Góc nhìn ngược: Tương quan không phải nhân quả
Có một lỗi logic phổ biến: rò rỉ private key và phishing chiếm 43,9 phần trăm tổn thất, ba loại lỗi audit phổ biến chiếm 37,6 phần trăm phát hiện, vậy nếu sửa hết các lỗi đó thì sẽ ngăn được phần lớn tổn thất. Sai. Hai con số này đến từ hai tập dữ liệu khác nhau. Một bên là các lỗi tìm thấy trong quá trình kiểm toán, một bên là các vụ mất tiền thực tế. Chúng không có mối quan hệ nhân quả trực tiếp. Để chứng minh điều đó, cần dữ liệu chồng lấn: trong các vụ mất mát, bao nhiêu vụ bắt nguồn từ một lỗi đã từng xuất hiện trong báo cáo audit? Bản thảo của Oak Security chưa cung cấp đủ điều đó.
Tương quan không phải nhân quả. Một phát hiện audit có thể là một lỗi nhỏ không khai thác được trong thực tế. Một vụ mất mát có thể bắt nguồn từ một lỗi chưa từng được kiểm toán. Khi ta gộp hai tập dữ liệu này lại, ta tạo ra một câu chuyện dễ hiểu nhưng thiếu chính xác. Câu chuyện đó nguy hiểm hơn cả việc không có dữ liệu, vì nó mang vẻ ngoài khoa học. Là một người phân tích on-chain, tôi luôn yêu cầu các quỹ kiểm tra nguồn gốc dữ liệu, kích thước mẫu, phương pháp thu thập và ngày công bố trước khi đưa vào mô hình rủi ro.
Nghịch lý lớn nhất nằm ở chỗ: các công ty audit thường thận trọng hơn dự án. Họ ghi rõ phạm vi, ghi rõ giới hạn, ghi rõ rằng audit không đảm bảo an toàn tuyệt đối. Nhưng khi báo cáo đến tay bộ phận marketing, sự thận trọng đó bị xóa. Huy hiệu audited được tách ra, đứng cô lập, không có chú thích. Nó trở thành một công cụ bán hàng. Và trong thị trường tăng, công cụ đó hoạt động cực kỳ hiệu quả, bởi vì ai cũng muốn tin rằng mình đang mua một tài sản an toàn.
Tôi không phản đối audit. Tôi phản đối việc biến audit thành bùa hộ mệnh. Khi bạn đặt một báo cáo kỹ thuật vào tay một bộ phận marketing, bạn đang tạo ra thứ nằm ngoài tầm kiểm soát của công ty audit. Họ không thể kiểm soát cách dự án trình bày kết quả. Họ không thể xóa huy hiệu cũ khi mã nguồn đã thay đổi. Họ không thể ngăn một website tiếp tục hiển thị logo cũ sau khi hợp đồng được nâng cấp. Vì vậy, trách nhiệm cuối cùng nằm ở người đọc báo cáo. Nếu bạn không thể tự mình kiểm tra phạm vi, ngày phát hành, commit hash và danh sách hợp đồng, thì huy hiệu kia chỉ là một tấm ảnh. Nếu không thể kiểm tra, đừng đầu tư.
Takeaway: Từ huy hiệu sang quy trình kiểm chứng
Tuần tới, khi ai đó nói với bạn rằng một dự án đã được audit, hãy đặt năm câu hỏi. Báo cáo audit nằm ở đâu và có đầy đủ không? Phạm vi kiểm tra gồm những hợp đồng nào? Mã nguồn đang được kiểm tra tại commit nào? Báo cáo hoàn thành ngày nào, và mã nguồn có thay đổi kể từ ngày đó không? Audit có đề cập đến quy trình vận hành, thiết bị ký, front-end và kiểm soát truy cập không? Nếu năm câu hỏi đó không thể trả lời, bạn không sở hữu một kết luận bảo mật. Bạn chỉ đang sở hữu một logo.
Thị trường tăng không dạy bạn những câu hỏi này. Thị trường tăng dạy bạn nhấn nút mua càng nhanh càng tốt. Nhưng kẻ tấn công không vội. Chúng chờ bạn tin vào câu chuyện tròn trịa. Chúng biết rằng huy hiệu audited có thể khiến bạn bỏ qua những dấu hiệu bất thường trên chuỗi: quyền admin thay đổi, proxy được nâng cấp, dòng tiền lớn rời khỏi ví chưa từng di chuyển. Những tín hiệu đó mới là nơi dữ liệu thực sự nói chuyện.
Vậy tín hiệu cho tuần tới là gì? Hãy theo dõi những dự án công bố audit nhưng không công bố phạm vi chi tiết. Đó là dấu hiệu đỏ. Hãy theo dõi những dự án nâng cấp hợp đồng hoặc thay đổi front-end nhưng không có vòng kiểm toán mới. Đó là dấu hiệu đỏ. Hãy theo dõi các cuộc tấn công nhắm vào ví đa chữ ký, vì chúng có xu hướng lặp lại sau khi một phương thức đã thành công. Bybit không phải là vụ cuối cùng. Nó chỉ là một hồi chuông cho thấy ranh giới mà audit không thể vượt qua.
Tôi không nói rằng hãy bỏ qua audit. Tôi nói rằng hãy đặt nó đúng vị trí. Audit là một lớp kiểm tra cần thiết, nhưng chỉ là một lớp. Sau audit, dự án cần kiểm tra thiết bị của nhà phát triển, bảo vệ quy trình ký, theo dõi các thay đổi front-end, và xây dựng hệ thống cảnh báo bất thường on-chain. Nhà đầu tư cũng nên làm như vậy. Trước khi vào lệnh, hãy mở trình thám hiểm khối, xem ai đang nắm quyền thay đổi cấu hình, xem những giao dịch lớn gần đây, xem hợp đồng có đang được nâng cấp liên tục không. Dữ liệu on-chain không nói dối. Nhưng nó chỉ hữu ích nếu bạn chịu đọc.
Huy hiệu audited có thể khiến bạn yên tâm, nhưng sự yên tâm không phải là bảo mật. Bảo mật đến từ việc liên tục đặt câu hỏi, kiểm tra chéo, và tôn trọng sự phức tạp. Trong một thị trường nơi mọi thứ đều tăng, người ta dễ quên rằng thị trường tăng cũng là nơi kẻ xấu có động lực lớn nhất. Họ không nhắm vào những dự án chết. Họ nhắm vào những dự án có nhiều người tin tưởng, có huy hiệu đẹp, có TVL lớn. Họ để mắt đến những tấm khiên màu mè, bởi vì họ biết rằng phía sau tấm khiên đó là một chuỗi vận hành yếu. Nếu không thể kiểm tra, đừng đầu tư.
Hãy coi bài viết này như một lời nhắc. Lần tới khi bạn nhìn thấy cụm từ audited, đừng nhìn logo. Hãy nhìn vào ngày tháng, phạm vi, và câu chữ giới hạn. Rồi tự hỏi: tôi có thể kiểm tra điều này trong năm phút không? Nếu không, có lẽ bạn đang mua một cảm giác an toàn, chứ không phải một tài sản an toàn. Và cảm giác đó, giống như mọi cảm giác khác, sẽ tan biến ngay khi dữ liệu bắt đầu nói sự thật.