Một khi đề cập đến các hợp đồng trên chuỗi gặp vấn đề, mọi người đều đổ lỗi cho mã nguồn—bug, lỗ hổng logic, các trường hợp biên không được xem xét kỹ lưỡng. Thật sự, có những việc là do mã nguồn gây ra. Nhưng thành thật mà nói, nhiều "rủi ro hợp đồng thông minh" hoàn toàn không phải do hợp đồng tự sinh ra, mà là bị thâm nhập từ bên ngoài. Những rủi ro này giả dạng thành dữ liệu, trong khi hợp đồng hoàn toàn không học được cách xem xét xem dữ liệu đó có thực sự đáng tin hay không.

Đây chính là bất lực lớn nhất của hợp đồng thông minh—cái "não" của nó cực kỳ cứng nhắc: không biết linh hoạt, không dám chất vấn, cũng hoàn toàn không quan tâm xem con số mà bạn cung cấp có hợp lý trong thực tế hay không. Oracles gửi về một mức giá X, hợp đồng coi đó là chân lý tuyệt đối, không chớp mắt thực thi logic. Kết quả là gì? Thực tế, tầng dữ liệu ngầm đã trở thành nguồn gốc rủi ro của hợp đồng, nhưng nhóm phát triển thường không nhận ra điều đó.

Hơn nữa, các cái bẫy ở phía dưới lại càng đau lòng hơn: thanh lý lớn đột ngột, giá thanh toán kỳ lạ, thanh khoản của kho bạc nhanh chóng cạn kiệt nhưng vẫn tiếp tục điều chỉnh vị thế… Bạn nhìn thấy logic hợp đồng không có vấn đề gì, thực thi cũng không bị gián đoạn, nhưng kết quả lại rối tung lên. Rất nhiều lần, hợp đồng thực sự không có vấn đề, chỉ là cái "thực tế" mà nó "nhìn thấy" đã có vấn đề rồi.

Đây chính là lý do tại sao tôi nghĩ oracle thực ra là một hạ tầng quản lý rủi ro chứ không chỉ là một công cụ nhập dữ liệu. Những gì nó truyền tải quyết định "phiên bản thực tế" nào trên chuỗi sẽ kích hoạt các thao tác không thể hoàn tác trên chuỗi. Trách nhiệm này không nhẹ nhàng chút nào, cấu trúc thiết kế của nó trực tiếp liên quan đến an toàn của toàn bộ hệ thống hợp đồng. Làm thế nào để lọc dữ liệu nhiễu, làm thế nào để nhận diện nguồn dữ liệu đáng ngờ, làm thế nào để phòng tránh điểm yếu đơn lẻ—những chi tiết thiết kế này thực chất chính là đang trang bị "quần bảo hiểm an toàn" cho hợp đồng thông minh.