Liquid mất gần 4.000 BTC: Lỗ hổng xác thực bridge, không phải vụ đánh cắp khóa riêng

Liquid Network đã tạm dừng hoạt động bridge sau khi khoảng 4.000 BTC — được định giá khoảng 320 triệu USD tại thời điểm đó — rời khỏi ví liên minh dùng để bảo chứng L-BTC. Lượng rút này tương đương xấp xỉ 95% dự trữ được báo cáo. Các thông tin công khai hiện có hướng tới một lỗi lạm phát trong phần mềm Elements, thay vì việc khóa ủy quyền của liên minh Liquid hay SideSwap bị đánh cắp; tuy nhiên chi tiết kỹ thuật đầy đủ vẫn chưa được công bố. 413

Diễn biến được báo cáo

Chuỗi sự việc được mô tả như sau:

1. Một bên được cho là đã tạo ra L-BTC không được bảo chứng bằng BTC bị khóa, thông qua lỗi trong phần mềm Elements.
2. Số L-BTC này được gửi vào dịch vụ peg-out thông thường của SideSwap để đổi về BTC trên mạng Bitcoin.
3. Lệnh peg-out sử dụng Peg-out Authorization Key (PAK) hợp lệ của SideSwap; Liquid và SideSwap đều nói khóa này không bị xâm phạm.
4. Hạ tầng liên minh Liquid đã phê duyệt khoản chi BTC. Các báo cáo đề cập khoảng 3.996 BTC được chi trả, còn quy mô toàn sự kiện là gần 4.000 BTC. 26

Nói ngắn gọn: vấn đề được báo cáo không phải là kẻ tấn công lấy được khóa điều khiển quỹ dự trữ. Thay vào đó, một yêu cầu rút tiền dường như đã vượt qua các kiểm tra ủy quyền của hệ thống, dù L-BTC dùng để đổi có thể không có bảo chứng kinh tế hợp lệ.

Vì sao HSM vẫn ký khi không có khóa nào bị lộ?

Liquid vận hành theo mô hình Strong Federation: các thành viên liên minh cùng vận hành sidechain và kiểm soát lượng BTC dự trữ ở mạng chính thông qua cơ chế ký theo ngưỡng. Tài liệu kỹ thuật của Liquid gọi đây là mô hình đồng thuận Strong Federations.

HSM (mô-đun bảo mật phần cứng) có nhiệm vụ bảo vệ khóa ký và thực thi các chính sách đã được cấu hình. Nhưng HSM không phải một cơ quan độc lập có thể tự kiểm tra toàn bộ lịch sử phát hành để kết luận tài sản có thật sự được bảo chứng hay không.

Nếu một yêu cầu peg-out trình bày dữ liệu mà hệ thống nhận diện là hợp lệ — gồm cả đường ủy quyền hợp lệ — HSM có thể ký mà không hề có khóa riêng nào bị đánh cắp. Điểm then chốt trong sự cố được báo cáo là:

• Ủy quyền: peg-out được xử lý bằng PAK hợp lệ của SideSwap.
• Nguồn gốc và bảo chứng: L-BTC đem đi đổi được cho là sinh ra từ lỗi Elements, thay vì quy trình phát hành L-BTC thông thường có BTC bị khóa làm tài sản bảo chứng. 2

SideSwap cho biết khoản peg-out gần 4.000 BTC đi qua dịch vụ của họ dưới dạng lệnh khách hàng; PAK không bị xâm phạm và L-BTC xuất phát từ lỗi Elements, không phải hệ thống riêng của SideSwap.

Vì vậy, điều bị phơi bày không nhất thiết là thất bại của mật mã đa chữ ký hay HSM. Một lỗi chung trong lớp xác thực, phát hành hoặc chính sách có thể khiến những bộ ký tự động hoạt động đúng thiết kế cùng chấp nhận một yêu cầu rút vốn lẽ ra không đủ điều kiện. Chữ ký hợp lệ chỉ chứng minh các điều kiện ký đã được đáp ứng; nó không tự chứng minh L-BTC được đổi đã được bảo chứng đúng cách.

Họ có thực sự là “white hat”?

Những người kiểm soát số BTC đã để lại thông điệp on-chain: “we are whitehats. contact us on chain.” 16

Các báo cáo cũng cho biết Blockstream/Liquid đã liên hệ với họ qua các thông điệp on-chain có chữ ký. Nhóm này nói sẽ hoàn trả “phần lớn” số tiền sau khi lỗ hổng được vá trên toàn mạng. 418

Tuy nhiên, các dữ kiện đó chỉ cho thấy họ tự nhận động cơ là nghiên cứu bảo mật và để lại kênh liên lạc. Chúng không tự động chứng minh họ là white hat. Tại thời điểm các báo cáo được công bố, chưa có xác nhận tiền đã được trả lại, bản vá công khai hay việc mở lại mạng. 13

Cách gọi chính xác nhất hiện nay là “những người tự nhận là white hat” hoặc “white hat được cho là”. Chỉ khi tiền được hoàn trả, cơ chế khai thác và biện pháp khắc phục được xác minh độc lập, nhãn này mới có cơ sở vững chắc hơn.

Liquid, SideSwap và các sàn đã phản ứng ra sao?

Liquid đã vô hiệu hóa các node bridge và tạm dừng hoạt động, khiến việc chuyển tài sản thông thường giữa Bitcoin và Liquid bị chặn. Các sàn được thông báo để tạm dừng, hoặc chuẩn bị tạm dừng, nạp/rút L-BTC. 48

SideSwap cho biết họ cũng dừng peg-in và peg-out trong thời gian Liquid bị tạm dừng.

