Перейти к основному содержанию
Change page

Тестирование смарт-контрактов

Последнее обновление страницы: 26 февраля 2026 г.

wackeroww (opens in a new tab)
mnelsonBTm (opens in a new tab)
corwintinesc (opens in a new tab)
+22

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

По этим причинам тестирование смарт-контрактов перед развертыванием в основной сети (Mainnet) является минимальным требованием для обеспечения безопасности. Существует множество методов для тестирования контрактов и оценки правильности кода; выбор зависит от ваших потребностей. Тем не менее, набор тестов, состоящий из различных инструментов и подходов, идеально подходит для выявления как незначительных, так и серьезных недостатков безопасности в коде контракта.

Предварительные условия

На этой странице объясняется, как тестировать смарт-контракты перед развертыванием в сети Ethereum. Предполагается, что вы знакомы со смарт-контрактами.

Что такое тестирование смарт-контрактов?

Тестирование смарт-контрактов — это процесс проверки того, что код смарт-контракта работает так, как ожидалось. Тестирование полезно для проверки того, удовлетворяет ли конкретный смарт-контракт требованиям надежности, удобства использования и безопасности.

Хотя подходы различаются, большинство методов тестирования требуют выполнения смарт-контракта с небольшим объемом данных, которые он должен обрабатывать. Если контракт дает правильные результаты для выборочных данных, считается, что он функционирует должным образом. Большинство инструментов для тестирования предоставляют ресурсы для написания и выполнения тестовых случаев (opens in a new tab) для проверки соответствия выполнения контракта ожидаемым результатам.

Почему важно тестировать смарт-контракты?

Поскольку смарт-контракты часто управляют дорогостоящими финансовыми активами, незначительные ошибки программирования могут привести и часто приводят к огромным потерям для пользователей (opens in a new tab). Однако тщательное тестирование может помочь вам выявить дефекты и проблемы в коде смарт-контракта на ранней стадии и исправить их до запуска в основной сети (Mainnet).

Хотя возможно обновить контракт при обнаружении ошибки, обновления сложны и могут привести к ошибкам (opens in a new tab) при неправильном обращении. Обновление контракта еще больше отрицает принцип неизменности и обременяет пользователей дополнительными предположениями о доверии. И наоборот, комплексный план тестирования вашего контракта снижает риски безопасности смарт-контрактов и уменьшает необходимость в сложных логических обновлениях после развертывания.

Методы тестирования смарт-контрактов

Методы тестирования смарт-контрактов Ethereum делятся на две большие категории: автоматизированное тестирование и ручное тестирование. Автоматизированное и ручное тестирование предлагают уникальные преимущества и компромиссы, но вы можете объединить их для создания надежного плана анализа ваших контрактов.

Автоматизированное тестирование

Автоматизированное тестирование использует инструменты, которые автоматически проверяют код смарт-контракта на наличие ошибок при исполнении. Преимущество автоматизированного тестирования заключается в использовании скриптов (opens in a new tab) для управления оценкой функциональности контракта. Скриптовые тесты можно запланировать для многократного запуска с минимальным вмешательством человека, что делает автоматизированное тестирование более эффективным, чем ручные подходы к тестированию.

Автоматизированное тестирование особенно полезно, когда тесты повторяются и занимают много времени, их трудно выполнять вручную, они подвержены человеческим ошибкам или включают оценку критически важных функций контракта. Но инструменты автоматизированного тестирования могут иметь и недостатки: они могут пропустить некоторые ошибки и выдать много ложноположительных результатов (opens in a new tab). Следовательно, идеальным является сочетание автоматизированного и ручного тестирования для смарт-контрактов.

Ручное тестирование

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

Ручное тестирование может проводиться одним человеком в соответствии с письменным планом тестирования, который охватывает различные сценарии тестирования. Вы также можете попросить нескольких лиц или групп взаимодействовать со смарт-контрактом в течение определенного периода в рамках ручного тестирования. Тестировщики будут сравнивать фактическое поведение контракта с ожидаемым, отмечая любое различие как ошибку.

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

Автоматизированное тестирование для смарт-контрактов

Модульное тестирование

