Fusées, menaces quantiques, zéros et uns : Dean Little façonne la vérité de Solana

Introduction

Les blockchains reposent sur des mensonges. Plus précisément, des mensonges polis qui prennent la forme de couches d’abstraction. Le développeur voit un monde rempli de SDK, d’API et de frameworks qui promettent rapidité et sécurité. La réalité est bien plus nuancée, jonchée de registres, de syscalls et de bytecode — une réalité dans laquelle seuls les plus téméraires osent s’aventurer. En pratique, chaque abstraction ajoute une surcharge et chaque compilateur dissimule la vérité.

Dean Little a passé sa carrière à naviguer parmi ces mensonges, en cherchant la vérité à coups de circuits soudés et d’EEPROMS flashées. Avec Bitcoin, il a créé des pools de minage, des kernels GPU et des outils SPV, en restant aussi proche que possible de la machine et en découvrant le potentiel de systèmes distribués qui, à l’époque, ne parvenaient jamais vraiment à tenir leurs promesses. Puis il a découvert Solana, où il est connu pour son hérésie : écrire de l’assembleur à la main, mépriser les compilateurs et détourner les syscalls — non pas parce que c’est amusant, mais parce que la vitesse est la vérité.

En tant que directeur scientifique de Zeus Network, il a réimplémenté de zéro l’intégralité du protocole Bitcoin sur Solana, permettant à la liquidité BTC de circuler sans friction. Et, dans une démonstration imparable face au FUD quantique, il a conçu un coffre-fort fondé sur les signatures à usage unique de Winternitz, capable de migrer des dizaines de milliers d’actifs par seconde, tandis que d’autres ne font qu’en rêver de six. 

Mais Dean est aussi enseignant. De Turbin3 à Blueshift, en passant par son récent travail en DevRel pour l’équipe des marchés mandarinophones et cantonophones de Solana Foundation, il fait entrer les développeurs dans un monde que la plupart ne verront jamais. Il a appris à des centaines de développeurs à déployer on-chain, souvent dans leur propre langue et en partant de zéro. Il vit dans une tension permanente : attirer les gens vers le haut grâce aux abstractions, puis les ramener vers la machine. 

Je voulais comprendre ce que signifie vivre dans cette tension — entre pédagogie et expérimentation, abstraction et assembleur, code écrit pour les humains et instructions destinées aux machines. Cet entretien porte sur ce dialogue et sur ce que signifie parler directement à la machine quand tous les autres parlent sans vraiment s’adresser à elle.

Cette conversation a été remaniée et condensée par souci de concision. 

Entretien

Origines et vision du monde

Ichigo : Bien avant Solana, vous répariez du matériel, flashiez des EEPROMs et écriviez des systèmes de contrôle embarqués pour des fusées. En quoi le fait de travailler si près du matériel — littéralement avec des fers à souder et du firmware — a-t-il façonné votre vision du monde en tant que créateur ?

Dean Little : J’ai appris à souder vers l’âge de dix ans. J’ai grandi en travaillant avec des microprocesseurs et des microcontrôleurs, puis je suis passé au développement web et mobile avant de rejoindre une startup de fusées en Norvège.

Travailler sur des systèmes embarqués critiques vous apprend plusieurs choses très importantes. D’abord, l’attention aux détails, car si quelque chose tombe en panne, la situation peut très vite dégénérer. Ensuite, la simplicité : les systèmes simples, rapides et faciles à comprendre sont généralement préférables aux systèmes trop complexes. Enfin, vous apprenez à raisonner comme un adversaire. 

Pour moi, travailler sur les commandes de ballast de fusées océaniques, c’est se demander constamment : que se passe-t-il si ce contrôleur tombe en panne ? Comment détecter la panne ? De quelles solutions de secours disposons-nous ? Et si notre contrôle d’attitude est incorrect et que nous pensons pointer vers le haut alors que nous pointons en réalité vers le bas ? Cela vous oblige à concevoir en prévision des défaillances, plutôt que de supposer que tout fonctionnera toujours.

On apprend également à ne pas faire aveuglément confiance au travail des autres. Cela vaut pour le logiciel comme pour le matériel. Les fabricants changent les spécifications, le service des achats peut commander la mauvaise pièce par erreur et, soudain, plus rien ne fonctionne. Tant de choses peuvent mal tourner, et une seule petite erreur suffit à faire tomber tout le système. Cet état d’esprit ne m’a jamais quitté depuis. 

Votre carrière vous a ensuite rapidement conduit vers Bitcoin. Vous avez travaillé sur des pools de minage, des kernels GPU, des outils SPV, puis sur Twetch. Que vous ont appris ces années consacrées à l’infrastructure Bitcoin sur la conception de systèmes distribués à grande échelle et sur les limites des blockchains de l’époque ?

