1. Est-ce que le consensus peut réparer les blockchains ?

Les mécanismes de consensus garantissent que chaque ordinateur du réseau est d'accord sur les transactions qui sont validées de manière cohérente et sécurisée et ajoutées à la chaîne de blocs, en se basant sur un ensemble de règles de consensus.

Chaque blockchain tente d'atteindre un équilibre par rapport au trilemme de la blockchain : équilibrer la vitesse, la sécurité et la décentralisation. Les projets ne peuvent souvent privilégier que deux caractéristiques au détriment d'un troisième.

Les mécanismes de consensus sont essentiels pour empêcher les acteurs malveillants de réussir à falsifier le réseau ou ses données. Ils empêchent le double dépense et maintiennent tout en synchronisation, en veillant à ce que chaque nœud dans la blockchain produise la même séquence de transactions pour chaque bloc.

Pensez à eux comme aux règles d'un jeu décentralisé, guidant les participants vers une "vérité" unifiée. Voici un résumé des mécanismes de consensus clés :

Preuve de travail (PoW) : Les mineurs résolvent des énigmes complexes avec une puissance de calcul pour ajouter des blocs et sont récompensés par des cryptomonnaies. C'est sécurisé mais énergivore et lent (par exemple, Bitcoin, Ethereum avant 2022).

Preuve d'enjeu (PoS) : Les validateurs misent des cryptomonnaies pour avoir la chance de créer des blocs. Cette méthode est éco-énergétique et plus rapide, mais elle peut favoriser les participants plus fortunés (par exemple, Ethereum post-2022, Cardano).

Preuve d'enjeu déléguée (DPoS) : Les détenteurs de jetons votent pour des délégués afin de valider les transactions, offrant rapidité et évolutivité mais risquant la centralisation (par exemple, EOS, Tron).

Preuve d'autorité (PoA) : Les nœuds de confiance valident en fonction de l'identité, ce qui le rend rapide et efficace mais moins décentralisé (par exemple, VeChain).

Malgré la promesse de décentralisation apportée par les blockchains, celles-ci se traduisent rarement par les performances attendues, surtout pour les blue chips :

Bitcoin a en moyenne 7 transactions par seconde (TPS).

Ethereum post-PoS atteint 15 à 30 TPS.

Visa, en revanche, a une moyenne de 1 700 TPS par jour.

Ces lacunes provoquent des retards, des congestions et des frais élevés, exposant ainsi des défis de scalabilité.

1.2 Nouveaux modèles de consensus

Les couches de base émergentes (L1) comme @Hyperliquidx, @Monad_xyz, et @Soniclabsmènent à de nouveaux mécanismes de consensus spécifiquement conçus pour résoudre ces défis, stimulant la vitesse, la scalabilité et l'impact tout en favorisant la confiance.

Cet article offre un examen approfondi de la manière dont ces projets abordent le trilemme de la blockchain, faisant progresser la conception du consensus. Nous plongeons dans l'histoire de chaque projet, les mécanismes de consensus, la relation avec Ethereum, les solutions de scalabilité, les applications pratiques, les approches de financement et de gouvernance, ainsi que les principaux défis.

2 Hyperliquid

Hyperliquid est une blockchain L1 construite pour le trading décentralisé à haute vitesse et à faible coût. Il se divise en deux piliers:

HyperCore : un moteur on-chain pour les contrats à terme perpétuels et les carnets de commandes au comptant avec une finalité en un bloc.

HyperEVM : une plateforme de contrat intelligent compatible avec Ethereum.

Alors que les L1 traditionnels sont confrontés à des compromis entre la décentralisation, les performances et l'accessibilité, Hyperliquid cherche à surmonter ces défis en offrant un écosystème de trading entièrement sur chaîne et performant.

HyperCore peut traiter jusqu'à 200 000 commandes par seconde, un pic théorique devant augmenter avec les mises à jour du logiciel de nœud.

HyperEVM introduit la plateforme de contrat intelligent d'Ethereum à Hyperliquid, offrant la liquidité de HyperCore et les outils financiers en tant que ressources ouvertes.

Avec HyperCore et HyperEVM, l'équipe vise à permettre une interaction transparente entre les applications décentralisées (dApps) et les composants de la blockchain sans sacrifier l'efficacité ou l'expérience utilisateur.

2.1 Mécanisme de Consensus

