Files
SHiNE-server/docs/Blockchain/sync-between-servers.md
T

43 lines
2.6 KiB
Markdown

# Синхронизация 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.