Épisode 4 de la série « Préparer un nœud mineur Flop sous Linux ».
Les trois premiers épisodes ont préparé un mineur : une RTX 5070 Ti sous Rocky Linux, mesurée puis testée 24 heures à pleine charge. Mais le testnet du Flop Network a un deuxième rôle, celui de validateur, qui n'a besoin ni de GPU ni d'enclave de confiance (TEE) : un processeur, de la mémoire, un disque rapide et une bonne connexion. Ma machine en a beaucoup, et le GPU n'en utilise qu'une partie.
D'où la question de cet épisode : peut-on faire tourner les deux rôles sur un seul serveur domestique ? Je confronte ce que demande Flop à ce que j'ai, critère par critère, puis je liste ce qu'il faut préparer avant l'ouverture et ce qui reste inconnu.
Avertissement. Au 31 octobre 2026, le testnet du Flop Network n'est pas ouvert et n'a pas de date officielle. Les exigences citées sont provisoires, et les procédures publiées concernent le devnet (le réseau de développement de l'équipe, sur invitation). Rien ne garantit une place ni une récompense.
Ce que les pages officielles disent au 31 octobre 2026 :
Autrement dit, si la machine tient la charge, tenter le second rôle ne coûte que de l'électricité et de l'attention.
Trois sources donnent des chiffres un peu différents : la page Testnet (« provisoire »), la documentation validateur du devnet (« estimations de planification ») et le profil de référence du Yellow Paper. J'ai mis la plus exigeante en face de ma machine.
| Critère | Ce que demande Flop | Mon serveur | |
|---|---|---|---|
| Processeur | 8 cœurs dédiés (8+ cœurs sur la page Testnet) | Ryzen 9 7900X, 12 cœurs / 24 fils | ✅ mais partagé |
| Mémoire | 64 Go (page Testnet) ; 32 Go ECC (Yellow Paper) | 92 Go, sans ECC | ✅ / ⚠️ |
| Stockage | 4 To NVMe, DA comprise (2 To minimum) | WD SN580 2 To, grand public, vierge | ⚠️ minimum |
| Réseau | 1 Gb/s redondant, faible latence | Fibre 929 Mb/s descendant, 946 Mb/s montant, un seul lien | ✅ débit / ❌ redondance |
| Adresse | Joignable depuis Internet (P2P et DA) | IP fixe, serveur derrière la box | ✅ ports à ouvrir |
Ce que j'en retiens, point par point.
Le processeur. Pendant le test d'endurance de l'épisode 3, Ollama occupait en moyenne l'équivalent de 6 fils d'exécution sur 24. Il en reste largement pour un nœud validateur, mais pas « 8 cœurs dédiés » au sens strict. C'est le premier point à surveiller : un validateur qui produit ses blocs en retard parce que le mineur sature le processeur perd des places au classement.
La mémoire. 92 Go suffisent pour les deux rôles. En revanche, ma carte mère et mes barrettes n'ont pas de correction d'erreurs (ECC). Le Yellow Paper la recommande (« SHOULD »), sans l'exiger. Sans ECC, une erreur mémoire rare passe inaperçue au lieu d'être corrigée. Pour un testnet, je l'accepte. Pour un validateur de mainnet, la question se reposera.
Le stockage. Le WD SN580 de 2 To est exactement le minimum. Il est relié en PCIe 4.0 x2 (environ 3,9 Go/s), ce qui suffit largement. Le risque est la place : la couche DA garde des poids de modèles, et 2 To pourraient devenir justes.
Le réseau. C'est le vrai point faible. Le débit est là, dans les deux sens, mais je n'ai aucun accès de secours. Une coupure de la fibre arrête les deux rôles en même temps, et la disponibilité compte dans le classement validateur. La page Testnet parle de connexion « redondante », sans dire si c'est éliminatoire.
La documentation validateur du devnet (mise à jour du 30 octobre) décrit un nœud en Docker Compose, avec deux conteneurs : le nœud de la chaîne et un « worker » DA. Sur le devnet actuel, tout passe par un réseau privé Tailscale fourni par l'équipe. Pour le testnet public, un profil « P2P public + DA filtrée » est préparé mais pas encore publié. Côté mineur, la doc du 30 octobre ouvre aussi une voie sans Tailscale (sur invitation pour l'instant) : un nom DNS qui pointe vers la machine, et les ports 80 et 443 ouverts pour un relais HTTPS (Caddy, certificat Let's Encrypt).
| Port | Rôle | Exposition |
|---|---|---|
| 30333/tcp | Validateur, P2P : pairs, production de blocs, finalité | Joignable depuis Internet |
| 7001/tcp (ou 7000) | Validateur, DA : les autres validateurs lisent les données stockées | Joignable depuis Internet |
| 80 et 443/tcp | Mineur, voie sans Tailscale : sessions HTTPS | Joignable depuis Internet |
| 9944/tcp | RPC du nœud validateur | Uniquement en local (127.0.0.1) |
Le port DA n'est pas encore fixé : la doc du 30 octobre annonce 7001 dans la liste des ports, mais son modèle de configuration garde DA_PORT=7000. L'incohérence a été signalée publiquement (issue #10 du dépôt flop-labs/network). Je redirigerai celui que le client du testnet utilisera.
Mon serveur a une adresse privée derrière la box. Avec une IP fixe, il suffira de rediriger ces ports de la box vers le serveur, et de renseigner l'adresse publique dans la configuration (PUBLIC_ADDR, DA_PUBLIC_ENDPOINT pour le validateur, SESSION_PUBLIC_HOST pour le mineur). Une IP fixe évite aussi le piège du CGNAT, où l'adresse publique est partagée entre plusieurs abonnés et où aucune redirection n'est possible. Je vérifierai quand même, le jour J, depuis une connexion extérieure, que chaque port répond.
Le piège Docker. Sur Rocky Linux, un port publié par Docker est ouvert sans passer par les zones de firewalld : Docker écrit ses propres règles. Fermer 9944 dans firewalld ne protège donc rien. La seule protection fiable est de publier le RPC sur 127.0.0.1, ce que prévoit la configuration du devnet :
RPC_BIND_IP=127.0.0.1
RPC_METHODS=safePour générer les clés de session, le RPC passe brièvement en mode unsafe. Depuis la mise à jour du 30 octobre, c'est l'outil d'inscription (pnpm onboard join) qui s'en charge et qui remet le mode safe avant de se déclarer prêt. Le RPC doit rester en local pendant tout ce temps. C'est la même logique côté mineur : le worker reste sur 127.0.0.1 (SESSION_BIND_IP), seul le relais HTTPS est exposé.
Le SN580 a servi de disque Kubernetes dans une autre vie. Je l'ai inspecté puis effacé le 12 octobre. Il est vierge. Pour le préparer au rôle de validateur, je le formate en XFS et je le monte par son UUID, avec nofail pour qu'un disque absent ne bloque pas le démarrage :
sudo mkfs.xfs -L flop /dev/disk/by-id/nvme-WD_Blue_SN580_2TB_<numéro-de-série>
echo "UUID=$(sudo blkid -s UUID -o value /dev/disk/by-id/nvme-WD_Blue_SN580_2TB_<numéro-de-série>) /srv/flop xfs defaults,nofail 0 2" | sudo tee -a /etc/fstab
sudo mkdir -p /srv/flop && sudo systemctl daemon-reload && sudo mount /srv/flop && df -h /srv/flopDeux précautions, apprises sur cette machine :
/dev/disk/by-id/. Les noms nvme0n1 / nvme1n1 changent d'un démarrage à l'autre, et un mkfs sur le mauvais disque efface le système.findmnt -S <disque> doit ne rien renvoyer.Les volumes Docker du validateur iront sur /srv/flop, séparés des modèles du mineur qui restent sur le disque système.
La documentation du devnet est claire sur quatre points :
babe (production de blocs), audi (découverte des pairs) et alp0 (finalité AlephBFT). Elles restent sur la machine.pnpm onboard prepare les affiche). L'équipe lit le reste directement sur la chaîne.À sauvegarder, hors de la machine et chiffrés : la graine du compte, le trousseau du nœud, la clé libp2p et les données du worker DA. Une simple copie de la base de la chaîne ne suffit pas à restaurer un validateur.
flop-labs/network).pnpm onboard preflight --profile public-testnet), mais elle refuse volontairement de démarrer tant que l'identité du réseau n'est pas publiée.| Condition | État au 31/10/2026 |
|---|---|
| Disque de 2 To dédié | Vierge, prêt à formater |
| IP fixe et ports redirigés (30333, DA, 80/443) | IP fixe ✅, redirections à faire le jour J |
| RPC en local uniquement | Prévu dans la configuration |
| Comptes séparés mineur / validateur | À créer le jour J |
| Admission | Parrainage validateur automatique annoncé ; invitation mineur sans contact |
| Cumul autorisé par le client | Inconnu |
| Accès réseau de secours | Absent, rien acheté |
Je tenterai les deux rôles à l'ouverture si le client le permet. Si le processeur ne suit pas, la priorité ira au mineur : c'est le rôle pour lequel cette machine a été construite. Je n'achèterai ni disque de 4 To ni accès 4G/5G de secours avant de lire la documentation validateur officielle du testnet.
Mon DID : did:key:z6MkgzG86nL4pgoytHsEUAshr24ByY8pvmRxYWFuVS2Y1DQi
Épisode 1 : Technocore et DID
Épisode 2 : Serveur Linux et GPU
Épisode 3 : Benchmarks, endurance et jour J
Me suivre : @bvivi57 — le projet : @flop_labs
Documentation du Flop Network consultée le 31 octobre 2026 ; constats matériels relevés sur Rocky Linux 10.2 du 12 au 24 octobre 2026.