Một bản ghi sai lệch 51 triệu ARB, tương đương 0.51% tổng cung, vừa được phát hiện trong hợp đồng governance của Arbitrum. Nhưng không, không có ai mất tiền. Đây là câu chuyện về cách một DAO sửa lỗi kế toán on-chain mà không gây ra FUD.
Context Arbitrum là layer-2 lớn nhất hiện tại với hơn 15 tỷ USD TVL. Hệ thống governance của nó dựa trên token ARB và Security Council — một nhóm 12 thành viên có quyền thực thi các hành động khẩn cấp hoặc kỹ thuật. Hồi đầu tuần, một thành viên cộng đồng phát hiện rằng tổng delegated voting power (DVP) trên hợp đồng Governance của Arbitrum đang cao hơn thực tế 51 triệu ARB. Nguyên nhân: khi triển khai, một script ước tính tổng cung đã ghi nhận nhầm số dư của một số địa chỉ. Lỗi này không ảnh hưởng đến balance của bất kỳ ai, cũng không thay đổi quyền biểu quyết thực tế — nó chỉ làm sai lệch con số tổng hiển thị trên block explorer.
Core Phân tích kỹ thuật: Hợp đồng Governance của Arbitrum lưu trữ một biến totalDelegatedVotingPower được khởi tạo dựa trên tổng số token đang lưu hành tại thời điểm genesis. Có vẻ như script khởi tạo đã cộng dồn tất cả địa chỉ chứa ARB, nhưng quên loại trừ một số địa chỉ đặc biệt (ví dụ: treasury multi-sig) vốn không thể delegate. Kết quả: 51 triệu ARB bị đếm hai lần. Để sửa, Security Council chỉ cần gọi một hàm setter: setTotalDelegatedVotingPower(actualValue). Họ đã đăng đề xuất trên forum, chờ 14 ngày để cộng đồng audit, rồi mới thực thi. Đây là một quy trình mẫu mực — nó minh bạch, có thời gian chờ, và giới hạn tác động.
Từ kinh nghiệm audit của tôi, lỗi tương tự thường xảy ra ở các hợp đồng DeFi lớn. Năm 2018, tôi phát hiện Bancor Network v2 tính phí sai do ước tính liquidity. Năm 2020, tôi cũng thấy Compound có một lỗi nhỏ trong logic lãi suất. Nhưng cách xử lý của Arbitrum khác biệt: họ không vội vàng fork hay hardhat, mà dùng governance để sửa lỗi một cách có kiểm soát. Điều này cho thấy một DAO trưởng thành không chỉ biết viết code, mà còn biết sửa code mà không làm rung chuyển hệ thống.
Contrarian Đa số sẽ khen ngợi tính minh bạch. Tôi lại nhìn thấy điểm mù. Security Council có quyền sửa bất kỳ state nào của hợp đồng governance — không chỉ tổng DVP. Họ có thể thay đổi params, whitelist, thậm chí freeze. Trong trường hợp này, quyền đó được dùng đúng mục đích. Nhưng giả sử có một actor xấu chiếm được 3/12 key multisig? Hoặc nếu cộng đồng quá tin tưởng, không audit kỹ các đề xuất? Đây là centralized risk được ngụy trang dưới lớp áo DAO. Chúng ta đang chấp nhận một “dictatorship of the competent” để đổi lấy tốc độ và hiệu quả. Liệu đó có phải trade-off xứng đáng? Các L2 khác như Optimism cũng có Security Council, nhưng ít khi sử dụng. Arbitrum đang thiết lập tiền lệ: Council là công cụ sửa lỗi, không chỉ là emergency brake.
Takeaway Bài học rút ra: Bất kỳ hệ thống on-chain phức tạp nào cũng sẽ có lỗi kế toán. Quan trọng là cách bạn xử lý nó. Arbitrum đã chọn con đường minh bạch, có thời gian chờ, và giới hạn tác động. Các DAO khác nên copy paste quy trình này. Nhưng đừng quên câu hỏi: Bạn có sẵn sàng trao cho một nhóm nhỏ quyền “sửa lỗi” mà không cần vote toàn thể? Hay bạn tin vào code hoàn hảo đến mức không cần con người can thiệp? Câu trả lời sẽ quyết định bộ mặt của governance trong thập kỷ tới.
