Тестування та офіційна перевірка безпеки смарт-контрактів Web3

Час читання: 9 протокол

Уявіть, що ви стрибаєте з парашутом. Перш ніж стрибнути з літака, ти сто разів перевіриш, чи немає парашута? Перевірка та тестування є невід'ємною частиною безпеки; думати про будь-які речі, пов'язані з безпекою. Ймовірно, згодом існував би механізм тестування, будь то встановлення системи відеоспостереження чи перевірка чорнила в ручці перед письмовим іспитом у школі, ми всі дотримуємося заходів безпеки. Чим вищий ризик, тим більше ми тестуємо речі. А коли ми говоримо про розумні контракти, ризик ВЕЛИЧЕЗНИЙ. Ви не можете бути недбалими, коли йдеться про безпеку смарт-контрактів.

1. Безпека потрібна завжди.

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

Світ Web3 нічим не відрізняється. Немає безпечного способу врятуватися, але наявність досвідчених аудиторів із QuillAudits може значно підвищити ймовірність того, що ваш протокол буде захищено, і забезпечить вашу актуальну безпеку. У web3 є два важливі механізми, які допомагають зрозуміти, наскільки ви захищені, виконавши деякі тести на вашому протоколі:-

1. Тестування смарт-контрактів
2. Формальна перевірка смарт-контрактів

Давайте детально розберемося з ними та дізнаємося, як вони допомагають нам пізнати слабкі місця або вразливі місця наших контрактів.

2. Тестування смарт-контрактів

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

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

2.1 Автоматизовано

Як випливає з назви, цей метод тестування смарт-контрактів використовується для тестування за сценарієм. Він включає в себе автоматизоване програмне забезпечення, яке виконує повторні тести, щоб знайти будь-які вразливості та дефекти в смарт-контрактах. Ці інструменти автоматизованого тестування можна налаштувати за допомогою тестових даних і очікуваних результатів. Потім фактичний результат порівнюється з очікуваним, щоб перевірити, чи договір працює належним чином. Автоматизоване тестування можна далі класифікувати на три категорії.

2.1.1. Функціональне тестування

Припустімо, ви пишете програму, яка бере два числа, a і b, а потім повертає додавання обох чисел. Отже, щоб перевірити цю програму, ви вказуєте 2 і 8 і передаєте очікуваний результат 10. Тепер, коли програма запускається, вона також має повернути 10. Якщо так, тоді вона працює нормально, і наш код правильний, але якщо він ні, то є якась помилка з нашим кодом. 

Функціональне тестування вимагає розуміння того, як ваш контракт повинен поводитися в певних умовах. Ми можемо перевірити це, виконавши обчислення з вибраними значеннями та порівнявши отримані результати. Функціональне тестування має три класи:-

1. Блок тестування:- Це стосується тестування окремих компонентів смарт-контракту на правильність. Він наполегливий або вимагає операторів щодо змінних.

2. інтеграцією текстиng: – Вони стосуються спільного тестування кількох окремих компонентів. Інтеграційне тестування є вищим рівнем в ієрархії, ніж модульне тестування. Це допомагає нам визначати помилки, що виникають через взаємодію різних функцій, які можуть бути частиною інших смарт-контрактів.

3. SYSTEM тестng: – Це найвищий в ієрархії. У цьому випадку ми перевіряємо весь контракт як одну повністю інтегровану систему, щоб перевірити, чи відповідає він нашим потребам. Це робиться з точки зору користувача, і найкращий спосіб зробити це – розгорнути його в тестових мережах.

2.1.2. Статичний аналіз

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

2.1.3. Динамічний аналіз

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

2.2 Посібник

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

Ручний режим вимагає значного часу, умінь, грошей і зусиль. Тим не менш, результат часто вартий того, оскільки завдяки цьому ми виявляємо вразливості, які можуть залишитися непоміченими під час автоматичного тестування. Є два основних типи ручного тестування:-