Đây là các bước cô lập sự cố: ngăn bridge tiếp tục dịch chuyển tài sản trong lúc đơn vị vận hành điều tra lỗ hổng, đánh giá trạng thái dự trữ và xác định điều kiện khởi động lại an toàn. Kế hoạch khắc phục được báo cáo phụ thuộc vào việc sửa lỗi, cập nhật các node bị ảnh hưởng và giải quyết tình trạng số BTC đã bị rút. 1318

Điều này có ý nghĩa gì với người nắm giữ L-BTC?

L-BTC được thiết kế để đại diện cho BTC trên Liquid. Nhưng trên thực tế, mức độ tương đương với BTC phụ thuộc vào việc bridge có hoạt động và có bảo chứng đáng tin cậy hay không.

Với khoảng 4.000 BTC được báo cáo đã rời khỏi quỹ dự trữ khoảng 4.200 BTC, trong khi bridge bị tạm dừng, khả năng đổi L-BTC về BTC thông thường đã bị gián đoạn. Thiếu hụt dự trữ được báo cáo trở thành rủi ro trực tiếp với người nắm giữ. 313

Điều này chưa xác định kết cục cuối cùng hay khả năng thu hồi. Nhưng trong thời gian xảy ra sự cố, nắm giữ L-BTC không còn tương đương về mặt vận hành với nắm giữ BTC có thể tự do rút trên lớp mạng chính Bitcoin. Kết quả sau cùng phụ thuộc vào việc thu hồi tiền, vá lỗi, quyết định của liên minh và chính sách của các nhà cung cấp dịch vụ.

Các tài sản khác phát hành trên Liquid

Việc BTC rời ví liên minh không đồng nghĩa các tài sản khác trên Liquid tự động mất phần dự trữ của tổ chức phát hành. Liquid tuyên bố USDT, DePix và các tài sản thế giới thực được token hóa (RWA) không bị ảnh hưởng trực tiếp bởi sự cố.

Dù vậy, “không bị ảnh hưởng trực tiếp” không có nghĩa là không có rủi ro. Việc mạng tạm dừng có thể tác động đến quyền truy cập ví, hỗ trợ từ sàn, thanh khoản, khả năng giao dịch và khả năng dùng L-BTC làm tài sản trả phí mạng hoặc tài sản bridge. Bảo chứng trực tiếp của từng tài sản vẫn phụ thuộc vào tổ chức phát hành và cơ chế lưu ký riêng; còn khả năng sử dụng thực tế lại phụ thuộc vào việc hạ tầng Liquid trở lại bình thường.

Bài học kiến trúc: bridge liên minh và hướng BitVM 1-trong-n

Liquid hiện dựa vào một liên minh đã biết, có quyền vận hành và kiểm soát BTC dự trữ bằng ký theo ngưỡng. Đây khác với mô hình mà chính cơ chế đồng thuận Bitcoin tự xác minh từng yêu cầu đổi trả đều có tài sản bảo chứng.

Peg liên minh hiện tại	Hướng BitVM kiểu 1-trong-n được đề xuất
Một liên minh cố định kiểm soát BTC dự trữ thông qua ký theo ngưỡng.	Blockstream mô tả đây là sáng kiến nghiên cứu dài hạn, chưa phải phương án thay thế Liquid đang triển khai.
An toàn phụ thuộc vào việc bảo vệ khóa, vận hành người ký, và tính đúng đắn của phần mềm xác thực/chính sách dùng chung.	Mục tiêu là giảm giả định phải tin cậy so với mô hình chữ ký ngưỡng thông thường.
Một lỗi phần mềm dùng chung có thể khiến toàn bộ bộ ký tự động cùng chấp nhận một cách diễn giải không hợp lệ.	Hệ thống kiểu BitVM dùng xác minh lạc quan và cơ chế phản biện; độ an toàn phụ thuộc vào thiết kế đúng và có ít nhất một bên phản biện trung thực, hoạt động.

Mô hình BitVM không loại bỏ rủi ro bridge mà chuyển rủi ro sang những giả định khác: bên phản biện phải có khả năng và động lực hành động, quy trình chứng minh gian lận phải đúng, và việc rút tiền có thể phức tạp hoặc chậm hơn. Nghiên cứu về bridge dựa trên BitVM mô tả mục tiêu an ninh là chỉ cần ít nhất một người tham gia trung thực; BitVM2 hướng tới việc cho phép bất kỳ ai phản biện một khẳng định không hợp lệ trong lúc vận hành.

Nếu cơ chế được báo cáo của vụ việc được xác nhận, sự cố Liquid cho thấy rõ điểm khác biệt này: một liên minh ký theo ngưỡng có thể vẫn chống được việc đánh cắp khóa, nhưng lại dễ tổn thương khi mọi người ký cùng dựa vào một diễn giải sai của phần mềm về việc tài sản có đủ điều kiện để đổi trả hay không.

Kết luận

Sự cố Liquid trị giá khoảng 320 triệu USD được báo cáo là một cuộc khủng hoảng ở lớp xác thực bridge, không phải vụ trộm khóa riêng theo kiểu thông thường. Một lượng L-BTC được cho là không có bảo chứng đã đi qua lộ trình peg-out được ủy quyền, dẫn tới việc liên minh giải phóng BTC thật. 24

Các câu hỏi còn bỏ ngỏ đều rất quan trọng: lỗ hổng Elements chính xác là gì, trạng thái cuối cùng của dự trữ và bảo chứng L-BTC ra sao, tiền có được hoàn trả không, và cần thay đổi những biện pháp kiểm soát nào trước khi bridge có thể vận hành lại an toàn. Cho tới khi các câu trả lời này được công khai và kiểm chứng, đây vẫn là một sự cố chưa khép lại — không nên xem như một màn tiết lộ lỗ hổng “white hat” đã hoàn tất hay một gián đoạn dịch vụ thông thường.