SHiNE-server/docs/Blockchain/README.md

Документация блокчейна SHiNE (MVP)

Этот каталог описывает только текущий рабочий формат протокола для MVP.

Основные документы

1. 01_Common_Block_Format.md Единый бинарный формат блока (Frame v0), подпись, базовые проверки.
2. 02_Blockchain_Kinds_and_Lines.md Виды цепочек и правила line-полей.
3. 10_TECH_Blocks.md Системные блоки (msg_type=0).
4. 11_TEXT_Blocks.md Текстовые блоки (msg_type=1).
5. 12_REACTION_Blocks.md Реакции (msg_type=2).
6. 13_CONNECTION_Blocks.md Социальные связи (msg_type=3).
7. 14_USER_PARAM_Blocks.md Параметры пользователя (msg_type=4).
8. 15_STATUS_ACTION_Blocks.md Статусные действия пользователя (msg_type=5).
9. 16_TEXT_Attachments.md Вложения в TEXT-сообщениях через S:att v=1, включая опциональные preAr/preSha256 для видео и крупных изображений.
10. 16_TEXT_Channel_Meta.md Скрытый TEXT_CHANNEL_META для профиля канала.
11. 01_Channel_Types_and_CreateChannel.md Типы каналов и формат CreateChannelBody.
12. 02_Channel_Commands.md Команды в текстовых сообщениях каналов.
13. CHANGELOG.md Журнал изменений документации.

Смежная документация

• ../ИТХ/README.md — ежедневное закрытие блокчейна (ИТХ): краткий обзор.
• ../ИТХ/Спецификация_ИТХ_v1.md — точная спецификация чекпоинтов (Arweave/Solana/канал закрытий).
• sync-between-servers.md — живая межсерверная синхронизация блоков и DM.

Важные ограничения MVP

• Каналы type=100 и type=200 присутствуют в формате, но сейчас не используются в UI.
• Поддерживаемый рабочий сценарий UI на текущем этапе: stories (type=0) и public (type=1).

Обязательное сопровождение

• При любом изменении формата/правил блокчейна в коде документы этого каталога обновляются в том же наборе изменений.
• Обычный AddBlock сейчас пишет через <blockchainName>.tmp_bch, <blockchainName>.write_check и <blockchainName>.write_pending; эта схема и BlockchainTmpRecoveryOnStartup должны быть описаны в актуальной документации по синхронизации и recovery.
• Для runtime-агрегатов статистики user_stats_state и channel_stats_state действует тот же принцип derived state: они обновляются вместе с AddBlock и полностью пересобираются при full resync.
• Если в старых данных есть канал владельца, которого ещё нет в solana_user_pda_current, сервер не падает: channel_stats_state всё равно обновляется, а user_stats_state создаётся только после появления пользователя в Solana PDA.
• Каждое обновление документов фиксируется в CHANGELOG.md с датой/временем и хэшем коммита-основания.