Cầu cross-chain: 2.5 tỷ USD đã bay, nhưng logic kiến trúc vẫn còn chết

Nếu bạn nhìn vào tổng số tiền bị đánh cắp từ các cầu nối cross-chain từ năm 2020 đến nay, con số 2.5 tỷ USD không còn gây sốc nữa. Nó giống một cái chết âm thầm, được chôn vùi dưới hàng trăm bản cập nhật bảo mật và vài dòng tweet “funds are safe”. Nhưng điều khiến tôi bận tâm không phải là số tiền. Mà là thực tế: sau mỗi vụ hack, cộng đồng lại đổ lỗi cho “smart contract bug”, trong khi chính kiến trúc của các cầu nối – thứ mà tôi gọi là mượn xác thực tập trung để bán tính phi tập trung – chưa bao giờ được mổ xẻ đúng cách.

Hãy bắt đầu bằng một chi tiết nhỏ trong mã nguồn của Wormhole phiên bản V1 (tháng 2/2022). Hàm verifySignature() kiểm tra chữ ký của guardian – 19 node được uỷ quyền. Nếu 13/19 ký, giao dịch được coi là hợp lệ. Nhưng họ quên mất một chi tiết: threshold 13 là cố định, không thay đổi theo số lượng guardian thực tế. Khi một guardian bị compromised, kẻ tấn công chỉ cần 13 chữ ký – và 13 là con số có thể đạt được nếu chiếm được 13 node. Đó không phải lỗi code, đó là lỗi thiết kế mô hình tin cậy (trust model).

Context: cơ chế hoạt động của cross-chain bridge

Để hiểu tại sao các cầu nối lại dễ bị tổn thương, bạn phải hiểu cơ chế cốt lõi: một cầu nối (bridge) là một bên thứ ba tin cậy để chuyển thông điệp giữa hai blockchain. Có ba loại chính: trusted (dựa vào bộ xác thực tập trung), trustless (dùng light client + bằng chứng merkle) và hybrid (kết hợp cả hai). 90% các cầu nối đang hoạt động thuộc loại trusted hoặc hybrid – chúng sử dụng một tập hợp validator riêng (gọi là guardian, oracle, signer) để xác nhận giao dịch. Vấn đề: nếu tập validator này bị tấn công, toàn bộ số tiền trong bridge có thể bị rút.

Trong thực tế, không có cầu nối nào đạt được độ bảo mật tương đương với blockchain cơ sở. Ngay cả cầu trustless như IBC (Inter-Blockchain Communication) của Cosmos cũng chỉ an toàn khi các chain kết nối có cùng mô hình đồng thuận. Còn với Ethereum ↔ Solana, bạn buộc phải tin vào một bên thứ ba. Và đó là nơi thảm hoạ xảy ra.

Core: phân tích kỹ thuật các vụ hack tiêu biểu

Tôi sẽ không liệt kê tất cả. Tôi chỉ đào sâu vào 3 vụ đại diện cho 3 kiểu lỗ hổng cấu trúc:

1. Wormhole (tháng 2/2022, mất 326 triệu USD): Như đã đề cập, lỗi nằm ở cơ chế xác thực chữ ký guardian. Hàm verifySignatures không kiểm tra tính hợp lệ của guardianSetIndex, cho phép attacker sử dụng một guardian set cũ đã bị xoá. Cụ thể: hợp đồng Wormhole lưu trữ một mảng guardianSets có thể thay đổi. Khi team cập nhật guardian set mới, họ thêm vào mảng, nhưng không xoá set cũ. Attacker gọi hàm verifySignatures với index của set cũ – set cũ có thể đã bị leak private key từ trước. Kết quả: attacker mint 120,000 wETH trên Solana. Lỗi này không phải do reentrancy hay overflow, mà là do quản lý vòng đời của cấu hình validator. Dựa trên kinh nghiệm audit ICO năm 2017 của tôi, những lỗi liên quan đến state lưu trữ cấu hình thường bị bỏ qua vì dev cho rằng “nó không thay đổi thường xuyên”.

1. Ronin (tháng 3/2022, mất 625 triệu USD): Cầu nối của Axie Infinity sử dụng 9 validator. Attacker chiếm được 5 private key (4 từ Sky Mavis + 1 từ Axie DAO). Điểm mù: Sky Mavis đã chạy một “validator gas-free” (miễn phí gas) như một phần của chương trình tối ưu hoá – nhưng validator này thực chất là một node do Sky Mavis kiểm soát, không có bất kỳ ràng buộc on-chain nào. Kẻ tấn công xâm nhập vào máy chủ của Sky Mavis thông qua một lỗi RCE (Remote Code Execution) trên ứng dụng Discord bot. Mô hình tin cậy: 5/9 threshold quá thấp, cộng với việc một validator thực chất là “internal” đã phá vỡ toàn bộ giả định phi tập trung. Đây là lỗi ở lớp tổ chức, không phải lớp code – nhưng không ai audit tầng tổ chức khi kiểm tra cầu nối.

