AI trở thành "kẻ phản diện", bảo hiểm DeFi cần một bài kiểm tra áp lực

Thực hiện bài kiểm tra va chạm cho kho DeFi: Firelight dự định sử dụng AI để tìm kiếm "tai nạn tiếp theo".

Tác giả: @jrdothoughts

Biên dịch: AididiaoJP, Foresight News

Điểm mù của bảo hiểm DeFi: Chưa từng nổ không có nghĩa là an toàn

Hãy nghe một đoạn quảng cáo hài hước: "Chiếc máy bay mới của chúng tôi hoàn toàn an toàn, chưa bao giờ gặp tai nạn."

"Bay được bao lâu rồi?"

"... Khoảng hai lần."

Thay máy bay bằng kho DeFi, câu chuyện trở nên quen thuộc: Sáu tháng rút tiền suôn sẻ, không bị tấn công, lợi nhuận cũng khá. Điều này chắc chắn là bằng chứng. Nhưng trong sáu tháng đó, nó có gặp phải tình trạng tắc nghẽn mạng khiến tài sản thế chấp bị mất giá, nhà cung cấp thanh khoản (LP) đồng loạt rút tiền, và oracle không cập nhật không? Có khả năng cao là không.

Lịch sử sạch sẽ chỉ cho thấy một hệ thống đã chịu đựng những gì. Bảo hiểm cần hỏi: Nó có thể gặp phải điều gì tiếp theo.

Đây là cơ hội mà Firelight nhìn thấy: Định giá dựa trên cách thức hình thành tổn thất, chứ không chỉ xem tổn thất đã xảy ra hay chưa. Lịch sử có trách nhiệm neo giữ, mô phỏng có trách nhiệm khám phá các tình huống thay thế, AI có trách nhiệm tìm ra điểm yếu, và vốn có trách nhiệm bảo lãnh.

Lịch sử là bức ảnh, nhưng hệ thống có thể thay đổi

Dữ liệu tổn thất lịch sử là bức ảnh của một cỗ máy hoạt động dưới một điều kiện nhất định. Khi cỗ máy thay đổi, bức ảnh cần được xem xét lại.

Một kho mới thêm loại tài sản thế chấp, thay đổi oracle, và tăng đòn bẩy. Tên không thay đổi, logo không thay đổi, nhưng rủi ro đã khác biệt rất nhiều. Những người vay, người thanh lý và LP bên trong không phải là những con số đứng yên trong bảng. Họ sẽ phản ứng với các động lực, và khi có sự cố, họ đều muốn chạy ra cùng một cánh cửa.

Điều này giống như một bản đồ giao thông được vẽ dựa trên tình hình đi lại vào thứ Ba bình thường. Nhìn chung có vẻ chính xác, nhưng khi cầu chính bị đóng, nó sẽ không còn hiệu quả. Bản đồ không sai, mà tình hình đã thay đổi.

Vì vậy, đối với Firelight, vấn đề thực sự không chỉ là "giao thức này đã từng bị hack chưa", mà là: Nó có những quyền hạn nào? Những phụ thuộc nào thực sự quan trọng? Khi mọi người cùng chạy ra ngoài, những con đường thanh lý nào vẫn còn khả thi? Khung công khai của Firelight đã tách biệt các lỗ hổng kỹ thuật và tính dễ bị tổn thương kinh tế, thay vì gộp lại thành một điểm số an toàn.

Bảo hiểm nhắm vào cấu trúc và mối quan hệ phụ thuộc hiện tại của hệ thống, chứ không phải thương hiệu mà nó đã sử dụng cho đến nay.

Bảo hiểm thảm họa đã viết kịch bản từ lâu

Các công ty bảo hiểm truyền thống không từ bỏ việc mô hình hóa sự không chắc chắn. Các nhà bảo hiểm thảm họa luôn làm một việc: Mô phỏng cách thức xảy ra thảm họa, tài sản nào sẽ bị phơi bày, cấu trúc có bao nhiêu điểm yếu, và cuối cùng hợp đồng sẽ phải bồi thường bao nhiêu. Những cơn bão đã xảy ra trong quá khứ không đại diện cho tất cả các cơn bão có thể xảy ra trong tương lai.

DeFi cũng cần một bộ mô hình thảm họa riêng. Chỉ khác là thảm họa từ bão chuyển sang lỗi oracle, đối tượng bị ảnh hưởng từ tòa nhà chuyển sang vị thế vay, tính dễ bị tổn thương từ chất lượng xây dựng chuyển sang đệm thế chấp và thiết kế thanh lý, và cuối cùng tính toán bồi thường theo các điều khoản bảo hiểm.

