Qu'est-ce que Firedancer ? Client Jump Crypto Validator de Solana 2026

Firedancer : le client validateur conçu pour pousser Solana à 1 million de TPS

Solana a passé quatre ans à promettre un million de transactions par seconde et ne l'a jamais atteint sur le matériel de production. La chaîne fonctionnait rapidement, parfois la plus rapide du secteur, mais le client validateur d'origine (maintenant appelé Agave) n'a jamais été conçu pour extraire chaque cycle d'horloge du silicium. En mai 2026, ce plafond s’est finalement brisé. Danseur de feu, un client de validation Solana en salle blanche entièrement écrit en C par Jump Crypto, a commencé à produire des blocs de réseau principal pour la première fois, a traité des dizaines de millions de transactions en direct et a prouvé que la bande passante théorique de Solana était toujours un problème logiciel et non un problème de protocole.

Pour les validateurs, le lancement remodèle l'économie. Pour les traders DeFi sur Jupiter, Raydium et Drift, cela promet des frais moins élevés, des remplissages plus rapides et moins de transactions abandonnées lors des frénésie de pièces de monnaie. Pour l’écosystème plus large, cela apporte quelque chose que Solana n’a jamais eu : une véritable diversité de clients, une propriété qu’Ethereum a longtemps présentée comme le fondement de la décentralisation.

Ce guide permanent de 2026 explique exactement ce qu'est Firedancer, pourquoi Jump Crypto y a consacré des années d'ingénierie de bas niveau, comment le déploiement s'est déroulé à travers les étapes du testnet et la production de blocs du réseau principal, et ce que cela signifie pour l'avenir de la finance en chaîne à haut débit. Nous couvrons l'hybride Frankendancer, la comparaison avec Agave et Jito-Solana, les implications pour les protocoles MEV et DeFi, les risques toujours sur la table et les questions pratiques que chaque partie prenante de Solana se pose actuellement.

Pourquoi Solana avait besoin d'un deuxième client validateur

Jusqu'à ce que Firedancer atteigne le réseau principal, Solana était en fait un réseau mono-client. Chaque validateur de vote de la planète utilisait une version de la même base de code Rust écrite à l'origine par Solana Labs (rebaptisée plus tard Agave, désormais maintenue par l'équipe Anza après que Solana Labs a restructuré sa branche d'ingénierie). Un seul client signifie un seul ensemble de bogues. Lorsqu'Agave rencontrait un problème de pression de mémoire ou un cas limite de consensus, la chaîne entière s'arrêtait, car elle exécutait un logiciel identique.

Solana a connu plusieurs pannes de plusieurs heures entre 2021 et 2023 exactement pour cette raison. La communauté connaissait le remède (créer un deuxième client indépendant dans un langage différent, sur un modèle de thread différent, avec des hypothèses de mémoire différentes), mais écrire un client de validation de niveau production à partir de zéro est l'une des tâches d'ingénierie les plus exigeantes du secteur. Cela nécessite une expertise en matière de protocole de consensus, une optimisation du réseau au niveau du noyau, des primitives cryptographiques implémentées à la perfection et une capacité à gérer des conditions contradictoires sur une chaîne qui traite des milliers de transactions par seconde.

Jump Crypto s'est porté volontaire. Soutenue par les ressources de Jump Trading, l'une des plus grandes sociétés de trading quantitatif au monde, l'équipe s'est engagée en 2022 à créer une implémentation en salle blanche en C, le même langage utilisé pour écrire des serveurs Web, des systèmes de trading haute fréquence et des moteurs de jeu où chaque nanoseconde compte. Le pari était simple : si Jump pouvait tenir ses promesses, Solana gagnerait non seulement en redondance, mais débloquerait également le débit brut que la conception du protocole a toujours promis.

Qui est Jump Crypto et pourquoi l'ont-ils construit ?

Jump Crypto est la filiale axée sur les actifs numériques de Jump Trading, fondée en 1999 à Chicago et connue pour être l'une des sociétés de trading pour compte propre les plus secrètes et les plus rentables au monde. Jump est un fournisseur de liquidités actif sur les marchés de la cryptographie depuis 2017, mais Jump Crypto s'est formalisé en tant qu'unité commerciale distincte en 2021 sous la direction de Kanav Kariya, qui dirigeait auparavant les efforts d'ingénierie cryptographique de Jump et sert désormais de visage public du groupe.

