Vélocité d’ingénierie : au cœur de l’équipe performance d’Anza avec Alessandro Decina

Introduction

Le techno-optimisme est incontestablement au cœur de l’air du temps culturel de Solana. La foi absolue dans une vitesse, un progrès et une innovation sans entraves sous-tend chaque pull request déployée sur le mainnet. Le mantra est IBRL : Increase Bandwidth, Reduce Latency. À parts égales, c’est un diktat d’ingénierie, un signe de reconnaissance culturel et une prière séculière. Si Bitcoin est une cathédrale dédiée à la permanence et Ethereum une agora consacrée à la neutralité, Solana est un circuit de course : le royaume d’une vitesse mécanique et mesurable.

Pourtant, cette vitesse ne descend jamais du ciel sous la forme d’un diff soigneusement commenté. Elle est extraite, polie et façonnée par celles et ceux qui osent fixer du code toute la journée. Peu le font avec autant d’intensité qu’Alessandro Decina, à l’origine un virtuose de GStreamer qui prenait les saccades des buffers vidéo comme une offense personnelle. Aujourd’hui, il dirige l’équipe performance de quatre personnes d’Anza, une équipe dont l’idée de « prendre soin de soi » consiste à supprimer les barres jaunes d’une trace de validateur à 3 heures du matin. Leur quotidien consiste à scruter des flame graphs, à supprimer des workflows entiers et à réécrire du code de production éprouvé, car tout ce qui peut être optimisé finira par l’être.

Je voulais comprendre ce que signifie vivre à cette vitesse. Je me suis donc entretenu avec Alessandro Decina pour découvrir comment il continue d’accélérer la blockchain la plus rapide au monde. L’entretien qui suit est une autopsie de la vitesse. Nous avons parlé de ses années à travailler sur des pipelines multimédias, ainsi que des garde-fous culturels qui permettent à quatre ingénieurs de livrer davantage que des organisations entières. 

Cette conversation a été remaniée et condensée dans un souci de clarté et de concision.

Entretien

Origines et vision du monde

Ichigo : Revenons un peu en arrière. Votre premier amour a été GStreamer et les pipelines multimédias. Quelles grandes leçons avez-vous tirées de cette époque sur la latence ? Qu’est-ce que la recherche d’un traitement audio et vidéo en temps réel vous a appris sur la manière de gagner quelques millisecondes sur Agave ? 

Decina : Tout d’abord, beau travail de traque, haha. J’ai travaillé sur GStreamer pendant environ 15 ans, peut-être un peu plus. C’est vraiment là que j’ai appris absolument tout ce que je sais. J’ai commencé à contribuer au projet lorsqu’il était open source et venait tout juste de démarrer. Et j’ai eu énormément de chance : je me suis rapproché du fondateur de l’époque. Il avait, je ne sais pas, 15 ans de plus que moi, et il était vraiment doué. Ce type a une page Wikipédia, il est donc probablement intelligent. Pas comme moi : moi, je fais semblant de l’être. Il a simplement décidé : oui, peu importe, je vais t’enseigner gratuitement tout ce que je sais. Et c’est ainsi que j’ai commencé à travailler là-dessus.

C’est amusant de nous entendre parler aujourd’hui de faible latence dans le cadre de notre travail sur Solana, car ce n’est absolument pas de la faible latence. Quand on parle de traitement audio, de DPS et de matériel multimédia, ce que nous faisons sur Solana présente une latence extrêmement élevée. Si un système audio ou vidéo avait un temps de réponse de 400 millisecondes, il serait tout simplement inutilisable. Cela ne fonctionne pas.

À un moment donné, j’ai commencé à travailler avec des pilotes Linux et du matériel assurant l’encodage et le décodage vidéo et audio. Beaucoup de choses que je fais aujourd’hui sont essentiellement identiques à ce que je faisais à l’époque. Quand on travaille avec du matériel, la latence signifie qu’il existe quelque part une file d’attente. Il faut trouver cette file, tenter de la réduire au minimum et s’assurer qu’elle ne soit jamais à court de données.

Par exemple, le travail que je mène actuellement sur XDP ressemble beaucoup au fonctionnement des buffers circulaires audio. Même pendant cet appel, de nombreux paquets arrivent dans le désordre. Un buffer circulaire les remet en ordre quelque part, et il faut absolument veiller à ce qu’il ne soit jamais à court de données.

