Розробка смарт-контрактів: порівняння двох провідних фреймворків

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

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

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

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

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

Наприклад, замість написання довгих шляхів імпорту, ви можете написати короткі відповідності, які допоможуть зробити ваш код більш читабельним і зручним для обслуговування.

Фреймворки радикально відрізняються за способом управління залежностями:

• •Hardhat використовує усталену екосистему npm, яка відразу ж відкрита для розробників JavaScript
• •Встановлення контрактів OpenZeppelin — це просто команда npm install
• •Foundry покладається на управління залежностями за допомогою субмодуля Git через інструмент forge CLI
• •Залежності зберігаються в папці lib/ і додаються до файлу .gitmodules, на відміну від package.json

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

Ви можете вказати організацію GitHub та назву репозиторію, а також, за бажанням, вказати гілку або тег для встановлення. Після встановлення forge можна скористатися командою forge remapping, щоб переглянути стандартні шляхи імпорту, які буде використовувати Foundry, а потім налаштувати їх за допомогою файлів конфігурації.

Однією з областей, в якій Hardhat виділяється, є досвід налагодження. Фреймворк також пропонує використання console.log за замовчуванням, що нагадує очікуваний стиль налагодження в розробці JavaScript. Ця функціональність активно рекламується як перевага і може бути легко відстежена розробниками, щоб зрозуміти, як було виконано виконання і що не так.

Foundry потребує альтернативного методу реєстрації контрактів. Хоча можна вручну встановити та імпортувати Hardhat і встановити контракт консолі, найкращим способом буде скопіювати спеціалізований контракт консолі у ваш проект.

Особливо у випадку тестових файлів, контракт DSTest, що входить до складу, включає події журналу, такі як logstring, logint та logaddress, які можуть бути виведені без будь-яких додаткових залежностей.

Досвід тестування є, мабуть, найпомітнішою відмінністю між цими двома фреймворками.

Підхід до тестування Hardhat

Hardhat базується на стандартних шаблонах тестування JavaScript:

• •Використовує блоки describe та it разом із Mocha як бібліотекою тверджень за замовчуванням
• •Тестові файли можуть нагадувати цей більш природний стиль розробників, які знайомі з веб-розробкою
• •Пропонує описові назви тестів, які чітко вказують на їх призначення
• •Звичні асинхронні шаблони
• •Крива навчання мінімальна для тих, хто вже знайомий із сучасною веб-розробкою

Підхід до тестування Foundry

Foundry працює зовсім по-іншому:

• •Тести розробляються як смарт-контракти Solidity, які успадковують DSTest
• •Усі тести мають префікс test або testFail
• •Усі твердження робляться через успадкований контракт DSTest
• •Тестові файли — це справжні смарт-контракти, які використовуються для тестування

Метод Foundry має ряд наслідків:

• •Тестові контракти повинні бути інстанційовані в процедурі setUp(), аналогічній beforeEach в JavaScript-клієнтах
• •Розподіл методів контракту ETH передбачає певний синтаксис із параметрами значень, укладеними в фігурні дужки
• •Початкова крута крива навчання може бути компенсована тим, що не потрібно обробляти асинхронні операції

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

Ви можете:

• •Змінити поточний номер блоку
• •Не видавайте себе за інші облікові записи
• •Заявляйте про певну поведінку контракту

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

• •vm.prank(), щоб встановити наступний виклик контракту іншому одержувачу
• •vm.roll() для просування блокчейну до певної точки

Різниця в продуктивності між фреймворками є значною і відразу помітною. На однакових контрактах і тестових сценаріях я отримав показові результати щодо часу компіляції та виконання тестів:

Ці відмінності в продуктивності стають більш вираженими при збільшенні складності проекту.

Переваги продуктивності важко заперечити, а назви тестів Solidity не можуть бути такими ж описовими, як назви тестів JavaScript, що може ускладнити розуміння мети тесту. Система чіт-кодів, хоч і є потужною, вимагає початкових витрат на навчання.

Розгортання — це одна з областей, де Hardhat на даний момент має кращий досвід розробки. Фреймворк підтримує:

• •Скрипти розгортання на основі JavaScript
• •З'єднання з різними мережами
• •Завантажуйте конфігурацію через змінні середовища
• •Вміло вирішуйте складні ситуації, пов'язані з розгортанням

Наразі в Foundry потрібні скрипти розгортання на основі JavaScript, але вони можуть бути громіздкими, коли конструктори повинні мати свої аргументи. Пропоноване рішення полягає в розробці скриптів розгортання bash для обробки складності розгортань, але команда розробників зараз працює над розробкою більш просунутих рішень для розгортання.

Це одна з найсерйозніших сучасних слабких сторін Foundry порівняно з Hardhat, який має розвинену екосистему розгортання.

Foundry має інструмент CLI cast для взаємодії з блокчейном і запитування смарт-контрактів. Це потужна утиліта, яка дозволяє:

• •Викликайте функції контракту
• •Запит стану блокчейну
• •Виконуйте ряд дій з блокчейном у командному рядку

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

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

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

• •Foundry для розробки та тестування контрактів
• •Hardhat для розгортання та скриптів

Користувачі, які більше звикли до стандартних інструментів JavaScript та усталених практик розгортання, можуть бути більш продуктивними з Hardhat зараз, хоча рішення знову залежить від вашого досвіду та здатності освоїти нові інструменти.