Tình Trạng Đáng Buồn của Kiểm Toán Web3, Và Những Gì Có Thể Được Thực Hiện

Balancer, một giao thức lâu đời và được kiểm toán kỹ lưỡng, gần đây đã bị "hack". Yearn Finance cũng được kiểm toán tương tự cũng vậy. Nhiều năm trước, Euler Finance đã bị "hack" thông qua một chức năng được giới thiệu để phản hồi một cuộc kiểm toán trước đó. USPD đã được kiểm toán trước khi triển khai và sau đó chính quy trình triển khai chưa được kiểm toán đã bị hack dẫn đến mất toàn bộ trong vòng khoảng 3 tháng sau khi ra mắt. Không ai theo dõi tin rằng kiểm toán là sự đảm bảo về tính bảo mật. Nhiều người đặt câu hỏi liệu chúng có đáng giá gì không.

Điều này không mới. Đây không phải là vấn đề của web3. Và thực sự, đây không phải là một nhận xét đặc biệt sâu sắc. Nhưng kiểm toán vẫn là một điều rất quan trọng. Các dự án trả tiền cho kiểm toán. Các dự án quảng bá kiểm toán. Mọi người giả vờ đọc kiểm toán. Thường thì khi một sản phẩm đã được kiểm toán bị khai thác, mọi người hỏi tại sao và làm thế nào điều đó xảy ra.

Thay vì trả lời trực tiếp bất kỳ điều gì trong số đó, chúng tôi sẽ xem xét một số cuộc kiểm toán gần đây cho các sản phẩm mới ra mắt. Mục tiêu ở đây không phải là chế giễu hoặc ch비판bất kỳ ai. Những cái này được chọn ngẫu nhiên, chủ yếu là do tập trung vào những thứ gần đây. Điều đó không có nghĩa là chúng đặc biệt tồi. Chúng thậm chí không tệ đến thế!

Quan điểm của chúng tôi ở đây không phải là các kiểm toán viên đang làm điều gì sai. Các kiểm toán viên đang làm những gì các dự án thuê họ yêu cầu. Phạm vi kiểm toán được dự án thiết lập. Chỉ là một ví dụ cực đoan: nếu Do Kwon đã thuê kiểm toán viên cho kế hoạch stablecoin của mình, họ sẽ lưu ý rằng nó có khả năng không ổn định. Vấn đề sẽ được đánh dấu "đã xác nhận" và không có gì được thực hiện hoặc khác biệt.

Vấn đề này hoàn toàn không liên quan gì đến các nghiên cứu như những nghiên cứu cho rằng hệ sinh thái Terra-LUNA của Do rất mạnh mẽ. Thật khó để dự đoán tương lai và những loại nghiên cứu đó đúng là được xem như marketing tự phục vụ, trong giới hạn, thừa nhận các vấn đề cốt lõi. Nghiên cứu do dự án tài trợ được kỳ vọng vẽ mọi thứ theo hướng tích cực. Toàn bộ mục đích của kiểm toán là cung cấp quan điểm khách quan của bên thứ ba. Không nên tin tưởng vào sự phóng đại và kiểm toán không phải là đảm bảo hay bảo hiểm. Đó là cuộc sống.

Điểm của cuộc khảo sát này là nhấn mạnh rằng vấn đề thực sự ở đây không phải là các lỗi lập trình cơ bản thuộc loại mà kiểm toán viên có điều kiện tốt để xác định và quy trình kiểm toán được thiết kế tốt để giải quyết. Các kiểm toán viên khá giỏi trong việc phát hiện những thứ đó. Trên thực tế, các lập trình viên xây dựng những thứ này ngay từ đầu cũng vậy. Theo kinh nghiệm, loại phản hồi này đến đúng người và các vấn đề hẹp được khắc phục.

Không, vấn đề thực sự là các sản phẩm hoạt động chính xác như dự định và nơi một "rủi ro" đã biết hiện thực hóa để phá hủy mọi thứ. Những gì bạn sẽ thấy bây giờ là các kiểm toán viên cố gắng bảo vệ bản thân khỏi mọi vấn đề đã biết-chưa biết trong tương lai. Như một bài tập bảo vệ khỏi trách nhiệm pháp lý và chế giễu, có lẽ đây là điều có giá trị. Nhưng theo nghĩa chung, nó không giúp ích gì cho ai cả.

