samczsun: Bảo mật giao thức tiền mã hóa, chìa khóa là chủ động kiểm toán lại

Chương trình tiền thưởng phát hiện lỗ hổng là một biện pháp bị động, trong khi bảo vệ an ninh cần được chủ động thúc đẩy.

Tác giả: samczsun, Nhà sáng lập Security Alliance, cựu đối tác nghiên cứu tại Paradigm

Hiện nay, ngành công nghiệp đã đạt được sự đồng thuận rằng bảo vệ an ninh cho tiền mã hóa cần tuân theo ba bước then chốt: viết các trường hợp kiểm thử trong giai đoạn phát triển để phát hiện lỗi cơ bản; tiến hành kiểm toán và thi đấu kiểm tra toàn diện trước khi triển khai; thiết lập chương trình tiền thưởng phát hiện lỗ hổng để thưởng cho các nhà nghiên cứu tiết lộ lỗ hổng một cách có trách nhiệm nhằm ngăn chặn các cuộc tấn công. Việc phổ biến các thực tiễn tốt nhất này đã giảm đáng kể số lượng lỗ hổng trên chuỗi, buộc các kẻ tấn công chuyển mục tiêu sang các lỗ hổng ngoài chuỗi như đánh cắp khóa riêng, xâm nhập hạ tầng.

Tuy nhiên, ngay cả những giao thức đã được kiểm toán toàn diện và cung cấp tiền thưởng lỗ hổng hấp dẫn vẫn đôi khi bị tấn công bởi hacker. Những sự kiện như vậy không chỉ ảnh hưởng đến chính giao thức liên quan mà còn làm lung lay nền tảng niềm tin của toàn bộ hệ sinh thái. Các vụ tấn công gần đây vào Yearn, Balancer V2, cũng như các sự cố an ninh đầu năm của Abracadabra, 1inch đều cho thấy ngay cả những giao thức đã được thử thách qua thời gian cũng không hoàn toàn an toàn. Liệu ngành công nghiệp tiền mã hóa có thể tránh được những cuộc tấn công này không? Hay đây chỉ là cái giá tất yếu của tài chính phi tập trung?

Các nhà bình luận thường cho rằng, tăng tiền thưởng lỗ hổng có thể bảo vệ các giao thức này. Nhưng ngay cả khi bỏ qua thực tế kinh tế, tiền thưởng lỗ hổng về bản chất là một biện pháp an ninh bị động, giao phó số phận của giao thức cho các hacker mũ trắng, trong khi kiểm toán mới là hành động tự bảo vệ chủ động của giao thức. Việc tăng tiền thưởng lỗ hổng không thể ngăn chặn các cuộc tấn công của hacker, vì điều này chẳng khác nào đặt cược gấp đôi, dựa vào việc hacker mũ trắng phát hiện lỗ hổng trước hacker mũ đen. Nếu giao thức thực sự muốn tự bảo vệ mình, họ phải chủ động tiến hành kiểm toán lại.

Quỹ tài chính và giá trị khóa (TVL)

Đôi khi, hacker sẽ đồng ý trả lại phần lớn số tiền bị đánh cắp, chỉ giữ lại một phần nhỏ (thường là 10%) như phần thưởng. Đáng tiếc, ngành công nghiệp lại gọi phần thưởng này là "tiền thưởng mũ trắng", điều này khiến người ta tự hỏi: tại sao giao thức không trực tiếp cung cấp số tiền tương đương thông qua chương trình tiền thưởng lỗ hổng để tránh rắc rối đàm phán? Tuy nhiên, suy nghĩ này đã nhầm lẫn giữa số tiền mà kẻ tấn công có thể đánh cắp và số tiền mà giao thức có thể chi tiêu.

Mặc dù nhìn bề ngoài, giao thức dường như có thể sử dụng cả hai khoản tiền này cho bảo vệ an ninh, nhưng thực tế, giao thức chỉ có quyền hợp pháp đối với quỹ tài chính của chính mình, không có quyền sử dụng tiền do người dùng gửi vào. Người dùng cũng rất khó có thể trao quyền này cho giao thức từ trước, chỉ trong những thời điểm khủng hoảng (ví dụ, khi người gửi tiền phải chọn giữa mất 10% hoặc mất 100% số tiền gửi) họ mới cho phép giao thức sử dụng tiền gửi để đàm phán. Nói cách khác, rủi ro sẽ tăng theo giá trị khóa (TVL), nhưng ngân sách an ninh lại không thể tăng theo.

Hiệu quả sử dụng vốn

Ngay cả khi giao thức có đủ tiền (ví dụ có quỹ lớn, khả năng sinh lời mạnh hoặc đã áp dụng chính sách phí an ninh), việc phân bổ hợp lý các khoản tiền này cho bảo vệ an ninh vẫn là một bài toán khó. So với đầu tư vào kiểm toán lại, tăng tiền thưởng lỗ hổng trong trường hợp tốt là hiệu quả sử dụng vốn rất thấp, trong trường hợp xấu có thể dẫn đến xung đột động lực giữa giao thức và các nhà nghiên cứu.