J’ai l’impression de faire le même travail depuis 20 ans.

Autrement dit, même chose, autre jour. Parce que j’ai également remarqué que vous aviez travaillé chez Spotify, ainsi qu’un peu sur Firefox…

Ah, non, le travail sur Firefox concernait simplement des intégrations pour un hackathon. Haha, je suis si vieux que j’ai écrit la balise vidéo d’origine de Firefox, qui utilisait GStreamer.

Mince, haha. Tous les chemins ramènent donc à GStreamer ? 

GStreamer m’a vraiment appris la programmation multithread. C’est grâce à lui que je suis dans cet écosystème. Certaines personnes écrivent en assembleur et font toutes sortes de bidouillages de bas niveau. Et moi, je me dis : oui, je fais cela depuis longtemps. Et j’ai appris que sans langage doté d’un système de types robuste et d’un bon compilateur, on finit par se tirer une balle dans le pied. Je suis certain qu’on peut rendre quelque chose légèrement plus rapide avec l’assembleur, mais je veux vraiment Rust. 

Je veux que le compilateur Rust me dise : tu es idiot, cela ne fonctionnera pas parce qu’il y a un bug ici. Avant Rust, j’avais l’impression d’être ingénieur logiciel à 10 % et débogueur humain à 90 %. Je ne faisais que déboguer. Je pense donc que GStreamer et mon amour pour Rust sont les raisons pour lesquelles j’ai commencé à travailler sur Solana. Rust gagnait en popularité, peu d’emplois permettaient encore d’y travailler à temps plein et j’avais décidé de ne travailler qu’avec Rust. 

Je suis trop vieux pour écrire du C. Je ne veux pas d’un langage qui ne garantit pas la sûreté de la mémoire. Je ne veux pas perdre mon temps. Et voilà comment je suis arrivé ici.

Très bien. Lorsque vous avez fait cette transition, aviez-vous des idées fausses sur les systèmes décentralisés avant de travailler sur le code des validateurs ? Qu’est-ce qui vous a convaincu que l’architecture de Solana pouvait réellement passer à l’échelle ? 

J’ai finalement rejoint Solana avec presque deux ans de retard parce que j’étais occupé à travailler sur le compilateur Rust. Quelqu’un chez Solana, qui commençait tout juste à travailler sur la machine virtuelle, m’a envoyé un e-mail disant : « Je fais la même chose, vous semblez avoir un peu d’avance, venez travailler avec nous. » Je n’ai pas répondu à cet e-mail parce que je m’étais renseigné sur Bitcoin, puis sur Ethereum, et j’avais constaté qu’on pouvait exécuter des choses, mais avec 10 TPS. Ce n’est pas vraiment un projet sérieux, n’est-ce pas ? On ne peut rien faire de concret avec 10 TPS. 

Je n’ai donc pas répondu à cet e-mail. Je me suis simplement dit : bon, ces gens de la crypto ne sont pas encore sérieux.

Toly m’a recontacté deux ans plus tard et j’ai vérifié le cours de SOL. Je me suis dit que j’aurais dû ouvrir cet e-mail, haha. Cette fois, j’ai fini par discuter avec lui. Avant notre échange, il m’a indiqué du code. Je l’ai examiné et, franchement, il était affreux. C’était vraiment du très mauvais code Rust.

Mais j’ai ensuite parlé à Toly sans le chercher sur Google, donc je n’avais aucune idée de qui il était. Il était intelligent et disait exactement ce qu’il fallait. Il m’a expliqué que nous construisions ce système. Actuellement, nous procédons ainsi. Ce n’est évidemment pas à la pointe, mais notre ambition est de passer à l’échelle avec le matériel. Nous construisons la blockchain la plus performante, jusqu’à ce que le matériel devienne le goulot d’étranglement. L’idée est que plus on lui fournit de ressources matérielles, plus elle passe à l’échelle.

Et cela m’a convaincu. J’ai eu l’impression qu’il ne s’agissait pas simplement d’une bande de fanatiques de blockchain qui se paluchaient sur la Troisième Guerre mondiale… Ce qui m’intéresse, c’est la technologie. Je fais partie des rares personnes de la crypto qui sont vraiment là pour la technologie.