Pourquoi une société de trading à haute fréquence passerait-elle des années à construire une infrastructure publique pour une blockchain ? Deux raisons. Premièrement, Jump est l'un des plus grands détenteurs de jetons SOL hors protocole et gère un volume d'échanges important via Solana DEX, de sorte qu'un Solana plus rapide et plus fiable améliore directement les propres activités de Jump. Deuxièmement, le pedigree technique requis pour écrire Firedancer (réseau de contournement du noyau, structures de données sans verrouillage, cryptographie accélérée SIMD, allocateurs de mémoire personnalisés) est exactement ce que Jump Trading fait déjà pour ses systèmes de négociation d'actions et de contrats à terme basés sur la colocation. L’ensemble des compétences transférées.

Le projet a été annoncé publiquement pour la première fois à Breakpoint Lisbonne en 2022. Dès le début, Jump s'est engagé à publier Firedancer sous la licence open source Apache 2.0, ce qui signifie que tout opérateur de validation peut créer, auditer et modifier le code. La source complète réside sur GitHub et a fait l’objet de plusieurs audits de sécurité tiers depuis 2024.

Si vous ne savez pas comment les blockchains structurent leur pile logicielle, notre aperçu de comment fonctionnent les crypto-monnaies au niveau de la couche protocolaire couvre les bases des nœuds, des clients et de la participation par consensus.

Comment Firedancer fonctionne réellement sous le capot

Un validateur Solana fait cinq choses en parallèle. Il écoute les transactions entrantes sur un port réseau UDP (Solana utilise un protocole personnalisé appelé QUIC superposé à UDP plutôt que TCP). Il vérifie les signatures numériques sur chaque transaction. Il exécute les transactions à l'intérieur de la machine virtuelle Solana. Il participe au consensus en votant sur les blocs valides. Et, quand vient son tour de leader, il produit un nouveau bloc et le diffuse via Turbine (le protocole de propagation de bloc de Solana).

Agave gère les cinq tâches dans un seul processus Rust intégré. Firedancer les répartit entre des processus distincts qui communiquent via des anneaux de mémoire partagée, une conception empruntée aux systèmes de réseau haute performance. Chaque composant fonctionne comme une « tuile » épinglée sur un cœur de processeur spécifique, avec sa propre région de mémoire et aucun verrou global. La vignette d'ingestion de transactions lit les paquets directement depuis la carte réseau sans les copier via le noyau, la vignette de vérification utilise les instructions SIMD pour vérifier des milliers de signatures Ed25519 par milliseconde, et la vignette d'exécution conserve un cache chaud des comptes récemment touchés pour éviter les lectures sur disque.

Le résultat est qu'un validateur Firedancer fonctionnant sur du matériel de centre de données standard peut maintenir un débit qu'Agave ne peut physiquement pas égaler, car la conception d'Agave impose trop de conflits de mémoire et trop d'appels système. Dans des tests de référence internes (confirmés plus tard par des tiers sur Devnet), Firedancer a démontré des taux de vérification de signature soutenus supérieurs à 1 million par seconde sur une seule machine à 64 cœurs, l'estimation approximative nécessaire pour atteindre l'objectif TPS principal du protocole.

L'approche en anneau de mémoire partagée présente un énorme avantage en termes de sécurité : si une seule tuile tombe en panne, les autres peuvent continuer à fonctionner et le validateur reste en ligne pendant que le composant défectueux est redémarré. Chez Agave, une panique dans n’importe quel sous-système peut faire échouer tout le processus. L'inconvénient est la complexité. Les opérateurs doivent ajuster l'affinité du processeur et la disposition de la mémoire de chaque tuile, ce qui n'est pas le genre de travail que la plupart des intervenants de Solana souhaitent effectuer.

Frankendancer : l'hybride qui fait le pont entre Agave et Firedancer

Construire un client de validation complet est difficile. En construire un qui produit des blocs correctement dans des conditions contradictoires sur le réseau principal est encore plus difficile. La réponse pragmatique de Jump Crypto a été Frankendancer, un hybride qui combine le code de mise en réseau, de consensus et d'exécution bien testé d'Agave avec le nouveau pipeline de production de blocs hautes performances de Firedancer.

