Это описание и блок-схема отражают архитектуру системы после внесенных правок, которые устранили петли репликации и обеспечили консистентность хэш-цепочек.

[psqlmaster]

Gorgona представляет собой децентрализованную P2P-сеть для безопасной доставки зашифрованных сообщений. Основная задача системы - обеспечить синхронизацию данных между узлами в условиях отсутствия центрального сервера и при наличии сложных сетевых топологий, таких как Docker-контейнеры и NAT.

Для достижения строгого порядка сообщений используется SnowflakeID, который позволяет каждой ноде мгновенно определять место записи в истории без координации с другими участниками. Целостность данных гарантируется механизмом XXH3 Hash Chaining: каждый новый блок математически связан с предыдущим, что делает базу данных устойчивой к подмене и позволяет легко проверять идентичность истории на разных узлах через сравнение финального хэша.

Внесенные изменения решают критическую проблему широковещательных штормов в P2P-сетях. Благодаря внедрению логического фильтра Gossip Gate и учету метаданных узлов на втором уровне управления, система теперь четко разграничивает процесс синхронизации старой истории и распространение новых событий в реальном времени. Это исключает бесконечное дублирование трафика и гарантирует, что каждый узел кластера придет к идентичному состоянию кратчайшим путем.

Подробная техническая документация доступна по ссылке:

https://github.com/psqlmaster/gorgona/blob/master/docs/replication.md

Ознакомиться с работой системы через панель управления можно здесь:

https://46.138.247.148:8000/

Данные для входа:

Username: demo

Password: demo

[psqlmaster]

📢 Что изменилось в новой версии gorgonad

В предыдущих релизах при перезапуске ноды наблюдался неприятный эффект: логи мгновенно заполнялись предупреждениями CHAIN HEALING, Divergence too deep и Replay attack, а ноды начинали бесконечно обмениваться Full Sync, хотя данные на диске были полностью актуальны. Корневая причина крылась в том, что при загрузке базы алерты считывались в порядке их физического поступления на диск (append-only), а не по их Snowflake ID. Из-за этого массив в памяти оказывался неотсортированным, бинарный поиск find_alert_index_by_id возвращал некорректные результаты, а last_hash указывал на хеш алерта, который просто последним пришёл в сеть, а не на истинный хвост логической цепи. В результате пиры при подключении видели расхождение в вершинах цепей и инициировали тяжёлую полную синхронизацию, которая, в свою очередь, триггерила ложные срабатывания механизмов лечения цепи и защиты от replay-атак.

В текущем релизе проблема решена: после загрузки записей с диска массив алертов принудительно сортируется по ID через qsort, а last_hash теперь вычисляется как хеш последнего элемента отсортированного массива - то есть алерта с максимальным Snowflake ID. Это гарантирует, что все ноды кластера, имеющие одинаковый набор алертов, будут сообщать пирам идентичную вершину цепи, и протокол синхронизации больше не будет уходить в бесконечный цикл Full Sync. Важно отметить, что сами хеши цепи при загрузке не пересчитываются - они остаются ровно такими, какими были записаны на диск, что сохраняет совместимость с другими нодами кластера и избегает каскадных расхождений. Для пользователей это означает чистый старт без шторма логов, предсказуемое поведение при рестарте и стабильную работу P2P-синхронизации.
64ca8d6

[psqlmaster]

проверку сплитбрейна в детерменированой сети можно провести отключая ноду от меш сети скриптом

iptables -A INPUT  -s 192.168.1.10 -j ACCEPT && \
iptables -A OUTPUT -d 192.168.1.10 -j ACCEPT && \
iptables -A INPUT  -p tcp --dport 22 -j ACCEPT && \
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT && \
iptables -P INPUT DROP && \
iptables -P OUTPUT DROP && \
echo "Node isolated. Rollback in 300s" && \
sleep 100 && \
iptables -P INPUT ACCEPT && \
iptables -P OUTPUT ACCEPT && \
iptables -F && \
echo "Network restored"

оствив исключение для 22 порта, чтобы смотреть логи, и IP вашего хоста, пример 192.168.1.10
с которого на изолированную ноду вы отправите тестовое сообщение, пример:

gorgona send "$(date -u '+%Y-%m-%d %H:%M:%S')" "$(date -u -d '+30 days' '+%Y-%m-%d %H:%M:%S')" "test 2" "4YzEYpwB9hc=.pub"
Server Result: Alert ID: 219260995915776 added successfully

пока идет таймер sleep 100 вы должны отправить на другую ноду на этот же адрес, первое тестовое сообщение:

