Лендинг токенсейла: смарт-контракт, Merkle whitelist, real-time

Веб3 лендинг токенсейла: где ломается учёт квот и допуска

Публичный этап продажи токена ломается не на самой странице — она статична и предсказуема. Сбои приходят с другой стороны: участники заходят пачкой в первые минуты, и веб3 лендинг токенсейла начинает проверять квоты и допуск в режиме, к которому интерфейс не готов. Что именно здесь рвётся, видно по трём узлам.

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

Второй — список допуска. Пока он живёт в таблице, его правят руками: дописывают адреса, меняют уровень квоты, ловят дубликаты в разном регистре. Ручная модерация не выдерживает потока, а правка после публикации корня Merkle-дерева обнуляет доказательство — участник получает «вас нет в списке» при формально верном адресе. Ошибка тихая: ни письма, ни строки в журнале.

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

Что меняется после внедрения: сроки, нагрузка, класс отказов

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

Пик — тысячи кошельков в первые минуты. Подпись транзакции происходит на стороне клиента, лендинг лишь формирует данные и следит за подтверждением в сети Ethereum через подписку на события. Профиль нагрузки меняется: инфраструктура обслуживает чтение и поток статусов, а не массовые записи, поэтому страница не деградирует на пике, а лимит на адрес и временное окно проверяет сам контракт.

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

Для команды это предсказуемость: понятные метрики по этапам, оповещения на события контракта, одинаковый сценарий на тестовой и рабочей сети.

Варианты реализации лендинга: что берём готовым, что пишем

Страница токенсейла — это две части: сам лендинг (кошелёк, заявка, статус) и логика допуска. Допуск чаще всего строится на Merkle-дереве: полный список адресов фиксируется одним корнем, участник предъявляет ветку — проверка в контракте не дорожает с ростом списка. Насколько свободно эту логику можно переписать, зависит от подхода к сборке.

Готовый конструктор закрывает типовые распродажи быстро, но диктует и форму проверки допуска, и момент обновления статуса. Собственная сборка снимает эти рамки — ценой поддержки, мониторинга и повторных проверок контракта при каждом изменении правил.

Три пути и их цена

Смешанный вариант — частый компромисс: страница своя, распределение на проверенном контракте.

Этапы работ: от разбора модели распределения до передачи

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

1. Разбор модели распределения. Сводим раунды, лимиты на кошелёк, вестинг и правила возврата в одну таблицу состояний — она становится источником правды и для контракта, и для витрины.
2. Схема допуска. Определяем, кто и на каких условиях покупает: Merkle-дерево для списков, подпись сервера для открытых окон, раздельные фазы для разных групп.
3. Настройка контракта. Переносим таблицу в параметры: длительность фаз, потолки, пауза, события, на которые подписывается фронтенд. Каждое событие имеет ровно одного потребителя в интерфейсе.
4. Сборка витрины в реальном времени. Подписка на события сети, обработка промежуточных состояний транзакции и редких откатов блоков — счётчик проданного не «дёргается» и не откатывается назад на глазах покупателя.
5. Проверка на нагрузке. Прогоняем сценарий одновременного выкупа: сотни адресов в одном окне, конкуренция за лимит, поведение при переполнении раунда. Смотрим, где очередь растёт и что видит человек в этот момент.
6. Передача управления. Раздаём роли по мультиподписи, отзываем лишние права, отдаём доступы, схему развёртывания и инструкцию по аварийным действиям — команда заказчика может менять параметры без нас.

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

Комплект передачи: схемы допуска, правила, регламенты

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

• Схема допуска — как формируется список адресов, кто и на каком основании включает участника, где хранится подтверждение права на покупку и как оно проверяется при каждом обращении.
• Правила распределения — лимиты на участника и на этап, очерёдность выдачи при перегрузке сети, поведение при частичном заполнении и при досрочном закрытии раунда.
• Конфигурация окружений — параметры сетей, адреса развёрнутых контрактов, ключи доступа к узлам и сервисам наблюдения, разделённые на тестовый и рабочий контуры.
• Регламент обновлений — порядок правок: кто готовит, кто подтверждает, как проверяется на тестовом контуре, как выполняется откат, если проверка не прошла.
• Документация по контракту — назначение методов, перечень событий, известные ограничения и допущения, чтобы новый разработчик входил в проект без обращений к нам.
• Инструкция по инцидентам — признаки типовых сбоев, точки контроля, порядок действий по каждому сценарию и граница, за которой подключается наш инженер.
• Ведомость доступов — учётные записи, роли и права с указанием владельца каждого пункта, чтобы при смене сотрудника доступы не терялись.

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

Кейс: пиковая нагрузка без ручной модерации участников

На проекте Aurum Launchpad до запуска допуск в белый список держался на ручной модерации. Координатор сверял адреса кошельков с таблицей и вносил их в контракт отдельными вызовами — на пике поток заявок шёл в несколько тысяч обращений в минуту, обработка не успевала, очередь на допуск росла, часть участников видела ошибку и просто закрывала страницу. Каждая правка требовала вмешательства человека: риск занести чужой адрес, оставить дубль или пропустить бота, а разбор спорных заявок занимал до суток.

Что именно изменили

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

Метрики до и после

Пик в одиннадцать тысяч обращений за первые десять минут прошёл без отказов: все корректные заявки подтвердились автоматически, ручных правок — ноль. Медианное время от подписи до допуска сократилось с четырёх минут до трёх секунд, обращения в поддержку с формулировкой «не могу попасть в список» — в шесть раз меньше. Ошибки допуска (чужой адрес, дубль, прошедший фильтр бот) ушли как класс.

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

Что делать, если контракт уже развёрнут и менять его нельзя

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

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

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

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

Частые технические вопросы: допуск, нагрузка, обновления

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

Выдержит ли страница одновременный заход тысяч участников?

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

Сможем ли мы сами менять правила продаж?

Да, если параметры вынесены в конструктор контракта: длительность этапов, вилки распределения, лимиты и паузы меняются административной ролью без пересборки. Границы правок прописываются заранее — что меняется, до какого момента и что фиксируется после первой покупки. Роль администратора можно держать на мультисиге или под таймлоком.

Обсудим задачу: вернёмся с оценкой и планом работ

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

• Цель сбора и модель распределения: доли, лимиты на один кошелёк, кому и в каком порядке открывается доступ.
• Правила раунда: фиксированная цена или диапазон, время старта и закрытия, что происходит при недоборе.
• Список допущенных адресов: сколько их, откуда приходят, нужен ли Merkle-корень и как часто он обновляется.
• Сеть и активы: где выпускается токен, принимаете нативный актив или стейблкоин, нужен ли возврат средств.
• Что показываем в реальном времени: прогресс сбора, счётчик участников, таймер, статус подключённого кошелька.
• Доступы и управление: кто подписывает развёртывание, нужна ли мультиподпись и пауза на случай инцидента.
• Ожидаемая нагрузка: сколько людей зайдёт в первые минуты, нужны ли ограничения частоты запросов к контракту.
• Что уже готово: макеты, домен, аналитика, юридические формулировки на странице.

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