# 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 как homeserver с ключами

Что сделать:

- дописать прошивку, чтобы устройство могло выступать homeserver с ключами;
- дать ему возможность регистрироваться и подключаться к серверу;
- определить, какие операции устройство подписывает и где хранит ключевой материал.

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