Je me suis consacré à plein temps au développement Bitcoin vers 2017. J’ai développé sur plusieurs blockchains — Bitcoin, EOS et quelques autres qui étaient populaires à l’époque. Avec Bitcoin, j’ai commencé comme simple utilisateur, mais lorsque les frais ont explosé, le réseau est devenu pratiquement inutilisable. C’était la première véritable ruée du grand public vers la crypto, et j’ai alors compris que dès que les frais s’envolent, la blockchain devient inutile.

Cette expérience m’a amené à reconsidérer le prétendu « trilemme de la scalabilité ». Franchement, c’est un problème inventé de toutes pièces. Même en 2017, nous pouvions envoyer des photos de 4 Mo à l’autre bout du monde en moins d’une seconde. Il paraissait ridicule de croire que les blockchains ne pouvaient pas dépasser des blocs de 1 Mo. La limite ne venait pas de la physique, mais de la conception. 

Comme la couche de base de Bitcoin est très contrainte, il faut innover autrement. J’ai fini par me plonger dans Secp256k1 pour concevoir des solutions permettant de dissimuler les résultats d’exécution dans les signatures. C’était une forme rudimentaire de calcul vérifiable, bien avant le véritable essor de ZK.

Ces années m’ont appris que diriger une entreprise Bitcoin revient en réalité à diriger une entreprise d’infrastructure. Le protocole Bitcoin peut faire beaucoup de choses, mais le logiciel des nœuds est limité. Le modèle UTXO est excellent pour la parallélisation, puisque l’état est séparé, un peu comme avec les comptes Solana, mais il est très mauvais pour l’état partagé et l’indexation. À l’inverse, le modèle de comptes d’Ethereum est excellent pour l’état partagé, mais très mauvais pour la parallélisation. Ce qui m’a convaincu avec Solana, c’est son modèle de comptes séparés : il associe la parallélisation des UTXO à la facilité d’utilisation du modèle d’état global d’Ethereum.

La grande leçon que j’ai tirée de ces années, c’est que les systèmes tombent souvent en panne et qu’ils doivent donc être conçus pour échouer proprement plutôt que de manière catastrophique. Il ne faut jamais simplement accepter les limites. Il faut les repousser de manière créative, d’une façon à laquelle personne n’a encore pensé. C’est la philosophie que j’ai appliquée à mon travail sur Solana.

Aujourd’hui, beaucoup de membres de la communauté Solana vous connaissent comme celui qui écrit en assembleur et méprise les compilateurs. Pourquoi rester si proche de la machine ? Pourquoi ne pas vous concentrer davantage sur l’amélioration des abstractions de plus haut niveau, puisque c’est là que la majorité des développeurs travailleront ?

Contrairement à ce que l’on croit souvent, je contribue à Anchor, Pinocchio, Agave, Alpenglow — à pratiquement tout. J’ai travaillé sur la cryptographie, les SIMD et les programmes de bas niveau, sur l’ensemble de la stack. 

Le principal problème du développement sur Solana, c’est qu’en dehors des programmes on-chain et de l’infrastructure, tout est entièrement soumis à autorisation. Il m’est presque impossible de faire fusionner mes PRs dans un dépôt officiel. Mais les programmes on-chain ? Je peux faire tout ce que le système m’autorise accidentellement à faire. Là, rien ne me retient. C’est sans autorisation. Je peux continuer à améliorer les choses et à tout déchirer.

La question est donc la suivante : si vous regardez mon travail, sa qualité et ce que j’ai accompli pour les programmes on-chain, et que vous voulez que cela se produise dans les autres couches de la stack, commencez à fusionner mes PRs, haha.

Concernant l’assembleur, franchement, le compilateur fait un travail épouvantable, et les personnes qui travaillent dessus ne font guère mieux. Elles n’ont jamais pris le temps d’écouter réellement leurs clients finaux, à savoir les développeurs. C’est pour cela que nous avons dû créer notre propre chaîne d’outils indépendante afin de nous faciliter la vie.

Malheureusement, la plupart des développeurs sont assez moyens. Ce n’est pas péjoratif, mais ils ne sont pas comme Cavey, moi-même ou les cadors de la DeFi chez Ellipsis qui savent vraiment écrire du code très performant. Nous formons cet étrange petit sous-ensemble de développeurs qui savent repousser les limites du système au niveau le plus bas et l’améliorer pour tous les autres. 

Nos retours pourraient être extrêmement précieux, mais la plupart du temps, ils ne sont pas pris au sérieux. Nous finissons donc par innover sur les éléments que personne ne peut nous empêcher de toucher — à savoir la VM. C’est pour cela que, sur ce point, je reste proche de la machine. 

Innovations et contributions techniques

À propos de votre travail dans différentes parties de la stack — entre Zeus, Jupiter et votre temps libre —, vous avez créé et intégré plusieurs primitives cryptographiques avancées. La cryptographie on-chain, quelle qu’elle soit, est notoirement difficile à mettre en œuvre sur Solana. À quoi ressemblera l’avenir de la cryptographie sur Solana ? Et, à part crier sur les gens pour qu’ils fusionnent les PRs, haha, comment pouvons-nous aider les autres à créer plus facilement des primitives avancées ?