Initialement, Hyperliquid a utilisé l'algorithme de consensus Tendermint. Cependant, une solution plus avancée était nécessaire pour mieux soutenir le trading à haute fréquence et obtenir un débit de transactions plus élevé.

Pour remédier à cela, Hyperliquid a développé un mécanisme de consensus appelé HyperBFT. Ce système hybride combine PoS avec la tolérance aux fautes byzantines (BFT) et est optimisé pour un débit élevé, une latence faible et une sécurité robuste.

Le modèle PoS est basé sur le protocole HotStuff, où les validateurs génèrent des blocs en misant.$HYPE jetons. L'approche hybride de HyperBFT est plus économe en énergie que les méthodes PoW traditionnelles, tout en maintenant une sécurité robuste.

2.2 Scalabilité et Vitesse

HyperBFT atteint une finalité médiane de 0,2 secondes et une latence inférieure à 0,9 secondes. Le carnet d'ordres on-chain imite la précision des échanges centralisés, prend en charge un effet de levier de 50x, le trading en un clic et les stop-loss.

Hyperliquid excelle dans les scénarios à haut débit, traitant 200 000 TPS simultanément sans sharding. Cela est actuellement limité principalement par la latence du réseau et la répartition des validateurs.

2.3 Défis

Faible nombre de validateurs (sécurité) : Hyperliquid est relativement centralisé, avec seulement 16 validateurs comparé au vaste réseau d'Ethereum de plus de 800k validateurs. Ils visent à étendre leur ensemble de validateurs à mesure que le réseau se développe, en alignement avec leur objectif de décentralisation.

Résilience non testée face aux grandes cyberattaques, soulevant des questions sur sa décentralisation et sa robustesse à long terme. Cette centralisation pose des risques de sécurité, notamment en ce qui concerne les 2,3 milliards de dollars.$USDCdans le pont, ciblé dans une tentative de piratage en 2024.

Impact de la centralisation : En mars 2025, Hyperliquid a été confronté à un incident avec le$JELLY token. Un trader a manipulé le système de liquidation de la plateforme en créant trois comptes et en prenant des positions à effet de levier : deux longues totalisant 4,05 millions de dollars et une courte de 4,1 millions de dollars en$JELLYfutures. Cela a entraîné une augmentation de prix de 400 % et le trader s'est auto-liquidé, entraînant une position courte de 6 millions de dollars pour le coffre-fort de Hyperliquid. Cela a entraîné des pertes non réalisées pour les fournisseurs de liquidité, estimées entre 700 000 et 10 millions de dollars. Cependant, après l'intervention de Hyperliquid, le coffre-fort a réalisé un bénéfice de 700 000 dollars, car Hyperliquid a fini par retirer la$JELLYcontrat, déclenchant des débats sur la décentralisation et la transparence de la gouvernance.

Risques de trading à haute levier : le 13 mars 2025, une baleine a liquidé$ETHpositions longues à travers des transactions à effet de levier élevé, entraînant une perte d'environ 4 millions de dollars dans le coffre-fort HLP. De tels événements mettent en lumière la vulnérabilité de la plateforme à la manipulation du marché et la nécessité de stratégies de gestion des risques solides.

Concurrence : Le code source fermé d'Hyperliquid et l'absence de pénalités automatiques pour les validateurs limitent la transparence et la résilience. La concurrence des plateformes à haut débit comme Solana, des L1 émergentes telles que Monad et MegaETH et des DEX avancées comme dYdX présente des défis.

Scalabilité : Hyperliquid est conçu pour la scalabilité, gérant jusqu'à 200 000 TPS avec une finalité en moins d'une seconde. Cependant, des conditions extrêmes telles que des échanges massivement levier peuvent introduire des défis comme une contrainte de liquidité ou des retards de coordination des validateurs.

3. Monad

Monad est un L1 compatible avec l'EVM pour la scalabilité et les performances, utilisant l'exécution parallèle et MonadBFT.

Monad vise jusqu'à 10k TPS avec des blocs produits toutes les 500 ms et finalisés en une seconde. Il favorise la décentralisation tout en s'attaquant aux goulots d'étranglement d'Ethereum (par exemple, les vitesses lentes, les frais élevés et la scalabilité limitée). Son testnet a été lancé le 19 février 2025, avec des spéculations sur le lancement du mainnet au T3-T4 2025.

