Hãy thử chạy một truy vấn trên Etherscan: tìm kiếm tất cả các giao dịch gọi hàm claim() của một hợp đồng airdrop phổ biến trong top 10. Bạn sẽ thấy một điều kỳ lạ.
Hơn 40% địa chỉ ví nhận airdrop đã chuyển toàn bộ token sang một sàn giao dịch tập trung trong vòng chưa đầy 30 phút sau khi claim. Đây không phải là một cuộc tấn công. Đây là hành vi 'bình thường' của người dùng. Nhưng nó nói lên một sự thật phũ phàng: đa số holder không phải là người ủng hộ dự án, mà là những kẻ săn airdrop chuyên nghiệp.
Tuy nhiên, câu chuyện thú vị hơn nằm ở phía ngược lại: tại sao các giao thức lại liên tục phát hành airdrop cho những ví rõ ràng là bot? Câu trả lời nằm ở một lỗ hổng dữ liệu nghiêm trọng trong thiết kế incentive layer.
Context:
Blockchain là một cỗ máy sự thật, nhưng sự thật đó là về dữ liệu giao dịch, không phải về mục đích của con người. Mỗi một địa chỉ ví là một 'identity' giả định. Không có cách nào để biết đằng sau một địa chỉ là một người dùng thực sự, một bot, hay một nhóm Sybil.
Hầu hết các giao thức DeFi hiện nay sử dụng một bộ lọc chống Sybil cơ bản. Họ dùng các heuristic như: lịch sử giao dịch, số lượng tương tác, số dư tối thiểu. Nhưng những bộ lọc này đã trở nên lỗi thời. Tôi đã từng audit một dự án airdrop vào năm 2021, nơi mà team của họ tự hào về bộ lọc Sybil 'tinh vi' của mình. Nó chỉ đơn giản là loại bỏ các ví có ít hơn 5 giao dịch. Kết quả? Những kẻ săn airdrop đã deploy một mạng lưới bot thực hiện chính xác 5 giao dịch trên mỗi ví, kiếm về hàng triệu token.
Lõi của vấn đề là một bài toán kinh điển trong khoa học dữ liệu: đánh đổi giữa độ chính xác (precision) và độ phủ (recall).
- Precision cao: Bạn chỉ chấp nhận những địa chỉ ví có độ tin cậy cực cao, ví dụ: đã tham gia governance, đã stake token trong 6 tháng. Điều này sẽ giết chết sự phát triển của cộng đồng mới.
- Recall cao: Bạn chấp nhận tất cả mọi người, nhưng sẽ bị Sybil tấn công làm loãng phần thưởng.
Không có bộ lọc nào có thể đạt được cả hai cùng lúc. Sự thật là, các dự án thường chọn recall cao vì nó tạo ra một 'câu chuyện' đẹp về sự phát triển của cộng đồng, giúp họ gọi vốn dễ dàng hơn.
Core: Phân tích cấp mã nguồn và Trade-offs
Hãy nhìn vào cấp độ hợp đồng thông minh. Một hàm claimAirdrop() điển hình trông như thế này:
function claimAirdrop(uint256 _amount, bytes32[] calldata _proof) external {
require(!claimed[msg.sender], "Already claimed");
// Verify Merkle proof...
// Transfer token...
claimed[msg.sender] = true;
}Hàm này không kiểm tra bất cứ điều gì về lịch sử của msg.sender. Nó chỉ kiểm tra xem địa chỉ đó có trong danh sách Merkle tree hay không. Ai đã tạo ra danh sách đó? Một tập lệnh off-chain, dựa trên dữ liệu on-chain.
Trade-off chính ở đây là chi phí gas và tính phi tập trung. Việc thực hiện kiểm tra Sybil phức tạp trong EVM (ví dụ: gọi oracle để xác minh lịch sử giao dịch) sẽ làm tăng chi phí gas lên gấp nhiều lần. Về mặt kỹ thuật, việc kiểm tra Sybil được đẩy hoàn toàn ra ngoài chuỗi (off-chain). Điều này tạo ra một lỗ hổng: logic phân phối trở nên kém minh bạch và dễ bị thao túng.
Dựa trên kinh nghiệm audit của tôi, tôi từng thấy một trường hợp nơi các nhà phát triển đã viết một bộ lọc off-chain có chứa một 'danh sách trắng' bí mật chứa địa chỉ ví của chính họ và bạn bè. Họ lý luận rằng điều này là cần thiết để 'chống lại Sybil', nhưng thực chất là một backdoor. Vấn đề không chỉ là Sybil. Vấn đề là sự tập trung hóa của sự thật. Ai kiểm soát bộ lọc, người đó kiểm soát việc phân phối.
Contrarian: Điểm mù bảo mật
Góc nhìn phản trực giác ở đây là: Các cuộc tấn công Sybil không phải là vấn đề bảo mật lớn nhất. Vấn đề lớn nhất là sự thao túng dữ liệu lịch sử để đủ điều kiện nhận airdrop, hay còn gọi là 'social engineering attack' trên quy mô lớn.
Hãy tưởng tượng một kịch bản: một quỹ đầu cơ muốn thao túng một giao thức DeFi. Họ không cần phải hack hợp đồng thông minh. Họ chỉ cần tạo hàng nghìn ví, thực hiện các giao dịch giả mạo trên DEX của giao thức đó trong một khoảng thời gian dài. Điều này làm tăng khối lượng giao dịch (volume) một cách giả tạo, giúp giao thức đó đáp ứng các KPIs của vòng gọi vốn, và sau đó nhận được airdrop khổng lồ. Đây là một 'attack vector' ít được chú ý: tấn công vào data credibility.
Tôi đã nghiên cứu về zero-knowledge proofs (ZKP) và tôi thấy một tiềm năng ở đây. ZKP có thể cho phép một người dùng chứng minh họ đã thực hiện một hành động (ví dụ: swap) mà không tiết lộ địa chỉ ví của họ. Điều này làm cho việc xây dựng lịch sử cho mỗi ví trở nên vô nghĩa, vì lịch sử đó là ẩn danh. Nhưng vấn đề là, ZKP vẫn quá đắt đỏ và phức tạp để áp dụng cho tất cả các giao dịch airdrop. Hầu hết các dự án sẽ tiếp tục sử dụng các bộ lọc off-chain rẻ tiền và dễ bị tấn công.
Một điểm mù khác: sự phụ thuộc vào các oracle off-chain. Nhiều giao thức kiểm tra số dư của một ví trên các giao thức khác (ví dụ: Uniswap, Aave). Điều này tạo ra một vector tấn công gián tiếp: một kẻ tấn công có thể thao túng dữ liệu trên Uniswap (ví dụ: tạo một thanh khoản giả) để làm cho ví của họ trông có vẻ 'đáng tin cậy' trên giao thức mục tiêu.
Takeaway: Dự báo lỗ hổng
Trong 12–18 tháng tới, tôi dự đoán sẽ xuất hiện một làn sóng các cuộc tấn công mới, không nhắm vào contract code, mà nhắm vào lớp dữ liệu lịch sử (historical data layer). Các giao thức sẽ phát hiện ra rằng các bộ lọc Sybil hiện tại hoàn toàn vô dụng trước các bot được tinh chỉnh.
Tôi đã chứng kiến một dự án farm điểm, nơi các bot đã mô phỏng hành vi của người dùng thực một cách hoàn hảo trong suốt 3 tháng, thực hiện tất cả các loại tương tác: swap, add liquidity, vote, stake. Chúng trông giống hệt con người. Khi airdrop diễn ra, chúng chiếm 60% tổng số token. Đây không phải là chuyện của tương lai. Đây là chuyện đang xảy ra ngay bây giờ.
Câu hỏi đặt ra là: Liệu chúng ta có đang xây dựng một hệ thống 'sự thật' mà ở đó, sự thật có thể dễ dàng bị mua chuộc bằng chi phí gas?