Selon moi, il y a quelques années, toute une série d’équipes ZK étaient prêtes à développer sur Solana. Nous leur avons en gros dit : « Oui, ça arrive », puis Firedancer est arrivé et a dit : « Non, nous ne fusionnerons pas ça », et tout a été repoussé. Certaines de ces équipes avaient levé des fonds et ne pouvaient littéralement pas exploiter leur entreprise faute de disposer des primitives cryptographiques on-chain nécessaires. Elles ont donc été contraintes d’aller ailleurs. Cela a été très dur. Traiter les développeurs ainsi est inadmissible. Les premiers clients du protocole sont les développeurs : si vous ne prenez pas soin d’eux, rien ne se construit et le grand public n’a alors rien à utiliser. 

Alors je me suis dit : très bien, je vais trouver la solution moi-même. J’ai détourné le syscall de récupération Secp256k1 et, en gros, débridé toute la courbe. Vous pouvez désormais utiliser des signatures Schnorr, des engagements de Pedersen, des Bulletproofs, des multiplications arbitraires sur courbe elliptique et même des adresses Taproot modifiées, le tout sans le moindre changement de protocole et pour seulement environ 25 000 CUs. Tout cela par une seule personne, sur son temps libre. J’ai livré davantage de protocoles cryptographiques qu’Anza, pas vrai ? Imaginez ce qui serait possible si ce travail était réellement encouragé. Imaginez si le développement était plus ouvert. 

Ce qui est amusant, c’est que la plupart des gens ne mesurent même pas l’importance de cette avancée. Je vais à une conférence et j’explique à certains membres d’Arcium ce que j’ai créé. Ils me répondent : « C’est incroyable. » Mais, en dehors des quelque dix personnes qui comprennent vraiment la crypto(graphie) à ce niveau sur Solana, personne ne le remarque vraiment. 

Quant à Anza, ce sont des gens bien, mais ils n’ont qu’un seul cryptographe, Sam Kim. Même s’il est plutôt bon, le fait que personne d’autre chez Anza ne connaisse quoi que ce soit à la cryptographie me paraît assez inquiétant. Ils m’ont fait intervenir comme relecteur pour la mise à niveau Alpenglow. Je relis le code de Sam et, dans l’ensemble, il est bon et ses idées sont sensées. C’est sans doute positif qu’ils reconnaissent et exploitent les compétences de quelqu’un d’autre. Mais, au bout du compte, Anza ne deviendra probablement jamais vraiment excellent dans ce domaine. Il faut plusieurs entreprises concurrentes, avec certains recoupements, mais aussi leurs propres spécialités. Cela n’a aucun sens qu’Anza essaie de tout faire. Nous avons réellement besoin de diversifier le développement du cœur du protocole.

Pensez-vous qu’il s’agisse plutôt d’un problème culturel ? Par exemple, Ethereum dispose de L2 entièrement consacrés à ZK, comme ZKsync ou StarkWare. Solana a-t-elle simplement considéré ZK comme une approche vague de la scalabilité ? Du genre : nous préférons exploiter le matériel au maximum, c’est donc notre priorité — nous ferons évoluer la chaîne ainsi. Et même si ZK ne doit pas nécessairement servir uniquement à la scalabilité sur Solana, cette technologie a été réduite à cet usage et se trouve maintenant dans une situation étrange ?

Je pense que les outils ne sont pas bons. Il n’existe aucun tutoriel expliquant comment les utiliser. Blueshift va en ajouter : nous essayons simplement de fusionner les éléments SIMD Little Endian. Une fois cette fusion effectuée, nous publierons un modèle ZK simple à utiliser et très performant, ainsi que quelques tutoriels, car nous voulons permettre aux gens de créer plus facilement et de comprendre le fonctionnement de ces outils.

Pour le moment, passer de zéro à Hello, World! sur Solana est absolument ridicule. Regardez Sui : suivez la documentation pendant cinq minutes et vous aurez un Hello, World! fonctionnel. Solana n’a pas cela. Voilà la différence entre Mysten Labs, qui recrute une dizaine de personnes connaissant la cryptographie, et Anza, qui n’en recrute qu’une, pas vrai ?

Selon moi, l’hypothèse qui prévaut est que Solana Foundation manque cruellement de compréhension technique sur, disons, à peu près tout. Sa conception de la technologie ne dépasse pas la commercialisation, n’est-ce pas ? Au-delà, elle externalise la réflexion sur ces sujets auprès d’Anza. L’idée est que si la réponse d’Anza affirme que c’est bon, alors cela doit l’être. En réalité, la plupart du temps, la réponse est bonne sur le plan des performances, mais pas vraiment sur le reste.

