Buổi tối tháng Tư năm ngoái, tôi ngồi ở một quán cà phê nhỏ gần nhà thờ Grossmünster, trước mặt là laptop mở trang web của một giao thức DeFi mới. Một cô bạn — vừa chuyển từ ngân hàng truyền thống sang crypto — chỉ vào logo “Audited by OpenZeppelin” và hỏi tôi bằng giọng đầy kỳ vọng:
“Vậy là an toàn đúng không?”
Tôi im lặng hai giây. Đủ lâu để cô ấy nhận ra câu trả lời không đơn giản như cái huy hiệu kia gợi ý. Tôi nhớ lại năm 2017, khi tôi đầu tư 8 ETH vào Aragon vì một whitepaper đẹp, và sau đó nhìn hàng loạt dự án “audited” sụp đổ chỉ sau một đêm. Tôi nhớ lại năm 2022, khi Terra — một dự án được quảng bá rầm rộ — bốc hơi 40 tỷ USD trong khi bao nhiêu bản audit nằm im trên website. Và tôi nhớ lại tháng 2 năm 2025, khi Bybit mất 1,4 tỷ USD dù sàn này từng tự hào về hệ thống bảo mật lạnh.
Tôi không trả lời cô bạn ngay. Tôi mở trình duyệt, tải báo cáo audit của một dự án bất kỳ, và trỏ vào phần “Scope” — phần mà hầu như không ai đọc.
Đó là khoảnh khắc tôi nhận ra: Thứ khiến nhà đầu tư an tâm nhất trên thị trường crypto hiện tại không phải là code an toàn. Mà là một tấm huy hiệu được thiết kế đẹp, đặt ở góc phải website, với dòng chữ nhỏ xíu “Audited by...” mà không ai bấm vào để đọc giới hạn của nó.
Câu chuyện Bybit: Khi màn hình nói dối
Ngày 21 tháng 2 năm 2025, sàn giao dịch Bybit bị tấn công. Kẻ tấn công chiếm được quyền kiểm soát một trong những ví đa chữ ký lạnh của sàn — ví được bảo vệ bởi công nghệ Safe (trước đây là Gnosis Safe), một trong những tiêu chuẩn ví đa chữ ký đáng tin cậy nhất trong ngành. Thiệt hại: khoảng 1,4 tỷ USD theo giá trị thời điểm đó.
Điều khiến vụ việc này trở thành cú sốc đặc biệt không chỉ là con số khổng lồ, mà là cách tấn công. Các nhà ký (signer) của Bybit — những người được uỷ quyền phê duyệt giao dịch — nhìn thấy trên màn hình một giao dịch hợp lệ: gửi tiền đến một địa chỉ quen thuộc, đúng định dạng. Họ ký. Nhưng giao dịch thực tế được đóng gói bên dưới là một payload độc hại — chuyển quyền sở hữu ví cho kẻ tấn công. Màn hình nói một điều, blockchain ghi một điều khác. Và vì các signer tin vào màn hình — tin vào công cụ họ đang dùng — họ không bao giờ nghi ngờ.
Safe sau đó giải thích rằng sự cố không đến từ lỗ hổng trong smart contract của Safe, mà từ một “máy tính của nhà phát triển bị xâm nhập”. Nói cách khác, kẻ tấn công không phá được code — chúng phá được con người và hệ thống vận hành xung quanh code.
Hãy dừng lại ở đây một chút, vì đây chính là điểm mù mà cả ngành đang cố tình lờ đi.
Audit là gì — và quan trọng hơn, audit không phải là gì
Tôi đã tham gia vào quá trình audit nhiều giao thức trong vai trò cố vấn về quản trị — đủ để biết một sự thật phũ phàng: Một bản audit smart contract, dù được thực hiện bởi công ty uy tín nhất, chỉ bao phủ một ảnh chụp (snapshot) của mã nguồn tại một thời điểm cụ thể, trong một phạm vi được liệt kê rõ ràng trong báo cáo.
Cụ thể hơn, khi OpenZeppelin audit một dự án, họ xác định rõ PR được review bằng commit hash, danh sách hợp đồng nằm trong phạm vi, và khoảng thời gian — thường là ba ngày — dành cho việc xem xét. Báo cáo kết luận: “Chúng tôi không tìm thấy lỗ hổng nào trong phạm vi này tại commit này.” Không hơn, không kém.
Nhưng khi báo cáo đó được dự án đăng tải lên website, kèm theo logo công ty audit to đùng, với dòng chữ “Audited by OpenZeppelin” — câu chuyện bị bóp méo. Nó trở thành: “Dự án này an toàn.” Người đọc không biết rằng báo cáo đó có thể đã lỗi thời từ lâu, vì dự án đã thêm tính năng mới, thay đổi quyền admin, hay nâng cấp hợp đồng sau khi audit hoàn tất. Họ không biết rằng báo cáo đó không hề đả động đến frontend — giao diện web mà họ đang tương tác — cũng như không kiểm tra được máy tính cá nhân của các signer, tài khoản cloud, hay thiết bị ký.
Audit không bao phủ hệ thống đang chạy. Nó bao phủ một bức ảnh của hệ thống tại một thời điểm. Hệ thống thì sống tiếp, và mỗi ngày trôi qua, bức ảnh đó lại càng cũ đi.
— Root: Một audit là một bức ảnh chụp lúc bình minh; hệ thống sống tiếp sau đó, dưới ánh nắng khác, với những cái bóng khác.
Những con số đáng sợ từ Oak Security
Nếu bạn vẫn nghĩ vấn đề chỉ là “audit cũ”, hãy nghe những con số thống kê từ Oak Security — được trích dẫn trong bài viết trên CryptoSlate (lưu ý: nguồn là bản in trước — preprint, chưa qua bình duyệt đầy đủ, nhưng dữ liệu vẫn đủ sức khiến ta giật mình).
Theo phân tích của Oak Security trên nhiều hợp đồng thông minh đã được audit, khoảng 1/6 các phát hiện (findings) được xếp loại ở mức nghiêm trọng (critical) hoặc mức độ cao (high). Nghĩa là, cứ sáu lỗi mà công cụ và con người phát hiện ra trong quá trình audit, thì có một lỗi đủ nghiêm trọng để gây thiệt hại đáng kể nếu bị khai thác.
Nhưng khoan — con số này không nói rằng 1/6 dự án được audit sẽ bị hack. Nó nói rằng trong số các lỗi được tìm thấy, tỷ lệ nghiêm trọng là đáng kể. Và điều đó dẫn đến một câu hỏi khó chịu: Nếu audit bỏ sót — ví dụ — 10% lỗi nghiêm trọng, thì tổn thất sẽ như thế nào? Chúng ta không có câu trả lời, vì hệ thống chỉ báo cáo những gì nó tìm thấy, không phải những gì nó không tìm thấy.
Dữ liệu từ Oak Security còn chỉ ra: Các lỗi liên quan đến lộ private key và lừa đảo (phishing) chiếm tới 43,9% tổng giá trị bị đánh cắp trong các sự kiện được phân tích. Không phải lỗi smart contract. Không phải flash loan attack. Không phải reentrancy. Mà là key bị lộ và con người bị lừa.
Điều này phù hợp với một thực tế mà những người làm bảo mật lâu năm trong ngành đều biết: Kẻ tấn công có hai lựa chọn — hoặc tìm lỗ hổng trong mã nguồn (tốn thời gian, khó khăn, dễ bị phát hiện), hoặc tấn công con người và hệ thống vận hành (rẻ hơn, nhanh hơn, và thường hiệu quả hơn nhiều). Khi bạn đặt một khoá riêng tư vào tay một người — hoặc nhiều người — bạn không còn ở trong lĩnh vực của smart contract nữa. Bạn đang ở trong lĩnh vực của quản lý rủi ro con người.
Cáo phó cho các lập trình viên smart contract: Các bạn làm rất tốt công việc của mình. Nhưng kẻ tấn công đã chuyển hướng sang tầng khác.
Ba loại lỗi chiếm 37,6% — và bài học về sự tập trung thái quá
Oak Security cũng chỉ ra rằng ba loại lỗi phổ biến nhất trong các phát hiện audit chiếm khoảng 37,6% tổng số. Các lỗi này thường liên quan đến vấn đề kiểm soát truy cập (access control), xác thực (authentication), và xử lý dữ liệu đầu vào. Điều này không có gì mới mẻ với những ai đã đọc nhiều báo cáo audit — nhưng nó làm nổi bật một điểm: Các lỗi xảy ra thường xuyên nhất không phải là những lỗi đòi hỏi thiên tài toán học để khai thác. Chúng là những lỗi đến từ sự phức tạp trong phân quyền và các giả định sai lầm về cách dữ liệu được truyền vào.
Nghe quen không? Năm 2017, tôi đã viết trên Medium về sự khác biệt giữa “cộng đồng” và “bầy đàn” — rằng một dự án có hàng nghìn thành viên Telegram vẫn có thể là một mớ hỗn độn về quản trị. Bài học tương tự áp dụng cho smart contract: Một hợp đồng có thể chạy hoàn hảo trong môi trường test, nhưng khi đưa vào sản xuất với hàng chục vai trò khác nhau — admin, pause role, proxy admin, owner — thì sự phức tạp trong tương tác giữa các vai trò đó tạo ra lỗ hổng không nằm trong bất kỳ dòng code đơn lẻ nào.
Đó là lý do tại sao tôi tin rằng các audit tốt nhất không chỉ review code — họ review mô hình quản trị của dự án. Ai có quyền làm gì? Làm thế nào để sửa một lỗi khẩn cấp? Sau khi upgrade, mức độ phân quyền còn nguyên không? Nếu câu trả lời cho những câu hỏi này không rõ ràng, thì mọi dòng code “sạch” đều vô nghĩa.
— Root: An toàn không nằm ở chữ ký của một công ty audit, mà nằm ở sự phân tán quyền lực trong hệ thống; một code sạch trong tay một kẻ độc tài vẫn là một tòa nhà bằng kính.
Vậy Bybit đã sai ở đâu?
Hãy quay lại vụ Bybit. Nếu bạn đọc kỹ cách Safe mô tả sự kiện — nguyên nhân là một máy tính nhà phát triển bị xâm nhập — bạn sẽ thấy một cấu trúc lỗ hổng rõ ràng, không khác gì một chuỗi domino:
- Máy tính của nhà phát triển bị cài phần mềm độc hại.
- Kẻ tấn công dùng quyền truy cập này để chuẩn bị một giao dịch độc hại trên giao diện Byzantine hoặc một công cụ tương tự.
- Giao dịch được thiết kế tinh vi: Với các signer, nó hiển thị đúng địa chỉ người nhận mà họ mong đợi. Nhưng nếu nhấp vào “chi tiết” — hoặc nếu kiểm tra dữ liệu thô trên block explorer — họ sẽ thấy một payload khác biệt.
- Signer ký dựa trên thứ họ thấy trên màn hình. Một cuộc tấn công blind signing kinh điển.
Từ góc độ kỹ thuật, không có smart contract nào của Safe bị khai thác trực tiếp. Nhưng từ góc độ bảo mật, toàn bộ hệ thống đã thất bại trong khâu mà không một bản audit nào có thể bảo vệ: khâu con người tương tác với giao diện số.
Trong các buổi đào tạo DAO ở Zurich, tôi thường cảnh báo các founder về điều này: Khi bạn xây dựng một tổ chức phi tập trung, bạn phải đối xử với giao diện ký (signing interface) như một ranh giới quyền lực — bởi vì trên thực tế, bất kỳ ai kiểm soát được giao diện đó đều có khả năng kiểm soát toàn bộ dòng tiền của tổ chức. Điều này nằm ngoài phạm vi smart contract audit.
Tấm huy hiệu “Audited” — con dao hai lưỡi
Bây giờ, hãy nói về tấm huy hiệu. Trong thị trường đi ngang hiện tại — khi BTC và ETH giằng co quanh một vùng giá, và nhà đầu tư không có nhiều tín hiệu rõ ràng — nhu cầu tìm kiếm một “căn cứ an toàn” trở nên mạnh mẽ hơn bao giờ hết. Trong bối cảnh đó, tấm huy hiệu “Audited by X” trở thành một tín hiệu tin cậy được ưa chuộng, vì nó giúp rút ngắn quá trình due diligence. Bạn không cần đọc hiểu code, không cần phân tích kiến trúc, không cần hiểu mô hình quản trị. Chỉ cần nhìn badge, rồi next.
Điều này giống hệt như việc tổ chức một bộ sưu tập NFT có 100 tác phẩm pixel về lịch sử blockchain — và nghĩ rằng chỉ cần gắn tên “NFT art” thì nó đã là nghệ thuật. Không. Giá trị của một bộ sưu tập không nằm ở nhãn mác, mà nằm ở câu chuyện bạn kể và cộng đồng bạn xây dựng. Tương tự, giá trị của một bản audit không nằm ở tấm huy hiệu, mà nằm ở phạm vi và giới hạn của nó.
Tấm huy hiệu “Audited” không chỉ vô dụng — nó còn nguy hiểm, bởi những lý do sau:
Thứ nhất, nó tạo ra cảm giác an toàn sai lệch (false sense of security). Khi người dùng tin rằng một giao thức “đã được audit”, họ thường chấp nhận rủi ro mà lẽ ra họ sẽ tránh nếu họ biết sự thật. Họ bỏ tiền vào các pool thanh khoản có APY hấp dẫn mà không kiểm tra xem báo cáo audit có bao phủ module mà họ đang tương tác hay không. Họ nháy “Approve” trên các trang web lạ vì yên tâm rằng hợp đồng đã được kiểm tra — trong khi chính hành động approve đó là thứ bị khai thác.
Thứ hai, nó tạo ra khoảng trống trách nhiệm. Khi một dự án sụp đổ, ai chịu trách nhiệm? Công ty audit chỉ chịu trách nhiệm trong phạm vi hợp đồng đã ký. Nhà đầu tư không thể kiện ai vì họ đã không đọc báo cáo audit cẩn thận. Founder có thể chỉ tay vào badge. Và cộng đồng tự trách mình vì đã quá ngây thơ. Hệ quả là chẳng ai học được gì, và vòng lặp tiếp tục.
Thứ ba, nó tạo ra một thị trường “audit laundering”. Dự án được audit vì mục đích marketing, không phải vì mục đích an toàn. Công ty audit bị đặt vào thế xung đột lợi ích: họ trả tiền để tìm lỗi — và nếu họ tìm ra quá nhiều lỗi, dự án có thể khó gọi vốn. Kết quả là một số bản audit có xu hướng nhẹ tay, tránh đối đầu với khách hàng. Tôi không thể đưa ra bằng chứng cụ thể, nhưng kinh nghiệm audit của tôi cho tôi biết: áp lực thương mại luôn tồn tại, ở mọi công ty, dù họ có phủ nhận thế nào đi nữa.
Lúc này, ai đó sẽ nói: “Vậy ý anh là audit vô dụng? Chúng ta nên bỏ audit đi?” Không. Đó là một phản ứng cực đoan, và tôi không hề đề xuất điều đó. Audit là một ngành công nghiệp cần thiết — giống như kiểm toán tài chính truyền thống. Vấn đề là cách chúng ta tiêu thụ nó — với tư cách là nhà đầu tư, founder, và người tham gia hệ sinh thái.
— Root: Vấn đề không nằm ở chất lượng của bản audit, mà nằm ở câu chuyện chúng ta tự kể về nó khi nhìn vào tấm huy hiệu — và chúng ta giao quá nhiều quyền phán quyết cho một logo ở góc màn hình.
Đọc audit report như một nhà đầu tư có kỷ luật
Trong thị trường đi ngang, khi mọi tín hiệu giá đều mù mờ, kỷ luật đọc hiểu chính là lợi thế cạnh tranh của bạn. Một báo cáo audit không phải là tài liệu dành riêng cho kỹ sư. Bất kỳ ai cũng có thể đọc được vài trang đầu tiên một cách có ý nghĩa, chỉ cần biết tìm ở đâu.
Khi tôi xem xét một dự án mới, tôi làm theo một quy trình đơn giản — tôi gọi vui là “nghi thức ba trang”:
Trang 1: Phạm vi (Scope). Tôi đọc danh sách hợp đồng được audit. Sau đó tôi mở trang chủ của dự án và kiểm tra: Có hợp đồng nào được triển khai trên mainnet mà không nằm trong danh sách này không? Nếu dự án đã nâng cấp — ví dụ, thêm module staking mới — thì bản audit đó đã lỗi thời. Tôi nhìn vào commit hash trong báo cáo và so sánh với commit hiện tại trên GitHub. Khoảng cách giữa hai thời điểm đó là vùng rủi ro.
Trang 2: Kết luận của auditor. Không phải phần tóm tắt marketing ở đầu trang, mà là phần kết luận cuối báo cáo. Auditor thường nói rõ: “Chúng tôi không tìm thấy lỗ hổng nào có thể dẫn đến mất mát tài sản trong phạm vi được review.” Đọc kỹ từng từ: “trong phạm vi được review”. Nếu kết luận có các cụm từ như “ngoài phạm vi”, “không được xem xét”, “giả định rằng” — hãy ghi chú lại.
Trang 3: Phần “Known Issues” hoặc “Findings”. Các báo cáo trung thực thường tiết lộ các vấn đề còn tồn đọng — những lỗi không nghiêm trọng đến mức cần sửa ngay nhưng vẫn tồn tại. Nếu dự án không có phần này, khả năng cao họ đã chọn một công ty audit không trung thực hoặc họ tự biên tập lại báo cáo.
Nghi thức ba trang này không mất quá mười lăm phút. Nhưng mười lăm phút đó có thể cứu bạn khỏi — không phải là một vụ rug pull của một dự án scam, mà khỏi một dự án có ý định tốt nhưng vận hành kém — điều phổ biến hơn nhiều.
Mở rộng phạm vi: Từ smart contract audit sang hệ thống audit
Vụ Bybit dạy cho chúng ta một bài học sâu sắc hơn: Chúng ta đang sai lầm khi tập trung quá nhiều vào smart contract audit mà bỏ quên các tầng rủi ro khác. Hãy nhìn vào các thành phần cấu thành một giao thức phi tập trung:
- Smart contract — lớp được audit kỹ nhất, nhưng chỉ chiếm một phần nhỏ của hệ thống.
- Frontend — nơi người dùng tương tác. Không được audit bởi các công ty smart contract audit chuẩn. Có thể bị tấn công qua CDN, qua DNS, qua extension của trình duyệt.
- Infrastructure — máy chủ, nhà cung cấp cloud, service provider nội bộ. Một nhân viên bất mãn có quyền admin có thể phá sản cả hệ thống.
- Con người — những người nắm key, những người có quyền quản trị, những người ký giao dịch. Đây là điểm yếu lớn nhất, chiếm 43,9% giá trị tổn thất theo Oak Security.
- Quy trình quản trị — cách các quyết định được thực hiện và cập nhật. Một DAO có cơ chế quản trị tệ có thể bị tấn công qua governance attack — không cần khai thác code, chỉ cần tận dụng sự thờ ơ của cử tri.
Vì vậy, điều tôi muốn thấy trong tương lai không phải chỉ là “smart contract audit”, mà là hệ thống audit toàn diện (system-level audit): bao gồm đánh giá bảo mật quy trình vận hành, kiểm tra mô hình quản trị, đánh giá các giả định niềm tin, và test thử các tình huống xã hội — ai có thể làm gì, trong hoàn cảnh nào, với hậu quả gì. Một số tổ chức tiên phong đã bắt đầu làm điều này, nhưng nó vẫn chưa trở thành tiêu chuẩn ngành. Và trong thị trường đi ngang, chính những dự án chấp nhận tiêu chuẩn cao hơn này mới là những dự án đáng giá.
Không phải là vứt bỏ audit, mà là hạ cấp huy hiệu
Tôi không phải là người bài audit. Tôi là người bài sự lười biếng nhận thức. Và tấm huy hiệu “Audited” chính là hiện thân của sự lười biếng đó — một công cụ để chúng ta không phải suy nghĩ, không phải đặt câu hỏi, không phải tự chịu trách nhiệm.
Nhưng có một điều thú vị: Trong một thế giới mà ai cũng có thể đặt một tấm huy hiệu “Audited” lên website, thì chính việc không đặt huy hiệu — hoặc đặt huy hiệu nhưng kèm theo một đường dẫn đến báo cáo audit đầy đủ — trở thành một tín hiệu xa xỉ. Nó nói lên rằng dự án đó tôn trọng sự thông minh của người dùng, thay vì cố gắng cám dỗ họ bằng một logo đẹp.
Tôi bắt đầu thấy xu hướng này trong những dự án trẻ mà tôi gặp ở châu Âu: Họ đăng tải toàn bộ báo cáo audit, kèm theo phần mô tả “điều gì không nằm trong phạm vi audit này”. Họ dùng những cụm từ như: “Bản audit này không đảm bảo tính bảo mật của frontend”, “Chúng tôi chưa được audit về mô hình quản trị”, “Hợp đồng này đã thay đổi sau audit vào ngày X”. Cách làm này không khiến nhà đầu tư hoảng sợ — ngược lại, nó xây dựng lòng tin dài hạn.
Đó là một sự thật trớ trêu: Trong một thị trường đầy rẫy những tấm huy hiệu rỗng tuếch, sự trung thực về giới hạn chính là thứ marketing mạnh mẽ nhất.
Bài học cho mùa đi ngang này
Thị trường đang đi ngang. Khối lượng giao dịch giảm, sự phấn khích giảm, và những nhà đầu tư mới rời bỏ dần. Đây là thời điểm hoàn hảo để học cách đọc hiểu — thay vì chạy theo cảm xúc. Nếu bạn bỏ ra mười lăm phút để đọc một báo cáo audit, bạn sẽ không bao giờ nhìn nhận các dự án crypto theo cách cũ nữa. Bạn sẽ bắt đầu nhận ra rằng hầu hết các “lỗ hổng bảo mật” không nằm trong code, mà nằm trong cách chúng ta sắp xếp niềm tin của mình.
Trong tất cả các cuộc trò chuyện tôi có với các founder ở châu Âu — từ Lisbon đến Berlin, từ Paris đến Zurich — tôi nhận ra một điều: Những người thực sự xây dựng tốt đều có chung một thái độ khiêm tốn về bảo mật. Họ không nói “Chúng tôi đã được audit nên chúng tôi an toàn”. Họ nói “Chúng tôi đã được audit một phần, và chúng tôi còn những rủi ro này ngoài phạm vi — hãy cùng nhau tìm hiểu”. Họ coi bảo mật là một quá trình liên tục, không phải một chiếc huy hiệu treo tường.
Điều đó gợi cho tôi nhớ lại một câu tôi thường nói với cộng đồng DAO của mình khi họ hỏi về rủi ro — một câu đã trở thành châm ngôn trong các buổi meetup của tôi: “Một DAO không an toàn vì nó có nhiều audit, nó an toàn vì nó kiểm tra lại mọi thứ mỗi ngày.”
Huy hiệu “Audited” giống như một tấm bản đồ kho báu được vẽ từ rất lâu trước. Nó không nói dối — nhưng nó cũng không còn đúng với địa hình hiện tại. Người dùng khôn ngoan sẽ không nhìn vào bản đồ cũ để tìm kho báu. Họ sẽ cầm la bàn, tự đọc các vì sao, và tự vẽ đường đi của mình.
Câu hỏi còn lại — dành cho bạn — là: Bạn có đang nhìn vào tấm bản đồ cũ, hay bạn đã sẵn sàng cầm lấy chiếc la bàn?
Trần Sơn — DAO Governance Architect, Zurich. Bài viết được lấy cảm hứng từ cuộc phân tích CryptoSlate về giới hạn của audit và vụ Bybit, với góc nhìn từ các buổi đào tạo DAO và kinh nghiệm thực tế trong mùa hè ICO 2017 đến thị trường đi ngang hiện tại.
Tags: audit, Bybit, smart-contract-security, DAO-governance, crypto-risk-management, Safe-wallet, false-sense-of-security, DeFi-safety, due-diligence, blockchain-news-vietnam
Prompt cho hình minh họa: Phong cách tranh pixel art theo trường phái Cyberpunk, cận cảnh một màn hình giao diện ví blockchain đang phát sáng, trên màn hình có biểu tượng dấu tích "Audited" to đùng được phủ lớp vàng óng, nhưng bên dưới lớp phủ đó là vô số những dòng code màu đỏ cảnh báo và một con dao móc câu đang luồn lách qua các kẽ hở. Nền tối với tông màu xanh neon và cam cháy, thể hiện sự tương phản giữa vẻ ngoài an toàn hào nhoáng và sự nguy hiểm tiềm ẩn bên trong. Phong cách retro-futuristic, chi tiết pixel sắc nét, tạo cảm giác vừa quen thuộc vừa kỳ dị.
