Концепция смарт-контрактов была впервые описана Ником Сабо в 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 больше не было общеизвестного механизма защиты безопасности для устранения этих уязвимых контрактов.
Блудные, жадные, суицидальные — основные характеристики смарт-контрактов эфира?
В начале 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).
Делая выводы своей работы, исследователи пришли к довольно неутешительному итогу.
Будут ли решены проблемы?
Очевидно, что из-за человеческого фактора, связанного с применением в Ethereum Solidity, и рядом других проблем, которые, скорее всего, не исчезнут даже после нахождения и устранения всех багов, недостатки у смарт-контрактов Ethereum, конечно же, останутся. Тем не менее минимизировать их вполне реально. Команда уже начала вводить Vyper — похожий на Solidity, но более легкий в использовании язык. К тому же, Ethereum 2.0 уже не за горами — в 2018 году блокчейн-сообщество увидит «вторую фазу» взросления системы. Может быть, именно эти меры приведут к решению основных проблем ее смарт-контрактов?
Будь в курсе! Подписывайся на Криптовалюта.Tech в Telegram.
Обсудить актуальные новости и события на Форуме