Và sau đó ở cuối, chúng tôi sẽ thảo luận về những gì một loạt các bên có thể làm để vừa giúp đỡ vừa phục vụ lợi ích riêng hẹp của họ. Nếu đơn thuốc của bạn về cách cải thiện kiểm toán liên quan đến lòng vị tha thì, chà, nó không hữu ích lắm.

Jovay

Jovay là một L2 liên quan đến Ant Financial hoặc Alibaba hoặc một cái gì đó trong khu vực chung đó. Nhưng không thực sự quan trọng Jovay làm gì. Đó là một thứ được xây dựng bằng phần mềm từ một tổ chức lớn và được tài trợ tốt. Cuộc kiểm toán này liệt kê tám vấn đề:

1. Một lỗi lập trình hợp pháp sau đó đã được khắc phục.
2. Giao thức không đáng tin cậy. Đây là một vấn đề nhưng nó cũng là một phần cốt lõi của thiết kế.
3. Cuộc tấn công "nạp tiền giả" áp dụng cho một phần rộng lớn của hệ sinh thái và không cụ thể cho dự án.
4. Các máy chủ RPC sử dụng HTTP thay vì HTTPS. Các giao diện này không xử lý thông tin bí mật. Điều này áp dụng cho hàng tỷ trang web chỉ đọc hoàn toàn an toàn.
5. Máy tính lượng tử gây ra rủi ro cho Ethereum. OK. Rất đúng chủ đề.
6. Hợp đồng thông minh EVM có thể dễ bị tổn thương. Không đùa đâu. Nó nói "Hợp đồng thông minh Evm dễ bị các vectơ tấn công khác nhau do triển khai mã bất biến và tương tác phức tạp, có khả năng dẫn đến trộm cắp tiền,.." OK. Một lần nữa thực sự tôn trọng trọng tâm hẹp của cuộc kiểm toán này.
7. Thiết kế sequencer chịu ảnh hưởng của MEV. Giống như toàn bộ phần còn lại của hệ sinh thái Ethereum. Trời cũng quá tối vào ban đêm.
8. Chất lượng mã có thể được cải thiện. Không giống như hầu hết các mã khác được viết kể từ buổi bình minh của máy tính.

Chỉ có một trong số này là vấn đề thực sự. Có, đáng chú ý là chính sản phẩm không đáng tin cậy nếu tài liệu nói khác rằng nó đáng tin cậy. Nhưng sản phẩm này khá ổn về mặt đó. Lưu ý rằng máy tính lượng tử có khả năng gây ra rủi ro trong tương lai và hợp đồng thông minh có thể có rủi ro...đó là nỗ lực làm cho báo cáo dài hơn bằng cách tìm ra các vấn đề bịa đặt hoặc chúng là nỗ lực cung cấp một loại "đó không phải lỗi của chúng tôi" nếu cuối cùng có cái gì đó bị hack. Có lẽ là sự kết hợp của cả hai.

Theo tinh thần của những điểm đó, chúng tôi đề xuất vấn đề thứ chín là mạng sẽ ngừng hoạt động khi mặt trời chết trừ khi chúng ta trở thành một loài liên sao và bằng cách nào đó tìm ra thông tin liên lạc nhanh hơn ánh sáng. Nếu không, thuyết tương đối giới hạn tuổi thọ hữu ích của hệ thống này khoảng 5 tỷ năm. Thành thật mà nói điều đó hữu ích hơn việc nói rằng chất lượng mã có thể được cải thiện bởi vì ngay cả sau khi Mặt trời chết vẫn sẽ có mã xấu đang thực thi ở đâu đó. Nhưng chúng tôi đùa thôi.

Hyperliquid

Hyperliquid đã công bố một số báo cáo kiểm toán. Báo cáo kiểm toán đầu tiên tìm thấy sáu vấn đề và báo cáo thứ hai xác nhận những vấn đề đó đã được giải quyết. Nhưng phạm vi kiểm toán đã loại trừ:

1. Các hợp đồng thông minh khác là một phần của hệ thống Hyperliquid
2. Các thành phần ngoài chuỗi, chẳng hạn như validators
3. Các thành phần Front-end
4. Cơ sở hạ tầng liên quan đến dự án
5. Lưu trữ khóa

