Что не так со смарт-контрактами Ethereum?
Концепция смарт-контрактов была впервые описана Ником Сабо в 1996 году. «Цифровая революция стала возможной благодаря новым институтам и новым способам формализации отношений, составляющих эти институты. Я называю эти новые контракты “умными”, потому что они гораздо более функциональны, чем их неодушевленные предки, основанные на бумаге. Не подразумевается использование искусственного интеллекта. Смарт-контракт — это набор обещаний, указанных в цифровой форме, включая протоколы, в которых стороны выполняют эти обещания», — описал он свою идею. Но не все так гладко: столь масштабные идеи неизменно влекут за собой ошибки и неточности. Какие проблемы в смарт-контрактах одного из самых больших и старых блокчейнов уже обнаружены?
Что не так с Ethereum?
Спустя 20 с лишним лет абстрактная идея смарт-контрактов воплотилась в реальность. Потенциал, присущий смарт-контрактам, огромен. Зарождающаяся технология может использоваться для проверки подлинности, безопасного обмена данными, а также для управления токенами и привлечения средств при ICO. Так, блокчейн Ethereum, одна из первых площадок, реализовавших смарт-контракты в своем блокчейне, имеет более 1500 децентрализованных приложений, каждое из которых использует смарт-контракты для выполнения самых разных задач. Однако проблема со смарт-контрактами заключается в том, что они основаны на коде, и некоторые ошибки в нем могут стать в буквальном смысле катастрофическими.
По мнению ряда экспертов, у Ethereum есть «родовая травма», поскольку его блокчейн в значительной степени построен в Solidity — продвинутом языке программирования. Таким образом, многие разработчики должны изучить совершенно новый язык, что увеличивает вероятность человеческой ошибки.
Ошибки BatchOverflow
И такого рода ошибки не заставили себя ждать. 23 апреля 2018 года компания PeckShield, занимающаяся безопасностью на блокчейне, заявила о нахождении ошибки BatchOverflow сразу в нескольких смарт-контрактах ERC20.
Разработчики создали аналитический алгоритм переносов токенов ERC-20. Система предназначена для автоматического уведомления о подозрительных транзакциях. В итоге «улов» не заставил себя долго ждать — программа издала тревожный сигнал, увидев странную транзакцию токена BEC. В этой сделке было перечислено запредельное количество токенов BEC — 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,00)
Такая необычная транзакция побудила разработчиков посмотреть код смарт-контракта. В ходе исследования выяснилось, что такая передача может стать следствием атаки «in-the-wild», которая воспользовалась ранее неизвестной уязвимостью в контракте (batchOverflow).
Уязвимая функция располагалась в batchTransfer. В строке 257 видно, что локальная переменная суммы находится с помощью умножения cnt и _value. Вторая же переменная (_value) может и вовсе быть рандомным 256-битным целым числом (к примеру, 0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,00).
Таким образом, имея в своем распоряжении два _receivers, отправленных в batchTransfer (), с этим чрезвычайно большим значением, мы можем переполнить сумму и сделать ее равной нулю. В случае обнуления злоумышленник может спокойно пройти проверки работоспособности в строках 258−259, после чего сделать вычитание в строке 261 абсолютно неактуальным.
В итоге, как продемонстрировано в строках 262−265, баланс двух кошельков пополнится огромной суммой. Интересно, что, по словам разработчиков, на тот момент более десятка контрактов ERC20 были также уязвимы для batchOverflow.
По словам команды, тогда они уже перепробовали все возможные способы связи с разработчиками, однако после введения принципа «кодекс-закон» в блокчейне Ethereum больше не было общеизвестного механизма защиты безопасности для устранения этих уязвимых контрактов. «Наличие нецентрализованных обменов с автономными торговыми услугами может вызвать дополнительные проблемы, поскольку они даже не могут остановить атакующих от отмывания своих токенов. С другой стороны, мы можем столкнуться с дополнительными серьезными сложностями. В частности, очень вероятно, что злоумышленник обладает огромным количеством токенов, используя эти уязвимые контракты. Что если они перейдут на возможность обмена криптовалюты и торговли этими токенами для ETH, BTC или даже USD?», — задалась тогда вопросом обнаружившая баг команда.
Блудные, жадные, суицидальные — основные характеристики смарт-контрактов эфира?
В начале 2018 года пятеро исследователей из Великобритании и Сингапура с помощью созданного ими инструмента MAIAN, служащего для обнаружения уязвимостей непосредственно через байт-код и не требующего доступ к исходному коду, нашли 34,200 смарт-контрактов, которые могут иметь потенциальные баги и хранят в себе информацию о транзакциях на сумму в несколько миллионов долларов в эфире.
Они разделили уязвимые контракты на условные три группы: суицидальные, блудные и жадные.
Блудные контракты
Функция tap блокирует эфир, поскольку условие в строке 4 никогда не может быть выполнено. Тем не менее оптимизация компилятора Solidity позволяет этому произойти, когда для вызова функции используется вход более 20 байтов. На уровне байтового кода EVM сможет загрузить только куски из 32 байт входящих данных. В строке 3 при нажатии первые 20 байт присваиваются переменной prev, а остальные 12 байт просто игнорируются. Такая ошибка возникает, поскольку EVM в строке 4 аккуратно сводит на нет 12 байт prev. Этот контракт потерял 5.0001 эфира с разных адресов в блокчейне Ethereum.
Суицидальные контракты
Контракт может быть убит путем использования незащищенной инструкции SUICIDE. Тривиальный пример — это функция общественного уничтожения, в которой размещается инструкция suicide. Иногда SUICIDE защищен слабым условием. Этот контракт позволяет пользователям покупать токены или выводить свои средства. Логика вывода средств осуществляется функцией вывода. Однако эта функция имеет инструкцию self_destruct, которая может быть выполнена в случае, если последние средства были внесены в него более 4 недель назад. Следовательно, если «инвестор» вызывает эту функцию через 4 недели после последнего вложения, все средства идут к владельцу контракта, и все записи «инвесторов» стираются с блокчейна.
Жадные контракты
Контракт SimpleStorage является примером контракта, который блокирует эфир в неограниченных объемах. Если произвольный адрес отправляет эфир вместе с транзакцией, которая вызывает функцию set, баланс контракта увеличивается пропорционально количеству отправленного эфира. Когда произвольный адрес отправляет эфир вместе с транзакцией, вызывающей функцию set, баланс контракта увеличивается на количество отправленного эфира. Однако в контракте нет инструкций по выпуску эфира, и, таким образом, он блокирует его на блокчейне.
Ключевое слово payable было введено в Solidity не так давно, чтобы предотвратить принятие функциями эфира по умолчанию — функции, не имеющие ключевого слова payable, не выполняются, если в ходе транзакции пересылается эфир. Однако, хотя этот контракт не имеет никакой функции, связанной с payable, он принимает эфир, поскольку он был скомпилирован более старой версией компилятора Solidity (без поддержки payable).
Делая выводы своей работы, исследователи пришли к довольно неутешительному итогу. «Анализируя 970,898 контрактов, наш новый инструмент MAIAN нашел тысячи уязвимых контрактов. Кроме того, 6239 эфиров (около $5.6 миллиона) заперты в посмертных контрактах, которые в настоящее время находятся на блокчейне, из которых 313 эфиров были отправлены в мертвые контракты после их убийства», — резюмировали они.
Будут ли решены проблемы?
Очевидно, что из-за человеческого фактора, связанного с применением в Ethereum Solidity, и рядом других проблем, которые, скорее всего, не исчезнут даже после нахождения и устранения всех багов, недостатки у смарт-контрактов Ethereum, конечно же, останутся. Тем не менее минимизировать их вполне реально. Команда уже начала вводить Vyper — похожий на Solidity, но более легкий в использовании язык. К тому же, Ethereum 2.0 уже не за горами — в 2018 году блокчейн-сообщество увидит «вторую фазу» взросления системы. Может быть, именно эти меры приведут к решению основных проблем ее смарт-контрактов?