Solana possède une culture d’ingénierie dans laquelle la technologie est fortement influencée par le techno-optimisme, toute cette culture de l’Increase Bandwith, Reduce Latency. Comment la percevez-vous personnellement ? Quelle est son influence sur le quotidien chez Anza ? 

À mes yeux, Ethereum repose fondamentalement sur une mentalité de pénurie. Ils se disent : bon, nous avons atteint certaines limites et nous allons trouver des moyens de les contourner. Nous allons inventer toute cette infrastructure pour pallier ce qui n’est au fond que des lacunes dans nos connaissances, que nous pensons impossibles à combler. N’est-ce pas ?

À l’inverse, j’ai l’impression que nous sommes à l’opposé. Nous nous disons : bon, il y a un problème. Il n’existe aucun problème insoluble, hormis ceux qui violent les lois de la physique. C’est une immense différence culturelle.

Si quelque chose ne fonctionne pas, nous disons simplement : bon, asseyons-nous. Faisons un peu de profiling et examinons les problèmes. Parlons aux traders et aux teneurs de marché. Voyons quels sont leurs problèmes. Récemment, nous avons identifié des problèmes très concrets. Et nous avons corrigé la plupart d’entre eux. Sincèrement, en deux ou trois mois, nous pouvons tous les corriger. 

Beaucoup de choses ne fonctionnent pas aujourd’hui sur Solana. Nous le savons, et jamais nous ne nous sommes assis en disant : « Nous avons la solution parfaite ! Et maintenant, pour aller plus loin, nous devons inventer quelque chose de nouveau, faire des recherches ou essayer autre chose. » Non, ce sont des problèmes concrets. La plupart sont vraiment stupides. 

Et nous n’avons connu aucune panne récemment. Personnellement, je trouve cela baissier, n’est-ce pas ? Parce que je pense que certaines personnes ont commencé à devenir un peu trop prudentes. Nous savons que nous pouvons aller beaucoup plus vite. Nous savons que nous pouvons produire dès demain des blocs de 100 millions de CU. Il suffit d’accélérer quelques opérations. Et je suis favorable à ce que nous accélérions tout.

Fondamentalement, nous le savons : nous n’avons pas besoin d’une feuille de route pour savoir que nous pouvons multiplier les performances actuelles par dix. Nous voyons comment y parvenir. Nous savons comment faire. Soit nous avons écrit le code et il n’est pas entièrement terminé, soit nous l’avons écrit, mais ne pouvons pas le déployer parce qu’il reste quelques cas limites à corriger. Mais nous savons exactement quoi faire.

Nous savons comment faire passer ce système à l’échelle.

Ingénierie des performances

À propos de ce travail sur les performances, je pense que peu de personnes savent vraiment qu’Anza possède une équipe qui s’y consacre. Elle passe un peu sous les radars. Parlez-moi de la structure de cette équipe. En quoi diffère-t-elle des autres équipes d’ingénierie d’Anza ? 

En effet, nous avons différentes équipes chez Anza. Il y a actuellement l’équipe chargée du consensus, qui se concentre sur Alpenglow. L’équipe réseau se concentre principalement sur Gossip. L’équipe AccountsDB travaille essentiellement et exclusivement sur la base de données des comptes. L’équipe de production des blocs travaille sur le scheduler. Et bien sûr, il y a toutes les autres équipes que j’oublie.

La différence avec l’équipe performance, c’est que nous travaillons sur tout. Nous faisons du profiling, trouvons un goulot d’étranglement et demandons aux équipes concernées si elles ont le temps et l’expertise nécessaires, car nous trouvons parfois des problèmes que tout le monde ne peut pas corriger. Par exemple, une personne spécialisée dans le consensus n’est pas nécessairement la meilleure en programmation de bas niveau, car son expertise se situe ailleurs. Dans ce cas, nous intervenons généralement nous-mêmes pour corriger le code à sa place.

Nous ne travaillons donc pas sur une seule chose. Nous cherchons simplement le prochain goulot d’étranglement. Nous nous synchronisons environ toutes les deux semaines pour faire le point, décider de la prochaine étape et déterminer comment accélérer la prochaine version.