3.1 Mécanisme de consensus

L'architecture de Monad est centrée sur son mécanisme de consensus MonadBFT personnalisé, une évolution optimisée du protocole BFT HotStuff.

Il intègre une exécution en mode pipeline et une communication efficace pour se distinguer des conceptions de blockchain traditionnelles.

MonadBFT: Cet algorithme transforme le processus en trois phases de HotStuff en deux, améliorant la vitesse des validateurs. Les validateurs tournent en tant que leaders : l'un propose un bloc et rassemble les votes précédents dans un certificat de quorum (QC), une preuve de consensus pour certifier le bloc précédent. Un mécanisme de temporisation maintient le réseau robuste en cas d'échec d'un leader, assurant la sécurité dans des environnements partiellement synchrones.

Exécution parallèle : L'exécution parallèle fait référence à la capacité de traiter plusieurs tâches ou transactions simultanément, plutôt qu'une par une. Les nœuds s'accordent d'abord sur l'ordre des transactions, puis exécutent les transactions simultanément sur plusieurs threads en utilisant une approche optimiste. Cela garantit la cohérence avec les résultats séquentiels tout en augmentant considérablement le débit.

PoS : Les validateurs misent des jetons pour participer, sécurisant le réseau grâce à des incitations économiques. Ce système PoS équilibre la vitesse et la sécurité, les actifs misés décourageant les actions malveillantes.

MonadBFT offre une finalité évolutive et fiable pour les dApps en temps réel en réduisant les frais de communication,

Le schéma ci-dessous illustre le processus de pipelining de MonadBFT, montrant comment les validateurs (Alice, Bob, Charlie, David, etc.) proposent, votent et finalisent des blocs (N, N+1, N+2, etc.) à travers des tours se chevauchant.

Chaque bloc progresse à travers les étapes : proposé, voté et finalisé. Les validateurs font tourner la direction, produisant des QCs pour certifier les blocs.

3.2 Scalabilité et Vitesse