Frankendancer est sorti en 2024 comme premier tremplin. Les validateurs pourraient choisir de l'exécuter sur le réseau principal, obtenant ainsi la vitesse de production de blocs du pack de Firedancer et déchiquetant les tuiles tout en s'appuyant sur Agave pour le vote par consensus et sur la couche d'exécution complète de la machine virtuelle Solana. Étant donné que Frankendancer utilisait le code de consensus éprouvé d'Agave, le risque de destruction de la chaîne était négligeable. Les validateurs qui l'ont exécuté ont signalé une utilisation inférieure du processeur pendant les emplacements leaders et des taux d'inclusion de transactions légèrement plus élevés.

Fin 2025, environ 15 % de la participation de Solana dirigeait Frankendancer. Ces opérateurs sont devenus les bêta-testeurs de facto du pipeline de production de blocs qui deviendra finalement le client Firedancer complet. Lorsque le lancement complet du réseau principal de Firedancer est arrivé en mai 2026, la voie hybride signifiait que Jump Crypto disposait déjà de données de performances réelles sur les parties les plus nouvelles de la base de code, réduisant ainsi considérablement les risques du basculement.

Frankendancer ne s'en va pas. De nombreux opérateurs continueront à utiliser l'hybride car il offre une couche de consensus Agave réputée avec des gains de performances mesurables par rapport à la moitié de la production de blocs Firedancer. Pensez-y à la façon dont les opérateurs d'Ethereum associent parfois un client d'exécution d'une équipe avec un client de consensus d'une autre : la flexibilité de mix-and-match elle-même est le dividende de la diversité.

Chronologie du déploiement du réseau principal (2022 à 2026)

Firedancer n'est pas arrivé d'un seul coup. La stratégie de publication était délibérément incrémentale, chaque étape exposant une plus grande partie de la base de code à des conditions contradictoires tout en assurant la sécurité de la chaîne.

Le moment « Block hits » en mai 2026 a été le point d'inflexion. Pour la première fois, une base de code non descendante d'Agave a finalisé des blocs sur le réseau principal Solana. La chaîne ne s'est pas arrêtée, aucun double signe n'a été détecté et le réseau a continué à bourdonner. Pour les ingénieurs qui ont vu Ethereum passer une décennie à favoriser la diversité des clients, cette étape marque l'obtention du diplôme de Solana dans la même ligue.

Firedancer vs Agave vs Jito-Solana : face-à-face

Solana compte désormais, concrètement, trois clients validateurs de production en utilisation active. Agave est le client Rust d'origine, maintenu par Anza après la restructuration de Solana Labs. Jito-Solana est un fork d'Agave maintenu par Jito Labs qui ajoute la prise en charge du bundle MEV, permettant aux constructeurs de blocs de monétiser l'ordre des transactions. Et Firedancer est le nouveau client C de Jump Crypto. Chacun a des atouts différents.

Les numéros de partage des validateurs évoluent de semaine en semaine. Ce qui compte, c'est la tendance directionnelle : la part de marché d'Agave est passée de près de 100 % en 2023 à environ 44 % à la mi-2026, Jito-Solana et Firedancer absorbant le reste. C'est sain. C'est également le type de diversification structurelle que l'on constate dans les systèmes décentralisés matures, de la même manière que la couche d'exécution d'Ethereum est désormais divisée entre Geth, Nethermind, Besu, Erigon et Reth. Si vous souhaitez un aperçu de la pile d'Ethereum à des fins de comparaison, consultez notre Guide complet du débutant Ethereum.

Ce que Firedancer signifie pour Solana DeFi

Les clients Validator sont une infrastructure et la plupart des utilisateurs ne les touchent jamais directement. Mais les effets en aval sur la couche application sont significatifs.

Premièrement, un débit durable plus élevé se traduit par des frais médians inférieurs. Le marché des frais de Solana est dynamique. Lorsque la chaîne est encombrée, les frais de priorité augmentent. Une production de blocs plus rapide avec une plus grande capacité effective de blocs donne au marché des frais prioritaires plus de marge, ce qui maintient les coûts médians à un niveau bas, même pendant les manies de pièces de monnaie ou les monnaies NFT. Pour les utilisateurs DEX sur Jupiter, Raydium et Drift, c'est la différence entre effectuer un échange du premier coup et le regarder expirer trois fois de suite.

