#termmax @TermMax 90000u, là số tiền mà tôi dám đưa vào sau khi đọc xong báo cáo kiểm toán của TermMax—trước khi hành động, tôi đã mất hai tuần lật lại toàn bộ hồ sơ kiểm toán công khai của Spearbit và Cantina.
Trước hết là kết luận: hai báo cáo kiểm toán là xác thực, điều này tốt hơn so với phần lớn dự án. Tôi tìm thấy các bản ghi tương ứng trên trang web của các tổ chức kiểm toán và cả trong tài liệu của TermMax. Trong báo cáo, việc phân loại mức độ lỗ hổng rất rõ ràng: các vấn đề mức độ cao và trung bình tập trung ở các phiên bản ban đầu, chủ yếu liên quan đến logic thanh lý tài sản thế chấp và điều kiện biên trong cách tính giá FT—những lỗi kiểu này là chuyện thường gặp trong các giao thức cho vay. Điểm quan trọng nằm ở tình trạng khắc phục: tôi đối chiếu với các phiên bản sau, các lỗi được đánh dấu đều có tương ứng với bản ghi sửa chữa; không hề thấy dấu hiệu kiểu “kiểm toán xong rồi chẳng ai quan tâm nữa”.
Nhưng quá trình đọc báo cáo cũng giúp tôi hiểu ba điều. Thứ nhất, kiểm toán là một bản chụp nhanh chứ không phải bảo hiểm: báo cáo bao phủ một commit cụ thể, sau đó hợp đồng trên chuỗi đã nâng cấp vài lần, và lần tái cấu trúc V2 là một thay đổi lớn—phần mã được thêm sau không chắc đã nằm trong phạm vi báo cáo. Thứ hai, kiểm toán không bao phủ chính thiết kế giao thức: cấu trúc gồm FT + XT + GT, các tham số của MLTV, quyền hạn của Curator—đây là lựa chọn thiết kế, không phải lỗ hổng mã, nên các kiểm toán viên thường không “động” tới. Thứ ba, điều thực tế nhất: báo cáo kiểm toán không có mối liên hệ tất yếu với tổn thất thực sự của người dùng; thứ quyết định rủi ro là phản ứng của đội ngũ nhanh đến mức nào khi có sự cố.
Vì vậy, 90000u không phải “vì kiểm toán thông qua nên tôi dám ném vào”, mà là “kiểm toán thông qua + có lịch sử lặp lại/iterative bổ sung + đội ngũ có lịch sử khắc phục sửa lỗi”—ba điều kiện cùng thỏa mãn thì tôi mới dám. Kiểm toán giống như giấy khám sức khỏe: nó chứng minh bạn đã từng khỏe trong quá khứ, chứ không thể đảm bảo tương lai không phát bệnh—điều tôi có thể làm là kiểm tra lại định kỳ.
@TermMax #termmax
Trước hết là kết luận: hai báo cáo kiểm toán là xác thực, điều này tốt hơn so với phần lớn dự án. Tôi tìm thấy các bản ghi tương ứng trên trang web của các tổ chức kiểm toán và cả trong tài liệu của TermMax. Trong báo cáo, việc phân loại mức độ lỗ hổng rất rõ ràng: các vấn đề mức độ cao và trung bình tập trung ở các phiên bản ban đầu, chủ yếu liên quan đến logic thanh lý tài sản thế chấp và điều kiện biên trong cách tính giá FT—những lỗi kiểu này là chuyện thường gặp trong các giao thức cho vay. Điểm quan trọng nằm ở tình trạng khắc phục: tôi đối chiếu với các phiên bản sau, các lỗi được đánh dấu đều có tương ứng với bản ghi sửa chữa; không hề thấy dấu hiệu kiểu “kiểm toán xong rồi chẳng ai quan tâm nữa”.
Nhưng quá trình đọc báo cáo cũng giúp tôi hiểu ba điều. Thứ nhất, kiểm toán là một bản chụp nhanh chứ không phải bảo hiểm: báo cáo bao phủ một commit cụ thể, sau đó hợp đồng trên chuỗi đã nâng cấp vài lần, và lần tái cấu trúc V2 là một thay đổi lớn—phần mã được thêm sau không chắc đã nằm trong phạm vi báo cáo. Thứ hai, kiểm toán không bao phủ chính thiết kế giao thức: cấu trúc gồm FT + XT + GT, các tham số của MLTV, quyền hạn của Curator—đây là lựa chọn thiết kế, không phải lỗ hổng mã, nên các kiểm toán viên thường không “động” tới. Thứ ba, điều thực tế nhất: báo cáo kiểm toán không có mối liên hệ tất yếu với tổn thất thực sự của người dùng; thứ quyết định rủi ro là phản ứng của đội ngũ nhanh đến mức nào khi có sự cố.
Vì vậy, 90000u không phải “vì kiểm toán thông qua nên tôi dám ném vào”, mà là “kiểm toán thông qua + có lịch sử lặp lại/iterative bổ sung + đội ngũ có lịch sử khắc phục sửa lỗi”—ba điều kiện cùng thỏa mãn thì tôi mới dám. Kiểm toán giống như giấy khám sức khỏe: nó chứng minh bạn đã từng khỏe trong quá khứ, chứ không thể đảm bảo tương lai không phát bệnh—điều tôi có thể làm là kiểm tra lại định kỳ.
@TermMax #termmax