Une autre grande différence est qu’Anza a tendance à recruter des personnes intelligentes. Vous ne connaissez pas Rust ? Ce n’est pas grave. Vous ne connaissez pas la programmation de bas niveau ? Ce n’est pas grave. Nous partons du principe que si vous êtes intelligent, nous pouvons vous enseigner l’essentiel de ces compétences sur le terrain. Pour l’équipe performance, je recrute généralement des personnes qui ont réellement travaillé avec le kernel ou d’autres éléments de bas niveau, en raison du type de goulots d’étranglement auxquels nous sommes actuellement confrontés.

Par exemple, la base de données des comptes présente certains problèmes algorithmiques que nous devons corriger. Mais*,* si, dans la version 2.3, elle est environ dix fois plus rapide qu’il y a deux mois, c’est simplement parce que nous avons corrigé sa gestion des I/O. Et il faut savoir comment cela fonctionne pour pouvoir l’accélérer. Avec seulement une compréhension de haut niveau des bases de données, on ne sait pas vraiment comment fonctionnent les disques, et on n’a pas besoin de connaître la manière dont le kernel planifie les requêtes I/O.

Pour l’équipe performance, j’ai donc personnellement tendance à recruter davantage de spécialistes du bas niveau. Encore une fois, peu m’importe qu’ils connaissent Rust, mais je veux qu’ils aient travaillé avec C ou C++ sur d’autres sujets de bas niveau.

Si l’existence d’une équipe performance est peu connue, c’est parce que nous n’avons réellement commencé qu’en décembre. À l’origine, j’avais été recruté pour travailler sur le compilateur, mais je suis passé aux performances autour de la panne de mars 2024 et j’ai commencé à optimiser les choses. Les gens n’étaient pas très contents, parce qu’un jour je leur avais simplement annoncé que j’allais travailler sur ce que je voulais. Donc oui, haha, ils n’étaient pas contents, mais nous avons ensuite obtenu d’excellents résultats. Des gens sont alors venus me voir en disant : « Bon, en fait, voulez-vous recruter davantage de personnes pour faire cela ? » En décembre, nous avons officiellement lancé l’initiative consacrée aux performances et créé l’équipe.

Pour être honnête, je manque d’objectivité, mais l’équipe performance est sans aucun doute la meilleure équipe d’Anza.

Je n’en doute pas, haha. Combien de personnes compte l’équipe ? 

Nous sommes quatre à temps plein, mais je plaisante sur Twitter à propos de l’arrivée de Brooks et de quelques autres personnes, car j’ai commencé à diffuser plus largement mon profiler. Jusqu’à il y a peut-être deux mois, seuls les membres de l’équipe performance y avaient accès. Désormais, tout le monde l’a. Et par exemple, depuis que je l’ai donné à Brooks, il travaille davantage que moi sur les performances, haha. Il est complètement accro. Maintenant, il accélère absolument tout.

Brooks et quelques autres personnes qui travaillent aussi beaucoup sur les performances font donc désormais officieusement partie de l’équipe. Mais nous sommes quatre à y travailler à temps plein. 

Lorsque vous travaillez sur les performances, quel « indice » recherchez-vous pendant le profiling et que la plupart des ingénieurs ne remarqueraient pas ? Comment décidez-vous de ce qui doit être optimisé ? 

Certaines choses sont vraiment évidentes. Lorsque j’ai commencé à profiler Agave, nous passions beaucoup plus de temps dans le kernel qu’à exécuter du code en espace utilisateur, ce qui est ridicule. Notre application n’est pas vraiment une application de bas niveau. Si nous développions un framework multimédia, il serait logique d’effectuer la majeure partie du travail dans le kernel, puisqu’il faut en définitive envoyer les échantillons au matériel. Mais le seul travail véritablement de bas niveau que nous effectuons est Turbine.

En général, le principal indice lorsque je commence le profiling est la présence de beaucoup de jaune dans mes flame graphs, car cela signifie que nous passons trop de temps dans le kernel. Cela indique probablement que quelqu’un utilise une API de haut niveau qui semble anodine, mais dont les performances sont catastrophiques en coulisses.

Au cours de l’année écoulée, nous avons divisé par environ dix la quantité de mémoire utilisée par Agave, car nous rencontrons généralement le même problème. Lorsqu’on effectue trop d’allocations mémoire, il faut à un moment donné commencer à interagir avec le kernel. Cette interaction apparaît dans le profiler. On se demande alors d’où elle vient. On constate que cette chaîne malmène constamment la mémoire. On la remonte jusqu’à l’endroit où se produisent trop de renouvellements et d’allocations mémoire, puis on corrige le problème.