1. Multichain (tháng 7/2023, mất 126 triệu USD): CEO bị bắt, private key bị thu giữ. Dù vụ việc mang tính chất pháp lý, nhưng tựu trung là cầu nối dựa vào một multi-signature wallet do một thực thể duy nhất kiểm soát. Multichain từng tự hào là “bridge phi tập trung nhất” với mô hình SMPC (Secure Multi-Party Computation). Thực tế: các node SMPC chạy trên cùng một VPS, cùng một AWS account. Một lệnh revoke IAM là đủ để tê liệt toàn bộ hệ thống. Phi tập trung chỉ tồn tại trong whitepaper, không tồn tại trong deployment.

Từ ba vụ trên, tôi rút ra một trade-off mà ít người nói đến: cầu nối cross-chain càng dễ sử dụng, càng dễ bị tấn công. Để tối ưu trải nghiệm người dùng (tốc độ 1-2 phút, phí thấp), các bridge phải hy sinh bảo mật. Một cầu trustless thuần tuý (như việc chạy light client trên chain đích) có latency lên đến vài giờ và gas cực kỳ đắt. Không ai dùng. Vì vậy, thị trường chấp nhận rủi ro để đổi lấy sự tiện lợi. Nhưng họ có ý thức về rủi ro đó không? Dữ liệu cho thấy: sau mỗi vụ hack, TVL của bridge đó giảm 70% trong vòng 48 giờ, nhưng sau 6 tháng, nó thường phục hồi 50% – nghĩa là người dùng có trí nhớ ngắn. Hoặc họ không có lựa chọn khác.

Contrarian: điểm mù bảo mật mà cả ngành đang bỏ qua

Quan điểm phổ biến: “dùng bridge có bảo hiểm” hoặc “dùng trustless bridge”. Tôi cho rằng cả hai đều sai lầm. Bảo hiểm (như Nexus Mutual) chỉ trả tiền sau khi hack – nó không ngăn chặn mất mát. Và trustless bridge vẫn có điểm mù: ngay cả cầu IBC cũng gặp vấn đề về “light client update” – nếu chain A thay đổi bộ validator, light client trên chain B cần được cập nhật thủ công, tạo ra cửa sổ tấn công.

Điểm mù thực sự: cầu nối tạo ra bề mặt tấn công mới mà chưa có framework bảo mật nào bao phủ. Cụ thể: - Lỗ hổng giao tiếp giữa các lớp : Hợp đồng bridge trên chain nguồn + hợp đồng trên chain đích + oracle/relayer. Tấn công có thể nhắm vào relayer (như Ronin), vào hợp đồng (như Wormhole), hoặc vào cả hai. Không có một mô hình bảo mật thống nhất. - Vấn đề về thời gian sống của state : Một giao dịch bridge mất vài phút để hoàn tất. Trong khoảng thời gian đó, state trên chain nguồn có thể thay đổi (ví dụ: token bị burn, nhưng chưa mint). Kẻ tấn công có thể lợi dụng “race condition” giữa các block. Điều này đặc biệt nguy hiểm với các bridge dùng optimistic verification (chờ challenge). - Thiếu cơ chế phục hồi : Khi bridge bị hack, thường không có cách nào để rollback giao dịch. Hard fork là phương án cuối cùng, nhưng nó gây ra tranh cãi và mất lòng tin. Một số bridge (như Polygon) đã phải hard fork để khôi phục tiền – đó là một can thiệp chính trị, không phải kỹ thuật.

Tôi từng đề xuất một giải pháp vào năm 2023: sử dụng ZK-proofs kết hợp với optimistic challenge period – về mặt lý thuyết, nó giảm thiểu rủi ro trust model. Nhưng khi tính toán chi phí, mỗi lần bridge mất 0.02 ETH cho proof + 0.01 ETH cho challenge, tổng cộng 0.03 ETH (~50 USD) cho mỗi giao dịch. Không ai chịu trả. Thị trường chọn rẻ và nhanh, bất chấp nguy hiểm.

Takeaway: dự báo lỗ hổng tiếp theo

Trong vòng 12 tháng tới, tôi dự đoán một vụ hack lớn sẽ xảy ra không phải ở hợp đồng bridge, mà ở cơ sở hạ tầng oracle phụ trợ (off-chain data feed) mà bridge sử dụng. Các bridge ngày càng phụ thuộc vào các oracle để lấy giá token, xác thực block header, v.v. Một tấn công vào oracle (như cung cấp giá sai hoặc block header giả) có thể khiến bridge xử lý sai. Và vì hầu hết oracle đều tập trung hoặc bán tập trung, bề mặt tấn công rất rộng. Câu hỏi đặt ra: liệu người dùng có sẵn sàng từ bỏ bridge để chuyển sang giải pháp native swap (như THORChain, hay Cosmos IBC) hay không? Tôi nghĩ là không, vì họ muốn giữ thanh khoản trên chain chính. Vậy nên, hãy chuẩn bị tinh thần cho một mùa đông hack nữa.

Như tôi đã nói: 0xdead là mã lỗi của bridge, nhưng logic thì còn sống. Còn sống để chờ một thiết kế thực sự khác.