Как выбирать фреймворк для разработки умных контрактов на Solidity для нового проекта?

В этом году стукнуло уже 10 лет, как я разрабатываю умные контракты на Solidity под EVM. В связи с этим решил написать статью и устроить очередной холивар про выбор фреймворка в зависимости от типа проекта, который предполагается разрабатывать. Статья в меньшей степени актуальна для разработчиков (тут не будет глубоких технических разборов и измышлений на тему tool1 быстрее tool2 на N ms) и в большей степени для руководителей, которые принимают решение о выборе технологического стека перед стартом web3-проекта и сбором команды исходя из соображений бизнеса и рационального использования ресурсов (да, это тоже зачастую важно и я готов сегодня пострадать за эту истину на костре из минусов за эту ересь).

Экономия ресурсов, разделение труда и bus factor

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

При этом следует сохранять устойчивость команды к bus factor, что в самом примитивном виде сводится к простому дублированию каждой роли в команде вплоть до двух девопсов в небольшой команде на случай, если с одним из них что‑то случится. Тем не менее снижение риска bus factor возможно не только за счёт примитивного дублирования ролей, но и за счёт перекрытия компетенций каждого специалиста в команде компетенциями другого. Так в самом простом примере вы можете для старта собрать устойчивую к bus factor классическую команду из двух фронтендеров и двух бэкендеров, либо же из фронтендера, бэкендера и одного фулстэка (такая команда зачастую дешевле, быстрее и при этом всё ещё устойчива к bus factor так как фулстэк закрывает компетенцию бэкендера и фронтендера и наоборот по крайней мере на время поиска замены выбывшему участнику команды). Естественно такую команду можно расширить при необходимости.

Далее я буду исходить именно из этих двух принципов, которые наиболее критичны при работе с ограниченным бюджетом. Если ограничений по бюджету нет, то всё это экономия на спичках, статья не столь актуальна, берите команду rockstars или даже несколько команд,‑ они сами разберутся с любым стеком даже если весь фронт будет на PureScript, а бэк на Haskell.

Разработка dApp (JS-based)

Классический и самый простой dApp в наше время — это развёрнутые умные контракты на Solidity, фронтед на JS‑стеке с поддержкой браузерного web3-кошелька типа Metamask и опционально инстанс индексатора, а полноценного самописного бэкенда такой dApp зачастую не имеет в силу отсутствия потребности в нём. Продукт достаточно массовый и в общем случае при разработке умных контрактов для него следует использовать hardhat (фреймворк для разработки умных контрактов с опорой на JS‑экосистему, где тесты и скрипты для работы с контрактами можно писать на JS/TS). Выбор hardhat позволит использовать JS/TS на проекте для всех целей: тестирования умных контрактов, скриптах к ним, фронтенде и даже в небольшом бэкенде на NodeJS при необходимости и отсутствии high‑load сценариев,‑ в результате вы сможете выделить переиспользуемый во всех частях dApp код в единый хорошо оптимизированный и протестированный модуль, который в дальнейшем можно даже опубликовать как npm‑пакет, чтобы другие использовали его как SDK для простоты интеграции с вашим продуктом. Такой подход позволяет максимально избежать написания дублирующего кода на разных языках, сохранив кодовую базу минималистичной и легко поддерживаемой.

Для того чтобы стартануть в такой конфигурации будет достаточно всего двух JS/TS‑специалистов (именно двух, никогда не забываем про bus factor) с компетенциями в web3 и приемлемыми навыками разработки умных контрактов,‑ таких специалистов реалистично найти на рынке и стоят они не очень дорого по меркам web3. Судя по статистике GitHub данный фреймворк был суммарно использован в 360 тысячах проектов с открытым кодом, что немало и обеспечивает запас по разработчикам и представленность в обучающих выборках LLM.

Разработка продуктов без фронтенда на python

В web3-индустрии есть и огромный пласт проектов, для которых не нужен никакой фронтенд вовсе, но при этом требуется бэкенд. Сюда можно отнести различных торговых ботов, MEV-ботов, DeFi-execution сервисы для криптобирж и криптофондов, сервисы сбора данных и аналитики и тд и тп. Обычно архитектура таких проектов состоит из:

