VỤ HACK RESOLV VÀ NHỮNG BÀI HỌC CHƯA ĐƯỢC RÚT RA Lần này, thiệt hại hoàn toàn là do lỗi của bản thân và hoàn toàn có thể tránh được. Vụ giao dịch trị giá 50 triệu đô la + 30 triệu đô la Mint trái phép được coi là "không được phép", nghĩa là khóa riêng tư của nó đã bị xâm phạm, theo kiểu Triều Tiên cổ điển. Loại phí bảo hiểm Kimchi sai lầm này hoàn toàn có thể được ngăn chặn. Đây không phải là do thị trường gặp trục trặc, giá cả giảm, tài sản thế chấp trở nên vô dụng. Điều này đơn giản chỉ do sự thiếu năng lực, một kiểu ngu ngốc kinh điển như tự bắn vào chân mình. Giờ đây, trong suốt 13 năm, kể từ năm 2013, khi chữ ký đa chữ ký được thêm vào Bitcoin, chúng ta đã biết cách tránh việc sử dụng khóa riêng trái phép: - Tốt nhất là không nên sử dụng khóa riêng tư ngay từ đầu, mà hãy sử dụng ví Đa chữ ký. - Sử dụng Mô-đun bảo mật phần cứng (HSM) với các biện pháp bảo vệ bổ sung cho quá trình ký kết. Nhưng tại sao Resolv lại làm vậy?? Chuyện này đâu có khó hiểu gì. NGUYÊN NHÂN GÂY RA VIỆC VI PHẠM QUYỀN HÀNH "SERVICE_ROLE là một vai trò đặc quyền trong các hợp đồng giao thức USR của Resolv (một phần của quy trình yêu cầu/hoàn thành Mint/hoán đổi hai giai đoạn). Không có tài liệu chính thức chi tiết nào từ Resolv giải thích mục đích, mô hình bảo mật, quy trình gán hoặc rủi ro của nó. Nó không được đề cập ở bất cứ đâu trong tài liệu giới thiệu công khai, tài liệu người dùng (http:/docs.resolv.xyz) hoặc README trên GitHub." (Trích dẫn của Grok) ĐÃ KIỂM TOÁN 18 LẦN Tại sao Resolv không phát hiện ra điều này dù đã có nhiều lần kiểm toán? Bởi vì các kiểm toán viên, ngoại trừ những trường hợp hiếm hoi như @sherlockdefi, không quan tâm đến việc dự án có bị tấn công hay không. Họ không chịu bất kỳ trách nhiệm nào đối với một hệ thống đã được triển khai. Không có rủi ro gì cả. Chỉ cần tiền mặt và "mã nguồn trông ổn". Và ngay cả như vậy, tất cả các kiểm toán viên này đều không phát hiện ra điều hiển nhiên này. Chúng ta có một SERVICE_ROLE có thể Mint số lượng stablecoin không giới hạn, điều này KHÔNG ĐƯỢC GHI CHÉP Ở BẤT KỲ ĐÂU. Thôi nào, anh bạn! "Đây là khóa riêng quyền năng trong hệ thống", nhưng nếu anh trả cho chúng tôi khoản phí nhỏ, phần mềm của anh sẽ ổn, chúng tôi không thực sự quan tâm chuyện gì xảy ra sau đó. Chỉ cần đừng giữ nó sai cách là được, nhé? ĐƯỢC ĐẦU TƯ BỞI COINBASE, ĐƯỢC NHÀ HÀNG BÍT TẾT KHEN NGỢI Sự chấp thuận của Brian cũng chẳng giúp ích gì. Chỉ sáu ngày trước, Steakhouse đã viết điều này trong chuyên mục Phân tích Tài chính của Steakhouse: "Về mặt vận hành, Resolv thể hiện sự chặt chẽ về mặt thể chế thông qua việc lưu ký bởi bên thứ ba, hệ thống dự phòng đa oracle và các biện pháp bảo vệ theo chương trình. Resolv đã hoạt động mà không gặp sự cố nào cho đến nay và đã thể hiện khả năng tự điều chỉnh trong các điều kiện bất lợi." kitchen.steakhouse.financial/p... Đoạn văn này quá chung chung đến nỗi nó cũng có thể là một báo cáo kiểm toán chất lượng ISO 9001, vì không nêu rõ các hệ thống, quy trình và đặc tính cụ thể của chúng. "Tôi đã đi ăn trưa với mấy anh em, và sau khi uống một ly rượu vang đỏ Pháp, tôi chắc chắn rằng hệ thống hoạt động tốt." Việc lưu giữ bởi bên thứ ba? Điều này có nghĩa là họ đã sử dụng Fireblocks để bảo mật khóa riêng tư? Một ví khóa riêng tư do một cựu điệp viên Mossad viết vẫn là một ví khóa riêng tư, và thậm chí còn rủi ro hơn vì khóa có khả năng bị đánh cắp trực tiếp bởi nhà cung cấp phần mềm dịch vụ mã nguồn đóng của bạn, vì bạn không thể biết phần mềm của họ tệ đến mức nào. CÁCH TRÁNH NHỮNG ĐIỀU NÀY TRONG TƯƠNG LAI Việc đó không khó. Đặc biệt với số vốn ban đầu 10 triệu đô la và mức Stake tối đa lên đến 500 triệu đô la, người ta hoàn toàn có thể làm tốt hơn. 1. Khóa riêng tư có quyền hạn thấp hơn 2. Sử dụng các kiểm toán viên có "lợi ích cá nhân" trong dự án. 3. Minh bạch và tuân theo mô hình tài chính phi tập trung. LÀM THẾ NÀO BẠN, VỚI TƯ CÁCH LÀ NGƯỜI DeFi , CÓ THỂ TRÁNH NHỮNG SỰ CỐ NÀY? Đây là một vấn đề khó. Vấn đề nằm ở chỗ các hợp đồng thông minh cơ bản được viết bằng Solidity, một ngôn ngữ tự chế hỗn tạp. Rất khó để đánh giá các thuộc tính bảo mật của hợp đồng thông minh Solidity . Có những ngôn ngữ tốt hơn, nhưng dường như chúng ta vẫn phải sử dụng Solidity cũ. Mặc dù Solidity có những nhược điểm đã được biết đến rộng rãi, nhưng vẫn chưa có nhiều nỗ lực thực sự để làm cho nó an toàn hơn bằng cách xem xét lại các sự cố trong quá khứ và thuê người chuyên nghiệp để tìm ra cách khắc phục những lỗ hổng này ở cấp độ ngôn ngữ. Trí tuệ nhân tạo (AI) sẽ giúp ích rất nhiều. Bởi vì chúng ta chưa thể buộc các chuyên gia kiểm toán bảo mật phải chịu trách nhiệm, do uy tín mà họ tạo dựng dường như không tương quan với các vụ tấn công mạng, nên cách tốt nhất là loại bỏ các chuyên gia kiểm toán bảo mật. Một ngày nào đó, và rất sớm thôi, bất kỳ ai cũng có thể hướng một tác nhân AI đến một hệ thống hợp đồng thông minh phức tạp đã được triển khai, và nó sẽ đưa ra báo cáo đánh giá tích cực hoặc tiêu cực. Về chủ đề này, tôi đã thực hiện một thử nghiệm nhỏ ở đây github.com/tradingstrategy-ai/...… và Claude Code đã có thể chọn được khóa riêng tư có đặc quyền trong hệ thống của một trong các đối tác của chúng tôi trên một hợp đồng thông minh đã được triển khai mà lẽ ra không được phép có. P.S. Đối với HSM: Bạn không cần bất kỳ giải pháp bảo mật mờ ám nào khác từ các công ty thương mại để bảo vệ các khóa riêng tư quan trọng của mình. Nếu bạn đang xây dựng các hệ thống hợp đồng thông minh quan trọng về bảo mật cần một khóa riêng tư có độ tin cậy cao ngoài chuỗi, bạn có thể sử dụng Google Cloud cho việc này. Đây là mô-đun ký điện tử Ethereum mã nguồn mở miễn phí của chúng tôi dành cho Google Cloud: web3-ethereum-defi.tradingstra...… - chỉ cần nhớ thiết lập chính sách tổ chức cho phù hợp. Xin chúc mừng @zacodil và @omeragoldberg vì những nghiên cứu này.