Блокчейн-платформа: контракты, аудит и кабинет
Проект показываем обезличенно: без названия, отрасли и ссылок
Заказчику нужен был не просто выпущенный токен, а работающая платформа: контракты с собственной экономикой, личный кабинет с реферальной программой, сервис распределения выплат и внешний аудит, который можно показать держателям. Мы прошли весь путь — от первой версии контрактов до четвёртой, с переносом накопленного состояния между ними.
Задача
- Экономика проекта не сводилась к стандартному токену: нужны были комиссии с раздельным назначением, отложенная выдача долей по расписанию, многоуровневая реферальная сеть и правила, ограничивающие операции. Всё это — собственный код, который нельзя исправить после публикации, и который держатели вправе потребовать показать проверенным независимой стороной.
Что сделали
- Контракты с собственной экономикой: комиссии с раздельным назначением, хранилище сборов, правила операций
- Отложенная выдача долей по расписанию — с проверкой границ и невозможностью забрать раньше срока
- Реестр реферальной сети на стороне контракта: связи фиксируются в сети, а не в базе на сервере
- Разделение прав управления: критичные действия вынесены из-под одного ключа
- Подготовка к внешнему аудиту и сопровождение проверки, включая повторный проход после исправлений
- Личный кабинет: подключение кошелька, баланс, реферальная структура, история операций
- Бэкенд и отдельный сервис распределения выплат по расписанию
Результат
- Отчёт внешнего аудита, оформленный на двух языках и пригодный для публикации держателям
- Четыре версии контрактов с перенесённым состоянием: реферальные связи не потерялись при переходе
- Кабинет, в котором держатель видит свою структуру и историю без обращения в поддержку
- Выплаты идут по расписанию сервисом, а не запускаются человеком вручную
Почему версий получилось четыре
Опубликованный контракт не правится — любое изменение логики означает новый контракт и перенос всего, что успело накопиться. За время проекта экономика менялась трижды: уточнялись назначения комиссий, менялись правила операций, дорабатывалась реферальная механика. Каждый раз это был не патч, а новая версия с миграцией.
Самой дорогой частью миграции оказались не токены, а реферальная сеть. Балансы переносятся арифметикой, а сеть связей — это граф, который нужно перенести целиком и в правильном порядке: пригласивший должен появиться в новом контракте раньше приглашённого. Мы написали скрипты, которые выгружают граф из старого контракта, сортируют его и заливают порциями с проверкой каждой порции.
Что дал аудит и чего он не дал
К проверке мы шли подготовленными: стандартные библиотеки вместо собственных реализаций там, где это возможно, тесты на граничные значения и отдельный документ на человеческом языке — кто владелец, что он может, чего не может и как передаются права. Этот документ экономит аудитору больше всего времени, а оно и есть предмет оплаты.
Важная часть находок касалась не ошибок в коде, а централизации: мест, где один адрес может слишком много. Такие замечания закрываются не правкой логики, а организационно — разделением прав и задержкой перед исполнением критичных изменений. Отдельно закладывался повторный проход: правка серьёзной находки меняет логику, а новая логика никем ещё не читана.
Что осталось на бэкенде, а что ушло в сеть
Граница проводилась по одному правилу: в сеть уходит то, что должно быть проверяемым и неизменяемым, на сервер — то, что должно быть быстрым и изменяемым. Реферальные связи и правила начисления живут в контракте, потому что держатель вправе их проверить сам. Витрина кабинета, история операций и уведомления живут на сервере, потому что читать их из сети на каждый экран дорого и медленно.
Сервис распределения выплат вынесен отдельно от основного бэкенда сознательно: у него другой ритм работы и другая цена ошибки. Он запускается по расписанию, работает с ключом, у которого ограниченные права, и ведёт журнал каждой отправки — чтобы повторный запуск после сбоя не отправил вторую выплату.