La Foundation part du principe que tout se passe très bien. Mais pour les développeurs, l’expérience ressemble plutôt à : « C’est difficile à utiliser. » C’est terriblement pénible pour les personnes qui sont meilleures que celles chargées des implémentations au niveau du protocole, qui travaillent bénévolement, mais dont les contributions ne sont pas prises au sérieux. C’est comme si l’on disait : « Je ne sais pas, ils n’ont pas le badge magique Anza, ignorons-les et évitons de prendre le risque réputationnel de fusionner une PR de la communauté. » Voilà sans doute pourquoi vous constatez que je me bats avec acharnement et défends beaucoup les développeurs open source : pour nous débarrasser de ce problème, car je pense que de nombreuses personnes de la communauté proposent d’excellentes PRs. Bien sûr, il y a beaucoup de bouillie générée par l’IA et beaucoup de merde, mais aussi énormément de personnes très compétentes qui méritent qu’on leur accorde du temps. C’est une blockchain, un réseau distribué : nous ne devrions pas avoir besoin d’une sorte de badge Anza pour contribuer. Ils devraient simplement avoir la responsabilité de se soucier du bon code, qu’ils l’aient écrit ou non.

Malgré tout cela, pour revenir à l’innovation et à la cryptographie, vous avez également créé sur Solana un coffre-fort résistant aux attaques quantiques à l’aide de signatures à usage unique de Winternitz. Qu’est-ce qui vous a inspiré ce projet et comment pensez-vous qu’il évoluera à l’avenir, peut-être lorsque les menaces quantiques deviendront plus crédibles ?

Honnêtement, tout est parti d’un tweet, haha. Un maximaliste Bitcoin a publié à la fin de l’année dernière : « Solana sera la première victime du quantique. » J’ai lu cela et pensé : « D’accord, mon pote. Si nous devons un jour faire migrer les gens d’une cryptographie vulnérable aux attaques quantiques vers une cryptographie qui y résiste, notre chaîne pourra effectuer plus de 50 000 migrations par seconde. La tienne pourra en faire environ six. Laquelle va vraiment se faire démolir en premier ? »

Alors je me suis dit : merde, je vais le faire. 

Dix jours plus tard, j’ai publié le coffre-fort Winternitz et cité son tweet en disant : GG. 

Voilà ce qui m’a motivé : quelqu’un affirmait que c’était impossible. Je réfléchissais déjà depuis quelque temps aux schémas de signature post-quantiques, mais cela m’a décidé à passer à l’action.

Et cela a fonctionné. Vous pouvez stocker des fonds dans une PDA hors courbe, utiliser le coffre-fort Winternitz et, quoi qu’il arrive — que le registre soit restauré à une version antérieure ou que des attaques quantiques perturbent les signatures des leaders —, vos fonds resteront en sécurité, au moins dans la version vers laquelle nous reviendrons. Ce n’est pas une solution définitive, mais c’est un canot de sauvetage idéal. 

Si vous gérez un fonds détenant des millions ou des milliards en LSTs ou en SOL stakés et que la résistance quantique devient soudain une exigence réglementaire, cela ne constitue plus un obstacle à l’adoption. Vous n’avez pas besoin de mettre à niveau le protocole. Cela fonctionne, tout simplement.

À ce jour, j’ai créé un firmware Ledger qui signe ces signatures, ainsi qu’un wallet et une application web. Blueshift cherchera probablement à rendre tout cela plus accessible plus tard cette année. Ce n’est évidemment pas encore urgent, mais l’essentiel est que cette possibilité existe dès aujourd’hui. Voilà la véritable avancée.

C’est assez drôle, en fait. Toly m’a envoyé un message privé le lendemain. En plaisantant, il m’a dit : « Mon pote, je pensais devoir prendre discrètement ma retraite lorsque les ordinateurs quantiques arriveraient. » Je lui ai répondu : « Haha, non, ne prends pas ta retraite. On assure tes arrières. »

À propos de Bitcoin, vous êtes directeur scientifique de Zeus Network, où vous avez pratiquement réimplémenté de zéro l’intégralité du protocole Bitcoin sur Solana. Quels ont été les principaux défis ? Et imaginez-vous un avenir où d’autres chaînes seraient réimplémentées sur Solana ?

C’est une question extrêmement intéressante. De la même manière que les signatures Winternitz étaient très coûteuses en calcul, mais restaient tout juste réalisables dans une seule transaction, Bitcoin se trouve dans la même zone idéale. Il est suffisamment sophistiqué pour permettre des éléments comme les preuves SPV, mais reste assez rudimentaire pour que Solana, une plateforme plus avancée et plus performante, puisse prendre cette chose et la placer dans celle-ci.

Avec les blockchains de deuxième génération comme Ethereum, c’est plus délicat. Elles sont beaucoup moins rudimentaires et bien plus complexes. La question devient donc : Solana peut-elle continuer à accélérer tout en allouant de plus en plus de ressources à chaque transaction ? 

