Lỗi trên Liquid Network có thể lý giải vụ thất thoát 320 triệu USD bằng BTC

Các nhà nghiên cứu đang phân tích sự cố Liquid Network trị giá khoảng 320 triệu USD cho biết đã phát hiện một lỗi bị nghi ngờ nằm ở cơ chế bộ nhớ đệm (cache) của phần mềm khi xác thực giao dịch. Diễn giải này đưa ra kịch bản cụ thể hơn về cách các token không có tài sản bảo chứng vẫn có thể được quy đổi để rút Bitcoin thật. Một số nguồn tin cũng đặt câu hỏi về quy trình triển khai phần mềm tại thời điểm xảy ra vụ việc. Theo Mononaut, đoạn mã chứa lỗi khai thác đã được đưa vào nhánh phát triển master của Elements từ tuần trước đó nhưng chưa từng xuất hiện trong bất kỳ bản phát hành gắn thẻ (tagged release) nào. Ông nói các "functionaries" của liên minh Liquid dường như đã vận hành đúng đoạn mã này, trong khi các nút khác lại từ chối các giao dịch không hợp lệ. Blockstream hiện chưa xác nhận mô tả về việc triển khai này trong các phát biểu được công bố. Nếu được kiểm chứng, vấn đề triển khai sẽ trở thành tâm điểm của sự cố: các thông tin ký (signing credentials) hợp lệ đã phê duyệt việc giải ngân BTC để đổi lấy LBTC bị cho là được tạo ra do lỗi phần mềm. Liquid là sidechain của Bitcoin, trong đó token LBTC được thiết kế phải được bảo chứng 1:1 bằng BTC do liên minh (federation) nắm giữ. Như CryptoSlate từng đưa tin, SideSwap cho biết ngày 6/9 một khách hàng đã nộp 4.000 LBTC qua dịch vụ peg-out, dẫn đến việc giải phóng khoảng 3.996 BTC. Liquid khẳng định khóa ủy quyền peg-out của SideSwap cũng như các khóa khác của liên minh không bị lộ hoặc bị chiếm đoạt. Trọng tâm của các phân tích kỹ thuật đang nổi lên nằm ở câu hỏi: các token đó đã đi vào quy trình rút tiền như thế nào. Calle mô tả một lỗ hổng liên quan đến "range proofs", cơ chế cho phép các nút kiểm tra rằng các giá trị giao dịch bị che giấu nằm trong một khoảng hợp lệ mà không cần lộ số liệu. Với confidential transactions của Liquid, việc xác thực không chỉ dừng ở cân bằng tổng đầu vào và đầu ra. Nếu tồn tại một đầu ra âm bị che giấu, nó có thể bù trừ cho một đầu ra dương lớn hơn, khiến token mới phát hành trông như vẫn cân bằng về mặt toán học. Range proofs được thiết kế để ngăn kịch bản này. Do việc kiểm tra range proofs tốn tài nguyên tính toán, các nút sẽ lưu kết quả xác minh thành công vào cache để tái sử dụng. Theo Calle, kẻ tấn công có thể tạo ra một đầu ra và bằng chứng không hợp lệ nhưng lại khớp với khóa cache (cache key) của một lần kiểm tra hợp lệ trước đó. Khi một nút tìm thấy kết quả trong cache, nó sẽ bỏ qua bước xác minh vốn phải loại bỏ đầu ra làm "phình" (inflationary) lượng token. Charles Guillemet đồng tình với cách lý giải này, cho rằng kẻ tấn công đã tạo ra một vụ va chạm khóa cache (cache-key collision) được "chế tác" để một confidential transaction không hợp lệ vượt qua kiểm tra range. Calle lưu ý mô tả của ông đã giản lược cơ chế và có thể còn sai sót. Một hướng tái dựng giao dịch khác do Stu thực hiện cho thấy có các giao dịch chuẩn bị, tiếp đó là một giao dịch bị cho là không hợp lệ tại block Liquid 4.050.336. Stu cho biết giao dịch này đã tạo ra khoảng 3.996,0183 LBTC trước khi số tiền được rút tiếp qua SideSwap. Mononaut bổ sung rằng đã xuất hiện khác biệt giữa các nút chấp nhận giao dịch và các nút từ chối. Ông nói các functionaries của liên minh đã chấp nhận các giao dịch khai thác, phê duyệt rút tiền và tiếp tục tạo block. Nhiều nút khác, bao gồm các nút phục vụ Liquid explorer của mempool, lại từ chối block bị ảnh hưởng. Điều này có thể lý giải vì sao một trình khám phá theo các nút "từ chối" sẽ không hiển thị những giao dịch mà nơi khác vẫn thấy. Sự phân kỳ được báo cáo khiến phiên bản phần mềm vận hành tại thời điểm đó trở thành yếu tố then chốt để hiểu nguyên nhân. Một báo cáo hậu kiểm (postmortem) sẽ cần làm rõ: những chức năng mã nào đã chạy, vì sao chúng được triển khai, và hành vi xác thực của chúng khác gì so với các nút đã từ chối block. Trong khi đó, nhóm kiểm soát số BTC đã rút tự mô tả là "whitehat" và đặt điều kiện chỉ hoàn trả phần lớn tài sản sau khi lỗi được khắc phục trên các nút bị ảnh hưởng. Thông tin hiện có chưa xác nhận việc hoàn trả đã hoàn tất hay quá trình triển khai bản vá đã được thực hiện xong. Thu hồi BTC sẽ xử lý phần thiếu hụt dự trữ; còn việc giải thích vì sao các nút liên minh chấp nhận giao dịch và chứng minh phần mềm đã sửa lỗi sẽ từ chối chúng mới là cách khép lại lỗ hổng đã khiến dự trữ bị rút ra.