Mô hình thảm họa hỏi: Một cơn bão quét qua một thành phố sẽ như thế nào? Mô hình DeFi hỏi: Một sự cố lan rộng theo đồ thị phụ thuộc sẽ như thế nào?

Firelight đã công khai thảo luận về việc phân tích rủi ro, hiệu chỉnh lịch sử, mô phỏng Monte Carlo, mô hình ngôn ngữ và học tăng cường kết hợp lại, đưa vào một phòng thí nghiệm kiểm tra va chạm tài chính. Cần lưu ý rằng đây là một hướng đề xuất, không phải tuyên bố rằng mọi phần đã được triển khai.

Còn một điểm cần lưu ý: Firelight định nghĩa sản phẩm của mình là bảo hiểm theo giao thức, chứ không phải hợp đồng bảo hiểm truyền thống. Việc so sánh với bảo hiểm trong bài viết này là so sánh về kỷ luật bảo hiểm, không liên quan đến định nghĩa pháp lý của sản phẩm.

Làm thế nào để xây dựng phòng thí nghiệm kiểm tra va chạm tài chính

Bước đầu tiên, trước tiên cố định trạng thái ban đầu, đảm bảo có thể tái hiện. Phiên bản hợp đồng, số dư, vị thế thế chấp, cũng như cài đặt oracle, quy tắc thanh lý, và tính thanh khoản thị trường đều phải được khóa lại. Nếu không, kết quả mô phỏng hai lần không khớp, có thể chỉ vì điểm khởi đầu khác nhau, không đo lường cùng một hệ thống.

Bước thứ hai, tách biệt thực thi và giả định. Nhánh blockchain có thể chạy logic hợp đồng thực tế, nhưng nó không thể tự tạo ra tính thanh khoản, giá cả ngoài chuỗi và hành vi của con người trong tương lai. Những điều này phải được mô hình hóa rõ ràng. Các bài kiểm tra dựa trên nhánh và điều khiển đại lý đã có tiền lệ trong nghiên cứu DeFi.

Bước thứ ba, sắp xếp các loại người tham gia trong môi trường mô phỏng. Người vay, người thanh lý, người gửi tiền, LP, mỗi người đều có giới hạn tài chính và động lực riêng. Nhưng không thể cho ai đó vai trò chính: Người thanh lý không thể thực hiện giao dịch thua lỗ chỉ để tạo ra một kết thúc hoàn hảo. Các vai trò cũng không nhất thiết phải sử dụng mô hình ngôn ngữ lớn, quy tắc đơn giản và minh bạch đôi khi tốt hơn, nhanh hơn và dễ tái hiện hơn. Các thất bại ở cấp độ kỹ thuật vẫn cần dựa vào kiểm tra mờ, xem xét mã và tiêm lỗi, những phương pháp này và mô phỏng kinh tế là song song, không thay thế cho nhau.

Bước thứ tư, gây rối. Giá nhảy vọt, oracle cập nhật chậm, tính thanh khoản giảm sút, và gián đoạn thực thi đều cần thử nghiệm. Không chỉ thay đổi độ lớn, mà còn thay đổi thứ tự. LP rút thanh khoản trước cú sốc giá và sau cú sốc, kết quả có thể hoàn toàn khác nhau.

Mô phỏng cuối cùng không nên đưa ra một điểm số an toàn chung chung, mà nên đưa ra một chuỗi tổn thất: vị thế nào thất bại trước, thu hồi được bao nhiêu, và khoảng trống mở rộng như thế nào. Có được chuỗi này, mới có thể xác định giới hạn bảo hiểm và yêu cầu vốn, hoặc đơn giản là đưa ra câu nói "không bảo hiểm".

Để AI ngồi vào "ghế phản diện", nhưng không thể thay đổi định luật vật lý

Cách sử dụng AI trực quan nhất là đọc mã và tài liệu. Mô hình ngôn ngữ có thể sắp xếp các phụ thuộc, giải thích các bản nâng cấp, và đề xuất các tình huống thất bại. Nhưng một câu chuyện nghe có vẻ đáng tin cậy không có nghĩa là đã tìm ra lỗ hổng, nó vẫn cần bằng chứng.

Điều thú vị hơn là để AI chủ động tìm kiếm các tình huống khả thi. Mô phỏng Monte Carlo sẽ lấy mẫu từ phân phối đã thiết lập, điều này chắc chắn hữu ích; nhưng những tổ hợp thực sự tồi tệ có thể quá hiếm, việc lấy mẫu ngẫu nhiên phần lớn thời gian chỉ lặp lại việc phát hiện các tình huống bình thường.

