Что такое смарт-контракт и что может пойти не так?

Смарт-контракт — один из наиболее вводящих в заблуждение терминов в крипто, поскольку он заимствует юридическое слово для явления, которое, строго говоря, не является контрактом. Это программа, хранящаяся в блокчейне, которая выполняется автоматически при соблюдении определённых условий, без участия банка, брокера или суда. Именно эта автоматизация привлекательна — и она же источник большей части риска. В этом материале объясняется, что на самом деле делает смарт-контракт, где эта идея применяется на практике и каковы основные категории сбоев, когда код ведёт себя не так, как задумывали его авторы.

Что такое смарт-контракт на самом деле

Если отбросить название, смарт-контракт — это программное обеспечение, развёрнутое в блокчейне, чаще всего в Ethereum или аналогичной программируемой сети. После развёртывания его код находится по фиксированному адресу и, как правило, не может быть изменён, если только разработчики заранее не встроили конкретный механизм обновления. Любой может отправить ему транзакцию, и сеть валидаторов исполняет код в точности так, как он написан, обновляя в результате общее состояние блокчейна. Тут нет службы поддержки клиентов, и в большинстве случаев нет способа отменить результат после его подтверждения.

Это принципиально отличается от традиционного соглашения. Бумажный контракт описывает намерение на естественном языке, и суд или арбитр интерпретирует это намерение в случае спора. У смарт-контракта нет интерпретатора. Он делает в точности то, что говорит его код, даже когда это резко расходится с тем, что предполагали стороны. Фраза «код — это закон» (the code is law), популярная на заре Ethereum, отражает это буквально: результат — это то, что вычисляет программа, а не то, что кто-то считает справедливым. На практике у этой идеи есть реальные пределы, которые рассматриваются в следующих разделах материала.

Где смарт-контракты применяются на практике

Концепция звучит абстрактно, пока её не привязать к конкретным примерам. Три сценария использования составляют бо́льшую часть активности в программируемых блокчейнах сегодня.

• Свопы на децентрализованных биржах. Протоколы, построенные на архитектуре автоматических маркет-мейкеров, позволяют пользователям обменивать один токен на другой напрямую против объединённого резерва, где обменный курс задаётся формулой, а не книгой заявок. Смарт-контракт держит средства и исполняет своп одной транзакцией.
• Кредитование и заимствование. DeFi-протоколы кредитования используют смарт-контракты для приёма залога, выдачи кредитов, учёта процентов и, если стоимость залога падает слишком сильно, запуска автоматической ликвидации — всё это без участия кредитного специалиста, рассматривающего заявку.
• Выпуск токенов. Большинство токенов помимо нативного актива блокчейна, включая большинство активов, построенных на Ethereum, сами являются смарт-контрактами, определяющими предложение, правила передачи и записи о владении.

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

Практические границы принципа «код — это закон»

Отношение к коду как к последнему слову звучит чисто в теории, но сталкивается с трением, как только код расходится с тем, что предполагали люди. Широко цитируемый пример — крах в 2016 году проекта под названием The DAO, где злоумышленник использовал изъян в логике контракта, чтобы вывести значительную долю объединённых средств с помощью функций, которые технически работали в точности так, как были написаны. Реакция сообщества Ethereum — спорный раскол сети, породивший Ethereum и Ethereum Classic, — остаётся наглядной иллюстрацией того, что «код — это закон» — это философия дизайна, а не закон физики. Когда результат достаточно разрушителен, участники всё же могут выбрать вмешательство на уровне базовой сети.

За пределами таких крайних случаев более распространённое противоречие тише. Контракт может исполниться безупречно и всё же дать результат, которого никто не хотел, потому что код не предусмотрел конкретную последовательность транзакций, конкретное рыночное условие или конкретную комбинацию входных данных. Как правило, для этого не предусмотрено встроенного процесса апелляции.

Что может пойти не так: основные категории