Những thứ đó có vẻ như là các khu vực vấn đề tiềm ẩn! Tất cả những gì được kiểm toán chỉ là một hợp đồng bridge duy nhất. Nhưng hệ thống, à, nó phức tạp hơn nhiều so với điều đó.

Kiểm toán một góc nhỏ của hệ thống chỉ làm một vài thứ được xác định chặt chẽ khá vô dụng. Cách Hyperliquid được thiết kế, hợp đồng được kiểm toán là điểm vào và ra bên ngoài cho mọi người. Vì vậy, sẽ là một vấn đề nghiêm trọng nếu hợp đồng đó đầy rẫy lỗi. Nhưng việc xác nhận hợp đồng hoạt động mang lại rất ít sự thoải mái.

Ondo

Cuộc kiểm toán này nhấn mạnh "RỦI RO TẬP TRUNG CHO CÁC THỰC THỂ VÀ VAI TRÒ ĐÁNG TIN CẬY" mà nhóm đã xác nhận. Nó được viết hoa như thế trong báo cáo. Đúng vậy.

Cuộc kiểm toán này lưu ý rằng hệ thống có thể sụp đổ nếu một stablecoin liên quan depeg quá mạnh. Họ diễn đạt điều đó như hệ thống "sẽ cho phép đúc token OUSG quá mức trong sự kiện depeg USDC". Cuối cùng "giải pháp" họ đưa vào là tham chiếu đến oracle Chainlink và một công tắc tắt trong trường hợp giá được báo cáo quá thấp. Vì vậy, thay vì nổ tung với giá trị sụp đổ, giao thức sẽ dừng lại với giá trị sụp đổ. Đúng vậy. Đây không phải là một vấn đề có thể giải quyết được vì không có cơ chế nào để tránh kết quả mất giá trị nếu USDC nổ tung. Và, phù hợp với sự thật đó, giải pháp không thực sự khắc phục bất cứ điều gì.

Những cuộc kiểm toán đó tương đối gần đây. Nhưng để đưa ra một số bối cảnh, cuộc kiểm toán này từ tháng 10 năm 2022 xác định rất nhiều vấn đề thực sự. Gần 200 trong số chúng. Hầu hết đã được khắc phục, một số tương tự như trên và chỉ được xác nhận. Vấn đề là kiểm toán từng làm điều gì đó cụ thể và có nội dung: tìm kiếm các lỗi lập trình không thể là ý định của lập trình viên. Các lập trình viên đã sửa những lỗi này bởi vì chúng, bạn biết đấy, là những sai lầm thực sự không chỉ là quyết định thiết kế đáng ngờ được tích hợp vào sản phẩm.

Và sau đó đến năm 2024, chúng ta thấy các cuộc kiểm toán tìm thấy tương đối ít vấn đề kỹ thuật và tuyên bố nằm ngoài phạm vi các cuộc tấn công liên quan đến tài chính. Cách duy nhất hợp lý để giải thích sự thay đổi này theo thời gian là các lập trình viên, và lập trình viên với tư cách là kiểm toán viên, nhận ra rằng mã hoạt động không phải là rủi ro duy nhất. Chắc chắn các lỗi lập trình đã bị khai thác theo thời gian. Nhưng đến giữa năm 2024, mọi người đều có thể thấy rằng các cơ chế kinh tế bị lỗi cũng là một rủi ro lớn. Chúng là rủi ro lớn nhất.

Các dự án hoạt động chính xác như dự định – không phải như trong mơ, như dự định trong thực tế – nổ tung theo thời gian bởi vì giấc mơ ổn định của các nhà thiết kế vỡ vụn khi đối mặt với thế giới thực.

Bạn có thể thấy sự tiến hóa này trong các cuộc kiểm toán của một dự án này.

Mutuum Finance

Bây giờ chúng ta có sự giảm thiểu vô lý của kiểm toán. Cái này xác định một vấn đề duy nhất:

Vấn đề là thiếu minh bạch xung quanh phân phối token ban đầu và điều đó có thể liên quan đến các vấn đề tập trung như thế nào. Nó đã được "giảm thiểu" bởi vì:

