Vị thế đòn bẩy của bạn gần như mất hết tiền vào đêm qua và thủ phạm thực sự không phải là biến động thị trường, mà là kẻ giết người vô hình ẩn nấp sau hệ thống DeFi.

Chúng ta đã thấy rất nhiều câu chuyện như thế này: thị trường trầm lắng và không có biến động bất thường, nhưng thỏa thuận cho vay hoặc vị thế phái sinh mà bạn đặt cược đột ngột bị thanh lý. Tài khoản bị làm trống ngay lập tức và đã quá muộn để bạn phản ứng.

Nếu bạn tìm hiểu sâu hơn, bạn sẽ thấy rằng thủ phạm thường là một vấn đề với việc cho ăn giá của nhà tiên tri. Một dữ liệu sai có thể kích hoạt phản ứng dây chuyền của toàn bộ chuỗi. Đây không phải là một sự kiện có xác suất thấp, mà là một vấn đề cũ lặp đi lặp lại trong vòng tròn DeFi.

Điểm mấu chốt của vấn đề là gì? Về cơ bản, blockchain không thể kết nối trực tiếp với dữ liệu trong thế giới thực. Bạn cần một "cầu nối" - một oracle - để mang thông tin như giá cả, thời tiết và tỷ giá hối đoái off-chain on-chain. Vấn đề là, cây cầu sụp đổ quá dễ dàng:

Dữ liệu có thể bị trì hoãn hoặc giả mạo với

Một mức giá cực đoan ngay lập tức gây ra một cơn bão thanh lý

Một nút tập trung có thể làm xấu hoặc một điểm lỗi duy nhất làm tê liệt toàn bộ hệ thống

Ai đó nghĩ ra một con đường khác. Thay vì để tất cả các tính toán chạy trên chuỗi (chậm và tốn kém), tốt hơn là bạn nên thu thập dữ liệu và các hoạt động phức tạp ngoài chuỗi, sau đó chỉ đưa kết quả lên chuỗi để xác minh và xác nhận. Nghe có vẻ giống như một "phán quyết tư pháp" - công việc thu thập và phân tích bằng chứng bẩn thỉu được thực hiện bên ngoài phòng xử án, và thẩm phán chỉ đưa ra vụ án dựa trên bằng chứng đầy đủ.

Có một số lợi thế đối với ý tưởng xác minh phân cấp này: logic tính toán có thể được tùy chỉnh linh hoạt mà không ảnh hưởng đến bảo mật. Các giao thức phái sinh có thể yêu cầu tính toán biến động phức tạp, các giao thức bảo hiểm có thể yêu cầu dữ liệu khí tượng — mỗi kịch bản có nhu cầu khác nhau, nhưng tất cả chúng đều có thể được xử lý trong khuôn khổ này.

Liệu bộ ý tưởng này có thể giải quyết hoàn toàn vấn đề oracle hay không phụ thuộc vào bài kiểm tra thực tế tiếp theo. Nhưng ít nhất một hướng được chỉ ra: thay vì chấp nhận rủi ro một cách thụ động, tốt hơn là chủ động thiết kế một kiến trúc dữ liệu linh hoạt hơn.