mohawk-nexus

Mohawk Nexus est l'espace de travail d'intégration racine pour la pile réseau Mohawk. Il regroupe plusieurs composants dans un seul dépôt afin qu'ils puissent être construits, validés et testés ensemble. Structure de l'espace de travail - SMIP-MWP : plan de contrôle Go couvrant l'intégration hôte AF_XDP, le routage, les liaisons crypto et l'ingestion de requêtes bridge. - SMIP-MWP-Rust : datapath Rust avec un pipeline de forwarding, un plan de données haute performance et des outils CLI. - Sovereign-Mohawk-Proto : définitions de protocole, évolution du schéma et actifs de vérification formelle. - bridge : schéma bridge canonique, manifeste et exemples de requêtes utilisés par la validation racine. - scripts : assistants de génération, validation et test au niveau de l'espace de travail. - go.work relie les modules Go entre eux. Prérequis et installation Go (1.26.1 épinglé pour des builds reproductibles ; 1.22+ devrait fonctionner pour la plupart des workflows locaux), Python 3.8+, Docker pour les exécutions de performance/stress conteneurisées, et une chaîne d'outils Rust uniquement pour exécuter localement les tests du datapath Rust. Une configuration devcontainer épingle Go pour Codespaces/Dev Containers, et des instructions sont fournies pour une installation locale de Go sans sudo. Compatibilité des appareils Une matrice décrit les profils pris en charge : serveurs Linux x86_64 avec NIC compatibles AF_XDP (accéléré), serveurs/nœuds edge Linux arm64, Raspberry Pi/SBC ARM, machines de développement macOS et Windows, et Kubernetes managé sans pods privilégiés (portable). Le datapath AF_XDP accéléré est réservé à Linux ; les workflows portables couvrent le contrôle, les services FL et SWIP ainsi que la validation bridge. Les profils d'exécution sont portable, accéléré et expérimental. Utilisation Les cibles Make courantes incluent bootstrap, status, verify, generate-bridge, validate-bridge, verify-go, bridge-smoke et verify-rust. Un démarrage rapide FL local construit et exécute un coordinateur avec deux clients via docker-compose. Les harnais de performance et de stress s'exécutent via scripts/bench.sh et un Dockerfile de stress, en écrivant la sortie de benchmark et les artefacts pprof sous SMIP-MWP/benchmarks/. Capacités - Datapath haute performance : forwarder Rust plus intégration AF_XDP pour un traitement de paquets à faible latence. - Crypto enfichable : primitives symétriques et asymétriques avec chiffrement/déchiffrement en place pour réduire les allocations. - Validation du contrat bridge : schéma canonique et manifeste avec validateurs détenus par la racine et vérifications SHA256 reproductibles pour les charges utiles d'exemple. - Harnais de test intégrés produisant des artefacts reproductibles et des profils pprof. - Vérification adaptée à la CI : make verify exécute la validation au niveau racine sans dépendre de SHA de sous-dépôts non publiés. - Exécutions de performance conteneurisées via Dockerfiles et scripts. Le README rapporte également des chiffres de micro-benchmarks internes (forwarding, multi-path spraying, crypto, session/routage, AF_XDP) sur du matériel AMD EPYC, avec la mise en garde que les résultats dépendent du CPU, du noyau, de la NIC et de la configuration de contournement du noyau. Il note que le projet privilégie la sécurité, les méthodes formelles, le multi-path spraying et les fonctionnalités souveraines plutôt que les débits maximaux bruts de paquets. L'outillage du contrat bridge comprend des scripts pour régénérer les artefacts canoniques, régénérer les constantes bridge du SDK pour Go/Rust/Python/TypeScript, et valider le manifeste et les hachages ; bridge/bridge_contract.version.json suit les versions de schéma et de manifeste. La CI exécute make verify depuis la racine du dépôt. L'espace de travail est multi-licence car il agrège des composants avec différentes licences amont, documentées dans LICENSE et LICENSES.md.