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

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

Та ще й підводні камені знизу — раптові великі ліквідації, незрозумілі ціни розрахунку, швидка втрата ліквідності в сейфі, але при цьому все ще відбувається ребалансування… Ви дивитеся на логіку контракту — все гаразд, виконання йде гладко, але результат — хаос. Часто справді проблема не в самому контракті, а в тому, що так званий "реальний світ", який він "бачить", вже сам по собі збої.

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