# `back32Hash32` — глобальная резервная ссылка SHiNE Статус: **реализовано для общей пользовательской цепочки**. Отдельный `back32` для логических линий намеренно не добавляется. ## Правило Каждый SHiNE Frame содержит: ```text [32] prevHash32 [32] back32Hash32 ``` `prevHash32` остаётся основной соседней связью `N -> N-1`. `back32Hash32` — дополнительная резервная связь: ```text N < 32 -> ZERO_HASH_32 N >= 32 -> SHA256(Frame блока N-32) ``` Номер блока для этой ссылки отдельно не хранится: он всегда равен `blockNumber - 32`. Поэтому дополнительных 4 байта номера нет. Стоимость механизма — **ровно +32 байта на каждый глобальный блок**. ## Зачем Если соседний DataItem недоступен у конкретного gateway/CDN/сервера, обычная проверка через `prevHash32` прерывается. `back32Hash32` даёт второй криптографический мост к более ранней части истории. Это не восстанавливает отсутствующий блок и не доказывает его содержимое, но позволяет связать доступный последующий участок с историей на 32 блока раньше. Пример: ```text block #100 prevHash32 -> HASH(#99) back32Hash32 -> HASH(#68) ``` Для первых 32 блоков: ```text #0 ... #31 -> back32Hash32 = ZERO_HASH_32 #32 -> HASH(#0) #33 -> HASH(#1) ``` Сервер при `AddBlock` обязан сам проверить это поле по сохранённому блоку `N-32`; клиентское значение не принимается на доверии. ## Почему без `back32` внутри линий CHANNEL / TECH / CONNECTION / USER_PROFILE уже имеют собственные `prev...BlockNumber`, `prev...Hash32` и sequence. Эти линии — дополнительный способ выборочной загрузки и проверки поверх основной пользовательской цепочки. Если в выборочно скачанной линии обнаружена дырка, блоки всё равно можно криптографически проверить через глобальную цепочку, где уже есть `prevHash32 + back32Hash32`. Поэтому добавлять ещё +32 байта в каждый line-based body сейчас нецелесообразно. Если когда-нибудь появится требование полностью проверять отдельный канал/профиль без доступа к глобальной цепочке даже через недоступный line-блок, line-back32 можно рассмотреть отдельной новой версией body.