Hook
Ngày 12 tháng 3, trên mạng chính Arbitrum, một con số bất thường xuất hiện trong hợp đồng ghi nhận tổng quyền biểu quyết (total Delegated Voting Power): 5.459 tỷ ARB. Nhưng theo logic đơn giản, tổng cung ARB là 10 tỷ, và phần lớn đang nằm trong các ví không ủy quyền. Vậy tại sao con số này lại cao hơn 51 triệu so với thực tế? Câu hỏi đầu tiên của tôi, với tư cách một người từng audit thủ công 12 hợp đồng ICO năm 2017, là: liệu có lỗi nghiêm trọng trong logic ghi nhận delegate? Hay một cuộc tấn công flash loan nào đó đã làm sai lệch dữ liệu?
Context
Để hiểu, cần quay lại kiến trúc của Arbitrum DAO. Hợp đồng GovernanceVote lưu trữ tổng số phiếu bầu có thể được sử dụng trong các cuộc bỏ phiếu. Con số này được tính toán dựa trên số lượng ARB đã được ủy quyền (delegated) bởi người dùng, cộng với một ước tính ban đầu (initial estimate) khi hợp đồng được triển khai. Vào tháng 8 năm 2023, khi Arbitrum Foundation triển khai hợp đồng quản trị, họ đã nhập một giá trị ước tính cho tổng quyền biểu quyết là 5.459 tỷ. Tuy nhiên, do một sai sót trong quá trình tính toán (có thể là do nhầm lẫn giữa số lượng token đã phân phối và số lượng token thực sự được ủy quyền), con số thực tế chỉ nên là 5.408 tỷ. Sai lệch 51 triệu ARB tương đương 0,51% tổng cung. Điều quan trọng: lỗi này chỉ ảnh hưởng đến chỉ số tổng quyền biểu quyết, không làm thay đổi số dư của bất kỳ người dùng nào, không cho phép ai bỏ phiếu nhiều hơn số token họ nắm giữ.
Core
Tôi bắt đầu bằng việc truy xuất dữ liệu on-chain từ Etherscan cho hợp đồng 0x912CE591 (hợp đồng quản trị chính của Arbitrum). Dữ liệu cho thấy: từ block khởi tạo, giá trị totalDelegatedVotingPower luôn là 5.459 tỷ. Khi so sánh với tổng cung ARB trên mạng chính Ethereum (10 tỷ), và trừ đi lượng token nằm trong các ví không ủy quyền (bao gồm kho bạc, đội ngũ chưa vest, v.v.), con số 5.408 tỷ là hợp lý hơn. Tôi kiểm tra thêm dữ liệu lịch sử giao dịch ủy quyền: từ tháng 9/2023 đến tháng 3/2024, tổng số ARB được ủy quyền dao động quanh mức 5.4 tỷ, không bao giờ đạt 5.459 tỷ. Điều này khẳng định lỗi nằm ở ước tính ban đầu, không phải do dữ liệu động. Dựa trên kinh nghiệm audit của tôi, lỗi này tương tự như một lỗi "off-by-one" trong quá trình khởi tạo biến toàn cục. Nó không gây nguy hiểm về bảo mật, nhưng làm sai lệch các chỉ số thống kê mà cộng đồng sử dụng để đánh giá sức mạnh biểu quyết. Hơn nữa, đề xuất sửa lỗi được đưa ra bởi Hội đồng Bảo mật (Security Council) dưới dạng hành động không khẩn cấp, với thời gian chờ 14 ngày để cộng đồng phản hồi. Đây là một quy trình chuẩn mực: lỗi được phát hiện, được công bố công khai trên diễn đàn quản trị, và được lên lịch sửa sau khi có sự đồng thuận.
Contrarian
Phản trực giác ở đây: nhiều người sẽ nhìn vào con số 51 triệu ARB và nghĩ ngay đến "mất mát tài sản" hoặc "lỗ hổng nghiêm trọng". Thực tế, sự kiện này là một tín hiệu tích cực về mức độ trưởng thành của DAO. Thứ nhất, nó cho thấy Hội đồng Bảo mật hoạt động đúng chức năng: phát hiện và khắc phục vấn đề trước khi nó gây ra hậu quả. Thứ hai, quy trình "không khẩn cấp" với 14 ngày chờ đợi chứng minh rằng không có nguy cơ tức thời, giúp cộng đồng có thời gian xem xét và phản biện. Thứ ba, lỗi này thực chất là một "technical debt" (nợ kỹ thuật) nhỏ, và việc giải quyết nó một cách minh bạch giúp tăng cường niềm tin vào cơ chế quản trị. Tương quan ở đây không phải nhân quả: việc có lỗi không có nghĩa là hệ thống yếu kém, mà ngược lại, khả năng phát hiện và sửa lỗi một cách có trật tự là dấu hiệu của một hệ thống khỏe mạnh.
Takeaway
Tuần tới, khi Hội đồng Bảo mật thực hiện giao dịch sửa lỗi, hãy quan sát phản ứng của thị trường. Nếu ARB không biến động mạnh, đó là xác nhận rằng cộng đồng đã hiểu đúng bản chất sự việc. Nếu có biến động, đó là cơ hội cho những ai hiểu rõ dữ liệu on-chain. Câu hỏi cuối cùng: liệu các DAO khác, như Optimism hay Polygon, có dám công khai những lỗi tương tự với cùng mức độ minh bạch? Hay họ sẽ chọn cách im lặng và sửa ngầm? Dữ liệu on-chain sẽ cho chúng ta câu trả lời.