Nhiều nhà phát triển khi tích hợp dịch vụ dữ liệu chuỗi, phản ứng đầu tiên là so sánh các tham số kỹ thuật: độ trễ bao nhiêu, có thể bao phủ bao nhiêu chuỗi, số lượng nút, chất lượng nguồn cung cấp báo giá. Nhưng những người đã từng đưa vào môi trường sản xuất đều rõ ràng rằng, cách làm này thực ra đã hơi lỗi thời.
Chọn Oracle đã không còn đơn thuần là quyết định kỹ thuật nữa, nó còn giống như một bài toán thiết kế sản phẩm: bạn muốn cung cấp trải nghiệm người dùng như thế nào, sẵn sàng chịu rủi ro loại nào, làm thế nào để kiểm soát phân bổ chi phí, trong thời điểm thị trường biến động hoặc có tranh cãi, chọn cách ứng phó ra sao. Nói ngắn gọn, cần trả lời những câu hỏi này.
Hiện nay, một số giải pháp Oracle mới bắt đầu cung cấp chế độ hai động cơ — vừa có đẩy dữ liệu chủ động, vừa có kéo dữ liệu theo yêu cầu. Ý tưởng thiết kế này thực sự rất thông minh, vì các mô hình kinh doanh khác nhau không phải là "cái này tốt, cái kia xấu", mà là "cái nào phù hợp hơn".
Lấy ZetaChain làm ví dụ, họ trình bày hai mô hình dịch vụ khá rõ ràng. Data Push là đẩy dữ liệu lên chuỗi theo lịch trình định kỳ hoặc theo ngưỡng, ưu điểm là tính thời gian thực cao, khả năng mở rộng tốt, phù hợp với những trường hợp cần cập nhật liên tục, mong muốn ổn định dự kiến. Data Pull là ứng dụng chủ động yêu cầu dữ liệu, độ trễ thấp, tần suất cập nhật linh hoạt, đặc biệt phù hợp với DEX hoặc sản phẩm DeFi — chúng cần lấy dữ liệu nhanh chóng nhưng không muốn trả thêm chi phí cho việc cập nhật liên tục.
Làm thế nào để xác định mình nên chọn cái nào? Có thể bắt đầu từ phân loại bản chất ứng dụng. Sản phẩm của bạn là "động lực trạng thái" hay "động lực giao dịch"?
Nếu bạn làm các giao thức vay mượn, kho bạc, chiến lược lợi nhuận, các logic kinh doanh tương đối ổn định, các tham số thanh lý cũng không thay đổi thường xuyên, thì thứ bạn thực sự cần là dịch vụ dữ liệu tiêu chuẩn "cung cấp ổn định, nhịp độ cập nhật dự kiến, giao diện hợp đồng rõ ràng". Trong trường hợp này, chế độ Push sẽ tiện lợi hơn — giống như cung cấp điện, nước, ga theo lịch trình cố định, chi phí và trải nghiệm sử dụng đều rất ổn định.
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.
7 thích
Phần thưởng
7
5
Đăng lại
Retweed
Bình luận
0/400
TokenDustCollector
· 12-26 23:11
Nói thật, ý tưởng về động cơ đẩy kéo (push pull) này thật sự rất hay, cuối cùng cũng có người giải thích rõ ràng về chuyện này
Xem bản gốcTrả lời0
WinterWarmthCat
· 12-26 12:49
Cuối cùng, ai đó đang nói sự thật, và các thông số kỹ thuật thực sự đã lỗi thời
Ý tưởng động cơ kép này thật tuyệt vời, không phải để chọn đúng, mà là chọn đúng, và tôi cảm thấy rằng nhiều dự án vẫn đang vật lộn với sự chênh lệch độ trễ vài mili giây
Push and Pull phải dựa trên bản chất kinh doanh của chính mình, không thể mù quáng chạy theo xu hướng
Phép ẩn dụ về nước, điện và khí đốt thật tuyệt vời, và Push là một logic như vậy
Các giao thức cho vay an toàn hơn nhiều với Push và kéo DEX thực sự linh hoạt và tiết kiệm chi phí hơn
Lựa chọn Oracle giống như yêu, bạn phải tìm ra những gì phù hợp với mình, không phải xem thông số của ai là tốt nhất
Xem bản gốcTrả lời0
RatioHunter
· 12-26 12:37
Đợi đã, push và pull thật sự có thể phân biệt đơn giản như vậy sao? Thực tế không phải lúc nào cũng rõ ràng như vậy đâu
Xem bản gốcTrả lời0
DAOdreamer
· 12-26 12:35
Hệ thống động cơ kép này thực sự đáng tin cậy hơn nhiều so với việc chỉ tập trung vào tối đa hóa tham số, cuối cùng cũng có người nói rõ vấn đề này rồi
Xem bản gốcTrả lời0
rekt_but_resilient
· 12-26 12:30
Chế độ push nghe có vẻ như là việc trả phí bảo vệ, pull mới là tự do thực sự
Nhiều nhà phát triển khi tích hợp dịch vụ dữ liệu chuỗi, phản ứng đầu tiên là so sánh các tham số kỹ thuật: độ trễ bao nhiêu, có thể bao phủ bao nhiêu chuỗi, số lượng nút, chất lượng nguồn cung cấp báo giá. Nhưng những người đã từng đưa vào môi trường sản xuất đều rõ ràng rằng, cách làm này thực ra đã hơi lỗi thời.
Chọn Oracle đã không còn đơn thuần là quyết định kỹ thuật nữa, nó còn giống như một bài toán thiết kế sản phẩm: bạn muốn cung cấp trải nghiệm người dùng như thế nào, sẵn sàng chịu rủi ro loại nào, làm thế nào để kiểm soát phân bổ chi phí, trong thời điểm thị trường biến động hoặc có tranh cãi, chọn cách ứng phó ra sao. Nói ngắn gọn, cần trả lời những câu hỏi này.
Hiện nay, một số giải pháp Oracle mới bắt đầu cung cấp chế độ hai động cơ — vừa có đẩy dữ liệu chủ động, vừa có kéo dữ liệu theo yêu cầu. Ý tưởng thiết kế này thực sự rất thông minh, vì các mô hình kinh doanh khác nhau không phải là "cái này tốt, cái kia xấu", mà là "cái nào phù hợp hơn".
Lấy ZetaChain làm ví dụ, họ trình bày hai mô hình dịch vụ khá rõ ràng. Data Push là đẩy dữ liệu lên chuỗi theo lịch trình định kỳ hoặc theo ngưỡng, ưu điểm là tính thời gian thực cao, khả năng mở rộng tốt, phù hợp với những trường hợp cần cập nhật liên tục, mong muốn ổn định dự kiến. Data Pull là ứng dụng chủ động yêu cầu dữ liệu, độ trễ thấp, tần suất cập nhật linh hoạt, đặc biệt phù hợp với DEX hoặc sản phẩm DeFi — chúng cần lấy dữ liệu nhanh chóng nhưng không muốn trả thêm chi phí cho việc cập nhật liên tục.
Làm thế nào để xác định mình nên chọn cái nào? Có thể bắt đầu từ phân loại bản chất ứng dụng. Sản phẩm của bạn là "động lực trạng thái" hay "động lực giao dịch"?
Nếu bạn làm các giao thức vay mượn, kho bạc, chiến lược lợi nhuận, các logic kinh doanh tương đối ổn định, các tham số thanh lý cũng không thay đổi thường xuyên, thì thứ bạn thực sự cần là dịch vụ dữ liệu tiêu chuẩn "cung cấp ổn định, nhịp độ cập nhật dự kiến, giao diện hợp đồng rõ ràng". Trong trường hợp này, chế độ Push sẽ tiện lợi hơn — giống như cung cấp điện, nước, ga theo lịch trình cố định, chi phí và trải nghiệm sử dụng đều rất ổn định.