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:

SHiNE + login + initialBlockchainKey32

initialBlockchainKey32 — public blockchain-signing key fork №1. Это только историческая запись происхождения цепочки. При смене ключа сохранённый префикс, включая HEADER, перепубликуется с тем же Frame; поле остаётся исходным ключом и не сравнивается с текущим ключом fork. Текущий ключ конкретного fork определяется подписью/owner и PDA.

3. Внешний target

Для REPLY, RATING, REPOST, LIKE/UNLIKE, CONNECTION, STATUS_ACTION:

[1]  toLoginLen
[N]  toLogin UTF-8
[2]  toForkNumber uint16
[4]  toBlockGlobalNumber
[32] toBlockHash32

toForkNumber — информационная историческая метка: fork, на который смотрел автор действия. Допустимы только реальные fork 1..999; 0 запрещён. Поле не участвует в identity и не должно сравниваться с текущим active fork как условие валидности.

Логическая identity цели:

toLogin + toBlockGlobalNumber + toBlockHash32

Если сохранённый префикс перепубликован в новом fork байт-в-байт, номер блока и SHA-256(Frame) совпадают, поэтому внешняя ссылка продолжает указывать на тот же логический блок.

4. Собственный edit

EDIT_POST и EDIT_REPLY относятся только к собственному blockchain и используют:

[4]  toBlockGlobalNumber
[32] toBlockHash32

Login/fork не хранятся. Целевой оригинальный блок должен существовать в текущей ветке с тем же hash. Блок, отброшенный rollback и отсутствующий в новом active fork, редактировать из новой ветки нельзя.

5. CONNECTION на пользователя

Связь на пользователя всегда указывает на его реальный HEADER:

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, это новая логическая цель.

4.6 KiB Raw Blame History Unescape Escape