В основе DeFi-сервисов лежит публичный компьютерный код, известный как смарт-контракт. Его реализация, впервые описанная Ником Сабо в статье 1997 года[88], является принципиально новой с точки зрения инженерной практики, поэтому методы устранения программных ошибок смарт-контрактов пока что находятся на стадии совершенствования. Недавние взломы сервисов DForce и bZx наглядно показали программную хрупкость смарт-контрактов, вследствие чего данный пробел в экспертизе смарт-контрактов начали заполнять аудиторские фирмы, такие как, например, Quantstamp, Trail of Bits и Peckshield[89].
Риск смарт-контракта может иметь вид логической ошибки в программном коде или экономического эксплойта, который способен причинить финансовый ущерб, например, позволяя злоумышленнику вывести средства в сумме, превышающей ту, что была предусмотрена функциональностью платформы. В первом случае речь может идти о любой типичной программной ошибке. Рассмотрим эту ситуацию на следующем примере. Пусть имеется смарт-контракт, предназначенный для условного депонирования активов ERC-20 неких пользователей и перевода всего баланса победителю лотереи. Данный контракт отслеживает количество содержащихся в нем токенов и использует это число в качестве суммы перевода. Представим, что из-за ошибки округления в нашем гипотетическом контракте это число немного превышает фактическое количество токенов. Если контракт попытается перевести эту превышающую лимит сумму, произойдет сбой. В случае отсутствия защитных механизмов, которые позволяют обработать данную ситуацию, токены попросту заблокируются внутри протокола. На профессиональном жаргоне такие средства иногда называются «замурованными», потому что их нельзя вернуть обратно.
Экономический эксплойт работает иначе. В данном случае речь идет не о явной ошибке в логике кода, а о возможности для злоумышленника, обладающего необходимыми финансовыми ресурсами, повлиять на рыночные условия, чтобы получить «незаконный» доход за счет контракта. Для иллюстрации этого типа риска смарт-контракта рассмотрим следующий пример. Представим, что у нас есть контракт, который выполняет роль биржи для обмена двух токенов по курсу, слегка отличающемуся от обменного курса другого аналогичного контракта, выступающего в роли ценового оракула. Если биржа-оракул обладает значительно более низкой ликвидностью, чем основная биржа в нашем примере, открывается возможность для применения экономического эксплойта. Финансово обеспеченный злоумышленник может продать токены на большую сумму на бирже-оракуле, чтобы понизить цену, а затем купить гораздо большее их количество на основной бирже, чтобы извлечь выгоду из движения цены. Суть заключается в том, что злоумышленник может понизить цену на бирже с высокой ликвидностью, манипулируя биржей-оракулом с низкой ликвидностью.
Экономические эксплойты выглядят еще более коварными, если учесть существование флеш-кредитов, которые позволяют любому участнику Ethereum приобрести большой объем средств для проведения одной транзакции. При создании протоколов разработчикам следует быть особенно внимательными к деталям, чтобы в системе не было лазеек для манипулирования протоколом с помощью большой рыночной волатильности в рамках одной транзакции. Экономический эксплойт, предусматривающий использование флеш-кредита, называется