Deuxièmement, l'architecture déterministe basée sur des tuiles de Firedancer rend l'inclusion des transactions plus prévisible. Solana a depuis longtemps un problème de « transaction perdue » où les utilisateurs soumettent un échange, la transaction n'atteint jamais car le validateur l'a abandonnée sous charge et l'utilisateur doit réessayer. La tuile pack dans Firedancer est spécialement conçue pour conserver un pool de mémoire plus profond et plus équitable, réduisant ainsi les transactions abandonnées. Pour les traders actifs, moins de tentatives signifient une exécution plus propre et moins de dérapages.

Troisièmement, l'histoire du MEV change. Aujourd'hui, la plupart des Solana MEV transitent par les offres groupées Jito-Solana, dans lesquelles les chercheurs paient directement les validateurs pour inclure leurs transactions à des positions spécifiques dans un bloc. Firedancer est conçu pour être compatible MEV : les futures versions permettront aux opérateurs de choisir leurs propres politiques de création de blocs, notamment en exécutant des versions modifiées qui résistent aux attaques sandwich ou en implémentant des pools de mémoire cryptés. Si vous souhaitez comprendre les modèles d'attaque qui motivent ce travail, notre explicatif sur Bots MEV, attaques frontales et sandwich couvre la mécanique.

Quatrièmement, des performances prévisibles permettent de nouvelles catégories d'applications. Les carnets de commandes en chaîne à haute fréquence, les jeux en temps réel et les ordres limités en chaîne deviennent tous plus réalisables lorsque la latence médiane de confirmation diminue et reste faible. La même logique qui a poussé Sui et d'autres chaînes basées sur Move à poursuivre l'exécution parallèle s'applique à Solana une fois que le plafond de Firedancer est déverrouillé. Notre Analyse approfondie du réseau Sui couvre une conception alternative à haut débit pour le contexte.

Exécution d'un validateur Firedancer : une procédure pas à pas de haut niveau

L'exploitation d'un nœud Firedancer n'est pas une entreprise fortuite. Les exigences matérielles sont agressives (les spécifications actuelles de Solana recommandent un processeur à 32 cœurs, 512 Go de RAM et un stockage NVMe haut de gamme, Firedancer récompensant encore plus de cœurs). La surface de configuration est plus grande qu'Agave en raison de l'architecture en tuiles. Et fonctionner sur le réseau principal signifie accepter la responsabilité du consensus : si votre nœud se comporte mal, vous pouvez être réduit ou perdre vos récompenses de vote.

Si vous êtes un délégant (quelqu'un qui mise SOL avec un validateur plutôt que d'en exécuter un vous-même), vous pouvez demander à votre opérateur quel client il gère. De nombreux tableaux de bord de jalonnement affichent désormais la composition des clients en un coup d'œil. Déléguer aux validateurs Firedancer ou Frankendancer est l'un des moyens les plus directs pour les parties prenantes individuelles de soutenir la diversification de Solana.

Risques et compromis honnêtes

Firedancer est impressionnant, mais il est aussi nouveau. Plusieurs catégories de risques méritent un regard lucide.

Aucune de ces raisons ne constitue une raison pour éviter Firedancer. Ce sont des raisons de le déployer avec soin, et c’est exactement ce que Jump Crypto et la communauté des validateurs Solana ont fait. Les plus de 100 jours de testnet continu et les plus de 50 000 blocs de validation avant le réseau principal n’étaient pas des jalons marketing ; c'était le prix à payer pour dérisquer une base de code de ce roman.

Firedancer en contexte : diversité des clients dans les L1

Cela vaut la peine de faire un zoom arrière. La plupart des grands L1 ont été aux prises avec la diversité des clients à un moment donné de leur évolution.

Ethereum est l'exemple canonique. La couche d'exécution compte cinq clients viables (Geth, Nethermind, Besu, Erigon, Reth) et la couche consensus en compte cinq autres (Prysm, Lighthouse, Teku, Nimbus, Lodestar). Aucun client ne contrôle à lui seul plus de 50 % des parts à un moment donné, et la communauté publie des tableaux de bord mensuels sur la diversité pour suivre les progrès. Le coût de cette diversité est un effort d'ingénierie (plusieurs équipes doivent mettre en œuvre chaque mise à niveau de protocole de manière synchronisée), mais l'avantage est que les bogues d'un client donné ne peuvent pas arrêter la chaîne.

