SHiNE-server/DAO_запуск/README.md

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. после этого делать синхронизацию, архив и восстановление.