Andre Cronje : 99 % des projets sont de la camelote, mais il reste tout de même 1 % de valeur réelle
TechFlow SélectionTechFlow Sélection
Andre Cronje : 99 % des projets sont de la camelote, mais il reste tout de même 1 % de valeur réelle
« Si vous pensez qu'un projet de blockchain peut résoudre les problèmes financiers mondiaux, c'est tout simplement de la folie. »
Dédié à des analyses Web3 approfondiesInterviewé : Andre Cronje
Traduction : loxia.eth
Il s'agit d'un entretien approfondi avec Andre Cronje, d'une durée totale de 1 h 20 min.
Cet entretien inclut un bilan par Andre Cronje de sa carrière passée, ainsi que de nombreuses expériences, conseils pratiques et jugements personnels relatifs à son idéologie.
En tant qu'OG du secteur dans plusieurs domaines, il s'agit ici de l'interview la plus récente et la plus approfondie jamais réalisée avec Andre Cronje. Elle mérite d'être lue et prise comme référence.
L'article fait environ 20 000 caractères au total, divisés en 9 parties.
Andre Cronje estime qu’il est absurde de considérer n’importe quel projet blockchain comme un « tueur d’Ethereum ». Même si l’on additionne la valeur totale verrouillée (TVL) de tous les réseaux blockchain, y compris Bitcoin et Ethereum, ils ne représentent qu’une part insignifiante dans l’ensemble du monde financier. Croire qu’un seul projet blockchain pourrait résoudre les problèmes financiers mondiaux est tout bonnement fou.
1. Introduction
Modérateur 1 : Bonjour à tous, bienvenue dans l’émission « Bright Talks » ! Aujourd’hui, nous avons le plaisir d’accueillir Andre Cronje, fondateur de Yearn Finance, Phantom et Keeper Network, ainsi que contributeur majeur à de nombreux projets DeFi. Bienvenue dans notre émission, Andre !
Andre Cronje : Merci. Euh, cette présentation est un peu exagérée. Je suis juste quelqu’un qui aime écrire du code.
Modérateur 1 : En écoutant l’émission « Core Never Sleeps » de 2020, ils vous décrivaient comme un bâtisseur. Personnellement, je ne suis pas développeur, plutôt un intégrateur, mais je pense que vous vous sous-estimez. Vous avez une histoire très intéressante, de laquelle nous pouvons tous tirer des enseignements. Peut-être pourrions-nous commencer en 2017, lorsque vous êtes entré pour la première fois dans ce domaine, juste au moment de l’ère des ICO. Ce serait intéressant d’entendre comment vous avez commencé, et aussi d’expliquer à ceux qui n’étaient pas là à quel point cette époque était folle.
2. L’ère des ICO : Le voyage d’Andre dans la cryptomonnaie
Andre Cronje : Oui, avant de m’intéresser aux cryptomonnaies, j’étais un sceptique très traditionnel. Je venais du monde de la finance traditionnelle, où j’étais architecte et directeur technique d’une petite société financière. Nous faisions des systèmes à haut débit, utilisant Kafka et Scala à l’époque. C’était donc mon background en solutions financières à haut débit.
L’époque de 2017 ressemblait beaucoup à aujourd’hui sur bien des aspects, notamment à cause du bruit ambiant. Beaucoup d’équipes affirmaient résoudre des problèmes sectoriels que la finance traditionnelle et les systèmes distribués avaient peiné à régler pendant des décennies. Mais voilà que des jeunes de 18 à 20 ans, sans expérience professionnelle, lançaient une ICO, levaient 20 ou 40 millions, et prétendaient avoir résolu des problèmes de système distribué ou autres.
Je suis donc entré dans ce domaine initialement pour tester mes doutes, pour m’assurer que je n’avais rien manqué — après tout, il n’est pas rare qu’une technologie disruptive remplace une ancienne. Mon inquiétude portait sur le fait que le domaine blockchain manquait cruellement de recherches solides, de preuves concrètes, malgré toutes ces affirmations. J’ai donc commencé à lire des white papers, dont beaucoup semblaient théoriquement plausibles. Mais il y avait déjà un problème, qui existe encore aujourd’hui : beaucoup de concepts semblent logiques en théorie, on se dit « ça peut marcher », mais quand on passe à la pratique, certaines contraintes techniques empêchent leur fonctionnement tel que prévu.
Même si la théorie est correcte, ou même si le concept est valide, euh… cela ne veut pas dire que c’est faisable. Après avoir lu beaucoup de white papers, j’ai commencé à examiner le code, à faire mes propres audits de base. Je ne le faisais ni dans une optique de création de valeur, ni dans un cadre de due diligence. C’était simplement : j’ai lu ce white paper, il affirme résoudre le problème X ; je regarde le code, est-ce qu’il résout vraiment X ? Plutôt un exercice personnel.
Quand je publiais ces analyses sur Medium, je notais simplement : « Ce code ne correspond pas à ce qu’ils disent ici », « Ce dépôt n’a aucun lien avec leurs affirmations ». Pour une raison quelconque, j’ai rendu ces écrits publics, et durant l’ère des ICO, ils sont devenus très populaires, car il n’y avait presque pas de détracteurs, personne pour dire : « Ça ne marchera pas, car votre code prouve que vous n’avez pas ce que vous prétendez avoir. » Un problème est alors apparu, qui a été une des raisons principales pour lesquelles j’ai finalement arrêté ces audits : les gens ont commencé à les utiliser comme signal d’investissement, plutôt que comme outil pédagogique. J’avais partagé ces travaux pour aider d’autres à suivre le même chemin d’apprentissage que moi.
J’ai donc fait mes propres audits publics, puis collaboré avec une entreprise appelée Crypt Briefing, avec Hana, John et d’autres personnes formidables, avec qui je suis toujours en contact aujourd’hui. J’ai commencé à faire des audits pour eux, mais cela a pris une tournure qui me dérangeait : j’aimais auditer du code public. Si quelque chose était sur GitHub, que je puisse voir le code et que tout le monde puisse le vérifier, alors mes affirmations pouvaient être confirmées ou corrigées.
Mais avec l’augmentation de mon influence, de plus en plus d’équipes voulaient que j’audite leur code privé, puis publie les résultats. Cela me mettait mal à l’aise, car cela devenait purement un signal d’investissement. Quoi qu’il en soit, c’est une autre discussion que nous pourrions approfondir ailleurs. Mais à travers tout cela, j’ai vu que 99,9 % étaient de la merde, mais il restait 1 % de vrai potentiel. Ce 1 % m’a toujours hanté, attiré.
Avec recul, mon objectif a changé : passer de la compréhension de ce qui se passait à rattraper le retard du secteur. Je pense y être arrivé après environ deux ans, probablement vers 2019, peut-être fin 2018. Rattraper le rythme est difficile : chaque jour apporte du nouveau, il faut lire les 98 % de publications inutiles pour trouver les 1 à 2 % de choses réellement pertinentes.
À ce moment-là, j’ai commencé à me concentrer sur un point : le POW (preuve de travail) était clairement un goulot d’étranglement. En observant les blockchains, on voyait bien que la vitesse était limitée. Sur Bitcoin, la règle de la chaîne la plus longue imposait un délai de 10 à 30 minutes pour une transaction. Avant cela, j’étais fasciné par les paiements transfrontaliers, les règlements instantanés en ligne.
Je suis sud-africain, et l’Afrique du Sud n’est même pas membre du SWIFT ou de l’IBAN (organisations offrant des services financiers mondiaux). Nous sommes soumis à des contrôles des changes, limités dans les achats en ligne. Notre système bancaire est très restrictif, ce qui pose constamment problème. Voir une liberté non contrôlée par une entité unique m’a fortement attiré, et cela correspondait à mon background.
J’ai donc commencé à me concentrer sur la recherche en matière de consensus. Mes recherches et audits m’ont conduit vers Fantom et son équipe, avec lesquels j’ai commencé à m’impliquer davantage. Ils ont levé des fonds à un moment de grande frénésie, environ 40 millions de dollars en ETH ! À noter, ils ont gardé ces ETH, même pendant le marché baissier, et je crois qu’ils n’ont vendu qu’à environ 300 $ l’unité. Mais ils ont fait beaucoup de promesses alléchantes qu’ils ne pouvaient pas tenir. Apparemment, ils s’en sont rendu compte, mais n’ont pas choisi de se retirer activement, de dépenser ou consommer ces fonds. Finalement, ils m’ont demandé si je pouvais utiliser mes recherches publiées. Je réfléchissais justement à lancer ma propre chaîne. C’était parfait, car je n’avais aucune expérience avec les VC, ni dans la levée de fonds ou autres. Ce n’est pas mon domaine. C’est une compétence que je n’ai pas.
C’est aussi pourquoi je n’ai jamais lancé quoi que ce soit — ni Yearn, ni Keeper, ni autre — avec un investissement VC ou similaire. Beaucoup pensent que c’est une déclaration morale sur l’éthique du travail, mais non : je suis simplement mauvais dans ce domaine. J’ai trouvé des moyens de contourner cela, c’est tout.
Finalement, ils avaient les fonds, une équipe reconnue. J’ai donc intégré mes recherches à leur projet. La première chose fut le consensus : le consensus initial était ABFT (Asynchronous Byzantine Fault Tolerance), qu’ils appelaient Lachesis, mais qui reposait en réalité sur un article des années 1990, « Common Concurrent Knowledge », un simple système de communication ABFT pair-à-pair. Nous avons lancé cela fin 2019 ou début 2020. Le consensus en soi était excellent : l’un des premiers systèmes ABFT, passant de 7 TPS maximum à 30 000–50 000 transactions par seconde selon la connectivité et la participation des validateurs — sans machine virtuelle, juste des transactions pures, car c’était initialement un réseau de paiement.
Mais nous voulions intégrer une machine virtuelle, car les contrats intelligents sont puissants. Nous avons choisi l’EVM, le seul choix viable à l’époque. Nous avions envisagé WM, des compilateurs basés sur des risques, etc., mais même aujourd’hui, pour qu’une blockchain devienne viable, il faut de nombreux fournisseurs de services. Tout construire soi-même — portefeuilles, RPC, déploiement instantané — est trop difficile. Tout le monde disait : « On fait juste de l’EVM », donc nous avons décidé de garder l’EVM, en connectant notre consensus comme couche de tri, car le consensus n’est qu’un système de classement : il prend les transactions, les ordonne, puis les transmet à la VM pour mise à jour d’état.
Nous avons alors vu nos TPS chuter entre 180 et 200, uniquement à cause des limitations de l’EVM. Pendant les trois années suivantes, nous nous sommes battus pour améliorer l’EVM, avec quelques progrès. Mais je dois dire que si je pouvais revenir en arrière, je changerais ce choix.
Nous avons choisi la voie la plus facile à l’époque, celle de l’EVM, sachant que l’intégration avec les fournisseurs tiers serait plus simple. C’était un choix actif, car nous n’avions pas les moyens de construire toute l’infrastructure nécessaire. Mais c’est un sujet que nous pourrions approfondir plus tard.
3. Construire Yearn Finance
Andre Cronje : Comme mentionné précédemment, ils ont levé 40 millions de dollars et gardé tout en ETH. Lorsqu’ils ont finalement converti en dollars, il ne restait plus que 2,5 millions environ. C’était notre budget opérationnel global. Pour gérer ces fonds, j’ai étudié les protocoles de prêt existants : Compound, BZX, Full Crim, etc. Sauf Compound, tous ont disparu. À l’époque, les frais Ethereum étaient de 3 à 6 cents, donc on pouvait agir quotidiennement. Chaque matin, je regardais sur quels sites le taux annuel (APY) était le plus élevé, puis je transférais manuellement les fonds entre protocoles. Avec le temps, j’ai trouvé cela fastidieux. Il aurait fallu des contrats intelligents capables d’afficher les taux, permettant de centraliser les données.
Mon premier contrat intelligent déployé sur Ethereum était simplement un agrégateur d’APY. Il collectait les données de différents endroits et les affichait. Je l’ai fait car je ne comprenais pas encore l’infrastructure RPC, comme Web3.js, pour extraire les données depuis les nœuds. Déployer sur la chaîne, puis lire depuis là-bas, était plus simple pour moi.
C’est ainsi que j’ai commencé mon parcours en développement Solidity. Avec ce contrat, au moins, je pouvais chaque matin voir quel taux était le plus élevé et transférer. Puis j’ai pensé : « Et si je créais un contrat intelligent pour automatiser ça ? » C’est ainsi que Yearn est né. Il est devenu bien plus sophistiqué depuis — comparé à mon code initial, c’est de la science spatiale. Mais c’était là l’origine : automatiser ce que je faisais manuellement, jusqu’à ce qu’il gère lui-même mes fonds. Je l’ai ensuite ouvert à d’autres. Je n’avais plus besoin de cliquer chaque matin pour réaffecter les fonds : dès qu’un utilisateur interagissait (dépôt ou retrait), le système réaffectait automatiquement. C’est ainsi que tout a été automatisé — la naissance de Yearn.
Cependant, avec le développement de Yearn, le lancement du jeton ne s’est pas déroulé comme prévu. Ce n’était pas un lancement équitable. Je voulais ironiser sur ces jetons sans valeur. Je disais : « Donnez-moi de la liquidité, je vous donnerai gratuitement ces déchets. » Dans mon esprit, c’était l’idée la plus stupide, mais visiblement, j’avais tort. Cela a attiré beaucoup d’attention, les gens sont venus, et cela est devenu complexe — stratégies d’investissement, infrastructure, etc.
Au fil des stratégies, nous avons beaucoup « récolté ». Comme n’importe quel protocole qui vend ses jetons. C’est devenu une chose. Avant, j’exécutais ces scripts manuellement. Je me suis dit : il doit y avoir un moyen de le faire publiquement, où n’importe qui puisse appeler la fonction et ait un incitatif à le faire. C’est ainsi que sont nés les « tâches » et les « keepers ». Cela a évolué en réseau Keeper, qui a très bien fonctionné pour Yearn. Nous avons décidé de l’ouvrir : n’importe qui peut connecter une tâche, et des keepers l’exécutent. Je ne sais pas qui ils sont, mais ils font le travail. Le premier appel de tâche sur la chaîne a été fascinant : nous n’avions rien annoncé, rien publié, juste activé la tâche — et aussitôt, des robots l’ont appelée. Voir cela se produire sur la chaîne était intense. C’est probablement ce qu’on appelait autrefois la « forêt obscure », aujourd’hui plutôt la « forêt MEV ».
4. Erreurs et tests en production
Andre Cronje : Ensuite, il y a eu beaucoup… d’erreurs, faute de meilleur mot. Avant Yearn, certaines personnes suivaient mon travail, mais je n’avais ni réputation publique ni notoriété. J’avais donc développé de mauvaises habitudes. Par exemple, je testais souvent en production : je lançais des éléments expérimentaux sur des systèmes en fonctionnement. Oui, je l’ai fait. Un autre exemple : l’intention et la direction étaient totalement désynchronisées. Car mélanger test et production est extrêmement risqué. C’est comme dire : « Hé, je teste en production, si tu interagis, ce n’est pas recommandé, car les chances d’erreur sont très élevées. » C’était un avertissement : comprends que le risque est énorme.
Tester en production est devenu une sorte de pari hasardeux, bien que ce ne fût pas mon intention. J’utilisais encore mes anciennes pratiques de développement, notamment lors de la création d’Eminence. À l’époque, j’étais très frustré par la culture NFT, qui s’est améliorée depuis. Mais à ce moment-là, l’utilisation des NFT était ridicule : transformer une peinture en NFT et la vendre à 100 000 $. J’aime l’idée des NFT, car je suis un joueur passionné. Je les vois comme une application parfaite. J’ai obtenu la licence IP d’Eminence, provenant d’un autre jeu. Nous voulions créer des jeux idiots pour montrer comment les NFT fonctionnent. Je pense que l’IP des NFT posera toujours problème, car elle ne peut pas être enfermée dans un seul jeu. L’idée était de créer plusieurs jeux partageant la même couche de base.
Mais j’ai déployé des tests, les gens ont interagi, une grave faille est apparue, entraînant une perte d’environ 60 millions de dollars. J’ai fait un grand pas en arrière, réalisant à quel point ce domaine était dangereux, combien les choses pouvaient mal tourner rapidement sans mesures de sécurité. En même temps, à cause de Yearn, je subissais une pression énorme de régulateurs, qui qualifiaient le projet d’instrument financier — ce que je trouve juste, mais je voulais m’en distancier. Je suis finalement revenu, car une question me hantait : comment améliorer les courbes AMM. À l’époque, il n’y avait qu’une seule courbe standard pour les échanges stables : Curve Finance, fondée par Mitch, un développeur, fondateur et architecte absolument génial. Je pense toujours qu’il est l’un des esprits les plus brillants du secteur. Mais j’étais obsédé par l’idée de créer quelque chose d’aussi simple qu’Uniswap, avec X × Y = K. J’ai fini par concevoir X³Y + Y³X, qui fonctionnait très bien, avec une courbe simple et paramétrable.
Parallèlement, j’ai ajouté plusieurs éléments. À l’époque, il y avait TWAP (prix pondéré par le temps). J’ai ajouté RWAP (prix pondéré par les réserves). Concernant le fonctionnement des pools XY, je n’ai même pas besoin d’expliquer : pour TWAP, c’est un prix fixe sur une période donnée, ignorant complètement la quantité de liquidités. Cela signifie : « Tu peux vendre un milliard à ce prix fixe. » Ce qui me posait problème.
Note : Les algorithmes TWAP (Time Weighted Average Price) et RWAP (Reserve Weighted Average Price) utilisent des méthodes différentes pour calculer le prix d’un actif, composante fondamentale de presque tous les principes DeFi.
Car de nombreux robots de liquidation, moteurs de prêt, voire stablecoins entièrement décentralisés, doivent intégrer le slippage dans leurs calculs. Prenons un robot de liquidation : il vérifie s’il peut rembourser une dette, récupérer un collatéral (ex. 1 million d’ETH), le vendre sur Uniswap, et toujours réaliser un profit. Avec TWAP, le robot dira : « Profit OK, exécution possible. » Mais si le slippage réel est élevé, il perdra de l’argent. J’avais donc besoin d’une méthode tenant compte des liquidités, permettant une vérification réaliste, avec un poids temporel spécifique, pour savoir si de grandes liquidités n’ont pas été ajoutées via flash loan. Je peux vendre, mais cela donne aussi l’opportunité à d’autres de frontrunner mon robot.
J’ai donc dû revenir en arrière, vérifier tout cela, puis construire cette méthode. Son lancement sur Fantom a été chaotique, car je suis parti une à deux semaines après. Mais hormis cela, je pense que c’est ce que tout fondateur de protocole décentralisé devrait faire : si votre protocole est totalement immuable, sans mises à jour, vous devez partir, car vous ne pouvez pas rester la figure emblématique du projet. Je pense que Yearn et Keeper ont bien géré cela, grâce à une gestion très décentralisée. Pour ces deux protocoles, on ne peut pas vraiment identifier un leader. Sur Fantom, c’était un gros chaos, mais cela a permis à de nouveaux DEX VM comme Velodrome, Aerodrome, etc., d’émerger, dont beaucoup m’échappent encore.
Le but a été atteint, même si ce n’est pas exactement par mes itérations. Après cela, j’ai décidé que mes jours de développeur, de contrats intelligents, étaient terminés. Je n’avais pas l’infrastructure nécessaire. Je suis donc retourné à plein temps sur Fantom. Désolé, c’est une longue histoire, je vous ai fait attendre.
5. Fantom L1 : Rendre le logiciel aussi efficace que possible
Andre Cronje : Je pense que les bases de données ont un rôle à jouer. Selon moi, FVM est actuellement la meilleure machine virtuelle disponible. Du point de vue des structures de données, nous avons suivi un processus classique. Nous utilisions Badger, puis avons étudié diverses bases, avant de passer à Pebble, ce qui a amélioré notre débit, mais pas radicalement. Toutes ces bases existantes sont conçues pour des données générales, stockables de n’importe quelle manière. En outre, utiliser SQL en haut implique beaucoup de traitements en arrière-plan : création d’index, d’arbres B, etc., générant des surcoûts importants.
Même en passant à un stockage clé-valeur, on pourrait penser que c’est plus adapté aux données EVM ou contrats intelligents, ce qui augmente effectivement le débit. Mais encore une fois, derrière, il faut supporter des langages de requête comme GraphQL, SQL, etc. En passant de la base standard à Pebble, puis au stockage clé-valeur, nous avons vu un gain substantiel. Aujourd’hui, nous utilisons simplement un fichier plat sur disque, sans complexité.
Notre mode de recherche est très simple : comme tout contrat intelligent, c’est une adresse — première partie de l’index — puis l’emplacement du slot de données. C’est juste 1, 2, 3, 4… Si je cherche le nom du contrat, c’est à l’adresse 1. Je l’ai, pas besoin de langage complexe. Cela résout désormais efficacement la limitation de l’EVM, car l’EVM utilise une structure MPT très gourmande en données, avec index et autres.
Vous avez les feuilles de données, puis des composites, jusqu’au sommet. Beaucoup de travail lourd dans cette structure, majoritairement des hachages. Chaque lecture/écriture devient donc très coûteuse. Pour notre VM, en regardant seulement Carmen (stockage de données), la capacité pic a augmenté de 8,2 fois, ce qui a boosté le débit de 820 unités. Beaucoup d’autres optimisations mineures, mais cela reste un événement majeur.
Une chose que je défends : beaucoup de blockchains et d’équipes ont accepté les limitations actuelles comme des lois physiques fixes. Si vous demandez à un partisan de Bitcoin, il dira que le POW est le mécanisme de consensus le plus rapide. Pardonnez-moi de vous interrompre, je vais me taire.
Modérateur 2 : Non, cela correspond bien à la vision de Solana. Si vous regardez Kevin Bowers, le nouveau responsable du client Fire Dancer, tout son travail vise à rendre le logiciel aussi efficace que possible. Comme vous le dites, de nombreuses abstractions bizarres causent des problèmes de performance, qui s’accumulent. Ils ont même accéléré des algorithmes de hachage. Selon vous, il y a beaucoup à gagner en priorisant l’optimisation verticale, en exploitant pleinement les possibilités physiques, avant d’ajouter de la complexité. Pourriez-vous brièvement expliquer, pour ceux qui ne connaissent pas Fantom, comment il fonctionne globalement, et ce qui le distingue ? Quels sont les points clés ?
Andre Cronje : Notre priorité initiale était le consensus. À l’époque, le POW était dominant. Bien que ce soit une analogie, je n’aime pas qu’on qualifie des blockchains comme Fantom de PoS. Le PoS est un mécanisme anti-fraude, pas un mécanisme de consensus. Le POW combine les deux. Le cœur du consensus est la connaissance synchronisée partagée : tous les participants s’entendent sur un événement, et savent que les autres savent aussi.
Exemple : je porte un casque, je vous le montre. Vous savez que je le porte, je sais que je le porte. Vous dites à Garrett : « Andre porte un casque. » Andre confirme. Maintenant, Garrett sait que vous savez, et vous savez que Garrett sait. Je ne sais pas encore que Garrett sait, mais via confirmation tierce, un consensus émerge. C’est le principe de consensus de Fantom : les validateurs communiquent constamment, s’envoient des pings, vérifient qui est en ligne, partagent des transactions inconnues des autres. La communication est continue, nous l’utilisons pour partager messages et connaissance des messages.
Sur notre réseau, la propagation est virale. Lentement au début (un nœud à deux), puis exponentielle, elle se diffuse rapidement. Nous utilisons une structure DAG (graphe acyclique orienté), sans blocs comme les blockchains traditionnelles, basée uniquement sur la communication. Nous divisons le temps en « époques » (epochs). Quand 2/3 des nœuds sont d’accord, une nouvelle époque commence. Cela signifie que nous dépendons fortement du réseau P2P, que nous essayons d’optimiser pour une diffusion plus rapide.
La propagation de l’information est cruciale. Comme vous me dites un message, je le dis à d’autres, qui le disent à d’autres. Plus il y a de monde informé, plus vite le message forme une chaîne. Pour les contrats intelligents (EVM), nous introduisons les « epochs ». Quand 2/3 du réseau sait quelque chose, c’est une epoch. Cela signifie simplement qu’une majorité a atteint un accord. Cette epoch est traitée comme un bloc par l’EVM. Techniquement, nous n’avons pas de blocs, juste une communication continue et un consensus continu.
Cela dépend donc fortement de la topologie du réseau. Nous avons identifié plusieurs axes d’amélioration au niveau P2P, qui seront notre prochain focus. La communication joue un rôle clé. Même à l’échelle mondiale, la latence n’est pas un gros problème. Surtout avec un protocole de diffusion : au lieu de communiquer un-à-un, j’envoie à tous mes contacts. C’est un peu plus lent, mais dans un tel réseau, l’information circule très vite.
Passons à la couche consensus. Initialement, nous faisions juste des transferts simples, sans VM. Puis nous avons voulu ajouter une VM, d’où les epochs. Ces deux composants coopèrent : la VM gère et met à jour l’état. Malgré les optimisations, le débit reste limité. Sur le réseau de transactions pur, nous atteignons 50k à 180k TPS selon le matériel et le réseau. Notre objectif était de tester les limites, extensibles via matériel et techniques.
Nos recherches se concentrent maintenant sur la VM, notamment le consensus. Nous avons obtenu des revues par les pairs, aidés par l’Université de Sydney, en étroite collaboration avec le professeur Bernard Schultz. Une personne formidable, bien que certains puissent la trouver un peu lente — involontairement. Ils sont juste sur un autre niveau, ce qui peut frustrer, mais c’est aussi une chance d’apprendre. Pionnier des langages de programmation et des machines virtuelles, il a apporté des idées brillantes et une équipe complète.
Kman et TSA sont ses créations. Je comprends, mais je n’en suis pas propriétaire. TSA est une nouvelle machine virtuelle. Nous avons des développeurs DApp et un écosystème à considérer. Nos choix : tout recommencer (abandonner développeurs et communauté) ou trouver un compromis. Nous avons choisi la compatibilité au niveau bytecode : les anciens codes fonctionnent sur le nouveau système. Même après un fork, les contrats déployés continuent de marcher. C’est encore discuté, mais nous devrons décider pour réduire les coûts techniques. Actuellement, TSA est compatible bytecode avec l’EVM : pas besoin de recompiler Solidity, mais vous pouvez pour bénéficier d’optimisations via de nouveaux interpréteurs (Solidity, Viper). Pas encore appliqué, migration en cours.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@LXDAO_Official
