Bạn có tin không, có một giao thức đã sai tổng số phiếu bầu trên chuỗi của mình suốt nhiều tháng. 51,7 triệu ARB, tương đương 0.5% tổng cung, là một sai số trong sổ cái kỹ thuật số của DAO. Không phải ai đó ăn cắp, không phải lỗ hổng reentrancy, không phải oracle bị tấn công. Chỉ đơn giản là một con số được ghi lại sai từ ngày đầu tiên. Đội ngũ Arbitrum bảo vệ nó là một "bản ghi kế toán kỹ thuật". Và đây chính là lúc tôi, một thợ lặn kỹ thuật, phải nói rằng: Đây không phải là một bản vá lỗi vô hại. Đây là một lời nhắc nhở lạnh lùng về một rủi ro mà hầu hết mọi người trong DeFi đều phớt lờ: rủi ro về đặc quyền, về sức mạnh thầm lặng của các bộ phận an ninh, và về những dòng mã chết mà không ai thèm nhìn vào.
Hãy bỏ qua bài đăng trên blog bóng bẩy của Arbitrum Foundation. Họ không nói dối. Họ chỉ chọn cách nói sự thật một cách có lợi nhất. Họ mô tả hành động của Hội đồng An ninh như một hành động "không khẩn cấp", một sự điều chỉnh kế toán đơn thuần. Vâng, về mặt kỹ thuật, đó là sự thật. Họ đang sửa một lỗi trong hợp đồng ArbVote - hợp đồng quản lý quyền biểu quyết được ủy quyền. Tổng số delegatedVotingPower được ghi cứng (hardcoded) không khớp với tổng số thực tế của các ARB được ủy quyền. Nó sai khoảng 0.5%. Ai đó, trong quá trình triển khai ban đầu, đã ước tính sai. Nó không phải là lỗi logic nghiêm trọng. Nhưng nó là một vết nứt trong nền tảng của sự tin tưởng.
Khi bạn audit một hợp đồng thông minh, có hai loại lỗi: lỗi chức năng và lỗi trạng thái. Lỗi chức năng là khi một hàm không làm những gì nó phải làm. Lỗi trạng thái là khi một biến lưu trữ một giá trị sai. Lỗi của Arbitrum là một lỗi trạng thái cổ điển. Vấn đề là, việc sửa một lỗi trạng thái trên một chuỗi khối đã triển khai không hề đơn giản. Nó đòi hỏi một hành động đặc quyền, một cuộc gọi đến một hàm chỉ có thể được thực thi bởi một nhóm nhỏ người được tin tưởng. Arbitrum có Hội đồng An ninh, một nhóm các bên đáng tin cậy được trao quyền thực hiện các hành động khẩn cấp. Và giờ, họ cũng đang thực hiện các hành động không khẩn cấp.
Điểm mù ở đây không phải là lỗi sai số 51 triệu đô la. Điểm mù là sự tồn tại của quyền lực đó. Hầu hết các nhà phân tích bảo mật sẽ chỉ xem xét code của hợp đồng ArbVote. Họ sẽ kiểm tra xem liệu có lỗ hổng reentrancy, delegatecall injection hay overflow không. Họ sẽ tìm kiếm các vector tấn công từ bên ngoài. Nhưng họ sẽ bỏ qua mối đe dọa từ bên trong: một nhóm người, dù có thiện chí đến đâu, có thể thay đổi trạng thái của hợp đồng. Arbitrum gọi đây là một "bản ghi kế toán". Tôi gọi nó là một mở rộng bề mặt tấn công ưu tiên. Hãy tưởng tượng nếu đó không phải là một lỗi tính toán mà là một lỗi cho phép kẻ tấn công, thông qua một cuộc tấn công xã hội hoặc khai thác đa chữ ký, có được quyền đó. Khi đó, 51 triệu ARB chỉ là một thử nghiệm. Một cuộc tấn công thực sự có thể tái tạo lại toàn bộ sổ cái, thay đổi số dư, hoặc thậm chí phá hủy hợp đồng. Đây không phải là chuyện hoang đường. Đây là vụ hack Wormhole, vụ hack Ronin. Luôn luôn là một nhóm người có quyền lực cao bị xâm phạm.
Hành trình của tôi với tư cách là một kiểm toán viên an ninh bắt đầu với việc xem xét mã nguồn Bancor. Tôi phát hiện ra rằng các lỗ hổng thường nằm ở những gì không được viết ra, ở các giả định. Với Arbitrum, giả định là "Hội đồng An ninh sẽ không bao giờ làm điều sai trái". Giả định đó có thể đúng 99,99% thời gian. Nhưng trong thế giới của DeFi, 0,01% là đủ để gây ra một thảm họa. Uniswap V2, với thiết kế AMM thuần túy phi tập trung, không có cơ chế như vậy. Đó là lý do tại sao nó an toàn hơn, mặc dù kém linh hoạt hơn. Arbitrum đang giao dịch sự linh hoạt để lấy một rủi ro ưu tiên.
Tôi không nói rằng Arbitrum là một dự án tồi. Ngược lại, nó là một trong những Layer 2 tiên tiến và có trách nhiệm nhất. Việc họ công khai thừa nhận lỗi và thực hiện một quy trình minh bạch (với 14 ngày chờ đợi) là một dấu hiệu của sự trưởng thành về quản trị. Nhưng chúng ta không nên nhầm lẫn sự minh bạch với sự an toàn. Bài học thực sự ở đây là về kiến trúc quản trị. Nếu bạn đang xây dựng một giao thức, hãy tự hỏi: bạn có đang trao quá nhiều quyền lực cho một nhóm nhỏ không? Các điều kiện để thực hiện một "hành động không khẩn cấp" có đủ chặt chẽ không? Liệu có một cơ chế để thu hồi quyền lực đó không?
Khi tôi kiểm toán các cầu nối cross-chain, điều đầu tiên tôi nhìn vào là cơ chế chữ ký. Ai có thể ký? Có bao nhiêu chữ ký là đủ? Arbitrum đã áp dụng cùng một logic cho các hợp đồng quản trị của mình. Điều này có nghĩa là bảo mật của DAO Arbitrum hiện phụ thuộc vào bảo mật của các khóa riêng tư của ủy ban an ninh. Nếu bạn theo dõi các cuộc tấn công mạng trong Web3, bạn sẽ biết rằng các khóa riêng tư là điểm yếu nhất. Chúng ta đã thấy điều đó với sàn giao dịch FTX, với cầu nối Wormhole. Đây không phải là một lỗ hổng kỹ thuật; nó là một lỗ hổng trong mô hình tin cậy.
Kết luận cuối cùng của tôi là thế này: sự kiện 51 triệu ARB không phải là một bản vá lỗi thông thường; nó là một bản phác thảo cho các cuộc tấn công trong tương lai. Nó chứng minh rằng một nhóm nhỏ người có thể thay đổi các biến trạng thái cốt lõi của một DAO. Nó tạo ra một tiền lệ nguy hiểm. Vào lúc 3 giờ sáng, khi một hacker đã vượt qua được 3 trong số 5 chữ ký của ủy ban an ninh, chúng ta sẽ không còn nói về một lỗi kế toán nữa. Chúng ta sẽ nói về một vụ cướp có tổ chức. Bạn đã sẵn sàng cho điều đó hay bạn vẫn đang tin rằng 'không phải hack' sẽ mãi mãi là 'không phải hack'?