Certaines choses sont plus difficiles. Par exemple, nous avons identifié un problème de conception fondamental que je suis en train de corriger. Comme chacun sait, Solana utilise un pipeline avec différentes étapes, censées être entièrement parallélisées afin que toutes les opérations s’exécutent en parallèle.

En pratique, compte tenu de l’architecture du système, nous avons bien une conception en pipeline, mais celui-ci connaît de très nombreux blocages. Nous avons donc différentes étapes, mais nous ne maximisons pas leur débit à cause de bugs de conception stupides qui introduisent de la latence à différents endroits. C’est cette latence dont les gens se plaignent généralement lorsqu’ils ne peuvent pas envoyer de transactions ou lorsqu’ils évoquent de la gigue dans le système. Cette gigue n’est due à aucun facteur fondamental ni au matériel : elle vient simplement du fait que nous procédons de manière sous-optimale. 

Mais, pour être tout à fait franc avec vous, les problèmes sur lesquels nous travaillons sont stupides. Certains bugs sont extrêmement évidents, et nous ne faisons que corriger ces bugs évidents.

Comment déterminez-vous si ces bugs justifient des microbenchmarks ou une relecture complète du trafic du mainnet ? 

Je pense que la plupart de nos problèmes de performances viennent du fait que les gens ont écrit des microbenchmarks. Ils ont accéléré ces microbenchmarks. Ils les ont testés séparément. Puis, lorsqu’on réunit tout dans Agave, rien ne fonctionne comme dans les microbenchmarks.

Personnellement, je dis donc aux gens : n’utilisez jamais de microbenchmarks pour quoi que ce soit. Même la relecture des transactions, je ne l’ai peut-être effectuée que trois fois au cours de l’année écoulée. Parce que même lorsqu’on rejoue le trafic du mainnet, on ne le fait pas exactement à la même vitesse que lors de l’exécution réelle du trafic du mainnet, et de nombreuses choses changent. 

C’est en partie pour cela que nous accélérons autant le démarrage : sinon, devoir attendre une demi-heure chaque fois qu’on veut vérifier si un correctif fonctionne devient agaçant.

Au stade où nous en sommes avec Agave, on ne peut pas s’enfoncer profondément dans une piste pour un seul composant. Le travail est peut-être intellectuellement intéressant, mais il est totalement inutile si l’on ne tient pas compte de l’ensemble du système. Il ne fait rien avancer concrètement. 

Si l’on considère l’ensemble du système, pourquoi la réécriture de Turbine avec XDP est-elle si importante ? 

Je travaillais sur les réseaux juste avant de rejoindre Solana. J’étais dans une startup spécialisée dans l’inspection approfondie des paquets. En pratique, elle interceptait tout le trafic entrant dans une NIC, l’analysait en temps réel pour bloquer les flux malveillants, puis le réinjectait dans le kernel. Nous avions essentiellement écrit une stack TCP et UDP complète en espace utilisateur avec Rust, Tokio et, bien sûr, XDP.

Lorsque j’ai rejoint Anza, il était évident qu’il faudrait un jour utiliser XDP. Lorsque Firedancer a démarré, ils ont déclaré : « Nous allons commencer par une implémentation XDP de Turbine », et je leur ai dit que c’était stupide. Cela n’avait aucun sens. Cela prend beaucoup plus de temps parce que XDP est objectivement une API épouvantable. Il faut donc éviter de l’utiliser aussi longtemps que possible, jusqu’à ce que tout parte littéralement en vrille.

Puis on se dit : oh [censuré], maintenant je dois utiliser XDP. C’est ce qui nous est arrivé. Nous avions travaillé à supprimer tous les autres goulots d’étranglement du pipeline jusqu’au jour où nous avons commencé les tests de charge et constaté que Turbine cessait complètement de fonctionner.