gorgona send "$(date -u '+%Y-%m-%d %H:%M:%S')" "$(date -u -d '+30 days' '+%Y-%m-%d %H:%M:%S')" "test 1" "4YzEYpwB9hc=.pub"
Server Result: Alert ID: 219260927856640 added successfully

когда закончится таймер первого скрипта сеть восстановиться между нодами и в логах ноды которая до этого была в изоляции вы увидите процесс восставновления ее хеш цепочки после форка, при этом по сети будут переданы только алерты от алерта который имеет предка в цепочке (алертов)блоков с общим хешем.
пример лога с ноды после форка:

2026-09-12 13:35:16 UTC [INFO] [fd:21] [192.168.1.10:33514] Alert 219260995915776 added to chain at pos 7 [APPEND] [Hash: 0x89bd9f1d5c47a1f8]
2026-09-12 13:35:16 UTC [INFO] [fd:21] [192.168.1.10:33514] Client disconnected
2026-09-12 13:36:31 UTC [INFO] [fd:-1] [192.168.1.1:7777] Layer 2 GC: Removing unresponsive PEX node from memory
2026-09-12 13:36:50 UTC [INFO] [fd:20] [192.168.1.171:7777] Alert 219260927856640 added to chain at pos 7 [BACKFILL] [Hash: 0x1755f33b65e2cfdb]

вывод подписчика на этой ноде последних 2х алертов из меш сети по этому ключу:

gorgona -v listen new 4YzEYpwB9hc=

[2026-09-12 13:33:33 UTC] [INFO] [46.138.247.148:7777] Connection established
[2026-09-12 13:33:33 UTC] [INFO] Mesh Status: AUTH_SUCCESS|1000|7776000
Server: Subscription updated
[2026-09-12 13:33:56 UTC] [DEBUG] L2 Decrypted on Client: 
Received Alert: Recipient_Hash=4YzEYpwB9hc=
Alert ID: 219260927856640
Hash in the chain: 15371510522798048946
Timestamps (Local): Created: 2026-09-12 15:34:59, Unlock: 2026-09-12 15:34:59, Expire: 2026-10-12 15:34:59
Расшифрованный ключ AES (hex, len=32): 71374c4c060aed639b5634801653058e453e2582a22bb2d403de0bc6695ebd4e
Decrypted Content:
test 1
[2026-09-12 13:36:08 UTC] [DEBUG] L2 Decrypted on Client: PEX_LIST|7777|192.168.1.1:7777|46.138.247.148:7777|64.188.70.158:7777|192.168.1.172:7777|192.168.1.170:7777|
[2026-09-12 13:36:08 UTC] [INFO] [192.168.1.170:7777] L2 Mesh: New neighbor discovered
Received Alert: Recipient_Hash=4YzEYpwB9hc=
Alert ID: 219260995915776
Hash in the chain: 17545453266915102433
Timestamps (Local): Created: 2026-09-12 15:35:16, Unlock: 2026-09-12 15:35:16, Expire: 2026-10-12 15:35:16
Расшифрованный ключ AES (hex, len=32): 797a1c8d00b6d4255cec92bf9b7a8cec5973e2016b7a06faeb6b41065d5345e4
Decrypted Content:
test 2

имеем идеальную картину разница между отправкой алертов была 17сек, в реальном времени что имеем после синхронизации цепочки на ноде

Hash in the chain: 15371510522798048946
Timestamps (Local): Created: 2026-09-12 15:34:59
Hash in the chain: 17545453266915102433
Timestamps (Local): Created: 2026-09-12 15:35:16

недоступность ноды составляла 100сек. первое сообщение в доступную меш было отправлено, после отключения сети у ноды и второе на ноду пока она еще была в 100сек интервале недоступности, т.е. после того как она верулась в сеть(проходит 100 секунд, iptables сбрасываются) она переписала свое прошлое до предка с общим хешем и отправил в сеть алерт который был на нее отправлен в период ее недоступности, сохранив полную детерменированность всей меш сети.

изолированная нода: раздвинула массив памяти, вставила test 1 перед своим test 2, а затем каскадно пересчитала хэш для test 2, сделав его потомком test 1.

---

Шаг 1. Момент изоляции (Рождение временного форка)

В 15:35:16 на изолированную ноду приходит test 2 (ID: ...915776).
Нода не знает, что в основной сети 17 секунд назад уже был создан test 1.
Она смотрит на свой последний доступный алерт (назовем его Предком №6):

1. Кладет test 2 в позицию pos 7 [APPEND].
2. Привязывает его prev_hash = Хэш Предка №6.
3. Вычисляет временный хэш для test 2: 0x89bd9f1d5c47a1f8.