Bitcoin a emprunté un chemin différent. Bitcoin Core domine le réseau avec une majorité qualifiée de client unique, et les implémentations alternatives comme btcd ou libbitcoin sont minuscules. Les Bitcoiners soutiennent que la stabilité du protocole et une base de code petite et lente réduisent l'incitation à la diversité des clients, mais le désaccord philosophique n'est pas résolu.

Chaînes plus récentes comme Monade, Socle et Célestia Les disposent toujours de réseaux mono-clients, en partie parce qu'ils sont plus jeunes et que les ressources sont rares. Le succès de Firedancer pourrait accélérer le même investissement ailleurs. Si une entreprise quantitative de premier plan parvient à créer un client de classe million de TPS pour un L1 majeur, d’autres suivront.

Comment Firedancer change le quotidien du trader

Si vous êtes un commerçant Solana actif, vous ne remarquerez peut-être pas directement Firedancer. Mais vous remarquerez ses conséquences.

Les délais de confirmation pendant les pics de congestion doivent être compressés. Là où le lancement d'un meme coin sur Pump.fun poussait les taux d'atterrissage des transactions à un chiffre de réussite lors de la première soumission, les blocs compatibles Firedancer ont une capacité d'inclusion mesurablement plus grande. Les traders exécutant des robots qui surveillent les jetons nouvellement déployés verront moins d'appels RPC inutiles et des frais de priorité inférieurs nécessaires pour décrocher le premier achat. Pour un aperçu plus approfondi de la manière dont le launch sniping et le frontrunning interagissent avec les pipelines de validation, notre guide sur positionnement long versus short couvre certaines des dynamiques directionnelles.

La précision de la simulation des transactions s'améliore également. Le runtime de Firedancer émet des traces d'exécution déterministes que les outils en aval peuvent rejouer avec précision. Les fournisseurs RPC qui transfèrent les données de simulation sur les portefeuilles et les interfaces de trading bénéficient d'une surface API plus propre et plus uniforme. Si vous simulez des transactions avant de les signer, les données que vous récupérez sont plus fiables. Notre explicatif sur simulation de transactions explique pourquoi cela est important pour la sécurité.

Les protocoles DeFi eux-mêmes peuvent profiter de la nouvelle marge. Un débit plus élevé permet aux carnets de commandes comme Drift d'offrir des ticks plus serrés, des tailles de commande minimales plus faibles et des boucles d'annulation-remplacement plus rapides. Les réseaux de paiement Stablecoin construits sur Solana peuvent servir plus de commerçants par seconde. Les protocoles de tokenisation qui rééquilibrent périodiquement leurs paniers sous-jacents peuvent le faire à moindre coût. Si vous explorez la finance en chaîne plus largement, le Guide des principes fondamentaux de DeFi est un bon point de départ.

Le chemin à parcourir : ce que Firedancer permet ensuite

La production de blocs sur le réseau principal était le début, pas la ligne d'arrivée. Plusieurs mises à niveau sont visiblement en cours ou sur la feuille de route publique.

L'un est l'accélération matérielle. Certaines tuiles de Firedancer sont bien adaptées au fonctionnement sur des GPU ou des FPGA, qui peuvent fournir un ordre de grandeur plus de vérifications de signature par seconde. Jump Crypto a présenté un prototype de tuiles de vérification basées sur FPGA lors de conférences de développeurs, faisant allusion à un avenir dans lequel les validateurs spécialiseraient leur matériel pour des rôles spécifiques au sein du même client.

Un autre est le MEV fourni. L'architecture de Firedancer permet à des tiers de connecter une logique de création de blocs personnalisée. Jito Labs, par exemple, pourrait théoriquement porter ses enchères groupées pour qu'elles fonctionnent au-dessus de la tuile pack de Firedancer, obtenant ainsi le meilleur des deux mondes : l'infrastructure MEV mature de Jito avec les performances brutes de Firedancer. La réalisation de cette intégration dépend de l’alignement commercial entre les deux équipes, mais la voie technique est claire.

Un troisième est constitué de pools de mémoire cryptés. Plusieurs groupes de recherche Solana ont proposé des systèmes de cryptage du pool de mémoire qui empêchent les chercheurs de voir les transactions en attente avant leur arrivée. Le modèle de tuile de Firedancer rend relativement simple l'échange de la tuile de déduplication contre une variante prenant en charge le chiffrement sans toucher au code de consensus. S'ils sont mis en œuvre, les pools de mémoire chiffrés pourraient réduire considérablement les attaques sandwich sur les DEX Solana.

