Hãy tưởng tượng một hợp đồng thông minh như một nhà giao dịch trực tuyến 24 giờ, hoàn toàn dựa vào dữ liệu bên ngoài - thông tin giá, điều kiện thị trường, kết quả thanh toán. Nhưng điều gì sẽ xảy ra nếu kênh dữ liệu này đến và đi, gửi sai giá trong một thời gian và trì hoãn nó trong nửa ngày? Các ứng dụng DeFi sẽ mắc lỗi, các thuộc tính động NFT sẽ bị kẹt và quá trình yêu cầu bảo hiểm sẽ bị tê liệt. Đây là điểm đau tiềm ẩn sâu sắc nhất trong thế giới blockchain ngày nay:**Độ tin cậy và bản chất thời gian thực của dữ liệu còn lâu mới theo kịp tham vọng của các ứng dụng on-chain**。



Vấn đề với các nhà tiên tri truyền thống thực sự là rõ ràng. Hầu hết các giải pháp giống như một ống truyền duy nhất - một nguồn dữ liệu duy nhất và một đường dẫn cố định, và một khi nó bị ô nhiễm bởi một cuộc tấn công hoặc tắc nghẽn mạng, toàn bộ hệ sinh thái ứng dụng phụ thuộc vào nó sẽ bị tê liệt. Rủi ro tập trung tại một thời điểm và gây tử vong cho toàn bộ hệ sinh thái.

APRO đang cố gắng tái cấu trúc cơ bản hệ thống. Ý tưởng cốt lõi là thành lập một "trung tâm xử lý dữ liệu phân tán". Làm thế nào để làm điều đó?

**Bộ sưu tập đa nguồn**: Lấy thông tin từ hàng chục nguồn dữ liệu độc lập, được xác thực cùng một lúc, thay vì dựa vào một nguồn duy nhất. Bằng cách này, ngay cả khi có sự cố xảy ra với một nguồn, toàn bộ hệ thống sẽ không gặp sự cố.

**Lọc lớp nút**: Dữ liệu thô được thu thập đi vào mạng lưới các nút phi tập trung, tiến hành các cơ chế xác minh chéo và đồng thuận để đảm bảo tính xác thực của dữ liệu.

**Giám sát thời gian thực AI**: Mô hình học máy chạy liên tục để xác định và cô lập dữ liệu bất thường, thông tin ô nhiễm và thực hiện kiểm soát chất lượng như bác sĩ xét nghiệm máu.

Nhưng một kế hoạch như vậy cũng phải đối mặt với một vấn đề thực tế:**Các kịch bản khác nhau có yêu cầu dữ liệu hoàn toàn khác nhau**。 Một số ứng dụng yêu cầu phản hồi cực nhanh, trong khi những ứng dụng khác nhạy cảm với chi phí.

Câu trả lời của APRO là cung cấp hai kênh.

**Chế độ đẩy**(Ưu tiên theo thời gian thực): Các thông tin như thay đổi giá và điểm sự kiện sẽ được đẩy lên chuỗi ngay lập tức khi hệ thống chủ động phát hiện các thay đổi. Đây là cách thân thiện nhất đối với các nền tảng giao dịch DeFi, vì vậy bạn không còn phải lo lắng về việc bị thua lỗ do dữ liệu chậm trễ.

**Chế độ kéo**(Thanh toán theo mức sử dụng): Ứng dụng chỉ bắt đầu yêu cầu dữ liệu khi thực sự cần thiết và hoàn toàn không tính phí trong thời gian nhàn rỗi. Các hoạt động tần suất thấp như yêu cầu bảo hiểm và định giá tài sản là phù hợp nhất với phương pháp này.

Tóm lại, các nhà phát triển có thể điều khiển nó một cách linh hoạt như điều chỉnh vòi và lựa chọn phương thức cung cấp dữ liệu phù hợp theo thực tế của doanh nghiệp. Đây không chỉ là nâng cấp công nghệ, mà cơ bản giải quyết được vấn đề "cung cấp máu không đủ" dữ liệu được áp dụng trên chuỗi.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • 6
  • Đăng lại
  • Retweed
Bình luận
0/400
AirdropChaservip
· 11giờ trước
Oracle chuyện này đã nên giải quyết từ lâu, lỗi điểm đơn thực sự có thể giết chết toàn bộ hệ sinh thái, không phải nói chơi. Đa nguồn dự phòng không phải ý tưởng mới, nhưng ít có kế hoạch nào thực sự khả thi, xem xét方案 của APRO có chút thú vị. Hệ thống đẩy và kéo song song thực sự linh hoạt, chỉ là không rõ chi phí có thể giảm đến mức nào, những dịch vụ gọi là phí thấp trên thị trường cuối cùng cũng chẳng rẻ hơn bao nhiêu
Xem bản gốcTrả lời0
StakeWhisperervip
· 11giờ trước
Oracle thực sự là một thách thức lớn, thất bại tại điểm đơn lẻ quá đáng sợ... Thu thập đa nguồn nghe có vẻ đáng tin cậy, chỉ sợ thực tế triển khai lại là chuyện khác.
Xem bản gốcTrả lời0
WalletDivorcervip
· 11giờ trước
Vấn đề về oracle thực sự là rắc rối lớn, nhưng giải pháp kênh đôi này nghe có vẻ hơi quá lý tưởng... Việc thu thập đa nguồn nghe có vẻ tốt, chỉ sợ là ai sẽ duy trì đám node ở tầng node đó, chi phí lại đổ lên ai.
Xem bản gốcTrả lời0
GateUser-beba108dvip
· 11giờ trước
Chuyện về oracles thực sự là một vấn đề nan giải, lỗi điểm đơn lẻ thật sự dễ gây ra sự cố
Xem bản gốcTrả lời0
SchroedingersFrontrunvip
· 11giờ trước
Oracle thực sự là một vấn đề nan giải, một điểm yếu có thể khiến toàn bộ hệ thống sụp đổ, nhưng ý tưởng thu thập đa nguồn của APRO cuối cùng cũng có chút ý nghĩa
Xem bản gốcTrả lời0
TestnetNomadvip
· 11giờ trước
Này, vấn đề về oracles thực sự là một thử thách lớn, nguồn dữ liệu đơn lẻ quá dễ bị tấn công phá hủy.
Xem bản gốcTrả lời0
  • Ghim