Bạn đã bao giờ nhìn vào một dòng code và cảm thấy nó như một lời hứa hão huyền chưa? Tôi thì có, và nó thường đến từ những nơi ít ai ngờ tới nhất. Tuần trước, khi audit một giao thức yield farming mới, tôi phát hiện một lỗi reentrancy cổ điển – nhưng không phải trong contract chính, mà là trong một thư viện được cho là đã được kiểm toán. Điều này khiến tôi nhận ra: bảo mật không chỉ là về việc vá lỗi, mà là về cách chúng ta tin tưởng vào những gì chúng ta không nhìn thấy.
Hãy nói về Layer 2. Một vài tháng trước, tôi đào sâu vào mã nguồn của một dự án zk-rollup phổ biến. Mọi người đều bảo nó an toàn vì nó là zero-knowledge. Nhưng khi tôi bắt đầu mở rộng từng hàm nhỏ, tôi thấy một điều kỳ lạ: trong quá trình sinh proof, có một biến trạng thái không được xóa sau khi sử dụng. Trên lý thuyết, điều này có thể cho phép kẻ tấn công khai thác double-spend trong một điều kiện cụ thể. Tôi đã viết một PoC chỉ trong ba ngày, và nó hoạt động. Dự án đã vá lỗi ngay lập tức, nhưng câu hỏi đặt ra là: nếu tôi không nhìn vào chỗ đó thì sao?
Đây là vấn đề cốt lõi: chúng ta đang xây dựng những tòa nhà chọc trời trên nền móng mà không ai thực sự kiểm tra. Các hệ thống phức tạp như zk-rollup hay cross-chain bridge có quá nhiều lớp trừu tượng, khiến cho việc tìm ra lỗ hổng trở nên giống như mò kim đáy bể. Nhưng tôi không nghĩ đó là lỗi của công nghệ. Đó là lỗi của chúng ta – những người xây dựng và kiểm toán – vì đã quá tập trung vào narrative hơn là code.
Chính sự phức tạp không cần thiết đang giết chết DeFi. Nhiều dự án thêm tính năng chỉ để thu hút đầu tư, không phải để giải quyết vấn đề thực tế. Tôi đã thấy một giao thức lending có 15 contract khác nhau chỉ để quản lý một tính năng flash loan. Kết quả? Họ có một lỗi trong contract thứ 12 mà không ai kiểm tra kỹ, và tôi đã tìm ra nó chỉ bằng cách đọc từ trên xuống dưới.
Vài năm trước, trong một dự án ICO, tôi phát hiện một lỗ hổng tương tự. Tôi đã gửi báo cáo lên GitHub, và đội ngũ phát triển đã phải hoãn ICO để sửa. Khi đó, tôi nghĩ rằng thế giới crypto sẽ học được bài học. Nhưng không. Cùng một mô thức lặp lại: chạy đua với thời gian, bỏ qua kiểm tra chi tiết, và đặt niềm tin vào những thứ đã được kiểm toán một cách hời hợt.
Tôi không nói rằng tất cả các dự án đều xấu. Nhưng tôi nói rằng khuynh hướng 'chạy trước, sửa sau' đang tạo ra một hệ sinh thái mỏng manh. Mỗi lần một giao thức lớn bị hack, chúng ta lại thấy cùng một kịch bản: mất hàng triệu đô la, đổ lỗi cho hacker, và rồi quên đi. Nhưng điều mà ít ai nói đến là những lỗ hổng này thường có thể phát hiện được nếu chúng ta chịu khó đọc code một cách cẩn thận.
Từ kinh nghiệm audit của tôi, tôi thấy rằng hầu hết các lỗ hổng đều đến từ ba nguyên nhân: thiếu kiểm tra biên, sử dụng sai thư viện, và quá tin tưởng vào tính đúng đắn của các phép tính toán học. Đặc biệt, trong các giao thức yield farming, việc sử dụng số thập phân không chính xác đã gây ra vô số lỗi. Tôi từng thấy một contract tính lãi suất bằng cách chia cho 100 thay vì 10000, dẫn đến thất thoát hàng chục ETH chỉ trong một ngày testnet.
Vậy nên, khi tôi đọc một bài báo về 'Layer 2 giải quyết vấn đề scalability', tôi tự hỏi: giải quyết scalability bằng cách nào? Bằng cách thêm một lớp phức tạp khác lên trên một hệ thống vốn đã phức tạp? Điều này không khác gì việc đắp thêm tầng cho một tòa nhà đang lún. Chúng ta cần một sự thay đổi căn bản trong cách tiếp cận bảo mật: từ 'kiểm toán sau khi phát triển' sang 'bảo mật trong quá trình thiết kế'.
Hãy nhìn vào thị trường hiện tại. Thị trường gấu đang đến, và điều đó có nghĩa là nhiều dự án sẽ chết. Nhưng cũng có nghĩa là những dự án sống sót sẽ phải chứng minh được giá trị thực sự của mình. Và giá trị đó không đến từ marketing hay partnerships, mà từ code sạch, từ kiến trúc an toàn, từ sự minh bạch trong từng dòng code.
Tôi tin rằng tương lai của blockchain thuộc về những ai dám nhìn vào code và sửa nó, chứ không phải những ai chỉ biết nói về tầm nhìn. Khi bạn audit một giao thức, bạn không chỉ tìm lỗi. Bạn đang xây dựng niềm tin. Và niềm tin đó cần được đặt trên những dòng code có thể kiểm chứng, không phải trên những lời hứa hão huyền.
Liệu chúng ta có đủ can đảm để thay đổi cách làm việc của mình, hay chúng ta sẽ tiếp tục lặp lại những sai lầm cũ? Câu trả lời nằm ở cách bạn đọc bài viết này – và cách bạn sẽ hành động sau đó.