npm-пакет для смарт-контракта: типизация, ABI-генерация и CI/CD

Контракт задеплоен, фронтенд-разработчик хочет с ним работать. Первый вариант — копировать ABI JSON вручную, писать вызовы через ethers.Contract с кастингом на any. Второй — npm-пакет с типизированными обёртками, который импортируется одной строкой и даёт автодополнение в IDE. Мы специализируемся на втором подходе: за 5+ лет работы с Solidity и TypeScript реализовали более 30 таких пакетов для DeFi-протоколов, NFT-маркетплейсов и L2-мостов.

Разница особенно ощущается при апгрейде контракта: в первом случае нужно найти все места со старым ABI и надеяться, что не пропустили; во втором — достаточно обновить версию пакета. Если контракт меняет сигнатуру функции, TypeScript выбросит ошибки компиляции во всех местах использования. По нашим данным, использование типизированного пакета сокращает время интеграции в 5 раз и снижает количество багов на 70%.

Проблемы, которые решаем

Типичные технические сложности, с которыми сталкиваются команды:

• Ручное копирование ABI — в проекте с 50+ экранами ABI может быть вставлен в 10 разных файлов. При каждом деплое нужно синхронизировать все копии — одна опечатка ломает транзакцию.
• Отсутствие автодополнения — разработчик тратит до 3 минут на каждую функцию, постоянно заглядывая в документацию. В масштабе команды это часы в неделю.
• Ошибки типов — кастинг через as any пропускает несоответствие параметров, транзакция падает на этапе gas estimation, дебаг занимает полдня.
• Разброс адресов — адреса контрактов в .env или JSON, легко перепутать сеть. В одном проекте адрес на Sepolia случайно залили в mainnet — потеряли 5 ETH.

Наши пакеты избавляют от этих проблем: ABI генерируется автоматически из артефактов сборки, адреса централизованы в карте chainId → address, типы проверяются на этапе компиляции.

Как npm-пакет ускоряет интеграцию смарт-контракта?

Рассмотрим типовой проект на Foundry. После forge build артефакты лежат в out/. Используем TypeChain с адаптером для Foundry:

forge build
npx typechain --target ethers-v5 --out-dir src/typechain 'out/**/!(*.dbg).json'

Получаем файл src/typechain/factories/MyContract__factory.ts с типизированным методом connect(). Затем собираем npm-пакет через tsup — он даёт dual CJS/ESM output из коробки:

{
  "main": "./dist/index.cjs",
  "module": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "require": "./dist/index.cjs"
    }
  }
}

В одном проекте мы добавили React-хуки через wagmi CLI: команда wagmi generate с плагином foundry сгенерировала готовые хуки для чтения/записи. Фронтенд-разработчики смогли вызвать useReadMyContract() без написания ни одной строчки ABI-взаимодействия. Результат: время интеграции сократилось с 4 часов до 30 минут — в 8 раз быстрее.

Что входит в работу

При заказе разработки npm-пакета вы получаете:

1. Исходный код с типизированными обёртками (TypeChain или viem).
2. Карту адресов по всем сетям (mainnet, testnet, L2).
3. Dual-сборку (ESM + CJS) через tsup.
4. CI/CD на GitHub Actions: автотесты, сборка, публикация при пуше тега.
5. Документацию в README с примерами импорта и использования.
6. Поддержку на этапе интеграции — помогаем настроить импорт.

Почему стоит выбрать типизированный пакет вместо ручного ABI?

TypeChain генерирует не только типы, но и фабрики с connect() и полным автодополнением. Ручное обращение — 5 строк кода с кастингом, через TypeChain — 1 строка без any. Ошибки отлавливаются на этапе компиляции, а не на тестовой ноде. Наша статистика: TypeChain уменьшает количество багов в интеграции на 70%.

Сборка и публикация

Стек сборки: tsup (рекомендуем) или rollup. tsup настраивается за 5 минут и поддерживает dual ESM/CJS без дополнительных плагинов. Для версионирования используем semantic-release — автоматически ставит мажорную версию при breaking change в ABI.

Для внутренних пакетов — GitHub Packages или Verdaccio. Настройка .npmrc:

@myorg:registry=https://npm.pkg.github.com

Сроки ориентировочно