Модульное тестирование оценивает функции контракта по отдельности и проверяет правильность работы каждого компонента. Хорошие модульные тесты должны быть простыми, быстрыми в выполнении и давать четкое представление о том, что пошло не так, если тесты не пройдены.

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

Рекомендации по модульному тестированию смарт-контрактов

1. Поймите бизнес-логику и рабочий процесс ваших контрактов

Прежде чем писать модульные тесты, полезно знать, какие функции предлагает смарт-контракт и как пользователи будут получать к ним доступ и использовать их. Это особенно полезно для запуска тестов по «счастливому пути» (opens in a new tab), которые определяют, возвращают ли функции в контракте правильный результат для допустимых пользовательских вводов. Мы объясним эту концепцию на примере (сокращенном) контракта аукциона (opens in a new tab)

1constructor(
2        uint biddingTime,
3        address payable beneficiaryAddress
4    ) {
5        beneficiary = beneficiaryAddress;
6        auctionEndTime = block.timestamp + biddingTime;
7    }
8
9function bid() external payable {
10
11      if (block.timestamp > auctionEndTime)
12            revert AuctionAlreadyEnded();
13
14      if (msg.value <= highestBid)
15            revert BidNotHighEnough(highestBid);
16
17 if (highestBid != 0) {
18    pendingReturns[highestBidder] += highestBid;
19        }
20        highestBidder = msg.sender;
21        highestBid = msg.value;
22        emit HighestBidIncreased(msg.sender, msg.value);
23    }
24
25 function withdraw() external returns (bool) {
26        uint amount = pendingReturns[msg.sender];
27        if (amount > 0) {
28           pendingReturns[msg.sender] = 0;
29
30        if (!payable(msg.sender).send(amount)) {
31                pendingReturns[msg.sender] = amount;
32                return false;
33            }
34        }
35        return true;
36    }
37
38function auctionEnd() external {
39       if (block.timestamp < auctionEndTime)
40            revert AuctionNotYetEnded();
41        if (ended)
42            revert AuctionEndAlreadyCalled();
43
44        ended = true;
45        emit AuctionEnded(highestBidder, highestBid);
46
47        beneficiary.transfer(highestBid);
48    }
49}
Показать все

Это простой контракт аукциона, предназначенный для приема ставок в течение периода торгов. Если highestBid увеличивается, предыдущий участник, сделавший самую высокую ставку, получает свои деньги; как только период торгов заканчивается, beneficiary вызывает контракт, чтобы получить свои деньги.

Модульные тесты для такого контракта охватывали бы различные функции, которые пользователь мог бы вызывать при взаимодействии с контрактом. Примером может служить модульный тест, который проверяет, может ли пользователь сделать ставку во время аукциона (т. е. вызовы bid() завершаются успешно), или тест, который проверяет, может ли пользователь сделать ставку выше текущей highestBid.

Понимание рабочего процесса контракта также помогает в написании модульных тестов, которые проверяют, соответствует ли выполнение требованиям. Например, контракт аукциона указывает, что пользователи не могут делать ставки после окончания аукциона (т. е. когда auctionEndTime меньше block.timestamp). Таким образом, разработчик может запустить модульный тест, который проверяет, завершаются ли вызовы функции bid() успешно или неудачно после окончания аукциона (т. е. когда auctionEndTime > block.timestamp).

2. Оцените все предположения, связанные с выполнением контракта

Важно документировать все предположения о выполнении контракта и писать модульные тесты для проверки достоверности этих предположений. Помимо защиты от непредвиденного выполнения, тестирование утверждений заставляет вас задуматься об операциях, которые могут нарушить модель безопасности смарт-контракта. Полезный совет: выходить за рамки «тестов для счастливого пользователя» и писать негативные тесты, которые проверяют, не сбоит ли функция при неверных входных данных.

Многие фреймворки для модульного тестирования позволяют создавать утверждения — простые операторы, которые определяют, что контракт может и не может делать, — и запускать тесты, чтобы увидеть, соблюдаются ли эти утверждения при выполнении. Разработчик, работающий над описанным ранее контрактом аукциона, мог бы сделать следующие утверждения о его поведении перед запуском негативных тестов:

  • Пользователи не могут делать ставки, когда аукцион закончился или еще не начался.

  • Контракт аукциона отменяет транзакцию, если ставка ниже допустимого порога.

  • Пользователи, не выигравшие торги, получают свои средства обратно

