Обновить Telegram-бота, документацию и связанные доработки

2026-06-06 13:45:02 +04:00
parent ce5c348023
commit c5ec32f87a
16 changed files with 772 additions and 56 deletions
@@ -0,0 +1,255 @@
+# DAO_запуск
+
+Рабочий документ по тому, что ещё нужно сделать для первого запуска DAO-сценария SHiNE.
+
+Логика документа:
+
+- `этап1` — то, без чего нельзя считать сценарий первого запуска собранным даже в тестовом виде;
+- `этап2` — то, что полезно и, вероятно, потребуется дальше, но это можно делать после старта `этап1` или параллельно без блокировки первого результата.
+
+Базовая среда первого прохода:
+
+- сеть `Solana devnet`;
+- модель синхронизации: `server-to-server`;
+- `Solana + Arweave` используются как якорь и архив;
+- DAO понимается как стандартный governance/smart-contract контур, который управляет отдельными программами SHiNE, приносящими деньги.
+
+## Краткий вывод
+
+Для первого запуска DAO в тестовом виде текущего списка в целом хватает, но только если понимать запуск как:
+
+- можно развернуть и проверить базовый DAO-контур;
+- можно зарегистрировать пользователей и ключевые сущности;
+- можно провести тестовую покупку билета через smart contract;
+- можно завести тестовый денежный поток в программы, управляемые DAO;
+- можно проверить опорную межсерверную синхронизацию и фиксацию состояния в архивный слой.
+
+Если же под "запуском" понимать уже полностью устойчивую production-схему с ротацией ключей, восстановлением любого сервера из архива, железными устройствами подписи и полным циклом администрирования, то текущий список нужно будет ещё расширять.
+
+## Этап1
+
+Цель этапа: собрать минимально жизнеспособный DAO-сценарий в `devnet`, который можно пройти руками от регистрации до базовой экономики и проверки архитектуры.
+
+### 1. Переписать и стабилизировать регистрацию пользователей без Anchor
+
+Что сделать:
+
+- довести `shine_users` в чистом Rust/Solana SDK до рабочего и проверенного состояния;
+- убедиться, что `shine_login_guard` и связанный сценарий регистрации совместимы с новым ABI;
+- проверить создание и чтение `user_pda`;
+- проверить update пользовательской записи и связанные экономические параметры;
+- синхронизировать сервер, UI и lazy-import с новым форматом и seed'ами.
+
+Почему это в `этап1`:
+
+- без стабильной пользовательской регистрации дальше нельзя строить ни DAO-сценарий, ни привязку устройств, ни платёжные сценарии.
+
+### 2. Проверить полный сценарий регистрации и базовой Solana-интеграции
+
+Что сделать:
+
+- руками прогнать регистрацию нового пользователя;
+- руками прогнать создание и update server PDA там, где это требуется текущему сценарию;
+- убедиться, что сервер читает новые PDA без anchor-зависимостей и без старых discriminator'ов;
+- зафиксировать, какие именно части сценария уже подтверждены руками, а какие ещё нет.
+
+Почему это в `этап1`:
+
+- сейчас в проекте уже есть признаки перехода на pure Rust, но без ручной проверки это нельзя считать завершённым.
+
+### 3. Создать стандартный DAO smart contract / governance-контур
+
+Что сделать:
+
+- определить и реализовать стандартный DAO-контур, который будет управлять программами SHiNE;
+- зафиксировать, какие права сразу передаются DAO, а какие временно остаются на отдельных ключах;
+- подготовить тестовую DAO-структуру в `devnet`.
+
+Минимум для первого запуска:
+
+- DAO существует как управляемая сущность;
+- DAO может владеть или контролировать ключевые права управления денежными программами;
+- есть понятный путь, как DAO влияет на доходные программы SHiNE.
+
+Почему это в `этап1`:
+
+- без этого "DAO-запуск" будет только запуском отдельных Solana-программ, но не запуском управляемой DAO-системы.
+
+### 4. Доработать смарт-контракт выплат с третьей очередью
+
+Что сделать:
+
+- добавить в `shine_payments` третью очередь, о которой уже принято решение;
+- проверить совместимость с текущей моделью тикетов, выплат и DAO-управления;
+- убедиться, что логика очередей соответствует ожидаемой экономике проекта.
+
+Почему это в `этап1`:
+
+- по текущей постановке это нужно именно для сценария регистрации DAO и дальнейшей экономики.
+
+### 5. Сделать UI для покупки билетов и просмотра очереди
+
+Что сделать:
+
+- добавить UI-сценарий покупки билетов через smart contract;
+- показать пользователю, сколько перед ним человек в очереди;
+- убедиться, что UI отражает актуальное состояние контрактной логики, а не локальные предположения.
+
+Почему это в `этап1`:
+
+- покупка билетов у тебя обозначена как часть DAO-сценария, а не как побочная функция;
+- без UI можно тестировать контракт вручную, но нельзя считать сценарий запуска достаточно собранным для нормальной проверки.
+
+### 6. Реализовать базовую синхронизацию серверов
+
+Что сделать:
+
+- сделать обмен состоянием между серверами по модели `server-to-server`;
+- определить минимальный набор данных, который обязан синхронизироваться;
+- предусмотреть фиксацию синхронизированного состояния в `Arweave`, а `Solana` использовать как якорь и ссылочный слой;
+- описать, какой сервер считается источником истины в спорных случаях или как решается конфликт.
+
+Почему это в `этап1`:
+
+- без межсерверной синхронизации трудно обосновать архитектуру сети как воспроизводимую и переносимую;
+- это напрямую связано с идеей, что любой сможет поднять свой сервер.
+
+### 7. Подготовить базовый сценарий архивирования и восстановления
+
+Что сделать:
+
+- описать и частично реализовать схему: серверы синхронизируются между собой, архив состояния уходит в `Arweave`, ссылка/якорь фиксируется через `Solana`;
+- определить минимальный сценарий восстановления блоков или состояния из архивного слоя;
+- подтвердить, что новый сервер может получить достаточно данных для старта.
+
+Почему это в `этап1`:
+
+- это один из ключевых признаков независимой и воспроизводимой DAO-инфраструктуры.
+
+## Этап2
+
+Цель этапа: усилить безопасность, автономность и удобство системы после того, как минимальный DAO-сценарий уже запустился и проверен в `devnet`.
+
+### 1. Смена ключей цифровой подписи
+
+Что сделать:
+
+- продумать и реализовать смену `root key`, `device key`, `blockchain key`;
+- описать ограничения, кто и в каком сценарии может менять каждый тип ключа;
+- продумать, как не потерять доступ и как обновлять доверие к новым ключам.
+
+Почему это в `этап2`:
+
+- для production это очень важно;
+- для первого тестового запуска можно временно использовать фиксированный набор ключей.
+
+### 2. Полная повторная перепроверка всех сценариев
+
+Что сделать:
+
+- повторно прогнать регистрацию, DAO, выплаты, билеты, синхронизацию и архивирование после стабилизации `этап1`;
+- оформить итоговый чек-лист ручной проверки;
+- отдельно проверить пограничные сценарии и восстановление после ошибок.
+
+Почему это в `этап2`:
+
+- это обязательный шаг перед переходом от "собрали" к "доверяем".
+
+### 3. Устройство на ESP32 как сабсервер с ключами
+
+Что сделать:
+
+- дописать прошивку, чтобы устройство могло выступать сабсервером с ключами;
+- дать ему возможность регистрироваться и подключаться к серверу;
+- определить, какие операции устройство подписывает и где хранит ключевой материал.
+
+Почему это в `этап2`:
+
+- это очень сильное развитие архитектуры, но оно не должно блокировать первый DAO-запуск.
+
+### 4. Логин и подпись через коробочки / устройства
+
+Что сделать:
+
+- реализовать сценарий входа через устройство или хотя бы сценарий подписи сообщений и ключей через устройство;
+- определить, как это встраивается в регистрацию DAO и подтверждение действий;
+- проверить, можно ли через это безопасно регистрировать DAO или подписывать критичные команды.
+
+Почему это в `этап2`:
+
+- это следующий уровень безопасности и UX, но не минимальный блокер первого старта.
+
+### 5. Создание тестового DAO с использованием устройств подписи
+
+Что сделать:
+
+- после готовности устройств собрать тестовый DAO-сценарий уже с аппаратным участием;
+- проверить, где устройство достаточно, а где всё ещё нужен обычный кошелёк или управляющий ключ.
+
+Почему это в `этап2`:
+
+- это проверка усиленной модели, а не базового старта.
+
+### 6. Расписание синхронизации серверов
+
+Что сделать:
+
+- определить периодичность и правила фоновой синхронизации;
+- продумать ручной и автоматический режим;
+- решить, как часто публиковать архивные снимки и якоря.
+
+Почему это в `этап2`:
+
+- сначала важнее добиться самой работающей синхронизации, а потом уже делать её регулярной и автономной.
+
+### 7. Полное восстановление блоков из Solana/Arweave
+
+Что сделать:
+
+- довести процедуру восстановления до сценария "любой может поднять свой сервер";
+- определить минимальный bootstrap-набор;
+- проверить восстановление на чистом окружении.
+
+Почему это в `этап2`:
+
+- для концепции сети это критично, но как полноценная задача обычно идёт после появления базового архива и первичной синхронизации.
+
+## Что блокирует первый запуск сильнее всего
+
+Если расставить приоритет внутри `этап1`, то самый жёсткий порядок сейчас выглядит так:
+
+1. pure Rust регистрация пользователей и ручная проверка сценария;
+2. DAO/gov-контур и его права управления;
+3. доработка выплат с третьей очередью;
+4. покупка билетов через smart contract и UI-проверка очереди;
+5. межсерверная синхронизация;
+6. архивирование в `Arweave` с якорем в `Solana`;
+7. минимальное восстановление состояния новым сервером.
+
+## Что уже частично похоже на готовое
+
+По текущим документам и следам в проекте уже видно, что:
+
+- переход `shine_users` и `shine_login_guard` на pure Rust уже начат и в значительной степени сделан;
+- архитектура DAO, `shine_users` и `shine_payments` уже описана;
+- часть Solana-структуры и PDA-форматов уже формализована;
+- тема ESP32 уже отдельно присутствует в проекте как направление.
+
+Это хорошо, потому что документ получается не "с нуля", а как сборка того, что уже назрело в коде и планах.
+
+## Вопросы, которые всё ещё стоит уточнить
+
+1. Какой именно стандарт DAO планируется использовать в первом проходе: готовый governance-стек Solana или собственная минимальная обвязка вокруг управляющих кошельков?
+2. Третья очередь в `shine_payments` уже точно определена по смыслу, или пока есть только решение "она нужна", но без финальной экономики?
+3. Что именно считается единицей синхронизации между серверами: блоки SHiNE, агрегированные снапшоты, PDA-состояния, или смесь этих вариантов?
+4. Нужен ли для `этап1` уже полноценный автоматический recovery нового сервера, или достаточно доказать это в полу-ручном сценарии?
+5. Покупка билетов должна в первом проходе работать только через web/UI, или также нужен отдельный сценарий из серверного UI или скриптов?
+
+## Рекомендуемый следующий практический шаг
+
+Если идти без распыления, то следующим рабочим фокусом стоит считать:
+
+1. закрыть ручную проверку pure Rust регистрации;
+2. после этого формализовать минимальный DAO-контур;
+3. затем переходить к третьей очереди выплат и к UI покупки билетов;
+4. после этого делать синхронизацию, архив и восстановление.