• Базовый пакет (один контракт, ABI, типы, адреса) — от 1 рабочего дня.
• Полный пакет (TypeChain, dual, CI/CD, документация) — от 2 до 3 дней.
• Сложный пакет (несколько контрактов, cross-chain адреса, React-хуки) — от 4 до 7 дней.

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

Разработка смарт-контрактов

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $800k. Смотрим транзакцию в Tenderly: атакующий вызвал deposit(), внутри callback на ERC-777 повторно вызвал withdraw() — баланс обновился только после второго выхода. Классическая reentrancy, но не через ETH transfer, а через хук ERC-777. ReentrancyGuard стоял только на withdraw().

Такие случаи — не редкость. Смарт-контракт — это финансовая логика без возможности пропатчить её ночью. Наша команда разрабатывает контракты под ключ, встраивая защиту от reentrancy, MEV и gas-атак на ранних этапах.

Как мы разрабатываем смарт-контракты под ключ

Начинаем с аудита бизнес-логики и выбора стека. Solidity 0.8.x — стандарт для EVM-совместимых чейнов: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana используем Rust и Anchor: модель аккаунтов и программ требует явного объявления всех ресурсов. Для проектов с формальной верификацией подходит Move (Aptos, Sui) — линейные типы языка исключают копирование ресурсов на уровне компилятора. Vyper выбираем для контрактов, где критична простота аудита (Curve Finance).

Gas optimization — не преждевременная оптимизация, а архитектурное решение. На Ethereum mainnet деплой плохо спроектированного контракта может стоить 2–5 ETH только из-за неоптимального storage layout. Переупаковка структуры Proposal с 7 слотов до 4 сэкономила 18k gas на каждом голосовании — около $1.5 при gas price 30 gwei. Экономия на масштабе протокола с тысячами голосований в день даёт ощутимую годовую выгоду.

Типичные ошибки в gas: передача массивов через memory вместо calldata в external функциях (дороже в 2–3 раза); использование require с длинными строками вместо custom error error InsufficientBalance(...). Кастомные ошибки дешевле на 50–200 gas на revert и передают структурированные данные фронтенду.

Почему аудит смарт-контрактов критичен для безопасности

Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:

1. Статический анализ — Slither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
2. Фаззинг и invariant тесты — Foundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
3. Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.

Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.

Какие паттерны апгрейда выбираем

Storage collision — главная опасность прокси. Implementation v2 не должен добавлять переменные перед существующими. OpenZeppelin Upgrades plugin для Hardhat и Foundry проверяет это автоматически, но только при использовании его API.

Как защитить контракт от MEV и front-running

На Ethereum mainnet транзакции в mempool видны всем. MEV-боты проводят sandwich-атаки на DEX, фронтраннинги минтинга и governance. Решение: commit-reveal scheme для аукционов, приватная отправка через Flashbots PROTECT RPC. EIP-7702 и PBS (proposer-builder separation) меняют картину, но пока не массово.

Процесс разработки

1. Аналитика — спецификация функций, диаграмма вызовов, анализ edge cases. Без этого кодинг начинается впустую.
2. Разработка — Solidity/Rust с тестами параллельно. Тест → код → рефакторинг. Используем Foundry для fuzz и invariant тестов.
3. Внутренний аудит — Slither + Echidna + ручной code review. Foundry invariant tests для протокольных инвариантов.
4. Внешний аудит — для проектов с реальными деньгами. Срок: 2–4 недели.
5. Деплой — Foundry scripts или Hardhat Ignition с verify на Etherscan. Gnosis Safe для ownership transfer сразу после деплоя.
6. Мониторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Что входит в работу

• Документация на архитектуру и спецификацию контракта (NatSpec).
• Исходный код с репозиторием и CI (Slither, Foundry, coverage).
• Развёрнутая версия контракта с verify на блокчейн-эксплорере.
• Результаты аудита (внутреннего и внешнего по запросу).
• Доступы к мониторингу и управлению (Gnosis Safe).
• Гарантия на код: фиксы критических багов в течение месяца после деплоя.
• Консультация по интеграции с веб-интерфейсом (wagmi, RainbowKit).

Сроки ориентировочно

• ERC-20 token с базовыми функциями: 1–2 недели
• Vesting контракт с cliff/linear schedule: 2–3 недели
• NFT ERC-721/1155 с маркетплейсом: 4–6 недель
• AMM или lending протокол: 2–4 месяца
• Мультичейн протокол с bridge: 4–7 месяцев

Аудит добавляет 3–6 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.

Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.