Kiểm tra áp lực tự thích nghi ngược lại: đại lý trong mô phỏng chọn các yếu tố gây rối, chủ động tìm kiếm các con đường thất bại đáng tin cậy. Trong các bài kiểm tra lái xe tự động, đã có người sử dụng học tăng cường để trình bày tư duy này. Đại lý có thể thay đổi thời tiết, nhưng không thể viết lại định luật vật lý.

Trong thiết lập đề xuất của Firelight, đại lý có thể điều chỉnh độ trễ của oracle, rút thanh khoản và tỷ lệ có mặt của người thanh lý trong giới hạn thực tế. Tìm ra con đường phá hoại thì được thưởng, gian lận thì bị phạt. Một kẻ phản diện có vô hạn vốn và quyền lực của Chúa không phải là một mô hình bảo hiểm hữu ích.

Sau đó, để AI phân cụm các đường đi thất bại, chọn ra nhóm thí nghiệm tiếp theo có thể giảm thiểu sự không chắc chắn. Hàng trăm thảm họa có vẻ khác nhau có thể chia sẻ cùng một nút thắt thanh lý. Đây mới là giá trị hành động.

Tốc độ cũng quan trọng. Các phương pháp gần đúng chi phí thấp trước tiên lọc qua nhiều tình huống, các bài kiểm tra thực hiện tốn kém hơn sau đó sẽ phát lại các tình huống quan trọng trong nhiều môi trường thử nghiệm độc lập. Nhưng các lối tắt phải được xác minh. Tăng tốc cho mô phỏng sai sẽ chỉ khiến nó tự tin mắc lỗi nhanh hơn.

AI đóng vai trò là tài xế trong các bài kiểm tra đối kháng, không phải là trọng tài an toàn. Nó chỉ ra những gì cần kiểm tra, động cơ thực hiện, chuyên gia trong lĩnh vực và bằng chứng quyết định xem phát hiện này có đứng vững hay không.

Từ chuỗi tổn thất đến điều khoản bảo hiểm

Hãy tưởng tượng một kho cho vay giả định: Giá tài sản thế chấp giảm, LP đồng loạt rút tiền, oracle cập nhật chậm. Mặc dù người thanh lý đã vào cuộc, nhưng trượt giá đã nuốt chửng giá trị thu hồi, cuối cùng khoản nợ của người vay vượt quá giá thực tế mà tài sản thế chấp có thể bán được.

Hãy làm thêm vài nhóm đối chiếu: Chỉ để giá giảm; giá giảm trong khi rút thanh khoản; nhiều yếu tố cùng xảy ra. Chỉ như vậy mới có thể thấy được điểm yếu thực sự nằm ở giá cả, hay ở độ sâu của thị trường, hoặc là do sự tương tác giữa cả hai.

Giả sử một lần chạy ví dụ tạo ra 2 triệu USD tổn thất đủ điều kiện, tự giữ 500.000 USD, giới hạn bảo hiểm 1 triệu USD. Tầng tự giữ hấp thụ 500.000 USD, giả sử bảo hiểm bồi thường 1 triệu USD, còn lại 500.000 USD nằm ngoài giới hạn.

Đây là các điều khoản ví dụ hư cấu, không phải báo giá của Firelight, cũng không phải kết quả mô phỏng thực tế. Tính đủ điều kiện, thu hồi, loại trừ trách nhiệm và bảo hiểm chồng chéo vẫn cần được làm rõ.

Điều quan trọng là: Có tổn thất kinh tế không có nghĩa là có thể nhận được bồi thường. Mô phỏng chỉ thực sự hữu ích khi ảnh hưởng đến quyết định bảo hiểm, ví dụ như giảm giới hạn bảo hiểm, yêu cầu kiểm soát rủi ro nghiêm ngặt hơn, giữ lại nhiều vốn hơn, hoặc đơn giản là từ chối bảo hiểm. Dù hình ảnh thảm họa có đẹp đến đâu, nó vẫn không phải là một quyết định tài chính.

Tìm ra con đường thất bại không có nghĩa là tính toán xác suất

Giả sử một đại lý đối kháng đã phá vỡ hệ thống trong 30% các bài kiểm tra. Điều này có nghĩa là hệ thống có xác suất thất bại 30% không? Không hẳn. Đại lý này vốn đã được thiết kế để tìm ra lỗ hổng.

Việc phát hiện thất bại trả lời câu hỏi "Có thể hỏng như thế nào, hỏng đến mức nào". Ước lượng xác suất trả lời câu hỏi "Tần suất xuất hiện của các điều kiện này trong thời gian bảo hiểm là bao nhiêu". Nhầm lẫn hai điều này là tạo ra độ chính xác giả.