Nous nous sommes donc dit que ce n’était clairement plus viable. Et j’ai vraiment tout fait pour ne pas utiliser XDP, parce que je l’avais déjà utilisé et savais à quel point il était affreux. J’ai essayé de créer une implémentation de Turbine basée sur io_uring. Puis j’ai trouvé des bugs dans io_uring. J’ai commencé à les corriger. J’ai encore quelques correctifs du kernel à envoyer, mais j’ai fini par comprendre que je ne pouvais pas demander à tous nos opérateurs de validateurs d’utiliser mon kernel personnalisé pour exécuter Solana.

Je devais utiliser XDP, et c’est ce que nous avons fait. Maintenant, cela fonctionne.

La réponse est la suivante : on trouve le prochain goulot d’étranglement et on le corrige. Puis on continue à corriger tous ceux que l’on trouve. Les problèmes de demain pourront attendre demain. C’est ma devise. On pourrait ne se préoccuper que de demain, mais la situation serait alors désastreuse aujourd’hui. Aujourd’hui, la situation est mauvaise sur Solana. Les blocs sont trop petits, Turbine ajoute trop de latence et le scheduler présente encore des problèmes. Nous devons corriger les problèmes dès aujourd’hui. Sinon, il n’y aura pas de lendemain où aller aussi vite.

Comment vous protégez-vous contre les régressions de performances ? Comment vous coordonnez-vous avec Firedancer ? 

Les régressions de performances sont un combat. Personnellement, je profile quelque chose dans Agave tous les jours, au moins plusieurs fois par jour, et nous rencontrons souvent des régressions parce qu’écrire du code performant est un métier. Il faut savoir comment s’y prendre. Du code Rust sera, en moyenne, plus performant que du code Node.js, Python ou autre. Mais si, par exemple, on travaille sur AccountsDB et sur des collections contenant des millions d’éléments, on ne peut pas simplement écrire du code. Concevoir des algorithmes et travailler efficacement sur de grands ensembles de données est difficile. 

Nous rencontrons donc parfois des régressions. Jusqu’à il y a environ un mois, je passais mon temps à crier sur tout le monde, haha. Dans le cas de Brooks et d’AccountsDB, je pense qu’il m’a détesté pendant un temps. Nous entretenons une excellente relation, mais jusqu’au mois dernier, la moitié de nos échanges consistait essentiellement à ce que je lui crie dessus parce que quelque chose avait ralenti dans AccountsDB.

Pour le protocole, la collaboration avec Firedancer a amélioré la situation, car j’ai l’impression que de nombreuses parties du protocole se sont développées organiquement en réponse à différents défis. Le développement du protocole a commencé par une idée. Ils l’ont mise en production et, comme la plupart des idées, elle n’a pas fonctionné du premier coup. Ils ont alors commencé à ajouter des couches. Du point de vue des performances, beaucoup de ces ajouts étaient de très mauvaises idées.

Par exemple, Gossip comportait un mécanisme appelé epoch slots, par lequel le cluster indiquait essentiellement à tout le monde quels validateurs avaient vu quels slots. Il y a six mois, alors que je profilais tout autre chose, j’ai remarqué presque par hasard que ce mécanisme epoch slots consommait davantage de temps CPU que l’exécution des transactions elle-même. En termes de bande passante, il en consommait quatre fois plus que Turbine. Il s’agissait simplement d’un correctif aléatoire ajouté au protocole à un moment donné pour atténuer un problème.

Cela ne se produit donc plus. Et c’est en partie grâce à Firedancer. Désormais, lorsqu’une personne fait une proposition, nous devons travailler avec Firedancer. Ils développent évidemment un autre client, haha, et doivent donc budgétiser ce travail. Ils doivent déterminer combien de temps prendra l’implémentation de cette proposition. Quelle est sa priorité ? Ils opposent donc une résistance, pour le meilleur ou pour le pire, à beaucoup, voire à la quasi-totalité, des modifications que nous apportons. Et ils savent très bien s’opposer aux très mauvaises modifications. 

Une fois Turbine livré avec XDP, si vous disposiez d’un mois sans réunions ni conflits, avec une liberté totale de travailler sur ce que vous voulez, quelle partie d’Agave optimiseriez-vous ou réarchitectureriez-vous en premier ? 

Je veux vraiment… J’en rêve littéralement. Cela fait environ deux ans que je veux réécrire AccountsDB. Je sais simplement que si je commence, cela me prendra littéralement un ou deux mois de ma vie. Et pour l’instant, ce n’est pas la meilleure utilisation de mon temps. Mais je le ferai. J’essaie toujours de pousser Brooks à s’en charger, mais s’il ne le fait pas, je finirai par le faire moi-même.