Примечание: еще один способ проверить предположения — написать тесты, которые вызывают модификаторы функций (opens in a new tab) в контракте, особенно операторы require, assert и if…else.

3. Измерение покрытия кода

Покрытие кода (opens in a new tab) — это метрика тестирования, которая отслеживает количество ветвей, строк и операторов в вашем коде, выполненных во время тестов. Тесты должны иметь хорошее покрытие кода, чтобы минимизировать риск непроверенных уязвимостей. Без достаточного покрытия вы можете ошибочно предположить, что ваш контракт безопасен, потому что все тесты пройдены, в то время как уязвимости все еще существуют в непроверенных путях кода. Однако регистрация высокого покрытия кода дает уверенность в том, что все операторы/функции в смарт-контракте были достаточно протестированы на правильность.

4. Используйте хорошо разработанные фреймворки для тестирования

Качество инструментов, используемых для запуска модульных тестов для ваших смарт-контрактов, имеет решающее значение. Идеальный фреймворк для тестирования — это тот, который регулярно поддерживается, предоставляет полезные функции (например, возможности ведения журнала и отчетности) и должен быть широко использован и проверен другими разработчиками.

Фреймворки для модульного тестирования смарт-контрактов Solidity существуют на разных языках (в основном JavaScript, Python и Rust). См. некоторые из приведенных ниже руководств для получения информации о том, как начать запускать модульные тесты с различными фреймворками для тестирования:

Интеграционное тестирование

В то время как модульное тестирование отлаживает функции контракта изолированно, интеграционные тесты оценивают компоненты смарт-контракта в целом. Интеграционное тестирование может выявить проблемы, возникающие из-за межконтрактных вызовов или взаимодействия между различными функциями в одном и том же смарт-контракте. Например, интеграционные тесты могут помочь проверить, правильно ли работают такие вещи, как наследование (opens in a new tab) и внедрение зависимостей.

Интеграционное тестирование полезно, если ваш контракт имеет модульную архитектуру или взаимодействует с другими ончейн-контрактами во время выполнения. Один из способов проведения интеграционных тестов — это на определенной высоте (используя такой инструмент, как Forge (opens in a new tab) или Hardhat (opens in a new tab)) и смоделировать взаимодействие между вашим контрактом и развернутыми контрактами.

Форкнутый блокчейн будет вести себя аналогично основной сети (Mainnet) и будет иметь аккаунты со связанными состояниями и балансами. Но он действует только как локальная среда разработки в песочнице, то есть вам не понадобятся реальные ETH для транзакций, и ваши изменения не повлияют на реальный протокол Ethereum.

Тестирование на основе свойств

Тестирование на основе свойств — это процесс проверки того, что смарт-контракт удовлетворяет некоторому определенному свойству. Свойства утверждают факты о поведении контракта, которые, как ожидается, останутся верными в различных сценариях. Примером свойства смарт-контракта может быть: «Арифметические операции в контракте никогда не вызывают переполнения или антипереполнения».

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

Статический анализ

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

Линтинг (opens in a new tab) и статическое тестирование (opens in a new tab) являются распространенными методами статического анализа контрактов. Оба метода требуют анализа низкоуровневых представлений выполнения контракта, таких как абстрактные синтаксические деревья (opens in a new tab) и графы потока управления (opens in a new tab), выводимые компилятором.

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

Динамический анализ

Динамический анализ генерирует символические входные данные (например, при символическом выполнении (opens in a new tab)) или конкретные входные данные (например, при фаззинге (opens in a new tab)) для функций смарт-контракта, чтобы увидеть, нарушает ли какой-либо след(ы) выполнения определенные свойства. Эта форма тестирования на основе свойств отличается от модульных тестов тем, что тестовые случаи охватывают несколько сценариев, а программа обрабатывает генерацию тестовых случаев.