Un quatrième concerne les clients légers. Les traces d'exécution déterministes de Firedancer sont exactement le type d'artefact dont les clients légers et les ponts ont besoin pour vérifier l'état de Solana depuis l'extérieur du réseau. Une meilleure prise en charge des clients légers renforce les ponts inter-chaînes, les sidechains et les L2 construits au-dessus de la couche de base de Solana.

FAQ

Conclusion : un changement discret et fondamental

Firedancer n'est pas un lancement de jeton, un DEX flashy ou une pièce mème. Il s'agit d'un élément d'infrastructure que la plupart des utilisateurs de Solana ne verront jamais et n'auront jamais à penser. C’est exactement ce qui le rend important. Le client validateur que votre chaîne préférée exécute détermine la fiabilité, la rapidité et le degré de décentralisation de cette chaîne. Pendant cinq ans, Solana a fonctionné avec un seul client. Aujourd'hui, elle fonctionne sur trois, le nouveau venu (une salle blanche construite en C par une société de négoce quantitatif de premier plan) démontrant qu'une chaîne d'un million de TPS n'est pas un slogan marketing mais une destination d'ingénierie.

Pour les traders, l'implication pratique est simple : Solana devrait se sentir plus vive, plus juste et moins chère qu'auparavant. Moins de transactions abandonnées, une concurrence moins agressive en matière de frais de priorité et des résultats de simulation plus prévisibles découlent du travail effectué au niveau de la couche logicielle du validateur. Combiné avec l'évolution parallèle de Jito-Solana pour le regroupement MEV et la maintenance continue d'Agave sous Anza, Solana dispose désormais d'une pile d'infrastructure en couches et redondante à laquelle tout L1 sérieux devrait aspirer.

Pour les constructeurs, les implications sont encore plus importantes. Un débit plus élevé, une latence plus faible et la création de blocs enfichables débloquent des catégories d'applications qui ne convenaient tout simplement pas à un Solana à client unique plus lent. Les jeux en chaîne en temps réel, les DEX à ordre limité à haute fréquence, les réseaux de paiement desservant des milliers de commerçants par seconde et les ponts qui s'appuient sur des preuves de type client léger deviennent tous plus faciles à gérer. La prochaine vague d'applications Solana est conçue autour de ce que Firedancer rend possible, et non de ce qu'Agave seul pourrait offrir.

Si vous évaluez des L1 pour un projet, une allocation de portefeuille ou simplement pour comprendre le paysage, Firedancer modifie la comparaison. Solana n'est plus la chaîne avec une conception de protocole héroïque paralysée par un seul client vieillissant ; c'est une chaîne dont la pile client reflète désormais la maturité de son écosystème. Regarder l'action Firedancer croître au cours de la prochaine année nous en dira plus sur la trajectoire de Solana que n'importe quel graphique de prix symbolique. Et si vous souhaitez continuer à explorer le paysage de la L1, nos plongées approfondies sur EVM parallélisé de Monad, Runtime Sui's Move, Coinbase L2 de la base et Disponibilité modulaire des données de Celestia complète le tableau plus large de l’évolution des blockchains hautes performances en 2026.

Suivez les données du marché Solana, les principaux jetons et les analyses sensibles aux validateurs sur DexTools pour garder une longueur d'avance sur la façon dont Firedancer remodèle l'expérience en chaîne. Que vous misiez SOL avec un validateur, exécutiez des stratégies de trading sur Jupiter et Drift, construisiez des applications sur le runtime Solana ou déteniez simplement le jeton dans le cadre d'un portefeuille plus large, la couche client fait désormais partie de votre diligence raisonnable. Demandez quel client un validateur exécute avant de déléguer. Lisez l'historique des validations GitHub si vous souhaitez vérifier une réclamation. Regardez comment les chiffres des parts des validateurs évoluent trimestre après trimestre à mesure que Frankendancer et Firedancer absorbent une plus grande part du réseau. La chaîne que vous avez utilisée hier n'est pas tout à fait la même que celle que vous utiliserez demain, et la différence est écrite, un fichier source C à la fois, par une équipe d'ingénieurs qui ont décidé qu'un million de transactions par seconde n'était pas un slogan mais un délai.