Sau đó có rất nhiều chi tiết về multisig. Và cuối cùng là phản hồi của kiểm toán viên:

Vì vậy, rủi ro với dự án là một nhóm nhỏ kiểm soát mọi thứ và cách thức mà sự kiểm soát đó sẽ, hoặc có thể sẽ không, được phân tán hoàn toàn không minh bạch. Và giải pháp được nhóm đề xuất là viết một bài đăng blog để làm rõ ý định của họ không, theo bất kỳ nghĩa chặt chẽ nào, khắc phục điều này.

Để ghi lại, nhóm đã công bố một danh sách chi tiết về những token sẽ đi đâu khi nào. Và họ thừa nhận điều này chưa hoàn chỉnh với các bình luận như "Chúng tôi đang xem xét một mô hình phân phối theo block hoặc hàng tuần". Họ cũng thừa nhận mọi thứ sẽ được quản lý bằng multisig thủ công. Vì vậy, họ đang trung thực. Chỉ là sự trung thực tương đương với "vâng, chúng tôi vẫn có thể làm bất cứ điều gì chúng tôi muốn và bạn phải tin tưởng chúng tôi".

Mục đích của cuộc kiểm toán này là gì? Nếu mã không có lỗi có thể xác định được, kiểm toán viên chỉ có thể viết điều đó. Đôi khi một chuyến đi đến bác sĩ hoặc thợ máy tạo ra một hóa đơn sức khỏe sạch. Vì vậy, chúng tôi tự hỏi liệu chỉ có một lượng mã không đáng kể được kiểm toán? Hoặc có thể chính dự án chỉ là một lượng mã không đáng kể? Liệu kiểm toán viên có cảm thấy cần phải đưa cái gì đó vào báo cáo vì nếu không nó quá trống rỗng? Tại sao ai đó lại bận tâm với tất cả những điều này?

Một lần nữa, chúng tôi không thực sự đổ lỗi cho các kiểm toán viên ở đây. Trong phạm vi bất kỳ ai đang làm điều gì sai ở đây, gần như chắc chắn đó là vấn đề về động cơ với người đã ủy thác cuộc kiểm toán. Và thực tế là họ đang chi tiêu tiền của nhà đầu tư để tạo ra một tài liệu chủ yếu vô dụng cho mục đích marketing. Đó không phải là việc của kiểm toán viên!

Cải tiến

Đó là một điều tốt không mơ hồ rằng nhiều lỗi hơn được phát hiện, ít mã bị hỏng hơn được phát hành cho sản xuất và nhiều bản sửa lỗi được đề xuất hơn được triển khai. Và chúng tôi không đủ chưa trưởng thành để gợi ý rằng vấn đề là người dùng và nhà đầu tư quan tâm đến những thứ sai lầm như, ví dụ, đặt giá trị và tin tưởng vào các cuộc kiểm toán không có nghĩa nhiều. Mọi người quan tâm đến những gì họ quan tâm và cố gắng thay đổi điều đó là một nhiệm vụ ngu ngốc.

Nhưng có một vài cải tiến thực sự mà chúng tôi có thể đề xuất. Ethena đã dẫn đầu bằng cách giải thích một số chế độ thất bại của sản phẩm của họ ngay từ đầu. Nhóm đã nhất quán với thông điệp rằng USDe không phải là không có rủi ro. Và họ đã phác thảo các cách nó có thể gặp rắc rối. Sản phẩm đã tồn tại, với một vài vấn đề, và khá lớn ngày nay. Điều này cho chúng ta một điểm hành động cho các nhà đầu tư: nhấn mạnh các dự án trung thực về bất kỳ "cuộc tấn công liên quan đến tài chính" nào có thể tồn tại.

Ethena cho thấy rằng trung thực không làm hỏng dự án! Bạn có thể lập luận rằng bằng cách trung thực hơn, dự án đã thu hút nhiều quan tâm hơn. Sự trung thực cũng có phần thưởng bổ sung là cung cấp nhiều bảo vệ pháp lý hơn nếu có gì đó xảy ra. Các dự án nên muốn làm điều này rồi.