Фаззинг (opens in a new tab) — это пример метода динамического анализа для проверки произвольных свойств в смарт-контрактах. Фаззер вызывает функции в целевом контракте со случайными или искаженными вариациями определенного входного значения. Если смарт-контракт переходит в состояние ошибки (например, когда утверждение не выполняется), проблема отмечается, а в отчете приводятся входные данные, которые направляют выполнение к уязвимому пути.

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

  1. Написать тестовые случаи для охвата множества сценариев сложно. Тест на основе свойств требует только того, чтобы вы определили поведение и диапазон данных для его тестирования — программа автоматически генерирует тестовые случаи на основе определенного свойства.

  2. Ваш набор тестов может недостаточно охватывать все возможные пути в программе. Даже при 100% покрытии можно упустить крайние случаи.

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

Рекомендации по проведению тестирования смарт-контрактов на основе свойств

Проведение тестирования на основе свойств обычно начинается с определения свойства (например, отсутствия целочисленных переполнений (opens in a new tab)) или набора свойств, которые вы хотите проверить в смарт-контракте. Вам также может потребоваться определить диапазон значений, в пределах которого программа может генерировать данные для входных данных транзакции при написании тестов на основе свойств.

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

Ручное тестирование смарт-контрактов

Ручное тестирование смарт-контрактов часто проводится на более поздних этапах цикла разработки после выполнения автоматизированных тестов. Эта форма тестирования оценивает смарт-контракт как единый полностью интегрированный продукт, чтобы увидеть, работает ли он в соответствии с техническими требованиями.

Тестирование контрактов на локальном блокчейне

Хотя автоматизированное тестирование, проводимое в локальной среде разработки, может предоставить полезную информацию для отладки, вам захочется узнать, как ваш смарт-контракт ведет себя в производственной среде. Однако развертывание в основной сети Ethereum влечет за собой плату за газ, не говоря уже о том, что вы или ваши пользователи можете потерять реальные деньги, если в вашем смарт-контракте все еще есть ошибки.

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

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

Подробнее о сетях для разработки.

Тестирование контрактов в тестовых сетях

Тестовая сеть работает точно так же, как основная сеть Ethereum, за исключением того, что в ней используется эфир (ETH), не имеющий реальной ценности. Развертывание вашего контракта в тестовой сети означает, что любой может взаимодействовать с ним (например, через интерфейс децентрализованного приложения), не рискуя средствами.

Эта форма ручного тестирования полезна для оценки сквозного потока вашего приложения с точки зрения пользователя. Здесь бета-тестеры также могут проводить пробные запуски и сообщать о любых проблемах с бизнес-логикой контракта и общей функциональностью.

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

Подробнее о тестовых сетях Ethereum.

Тестирование и формальная верификация

Хотя тестирование помогает подтвердить, что контракт возвращает ожидаемые результаты для некоторых входных данных, оно не может окончательно доказать то же самое для входных данных, не использовавшихся во время тестов. Таким образом, тестирование смарт-контракта не может гарантировать «функциональную правильность» (т. е. не может показать, что программа ведет себя так, как требуется для всех наборов входных значений).

Формальная верификация — это подход к оценке правильности программного обеспечения путем проверки соответствия формальной модели программы формальной спецификации. Формальная модель — это абстрактное математическое представление программы, а формальная спецификация определяет свойства программы (т. е. логические утверждения о выполнении программы).

Поскольку свойства написаны в математических терминах, становится возможным проверить, что формальная (математическая) модель системы удовлетворяет спецификации, используя логические правила вывода. Таким образом, считается, что инструменты формальной верификации производят «математическое доказательство» правильности системы.

В отличие от тестирования, формальная верификация может быть использована для проверки того, что выполнение смарт-контракта удовлетворяет формальной спецификации для всех выполнений (т. е. не имеет ошибок), без необходимости выполнять его с выборочными данными. Это не только сокращает время, затрачиваемое на запуск десятков модульных тестов, но и более эффективно для выявления скрытых уязвимостей. Тем не менее, методы формальной верификации лежат в спектре в зависимости от сложности их реализации и полезности.

Подробнее о формальной верификации для смарт-контрактов.

Тестирование, аудиты и программы поощрения за поиск ошибок

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

Тем не менее, вы можете еще больше увеличить вероятность выявления уязвимостей контракта, получив независимую проверку кода. Аудиты смарт-контрактов (opens in a new tab) и программы поощрения за поиск ошибок (opens in a new tab) — это два способа заставить других проанализировать ваши контракты.

