Очень сильно переделать формат блоков

Внимание: версия ещё не проверена.
2026-10-01 09:34:19 +03:00
parent 08c7fd7676
commit 3281da7f5c
65 changed files with 1863 additions and 2743 deletions
@@ -0,0 +1,77 @@
+# Key rotation, fork и логические ссылки
+
+Этот документ фиксирует протокольную семантику fork. API-последовательность ротации описана отдельно в `docs/API/19_Key_Rotation_API.md`.
+
+## 1. Идентичности
+
+- Пользователь: `login`.
+- Физическая ветка: `login-forkNumber` (`1..999`, формат имени строго три цифры: `001..999`; fork `1000` и выше запрещён).
+- Активный fork определяется текущим PDA.
+- Исторические fork остаются проверяемыми.
+
+## 2. HEADER
+
+Block 0 новой пользовательской истории — `HEADER`:
+
+```text
+SHiNE + login + initialBlockchainKey32
+```
+
+`initialBlockchainKey32` — public blockchain-signing key fork №1. При смене ключа сохранённый префикс, включая HEADER, перепубликуется с тем же Frame; поэтому это поле остаётся исходным ключом, а новый ключ конкретного fork определяется подписью/owner и PDA.
+
+## 3. Внешний target
+
+Для REPLY, RATING, REPOST, LIKE/UNLIKE, CONNECTION, STATUS_ACTION:
+
+```text
+[1]  toLoginLen
+[N]  toLogin UTF-8
+[2]  toForkNumber uint16
+[4]  toBlockGlobalNumber
+[32] toBlockHash32
+```
+
+`toForkNumber` — информационная историческая метка: fork, на который смотрел автор действия. `0` зарезервирован как unknown/legacy и не является реальным fork. Поле не участвует в identity и не должно сравниваться с текущим active fork как условие валидности.
+
+Логическая identity цели:
+
+```text
+toLogin + toBlockGlobalNumber + toBlockHash32
+```
+
+Если сохранённый префикс перепубликован в новом fork байт-в-байт, номер блока и SHA-256(Frame) совпадают, поэтому внешняя ссылка продолжает указывать на тот же логический блок.
+
+## 4. Собственный edit
+
+EDIT_POST и EDIT_REPLY относятся только к собственному blockchain и используют:
+
+```text
+[4]  toBlockGlobalNumber
+[32] toBlockHash32
+```
+
+Login/fork не хранятся. Целевой оригинальный блок должен существовать в текущей ветке с тем же hash. Блок, отброшенный rollback и отсутствующий в новом active fork, редактировать из новой ветки нельзя.
+
+## 5. CONNECTION на пользователя
+
+Связь на пользователя всегда указывает на его реальный HEADER:
+
+```text
+toLogin = target login
+toBlockGlobalNumber = 0
+toBlockHash32 = SHA-256(target HEADER Frame)
+```
+
+Нулевой hash как sentinel запрещён.
+
+## 6. Что переносится при fork
+
+Для сохранённого префикса Frame не меняется. Могут измениться внешняя ANS-104 подпись, owner/DataItem ID, но SHiNE block hash (`SHA-256(Frame)`) остаётся прежним. Поэтому `number + hash` является устойчивой частью ссылки.
+
+`toForkNumber` старого действия не переписывается после fork: это исторический факт момента создания действия.
+
+## 7. Серверная модель Stage 2
+
+Stage 2 больше не хранит physical target name как identity. `blocks_store` хранит физическую ветку как `(login, fork_number)`, а `reactions_state`, `message_stats`, `connections_state` и просмотры адресуют цель логически через `login + blockNumber + hash`. Поэтому при смене active fork никакого массового rebind `old_bch_name -> new_bch_name` не выполняется.
+
+Если `number + hash` сохранились после fork, внешние состояния продолжают относиться к той же цели автоматически. Если hash изменился после rollback, это новая логическая цель.