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