" В экосистеме Ethereum по-прежнему наблюдается всплеск активности: отдельные лица и организации развертывают контракты на токены, добавляют ликвидность в пулы и развертывают смарт-контракты для поддержки широкого спектра бизнес-моделей. При этом протоколы децентрализованных финансов (DeFi) остаются уязвимыми для взломов и мошенничества.
Например, недавние данные аналитической компании Chainalysis показывают, что с начала января по июль 2022 года количество взломов, связанных с криптовалютами, увеличилось на 58,3%.
Хотя открытый исходный код полезен для индустрии блокчейнов, он, к сожалению, может быть легко изучен киберпреступниками в поисках эксплойтов. Аудит безопасности для смарт-контрактов направлен на решение этих проблем, но эта процедура не соответствует отраслевым стандартам, что создает сложность.
Отраслевой стандарт для обеспечения безопасности смарт-контрактов
Крис Корди, председатель рабочей группы по уровням безопасности EthTrust в Enterprise Ethereum Alliance (EEA), заявил, что по мере роста индустрии блокчейнов Ethereum возрастает потребность в зрелой структуре для оценки безопасности смарт-контрактов.
Чтобы решить эту проблему, Корди вместе с несколькими представителями членов EEA, обладающими опытом аудита и безопасности, в ноябре 2020 года помог создать рабочую группу по уровням безопасности EthTrust. С тех пор организация работает над проектом документа спецификации смарт-контракта или отраслевого стандарта, направленного на повышение безопасности смарт-контактов.
Совсем недавно рабочая группа объявила о публикации спецификации уровней безопасности EthTrust v1. Чаалс Невил, технический программный директор EEA, сообщил, что эта спецификация описывает уязвимости смарт-контрактов, которые требуются для надлежащего аудита безопасности в качестве минимальной меры качества:
«Это относится ко всем платформам смарт-контрактов на основе EVM, где разработчики используют Solidity в качестве языка программирования. Согласно недавнему анализу Splunk, это более 3/4 контрактов основной сети. Но есть также частные сети и проекты, основанные на стеке технологий Ethereum, но использующие собственный блокчейн. Эта спецификация так же полезна для них, как и для пользователей основной сети, она помогает защитить их работу».
Новая спецификация описывает три уровня тестов, которые организации должны учитывать при проведении аудита безопасности смарт-контрактов.
«Уровень [S] разработан таким образом, что в большинстве случаев, когда общие функции Solidity используются по хорошо известным шаблонам, тестируемый код может быть сертифицирован с помощью автоматизированного инструмента «статического анализа», — сказал Невил.
Тест уровня [M] требует более строгого статического анализа, он включает в себя требования, при которых ожидается, что человек-аудитор определит, необходимо ли использование функции или обосновано ли заявление о свойствах безопасности кода.
Тест уровня [Q] обеспечивает анализ бизнес-логики, реализованной в тестируемом коде.
«Это делается для того, чтобы убедиться, что код не содержит известных уязвимостей безопасности, а также убедиться, что он правильно реализует заявленное», — сказал Невил.
Существует также необязательный тест «рекомендуемая передовая практика», который может помочь повысить безопасность смарт-контрактов:
«Использование последней версии компилятора является одним из «рекомендуемых передовых методов». В большинстве случаев это довольно просто, но есть много причин, по которым контракт мог не быть развернут с последней версией. Другие передовые методы включают сообщение о новых уязвимостях, чтобы их можно было устранить в обновлении спецификации, и написании чистого, легко читаемого кода».
Всего во всей спецификации содержится 107 требований. Около 50 из них относятся к требованиям уровня [S], возникающим из-за ошибок в компиляторах Solidity.
Поможет ли отраслевой стандарт организациям и разработчикам?
Спецификация уровней безопасности EthTrust в конечном счете направлена на то, чтобы помочь аудиторам продемонстрировать клиентам, что они работают на отраслевом уровне.
Ронгуи Гу, генеральный директор и соучредитель компании CertiK, занимающейся безопасностью блокчейнов, заявил, что наличие таких стандартов помогает обеспечить ожидаемые процессы и рекомендации. Однако он отметил, что такие стандарты ни в коем случае не являются «штампом», указывающим на то, что смарт-контракт полностью безопасен:
«Важно понимать, что не все аудиторы смарт-контрактов равны. Аудит смарт-контрактов начинается с понимания и опыта конкретной экосистемы, для которой проверяется смарт-контракт, а также стека технологий и используемого языка кода. Не все коды или блокчейны одинаковы. Здесь важен опыт для освещения и выводов».
Гу считает, что компании, желающие провести аудит своих смарт-контрактов, должны выходить за рамки сертификации, о которой заявляет аудитор, и принимать во внимание качество, масштаб и репутацию аудитора. Поскольку эти стандарты являются рекомендациями, Гу отметил, что считает эту спецификацию хорошей отправной точкой.
С точки зрения разработчика, эти спецификации могут оказаться чрезвычайно полезными. Марк Бейлин, соучредитель Myco — новой социальной сети на основе блокчейна — сказал, что эти стандарты будут невероятно ценными, поскольку помогут разработчикам смарт-контрактов лучше понять, чего ожидать от аудита безопасности. Он заявил:
«В настоящее время существует множество разрозненных ресурсов для обеспечения безопасности смарт-контрактов, но нет конкретного свода правил, которым аудиторы будут следовать при оценке безопасности проекта. Используя эту спецификацию, как аудиторы безопасности, так и их клиенты могут быть на одной волне в отношении того, какие требования безопасности будут проверяться».
Майкл Левеллен, разработчик спецификации, также сообщил, что эти спецификации помогают, предоставляя контрольный список известных проблем безопасности, которые необходимо проверить.
«Многие разработчики Solidity в последнее время не получали формального образования или подготовки по аспектам безопасности при разработке Solidity, но безопасность по-прежнему ожидается. Наличие таких спецификаций облегчает понимание того, как писать более безопасный код», — сказал он.
Левеллен также отметил, что большинство требований спецификации написаны простым языком, что облегчает понимание разработчиками. Однако он заметил, что не всегда понятно, почему требование включено.
«У некоторых есть ссылки на внешнюю документацию об уязвимости, а у некоторых - нет. Разработчикам было бы легче понять, если бы у них были более четкие примеры того, как может выглядеть совместимый и несовместимый код».
Эволюция стандартов безопасности смарт-контрактов
Учитывая все обстоятельства, спецификация уровня безопасности помогает продвигать экосистему Ethereum, устанавливая руководящие принципы для аудита смарт-контрактов. Тем не менее, Невил отметил, что наиболее сложным аспектом продвижения вперед является предвидение того, как может произойти эксплойт. Он сказал:
«Такая спецификация полностью не решает проблемы. Однако спецификация определяет определенные шаги, такие как документирование архитектуры и бизнес-логики контрактов, которые важны для проведения тщательного аудита безопасности».
Гу также считает, что различные сети начнут разрабатывать аналогичные стандарты по мере развития Web3. Например, некоторые разработчики в индустрии Ethereum выдвигают свои собственные требования к смарт-контрактам, чтобы помочь другим. Сэмюэл Кардильо, главный технический директор RTFKT, недавно написал в Твиттере, что он создал систему, позволяющую разработчикам публично оценивать смарт-контракты на основе хороших и плохих элементов с точки зрения разработки:
“Несколько дней назад я запустил небольшую таблицу Google для оценки публичных смарт-контрактов, чтобы повысить осведомленность и помочь как коллекционерам, так и разработчикам. Она также будет содержать рекомендации при разработке контракта”.
Хотя все это является шагом в правильном направлении, Гу отметил, что для широкого внедрения стандартов требуется время. Более того, Невил объяснил, что безопасность никогда не бывает статичной. Отдельные лица могут отправлять вопросы рабочей группе, которая написала спецификацию.
«Мы примем эти отзывы, а также посмотрим, какие обсуждения ведутся в более широком публичном пространстве, потому что мы ожидаем обновления спецификации. Новая версия спецификации будет выпущена в течение шести-восемнадцати месяцев,», — сказал Невил.
