5 вопросов, которые CTO должен задать блокчейн-подрядчику перед стартом проекта

Рынок блокчейн-разработки перенасыщен командами, которые предлагают одно и то же. За одинаковыми презентациями, таблицами и громкими формулировками часто скрывается слабая экспертиза. CTO приходится разбираться, кто способен довести продукт до продакшена, а кто знает лишь красивые термины.

Проблема в том, что большинство типовых вопросов не дают нужной глубины. Любой подрядчик сможет уверенно рассказать о смарт-контрактах, «понимании Web3» и знаниях Solidity. Это ничего не говорит о том, как он справится с архитектурой под нагрузкой, интеграцией с существующей системой клиента или масштабированием продукта в будущем.

Чтобы отделить сильных исполнителей от тех, кто работает поверхностно, нужны вопросы, которые показывают реальный подход к архитектуре, безопасности и работе с данными. Ниже — пять вопросов, которые мы выявили за три года работы в блокчейн-разработке  и которые помогают понять, насколько подрядчик готов вести продукт.

1. Почему вы предлагаете именно этот протокол?

Это простой вопрос, который редко задают правильно. Подрядчики часто выбирают сеть по привычке или по принципу «так делают все». Такой подход приводит к проблемам: рост комиссий, нехватка пропускной способности, отсутствие нужных механизмов приватности или невозможность обновления логики без миграций.

CTO важно услышать аргументацию, которая исходит из требований конкретного проекта.
Команда должна учитывать:

• нагрузку и частоту операций;
• стоимость транзакций при масштабировании;
• поддержку приватных данных или разрешённых участников;
• требования к скорости подтверждения;
• будущие интеграции и возможность расширения.

Если подрядчик опирается на один-два привычных блокчейна и продвигает их независимо от контекста, это признак шаблонного подхода. «Ethereum популярный» — не аргумент. То же касается фраз о Solana, Polygon или любой другой сети без конкретики.

Опытная команда объясняет разницу между протоколами через практические последствия: как выбранная сеть поведёт себя при 5, 50 и 500 тысячах пользователей; какие ограничения накладывают её механизмы; как обрабатывается нагрузка; что будет при росте конкуренции в мемпуле; можно ли адаптировать архитектуру без полной переработки.

При проектировании Red Rock Pool нам пришлось учитывать требования к пропускной способности, задержкам и стабильности сети. Выбор протокола и архитектуры не был очевидным: часть данных должна обрабатываться мгновенно, часть — фиксироваться в блокчейне, а часть — храниться оффчейн, но с полной проверкой целостности. Такой опыт помогает лучше чувствовать компромиссы между сетями, когда мы обсуждаем архитектуру будущих продуктов клиентов.

2. Какой у вас опыт интеграции блокчейна с существующими системами компании?

Блокчейн-продукты редко существуют отдельно от остальной инфраструктуры компании. Им приходится работать рядом с CRM, учётными модулями, финансовыми системами, складскими базами и внутренними сервисами. Настроить такую связку значительно сложнее, чем написать отдельный смарт-контракт.

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

Если команда избегает темы интеграций, это тревожный сигнал. Хорошие разработчики рассказывают, как решали подобные задачи:

• синхронизация транзакций с 1С, SAP или кастомной ERP;
• работа с очередями, когда события из блокчейна приходят быстрее, чем backend успевает их обработать;
• мягкое восстановление после падения RPC или ноды;
• отдельные случаи, когда задержка сети ломала бизнес-процессы, и как это исправляли.

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

Подрядчик должен объяснить, как он решал такие задачи на предыдущих проектах. Какие механизмы использовал, чтобы система продолжала работать, если один из источников данных стал недоступен. Как добивался того, чтобы операции не выполнялись дважды. Какие проблемы встречались на интеграциях, как они проявлялись и как команда их устранила.

3. Какая у вас стратегия disaster recovery?

