Перейти до основного контенту
Change page

Тестування розумних контрактів

Останні оновлення сторінки: 26 лютого 2026 р.

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

Публічні блокчейни, як-от Ethereum, є незмінними, що ускладнює зміну коду смарт-контракту після його розгортання. Існують шаблони оновлення контрактів для виконання "віртуальних оновлень", але їх складно реалізувати, і вони вимагають соціального консенсусу. Крім того, оновлення може виправити помилку лише після її виявлення — якщо зловмисник виявить уразливість першим, ваш смарт-контракт перебуватиме під загрозою експлойту.

З цих причин тестування смарт-контрактів перед розгортанням у Головній мережі є мінімальною вимогою для безпеки. Існує багато методів для тестування контрактів та оцінки правильності коду; ваш вибір залежить від ваших потреб. Проте, набір тестів, що складається з різних інструментів і підходів, ідеально підходить для виявлення як незначних, так і серйозних недоліків безпеки в коді контракту.

Передумови

На цій сторінці пояснюється, як тестувати смарт-контракти перед розгортанням у мережі Ethereum. Передбачається, що ви знайомі зі смарт-контрактами.

Що таке тестування смарт-контрактів?

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

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

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

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

Хоча можна оновити контракт у разі виявлення помилки, оновлення є складними й можуть спричинити помилки (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 збільшується, попередній учасник, який зробив найвищу ставку, отримує свої гроші; як тільки період торгів закінчується, бенефіціар викликає контракт, щоб отримати свої гроші.

Модульні тести для такого контракту охоплюватимуть різні функції, які користувач може викликати під час взаємодії з контрактом. Прикладом може бути модульний тест, який перевіряє, чи може користувач зробити ставку під час аукціону (тобто виклики 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) та імітувати взаємодію між вашим контрактом і розгорнутими контрактами.

Розгалужений блокчейн поводитиметься подібно до Головної мережі та матиме облікові записи з пов’язаними станами та балансами. Але він діє лише як локальне середовище розробки в пісочниці, тобто вам не знадобиться справжній 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 передбачає плату за газ — не кажучи вже про те, що ви або ваші користувачі можете втратити реальні гроші, якщо у вашому смарт-контракті все ще є помилки.

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

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

Докладніше про мережі розробки.

Тестування контрактів на тестових мережах

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

Ця форма ручного тестування корисна для оцінки наскрізного потоку вашої програми з точки зору користувача. Тут бета-тестери також можуть виконувати пробні запуски та повідомляти про будь-які проблеми з бізнес-логікою контракту та загальною функціональністю.

Розгортання в тестовій мережі після тестування на локальному блокчейні є ідеальним, оскільки перша ближча до поведінки віртуальної машини 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 (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.

Пов'язані посібники

Для подальшого читання

Чи була ця стаття корисною?