Développements futurs

En ce qui concerne l’avenir et les fonctionnalités prévues comme Async Execution ou Multiple Concurrent Leaders, quel serait le plus gros casse-tête pour l’équipe performance ? 

Instinctivement, je déteste l’asynchrone. Le modèle actuel est très simple. On reçoit des transactions, on les rejoue très rapidement, puis on vote. Conceptuellement, c’est extrêmement simple. Async Execution complexifie la conception, mais améliore aussi considérablement l’expérience réelle d’utilisation de la blockchain.

Je déteste également la conception de Multiple Concurrent Leaders, haha. Je comprends qu’il faut plusieurs leaders, surtout si l’on veut pratiquer le trading à haute fréquence. Il n’y a pas d’autre solution. Mais cela n’arrivera pas avant au moins 12 mois. Je ne veux donc pas trop me laisser distraire.

Il est important que nous ayons Alpenglow dans un an, mais il est tout aussi important d’atteindre cent millions de CU le mois prochain. Nous devons nous concentrer sur l’accélération de ce que nous avons aujourd’hui, car Alpenglow est du nouveau code et Multiple Concurrent Leaders aussi. Il existe des inconnues dont nous ignorons l’existence. Supposons que, pour une raison quelconque, Alpenglow prenne du retard comme Firedancer. Que faisons-nous alors ? Conservons-nous la blockchain lente et pourrie que nous avons actuellement ? Non, nous devons nous concentrer sur la vitesse dès aujourd’hui.

Conseils sur l’ingénierie des performances

Quelles ressources recommanderiez-vous à une personne ayant de l’expérience avec Rust et souhaitant se lancer dans la programmation axée sur les performances et le profiling ?

Tout d’abord, je recommande d’utiliser un bon profiler, ce qui n’existe pas aujourd’hui, haha. Mais j’espère publier le mien bientôt. Ensuite, je pense réellement que le meilleur moyen d’apprendre quoi que ce soit consiste à le faire sur quelque chose qui compte vraiment pour soi.

Mon conseil aux personnes qui souhaitent apprendre à travailler sur les performances est donc de choisir un logiciel qu’elles utilisent quotidiennement et qu’elles aiment, de le profiler et de l’accélérer, car beaucoup de logiciels sont très lents. Même de nombreux logiciels rapides pourraient aller beaucoup plus vite. Les ordinateurs sont vraiment rapides. Et parce qu’ils le sont, il est très facile de faire quelque chose de lent sans même s’en rendre compte.

Pour accrocher, beaucoup de gens choisissent quelque chose qu’ils utilisent et le profilent : ils l’accélèrent, envoient des pull requests et, je vous le garantis, celles-ci seront acceptées. Vous deviendrez complètement accro.

Le kernel n’est qu’une dépendance comme une autre. Lorsque vous travaillez sur quelque chose et utilisez une bibliothèque, vous devrez probablement examiner cette bibliothèque à un moment donné si quelque chose ne fonctionne pas, est lent ou autre. Le kernel n’est qu’une bibliothèque de plus. Alors,, lisez le code du kernel. C’est l’un des codes les plus simples que j’aie jamais vus. Si vous examinez le scheduler du kernel, il est conceptuellement plus simple que celui que nous avons sur Solana. 

Allez simplement lire le code de Linux. C’est du C, ce n’est pas idéal, et tout ce qui touche au matériel est généralement maudit, haha, mais la majeure partie de Solana ne fonctionne pas directement avec le matériel. Cherchez des éléments génériques que vous utilisez tous les jours, comme un syscall, Tokio ou du code de système de fichiers. C’est très facile. Allez simplement le lire. En y consacrant une semaine, vous l’apprendrez comme n’importe quel autre code. Et vous aurez l’impression d’être un putain de génie. Vous vous direz : ah, maintenant je peux travailler sur le kernel, vous voyez ?

Quel est aujourd’hui le meilleur moyen de commencer à contribuer ?