Pour le moment, cela reste difficile, mais pas impossible. Le principal élément qui manque aujourd’hui pour assurer la compatibilité EVM est le syscall BigModExp. Si nous l’activions, je pense que nous pourrions nous rapprocher considérablement d’une parité totale avec Ethereum au niveau de la VM, ce qui est assez fou quand on y pense. 

Mais la vraie question est : pourquoi s’en donner la peine ? 

Pour Bitcoin, la réponse est évidente : il représente des milliers de milliards en valeur, constitue la référence absolue en matière de monnaie et reste suffisamment rudimentaire pour que Solana puisse le répliquer proprement. 

Ethereum ? Beaucoup moins. 

L’« ultrasound money » est un mème. Pendant un bref instant, le budget de sécurité de Solana a même dépassé celui d’Ethereum. Cela fait-il de Solana une ultrasound money ? Le fait d’envelopper des ETH sur Solana crée beaucoup moins de valeur que d’y envelopper des BTC.

Donc oui, je pense que Bitcoin était la bonne première cible. C’était techniquement réalisable et économiquement pertinent. À mesure que Solana progressera, nous verrons peut-être d’autres chaînes réimplémentées à leur tour. Mais honnêtement, plus Solana gagnera en performances, moins il sera nécessaire de s’embarrasser des autres chaînes.

La possibilité de regrouper toutes ces fonctionnalités dans une seule transaction est vraiment intéressante. Récemment, vous vous êtes passionné pour les mises à jour d’oracles ultraperformantes, en repoussant les limites avec Doppler et ses mises à jour à 21 CUs. En quoi ces prouesses à faible consommation de CUs illustrent-elles l’avantage de Solana sur les autres chaînes ? Nous avons observé des évolutions similaires sur d’autres chaînes avec le gas golfing, mais quelles possibilités propres à Solana cela ouvre-t-il ?

Les oracles constituent une étude de cas très intéressante, car tout le monde considère plus ou moins le problème comme « résolu ». 

Si vous remontez à environ un mois, Cavey a repris mon programme noop et atteint 100 000 transactions par seconde sur le mainnet. C’était impressionnant. Nous allons maintenant voir si nous pouvons aller encore plus loin. Plus précisément, atteindre 100 000 mises à jour d’oracle par seconde sur le mainnet. 

Si c’est possible, cela pulvérise complètement tout le discours selon lequel « nous avons besoin de temps de bloc plus rapides pour concurrencer Binance ». Si vous pouvez actualiser un oracle cent mille fois par seconde, qui se soucie des mises à jour de Binance toutes les 20 millisecondes ?

C’est tout l’intérêt de l’hyperoptimisation. Les AMMs propriétaires utilisent déjà plus ou moins ce type de mise à jour — pas exactement ce que je publie, mais ceux qui savent, savent. Pour le moment, ils intègrent cette logique au cœur de leurs stratégies de trading. 

Avec Doppler, il n’y a guère de raison de conserver cette complexité dans leurs programmes. La mise à jour de l’oracle peut simplement en être entièrement extraite et s’exécuter séparément.

L’empreinte est également minuscule. L’oracle Doppler ne fait qu’environ 480 octets. Je prépare même un SDK TypeScript pour permettre aux développeurs de déployer leur propre version personnalisée directement depuis TypeScript, sans avoir à toucher à Rust. Il suffit de définir un schéma Borsh, de le publier, puis d’envoyer des mises à jour d’oracle à pleine vitesse. Les développeurs Rust peuvent évidemment faire la même chose, mais je trouve intéressant que même un développeur TypeScript puisse désormais accéder à ce niveau de performances grâce à de l’assembleur hyperoptimisé en coulisses.

Concernant les cas d’usage : oracles d’aléa, perps, AMMs à oracle, AMMs propriétaires — tous en bénéficient. Mais cela vaut aussi pour des éléments comme les canaux de paiement ou la mise à l’échelle L2. Pouvoir ouvrir et fermer des canaux à un coût pratiquement nul est considérable. En somme, vous n’avez plus besoin d’un gigantesque programme Anchor omniprésent simplement pour mettre à jour un oracle. 

Abstraction, assembleur et IBRL

Compte tenu de votre réputation dans l’écriture en assembleur, pensez-vous que la plupart des développeurs devraient réellement y toucher un jour ? Ou s’agit-il d’un domaine dans lequel seules quelques personnes repoussent les limites pour que les autres puissent travailler sereinement plus haut dans la stack ?

Je pense que tout le monde devrait l’apprendre, au moins un peu. George Hotz, probablement le meilleur programmeur vivant, dit que tout le monde devrait apprendre Python, C et l’assembleur. 

Si vous ne comprenez pas l’assembleur, vous ne comprenez pas vraiment ce que fait le compilateur. Si vous ne comprenez pas C, vous ne mesurez pas toutes les facilités que Python vous apporte. Je ne trouve pas Python si formidable, mais Rust, par exemple, est un langage très expressif qui peut s’utiliser à haut comme à bas niveau. C’est un excellent choix.