Аудиты проводятся аудиторами, имеющими опыт в поиске недостатков безопасности и плохих практик разработки в смарт-контрактах. Аудит обычно включает тестирование (и, возможно, формальную верификацию), а также ручную проверку всей кодовой базы.

И наоборот, программа поощрения за поиск ошибок обычно включает в себя предложение финансового вознаграждения человеку (обычно называемому «белым» хакером (opens in a new tab)), который обнаруживает уязвимость в смарт-контракте и сообщает о ней разработчикам. Программы поощрения за поиск ошибок похожи на аудиты, поскольку они предполагают просьбу о помощи в поиске дефектов в смарт-контрактах.

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

Инструменты и библиотеки для тестирования

Инструменты модульного тестирования

  • solidity-coverage (opens in a new tab) — инструмент для определения покрытия кода для смарт-контрактов, написанных на Solidity.

  • Waffle (opens in a new tab) — фреймворк для продвинутой разработки и тестирования смарт-контрактов (на базе ethers.js).

  • Remix Tests (opens in a new tab) — инструмент для тестирования смарт-контрактов Solidity. Работает под плагином Remix IDE «Solidity Unit Testing», который используется для написания и запуска тестовых случаев для контракта.

  • OpenZeppelin Test Helpers (opens in a new tab) — библиотека утверждений для тестирования смарт-контрактов Ethereum. Убедитесь, что ваши контракты работают должным образом!

  • Фреймворк модульного тестирования Brownie (opens in a new tab) — Brownie использует Pytest, многофункциональный тестовый фреймворк, который позволяет писать небольшие тесты с минимальным кодом, хорошо масштабируется для больших проектов и обладает высокой расширяемостью.

  • Foundry Tests (opens in a new tab) — Foundry предлагает Forge, быстрый и гибкий фреймворк для тестирования Ethereum, способный выполнять простые модульные тесты, проверки оптимизации газа и фаззинг контрактов.

  • Hardhat Tests (opens in a new tab) — фреймворк для тестирования смарт-контрактов на основе ethers.js, Mocha и Chai.

  • ApeWorx (opens in a new tab) — фреймворк для разработки и тестирования на Python для смарт-контрактов, предназначенных для виртуальной машины Ethereum.

  • Wake (opens in a new tab) — фреймворк на Python для модульного тестирования и фаззинга с мощными возможностями отладки и поддержкой кросс-чейн тестирования, использующий pytest и Anvil для лучшего пользовательского опыта и производительности.

Инструменты тестирования на основе свойств

Инструменты статического анализа

  • Slither (opens in a new tab) — фреймворк для статического анализа Solidity на Python для поиска уязвимостей, улучшения понимания кода и написания пользовательских анализов для смарт-контрактов.

  • Ethlint (opens in a new tab) — линтер для обеспечения соблюдения стиля и лучших практик безопасности для языка программирования смарт-контрактов Solidity.

  • Cyfrin Aderyn (opens in a new tab) — статический анализатор на Rust, специально разработанный для безопасности и разработки смарт-контрактов Web3.

  • Wake (opens in a new tab) — фреймворк для статического анализа на Python с детекторами уязвимостей и качества кода, принтерами для извлечения полезной информации из кода и поддержкой написания пользовательских подмодулей.

  • Slippy (opens in a new tab) — простой и мощный линтер для Solidity.

Инструменты динамического анализа

  • Echidna (opens in a new tab) — быстрый фаззер контрактов для обнаружения уязвимостей в смарт-контрактах с помощью тестирования на основе свойств.

  • Diligence Fuzzing (opens in a new tab) — автоматизированный инструмент фаззинга, полезный для обнаружения нарушений свойств в коде смарт-контракта.

  • Manticore (opens in a new tab) — фреймворк динамического символического выполнения для анализа байт-кода EVM.

  • Mythril (opens in a new tab) — инструмент оценки байт-кода EVM для обнаружения уязвимостей контрактов с использованием анализа заражения, конколического анализа и проверки потока управления.

  • Diligence Scribble (opens in a new tab) — Scribble — это язык спецификаций и инструмент верификации во время выполнения, который позволяет аннотировать смарт-контракты свойствами, позволяющими автоматически тестировать контракты с помощью таких инструментов, как Diligence Fuzzing или MythX.

Связанные руководства

Дополнительные материалы

Была ли эта статья полезной?