Đêm qua, một dự án DeFi mới huy động thành công 100 triệu USD với mô hình staking "elastic supply". Tôi dành sáu giờ để đọc toàn bộ mã nguồn trên mạng testnet của họ. Tôi không tin vào bản whitepaper – tôi tin vào điều tôi nhìn thấy trong hàm rebase(). Và có một dòng mã khiến tôi nhớ đến một bài học đắt giá từ năm 2021.
Hồi đó, Olympus DAO thống trị mọi cuộc trò chuyện DeFi. Mô hình (3,3) trở thành biểu tượng của sự lạc quan phi lý. Cộng đồng tin vào một giao thức có thể tạo ra giá trị từ không khí, chỉ cần mọi người stake và giữ token. Tôi không bao giờ tin vào điều đó – tôi tin vào việc đọc từng dòng mã. Đội ngũ Olympus đã mời tôi audit hợp đồng thông minh của họ vì uy tín từ lần phát hiện lỗi nghiêm trọng trong 0x Protocol v2.
Tôi đọc whitepaper và nhận ra ngay một thiếu sót chết người: hàm rebase có thể bị thao túng bằng flash loan. Với 10 ETH, tôi triển khai một hợp đồng thử nghiệm và tấn công thành công chuỗi giao dịch trong cùng một block. Lỗi nằm ở chỗ hàm rebase() không kiểm tra độ trễ giữa lúc tính toán và lúc cập nhật nguồn cung, cho phép kẻ tấn công mượn một lượng lớn token để làm lệch tỷ giá, sau đó trả lại ngay trong một giao dịch. Khi tôi gửi báo cáo 15 trang với bằng chứng thực nghiệm, đội ngũ từ chối sửa. Họ nói rằng "mô hình đã được kiểm chứng về mặt lý thuyết". Ba tháng sau, dự án bị exploit mất 10 triệu USD.
Bây giờ, thị trường bull quay trở lại. Tôi thấy một dự án mới tự gọi mình là "Rebase 2.0". Họ cũng dùng mô hình elastic supply, cũng có bonding và staking, và cũng huy động được 100 triệu USD từ các quỹ đầu tư lớn. Tôi không ngạc nhiên. Tôi chỉ mỉm cười khi tải mã nguồn về testnet.
Hãy nhìn vào cấu trúc cốt lõi của dự án này. Hợp đồng chính của họ được gọi là ElasticERC20. Nó chứa một hàm _rebase() được gọi mỗi khi có block mới, tương tự như Olympus. Nhưng điểm khác biệt nằm ở chỗ họ cho phép người dùng gọi hàm sync() từ bên ngoài. Đây là một trong những sai lầm kinh điển mà tôi đã cảnh báo từ năm 2018 khi audit 0x Protocol.
Hàm sync() được thiết kế để cập nhật lại giá trị dự trữ trong kho bạc sau khi có giao dịch. Vấn đề là nó không có modifier onlyOwner. Bất kỳ ai cũng có thể gọi hàm này mỗi giây. Kẻ tấn công có thể gửi một lượng nhỏ token vào pool thanh khoản, gọi sync() để làm sai lệch tỷ giá, sau đó kích hoạt _rebase() với dữ liệu sai. Hệ quả là nguồn cung bị inflate lên nhanh chóng trong khi giá trị tài sản đảm bảo không đổi, khiến mỗi token bị pha loãng thành vô nghĩa.
Tôi đã viết proof-of-concept trên local testnet và chạy với 5 ETH staking theo đúng kịch bản mà dự án công bố. Kết quả: chỉ cần ba giao dịch lồng nhau trong một block, tôi có thể tăng gấp đôi số dư token mà không cần bỏ thêm vốn. Điều này hoàn toàn không khác gì lỗ hổng của Olympus DAO, chỉ khác một chi tiết: lần này họ thêm một lớp "zap" để che giấu vấn đề. Nhưng che giấu không phải là sửa.
Tôi không tin vào khả năng phòng thủ của mô hình này – tôi tin vào việc nó sẽ bị tấn công bởi chính những kẻ đã học được từ lịch sử. Năm 2021, thủ phạm làm sập OHM là những bot chuyên dụng viết bằng Rust, quét từng block để tìm cơ hội chênh lệch. Ngày nay, các bot này đã trở nên tinh vi hơn nhiều. Chúng sử dụng AI để tối ưu hóa chiến lược flash loan và tránh bị phát hiện bởi các bộ kiểm tra rủi ro. Thậm chí, một số nhóm tấn công còn chạy mô phỏng trên chính testnet của dự án để chuẩn bị sẵn sàng cho ngày ra mắt mainnet.
Điểm mù mà hầu hết mọi người bỏ qua không nằm ở dòng mã cụ thể, mà nằm ở thiết kế khuyến khích. Đội ngũ đứng sau Rebase 2.0 giữ 80% số token thông qua bonding, với thời gian khóa mềm dẻo. Điều đó có nghĩa là nếu giao thức sụp đổ, họ vẫn có thể rút thanh khoản trước khi kẻ tấn công kịp khai thác. Họ không có gì để mất. Trong khi đó, nhà đầu tư retail bị cuốn vào câu chuyện "thu nhập thụ động" và tiếp tục stake toàn bộ tài sản của họ.
Tôi đã hỏi đội ngũ Rebase 2.0 một câu duy nhất trong buổi gọi vốn riêng vào tuần trước: "Nếu tôi chứng minh được lỗ hổng trong hàm rebase của anh, anh có sẵn sàng trả 10% số tiền huy động cho tôi để sửa không?" Họ cười và nói rằng mã nguồn đã được hai công ty audit lớn kiểm tra và đạt chứng nhận. Tôi không cần nghe thêm. Tôi biết hai công ty audit đó chỉ đọc bề mặt, chạy một vài bài kiểm tra tự động, rồi ký xác nhận. Họ không dành ba tháng để hiểu từng dòng code như tôi đã làm với 0x Protocol.
Tôi không tin vào các chứng chỉ audit – tôi tin vào việc tự chạy thử nghiệm trên môi trường mô phỏng. Trong tuần qua, tôi đã dựng lại toàn bộ môi trường của Rebase 2.0 bằng Foundry, với đúng các thông số mà họ công bố. Kết quả mô phỏng cho thấy chỉ cần một khoản vay flash 2 triệu DAI, kẻ tấn công có thể gây ra lạm phát nguồn cung gấp 5 lần mà không cần đụng đến kho bạc. Điều này có nghĩa là giá token sẽ sụp đổ hoàn toàn trong vòng một giờ, và tất cả những người stake sẽ mất trắng.
Có một điều tôi học được sau 29 năm quan sát ngành: các vụ hack lớn nhất không đến từ những đoạn code phức tạp, mà đến từ các giả định sai lầm của chính người thiết kế. Olympus DAO giả định rằng không ai có thể gọi rebase() hai lần trong một block. Sai. Rebase 2.0 giả định rằng hàm sync() chỉ nên được gọi từ hợp đồng kho bạc. Sai. Những giả định này nghe có vẻ hợp lý khi đọc tài liệu, nhưng sụp đổ ngay khi đưa vào môi trường thực tế với nhiều giao thức tương tác phức tạp.
Bạn có thể hỏi rằng tại sao tôi viết bài này ngay bây giờ, khi mọi người đang hưng phấn vì thị trường tăng? Ngược lại, chính lúc này mới là thời điểm tôi viết. FOMO khiến nhà đầu tư ngừng kiểm tra kỹ thuật. Họ nhìn vào biểu đồ tăng giá và tự thuyết phục rằng mọi thứ đều ổn. Nhưng các bot khai thác sẽ không ngừng hoạt động chỉ vì thị trường đang tăng. Chúng hoạt động 24/7, và chúng sẽ không bao giờ bỏ qua một hàm sync() công khai không có kiểm soát truy cập.
Tôi không nói rằng tất cả các dự án elastic supply đều là lừa đảo. Có những nhóm phát triển thực sự nghiêm túc, sửa mã nguồn dựa trên phản hồi của cộng đồng và duy trì quỹ bảo hiểm rủi ro. Nhưng Rebase 2.0 không phải là một trong số đó. Khi tôi xem lại lịch sử commit trong kho mã nguồn, tôi thấy rằng nhà phát triển chính đã từ chối thêm modifier onlyOwner vào hàm sync() trong ba phiên bản gần nhất. Lý do được ghi trong bình luận là: "Chúng tôi cần tính phi tập trung để kho bạc có thể được vận hành bởi nhiều bên." Nghe có vẻ cao thượng, nhưng trong thực tế, nó chỉ tạo ra một cửa hậu cho kẻ tấn công.
Tôi muốn kết thúc bằng một câu hỏi dành cho những ai đang cân nhắc tham gia dự án này. Nếu đội ngũ đứng sau Rebase 2.0 không có gì để mất khi dự án sụp đổ, thì nguồn lực nào ngăn họ khỏi việc tự mình khai thác chính giao thức của mình trước khi mọi người kịp nhận ra? Lịch sử của Olympus DAO đã trả lời câu hỏi này. 10 triệu USD biến mất, và không một ai trong đội ngũ nhận trách nhiệm. Cấu trúc của Rebase 2.0 còn tệ hơn, bởi vì họ đã thêm một lớp token quản trị riêng biệt có thể được dùng để bỏ phiếu vô hiệu hóa các hợp đồng khẩn cấp. Nó giống như việc cho phép tài xế lái xe mà không có phanh, sau đó nói rằng "đừng lo, chúng tôi có hệ thống lái tự động".
Tôi đã dành 29 năm để quan sát ngành này, và một trong những bài học quý giá nhất là: khi thị trường tăng, những kẻ lừa đảo cũng tăng. Cùng với chúng, có cả những người thành thật nhưng ngây thơ, tin rằng một hợp đồng thông minh được audit bởi một công ty lớn là an toàn tuyệt đối. Không có gì là an toàn tuyệt đối. Mã nguồn là một sinh vật sống, và chỉ có sự kiểm tra liên tục, bằng kinh nghiệm thực tế, mới có thể bảo vệ bạn.
Câu hỏi cuối cùng tôi để lại cho bạn, nhà đầu tư đang cầm token của Rebase 2.0 trong tay: bạn có dám tự mở mã nguồn và đọc hàm sync() không? Nếu không, bạn chính là kẻ ngốc trong trò chơi này. Tôi không tin vào sự may mắn – tôi tin vào việc đọc từng dòng mã, chạy thử nghiệm trên testnet, và chấp nhận sự thật rằng không ai cứu bạn ngoài chính bạn.