Trong 7 ngày qua, một giao thức Layer-2 đã mất 40% TVL khi một trong những core developer chính thức "thăm" — theo nghĩa đen — kho lưu trữ mã nguồn của dự án trên GitHub. Không có commit mới, không có pull request, không có announcement. Chỉ có một dấu vết: một commit duy nhất với message "test cleanup" từ một tài khoản GitHub không liên quan trực tiếp, nhưng IP của session lại trùng với IP của node RPC mà developer đó sử dụng để chạy thực nghiệm trong 3 tháng qua. Tôi đã phát hiện điều này khi chạy phân tích logs của một số node archive. Đây là trường hợp hiếm có: một developer "ghé thăm" codebase của chính mình, và thị trường phản ứng như thể đó là một vụ tấn công.
Context ở đây là gì? Giao thức này là một optimistic rollup, chạy trên Ethereum, với token governance đang giao dịch ở mức $0.14, giảm 60% so với đỉnh năm 2023. Codebase của nó là một fork của Optimism Bedrock, với một số tùy chỉnh về cơ chế challenge period và sequencer selection. Trong 6 tháng qua, dự án đã có 3 lần thay đổi governance, 2 lần thay đổi về sequencer set, và một lần bị phát hiện lỗ hổng trong logic finality vào tháng 12/2024 — lỗ hổng mà tôi đã phân tích trong một bài viết trước.
Nhưng điều thú vị là gì? Việc developer "thăm" codebase không phải là bất thường. Tôi đã làm điều đó hàng trăm lần. Bất thường là khi tài khoản GitHub không chính thức — dù có thể là do developer tạo ra để tránh bị theo dõi — lại được sử dụng để truy cập vào một repository có write access. Trong cộng đồng blockchain, một commit từ tài khoản lạ vào codebase của một dự án lớn thường được coi là dấu hiệu của một vụ tấn công supply chain. Nhưng ở đây, không có mã độc. Không có thay đổi trong logic. Chỉ có một file test bị xóa.
Tôi đã dành 3 giờ để clone repository, checkout commit trước và sau, và chạy diff. Kết quả: file test bị xóa là một test về "finalization fork choice" — một trong những cơ chế quan trọng nhất của rollup. Tôi đã xem lại lịch sử commit của file đó. Nó được tạo ra vào tháng 8/2024, bởi chính developer đó, nhưng chưa bao giờ được merge vào nhánh chính. Nó tồn tại trong một nhánh riêng, và commit "cleanup" đó đã xóa nó khỏi nhánh đó. Tại sao một developer lại xóa test của chính mình, trong một nhánh riêng, bằng tài khoản không chính thức, vào thời điểm dự án đang mất TVL nhanh nhất?
Core insight ở đây nằm ở timing và context. Tôi đã theo dõi on-chain data của giao thức này trong 30 ngày qua. TVL giảm 40% không phải do một lý do duy nhất. Có 3 yếu tố: (1) Một vụ exploit nhỏ ở một DEX trên chain — $200k — nhưng đủ để gây hoảng loạn, (2) Một đề xuất governance tăng sequencer fee, bị từ chối, nhưng cho thấy nội bộ đang bất đồng, (3) Một lỗi trong logic của proposer contracts — được phát hiện bởi một whitehat — cho phép kẻ tấn công giả mạo một block finalization mà không cần bằng chứng fraud. Lỗi này đã được fix bằng một upgrade vào ngày thứ 3, nhưng hậu quả là 4.5 ETH bị mất.
Vậy, việc developer xóa test có liên quan gì? Tôi cho rằng developer đang âm thầm "làm sạch" bằng chứng về những lỗi chưa được công khai. Lỗi về finalization fork choice mà test đó kiểm tra có thể là một lỗi nghiêm trọng hơn lỗi đã được fix. Tôi đã thử nghiệm bằng cách build lại môi trường test với codebase trước khi xóa. Tái hiện test thất bại. Điều đó có nghĩa là: tồn tại một lỗ hổng chưa được vá trong logic lựa chọn fork của giao thức này — một lỗ hổng có thể cho phép kẻ tấn công tạo ra một block "gian lận" mà không bị phát hiện trong vòng 7 ngày chờ đợi của challenge period.
Thị trường đã phản ứng quá mức? Có lẽ. Nhưng không có gì thay thế được việc đọc từng dòng một. Tôi đã làm điều đó. Và tôi thấy một pattern: developer này đã từng làm điều tương tự vào tháng 6/2024, khi dự án bị tấn công bởi một vụ reentrancy. Khi đó, anh ta đã xóa một test về phí gas trước khi lỗi được phát hiện. Coincidence? Tôi không tin. Tôi đã dành 2 tháng để audit một dự án vào năm 2022, nơi một dev đã cố tình xóa test để che giấu lỗi trước khi bỏ việc. Kết quả: 12 triệu USD bị mất.
Contrarian angle ở đây là: Việc TVL giảm 40% không phải là tín hiệu của sự sụp đổ, mà là tín hiệu của một cơ hội arbitrage. Nếu lỗ hổng tồn tại, nhưng chưa bị khai thác, thì những người hiểu rõ cơ chế có thể tận dụng để farm token với mức phí rẻ hơn trước khi fix. Nhưng rủi ro là cực kỳ cao. Tôi đã thấy cảnh tượng này rồi: một dự án có lỗ hổng nghiêm trọng, developer cố gắng che giấu, cộng đồng hoảng loạn, TVL giảm, và rồi một kẻ tấn công thông minh đã khai thác nó vào đúng thời điểm challenge period kết thúc.
Takeaway cho người đọc: Nếu bạn thấy một developer "thăm" codebase của chính mình bằng tài khoản lạ, đừng theo dõi TVL. Hãy theo dõi git commit history và thử nghiệm tái hiện test. Tôi đã làm điều đó trong 3 giờ qua. Và tôi có một câu hỏi cho bạn: Khi nào thì một "test cleanup" trở thành một vụ tấn công phủ đầu? Khi người xóa nó là người duy nhất hiểu được lỗi. Và khi lỗi đó có thể khiến giao thức mất 40% — không phải TVL, mà là toàn bộ số tiền trong bridge.