В этот момент в сети возник форк (развилка):

• Основная сеть: [Предок 6] -> [test 1]
• Изолированная нода: [Предок 6] -> [test 2]

---

Шаг 2. Восстановление сети и сверка предков

Проходит 100 секунд, iptables сбрасываются.
Изолированная нода связывается с мешем (с нодой 192.168.1.171).

1. Ноды обмениваются верхушками цепи: хэши не сходятся.
2. Алгоритм process_chain_sample отматывает историю назад и находит Общего Предка №6 — алерт, у которого и ID, и хэш совпадают на обеих сторонах.
3. Нода из меша отправляет изолированной ноде всё, что появилось после Предка №6 — то есть алерт test 1 (ID: ...927856640).

---

Шаг 3. Магия BACKFILL и сдвиг памяти (memmove)

Изолированная нода получает test 1 в функции add_alert():

1. Она сравнивает Snowflake ID:
   $$ID_{test 1} (219260927856640) < ID_{test 2} (219260995915776)$$
   Алерт test 1 был создан на 17 секунд раньше, чем test 2!
2. Бинарный поиск find_insert_position() говорит: «Место алерта test 1 — строго в позиции 7!»
3. Сервер видит, что позиция 7 уже занята алертом test 2.
   Срабатывает ветка:

   /* Shift memory to accommodate the new alert */
   memmove(&rec->alerts[insert_pos + 1], &rec->alerts[insert_pos], ...);

   Нода физически сдвигает алерт test 2 в памяти из позиции 7 в позицию 8!
4. В освободившуюся позицию 7 записывается test 1.
   В логе появляется ключевая строка:

   Alert 219260927856640 added to chain at pos 7 [BACKFILL] [Hash: 0x1755f33b65e2cfdb]
   

---

Шаг 4. «Машина времени» и пересчет хэша (alert_chain_process_insertion)

Как только test 1 лег в позицию 7, запускается цикл пересчета цепи:

/* 1. test 1 привязывается к общему Предку №6 */
new_alert->prev_hash = rec->alerts[6].curr_hash;
new_alert->curr_hash = alert_chain_compute_link(...); // стал 15371510522798048946

/* 2. Каскадный пересчет ВСЕХ последующих алертов */
uint64_t running_prev = new_alert->curr_hash;
for (int i = pos; i < rec->count; i++) {
    Alert *cur = &rec->alerts[i]; // здесь наш сдвинутый test 2 (на pos 8)
    cur->prev_hash = running_prev; // ЕГО РОДИТЕЛЕМ СТАНОВИТСЯ test 1!
    cur->curr_hash = alert_chain_compute_link(cur->id, cur->prev_hash, cur->content_hash);
}

Что произошло с хэшем test 2:

• Во время изоляции его хэш был: 0x89bd9f1d5c47a1f8 (он опирался на Предка №6).
• После возвращения в сеть его хэш был пересчитан и стал: 17545453266915102433 (потому что теперь он опирается на test 1).

---

Шаг 5. Завершение консенсуса

1. Изолированная нода исцелила свою цепочку:
   $$\text{Предок 6} \longrightarrow \text{test 1 (pos 7)} \longrightarrow \text{test 2 (pos 8)}$$
2. После этого изолированная нода делает broadcast_replication своего алерта test 2 обратно в меш.
3. Ноды меша принимают test 2 уже как [APPEND] в позицию 8 поверх test 1.

ИТОГ:

Успешно была реализована и подтверждена стресс-тестами (через искусственную 100-секундную изоляцию ноды) модель детерминированной Eventual Consistency на чистом Си: сеть автоматически и бесшовно ликвидирует форки при сетевых сбоях («сплит-брейн»), выполняя локальный ребейз цепочки по Snowflake ID без единого потерянного байта. Для сообщества это означает абсолютную отказоустойчивость при околонулевом потреблении ресурсов: ноды могут терять связь, работать в изолированных сегментах и возвращаться в меш в любой момент -> кластер за миллисекунды математически восстановит хронологию и сойдется к единому состоянию сам, без ручного вмешательства, без риска потери данных и без раздутых механизмов вроде Raft или блокчейн-консенсусов, сохраняя сквозное E2E-шифрование нетронутым.
Парадокс отсечения головы:
Классический блокчейн или Git не умеют в плавающее окно - их цепочки бесконечно растут, пожирая диск (весь Биткоин весит ~800 ГБ, история Git тянется вечно).
А классические системы с плавающим окном (Redis, Kafka, кольцевые буферы) выбрасывают криптографические хэш-цепочки, потому что при удалении старых записей якорь цепочки теряется.
Теперь это решено.