Titre original de l'article : Qu'est-ce qui attend Solana | Anatoly Yakovenko
Traduction originale : Ismay, BlockBeats
Remarque de l'éditeur : La semaine dernière, SOL a franchi les 248 $, établissant un nouveau deuxième prix historique depuis le coup de tonnerre FTX, à seulement 4 % du sommet historique du 6 novembre 2021 à 259 $. Le podcast Lightspeed a invité le co-fondateur de Solana Labs Anatoly Yakovenko et le PDG de la société RPC de Solana Helius, Mert, à plonger dans les frais de transaction de Solana, comment rester compétitif dans le domaine des cryptomonnaies, l'inflation de SOL, la concurrence avec Apple et Google, si Solana a un rempart, et d'autres sujets.
Répertoire des questions
1. Pourquoi Solana a-t-elle encore tant de transactions à l'avance ?
2. L'architecture L2 peut-elle vraiment résoudre les problèmes de congestion ?
3. Une chaîne axée sur l'optimisation à un seul fil peut-elle vraiment défier l'avantage du consensus mondial de Solana ?
4. L'espace de bloc partagé est-il une "tragédie des biens communs" ou la clé de l'efficacité du capital DeFi ?
5. Quelle est la compétitivité fondamentale de Solana ?
6. Le taux d'inflation de Solana diminuera-t-il ?
7. Le coût de développement global de FireDancer est-il trop élevé ?
8. Comment Solana rivalise-t-il avec Ethereum ?
1. Pourquoi Solana a-t-elle encore tant de transactions à l'avance ?
Mert : Donc, commençons, Anatoly, commençons à zéro. Une des raisons pour lesquelles vous avez fondé Solana est que vous en aviez marre d'être devancé sur les marchés traditionnels. Vous vouliez réaliser grâce à Solana la synchronisation des informations à l'échelle mondiale à la vitesse de la lumière, maximisant la concurrence, minimisant l'arbitrage, mais rien de tout cela n'a été réalisé jusqu'à présent, presque tout le monde est constamment devancé. Non seulement le MEV a explosé, mais le pourboire de Jito a souvent dépassé les frais de priorité de Solana. Comment voyez-vous ce problème ? Pourquoi cela se produit-il ?
Anatoly : Vous pouvez configurer votre propre nœud validateur et soumettre vos transactions sans interférence d'autres, n'est-ce pas ? Sur les marchés traditionnels, vous n'avez pas du tout ce choix, et c'est exactement là que la fonctionnalité de décentralisation de Solana entre en jeu, ce qui fonctionne effectivement.
Le défi actuel réside dans le fait que configurer un nœud validateur n'est pas facile. Il n'est pas simple d'obtenir un nœud pour miser suffisamment pour atteindre une position significative, et il est encore plus difficile de trouver d'autres nœuds prêts à ordonner les transactions de la manière que vous attendez. Cependant, tout cela est réalisable ; cela nécessite juste du temps et des efforts. Le marché actuel n'est pas encore suffisamment mature pour avoir une compétition suffisante. Par exemple, la compétition entre Jito et ses concurrents n'est pas assez forte pour permettre aux utilisateurs de choisir facilement entre "Je ne soumets qu'à Y, le créateur de flux d'ordres, pas à K."
À un niveau fondamental, en tant qu'enthousiaste, je peux lancer mon propre nœud validateur, miser un certain montant, exécuter mon algorithme et soumettre directement mes transactions. Personne ne peut m'empêcher de le faire ; tout est possible. La vraie question maintenant est de savoir si nous avons mûri à un point où les utilisateurs peuvent toujours choisir la meilleure façon de soumettre des transactions. Je crois que nous sommes loin d'atteindre ce stade.
À mon avis, la méthode pour atteindre cet objectif est en fait simple mais incroyablement difficile : augmenter la bande passante, réduire la latence, optimiser le réseau autant que possible, éliminer les goulets d'étranglement qui rendent le système injuste, y compris les mécanismes avec plusieurs proposeurs de blocs parallèles. S'il n'y a qu'un seul leader par créneau, et que vous avez 1 % de mise, vous aurez environ une opportunité tous les 100 créneaux. Mais s'il y a deux leaders par créneau, et que vous avez 1 % de mise, vous aurez environ une opportunité tous les 50 créneaux. Par conséquent, plus nous pouvons ajouter de leaders, moins de mise vous aurez besoin, vous permettant d'exécuter votre algorithme à la qualité de service que vous exigez.
Quelqu'un a créé un site Web appelé la feuille de route de Solana. En l'ouvrant, il montre "Augmenter la bande passante, réduire la latence." Anatoly demande qui a fait cela.
Mert : Actuellement, la situation est que vous devez rassembler un certain montant de mise pour prioriser le traitement de votre transaction, même si ce n'est pas le cas. Il semble que d'avoir plus de mise dans le système non seulement aide à obtenir votre propre espace de bloc, etc., mais il y a une relation dynamique ici : plus vous êtes riche, plus votre avantage est grand, est-ce acceptable ?
Anatoly : Les améliorations de performance abaissent la barrière pour que les participants honnêtes changent la dynamique du marché. Si nous avons deux leaders par seconde, le montant mis en jeu nécessaire pour fournir le même service est réduit de moitié, diminuant ainsi la barrière économique à l'entrée, permettant à plus de personnes de rivaliser. On peut dire : "Hé, je suis le meilleur validateur ; vous devriez soumettre toutes les transactions Jupiter à moi, et je ferai ce que vous voulez." De cette manière, je peux exploiter une entreprise, l'offrir aux utilisateurs, et la concurrence forcera le marché à atteindre le point d'équilibre le plus juste. C'est l'objectif ultime.
Cependant, pour atteindre cet objectif, je crois qu'une différence significative entre Solana et Ethereum est que je pense que c'est juste un problème d'ingénierie. Nous devons simplement optimiser le réseau, augmenter la bande passante, par exemple, avoir plus de leaders par seconde, augmenter la taille du bloc, tout évolue jusqu'à ce que la concurrence force le marché à atteindre un état optimal.
2. L'architecture L2 peut-elle vraiment résoudre les problèmes de congestion ?
Mert : En parlant d'un problème d'ingénierie, la raison pour laquelle le pourboire de Jito dépasse les frais de priorité n'est pas seulement à cause du MEV mais aussi à cause du processus d'atterrissage des transactions, ou plus précisément, le fonctionnement du marché local des frais ne fonctionne pas toujours de manière déterministe, parfois il est simplement instable. Quelle en est la raison ?
Anatoly : Cela est dû au fait que l'implémentation actuelle du traitement des transactions est loin d'être optimale. Dans des scénarios de très forte charge, elle fonctionne sans problème lorsque la charge est faible. Pendant le mini marché baissier des six derniers mois, j'ai vu des temps de confirmation de moins d'une seconde du début à la fin, et tout fonctionne très bien car le nombre de transactions soumises au leader est minimal. Ces files d'attente, listes d'accès rapides, et d'autres ressources ne sont pas remplies, et il n'y a pas d'arriéré de queue à cause des goulets d'étranglement de performance.
Lorsque ces files d'attente sont en retard, vous ne pouvez pas prioriser ces files d'attente avant le planificateur, ce qui perturbe en fait le marché local des frais. Donc, à mon avis, c'est aussi un problème d'ingénierie et peut-être que le domaine qui nécessite le plus d'efforts d'ingénierie dans l'écosystème actuel est l'optimisation extrême de ces pipelines de traitement.
Mert : Étant donné l'existence de ces problèmes, il semble que votre réponse soit que ces problèmes existent, mais ce sont des problèmes d'ingénierie et donc peuvent être résolus, et les itérations futures les aborderont. Certains pourraient dire que ces problèmes n'existent pas en L2 en raison de son architecture, n'est-ce pas ? Parce que vous pouvez atteindre le premier arrivé, premier servi grâce à des séquenceurs centralisés.
Anatoly : Le premier arrivé, premier servi entraînerait également les mêmes problèmes, même Arbitrum a des canaux de priorité. Donc, si vous mettez en œuvre le premier arrivé, premier servi, cela encouragerait les transactions de spam, ce qui est aussi le même problème. Si vous avez un L2 à usage général supportant plusieurs applications, il rencontrera finalement le même problème.
Certains peuvent faire valoir qu'en raison du fait que L2 n'a pas un consensus et un écosystème verticalement intégré comme Solana, ils peuvent itérer plus rapidement, comme une entreprise Web2 poussant une nouvelle version toutes les 48 heures et corrigeant rapidement les problèmes grâce à des séquenceurs centralisés. Mais ils sont toujours confrontés aux mêmes problèmes que Solana.
Vous pourriez dire que Jito a une chance de régler ces problèmes parce que leur relayer peut être mis à jour toutes les 24 heures ou publier continuellement des mises à jour. Cependant, ce qu'ils ne font actuellement pas, c'est d'avoir suffisamment de planification et de filtrage des données pour limiter le trafic provenant de ces relayers à ce que le planificateur de validateurs peut gérer, mais vous pouvez obtenir un effet similaire.
Donc, je ne pense pas que L2 puisse lui-même s'attaquer à ces problèmes. L2 n'est efficace que lorsque vous lancez, uniquement pour une application populaire, et seulement lorsque d'autres applications ne sont pas autour pour résoudre le problème. Et cela ne s'applique même pas à l'application elle-même ; si vous avez une application avec plusieurs marchés, la congestion sur le marché A affectera tous les autres marchés.
3. Une chaîne axée sur l'optimisation à un point unique peut-elle vraiment défier l'avantage du consensus mondial de Solana ?
Mert : Regardons cela sous un autre angle. Si ce n'est pas un L2 général mais une chaîne comme Atlas qui se concentre sur DeFi et exécute SVM, comment Solana rivaliserait-elle avec une telle chaîne ? Atlas n'a pas à se soucier de la surcharge de consensus ou des problèmes d'espace de bloc partagé ; elle peut se concentrer sur l'optimisation DeFi et même atteindre un marché sans frais grâce à SVM.
Anatoly : Ce que vous décrivez est en fait la compétitivité de Solana dans un scénario avec un ensemble de validateurs plus petit. Dans ce cas, il n'y a qu'un seul nœud, ce qui est plus facile à optimiser car vous pouvez utiliser du matériel plus puissant. C'est le problème central : la composabilité synchrone est-elle importante à grande échelle ? Ce réseau plus petit ne peut couvrir que la région où ce matériel est situé, donc l'information doit encore se répandre à l'échelle mondiale, et dans l'état final de Solana, il y a plusieurs validateurs capables de synchroniser globalement les soumissions de transactions de manière sans autorisation et ouverte.
Si ce problème est résolu, le résultat final est Solana. Que les données soient soumises à L2 ou non, la question clé est de savoir comment synchroniser les informations à l'échelle mondiale et atteindre un consensus rapidement. Une fois que vous commencez à aborder ce problème, ce n'est plus quelque chose qu'une seule machine à New York ou à Singapour peut résoudre ; vous avez besoin d'une forme de consensus, de cohérence et de linéarisation. Même si vous comptez plus tard sur L2 pour des garanties de règlement plus strictes, vous serez toujours confronté aux problèmes actuels de Solana. Donc, à mon avis, ces SVM à nœud unique ne sont fondamentalement pas différents de Binance.
Comment rivaliser avec Binance est une question plus intéressante. Si vous le souhaitez, vous pouvez utiliser SVM, mais les utilisateurs préféreront finalement Binance à cause de sa meilleure expérience utilisateur. Donc, nous devons devenir la meilleure version d'une bourse centralisée. Et pour atteindre cet objectif, le seul moyen est d'embrasser le concept d'une architecture décentralisée à multi-proposants.
Mert : Un autre avantage est que Solana elle-même doit s'attaquer à ces problèmes, et grâce à L2, ils peuvent les résoudre plus rapidement. Il est plus facile de résoudre des problèmes sur une seule boîte que sur 1500 boîtes. De cette manière, ils attireront plus d'attention et construiront des effets de réseau dès le départ. Peu importe comment Solana le fait, elle doit s'attaquer à ces problèmes, et parce qu'ils utilisent la même architecture, ils peuvent en tirer des leçons et éventuellement sortir plus vite.
Anatoly : Le défi de la concurrence commerciale est de savoir si ces boîtes uniques peuvent survivre sous une certaine charge. Construire une boîte unique ne résout pas immédiatement tous les problèmes ; vous êtes toujours confronté à des défis d'ingénierie presque identiques. Surtout en considérant que la discussion ne porte plus sur la surcharge de consensus de Solana mais sur le processus de soumission des transactions.
Le pipeline de soumission des transactions peut lui-même être centralisé sur Solana, tout comme sur certaines solutions L2. En fait, Solana utilise un relayer à boîte unique pour recevoir un grand nombre de transactions et tenter ensuite de les soumettre aux validateurs. Le taux de transfert de données entre le relayer et les validateurs peut être limité à un niveau inférieur, garantissant que les validateurs peuvent toujours traiter ces transactions sans problème.
De plus, ce design permet à des composants comme Jito d'itérer à un rythme plus rapide. Par conséquent, je pense que l'avantage de ce design en L2 est en réalité plus petit que ce que les gens imaginent.
4. L'espace de bloc partagé est-il une "tragédie des biens communs" ou la clé de l'efficacité du capital DeFi ?
Mert : Si nous élargissons la discussion, Solana, en tant que L1, implique un espace de bloc partagé, ce qui peut conduire au problème de la "tragédie des biens communs", similaire à la surutilisation d'une ressource de piscine publique. Cependant, sur L2, surtout ceux qui ne sont pas nécessairement un L2 de chaîne d'application, les développeurs peuvent avoir un espace de bloc indépendant sans partager avec d'autres.
Anatoly : Cette indépendance peut être plus attrayante pour les développeurs d'applications, mais cet environnement doit être autorisé. Parce qu'une fois que vous adoptez des validateurs ou des séquenceurs sans autorisation, lorsque plusieurs applications fonctionnent simultanément, vous perdrez ce contrôle.
Même dans un environnement d'application unique comme Uniswap, si la plateforme a plusieurs marchés, ces marchés peuvent interférer les uns avec les autres. Par exemple, un jeton mème inconnu peut affecter la priorité des ordres des marchés principaux. En le regardant d'un point de vue produit et en envisageant un avenir où tous les actifs sont tokenisés, en tant que PDG d'une entreprise récemment cotée en bourse, je décide sur quelle plateforme faire mon introduction en bourse. Si je vois un volume de trading élevé de SHIB sur Uniswap causant une congestion sévère, au point où les actifs principaux ne peuvent pas se trader correctement, cela serait sans aucun doute un état échoué pour ce L2 axé sur les applications.
Par conséquent, les défis auxquels ces L2 axées sur les applications sont confrontés sont similaires à ceux de Solana, car elles doivent toutes isoler leurs états respectifs de manière à ne pas impacter d'autres applications. Parce qu'une seule application comme Uniswap, si l'un de ses marchés connaît une congestion qui affecte tous les autres marchés, dans un environnement comme celui-ci, ce qui est inacceptable pour un PDG d'une entreprise comme la mienne. Je ne veux pas que mon marché principal soit du genre où tout le monde échange. Je veux que chaque paire de trading fonctionne indépendamment.
Mert : Si c'est autorisé, cependant ? Puisqu'il y a un mécanisme de sortie, cela ne fonctionnerait-il pas ?
Anatoly : Même dans un environnement autorisé, vous devez toujours traiter le problème de l'isolement local. Traiter ce problème d'isolement dans un environnement autorisé n'est pas fondamentalement différent de le traiter dans un expéditeur ou un planificateur.
Mert : Pensez-vous que cette analogie de marché peut s'appliquer à tout type d'application ?
Anatoly : Certaines applications n'ont pas ces caractéristiques, comme les paiements peer-to-peer simples avec très peu de congestion et une planification simple. Donc, le défi de concevoir des mécanismes d'isolement et toutes ces choses apparemment complexes réside dans le fait que si vous ne pouvez pas garantir qu'un seul marché ou une seule application ne provoquera pas de congestion mondiale, alors des entreprises comme Visa introduiront leur L2 de paiement dédiée car leurs transactions ne rivalisent jamais. Ils ne se soucient pas de la priorité ; ils ne se soucient que du TPS. Peu importe si mon passage de carte est la première ou la dernière transaction dans le bloc ; ce qui compte, c'est que je puisse partir dans les deux secondes et demie après avoir glissé ma carte. Donc, dans un scénario de paiement, le mécanisme de priorité n'est pas crucial, mais c'est en effet un scénario d'application dans le monde réel très important.
Mon avis est que si nous ne pouvons pas mettre en œuvre correctement les mécanismes d'isolement, alors l'idée d'une machine d'état composable à grande échelle devient sans signification, car vous verrez l'émergence de chaînes de paiement et de L2 dédiées à des marchés uniques. Imaginez que je sois le PDG d'une entreprise cotée en bourse, pourquoi choisirais-je de lancer sur la chaîne d'Uniswap dans les 20 prochaines années ? Pourquoi ne pas lancer ma propre L2 qui ne prend en charge que mes paires de trading pour garantir de bonnes performances ?
C'est un avenir possible, mais je pense que d'un point de vue d'ingénierie, il n'y a pas de raison de le faire à moins qu'il n'y ait d'autres raisons. Si nous pouvons résoudre les problèmes d'ingénierie, alors je crois qu'atteindre la composabilité dans un environnement unique a un énorme avantage, car la friction du transfert de capital entre tous les états et la liquidité peut être considérablement réduite, ce qui est une fonctionnalité très importante pour moi. Je crois que le DeFi de Solana peut survivre dans un marché baissier et résister à un coup plus important que quiconque précisément à cause de sa composabilité, ce qui rend son efficacité en capital plus élevée.
Mert : Vitalik a récemment déclaré que "à mon avis, la composabilité est surestimée." Je pense qu'il est probablement arrivé à cette conclusion sur la base de données empiriques, croyant qu'il n'y a pas trop d'instances on-chain qui l'utilisent. Quelles sont vos pensées ?
Anatoly : Jupiter n'est-il pas l'incarnation de la composabilité ? Je pense qu'il se concentre uniquement sur Ethereum, malheureusement, Jupiter a une énorme part de marché sur Solana et une part de marché significative dans tout l'espace crypto. Pour atteindre la composabilité, Jupiter est indispensable. Sans composabilité, Jupiter ne peut pas fonctionner. Regardez 1inch, c'est un concurrent sur Ethereum, incapable d'évoluer car même le transfert entre L2 et le même L1 est extrêmement coûteux et lent.
Je pense qu'il a tort. Je crois que les systèmes financiers peuvent être asynchrones, c'est ainsi que la plupart des systèmes financiers fonctionnent aujourd'hui. Ce n'est pas pour dire que ces systèmes échoueraient ou s'effondreraient à cause de cela. Mais si Solana réussit et que l'écosystème aborde tous ces problèmes au rythme actuel, même si nous maintenons le niveau d'exécution actuel chaque année, vous verrez des améliorations significatives. En fin de compte, je pense que la composabilité émergera comme la gagnante.
5. Quel est l'avantage concurrentiel fondamental de Solana ?
Mert : Mettons de côté les problèmes d'ingénierie un moment, en supposant que l'ingénierie n'est pas un rempart, et que d'autres chaînes peuvent obtenir les mêmes résultats. Par exemple, une chaîne comme Sui pourrait également atteindre la composabilité et avoir un ensemble de validateurs plus petit. En supposant que certaines L2 seraient confrontées à des problèmes similaires à ceux que vous avez mentionnés, mais elles pourraient également aborder ces problèmes. Je vous ai demandé auparavant, lorsque l'ingénierie n'est plus le rempart, quel est le rempart ? Vous avez dit que c'est le contenu et la fonctionnalité.
Anatoly : Oui, Solana n'a pas fixé un objectif spécifique de validateurs. Le testnet a environ 3500 validateurs, et le mainnet a une grande échelle car je voulais qu'il soit aussi grand que possible pour préparer l'avenir du réseau. Si vous voulez autant de producteurs de blocs dans le monde que possible, vous avez besoin d'un grand ensemble de validateurs, permettant à quiconque de rejoindre et de participer à chaque partie du réseau sans autorisation.
Vous devriez tester aussi vite que possible car actuellement le coût de résolution de ces problèmes est bas. Solana ne gère pas des trillions de dollars de fonds d'utilisateurs maintenant ; c'est ce que fait Wall Street. Solana traite des cryptomonnaies, ce qui nous donne une opportunité d'avoir les personnes les plus intelligentes du monde pour résoudre ces énigmes et les forcer à faire face à ces défis.
Donc, mon point est que plutôt que Solana diminue la taille de l'ensemble de validateurs pour des performances, Sui et Aptos ont plus de chances d'avoir besoin d'augmenter leur ensemble de validateurs. Si vous trouvez PMF, tout le monde voudrait faire fonctionner son propre nœud car cela offre une assurance. À mesure que l'ensemble des validateurs grandit, si vous commencez à limiter les participants, vous limitez la scalabilité du réseau.
Mert : D'accord, vous avez mentionné un problème que je veux discuter. Bien que ce soit l'objectif, si vous regardez les données, le nombre de nœuds validateurs diminue avec le temps. Il semble que vous pensiez que cela est dû à un manque d'adéquation produit-marché, donc ils n'ont pas la motivation de faire fonctionner eux-mêmes l'équipement de nœud, n'est-ce pas ? Ou quelle est la raison ?
Anatoly: Oui, une partie de la raison est le soutien à la mise en jeu de la Fondation Solana. Mais je suis en effet intéressé de savoir combien de nœuds validateurs sont autosuffisants, ce nombre est-il en augmentation ?
Mert : Attendez, nous avons environ 420 nœuds validateurs qui sont autosuffisants.
Anatoly : Mais à quoi cela ressemblait-il il y a deux ans ?
Mert : Nous n'avons peut-être pas ces données. Mais nous savons que le montant total mis en jeu de la Fondation Solana a diminué de manière significative depuis deux ans,
Anatoly : Bien que les frais augmentent également. Donc, je suppose que le nombre de nœuds qui pouvaient s'auto-soutenir il y a deux ans était beaucoup plus bas, même si le nombre total de nœuds était plus élevé à cette époque. Donc, mon point est que nous avons besoin que le réseau se développe pour soutenir tous ceux qui souhaitent faire fonctionner l'équipement de nœud. C'est aussi l'un des principaux objectifs du plan de délégation, d'attirer plus de personnes à faire fonctionner des nœuds et de leur mettre un certain stress dans le testnet.
Mais le testnet ne peut jamais simuler pleinement les caractéristiques du mainnet, n'est-ce pas ? Peu importe combien de tests de validateurs ils effectuent dans le testnet, la situation sur le mainnet sera toujours assez différente. Donc, tant que le nombre de nœuds autosuffisants est en croissance, je le considère comme une tendance positive. Le réseau doit physiquement être capable de se développer pour soutenir une telle échelle, sinon cela limitera la croissance.
Mert : Donc, fondamentalement, vous voulez dire que le mécanisme de délégation aide le réseau à tester le stress de différentes échelles de nœuds validateurs, mais fondamentalement, la seule chose importante, ou la plus importante, est le nombre de nœuds validateurs autosuffisants.
Anatoly : Exactement, cela peut théoriquement proposer certains arguments, comme l'affirmation que dans un cas extrême, un seul nœud peut ne pas être autosuffisant. Mais même en cas d'échec catastrophique, si c'est le seul nœud survivant, il fournit une assistance. Cependant, cela tombe sous le domaine du problème de "décentralisation en guerre nucléaire" de fin de partie.
Fondamentalement, ce qui compte vraiment, c'est si le réseau est en croissance et réussit, ce qui repose sur des validateurs autosuffisants qui peuvent payer leurs propres factures et ont suffisamment d'intérêt pour le réseau pour être prêts à investir des ressources commerciales pour s'améliorer continuellement, plonger profondément dans les données et faire correctement leur travail.
Mert : Dans un monde où n'importe qui peut faire fonctionner un système rapide, peu coûteux et sans autorisation, pourquoi les gens choisiraient-ils encore Solana à l'état final ?
Anatoly : Je pense que le futur gagnant pourrait être Solana car cet écosystème a démontré une exécution exceptionnelle et a déjà pris de l'avance dans la résolution de tous ces problèmes. Ou, le gagnant pourrait être un projet entièrement identique à Solana, mais pas Solana simplement parce qu'il a exécuté plus vite, suffisamment pour surpasser les effets de réseau existants de Solana.
Donc je pense que l'exécution est le seul rempart. Si elle est mal exécutée, vous serez dépassé. Mais le dépasseur doit performer exceptionnellement bien pour devenir un produit killer. PMF fait référence à l'adéquation produit-marché, ce qui signifie qu'il en résulte un changement de comportement chez les utilisateurs.
Par exemple, si les frais de transaction sont dix fois moins chers, les utilisateurs passeront-ils de Solana à un autre projet ? Si les utilisateurs n'ont à payer qu'un demi-cent, cela peut ne pas suffire. Mais si passer ailleurs peut réduire considérablement le glissement, cela pourrait être suffisant pour les attirer ou pour que les traders passent.
En effet, il est nécessaire d'observer le comportement général des utilisateurs pour voir s'il y a une amélioration fondamentale suffisamment significative pour les inciter à choisir un autre produit. Il y a effectivement une telle différence entre Solana et Ethereum. Pour les utilisateurs, lorsqu'ils signent une transaction, et qu'il est montré qu'ils doivent payer 30 $ pour recevoir un jeton ERC-20, même juste pour effectuer un changement d'état très basique, ce prix est outrageusement élevé, dépassant les attentes des utilisateurs, les amenant à opter pour une alternative plus rentable.
Un autre facteur est le temps ; vous ne pouvez pas attendre deux minutes pour une confirmation de transaction ; c'est trop long. Le temps moyen de confirmation actuel de Solana est d'environ deux secondes, atteignant parfois un pic à 8 secondes, mais il progresse vers 400 millisecondes, un changement de comportement significatif pour les utilisateurs, suffisant pour les inciter à passer à un nouveau produit.
Mais cela reste encore inconnu. Cependant, dans la technologie de Solana, il n'y a pas de barrières empêchant le réseau de continuer à s'optimiser pour améliorer la latence et le débit. Donc, lorsque les gens demandent pourquoi la croissance de Solana est plus rapide que celle d'Ethereum, certains peuvent penser que le prochain projet le dépassera. Mais en réalité, la différence marginale entre Solana et le prochain concurrent est très petite, rendant plus difficile de créer une différence suffisamment significative pour influencer le comportement des utilisateurs, ce qui est un défi important.
Mert : Si la vitesse d'exécution est un facteur clé, alors fondamentalement, cela devient en quelque sorte un problème organisationnel ou de coordination. La différence entre la vision de Solana et ce qui peut être appelé modularité (bien que ce ne soit pas un terme formel) est que si, par exemple, vous êtes un développeur d'application comme Drip, et que votre application est construite sur Solana, vous devez attendre que L1 fasse quelques changements, comme résoudre la congestion ou corriger des bugs.
Cependant, si c'est en L2 ou sur une chaîne d'application, vous pouvez traiter ces problèmes directement vous-même. Peut-être que sous cet angle : sur cette autre chaîne, vous pourrez exécuter des opérations plus rapidement que de vous fier à un espace partagé. Donc, si c'est vrai, la vitesse d'exécution globale sera plus rapide.
Anatoly : Au fil du temps, cette différence se rétrécira progressivement. Par exemple, Ethereum était très lent. Si vous exécutez Drip sur Ethereum et que les frais de transaction explosent à 50 $, vous iriez demander à Vitalik (le fondateur d'Ethereum) quand ce problème pourrait être résolu. Il pourrait répondre : "Nous avons une feuille de route de six ans, mon frère, cela prendra du temps." Alors que si vous allez demander à des équipes comme Fire Dancer ou Agave, elles diraient : "Il y a déjà une équipe qui travaille dur pour résoudre ce problème et vise à le résoudre le plus rapidement possible dans la prochaine version."
C'est une différence culturelle. L'équipe L1 principale, y compris toute l'équipe d'infrastructure comme vous, tout au long du processus de soumission des transactions, tout le monde comprend que lorsque le réseau ralentit ou qu'il y a une congestion mondiale, c'est un problème le plus critique (p0) que tout le monde doit aborder immédiatement. Bien sûr, parfois, des problèmes inattendus peuvent survenir, comme des ajustements dans la conception du marché des frais.
Ces problèmes deviennent de moins en moins courants à mesure que l'utilisation du réseau augmente. Je ne pense pas qu'il y ait actuellement des défis qui nécessitent des changements de conception urgents et prennent six mois à un an à déployer. Je ne vois pas de tels défis sur la route devant nous en ce moment.
Cependant, vous savez qu'il y aura certainement quelques bugs ou d'autres problèmes inattendus au moment de la sortie, nécessitant que les gens travaillent dur pendant les week-ends, ce qui fait également partie du travail. Si vous avez votre propre chaîne d'application L2 dédiée, vous n'avez pas besoin de partager des ressources et vous avez un contrôle total de cette couche d'infrastructure, alors vous pouvez peut-être avancer plus vite, mais à un coût plus élevé, que tout le monde ne peut pas se permettre.
Par conséquent, une couche d'infrastructure partagée et composable peut être moins chère et plus rapide pour la grande majorité des cas d'utilisation, en tant que couche d'infrastructure de logiciel en tant que service qui peut être partagée et utilisée par tous. Avec des corrections de bugs et des améliorations continues, cet écart deviendra de plus en plus petit.
6. Le taux d'inflation de Solana diminuera-t-il ?
Mert : Un autre point de critique lié est le mécanisme d'inflation de Sol, car beaucoup de gens pensent que cela se fait en augmentant les récompenses pour aider davantage de validateurs. Cependant, le coût de faire cela peut se faire au détriment de ces investisseurs purs. Lorsque les gens disent que le taux d'inflation de Solana est trop élevé, quelle est votre première réaction ? Comment voyez-vous cela ?
Anatoly : C'est un débat sans fin, changer les chiffres dans la boîte noire ne change vraiment rien. Vous pouvez faire quelques ajustements pour qu'ils affectent certaines personnes, afin que la boîte noire ne puisse pas fonctionner normalement, mais cela ne crée ni ne détruit de valeur, c'est juste une opération de comptabilité.
La raison pour laquelle le mécanisme d'inflation est ce qu'il est maintenant est qu'il a directement copié le mécanisme de Cosmos, car beaucoup des validateurs initiaux étaient des validateurs Cosmos. Cependant, l'inflation affecte-t-elle le réseau dans son ensemble ? Cela peut avoir un impact sur les individus sous un régime fiscal spécifique, mais pour l'ensemble du réseau, c'est un coût pour les non-miseurs et un gain équivalent pour les miseurs, ce qui somme mathématiquement à zéro. Donc, d'un point de vue comptable, l'inflation n'affecte pas le réseau dans son ensemble comme une boîte noire.
Mert : J'ai vu des gens dire que comme c'est arbitraire, pourquoi ne pas simplement le baisser ?
Anatoly : Allez-y, proposez un changement, cela ne me dérange pas personnellement ; je l'ai dit maintes fois, changez-le en n'importe quelle valeur que vous voulez et persuadez les validateurs de l'accepter. Lorsque ces chiffres ont été initialement fixés, la principale considération était de ne pas provoquer une catastrophe totale, et puisque Cosmos n'a pas eu de problème à cause de ce paramètre, c'était suffisamment raisonnable.
7. Le coût global de développement de FireDancer est-il trop élevé ?
Mert : Donc revenons au défi de coordination. Nous avons récemment promu FireDancer, et Jerry a récemment mentionné que certaines personnes commencent à sentir que FireDancer est un peu exagéré. Cependant, Jerry a également mentionné que FireDancer a en effet ralenti un peu les gens car les ingénieurs Anza et Fire doivent clairement s'aligner sur certaines choses avant de pouvoir avancer, donc il y a effectivement un certain retard au début. Votre perspective semble être qu'une fois que les spécifications et les interfaces sont clarifiées, la vitesse d'itération augmentera, n'est-ce pas ?
Anatoly : Oui, cela peut essentiellement être décomposé en trois étapes : la première étape est la phase de conception, où vous devez établir un consensus sur ce qui doit être fait ; ensuite, il y a la phase d'implémentation, où les deux équipes peuvent travailler en parallèle ; et enfin, il y a la phase de test et de validation pour s'assurer qu'il n'y a pas de problèmes de sécurité ou de vivacité. Je pense que la phase de conception peut prendre plus de temps, mais l'implémentation est parallèle, donc les deux équipes peuvent progresser simultanément, et la phase de test et d'audit sera plus rapide car la probabilité que les deux équipes indépendantes introduisent le même bug est plus faible.
Je pense que la plus grande différence est qu'Ethereum fonctionne généralement comme ceci : nous allons publier une version majeure qui inclut toutes les fonctionnalités ciblées pour cette publication, en nous concentrant sur un ensemble de fonctionnalités plutôt que sur une date de publication. Alors que Solana fonctionne presque exactement à l'opposé, en fixant une date de publication, et si votre fonctionnalité n'est pas prête, elle est supprimée, ce qui entraîne un rythme de publication beaucoup plus rapide.
En théorie, s'il y a deux équipes qui souhaitent accélérer la vitesse d'itération, le cycle d'itération pourrait être encore plus accéléré. Mais cela nécessite que les ingénieurs principaux aient ce sens de l'urgence, se sentant que "nous devons sortir ces contenus dès que raisonnablement possible." Dans ce cas, vous pouvez compter sur une certaine redondance dans l'implémentation. Je crois que d'un point de vue culturel, les deux équipes ont des antécédents similaires car elles ne sont pas des équipes académiques mais ont grandi dans un environnement de pression technologique.
Mert : Cela m'amène au troisième point que je voulais faire : FireDancer. Vous devez supposer que vous n'avez aucune capacité d'exécution parce que vous travaillez pour un téléphone, pas pour aider au développement de L1 ou pour coordonner ces équipes clientes. Est-ce vraiment le meilleur choix pour un individu ?
Anatoly : Le dernier changement majeur auquel j'ai participé avec FireDancer a été de déplacer l'index de la base de données des comptes hors de la mémoire. À ce moment-là, je pourrais rédiger une proposition de conception et une petite mise en œuvre pour prouver sa faisabilité. Cependant, le problème est que pour compléter ce travail, cela nécessite un ingénieur à temps plein dédié à cette tâche. Je pourrais confier cette tâche à Jash, qui est responsable de l'accomplir, mais y compris le cycle de test et de publication, l'ensemble du processus prendrait un an.
Pour moi, ce serait formidable si je pouvais rejoindre Anzar Fire Dancer en tant que simple contributeur individuel (IC), uniquement responsable de me concentrer sur Grafana (un outil de surveillance des performances) et de développer certaines choses. Cependant, la réalité est que mon énergie est dispersée entre d'innombrables projets. Donc, je trouve que l'endroit où je peux avoir le plus grand impact est là où je peux définir l'état du problème, comme les problèmes de croissance, les problèmes de leadership de concurrence, les problèmes de révision, les problèmes de concurrence MEV, etc. Je peux proposer des solutions, discuter avec tout le monde, et finalement amener tout le monde à s'accorder à dire que mon analyse des problèmes est correcte et à mettre en avant leurs solutions possibles. Nous itérons ensemble sur le design, nous le façonnons finalement et le solidifions.
Ensuite, lorsque le sens de l'urgence que j'anticipais s'intensifie progressivement, les gens ont déjà la solution de conception. La partie la plus difficile - l'alignement entre les deux équipes - a été complétée, et il ne reste plus qu'à implémenter et tester. Donc, mon rôle est presque celui d'un ingénieur principal dans une grande entreprise. Je n'écris pas de code ; à la place, je communique avec plusieurs équipes, disant : "J'ai remarqué que vous rencontrez des difficultés dans un certain domaine, et d'autres équipes aussi. Vous devez résoudre le problème de cette manière pour que nous puissions nous aligner sur cet aspect." C'est probablement l'opportunité où je peux avoir le plus grand impact dans le domaine central.
Mert : C'est effectivement la responsabilité de ce rôle, mais ce n'est pas facile. Donc, dites-vous : "Jack Dorsey peut le faire, Elon Musk peut le faire, donc je peux aussi développer un téléphone tout en effectuant ces tâches" ?
Anatoly : Ce n'est pas comme ça, en fait. Il y a un ingénieur exceptionnel qui est responsable du côté mobile, c'est un ami proche depuis plus de dix ans, il a été impliqué dans la construction de BlackBerry, iPhone, et presque tous les téléphones auxquels vous pouvez penser. Et il y a un très bon directeur général. Ces deux-là gèrent toute l'équipe ensemble, et je suis responsable de définir la vision.
Je ne pense pas que les gens comprennent pleinement cette vision, mais si vous regardez Android ou iOS, ils sont en fait une spécification de firmware signée cryptographiquement qui définit toute la plateforme. Tout le monde a un tel appareil et garantit sa sécurité par un démarrage de confiance lorsque vous recevez une mise à jour de firmware, il vérifie la correction de la signature du firmware et réécrit l'ensemble du système du téléphone.
Et la partie la plus critique de cela est cette signature cryptographique, car elle pourrait entièrement être générée par un DAO, qui signe l'ensemble du firmware et est responsable de sa libération. Imaginez si le propre certificat de signature cryptographique d'Apple était contrôlé par un DAO, le concept entier de la plateforme logicielle serait perturbé. C'est cet état d'esprit "hacker" extrêmement cool et quelque peu excentrique.
De plus, mon travail principal est de définir une telle vision, de pousser l'équipe à vendre plus de téléphones, de le transformer en un produit vraiment significatif, et finalement d'atteindre le jalon où tout l'écosystème peut contrôler son propre firmware. Je ne m'implique pas dans le travail d'exécution quotidien.
Concernant Elon Musk, je pense que sa façon de travailler pourrait être ainsi : il a une grande idée, puis trouve un ingénieur qui peut lui dire de manière convaincante : "Je peux implémenter l'ensemble du projet de A à Z." Si vous pouvez trouver une telle personne, alors la seule chose que vous devez faire est de fournir des financements pour accélérer ce processus. Après avoir donné cet argent à cette personne, elle terminera l'ensemble du projet par elle-même et puis embauchera des gens pour accélérer ses progrès.
J'essaie d'opérer de cette manière, je ne suis pas sûr que ce soit la même que celle d'Elon, mais je crois que c'est une méthode qui peut gérer plusieurs projets en même temps : avoir une grande vision, un objectif très spécifique, puis trouver quelqu'un de vraiment capable de l'atteindre. Si le temps est illimité, je peux construire chaque partie. Et après leur avoir donné des financements, ils vont accélérer pour réaliser tout cela.
Mert : Vous avez mentionné que la vision est claire, mais le résultat idéal semble être le suivant : supposons que vous réussissiez, vendant un grand nombre de ces téléphones, ayant même un impact révolutionnaire sur Crypto Twitter et Apple. Alors Apple pourrait réduire ses frais. En d'autres termes, ce que vous faites change le monde.
Anatoly : En effet, cela a apporté un changement. Les entreprises de logiciels du Midwest n'ont plus à payer une rançon similaire aux 30 % d'Apple, et des logiciels et jeux plus efficaces peuvent être développés. C'est en effet bon.
Mert : Mais cela semble plus être un effort altruiste qu'un mouvement commercial, n'est-ce pas ?
Anatoly : Ce n'est que lorsque cet acte altruiste peut également réussir en tant que mouvement commercial qu'il peut être véritablement réalisé. Si Apple doit réduire ses frais, ils doivent ressentir la pression concurrentielle d'un écosystème en croissance et commercialement viable. Sinon, ils ne feront que stagner jusqu'à ce que cet écosystème meure en raison d'un manque de viabilité commerciale. Par conséquent, cet écosystème doit trouver l'adéquation produit-marché et avoir la capacité de s'autosuffire.
Mais cela ne signifie pas que cela ne changera pas le monde. Si cela peut réduire la part de revenus d'Apple, c'est l'essence du capitalisme : lorsque vous voyez un groupe extraire des rentes à 30 %, et que vous fournissez le même service à 15 %, vous changez l'économie de marché, bénéficiant à tout le monde, y compris les consommateurs.
Mert : Donc, vous voulez dire que vous devez croire que vous pouvez en quelque sorte battre l'une des plus grandes entreprises du monde, Apple et Google. Donc, pourquoi pensez-vous que vous pouvez rivaliser avec eux ?
Anatoly : Clairement, une part de revenus de 30 % est en effet trop élevée, car quelqu'un comme Tim Sweeney les poursuit partout, cela est devenu un point de douleur pour les entreprises utilisant les canaux de distribution d'Apple et de Google. Apple et Google extraient des rentes de cette manière, et les consommateurs ne se soucient pas de ces coûts car ils sont cachés. Les consommateurs paient un montant fixe à l'application, et Apple en prend 30 %.
Résoudre ce problème est un défi dans la construction du réseau, et je pense que le domaine crypto a un avantage à cet égard. La crypto peut financer des actifs numériques et la rareté d'une manière différente de celle du Web 2. Mais même ainsi, cela peut encore échouer. La raison de l'échec n'est pas que les développeurs d'applications ne veulent pas de frais plus bas, ce qui est évidemment vrai. La raison de l'échec est que nous n'avons pas encore trouvé un moyen de tirer parti des incitations fournies par la technologie crypto pour faire évoluer le réseau.
C'est un problème vraiment délicat. Ce n'est pas un problème de produit, pas un problème de modèle économique, mais une question de comment nous pouvons forcer les utilisateurs à changer leur comportement et à passer à d'autres réseaux.
8. Sur quoi Solana s'appuie-t-il pour rivaliser avec Ethereum ?
Mert : Changement de sujet, j'aimerais parler des problèmes liés aux ZK. Une vision ultime pour la blockchain semble être que tout est piloté par ZK, où vous n'avez pas besoin d'exécuter toutes les opérations sur un nœud complet ; vous avez juste besoin de vérifier les preuves. Cependant, Solana ne semble pas avoir de plan similaire.
Anatoly : Si vous avez lu mon article sur APE (Asynchronous Processing Execution), vous constaterez qu'il a un impact significatif sur le fonctionnement des validateurs. En partageant un prouveur commun, les validateurs peuvent vérifier l'état. Donc, vous pouvez avoir plusieurs validateurs partageant un environnement de confiance (par exemple, TE) ou un certain modèle de confiance, ou même en utilisant une solution ZK. Lorsque l'APE complète l'ensemble de l'exécution asynchrone et calcule un hash instantané complet, vous pouvez en fait réaliser cette idée : un Rollup entièrement basé sur la vérification ZK. Cela ne signifie pas que vous avez besoin d'un Rollup ou qu'un Rollup est d'une certaine manière incompatible avec Solana.
Cette vue est absurde - L'exécution asynchrone vous permet de calculer un hash instantané basé sur votre propre modèle de confiance, peu importe l'environnement que vous utilisez, comme exécuter votre propre nœud complet, partager un environnement TE, ou d'autres environnements. Cela n'affecte pas mon nœud complet. Si j'exécute mon propre nœud complet, vous pouvez utiliser n'importe quel environnement pour faire ce que vous voulez.
La question centrale est : qu'est-ce qui distingue Solana d'Ethereum et de ZK ? Pour que le réseau survive, il doit avoir une viabilité commerciale, ce qui signifie qu'il doit être rentable. À mon avis, le seul modèle commercial pour L1 est les frais de priorité, qui est essentiellement la même chose que le MEV. D'autre part, les Rollups créent leur propre MEV, effectuent une séquençage indépendant et rivalisent avec L1, créant un environnement de concurrence parasitaire pour L1.
Toute cette concurrence est bien, mais elle n'appartient pas à l'écosystème Solana. Ces Rollups sont basés sur EVM, tirant parti de la puissance de l'open source pour accélérer le développement mondial, tandis que l'écosystème de Solana est basé sur le SVM.
À mon avis, c'est la différence fondamentale dans la façon dont ZK est appliqué entre Solana et Ethereum. Le protocole léger est génial car sur le mainnet de Solana, la séquençage est effectuée par les validateurs de Solana.
Mert : Donnons un exemple très théorique, complètement à l'opposé, en supposant que la bande passante a été maximisée, la latence a été minimisée, et que la loi de Moore a été pleinement exploitée. Même dans une situation où le canal est saturé et où un peu plus de matériel est nécessaire pour résoudre le problème. Si nous avons vraiment réalisé tout cela mais que ce n'est toujours pas suffisant, que se passe-t-il alors ? Supposons que la technologie de cryptage soit effectivement devenue plus répandue (bien que je ne pense pas personnellement que cela se produise nécessairement), que se passerait-il alors ?
Anatoly : Eh bien, vous ne pouvez pas simplement démarrer un autre réseau car les nœuds complets de Solana ont déjà saturé la bande passante des FAI, et chaque FAI n'a plus de capacité ; nous avons consommé toute la bande passante disponible.
Mert : Je suppose qu'avant d'atteindre la saturation totale, tous les défis d'ingénierie doivent être abordés.
Anatoly : Il faut réaliser qu'actuellement presque partout dans le monde peut accéder à des vitesses réseau de 1 Gbps, et presque chaque appareil mobile a cette capacité, ce qui équivaut à traiter 250 000 transactions par seconde (TPS). Même sur la base des spécifications d'efficacité actuelles du protocole Turbine, cette configuration prendrait en charge 250 000 TPS. C'est un nombre astronomique, c'est une quantité ridicule de capacité. Saturons cela d'abord avant de discuter d'autres problèmes, comme les limites de la loi de Moore.
Mais en ce moment, Solana est encore à 250x de ce point en termes d'amélioration de charge. Nous avons besoin d'une amélioration de 250x avant de pouvoir commencer à envisager d'autres problèmes. Et ce soi-disant 1 Gbps est une norme technologique avec une histoire de 25 ans et est une technologie très mature.
Nous n'avons même pas encore approché de saturer cette capacité technologique. Je crois que lorsque nous atteindrons la saturation totale de la bande passante de 1 Gbps, lorsque Turbine sera entièrement saturé, ce sera le scénario que l'équipe FireDancer a déjà démontré dans un environnement de laboratoire. Bien sûr, cet environnement est encore distribué, mais fondamentalement, c'est un environnement de laboratoire, bien que cela soit effectivement réalisable.
Cependant, pour rendre cette technologie commercialement viable, il reste de nombreux problèmes à résoudre, et les applications doivent être capables d'utiliser efficacement cette capacité. Parce qu'actuellement, la plupart de la charge sur Solana provient de l'activité de marché, à commencer par atteindre la saturation, puis l'arbitrage remplit l'espace de bloc restant. Mais cela n'a pas encore atteint ce que j'appelle "saturation économique."
Mert : Dans un environnement où Ethereum a des actifs de meilleure qualité et un volume de transactions plus élevé en raison des effets de liquidité existants, comment Solana rivalise-t-elle ? En supposant que ces actifs, même les stablecoins, n'ont pas atteint le niveau d'Ethereum, que doit-il changer ?
Anatoly : Nous pouvons commencer à appeler les actifs d'Ethereum "Actifs Hérités", puis lancer toutes les nouvelles choses sur Solana, ce mème doit changer, (la nouvelle version est) Ethereum est la plateforme pour "actifs hérités", tandis que Solana est le berceau de nouvelles choses.
"Lien de l'article original"