2.2.1 Перевірки коду:- 

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

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

2.2.2 Винагорода за помилку:-

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

3. Формальна перевірка смарт-контрактів

Формальна перевірка — це процес оцінки правильності контракту на основі формальних специфікацій. Це означає, що формальна перевірка оцінює, чи виконує код те, що призначено. Формальна верифікація використовує формальні методи для специфікації, розробки та перевірки програм.

3.1 Що таке формальна специфікація?

У контексті розумних контрактів формальні специфікації стосуються властивостей, які мають залишатися незмінними за будь-яких можливих обставин. Це властивості «інваріантів», оскільки вони не можуть змінюватися та представляють логічні твердження щодо виконання контракту.

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

Це може допомогти нам визначити, чи відповідає смарт-контракт специфікаціям або має неочікувану поведінку. Формальна перевірка складається з трьох компонентів: специфікації, моделі та механізму перевірки.

3.1.1 Специфікація

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

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

Модель 3.1.2

Модель формально представляє смарт-контракт, який можна використовувати для обґрунтування його поведінки. Однією з популярних моделей смарт-контрактів є мова програмування Solidity. Ось приклад моделі для описаної вище функції додавання:

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 Механізм перевірки

Механізм верифікації — це інструмент, який може аналізувати модель і перевіряти її правильність щодо даної специфікації. Для смарт-контрактів доступно кілька механізмів перевірки, зокрема:

Mythril: інструмент символічного виконання з відкритим кодом, який може виявляти широкий спектр вразливостей безпеки в смарт-контрактах Solidity.

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

Certora Prover: комерційний інструмент, який може перевірити правильність смарт-контрактів за допомогою автоматизованих математичних міркувань. Ось приклад того, як формальну перевірку можна використовувати для перевірки правильності смарт-контракту за допомогою Certora Prover:

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

У наведеному вище прикладі ми визначаємо смарт-контракт Solidity, який включає модель функції додавання, специфікацію функції та механізм перевірки (Certora Prover), який може перевіряти правильність функції. Ми також визначаємо тестову функцію (test_add), яку можна використовувати для перевірки правильності функції.

3.2 Тестування проти формальної перевірки

Як ми обговорювали, тестування повертає очікуваний результат для деяких вхідних даних бота, яких йому не вистачає, оскільки ми не можемо сказати про дані, на яких він не тестувався. Перевірити це на всіх можливих входах практично неможливо. Тому ми не впевнені в його «функціональній коректності». Ось тут і з’являється формальна перевірка. Формальні методи перевірки використовують суворі математичні методи визначення та перевірки програмного забезпечення або смарт-контрактів.

3.3 Методи формальної перевірки

Формальна верифікація має широкий спектр методів для покращення безпека смарт-контрактів. У цій частині блогу ми розглянемо кілька окремо.

3.3.1 Перевірка моделі

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

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

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

3.3.2 Доведення теореми

Доведення теорем стосується математичних міркувань щодо правильності програм. Це стосується створення логічного уявлення про систему контракту та специфікації та перевірки «логічної еквівалентності» між заявами. Логічна еквівалентність — це математичне співвідношення, яке говорить, що твердження A є істинним тоді і тільки тоді, коли твердження B є істинним.

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

4. Висновок

Тестування та формальна перевірка є невід’ємними частинами розробки смарт-контракту. Це методи, які використовуються для забезпечення безпеки смарт-контрактів і підготовки їх до розгортання. Але, як відомо, безпеки ніколи не буває достатньо. Багато смарт-контрактів були зламані лише тому, що не було належного тестування. Зараз як ніколи спільноті web3 потрібні більш безпечні протоколи. 

Ми в QuillAudits виконуємо місію, щоб допомогти захистити ваші протоколи. З нашою вмілою та досвідченою командою ми гарантуємо, що жодна вразливість не залишиться непоміченою. Відвідайте наш веб-сайт і захистіть свій проект Web3!

28 думки

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
• джерело: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/