Разработка whitelist/allowlist для минтинга NFT
Типичная ситуация: коллекция на 10,000 NFT, whitelist-минт для 3,000 адресов за 12 часов до публичного. Если хранить whitelist on-chain как mapping(address => bool) — деплой контракта с записью 3,000 адресов обходится примерно в 15-20M gas только на SSTORE. При цене газа 20 gwei это около $4 000. Наша команда с 7+ лет опыта в блокчейн-разработке и 50+ выполненными проектами NFT-минтов предлагает эффективные решения. Мы разрабатываем whitelist/allowlist системы под ключ с использованием Merkle tree, что снижает затраты до 50k gas — экономия до $4 000. Оценим ваш проект за 1 день — получите консультацию.
Как работает Merkle proof и где ошибаются
Merkle tree строится off-chain: каждый адрес хэшируется через keccak256(abi.encodePacked(address)), из листьев строится дерево попарным хэшированием. Результат — 32-байтный merkleRoot. Этот root деплоится в контракт. При минте пользователь передаёт proof[] — массив хэшей-братьев по пути от его листа до корня. Контракт верифицирует через MerkleProof.verify() из OpenZeppelin.
Распространённая ошибка — двойной минт. Если в контракте нет mapping(address => bool) public hasMinted (или mapping(address => uint256) public mintedCount), пользователь из whitelist может минтить неограниченное количество раз. Proof остаётся валидным. Контракт не знает, что адрес уже минтил.
Вторая серьёзная проблема — leaf encoding. OpenZeppelin MerkleProof ожидает, что лист — это keccak256(keccak256(data)) (double hash) для защиты от preimage attacks в случае если узлы дерева совпадают с листьями. Если генерируешь дерево через merkletreejs с одинарным hash, а контракт использует _leaf = keccak256(abi.encodePacked(account)) без double hash — может сработать collision attack при определённых конфигурациях. Мы используем keccak256(bytes.concat(keccak256(abi.encode(addr)))) или стандартную связку @openzeppelin/merkle-tree JS библиотека + MerkleProof.sol.
Какой способ выбрать для вашего проекта?
Существует три основных подхода для реализации whitelist. Сравним их характеристики:
| Критерий | Merkle proof | ECDSA подпись | On-chain mapping |
|---|---|---|---|
| Стоимость деплоя (газ) | 50k (фиксированно) | 50k + базовая стоимость | 20k * N адресов |
| Гибкость обновления | Требует смены root | Динамическое (любые изменения) | Только owner-функции |
| Централизация | Нет | Зависит от signer key | Нет |
| Безопасность | Высокая (доказана) | Средняя (ключевой риск) | Высокая |
| Идеальный размер списка | 100 — 1 млн+ | Любой, с неизвестными изменениями | < 100 адресов |
Merkle proof — стандарт рынка, дешевле on-chain mapping в 40 раз для 10 000 адресов. ECDSA применяется в gaming mint и динамических кампаниях. On-chain mapping — только для очень маленьких фиксированных списков.
Сравнение схем для multi-tier и фаз
Для проектов с разными уровнями доступа (OG, core, community) или временными фазами (pre-sale, allowlist, public) нужна дополнительная логика. Рассмотрим типичные конфигурации:
| Схема | Количество root | Управление | Gas на минт |
|---|---|---|---|
| Один root + multi-tier через encoding | 1 | Простое, но фиксированные квоты | ~60k-70k |
| Отдельные root на фазу | 3-5 | Owner setPhase(), разные цены | ~50k + смена root |
| Гибрид: root + ECDSA для динамики | 1 подпись | Backend подписывает разрешения | ~70k + риск signer |
Выбор схемы зависит от требований: если квоты меняются до минта — лучше ECDSA, если фиксированные — Merkle proof с multi-tier encoding.
Как генерировать Merkle tree на практике?
- Соберите все адреса и квоты в массив.
- Используйте библиотеку
@openzeppelin/merkle-tree:
const { StandardMerkleTree } = require('@openzeppelin/merkle-tree'); const values = [ ['0x...', 1], ['0x...', 3], ]; const tree = StandardMerkleTree.of(values, ['address', 'uint256']); const root = tree.root; - Сохраните root в контракт.
- Для каждого пользователя генерируйте proof через
tree.getProof([address, maxMint])и передавайте при минте.
Почему Merkle proof — стандарт рынка?
Независимо от размера списка, деплой стоит одинаково. Proof передаётся пользователем (frontend генерирует автоматически), контракт лишь проверяет. Мы гарантируем отсутствие reentrancy и корректную верификацию proof. Наши контракты проходят аудит с использованием Slither и Mythril.
Дополнительные механики
Multi-tier whitelist — разные квоты для разных уровней. Merkle дерево содержит листья keccak256(abi.encode(address, maxMintAmount)). Пользователь передаёт proof + свой maxMintAmount, контракт верифицирует оба параметра вместе.
Temporal phases — WL → Allowlist → Public. Контракт держит enum SalePhase { PAUSED, WHITELIST, ALLOWLIST, PUBLIC }. Разные root'ы для разных фаз, разные цены. owner меняет фазу через setPhase().
Batch mint с WL — пользователь может минтить N NFT за одну транзакцию, если его квота позволяет. mintedCount[msg.sender] += amount вместо bool флага.
Что входит в разработку
- Смарт-контракт с Merkle verify, hasMinted mapping и управлением фазами
- Полный набор тестов в Foundry (edge cases: повторный минт, невалидный proof, исчерпанная квота)
- Frontend интеграция (генерация proof через
@openzeppelin/merkle-tree, wagmi hookuseMint()) - Деплой через Foundry script с автоматической верификацией Etherscan
- Документация и поддержка после запуска
Ориентиры по срокам
Whitelist контракт с Merkle proof — 2-3 дня включая тесты и frontend интеграцию. Стоимость рассчитывается индивидуально. Свяжитесь с нами для обсуждения вашего проекта — мы поможем выбрать оптимальную схему и реализуем её с гарантией безопасности.