1. Небольшого числа умных контрактов на Solidity (в основном обёртки, прослойки, роутеры и иные кастомные объединители транзакций в батчи, когда публичных MultiCall и MultiSend не хватает);

2. Бэкенда, который может быть в виде монолита, микросервисов или даже набора скриптов;

3. Реляционной или нереляционной базы данных или готового индексатора, однако это весьма опционально.

Исторически python достаточно популярен для таких проектов, поэтому случай для python я вынес в этот отдельный раздел. Многие python‑команды берут для такого проекта чистый web3py, но я бы рекомендовал вместо этого использовать один из россыпи релевантных python‑фреймворков: eth‑wake, eth‑brownie, ape или moccasin (только для vyper, так что не будет рассматриваться в этой статье). В отличие от JS‑экосистемы, где в итоге в живых остался только hardhat, в python‑экосистеме мы видим целый зоопарк, поэтому потребуется остановиться на том, когда и какой инструмент выбирать.

1. Если первоочерёдная задача это кибербезопасность с самым мощным фаззингом, автодетектом известных уязвимостей, работа с SARIF и полностью типизированный python‑код, то однозначным выбором будет wake, заточенный именно под такие задачи. Также его стоит выбрать, если разрабатываемый сервис будет кроссчейновым (то есть с потребностью работать с несколькими блокчейнами из одного процесса — это тоже ключевая фича wake);

2. Если важнее всего скорость работы, то однозначно следует выбирать brownie в связке с dank_mids, так как они работают на чистом Си за счёт компиляции через mypyc. Например, текущий бэк такого гиганта как YearnFinance живёт в значительной степени на этом стеке;

3. Если скорость и кибербезопасность не столь критичны, но нужна поддержка каких‑нибудь редких блокчейнов (например, zk‑based), то стоит присмотреться к ape, который за счёт гибкой системы плагинов позволяет получить её. Также этот фреймворк поддерживается той же командой, что и web3py, поэтому он активнее всего обновляется и хорошо с ним интегрирован. Из критических недостатков — отсутствие кроссплатформенности (есть поддержка только последних версий OS X и нескольких самых популярных дистрибутивов GNU/Linux).

Как и в случае с hardhat, чтобы запустить проект в такой конфигурации вам потребуется всего два python‑разработчика с компетенциями в web3 и Solidity. Популярность python‑фреймворков на два порядка меньше, чем у hardhat (самое большое количество публичных использований у brownie — 4 тысячи проектов на GitHub), однако всё ещё реалистично найти таких людей на рынке достаточно быстро и не совсем дорого по меркам web3.

Разработка проектов на чистом Solidity без фронта и бэка

В том случае, если у вашего проекта нет фронтенда и нет бэкенда, следует выбирать foundry. Особенностью данного фреймворка является то, что для работы не нужно знать вообще никаких языков программирования, кроме Solidity (в проектах на foundry на нём пишутся и тесты и скрипты), поэтому многие сильные Solidity‑разработчики зачастую предпочитают именно этот фреймворк. Примерами таких проектов без фронтенда и бэкенда являются библиотеки, которые пишутся на чистом Solidity и предполагаются к использованию в других проектах. Другим примером может быть что‑то очень шаблонирзированное, для чего уже существует написанная обвязка: токены различных стандартов, ERC-4626 хранилища и тп. Во всех этих случаях понадобится так же всего два разработчика, однако найти специалистов под foundry может быть посложнее, так как это более нишевый рынок.

Также foundry стоит использовать, когда бэкенд есть, но бэкендеры не питонисты, и для их стека нет специализированных фреймворков, но есть web3 SDK типа web3j или Nethereum и тд. В этом случае умные контракты всё также пишутся в отдельном репозитории с использованием foundry и в отдельном репозитории пишется код с использованием одного из языков общего назначения, для которого существует web3 SDK. В этом случае минимальная команда для старта обычно побольше и подороже, чем два человека, но реалистично уложиться в 3–4 человека (например, два бэкендера и два разработчика умных контрактов).

Выводы

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.Сколько разработчиков в вашем текущем web3-проекте0%1 (solo founder или бюджет позволял нанять только одного разработчика на проект)00%2-3 (минимальный рабочий сетап)0100%Более трёх1 Проголосовал 1 пользователь. Воздержавшихся нет.