1) Scripts et outils existants

• HTTP pull : backend/OBB_node_K/tools/sync_mock.py télécharge les nouveaux blocs (/chain/blocks/{id}) puis les importe via lAPI admin.
• Mode clé USB : export blocks/*.json et tx_pool/ sur support amovible, import automatique à larrivée (station K ou station H).
• LuckyBlocks : les manifests contiennent déjà ladressage complet (Pays Station S) afin que les proxys civiques puissent rerouter un bloc vers la commune correcte si le PCC cible est en déplacement.

2) Quotas, priorités et buffers

• Classes P0P3 : blocs critiques (alertes) passent avant les archives longues.
• Quotas par lien : réglage à faire (TODO) pour éviter quun backhaul saturé bloque les flux citoyens.
• Buffers locaux : chaque station K maintient outbox/blocks, outbox/docs et outbox/luckyblocks pour séparer chaînes, documents et pièces jointes.

3) Résolution de conflit & PoA local

• Règle actuelle : chaîne la plus longue + hash valide + signature PCC connue.
• Préparation PoA : possibilité de co-signer les blocs (PCC + station K + témoin voisin). Une infobulle «?» explique PoA au besoin ?.
• Journal des divergences : les scripts consigneront les forks détectés dans logs/sync_conflicts.log pour audit.

4) Flux type

1. La commune A mine un bloc (00000012.json), lajoute à outbox/blocks.
2. Un LuckyBlock P2 embarque ce bloc + un digest de chaîne et part via bus/ESP32-3248S035.
3. La commune B reçoit le LuckyBlock, vérifie signatures, compare head puis importe.
4. Si B est en avance, son script HTTP expose les blocs manquants pour quA rattrape la chaîne dès que possible.

Ce cycle fonctionne aussi via backhaul 5GHz (phase réseau V3/V4) ou via simple clé USB.

5) formaliser

• Quorum PoA (nombre minimal de signatures pour considérer un bloc «finalisé»).
• Compression/lotissement des blocs dans les LuckyBlocks (actuellement 1:1, peut évoluer vers paquets multi-blocs).
• API résumée (/chain/checkpoint) pour annoncer «jai tel hash à tel height» sans transférer tous les blocs.