Иногда создаётся впечатление, что если логика вынесена в блокчейн, система становится полностью устойчивой. На практике это не так. Отказы происходят на уровне RPC-провайдеров, облачной инфраструктуры, баз данных, сервисов, которые обрабатывают события, и даже очередей между модулями. Сама сеть при этом может продолжать работать, а продукт — временно терять функциональность или выдавать неверные данные.

CTO нужно понять, насколько подрядчик умеет проектировать систему так, чтобы она восстанавливалась после отказов.

Сильная команда говорит о:

• резервных нодах в разных регионах;
• механизмах быстрого переключения между провайдерами;
• чётких RPO и RTO — не абстрактных, а измеримых;
• мониторинге контрактов, транзакций и инфраструктуры;
• аварийных сценариях, включая временную паузу операций.

С нашим опытом мы точно знаем как действовать в критических ситуациях. Например, что происходит, если один из модулей начинает отдавать устаревшие данные или задерживает события. Могут ли операции быть временно заблокированы? Как уведомляются пользователи? Как решаются коллизии данных после восстановления?
Мы понимаем, что сбои неизбежны в сложных системах, и умеем работать с ними так, чтобы продукт оставался управляемым и предсказуемым.

4. Как проходит аудит смарт-контрактов и что входит в процесс проверки

Смарт-контракты требуют особенно внимательной проверки, потому что ошибки в них нельзя исправить обычным обновлением. Даже небольшие недочёты в логике могут приводить к неправильной работе продукта или некорректной обработке операций. Поэтому CTO важно понять, как подрядчик организует контроль качества и какие этапы проходят контракты перед выпуском.

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

В этом месте подрядчик обычно уточняет:

• как проходят рецензии кода внутри команды;
• какие случаи проверяются помимо стандартных сценариев;
• как используются инструменты статического анализа вроде Slither и Mythril;
• какие части логики моделируются вручную, а какие проверяются автоматикой;
• как проводится тестирование взаимодействия нескольких контрактов.

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

5. Как вы работаете с комплаенсом и нормативными ограничениями

Этот пункт часто недооценивают. Многие считают, что юридические вопросы — это зона ответственности клиента. На практике любая блокчейн-система сталкивается с требованиями регулирующих органов гораздо раньше, чем кажется: хранение персональных данных, валидность операций, соответствие локальным стандартам криптографии, механизмы подтверждения действий пользователя.

Подрядчик должен понимать, как сделать продукт юридически прозрачным, не нарушая логику блокчейна. Это не означает, что разработчики обязаны быть юристами, но они должны знать, как правильно передавать данные в on-chain слой и какие риски возникают, если проект игнорирует нормативные требования.

Признаки компетентности:

• аккуратная работа с персональными данными и логами;
• корректная фиксация событий через on-chain хеши;
• понимание требований отрасли, если проект связан с финансами или идентификацией;
• взаимодействие с юристами клиента при проектировании архитектуры;
• способность объяснить, что можно хранить в блокчейне, а что должно остаться вне его.

Когда подрядчик спокойно обсуждает эту тему и не пытается отмахнуться фразой «потом разберёмся», работа с ним становится предсказуемой.

Вывод

Для оценки подрядчика не требуется глубокое расследование. Достаточно этих пяти вопросов и внимательного отношения к тому, как команда обосновывает свои решения.

Сильные специалисты:

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

Слабые подрядчики говорят расплывчато и уходят от конкретных примеров. В таких случаях достаточно попросить показать рабочий код или результаты предыдущих проектов — это сразу делает картину прозрачной.

Эти вопросы помогают выявить уровень команды ещё до начала разработки. Благодаря им легче выбрать партнёров, которые способны не только вывести продукт в продакшен, но и обеспечить устойчивую работу и дальнейшее развитие.

Если вашему проекту нужна аккуратная архитектура, надёжные смарт-контракты и чёткая работа инфраструктуры, можно обсудить задачу с командой Nomium. Мы реализовали более 10 блокчейн-проектов и хорошо понимаем, как довести идею до устойчивого продакшена.