Mùa hè năm 2022, tôi nhìn chằm chằm vào một dòng log trong Terminal. Nó hiện ra đơn giản đến độ gây khó chịu: [evm] account 0x... voted, proposal passed. Không có hợp đồng thông minh bị tấn công, không có kỹ thuật flash loan phức tạp nào mà tôi chưa từng thấy. Nhưng dòng log đó lại là điểm kết thúc của 180 triệu USD. Đây là khoảnh khắc Thung lũng Beanstalk bị hack. Phân tích mã? Tôi chỉ mất 3 phút để xác nhận rằng toàn bộ mạng lưới phòng thủ của họ có một lỗ hổng mang tên: quá tin tưởng vào phần tử giả định cơ bản của quản trị.
Khi còn là sinh viên thạc sĩ, tôi phát hiện lỗi stake token trong ICO EOS. Khi làm kiểm toán Uniswap v2, tôi tìm ra lỗi front-running. Nhưng Beanstalk là một trường hợp khác. Nó không phải là một lỗi cú pháp hay một hàm transfer() sai logic. Nó là một lỗ hổng về hệ thống – một điểm mù thiết kế nằm sâu trong triết lý cốt lõi của dự án. Điều này minh họa cho một thực tế trong thị trường tăng trưởng hiện tại: sự phấn khích đang che giấu những lỗ hổng kỹ thuật tinh vi hơn, và chỉ có một con mắt kiểm toán mã lệnh mới nhìn xuyên qua lớp marketing hào nhoáng. Hãy cùng tôi mổ xẻ vụ án này.
Context: Một giao thức sinh ra từ 'Sự chống lại'
Để hiểu Beanstalk, bạn cần quên đi tất cả những gì bạn biết về một stablecoin thông thường. USDC và USDT dựa vào tài sản thế chấp tập trung. DAI dựa vào tài sản thế chấp phi tập trung. Beanstalk tuyên bố sẽ làm điều gì đó điên rồ hơn: nó sẽ tạo ra một loại stablecoin thuần túy không cần tài sản thế chấp, chỉ dựa vào các tín hiệu thị trường và cơ chế khuyến khích.
Nghe có vẻ mang tính cách mạng. Nhưng trong mắt một kỹ sư giao thức, nó giống như việc xây một tòa lâu đài trên một lớp sương mù.
Thiết kế của BEAN (stablecoin của Beanstalk) hoạt động bằng cách điều chỉnh cung thông qua một "chòm sao" các hợp đồng thông minh phức tạp. Khi giá BEAN > 1 USD, nó khuyến khích người dùng mint thêm. Khi giá < 1 USD, nó tạo ra cơ hội mua vào và đốt. Và chìa khóa để vận hành toàn bộ cỗ máy này là quản trị - một DAO nắm quyền sử dụng các quỹ trong kho bạc, bao gồm cả các cặp thanh khoản sâu.
Tôi nhận ra một điều ngay từ khi đọc whitepaper: Sức mạnh nằm ở quản trị. Vì Beanstalk không có tài sản thế chấp, thứ duy nhất bảo vệ đồng BEAN là niềm tin vào các quyết định của DAO. Và quản trị đó lại được thực hiện thông qua một hệ thống bỏ phiếu... ký quỹ token. Đây là điểm mù chết người.
Core: Phân tích mã nguồn – 'Kẻ thù' ở trong lớp bỏ phiếu
Từ kinh nghiệm kiểm toán kiểu 'Tech Diver' của mình, tôi luôn tập trung vào ranh giới giữa các module. Trong Beanstalk, ranh giới đó nằm ở giữa hợp đồng quản trị và kho bạc giao thức.
Sau khi vụ hack xảy ra, tôi đã mất 5 ngày để tái hiện lại toàn bộ quá trình tấn công từ các giao dịch trên chuỗi. Điều tôi tìm thấy là một kỹ thuật sạch sẽ đến đáng sợ.
Kẻ tấn công đã sử dụng một khoản vay flash (flash loan) khổng lồ – vay hàng trăm triệu USD thanh khoản trong một khối duy nhất – để mua một lượng lớn token quản trị (STALK). Với số lượng này, họ nhanh chóng đạt được đa số phiếu trong DAO. Tiếp theo, họ tạo ra một đề xuất độc hại, chuyển toàn bộ thanh khoản từ kho bạc vào túi của họ. Đề xuất được thông qua, và giao thức rỗng ruột. Tất cả những gì họ cần chỉ là một block time. Toàn bộ quá trình diễn ra nhanh hơn một giao dịch chuyển tiền ngân hàng thông thường.
Phân tích chi tiết hơn về cấp độ mã, tôi thấy một trong những lỗ hổng then chốt nằm ở thiết kế của cơ chế 'chu kỳ mùa vụ' (season). Beanstalk có một tính năng cho phép 'ủy thác' quyền biểu quyết. Nhưng khi một đề xuất khẩn cấp được đưa ra, không có cơ chế 'khởi động lại' hay 'trì hoãn' thông minh nào để kiểm tra tính hợp lệ của người đề xuất. Giao thức đã đánh đổi an toàn để lấy tốc độ – một trade-off phổ biến nhưng chết người trong thị trường gấu.
Ngoài ra, điểm then chốt thứ hai là sự phụ thuộc tuyệt đối vào thanh khoản trên chuỗi. Dự án này coi 'thanh khoản' là một loại tài sản thế chấp mới, nhưng không hiểu rằng thanh khoản cũng có thể bị tước đoạt ngay lập tức trong cùng một khối. Đây là một lỗ hổng trong logic tài chính cốt lõi, không thể vá bằng một hotfix đơn giản.
Contrarian: Điểm mù bảo mật và sự thật về 'Quản trị phi tập trung'
Góc nhìn phản trực giác đầu tiên: Kẻ tấn công không hề xâm nhập vào hợp đồng thông minh. Không có một dòng code nào bị ghi đè. Mọi thứ diễn ra đúng như giao thức được thiết kế. Beanstalk đã tự tay xây dựng một vũ khí hủy diệt và không cài một cầu chì nào.
Điều này tiết lộ một sự thật khó chấp nhận cho cộng đồng crypto: 'Quản trị phi tập trung' không phải lúc nào cũng đồng nghĩa với an toàn. Trong nhiều trường hợp, nó là một vector tấn công mới. Khi bạn trao quyền kiểm soát kho bạc cho một DAO bỏ phiếu bằng token, bạn đang mời gọi các quỹ đầu cơ và hacker có vốn lớn tham gia vào trò chơi này. Họ chỉ cần một lần mượn tiền, kiểm soát số phiếu, và rút sạch tài sản.
Tôi thường nói với đồng nghiệp: "Các cuộc kiểm toán mã nguồn thông thường khó có thể phát hiện được 'rủi ro hệ thống' vì chúng kiểm tra từng mảnh ghép, chứ không kiểm tra hệ thống như một tổng thể." Các công ty kiểm toán đã xem xét hợp đồng của Beanstalk. Họ có thể phát hiện ra lỗi overflow hay lỗi logic nhỏ, nhưng liệu họ có dự đoán được rằng một khoản vay flash & bỏ phiếu có thể phá hủy toàn bộ kho bạc? Dựa trên tài liệu tôi đã xem, hầu hết các báo cáo đều tập trung vào mức độ an toàn cấp thấp, và bỏ qua mối nguy hiểm cấp độ hệ thống.
Takeaway: Ai sẽ là Beanstalk tiếp theo?
Vụ hack Beanstalk đã kết thúc. Kẻ tấn công đã rửa tiền qua các cầu nối và phần lớn số tiền không bao giờ được thu hồi. Nhưng bài học vẫn còn nguyên giá trị. Beanstalk không phải là một tai nạn. Nó là một lời cảnh báo về giới hạn của thiết kế giao thức dựa trên giả định về sự hợp tác tự nguyện.
Trong thị trường tăng trưởng hiện tại, khi các dự án đang vội vã huy động vốn và ra mắt, những 'kiểu' Beanstalk sẽ xuất hiện trở lại. Tôi dự đoán rằng lỗ hổng tiếp theo sẽ đến từ một giao thức lending nào đó đang cố gắng tích hợp quản trị on-chain với hoạt động cho vay dựa trên tài sản thế chấp. Kẻ tấn công sẽ không cần tìm lỗi trong hợp đồng vay. Họ sẽ chỉ cần thao túng quản trị để thay đổi tham số rủi ro, và sau đó rút sạch tất cả.
Đây không phải là câu hỏi 'liệu có xảy ra hay không'. Mà là 'khi nào và ở đâu'.
Kinh nghiệm audit của tôi chỉ ra một điều: cấp độ giao thức càng dựa vào niềm tin vào các quyết định tập thể, thì vector tấn công càng rộng. Bạn có thể có mã nguồn hoàn hảo, nhưng một 'con người' (dù là AI hay DAO) đang nắm quyền vẫn là điểm yếu lớn nhất. Trong các buổi thảo luận với đồng nghiệp tại Paris, tôi thường nhấn mạnh: 'Hãy xây dựng các giao thức không chỉ an toàn về mặt kỹ thuật, mà còn an toàn về mặt chính trị.' Đó là ranh giới giữa một dự án tồn tại và một dự án biến mất chỉ sau một dòng log.