Le correctif snarkOS v4.12.1 pour le réseau principal ne modifie pas le consensus

snarkOS v4.12.1 est une version corrective pour le mainnet, sans changement de consensus. La hauteur d’activation de ConsensusVersion::V22 sur le mainnet reste fixée à 22 962 000 ; cette version ne modifie donc pas l’activation prévue. Le correctif renomme le fichier d’historique des récompenses de staking et met à jour des dépendances, notamment les paquets Rustls et webpki, en réponse à des avis de sécurité et à des certificats intermédiaires emSign qui ne sont plus considérés comme fiables. Il met également à jour les compilations CUDA pour cibler sm_86, car CUDA 13 a abandonné la prise en charge de sm_70. Les crates snarkVM restent en version 4.12.0, sans publication sur crates.io. Pour les traders, snarkOS v4.12.1 est avant tout une mise à jour de maintenance et de sécurité, et non un catalyseur lié à la tokenomics ou au consensus du réseau.
Neutral
Cette version est explicitement un correctif sans modification du consensus, et la hauteur d’activation de V22 reste inchangée. Le renommage du fichier, les mises à jour de sécurité des dépendances et l’ajustement de la compatibilité CUDA sont des améliorations opérationnelles, et non des changements apportés à l’économie du réseau, à l’offre de jetons ou aux règles de transaction. Par conséquent, cette mise à jour ne fournit aucun signal directionnel clair pour le trading d’ALEO et ne devrait probablement pas, à elle seule, affecter la stabilité du marché. Les versions similaires de maintenance et de sécurité pour les clients blockchain ont généralement eu un effet limité sur les prix, sauf lorsqu’elles corrigent une exploitation active, résolvent une panne majeure ou modifient le comportement du protocole. À court terme, les traders peuvent surveiller l’adoption et les éventuels signalements de problèmes liés à la mise à niveau, mais cette version seule ne devrait probablement pas entraîner de volume durable ni de tendance. À plus long terme, maintenir les dépendances à jour et préserver la compatibilité matérielle peut contribuer à la fiabilité du réseau. C’est un facteur légèrement positif pour la santé du projet, mais cela ne constitue pas un catalyseur haussier en l’absence de preuves d’une utilisation plus large ou d’un impact économique.