Donc oui, je conseillerais d’apprendre un peu d’assembleur et de Rust. À un moment donné, vous devrez également apprendre TypeScript si vous voulez écrire des frontends. En fin de compte, vous créez des produits pour des personnes, et si vos utilisateurs sont des développeurs, TypeScript finira dans votre champ de vision, que cela vous plaise ou non.

Quand j’ai commencé à écrire en assembleur sur Solana, personne ne le faisait, littéralement. J’ai créé les outils, publié des exemples et, aujourd’hui, quelques centaines de personnes s’y sont essayées. Une dizaine sont peut-être vraiment compétentes. Certaines ont même écrit des programmes plus impressionnants que les miens. Il s’agit surtout d’y consacrer le temps nécessaire.

Je crée principalement des éléments petits, élégants, hyperperformants et dédiés à une seule fonction, là où j’entrevois une réduction potentielle par 100 du coût d’exécution. Mon rôle consiste davantage à explorer, à inspirer et à laisser les autres pousser plus loin. À ce stade, faire moi-même la promotion de tout ce que je crée ne m’apporte pas grand-chose. Je préfère donc mettre les autres en avant, les retweeter et les aider à se faire un nom.

Donc oui, je pense que tout le monde devrait au moins apprendre l’assembleur. C’est un excellent exercice. Mais il est également vrai qu’une poignée de personnes qui repoussent fortement les limites au plus bas niveau peuvent créer des améliorations dont tout le monde bénéficie. 

Si vous examinez la grande majorité des améliorations apportées à Pinocchio ces six derniers mois, elles proviennent toutes d’optimisations en assembleur. Febo a passé en revue chaque PR comme un véritable champion et a fait fusionner d’excellentes contributions. Regardez par exemple p-token : c’est le même concept. 

Voyez-vous le code de bas niveau non seulement comme un choix technique, mais aussi comme quelque chose de plus idéologique ?

Oui, je pense que c’est les deux. Pourquoi les gens veulent-ils mettre un JPEG sur Bitcoin, par exemple ? Utiliser ce système très limité pour quelque chose qu’il n’a jamais été conçu pour faire présente un caractère rudimentaire et intrinsèquement intéressant. C’est à la fois assez hilarant et plutôt beau. 

La curiosité s’arrête lorsque vous cessez de poser des questions. 

Ainsi, si vous êtes curieux, le point d’aboutissement logique de votre curiosité ressemble probablement à ceci : « J’ai écrit quelque chose en TypeScript qui consommait un programme Anchor. Comment fonctionne Anchor ? Comment fonctionnent les macros ? Comment fonctionne Rust ? Comment fonctionne l’assembleur ? » 

Vous commencez peut-être ensuite à explorer en profondeur le compilateur Rust, puis MIR, puis LLVM IR et la manière dont le tout est compilé en eBPF. Vous vous demandez alors ce qu’est eBPF et vous vous renseignez sur son assembleur. Enfin, vous vous retrouvez face au bytecode brut et réalisez que vous pouvez économiser quelques octets parce que le compilateur n’a pas automatiquement optimisé quelque chose. C’est l’aboutissement logique de cette recherche. Il y a clairement une dimension idéologique.

Vous travaillez également avec Solana Foundation afin d’aider les équipes mandarinophones et cantonophones à démarrer, à déboguer et à développer. Vous accompagnez toutes ces équipes en simplifiant les choses et en les rendant plus accessibles. En parallèle, vous êtes connu pour défendre l’assembleur et détourner les syscalls. Comment conciliez-vous ces deux aspects ? Comment trouvez-vous l’équilibre entre le fait de rapprocher les développeurs du matériel et la nécessité pratique de les accompagner au moyen d’abstractions de plus haut niveau ?

Si vous regardez Blueshift, nous avons conçu tout un continuum allant du débutant à l’expert. Mon point de vue est simple : vous obtenez le niveau de développeurs correspondant à celui auquel vous les formez. Si vous n’enseignez qu’Anchor ou TypeScript, vous n’attirez que les développeurs qui pensent que cela suffit. Mais si vous commencez à parler d’économiser chaque unité de calcul grâce à de l’assembleur écrit à la main, vous attirez des développeurs d’un tout autre calibre, des gens qui comprennent réellement le sens de ces mots.

Avec Blueshift, notre stratégie consiste à viser d’abord le milieu de la courbe. C’est là que se trouve le plus grand nombre de personnes et que le ROI est le meilleur. Nous les faisons ensuite progresser vers la droite, les aidons à monter en compétence et finissons par disposer d’une armée de développeurs solides qui peuvent à leur tour soutenir le côté gauche de la courbe, celui des débutants absolus.

