2.6 KiB
Синхронизация 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:
- берёт lock chain;
- очищает derived rows/blocks/state через
BlockchainResyncCleanupDAO; - пересоздаёт state из актуального пользовательского реестра;
- последовательно проигрывает удалённую цепочку с блока 0;
- никаких файловых swap/recovery операций нет.
Arweave sync
Дополнительно каждый сервер может независимо включить ArweaveBlockSyncScheduler.
Он ищет child DataItems по тестовому тегу App=test5590, проверяет их и импортирует через ту же бизнес-проверку AddBlock. Импортированные блоки не публикуются повторно.
Если блоки обнаружены не по порядку, persistent queue оставляет более поздние блоки pending до появления предыдущих.
Источник истины для цепочки
Arweave не участвует в вычислении SHiNE chain hash:
block_hash = SHA256(FrameV1Bytes)
next.prevHash32 = block_hash
Поэтому цепочка остаётся проверяемой и переносимой независимо от конкретного storage backend.