Багато розробників при підключенні до сервісів даних на блокчейні першою реакцією є порівняння технічних параметрів: яка затримка, скільки ланцюгів охоплює, кількість вузлів, якість джерел цін. Але ті, хто вже працював у виробничому середовищі, добре знають, що цей підхід насправді трохи застарів.

Вибір Oracle давно вже перестав бути чисто технічним рішенням — це більше питання продуктового дизайну: який користувацький досвід ви прагнете надати, які ризики готові взяти на себе, як контролювати розподіл витрат, як реагувати у випадках аномалій або суперечливих ситуацій. По суті, потрібно відповісти на кілька ключових питань.

Зараз деякі нові рішення Oracle починають пропонувати двовекторний режим — з активним пушем і запитом за потребою. Такий підхід досить розумний, оскільки різні бізнес-моделі не стосуються просто "цей хороший, той поганий", а скоріше "який краще підходить".

Наприклад, ZetaChain пояснює дві моделі сервісів досить просто. Data Push — це періодичне або за пороговим значенням передавання даних у ланцюг, переваги — висока реальність, хороша масштабованість, підходить для сценаріїв, що потребують постійного оновлення та стабільних очікувань. Data Pull — це активний запит даних застосунком, з низькою затримкою та гнучкою частотою оновлень, особливо підходить для DEX або DeFi продуктів — їм потрібно швидко отримувати дані, але вони не хочуть додаткових витрат на постійне оновлення.

Як визначити, який варіант обрати? Можна почати з класифікації за сутністю застосунку. Ваш продукт — "стан-орієнтований" чи "транзакційно-орієнтований"?

Якщо ви працюєте з кредитними протоколами, сейфами, стратегічними прибутками — бізнес-логіка відносно стабільна, параметри ліквідації не змінюються часто, тоді вам справді потрібен стандартний сервіс даних, який "стабільно постачає, оновлюється передбачувано, інтерфейс контракту чіткий". У такому випадку режим Push буде більш зручним — як з водою, електрикою, газом: за встановленим графіком, з стабільними витратами та досвідом користування.