Cette approche est tout simplement plus évolutive. Je pourrais passer des heures chaque jour à apprendre aux débutants à effectuer un CPI vers le Token Program, ce qui représente 90 % de tous les programmes Solana. Ou je peux former cent personnes à faire la même chose, chacune pouvant ensuite en intégrer cent autres. C’est ainsi que l’on passe à l’échelle. 

Nous voulons accueillir les gens quel que soit leur niveau et continuer à les faire progresser vers la droite. Blueshift, Solana Foundation : l’objectif est le même.

Formation, transmission des connaissances et communauté

À propos de Blueshift, vous l’avez cofondé en parallèle de Turbin3, deux initiatives dotées d’une forte mission pédagogique. Comment voyez-vous leur évolution future ? 

Turbin3 n’était pas très développé lorsque je l’ai rejoint. Je suis arrivé, j’ai écrit tous les programmes du cursus et j’ai commencé à tout gérer. Je pense avoir dirigé trois ou quatre cohortes et formé toutes les personnes qui enseignent aujourd’hui. En neuf mois, je suis passé de rien au fait de pouvoir être remplacé grâce à une bonne formation. Il ne me restait donc plus grand-chose à faire. Former efficacement des personnes grâce à une formation de qualité montre qu’un cercle vertueux évolutif est possible.

Le problème, c’est qu’ils reçoivent un millier de candidatures chaque trimestre et en rejettent peut-être 800 à 900. Les personnes admises suivent un cursus de six semaines durant lequel elles doivent assister aux cours trois fois par semaine. À la fin, elles ne reçoivent aucun certificat ni aucune preuve qu’elles ont terminé la formation. Peut-être que l’équipe se portera garante pour vous, peut-être pas. Mais six semaines, c’est long pour espérer que rien ne se passe mal dans votre vie. Votre chien peut tomber malade, vous devez l’emmener chez le vétérinaire et manquer quelques cours, puis vous prenez soudain du retard et vous êtes exclu. Les bootcamps traditionnels coûtent beaucoup de temps et d’argent à organiser, et ils ne sont pas vraiment conçus pour sélectionner les meilleurs développeurs. Soit vous aidez des personnes qui n’avaient pas réellement besoin du bootcamp au départ et cherchaient seulement un point de départ pour leur carrière, soit vous accompagnez probablement pas à pas des personnes qui n’auraient pas réussi sans ce soutien constant. Aucune de ces approches ne permet de faire évoluer l’intégration des développeurs à l’échelle dont Solana a besoin aujourd’hui.

La meilleure question est donc la suivante : comment prendre les 800 à 900 personnes refusées par les bootcamps et donner une chance à celles qui en sont réellement capables ? 

Avec Blueshift, la réponse a consisté à créer un apprentissage autonome de haute qualité. Si vous pouvez suivre le contenu, vous pouvez le terminer à votre rythme et obtenir un NFT qui l’atteste. Tout est open source et nous encourageons activement les pull requests de la communauté, en mettant leurs auteurs en avant sur Twitter pour les aider à promouvoir et lancer leur carrière. Les gens proposent des améliorations, nous les fusionnons et toute la plateforme en ressort meilleure.

Au lieu de dire : « Désolé, votre candidature n’a pas été retenue, vous aurez peut-être plus de chance la prochaine fois », nous disons : « Voici le cursus, lancez-vous et terminez-le à votre rythme. » Les cours sont déjà traduits en huit langues, ce qui permet d’organiser des meetups ou des bootcamps partout dans le monde. Superteam peut les utiliser. Forma peut les utiliser. À la fin, vous disposez d’un critère objectif : les participants gagnent le même NFT, vous connaissez leur niveau et vous pouvez les recruter ou leur proposer des défis adaptés.

Blueshift résout tous ces problèmes en se concentrant sur les développeurs motivés et capables de suivre un apprentissage autonome de haute qualité. Nous acceptons le fait que si tout est open source, les gens seront plus critiques, ce qui permettra à la sagesse de la communauté de s’exprimer. Nous fusionnons donc leurs PRs et obtenons ainsi la meilleure plateforme et les meilleurs contenus pédagogiques disponibles.

Vous avez déjà répondu implicitement, mais pour formuler la question plus directement : considérez-vous la formation des développeurs davantage comme un problème de traduction — rendre les idées complexes plus accessibles — ou comme un problème de bootcamp — amener rapidement beaucoup de personnes à un niveau de base —, ou comme tout autre chose ?

Oui, le principal problème de la formation des développeurs aujourd’hui, c’est que les ressources gratuites que nous publions sont nulles. Beaucoup sont obsolètes. Tout le monde écrit essentiellement avec Anchor ou Pinocchio. Personne n’utilise solana_program. Tout devient très vite obsolète. En rendant tout open source, nous pouvons donc élaborer rapidement et méticuleusement du contenu de qualité, puis le maintenir. Personne d’autre ne semble vraiment vouloir le faire. Nous allons donc nous en charger, puisque personne d’autre ne le veut. 

