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

Когда я начал разрабатывать с помощью 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
• Связь с разными сетями
• Загрузите настройки через переменные среды
• Умейте справляться со сложными ситуациями при развертывании

Скрипты развертывания на основе JavaScript сейчас нужны в Foundry, но могут быть неудобными, когда конструкторам нужно предоставлять аргументы. Предлагаемое решение — создать скрипты развертывания bash для обработки сложных развертываний, но команда разработчиков сейчас разрабатывает более продвинутые решения для развертывания.

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

Foundry имеет инструмент CLI cast для взаимодействия с блокчейном и запроса смарт-контрактов. Это мощная утилита, которая позволяет вам:

• Вызывайте функции контракта
• Запрос состояния блокчейна
• Делайте разные вещи с блокчейном через командную строку

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

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

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

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

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