Monad combine l'efficacité de MonadBFT avec l'exécution parallèle, lui permettant de surpasser les L1 traditionnels en traitant les transactions simultanément, en évitant le sharding et en garantissant une finalité rapide. Sa capacité théorique pourrait être supérieure à celle mentionnée ci-dessus (10k TPS, finalité en moins d'une seconde), bien que les résultats réels dépendent de la latence du réseau et de la répartition des validateurs.

3.3 Défis

Complexité d'exécution : l'exécution parallèle optimiste de Monad pourrait entraîner des incohérences, des retours en arrière ou des vulnérabilités (par exemple, des exploits de cas limites). Ses fonctionnalités avancées (MonadBFT et exécution parallèle) ajoutent de la complexité, augmentant les coûts de développement et de maintenance, en particulier pour les petites équipes. Cela peut entraver la croissance et la sécurité, défiant les petites équipes et le rendant préféré par les équipes disposant de plus de ressources et d'expérience en développement.

Latence du réseau : les TPS réels et la finalité dans le monde réel dépendent de la distribution des validateurs et de la latence, risquant des performances insuffisantes.

Échelle non testée : Pré-mainnet, la revendication de Monad de 10 000 TPS reste non prouvée, avec des bogues ou des goulots d'étranglement possibles.

Concurrence : Des plateformes à haut débit comme Sonic, Arbitrum et Solana pourraient défier l'adoption par les développeurs et les utilisateurs.

Courbe d'apprentissage : Malgré la compatibilité avec l'EVM, les systèmes uniques de Monad (MonadBFT, MonadDB) peuvent ralentir l'intégration des développeurs.

Centralisation : Le contrôle précoce de la Fondation et un modèle de jeton concentré pourraient centraliser le pouvoir, menaçant la décentralisation à long terme et la sécurité.

4. Sonic

Sonic est un L1 compatible avec l'EVM pour un débit élevé et une finalité de transaction en moins d'une seconde, évoluant à partir de l'écosystème Fantom Opera.

Sonic introduit des améliorations opérationnelles notables : son dernier protocole de consensus, SonicCS 2.0, permet d'obtenir une augmentation de 2x de la vitesse de consensus et une réduction de 68 % de l'utilisation de la mémoire par époque (passant de 420 Mo à 135 Mo), réduisant ainsi les exigences en ressources pour les validateurs et améliorant la scalabilité.

Ces mises à niveau s'attaquent à plusieurs défis de la blockchain :

Traitement lent des transactions

Coûts opérationnels élevés

Écosystèmes fragmentés

Avec une identité rebrandée, Sonic incite les développeurs en redistribuant jusqu'à 90% des frais de transaction du réseau grâce à son programme de Monétisation des Frais (FeeM), favorisant la création et l'adoption de dApp.

4.1 Mécanisme de consensus

Le consensus Lachesis de Sonic mélange les graphes acycliques dirigés (DAG) avec la tolérance aux fautes byzantines asynchrones (ABFT), allant au-delà des fondements de Fantom Opera.

ABFT : permet aux validateurs de traiter les transactions et d'échanger des blocs de manière asynchrone. Cela élimine les retards séquentiels des systèmes basés sur la tolérance aux fautes byzantines pratiques (PBFT), améliorant ainsi le débit et la résilience.

DAG : Les transactions sont représentées sous forme de sommets et les dépendances sous forme d'arêtes DAG, permettant des ajouts de blocs concurrents. Cela accélère la validation par rapport aux conceptions de chaînes linéaires de blockchain, formant une structure de type toile interconnectée plutôt qu'une seule chaîne.

PoS: Les validateurs misent un minimum de 500k $Sjetons pour participer, regroupant les transactions en blocs d'événements au sein des DAG locaux. Le consensus est atteint lorsque suffisamment de validateurs confirment ces blocs comme des « racines » sur la chaîne principale, atteignant une finalité en moins d'une seconde. Ce système de PoS équilibre la vitesse, la sécurité et la décentralisation, les jetons mis en jeu dissuadant les comportements répréhensibles.

La figure ci-dessous illustre un DAG pour un nœud spécifique :

Les événements orange représentent les événements des candidats leaders

Les événements jaunes indiquent des événements de leader engagés.

Les événements positionnés entre ces leaders peuvent être séquencés en une chaîne, permettant l'extraction d'une liste de transactions pour construire un bloc.

4.2 SonicCS 2.0 - Leur dernière mise à niveau du mécanisme de consensus

Sonic a récemment mis à niveau son mécanisme de consensus avec SonicCS 2.0, introduit le 27 mars 2025. Ce protocole repose sur une approche basée sur un DAG avec des élections superposées, réduisant l'effort de calcul et l'utilisation de la mémoire de 68%. Des expériences avec 200 époques de données du mainnet de Sonic démontrent un gain de vitesse moyen de 2,04x (allant de 1,37x à 2,62x) et une efficacité mémoire significative, renforçant la capacité de Sonic à traiter plus de 10 000 TPS avec une finalité en moins d'une seconde. SonicCS 2.0 est prêt à être déployé sur le mainnet bientôt, avec un rapport technique détaillé à venir.

4.3 Scalabilité et Vitesse

Le consensus hybride Lachesis de Sonic fusionne l'adaptabilité du DAG avec l'intégrité de l'ABFT, offrant une finalité de transaction rapide et sécurisée sans nécessiter de sharding. Cette conception prend en charge une scalabilité transparente à mesure que la demande du réseau augmente.

SonicCS 2.0 a le potentiel de pousser les performances du réseau principal de Sonic plus près des estimations théoriques de 396 825 TPs. Cependant, il est bon de souligner que les résultats pratiques dépendent de la latence du réseau et de la distribution des validateurs. Selon @AndreCronjetechle TPS maximal en temps réel mesuré sur Sonic était déjà d'environ 5 140, ce qui est assez impressionnant.

Sonic est entièrement compatible avec l'EVM, optimisant les performances au sein de ce cadre plutôt que de le remplacer par une machine virtuelle distincte. Les opérations vectorisées de SonicCS 2.0 et les élections superposées améliorent l'efficacité des validateurs et les performances des dApps.

Source: Chainspect

4.4 Défis

Complexité du consensus: Sous charge élevée, le mécanisme de consensus de Sonic peut introduire des dépendances complexes ou des retards de validation, risquant des inefficacités ou des exploits.

Adaptation des développeurs : Bien que compatible avec EMV, les fonctionnalités avancées de Sonic (par exemple, le vote vectorisé de SonicCS 2.0) peuvent nécessiter des ajustements dans les flux de travail des développeurs, ce qui pourrait ralentir l'adoption.

Latence du réseau : La finalité en moins d'une seconde et 10k TPS dépendent de la distribution des validateurs et de la latence, ce qui pourrait dégrader les performances réelles.

Échelle non testée : avant le déploiement du réseau principal Pre-SonicCS 2.0, la revendication de 10 000 TPS manque de validation complète dans le monde réel et des goulots d'étranglement ou des bogues potentiels doivent encore émerger.

Dominance L2 : Les solutions L2 d'Ethereum (par exemple, Optimism, zkSync) offrent des performances similaires à moindre coût, en tirant parti de vastes liquidités et écosystèmes de développeurs. Le pont Sonic Gateway de Sonic aide à l'interopérabilité, mais rester compétitif en tant que L1 indépendant reste un défi.

Centralisation: Les 500 000 $SLa demande de mise en jeu et le contrôle précoce par la Fondation Sonic risquent de centraliser le pouvoir, ce qui pourrait aliéner les utilisateurs axés sur la décentralisation et affaiblir la sécurité si la distribution des jetons favorise les initiés.

5. Tableau comparatif

6. Exploiter l'écosystème d'Ethereum

Hyperliquid, Monad et Sonic exploitent tous la compatibilité EVM, permettant aux développeurs de déployer des dApps sur une infrastructure haute vitesse en utilisant des outils familiers et des contrats intelligents. Cela permet des transactions à faible coût et à haut débit avec une sécurité robuste, s'appuyant sur l'écosystème d'Ethereum sans réécriture de code.

Alimenter des dApps diverses

Ces L1 offrent des temps de confirmation inférieurs à la seconde et une capacité TPS élevée, ce qui les rend idéaux pour une large gamme de dApps pouvant être déployées de manière transparente.

Hyperliquid offre des transactions DEX rapides et sécurisées avec un carnet de commandes on-chain, correspondant à la précision des échanges centralisés avec une grande évolutivité.

Sonic ajoute une finalité rapide pour des applications DeFi efficaces, sécurisant les transactions en moins d'une seconde.

Monad améliore cela avec 10 000 TYPS, des temps de blocs de 1 seconde et une finalité à un seul emplacement.

Au-delà de Web3: Potentiel d'entreprise

La vitesse et la scalabilité de ces réseaux les positionnent pour une utilisation en entreprise dans la finance, la chaîne d'approvisionnement et les paiements. Les détaillants peuvent gérer des paiements à haut volume à des coûts réduits, tandis que les fournisseurs de soins de santé sécurisent les données des patients en temps réel avec compatibilité avec les systèmes existants.

7. L2 comme réponse d'Ethereum au problème de mise à l'échelle

Et les L2s ?

Pourquoi avons-nous besoin de nouveaux blockchains L1 avec des mécanismes de consensus sophistiqués en premier lieu ?

Les solutions L2 telles que Arbitrum, Optimism et Base ont renforcé la scalabilité de L1 en traitant les transactions hors chaîne. Arbitrum atteint jusqu'à 4 000 TPS, tandis que Base vise des milliers avec des Flashblocks de 0,2 seconde d'ici mi-2025.

Cependant, les L2 dépendent de la sécurité et de la finalité d'Ethereum, héritant de ses caractéristiques et limitations. Par exemple, le besoin de preuves de fraude dans des systèmes comme les rollups optimistes peut entraîner des retards, puisque les transactions sur les chaînes OP Stack d'Optimism deviennent finalisées lorsque leurs données sont incluses dans un bloc Ethereum finalisé. Cela peut avoir un impact sur l'expérience utilisateur, en particulier pour les applications nécessitant une finalité de transaction rapide.

Les nouveaux blockchains L1 tels que Hyperliquid, Monad et Sonic abordent ces limitations avec des mécanismes de consensus avancés. Contrairement aux L2, ces L1 sont très performants sans dépendre de l'infrastructure d'Ethereum, évitant des complexités telles que des preuves de fraude ou des goulots d'étranglement temporels de bloc L1.

Cependant, la construction de nouveaux L1 introduit des risques, remettant éventuellement en question la décentralisation ou augmentant les coûts. Alors que les blockchains L1 fournissent une couche de sécurité et de décentralisation de base, elles sont souvent confrontées à des défis de scalabilité en raison des mécanismes de consensus et des limitations de taille de bloc. De plus, ils n'ont pas les performances historiques et la confiance d'Ethereum.

La nécessité de développer de nouvelles blockchains L1 en présence de solutions L2 existantes est un sujet de discussion continu sur Twitter :

Les L2 soulagent la congestion de L1 mais lient leur scalabilité aux contraintes d'Ethereum. Ils sont aussi rapides qu'Ethereum, mais cela ne prend pas en compte le fait que la finalité de toutes les transactions L2 dépend des temps de confirmation des blocs de L1.

En même temps, les nouveaux L1 promettent l'indépendance et la rapidité, mais ils doivent prouver qu'ils peuvent évoluer de manière sécurisée pour des milliards d'utilisateurs.

L'interaction entre les solutions L1 et L2 soulève des questions critiques sur l'architecture future des réseaux blockchain.

Les défis de scalabilité des blockchains L1 peuvent-ils être efficacement résolus grâce au développement de nouveaux mécanismes de consensus, ou l'intégration de solutions L2 est-elle essentielle malgré leurs compromis inhérents?

Ces considérations soulignent la nécessité de poursuivre la recherche et le dialogue au sein de la communauté de la blockchain pour naviguer dans les complexités de la scalabilité, de la sécurité et de la décentralisation.

Conclusion et matière à réflexion

Un obstacle majeur sur le marché actuel est une liquidité faible et fluctuante, affectant à la fois les nouveaux utilisateurs et les utilisateurs existants. L'attention est faible et de courte durée, ce qui rend encore plus difficile de sécuriser une part d'esprit croissante dans ce secteur saturé.

Par conséquent, pour favoriser l'adoption, il est essentiel de prioriser les besoins à la fois des développeurs et des utilisateurs.

Mais soyons honnêtes : la plupart des utilisateurs se soucient davantage de la fonctionnalité pratique que de la technologie sous-jacente. Ils veulent une expérience sans faille, avec des transactions rapides et des frais réduits qui rendent le réseau accessible, en particulier pour les microtransactions.

La sécurité est également non négociable: les utilisateurs attendent des protections robustes pour protéger leurs actifs et leurs données, favorisant la confiance dans le système. Et, bien sûr, il doit y avoir des activités à réaliser sur la chaîne, qui répondent à différents types de besoins des utilisateurs.

Les L1 et L2 doivent tous deux se battre pour ces intérêts afin de rester pertinents. Au lieu de se concentrer uniquement sur la « meilleure technologie » et d'essayer de « sur-améliorer » les mécanismes de consensus de leur chaîne, ils devraient également être pragmatiques et se concentrer sur offrir aux utilisateurs et aux développeurs le meilleur réseau pour construire et utiliser leurs applications.

Pour conclure, de nouveaux L1, comme Hyperliquid, Monad et Sonic, abordent les dépendances L2 mais rencontrent des défis, comme on peut le voir dans le petit pool de validateurs d'Hyperliquid, où seulement quatre nœuds ont accru les risques de collusion, exposant des vulnérabilités. L'expansion des validateurs, la sécurisation des ponts et la mise en place de seuils d'approbation plus élevés, la surveillance en temps réel et la détection des anomalies peuvent renforcer la résilience. Équilibrer la sécurité, la scalabilité et la décentralisation grâce à une gestion proactive des risques est essentiel pour favoriser la confiance et soutenir la croissance de la DeFi, encourageant les utilisateurs à scruter les sauvegardes des plateformes et les développeurs à prioriser des défenses robustes.

Laissez les "devs faire quelque chose" : laissez-les prendre en charge le poids technique et définir le compromis des mécanismes de consensus, alimentant la recherche d'équilibre.

Aussi, n'oublions pas les utilisateurs : ceux qui apprécient simplement des applications réactives, efficaces, décentralisées et sécurisées.

Ces nouveaux designs repoussent les limites de ce que les modèles de consensus peuvent réaliser en termes de rythme, de sécurité et d'interopérabilité.

Il sera intéressant de voir comment ils évoluent et comment ils s'entrelacent une fois que Monad (et d'autres concurrents) seront opérationnels.

Avertissement :

1. Cet article est repris de [ Château Labs]. Tous les droits d'auteur appartiennent à l'auteur original [@cryptorinweb3]. Si vous avez des objections à cette réimpression, veuillez contacter le Portail Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. L'équipe Gate Learn traduit l'article dans d'autres langues. La copie, la distribution ou le plagiat des articles traduits est interdit sauf mention contraire.