Même Mert l’avait compris il y a six mois lorsque nous en parlions. De son point de vue, il était heureux que quelqu’un ait décidé de s’occuper de ce problème. Et qui de mieux que nous, pas vrai ? J’ai la chance d’être l’un des développeurs les plus influents de cet écosystème. Tout est open source. Nous n’avons aucun avantage défensif, haha. Nous ne bénéficions pas d’une énorme subvention de la Foundation : nous nous autofinançons. Nous avons tout fait nous-mêmes, et notre seul avantage est notre capacité d’exécution. 

La formation est un continuum. Il faut retrouver les gens là où ils en sont, avec des sujets suffisamment difficiles pour qu’ils apprennent quelque chose, mais aussi assez simples à comprendre et accessibles pour leur donner envie de revenir. Ensuite, vous commencez à les attirer vers la droite avec des défis passionnants. Je pense être doué pour cela, ce qui fait de Blueshift la plateforme ultime pour happer les passionnés. Et soudain, vous vous dites : « Mais merde, pourquoi suis-je en train d’écrire en assembleur ? » 

Le Discord de Blueshift propose également des services DevRel pour aider les gens à développer leurs projets lorsqu’ils sont bloqués. Le plus important, c’est que je ne réponds même pas à la plupart des questions qui y sont posées : la communauté s’en charge. C’est bien mieux que StackOverflow ou autre, car la communauté est solide et impliquée.

À quoi ressemblera l’avenir de Blueshift ?

L’avenir de Blueshift repose essentiellement sur deux produits : Coursera et LeetCode. Nous disposons déjà d’une version correcte — enfin, mieux que correcte, mais pas idéale — de ces deux produits, mais elle doit s’améliorer. Nous travaillons sur une V3, qui sera donc nettement meilleure. 

Nous voulons être extrêmement efficaces pour répondre aux besoins des développeurs capables de suivre un apprentissage autonome. Et honnêtement, c’est ce type de développeurs que je préférerais voir dans l’écosystème. 

Je veux des personnes qui retroussent simplement leurs manches et se lancent. Nous voulons leur faciliter autant que possible la tâche en leur fournissant de bonnes ressources. Ne leur faisons donc pas perdre leur temps avec des contenus obsolètes, des dépendances cassées et tout le reste. 

L’objectif final est de créer une plateforme où chacun peut apprendre ce qui l’intéresse sans être enfermé dans une case, puis prouver ses compétences en relevant différents défis. 

Questions-réponses express

Quelle musique avez-vous écoutée récemment en écrivant de l’assembleur ?

Haha, généralement du death metal.

Quel est le meilleur syscall à détourner sur Solana ?

secp256k1_recover

Préféreriez-vous écrire en C# ou en Java pour le reste de votre vie ?

Non.

Quel est le meilleur modèle : UTXO ou comptes ?

Un UTXO vaut davantage.

Si vous disposiez de ressources illimitées, quelle initiative pédagogique de vos rêves lanceriez-vous demain ?

Blueshift plus IRL. 

Quel conseil donneriez-vous pour enseigner les concepts Solana de bas niveau à de nouveaux développeurs sans les effrayer ?

L’autodérision.

Conclusion

Dans un monde d’abstractions de haut niveau que l’on fait accepter comme la « réalité » pour attirer les foules, Dean Little constitue une passerelle rare : un alchimiste du bas niveau qui forge des outils à partir des éléments les plus fondamentaux afin de hisser les autres sur ses épaules. Son parcours, des fusées à la multiplication de mises à jour d’oracles hyperoptimisées, révèle l’éthique d’un créateur. Une éthique inflexible dans sa quête de vérité : concevoir en prévision des défaillances, innover face aux limites et ne jamais accorder aveuglément sa confiance à quoi que ce soit.

Qu’il fasse apparaître par la seule force de sa volonté des coffres-forts quantiques ou qu’il fasse évoluer Blueshift pour captiver la prochaine génération de développeurs Solana surdoués — en espérant qu’ils puissent se tenir sur les épaules de géants et ne pas devoir mâcher autant de verre que nous autres —, Dean incarne la flamme du puriste, tempérée par la chaleur de la communauté. Il nous rappelle que le véritable progrès ne consiste pas seulement à jeter davantage de bois au feu et à empiler les couches : il faut retirer ces couches pour révéler le bourdonnement des machines et apprendre aux autres à danser avec lui.

Alors que Solana fonce vers son prochain bond en avant — qu’il s’agisse d’une parité EVM totale, d’Alpenglow ou de 100 000 mises à jour d’oracle par seconde —, le travail de Dean nous lance à tous un défi à voix basse : Pourquoi se contenter de mensonges polis lorsque vous pouvez souder votre propre réalité ? Si la curiosité est l’étincelle, les personnes comme Dean sont l’accélérant.

Plongez-vous dedans, détournez un syscall, surchargez une transaction de fonctionnalités complexes et, qui sait, vous en ressortirez peut-être avec votre propre canot de sauvetage quantique.