Nếu tiền thưởng lỗ hổng gắn với TVL, thì khi các nhà nghiên cứu nghi ngờ TVL của giao thức sẽ tăng và xác suất xuất hiện lỗ hổng lặp lại là rất thấp, họ rõ ràng có động lực để che giấu lỗ hổng quan trọng. Điều này cuối cùng sẽ đặt các nhà nghiên cứu vào thế đối đầu trực tiếp với giao thức, gây tổn hại đến lợi ích của người dùng. Việc chỉ đơn thuần tăng tiền thưởng cho lỗ hổng quan trọng cũng khó đạt được hiệu quả mong muốn: nhóm các nhà nghiên cứu tự do rất lớn, nhưng số người dành phần lớn thời gian cho tiền thưởng lỗ hổng và đủ kỹ năng để phát hiện lỗ hổng trong các giao thức phức tạp lại rất ít. Những nhà nghiên cứu tinh hoa này sẽ tập trung thời gian vào các dự án tiền thưởng có khả năng mang lại lợi nhuận đầu tư cao nhất. Đối với các giao thức lớn, đã được kiểm chứng qua thời gian, do mặc định luôn được hacker và các nhà nghiên cứu khác chú ý sát sao, xác suất phát hiện lỗ hổng được cho là cực kỳ thấp, do đó dù có tăng tiền thưởng bao nhiêu cũng không đủ hấp dẫn để họ đầu tư công sức.

Trong khi đó, từ góc độ giao thức, tiền thưởng lỗ hổng là khoản dự phòng để trả cho một lỗ hổng quan trọng duy nhất. Trừ khi giao thức sẵn sàng đánh cược rằng sẽ không bao giờ xuất hiện lỗ hổng quan trọng, đồng thời che giấu tình trạng thanh khoản của mình với các nhà nghiên cứu, nếu không khoản tiền này không thể sử dụng cho mục đích khác. Thay vì bị động chờ đợi các nhà nghiên cứu phát hiện lỗ hổng quan trọng, tốt hơn nên sử dụng số tiền tương đương để tiến hành nhiều lần kiểm toán lại trong nhiều năm. Mỗi lần kiểm toán lại đều đảm bảo thu hút được sự chú ý của các nhà nghiên cứu hàng đầu, không bị giới hạn bởi việc chỉ phát hiện một lỗ hổng, đồng thời giúp lợi ích giữa nhà nghiên cứu và giao thức luôn đồng nhất: nếu giao thức bị khai thác, cả hai bên đều bị tổn hại danh tiếng.

Tiền lệ hiện có

Trong ngành phần mềm và tài chính, kiểm toán định kỳ hàng năm là một thực tiễn đã được kiểm chứng và trưởng thành, cũng là cách tốt nhất để đánh giá liệu doanh nghiệp có thể đối phó với môi trường đe dọa liên tục thay đổi hay không. Báo cáo SOC 2 Type II được khách hàng B2B sử dụng để đánh giá liệu nhà cung cấp có duy trì các biện pháp kiểm soát an ninh phù hợp hay không; chứng nhận PCI DSS cho thấy doanh nghiệp đã thực hiện các biện pháp bảo vệ thông tin thanh toán nhạy cảm; chính phủ Hoa Kỳ yêu cầu các bên tiếp cận thông tin chính phủ phải có chứng nhận FedRAMP để duy trì tiêu chuẩn bảo vệ an ninh cao.

Bản thân hợp đồng thông minh có tính bất biến, nhưng môi trường vận hành lại không bất biến. Cấu hình có thể thay đổi theo thời gian, các phụ thuộc có thể được nâng cấp, các mẫu mã được cho là an toàn thực tế có thể tiềm ẩn rủi ro. Kiểm toán giao thức là đánh giá tình trạng an ninh tại thời điểm kiểm toán, chứ không phải là đảm bảo an ninh cho tương lai của giao thức. Cách duy nhất để cập nhật kết quả đánh giá này là tiến hành kiểm toán mới.

Năm 2026, ngành công nghiệp tiền mã hóa nên coi kiểm toán định kỳ hàng năm là bước thứ tư trong bảo vệ an ninh cho giao thức. Các giao thức hiện có với TVL lớn nên tiến hành kiểm toán lại đối với các triển khai của mình; các công ty kiểm toán nên cung cấp dịch vụ kiểm toán lại chuyên nghiệp tập trung vào đánh giá tổng thể các triển khai; toàn bộ hệ sinh thái nên cùng nhau thay đổi nhận thức về báo cáo kiểm toán, chúng chỉ là đánh giá an ninh tại một thời điểm nhất định, có thể hết hạn, chứ không phải là đảm bảo an ninh vĩnh viễn.