La préversion 11.2.1 de cardano-node réduit l'usage mémoire du nœud

La version 11.2.1 de cardano-node reste une préversion de maintenance

La version 11.2.1 de cardano-node est publiée le 10 novembre 2026 sur le dépôt GitHub IntersectMBO avec le statut de préversion. Ses notes de version la disent « not yet recommended for use on mainnet » (pas encore recommandée sur le réseau principal, ou mainnet, traduit de l'anglais) et la présentent comme une version de maintenance construite sur la 11.2.0.

La mise à jour de cardano-node intègre ouroboros-consensus 5.4, cardano-api 11.12 et cardano-cli 11.7. Selon les notes de version, ces trois mises à jour réduisent ensemble la consommation de mémoire du nœud autour des instantanés du registre (ledger snapshots).

Les paquets du registre mis à jour, dont cardano-ledger-core et cardano-ledger-alonzo, ne contiennent selon les notes que des modifications d'interface de programmation, « with no change in ledger rules or behaviour » (sans changement des règles ni du comportement du registre, traduit de l'anglais).

La publication de cardano-node 11.2.1 affiche la validation du Technical Steering Committee et du Product Committee d'Intersect, ainsi que celle des ingénieurs chargés des tests, de la performance, de la fiabilité et de la publication.

Les instantanés du registre ne font plus grimper la mémoire vive

Selon les notes de version de cardano-node 11.2.1, l'écriture d'un instantané du registre ne provoque plus de hausse passagère de la mémoire vive d'environ la taille de cet instantané. Le journal des modifications du consensus explique que la file des requêtes d'instantanés gardait auparavant la version sérialisée accessible jusqu'à la fin de l'écriture.

La base de données de la chaîne du nœud (ChainDB) cesse aussi de garder en mémoire l'état du registre de genèse. Les notes chiffrent l'économie à « several hundred MiB » (plusieurs centaines de mébioctets) sur les réseaux dotés d'un vaste ensemble UTxO (sorties de transaction non dépensées) ou de délégation à la genèse.

Pendant la synchronisation de cardano-node, tant que le nœud n'a pas rattrapé la chaîne une première fois, les instantanés sont désormais écrits dès qu'ils sont demandés. Le délai aléatoire ne joue qu'après ce premier rattrapage.

Les notes de la 11.2.1 corrigent un autre comportement : un échec d'écriture des traces sur la sortie standard, par exemple un canal fermé ou une erreur d'encodage, ne fait plus planter le nœud.

La 11.2.1 plafonne les instantanés à une heure, annonce la version de protocole 11.3 dans les en-têtes de bloc et liste le matériel requis

Les notes de version de cardano-node 11.2.1, datées du 10 novembre 2026, modifient la configuration réseau et rappellent les exigences matérielles. Les principales valeurs sont regroupées ci-dessous.

Donnée	Valeur
Délai maximal des instantanés (Storage.LedgerDB.Snapshots.MaxDelay)	3 600 s sur tous les réseaux, contre 21 600 s auparavant sur mainnet et preprod
Version de protocole annoncée dans les en-têtes de bloc	11.3, contre 11.1
Mémoire vive minimale	24 Go (moteur InMemory) ou 8 Go (moteur OnDisk, en attente de confirmation)
Stockage libre minimal	300 Go (350 Go recommandés)

Le moteur de stockage UTxO-HD LSM « has been confirmed to meet Praos performance guarantees for block production », selon les notes de cardano-node 11.2.1 (il respecte les garanties de performance Praos pour la production de blocs, traduit de l'anglais). Les mêmes notes du 10 novembre 2026 recommandent de le tester dans un environnement sûr avant de le déployer sur un producteur de blocs, et de prévoir au moins 8 Go de mémoire vive.

Les notes de la 11.2.1 indiquent qu'aucun changement cassant ne touche les opérateurs de nœud dans cette version. Les ruptures introduites par la 11.2.0, dont le format de configuration cardano-config et le retrait des versions NodeToClientV_16 à NodeToClientV_22, s'appliquent lors d'une mise à niveau depuis une version 11.1.x.

Questions fréquentes

La version 11.2.1 de cardano-node est-elle recommandée sur le réseau principal de Cardano ?

Non, pas encore. Selon les notes de version publiées le 10 novembre 2026 sur le dépôt GitHub IntersectMBO/cardano-node, la version 11.2.1 est une préversion qui n'est « not yet recommended for use on mainnet » (pas encore recommandée sur le réseau principal, traduit de l'anglais). Les mêmes notes la décrivent comme une version de maintenance construite sur la 11.2.0. Elles indiquent aussi qu'aucun changement cassant ne touche les opérateurs de nœud dans cette version.

Comment cardano-node 11.2.1 réduit-elle l'usage de la mémoire du nœud ?

Selon les notes de version du 10 novembre 2026 publiées sur GitHub, la version 11.2.1 réduit la mémoire autour des instantanés du registre (ledger snapshots). Écrire un instantané ne fait plus croître temporairement la mémoire vive d'environ la taille de cet instantané. La base de données de la chaîne (ChainDB) ne conserve plus l'état du registre de genèse, ce qui économise plusieurs centaines de mébioctets sur les réseaux dotés d'un vaste ensemble UTxO ou de délégation à la genèse. Les notes attribuent ces gains à la mise à jour conjointe d'ouroboros-consensus 5.4, de cardano-api 11.12 et de cardano-cli 11.7.

Quel est le délai maximal des instantanés du registre dans cardano-node 11.2.1 ?

Le paramètre Storage.LedgerDB.Snapshots.MaxDelay est plafonné à une heure, soit 3 600 secondes, sur tous les réseaux, selon les notes de version de cardano-node 11.2.1 du 10 novembre 2026. Il était auparavant de 6 heures (21 600 secondes) sur mainnet et preprod, et de 4 320 secondes sur preview et sanchonet. Les valeurs MinDelay et Interval restent inchangées. Les notes précisent aussi que, tant que le nœud n'a pas rattrapé la chaîne une première fois, les instantanés sont écrits dès qu'ils sont demandés ; le délai aléatoire ne s'applique qu'ensuite.

Quelle configuration matérielle minimale cardano-node 11.2.1 exige-t-elle ?

Les notes de version de cardano-node 11.2.1, publiées le 10 novembre 2026, demandent un processeur x86 Intel ou AMD à deux cœurs ou plus, cadencé à 1,6 GHz minimum (2 GHz pour un pool de mise ou un relais), ou un processeur Apple Silicon sous macOS. Elles indiquent 24 Go de mémoire vive avec le moteur InMemory, ou 8 Go avec le moteur OnDisk (en attente de confirmation), et 300 Go de stockage libre, 350 Go étant recommandés pour la croissance future. Pour le moteur LSM, elles recommandent un test préalable dans un environnement sûr avant déploiement sur un producteur de blocs.