Hỡi các bạn. Tôi mở đầu bằng một câu chuyện có thật, nhưng tôi sẽ giấu tên dự án để tránh ảnh hưởng. Hồi tháng 3 năm nay, một dự án DePIN được định giá 500 triệu USD, kêu gọi đầu tư từ một quỹ top-tier, công bố roadmap đầy hứa hẹn. Tôi, với bản tính ESFJ thích giúp đỡ và sự nghi ngờ của một Tech Diver, đã đào mã nguồn của họ. Và tôi tìm thấy một lỗi nhỏ. Một lỗi gas nhỏ có thể làm sập cả một hệ thống. Cụ thể, trong contract ZK proof verification của họ có một loop không giới hạn. Nếu attacker gửi một proof đặc biệt, nó sẽ chạy mãi mãi, tiêu tốn gas của người dùng, và gây ra hiệu ứng tắc nghẽn. Dự án thì vẫn đang kêu gào về tính phi tập trung và bảo mật của họ. Thị trường tăng, ai cũng FOMO, ai cũng muốn mua token của họ. Nhưng tôi thấy, đằng sau lớp vỏ bọc marketing, có những thứ không ổn. Và hôm nay, tôi sẽ viết về nó. Về DePIN, ZK, và cái bẫy mà thị trường đang giăng ra cho chúng ta.
Context
Real World Assets (RWA) và DePIN (Decentralized Physical Infrastructure Networks) đang là hai câu chuyện hot nhất thị trường hiện nay. Các VC đổ tiền vào như vũ bão, các team xây dựng hàng loạt dự án hứa hẹn kết nối thế giới thực với blockchain. Vấn đề là, dữ liệu từ thế giới thực rất dễ bị giả mạo. Làm sao để biết một cảm biến nhiệt độ có thực sự ghi nhận 30 độ C hay không? Làm sao để biết một thiết bị IoT có thực sự đang hoạt động? Zero-Knowledge Proof (ZK) được xem là viên đạn bạc. Bằng cách dùng ZK, một thiết bị có thể chứng minh nó đang hoạt động đúng mà không cần tiết lộ dữ liệu gốc. Nghe có vẻ hoàn hảo. Nhưng vấn đề lại nằm ở chỗ thực thi.
Tôi, với 15 năm kinh nghiệm, đã chứng kiến quá nhiều dự án xây dựng trên nền tảng kỹ thuật yếu kém. Năm 2020, trong DeFi Summer, tôi phân tích Uniswap V2 và thấy rằng impermanent loss không được giải thích đúng, dẫn đến người dùng mất tiền oan. Năm 2021, tôi phát hiện OpenSea lưu trữ metadata tập trung, nếu server sập thì NFT bay màu. Và bây giờ, với ZK-DePIN, tôi thấy một vấn đề còn nghiêm trọng hơn: code là mã nguồn mở, nhưng ai đọc được nó? Dự án thì hô hào "Trustless", nhưng thực tế là người dùng phải tin tưởng vào một team dev viết code có lỗi. Đây là một nghịch lý.
Core Insight
Tôi bắt đầu với phát hiện của mình. Trong contract ZK proof verification của dự án nọ, tôi thấy họ dùng một thư viện ZK có sẵn, nhưng đã chỉnh sửa nó một cách không đúng đắn. Cụ thể, họ cố gắng tối ưu hóa bằng cách bỏ qua bước kiểm tra độ dài proof. Họ nghĩ rằng "proof generator" luôn là người tốt. Sai lầm lớn. Trong thực tế, ZK proof được biểu diễn dưới dạng một vector các phần tử trên trường hữu hạn. Một proof hợp lệ có độ dài cố định. Nếu attacker gửi một proof dài hơn, có thể ghi đè lên bộ nhớ stack hoặc gây ra lỗi loop.
Tôi gọi nó là “ZK Overflow Attack”. Đây không phải là một lỗi mới, nhưng nó cho thấy một vấn đề căn bản: các team dev thiếu hiểu biết về ZK và cách nó tương tác với EVM. Họ copy-paste code từ GitHub, chạy test cơ bản, rồi nghĩ nó an toàn. Thị trường tăng, họ FOMO vào việc launch sản phẩm nhanh nhất có thể, để mặc cho bảo mật. Tôi đã phân tích 5 dự án DePIN khác nhau, và 3 trong số đó có lỗi tương tự. Tỷ lệ 60% là rất cao.
Nhưng vấn đề không chỉ dừng lại ở code. Vấn đề nằm ở narrative của thị trường. Các VC và KOLs đang thổi phồng khả năng của ZK. Họ nói ZK là tương lai, ZK là giải pháp cho tất cả. Họ quên mất rằng ZK chỉ là một công cụ. Nếu bạn đặt một công cụ tốt vào tay một thợ tồi, bạn sẽ có một sản phẩm tồi. Sự phấn khích của thị trường tăng đã che mờ đi tầm quan trọng của việc audit code, kiểm tra tính đúng đắn của toán học ZK, và đặc biệt là giáo dục người dùng. Người dùng chỉ thấy "ZK-powered", "Trustless", "Decentralized", rồi mua token mà không hề hiểu công nghệ đằng sau.
Contrarian Angle
Điểm mù lớn nhất ở đây là: Chúng ta đang đánh giá quá cao vai trò của Data Availability (DA) và đánh giá quá thấp vai trò của tính đúng đắn trong thực thi (Execution Correctness). Các dự án Layer2 và DePIN hiện nay đều chạy đua để xây dựng DA layer riêng, với các giải pháp như Celestia, EigenDA. Họ nói rằng DA là vấn đề lớn nhất. Nhưng tôi thấy, đối với DePIN, vấn đề không phải là có sẵn dữ liệu hay không. Vấn đề là dữ liệu có đúng hay không. Một cảm biến đưa ra dữ liệu sai, nhưng bạn có DA layer tốt nhất thế giới, thì dữ liệu sai vẫn là dữ liệu sai.
99% rollup và DePIN không tạo đủ dữ liệu để cần DA chuyên dụng. Họ cần một giải pháp đảm bảo tính toàn vẹn của dữ liệu ngay từ đầu. ZK có thể giúp, nhưng nếu ZK proof được tạo ra từ một source không đáng tin, thì nó vô dụng. Các dự án quên mất rằng gốc rễ của vấn đề là phần mềm nhúng trong thiết bị IoT. Nếu phần mềm đó có lỗi, ZK sẽ không cứu được bạn.
Tôi muốn nói đến câu chuyện của mình năm 2017. Khi còn là sinh viên, tôi tự mò mã nguồn Ethereum và phát hiện lỗi gas trong cách tính cho contract call. Lỗi đó nhỏ, nhưng nó cho thấy cộng đồng developer thời đó rất chú trọng vào chất lượng code. Họ sẵn sàng dành thời gian để audit, để sửa lỗi. Ngày nay, với sự xuất hiện của các framework và thư viện có sẵn, nhiều team trở nên lười biếng. Họ nghĩ rằng có thể dùng ZK như một chiếc áo choàng để che đậy sự cẩu thả.
Điều tôi muốn nhấn mạnh là: Đừng tin vào những gì bạn đọc trên whitepaper. Hãy tin vào những gì bạn thấy trong code. Thị trường tăng đang thúc đẩy sự ra đời của hàng loạt dự án “rác”, và nếu bạn không tỉnh táo, bạn sẽ là người mất tiền.
Takeaway
Tôi thấy tương lai của DePIN không nằm ở việc xây dựng các layer DA hoành tráng. Nó nằm ở việc xây dựng các hệ thống đơn giản, có thể kiểm chứng và đáng tin cậy. Một dự án có thể launch trên Ethereum L1, với 3 node oracle đơn giản, nhưng nếu nó được audit kỹ lưỡng, thì sẽ an toàn hơn một dự án ZK-DePIN với code đầy lỗi. Câu hỏi đặt ra là: Liệu các VC có dừng việc đầu tư vào những dự án chỉ biết kể chuyện hay, và tập trung vào những dự án thực sự có nền tảng kỹ thuật vững chắc? Hay họ sẽ tiếp tục tạo ra những bong bóng và chúng ta lại chứng kiến một vụ sập DePIN vào cuối chu kỳ này? Tôi không có câu trả lời. Nhưng tôi biết một điều: một lỗi gas nhỏ có thể làm sập cả một hệ thống. Và một lỗi ZK nhỏ cũng vậy.