Về mặt khái niệm, bồi thường dự kiến là số tiền bồi thường trong mỗi tình huống, nhân với xác suất xảy ra của tình huống đó, sau đó cộng tổng lại. Những xác suất này cần có bằng chứng hỗ trợ, giả định cũng cần được viết rõ ràng. Nếu không có ước lượng đáng tin cậy, hãy sử dụng khoảng, giới hạn bảo thủ và ràng buộc áp lực, thay vì bịa ra những con số chính xác đến dấu thập phân.

Bồi thường dự kiến không bằng tổng phí bảo hiểm. Vốn cũng cần phải bao phủ rủi ro đuôi, chi phí vận hành và sự không chắc chắn, trong khi rủi ro đuôi thường rất khó chịu. Nhìn từ góc độ tổ hợp, sự phụ thuộc chung có thể khiến nhiều hợp đồng cùng kích hoạt bồi thường.

Khung vốn công khai của Firelight đã xem xét đến độ tập trung và sự rút lui tài sản thế chấp. Mô phỏng cũng nên kiểm tra cả hai đầu: một đầu là sự gia tăng yêu cầu bồi thường, đầu kia là tài sản hỗ trợ đồng thời giảm giá, thậm chí trở nên khó bán hơn. Nếu một thảm họa lớn xảy ra mà vốn cũng giảm theo, thì bể bảo hiểm không thể chỉ ước tính theo tổn thất trung bình.

Ai sẽ kiểm tra "máy kiểm tra áp lực"?

Mô phỏng có thể tự logic nhưng kết luận lại hoàn toàn sai. Chạy một triệu lần với các thiết lập người thanh lý không thực tế chỉ là lặp lại cùng một lỗi một triệu lần. Chạy nhiều lần có thể giảm thiểu sai số mẫu, nhưng sai số của mô hình sẽ không tự động giảm.

Một phòng thí nghiệm đáng tin cậy sẽ làm bốn điều: Phân tích các sự kiện đã biết, kiểm tra bằng dữ liệu ngoài mẫu, so sánh các mô hình độc lập được xây dựng bởi các nhóm khác nhau, điều chỉnh giả định về hành vi của người tham gia. Bản chụp, hạt giống ngẫu nhiên và hồ sơ chạy đều cần được lưu trữ, để các phát hiện quan trọng có thể tái hiện. Còn cần phải hỏi lại một câu: AI tìm thấy điểm yếu của giao thức hay là lỗi của chính mô phỏng?

Không có bộ kiểm tra nào có thể chứng minh đã tìm ra tất cả các con đường thảm họa. Chính vì có những phụ thuộc chưa biết và hành vi chưa từng thấy, mà cần có đệm vốn, loại trừ trách nhiệm và sự kiềm chế trong bảo hiểm.

Ranh giới hợp đồng cũng cần được làm rõ. Bằng chứng mới có thể ảnh hưởng đến định giá và năng lực trong tương lai, nhưng không nên khiến bảo hiểm hiện tại trở thành mục tiêu di động. Khung công khai của Firelight tách biệt việc giám sát rủi ro liên tục và tỷ lệ cố định trong thời gian bảo hiểm. Học hỏi liên tục và giữ lời hứa có thể đồng hành; nhưng việc sửa đổi cam kết sau khi nguy hiểm xuất hiện thì không thể.

Kết luận: Học hỏi trước khi tổn thất xảy ra

Giá trị lớn hơn là để bảo hiểm gắn vào quy trình phát triển. Khi hệ thống có thay đổi lớn, sẽ kích hoạt các bài kiểm tra tương ứng; kết quả kiểm tra ảnh hưởng đến quyết định bảo hiểm mới; các sự kiện thực tế giúp cải thiện phiên bản mô hình tiếp theo. Công việc thực hiện càng tốt, cuối cùng sẽ phản ánh vào giá bảo hiểm và khả năng tiếp cận.

Bồi thường lịch sử là việc học lại sau khi sự việc xảy ra. Mô phỏng giúp Firelight làm rõ trước: Hệ thống này có thể gặp lỗi như thế nào.

AI có trách nhiệm mở rộng phạm vi tìm kiếm, bằng chứng có trách nhiệm ràng buộc kết luận của nó, và vốn có trách nhiệm thực hiện cam kết. Mục tiêu không phải là dự đoán mọi thảm họa, mà là sau khi nhìn rõ những gì có thể phải đối mặt, mới đầu tư vốn để chịu đựng những tổn thất không thể tránh khỏi.