Останні кілька років мене мучили оракулські гонорари. Наш середній за розміром угода має щомісячний дохід лише від 20 000 до 30 000 доларів США, а вартість оновлення даних становить 8 000 доларів США. Тоді я думав, як це може бути використання оракула, адже це явно кидає гроші.
Найболючіше — це механізм штовхання Chainlink. Його логіка дуже жорстка — незалежно від того, чи потрібні дані вашому проєкту в цей момент, система просто хоче передати інформацію до ланцюга у фіксований час, і плата за газ збирається відповідно. У ті дні, коли ринок не коливався, я спостерігав, як незмінні ціни фіксуються знову і знову, думаючи, скільки грошей це витратить даремно.
Три місяці тому я вирішив спробувати переключити весь оракул на іншу механіку pull. Найбільша перевага цього рішення особливо очевидна — ви викликаєте дані лише тоді, коли вони дійсно потрібні, і не переміщуєте їх, коли вони не потрібні. Ця зміна безпосередньо знизила вартість нашого оракула більш ніж на 60%. Іншими словами, заощаджених за три місяці коштів достатньо, щоб залучити ще одного штатного розробника.
Чесно кажучи, ця конверсія — це не жарти і включає низку процесів, таких як переписування, тестування та запуск базового коду. Але коли переваги справді проявляються, це відчуття...... Ентузіазм усієї команди з'явився. Фінансовий тиск не лише знімається, а й ресурси розробки можна більше інвестувати у функціональну версію самого протоколу.
Зараз, озираючись назад, справа не в тому, наскільки потужним є oracle-рішення, а в тому, щоб знайти найкращий інструмент для фази вашого проєкту. Для невеликих команд ефективність витрат іноді важливіша за славу.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
4
Репост
Поділіться
Прокоментувати
0/400
WalletAnxietyPatient
· 21год тому
Чорт, ця система Chainlink — це просто обман для новачків, платиш за автоматичні повідомлення, а ринок навіть не рухається, а вона все одно наполегливо тисне.
Переглянути оригіналвідповісти на0
NFTArchaeologis
· 22год тому
Це все одно, що з епохи пасивного переписування нарешті навчилися використовувати за потребою... Зменшити витрати на 60% — це переписати рівняння виживання.
Переглянути оригіналвідповісти на0
ChainWallflower
· 22год тому
60%?Блін, серйозно? Скільки ж це потрібно економити Gas-фі?
Переглянути оригіналвідповісти на0
LiquidationAlert
· 22год тому
Ого, зменшення витрат на 60% — це справжня оптимізація
Останні кілька років мене мучили оракулські гонорари. Наш середній за розміром угода має щомісячний дохід лише від 20 000 до 30 000 доларів США, а вартість оновлення даних становить 8 000 доларів США. Тоді я думав, як це може бути використання оракула, адже це явно кидає гроші.
Найболючіше — це механізм штовхання Chainlink. Його логіка дуже жорстка — незалежно від того, чи потрібні дані вашому проєкту в цей момент, система просто хоче передати інформацію до ланцюга у фіксований час, і плата за газ збирається відповідно. У ті дні, коли ринок не коливався, я спостерігав, як незмінні ціни фіксуються знову і знову, думаючи, скільки грошей це витратить даремно.
Три місяці тому я вирішив спробувати переключити весь оракул на іншу механіку pull. Найбільша перевага цього рішення особливо очевидна — ви викликаєте дані лише тоді, коли вони дійсно потрібні, і не переміщуєте їх, коли вони не потрібні. Ця зміна безпосередньо знизила вартість нашого оракула більш ніж на 60%. Іншими словами, заощаджених за три місяці коштів достатньо, щоб залучити ще одного штатного розробника.
Чесно кажучи, ця конверсія — це не жарти і включає низку процесів, таких як переписування, тестування та запуск базового коду. Але коли переваги справді проявляються, це відчуття...... Ентузіазм усієї команди з'явився. Фінансовий тиск не лише знімається, а й ресурси розробки можна більше інвестувати у функціональну версію самого протоколу.
Зараз, озираючись назад, справа не в тому, наскільки потужним є oracle-рішення, а в тому, щоб знайти найкращий інструмент для фази вашого проєкту. Для невеликих команд ефективність витрат іноді важливіша за славу.