Останнім часом прогнозний ринок набирає таку популярність, що я вирішив дослідити рішення різних провайдерів оракулів. Адже точність даних у блокчейні безпосередньо впливає на успіх торгівлі і має велике значення для управління позиціями. Після деякого часу експериментів з рішенням APRO я зрозумів, що у нього є дійсно варто уваги особливості, і сьогодні поділюся своїми враженнями від практичного використання.
Причина, через яку я почав звертати увагу на нього, досить реальна — раніше я користувався одним із провідних сервісів оракулів. Чесно кажучи, як стандарт у галузі він дійсно стабільний і надійний, але ціна була дуже високою. За кожен виклик даних потрібно було платити, і при частих торгах витрати швидко зростали. Згодом я дізнався, що APRO підтримує pull-модель — механізм викликів за потребою, що робить структуру цін значно більш дружньою, і я вирішив спробувати.
У день підключення я мушу сказати, що їхня технічна документація досить хороша — вона значно ясніша, ніж очікував. Інтерфейс Live-API зроблений дуже просто: можна безпосередньо отримати цінові дані та підписи, а потім перевірити їх у ланцюгу. Я запустив тестовий контракт на BNB Chain, викликав функцію verifyAndReadLatestPrice, і весь процес пройшов гладко. Затримка також була цілком прийнятною, вона задовольняє вимоги DEX і протоколів кредитування щодо актуальності даних.
Але тут потрібно зробити зауваження: хоча рекламовано підтримку понад 40 ланцюгів, насправді інформація про адреси контрактів для деяких ланцюгів неповна. Наприклад, щоб розгорнути на Base, довелося довго шукати і запитувати у спільноті правильну адресу VerifierProxy. Цю частину документації потрібно швидко покращити, інакше досвід розробників суттєво постраждає.
З точки зору функціональності, мульти-ланцюгова сумісність і оптимізація витрат у APRO — правильний напрямок, особливо для сценаріїв високочастотної торгівлі. Однак цілісність документації та інструментарій для розробки ще потребують доопрацювання.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
6
Репост
Поділіться
Прокоментувати
0/400
BoredApeResistance
· 11год тому
Вартість дійсно є основною статтею витрат, раніше ті старі провісники справді не витримували навантаження
---
Відсутність інформації про адресу Base трохи дратує, потрібно швидше доповнити документацію
---
Ідея моделі pull хороша, оплата за потребою набагато зручніша для високочастотних трейдерів
---
Показники затримки досить хороші, в критичні моменти дані мають бути надійними, інакше управління позиціями буде повністю хаосом
---
Підтримка понад сорока ланцюгів звучить дуже заманливо, але без повних деталей досвід розробки може суттєво постраждати
---
Дизайн Live-API досить простий, цю похвалу заслуговує APRO
---
Здається, це та сама стара проблема: на початку активно просували, але при реальному використанні виявляються різні підводні камені
---
Провісники зараз дуже конкуренційні, але дружелюбність до витрат дійсно є важливим аспектом
Переглянути оригіналвідповісти на0
RektButSmiling
· 18год тому
Оптимізація витрат дійсно влучає у ціль, поведінка провідних організацій виглядає дуже непривабливо
Кажучи про адресу Base, її потрібно шукати самостійно, це справді дуже Web3
У сценаріях високочастотної торгівлі ця модель все ще має сенс
Недосконалість документації навпаки є можливістю, екосистема ще на ранній стадії
Переглянути оригіналвідповісти на0
MidnightGenesis
· 19год тому
Дані з ланцюга показують, що витрати на модель pull дійсно можна знизити, але цікаво, що інформація про адреси 40 ланцюгів неповна... З коду видно, що офіційні особи, можливо, ще не продумали повну розгортку по всьому ланцюгу
Переглянути оригіналвідповісти на0
MemeCoinSavant
· 19год тому
Отже, фактично оплата за кожен виклик на старому оракулі була просто копінгом, а модель витягування APRO має інший рівень... але документація з розгортання Base, яка є кривою, — це вершина енергії "підтримується 40 ланцюгів" ngl 💀
Переглянути оригіналвідповісти на0
ResearchChadButBroke
· 19год тому
Оптимізація витрат дійсно влучила у болючу точку, але справа з Base показує, що все одно доведеться самим наступати на граблі
Переглянути оригіналвідповісти на0
gaslight_gasfeez
· 19год тому
Витрати можна зменшити наполовину, цього достатньо, щоб я вклався, все інше легко вирішується
Останнім часом прогнозний ринок набирає таку популярність, що я вирішив дослідити рішення різних провайдерів оракулів. Адже точність даних у блокчейні безпосередньо впливає на успіх торгівлі і має велике значення для управління позиціями. Після деякого часу експериментів з рішенням APRO я зрозумів, що у нього є дійсно варто уваги особливості, і сьогодні поділюся своїми враженнями від практичного використання.
Причина, через яку я почав звертати увагу на нього, досить реальна — раніше я користувався одним із провідних сервісів оракулів. Чесно кажучи, як стандарт у галузі він дійсно стабільний і надійний, але ціна була дуже високою. За кожен виклик даних потрібно було платити, і при частих торгах витрати швидко зростали. Згодом я дізнався, що APRO підтримує pull-модель — механізм викликів за потребою, що робить структуру цін значно більш дружньою, і я вирішив спробувати.
У день підключення я мушу сказати, що їхня технічна документація досить хороша — вона значно ясніша, ніж очікував. Інтерфейс Live-API зроблений дуже просто: можна безпосередньо отримати цінові дані та підписи, а потім перевірити їх у ланцюгу. Я запустив тестовий контракт на BNB Chain, викликав функцію verifyAndReadLatestPrice, і весь процес пройшов гладко. Затримка також була цілком прийнятною, вона задовольняє вимоги DEX і протоколів кредитування щодо актуальності даних.
Але тут потрібно зробити зауваження: хоча рекламовано підтримку понад 40 ланцюгів, насправді інформація про адреси контрактів для деяких ланцюгів неповна. Наприклад, щоб розгорнути на Base, довелося довго шукати і запитувати у спільноті правильну адресу VerifierProxy. Цю частину документації потрібно швидко покращити, інакше досвід розробників суттєво постраждає.
З точки зору функціональності, мульти-ланцюгова сумісність і оптимізація витрат у APRO — правильний напрямок, особливо для сценаріїв високочастотної торгівлі. Однак цілісність документації та інструментарій для розробки ще потребують доопрацювання.