🌐 Ответ на обвинения в уязвимости системы смарт-контрактов EOSIO (Daniel Larimer)
Недавно появилась история о том, что EOSIO является уязвимым для того же вида багов, к которому относится баг "batchOverflow", за последнее время нанесший ущерб множеству токенов ERC-20 в сети Ethereum. Команда Chengdu LiaAn Technology Co (LianAn Tech) с помощью своей исследовательской платформы VaaS (Verification as a Service) доказала, что EOSIO является Тьюринг-полным и способным воссоздать любую логику, включая логику бага batchOverflow.
Проблема заключается не в уязвимости безопасности, как им представляется, а в плохом кодинге. Платформа смарт-контрактов никак не может предотвратить ошибки разработчиков. Такие ошибки не являются уязвимостями в системе безопасности подразумеваемой платформы.
Тем не менее, существует значительное различие в доступных опциях для тех разработчиков, которые достаточно умны, чтобы принять хорошие практики. Одной из таких опций является реализация оболочки “smart integer”, автоматически проверяющей наличие подобных оверфлоу без добавления в код лишнего шума.
К примеру, вы можете использовать checked_int64_t, как определено boost multiprecision. Простой typedef может преобразовать небезопасный код в безопасный, не выполняемый в случае оверфлоу. Комбинация шаблонов c++ и перегрузки операторов означает, что использование безопасной математики и небезопасной математики будет одинаково беспрепятственно.
Любая платформа, обязывающая разработчиков всегда использовать “безопасную математику”, также ограничивает гибкость разработчика и/или производительность в той ситуации, когда желательно наличие оверфлоу.
На практике известно много случаев, когда простого предотвращения оверфлоу на типах стандартного размера недостаточно. Что делать, если вы хотите иметь безопасный int, который удерживает все значения в определенном диапазоне? С помощью шаблонов c++ можно создать ограниченный целочисленный класс. Нет простого способа получить тот же проверенный временем компиляции код на таких простых языках, каким является Solidity.
Сравнение платформ
Если кто-то хочет сравнить платформы, то им следует взглянуть на инструменты безопасности и удобочитаемости, доступные для разработчиков, решивших воспользоваться ими и сравнить качество на основе лучших практик. На Solidity вы вынуждены использовать нечитаемые функции, чтобы обернуть всю математику. Потеря читаемости из-за невозможности использовать встроенных операторов для +/- * так же плоха для безопасности, как и отсутствие проверок пределов.
Другой фактор, который следует учитывать – это производительность выполнения различных мер безопасности. Компиляторы на C++ часто могут выполнять проверку времени компиляции, оптимизировать и встраивать большинство математических проверок в минимальную необходимую сборку. Подобные проверки в таких языках, как Solidity, заставляют использовать вызовы функций и не имеют возможности встраивать код по причине незрелости инструментов для разработки по сравнению с доступными инструментами C++, проверенными в бою.
Возможность обновления кода
В недавнем твите о баге “batchOverflow” я подчеркнул, что разработчики отнюдь не идеальны, и что код должен быть обновлен. Хорошая платформа по умолчанию сделает обновления простыми, а не сложными. Пользователей стоит обязать недвусмысленно отметить контракт как необратимый. Кроме того, даже контракты, помеченные их создателем как необратимые, должны иметь возможность изменения сообществом без применения хардфорка.
Безответственное составление отчетности
Команда LianAn Tech и другие блоггеры, высказавшиеся по этому вопросу, использовали подмену тезиса как аргумент против EOSIO. Результатом их безответственно составленной отчетности является введение в заблуждение тех, кто не понимает нюансов технологии. Нам, как отрасли, нужны люди, способные видеть точную разницу между уязвимостью в безопасности (платформа не ведет себя так, как задумано), ошибкой пользователя (разработчики используют платформу неправильно) и фундаментальным недостатком дизайна платформы (платформа не дает разработчикам инструментов для самозащиты).
EOSIO разработан для того, чтобы дать разработчикам самый надежный набор инструментов для написания высокопроизводительных, высококачественных контрактов с малым количеством багов, а также обеспечить платформе и контрактам благополучное восстановление в случае неудачи.
Оригинал поста: ЗДЕСЬ