Lỗ hổng lớn nhất là tin rằng không có lỗ hổng.
Ngày 12 tháng 8 năm 2025, Harmony Protocol phát hiện một sự kiện mint trái phép ONE. Con số ban đầu là 4 tỷ. Nhưng khi đội ngũ dựng lại on-chain, họ tìm thấy 3.01 nghìn tỷ ONE – tương đương 3.010.000.000.000 token – được phát sinh từ sáu giao dịch cross-shard giả mạo. Đây không phải lỗi oracle, không phải tấn công reentrancy thông thường. Đây là một cross-shard receipt replay vulnerability – một lỗ hổng cho phép kẻ tấn công tái thực thi receipt đã được xử lý, vắt kiệt token từ những block rỗng.
Tôi đã dành 25 năm quan sát ngành này. Từ lỗ hổng bầu cử EOS 2017 đến kiểm toán Cosmos IBC, tôi học được một điều: những lỗi nguy hiểm nhất thường nằm ở lớp giao tiếp giữa các shard, nơi mà các lập trình viên giỏi nhất cũng dễ bỏ qua giả định về tính duy nhất của receipt. Và Harmony Protocol vừa trở thành bài học kinh điển cho điều đó.
Context: Cơ chế cross-shard và giả định về tính không thể tái tạo
Harmony Protocol là một blockchain sharding, chia mạng thành nhiều shard (bốn shard chính) để tăng thông lượng. Mỗi shard xử lý giao dịch riêng, nhưng khi cần chuyển token từ shard A sang shard B, cơ chế cross-shard được kích hoạt. Giao dịch gốc được thực thi ở shard nguồn, tạo ra một receipt (biên lai) chứa bằng chứng đã xử lý. Receipt này sau đó được gửi đến shard đích để mint token tương ứng.
Vấn đề nằm ở chỗ: cơ chế xác minh receipt không kiểm tra tính duy nhất của việc thực thi. Nếu một receipt có thể được gửi lại nhiều lần, mỗi lần sẽ mint thêm token. Đây chính là những gì đã xảy ra. Kẻ tấn công tận dụng lỗ hổng trong quorum verification – cơ chế đồng thuận giữa các validator để xác nhận receipt – cho phép họ tái sử dụng receipt từ các block rỗng (empty blocks) đã được xử lý trước đó.
Harmony Protocol đã xác nhận: 4 tỷ ONE đầu tiên được mint từ hai block rỗng, tạo ra 1 tỷ và 3 tỷ ONE tương ứng. Sau đó, 2.8 tỷ ONE được chuyển sang các địa chỉ khác. Nhưng bức tranh đầy đủ còn khủng khiếp hơn: on-chain reconstruction cho thấy 3.01 nghìn tỷ ONE được phát hành qua sáu giao dịch giả mạo. Con số này vượt xa nguồn cung lưu hành của ONE (vốn chỉ vài tỷ). Điều đó có nghĩa là kẻ tấn công đã mint ra một lượng token lớn hơn toàn bộ nguồn cung hiện tại, gây ra nguy cơ pha loãng cực độ và sụp đổ giá trị.
Core: Phân tích kỹ thuật – Tại sao cross-shard receipt replay lại nguy hiểm đến vậy?
Để hiểu, hãy nhìn vào mã nguồn giả định của cơ chế cross-shard (tôi đã từng audit các hệ thống tương tự trong quá khứ). Một receipt thường chứa các trường: shard_source, shard_dest, amount, tx_hash, validator_signatures. Khi shard đích nhận receipt, nó kiểm tra chữ ký của validator và thực thi mint. Lỗ hổng nằm ở chỗ: không có nonce hoặc unique identifier nào được gắn với receipt sau khi thực thi. Receipt có thể được lưu trữ và gửi lại – không cần thay đổi gì – vì validator vẫn xác nhận tính hợp lệ của chữ ký cũ.
Trong trường hợp của Harmony, block rỗng là những block không có giao dịch thực tế, nhưng cross-shard receipt từ block đó vẫn hợp lệ. Kẻ tấn công đã tạo ra các receipt từ block rỗng, sau đó gửi chúng đến shard khác nhiều lần. Mỗi lần gửi, shard đích mint token mới, vì không có cơ chế nào để kiểm tra “receipt này đã được dùng chưa”. Đây là lỗi kinh điển của distributed systems: thiếu idempotency.
Dựa trên kinh nghiệm audit của tôi, tôi đã thấy lỗi tương tự trong các hệ thống cross-chain bridge. Nhưng ở mức độ shard, nó còn nguy hiểm hơn vì tốc độ xử lý nhanh và phạm vi ảnh hưởng rộng. Khi bạn có thể mint token từ hư vô, không cần tài sản thế chấp, không cần thanh khoản – bạn đang phá vỡ nền tảng kinh tế của toàn bộ giao thức.
Con số 3.01 nghìn tỷ ONE cho thấy kẻ tấn công đã lặp lại quá trình này nhiều lần, mỗi lần mint với số lượng lớn. Sáu giao dịch giả mạo, mỗi giao dịch có thể mint tới 500 tỷ ONE. Điều này đặt ra câu hỏi: tại sao validator không phát hiện bất thường? Câu trả lời nằm ở quorum verification vulnerability – lỗ hổng trong cơ chế xác minh chữ ký. Có thể số lượng validator yêu cầu quá thấp, hoặc chữ ký có thể được giả mạo nếu attacker kiểm soát đủ số lượng node. Harmony đã xác nhận họ fix cả hai lỗ hổng trước khi staking, nhưng quá muộn.
Contrarian: Góc nhìn phản trực giác – Vấn đề không chỉ nằm ở code, mà ở triết lý thiết kế sharding
Nhiều người sẽ nói: “Đây là lỗi validator, cần tăng cường bảo mật.” Nhưng tôi thấy một vấn đề sâu hơn: niềm tin mù quáng vào tính không thể sai lầm của cross-shard communication. Các đội phát triển thường cho rằng receipt là immutable và không thể tái sử dụng, vì chúng đã được xác nhận bởi validator. Họ quên mất rằng tính bất biến của receipt chỉ tồn tại trong shard nguồn; khi nó được gửi qua mạng, nó trở thành một thông điệp có thể bị replay.
Góc nhìn phản trực giác: Lỗ hổng lớn nhất là tin rằng không có lỗ hổng. Harmony Protocol đã tồn tại nhiều năm, trải qua nhiều lần audit, nhưng vẫn mắc lỗi cơ bản này. Tại sao? Vì họ tập trung vào tối ưu hiệu suất sharding (tốc độ, chi phí) mà quên mất rằng cross-shard là điểm chạm yếu nhất. Càng nhiều shard, càng nhiều điểm cần kiểm tra tính duy nhất. Và mỗi điểm đó đều có thể bị khai thác.
Một điểm mù khác: empty blocks. Tại sao block rỗng lại có thể tạo ra receipt? Block rỗng thường là block không có giao dịch, nhưng trong sharding, cross-shard receipt có thể được tạo từ block rỗng nếu validator đồng thuận sai. Điều này cho thấy cơ chế tạo receipt không gắn với nội dung giao dịch thực tế. Kẻ tấn công chỉ cần một block rỗng hợp lệ, ký receipt giả, và gửi đi. Đây là lỗ hổng thiết kế ở cấp độ giao thức, không chỉ là lỗi implementation.
Takeaway: Dự báo lỗ hổng và bài học cho hệ sinh thái
Hiện tại, Harmony đã dừng shard 0 ở block 92,753,555, tạm dừng bridge, và phối hợp với validator và LayerZero để đóng băng tài sản. Họ chuẩn bị rollback mạng về block 92,730,034 – trước cuộc tấn công. Nhưng câu hỏi lớn: liệu rollback có đủ không? Nếu token đã được chuyển sang các chain khác qua bridge, việc đóng băng chỉ có hiệu quả một phần. Và nếu kẻ tấn công đã bán một phần trên CEX, thiệt hại là vĩnh viễn.
Tôi thấy một dự báo: cross-shard receipt replay sẽ trở thành vector tấn công phổ biến trong sharding blockchain. Các dự án như Polkadot, Near, hoặc bất kỳ chain nào dùng shared security với cross-chain messaging đều có nguy cơ. Bài học từ Harmony: hãy kiểm tra tính idempotency của mọi receipt, gắn nonce hoặc unique identifier, và không bao giờ tin rằng một receipt chỉ được xử lý một lần.
Lỗ hổng lớn nhất là tin rằng không có lỗ hổng. Và trong một hệ thống sharding, nơi mọi thứ đều được phân mảnh, lỗ hổng lớn nhất lại là niềm tin rằng các mảnh đó có thể giao tiếp an toàn mà không cần kiểm tra kỹ lưỡng. Harmony Protocol vừa chứng minh điều đó. Câu hỏi cho các dự án khác: bạn đã kiểm tra cross-shard receipt của mình chưa?