# Синхронизация blockchain между SHiNE-серверами

## Локальная модель хранения

PostgreSQL является единственным локальным хранилищем пользовательских блоков. Файлы `<blockchain>.bch`, `.tmp_bch`, `.write_pending`, `.write_check`, `.resync_pending` не используются.

`blocks.block_bytes` хранит полный подписанный ANS-104 DataItem. `blockchain_state` хранит текущую вершину цепочки.

## Обычный AddBlock

Все проверки и запись выполняются под lock конкретной chain. После проверки Frame v1, подписи и `prevHash` одна SQL-транзакция записывает block + derived state + новую вершину.

Локально созданный пользовательский блок получает `arweave_publish_pending=true`.

## Периодический peer-to-peer sync

Старый межсерверный P2P sync может получать `GetBlockchainBlock` и применять полученный полный DataItem через `AddBlock`. При divergence full-resync:

1. берёт lock chain;
2. очищает derived rows/blocks/state через `BlockchainResyncCleanupDAO`;
3. пересоздаёт state из актуального пользовательского реестра;
4. последовательно проигрывает удалённую цепочку с блока 0;
5. никаких файловых swap/recovery операций нет.

## Arweave sync

Дополнительно каждый сервер может независимо включить `ArweaveBlockSyncScheduler`.

Он ищет child DataItems по тестовому тегу `App=test5590`, проверяет их и импортирует через ту же бизнес-проверку AddBlock. Импортированные блоки не публикуются повторно.

Если блоки обнаружены не по порядку, persistent queue оставляет более поздние блоки pending до появления предыдущих.

## Источник истины для цепочки

Arweave не участвует в вычислении SHiNE chain hash:

```text
block_hash = SHA256(FrameV1Bytes)
next.prevHash32 = block_hash
```

Поэтому цепочка остаётся проверяемой и переносимой независимо от конкретного storage backend.