Các kiểm toán viên cũng có thể sắp xếp lại cách họ thực hiện phân tích để làm cho công việc của họ hữu ích hơn. Hoặc ít nhất là ít vô dụng hơn và có khả năng gây hiểu lầm. Không đặt các vấn đề về động cơ kinh tế hoặc mối quan tâm chung như an toàn lượng tử trong cùng một phần với lỗi. Hiện tại, chúng thường được dán nhãn theo cách phân biệt nhẹ chúng với các lỗi mã hóa. Hoặc chúng được liệt kê là "thông tin" trái ngược với "nghiêm trọng".

Nhưng điều này bỏ lỡ điểm chính. An toàn lượng tử có thể là một rủi ro "nghiêm trọng" cho một hệ thống – nhưng nó có bản chất hoàn toàn khác với kiểm tra chữ ký xấu hoặc dấu trừ sai! Đặt những thứ này trong các phần riêng biệt. Tương tự "kế hoạch stablecoin này không ổn định trong các điều kiện có khả năng hợp lý" không giống như một lỗi logic trong mã. Làm rõ sự nhầm lẫn này sẽ cải thiện vẻ ngoài của các tài liệu kiểm toán và đánh bóng danh tiếng của kiểm toán viên.

Cuối cùng, các sàn giao dịch có thể giúp đỡ điều này. Các sàn giao dịch lớn bị chỉ trích nhiều vì niêm yết các dự án tồi tệ, hoặc các memecoin rủi ro dao động dữ dội khiến mọi người mất tiền, hoặc tất cả các quyết định kinh doanh kỳ lạ gây mất mát khác. Điều gì sẽ xảy ra nếu các sàn giao dịch nhấn mạnh các cuộc kiểm toán hợp lý bao gồm sự ổn định kinh tế một cách trung thực và không nhầm lẫn các rủi ro như "hợp đồng thông minh có thể dễ bị tổn thương" với các kiểm tra logic thực sự?

Một cách để giải thích việc kiểm toán viên đệm kết quả của họ với loại chất độn này là không ai sẽ coi trọng kết quả kiểm toán trống. Đủ công bằng rằng một tài liệu như vậy sẽ gây ra câu hỏi. Nhưng nếu một sàn giao dịch lớn niêm yết một token với, giả sử, hai kết quả kiểm toán "trống" phù hợp không bao gồm vấn đề cụ thể của dự án và có lập trường rằng đây là một điều tốt...điều đó có thể giúp di chuyển bóng xuống sân một chút. Chúng ta cũng đang ở một thời điểm trong chu kỳ mà việc trở thành một sàn giao dịch "trung thực" và "hợp lý" hơn sẽ giúp bạn có nhiều khách hàng hơn so với việc thiếu marketing lên trăng vô lý khiến bạn mất.

Tương tự, không nên có kỳ thị gắn liền với việc kiểm toán một dự án và nói rằng nó trông ổn. Cái này là của các kiểm toán viên. Có lẽ một loạt kiểm toán viên có thể đưa ra một số tuyên bố chung trong lĩnh vực này. Có, chúng tôi có thể hiểu rằng các kiểm toán viên sẽ muốn đưa vào các cảnh báo cho các vấn đề tiềm ẩn đã bị loại khỏi phạm vi khi sự tham gia bắt đầu. Cũng đủ công bằng. Nhưng đệm kết quả với các vấn đề tiềm ẩn chung vô nghĩa không phải là câu trả lời. Cũng không phải là nói rằng nhóm đã giảm thiểu rủi ro tập trung bằng cách tạo một bài đăng blog về phân phối token mà họ dự định sắp xếp thủ công, sớm, theo một lịch trình vẫn chưa được xác định.

Kiểm toán có thể hữu ích. Kiểm toán có thể giúp đỡ. Và sự thật là kiểm toán web3 đã phát hiện các vấn đề thực sự và, trong một khoảng thời gian đáng kể, được đóng gói với nội dung hữu ích và thú vị. Nhưng các kỹ sư đã cải thiện theo thời gian bởi vì họ, bạn biết đấy, là kỹ sư và đó là những gì họ làm. Các kiểm toán viên cần theo kịp và, để mượn một từ, đổi mới một chút. Và nhiều phần lớn hơn của hệ sinh thái, như các sàn giao dịch, cũng có thể giúp thúc đẩy điều này.