Сообщения о сбоях смарт-контрактов, как правило, попадают в несколько повторяющихся категорий, и различать их важно, поскольку они требуют разного уровня проверки, прежде чем полагаться на протокол.

• Ошибки и эксплойты. Изъяны в самом коде — например, неверные механизмы контроля доступа, переполнение целых чисел или логика, позволяющая вызывать функцию в непредусмотренном порядке (шаблон, лежащий в основе многих эксплойтов реентерабельности), — могут позволить злоумышленнику вывести средства или несанкционированно выпустить токены. Это ошибки программирования, и после того как контракт запущен и неизменяем, их часто трудно или невозможно исправить.
• Манипуляция оракулами. Смарт-контракты не видят ничего за пределами собственного блокчейна. Когда контракту нужны внешние данные, например цена актива, он полагается на службу «оракула», подающую эту информацию. Если злоумышленник может исказить цену, которую сообщает оракул, даже ненадолго, он может обмануть кредитный или торговый контракт, заставив его действовать на основе ложной информации, — техника, стоящая за рядом громких потерь в DeFi.
• Риск административного ключа и обновлений. Многие контракты изначально включают «чёрный ход»: ключ администратора или мультиподписной кошелёк, способный приостановить контракт, изменить параметры или обновить код. Эта гибкость помогает командам быстро исправлять ошибки, но также означает, что система не полностью автономна. Если этот ключ скомпрометирован или команда, которая его держит, действует злонамеренно, пользователи несут убытки, никак не связанные с изъяном в основной логике.
• Изъяны экономического дизайна. Не каждый сбой — ошибка кода. Контракт может быть реализован в точности так, как задумывалось, и всё же дать сбой, потому что его экономические допущения оказались неверными — например, стимулирующая структура работает в обычных условиях, но ломается при экстремальной волатильности или дефиците ликвидности. Эту категорию сложнее проверить аудитом, поскольку код не «содержит ошибок» в техническом смысле — просто базовая модель поведения участников оказалась неполной.

Аудиты, программы вознаграждения за уязвимости и их пределы

Учитывая эти риски, большинство серьёзных проектов заказывают аудит безопасности сторонней компанией перед запуском, а многие ведут постоянные программы bug bounty, выплачивающие независимым исследователям вознаграждение за сообщения об уязвимостях. Обе практики ощутимо снижают риск. Аудит, проведённый опытной фирмой, как правило, выявляет распространённые шаблоны ошибок, а хорошо профинансированная программа bug bounty даёт «белым» хакерам финансовый стимул находить изъяны раньше злоумышленников.

Ни то, ни другое не является гарантией. Аудит — это проверка кода в том виде, в каком он существовал в конкретный момент времени, проведённая в рамках временных и бюджетных ограничений, и он не может доказать отсутствие абсолютно всех возможных изъянов — только отсутствие тех изъянов, которые рецензенты догадались проверить. Контракты, прошедшие несколько аудитов, всё равно подвергались эксплуатации — иногда через уязвимость за пределами проверенной области, иногда через экономическую атаку, а не ошибку на уровне кода. Отношение к значку аудита как к сертификату безопасности, а не как к одному из нескольких входных данных, — распространённая и дорогостоящая ошибка.

Для любого, кто использует протокол, построенный на смарт-контрактах, разумный минимум включает проверку того, проходил ли контракт аудит, кем, как давно, существует ли административный ключ и кто его контролирует, а также как протокол справлялся со стрессовыми ситуациями в прошлом. Ничто из этого не устраняет риск полностью, но заменяет слепое доверие обоснованным суждением, что и есть более реалистичный стандарт, на который вообще способны смарт-контракты. Читателям, вырабатывающим эту привычку применительно ко всему портфелю, может быть полезна более широкая система оценки риска — например, изложенная в методологии roo2ya — как отправная точка, наряду с общими исследовательскими практиками, такими как DYOR.

Этот материал носит исключительно информационный характер и не является финансовой консультацией.