Je préfère que les gens rejoignent Discord et le canal de développement du Discord Solana Tech. Par exemple, une personne travaille sur des éléments de réseau et, l’autre jour, elle a simplement lancé une discussion sur le code TPU. Pour être honnête, elle comprend mieux le fonctionnement de ce code que la plupart des gens chez Anza. Vous pouvez réellement contribuer. Et si vous êtes aussi bon que cette personne et que vous m’envoyez des correctifs, je les fusionnerai.

Nous faisons peu de développement interne et non ouvert. Donc, si vous ne voyez pas de pull request sur une partie du code que vous jugez lente, que vous connaissez bien,, et que vous voulez la corriger, dites-le-moi sur Discord. Nous créerons une issue, nous vous l’attribuerons et vous la corrigerez.

Je veux que les gens m’envoient des correctifs. Je veux développer notre communauté grâce à ces contributions.

Questions en rafale

Quel est le bug le plus difficile que vous avez éliminé cette année ?

Une erreur de compilation dans du code à virgule flottante qui bloquait la sortie de la version 2.2 il y a quelques mois. Ce n’était pas le plus difficile, mais c’était le plus fastidieux, car j’ai dû passer des jours entiers à lire du code assembleur.

Quelle musique écoutez-vous en boucle lorsque vous scrutez des flame graphs ? 

Généralement de la house ou de la techno minimale. Stephan Bodzin tourne souvent en boucle.

Quelle est votre distribution Linux préférée ? 

Debian, sans aucun doute. C’est la seule qui ne soit pas extrêmement agaçante, haha.

Quelle est la meilleure optimisation à venir avec Alpenglow ? 

Nous n’allons plus exécuter les votes. Les transactions de vote sont [censuré]. Et c’est formidable que tout le mécanisme de vote ne repose plus sur des transactions.

Que pensez-vous de la ZK ? 

C’est une excellente technologie, mais j’ai l’impression qu’elle en est encore largement au stade de la recherche pour le passage à l’échelle des blockchains. Cela ne m’intéresse donc pas énormément. 

En juillet 2026, dans un an, quelle durée prédisez-vous pour les slots ?

Personnellement, j’espère même y parvenir avant : je veux des slots de 200 millisecondes. Je répète à Toly qu’il doit en faire un mème jusqu’à ce que cela devienne réalité. J’espère donc que ce sera fait d’ici là. Je pense que nous pouvons même le faire aujourd’hui. Ce serait selon moi le minimum, au sens où tout résultat supérieur constituerait un échec, mais nous pouvons descendre encore plus bas.

Quand Agave atteindra-t-il le fameux million de TPS ? 

Haha, je ne vais pas répondre rapidement à celle-là. Je demande sans cesse aux gens : « D’où viendront ces un million de transactions ? »

Nous atteindrons un million de TPS lorsque les gens auront un million de TPS à envoyer, mais je crains que cela n’arrive pas de sitôt. J’ai tout de même déclaré que si Agave n’atteignait pas un million de TPS d’ici octobre, je quitterais mon emploi. Je vais donc peut-être devoir truquer une démo, haha. 

Conclusion

Alessandro Decina incarne le cœur battant de la culture de la performance de Solana : une quête incessante de vitesse fondée sur une ingénierie pragmatique plutôt que sur une perfection théorique. Son équipe performance joue bien au-dessus de sa catégorie, en identifiant et en corrigeant les « bugs stupides » dont l’accumulation provoque des ralentissements systémiques.

Dans un monde où de nombreuses équipes se perdent dans de grandes visions architecturales, l’équipe performance d’Anza reste entièrement concentrée sur les goulots d’étranglement qui se trouvent juste devant elle. Profiler, identifier, corriger, recommencer. C’est un travail peu prestigieux qui produit des résultats spectaculaires : une blockchain qui passe réellement à l’échelle avec le matériel, plutôt que de le contourner.

La conversation ci-dessus révèle une vérité fondamentale sur la construction de systèmes hautes performances : la vitesse ne dépend pas seulement d’algorithmes ingénieux ou de matériel de pointe. Elle repose sur un engagement culturel à ne jamais accepter le « suffisamment bien » lorsque l’excellence est techniquement atteignable. Pour Solana, cela signifie que des slots de 200 millisecondes, Async Execution, Multiple Concurrent Leaders et le maintien de plus d’un million de TPS ne sont pas de simples jalons techniques : ils sont inévitables.