Introduction

Émettre un jeton était autrefois simple : vous le déployiez sur Ethereum, où se déroulait toute l'action – utilisateurs, traders, capital et liquidité. Aujourd'hui, le paysage est beaucoup plus complexe. La liquidité est dispersée à travers Bitcoin, Ethereum, L2s, Solana et d'autres chaînes. Alors, où devriez-vous émettre votre jeton ? Il n'y a pas de réponse claire.

Mais que se passerait-il si vous n'aviez pas à choisir une seule chaîne ? Imaginez un jeton qui fonctionne partout, circulant sans problème dans toute l'économie crypto.

Grâce à protocoles d'interopérabilité(alias ponts), il est maintenant possible d'émettre des jetons avec un marché unifié qui couvre plusieurs chaînes. Cela crée une liquidité mondiale sans frontières, simplifiant les opérations pour les émetteurs de jetons: plus de liquidité, une adoption plus grande et des effets de réseau plus forts - sans les maux de tête de la fragmentation. Fondamentalement, c'est comme avoir un compte bancaire mondial qui fonctionne partout, intégré à tous les écosystèmes DeFi.

Dans cet article, nous comparerons les principaux cadres de jetons proposés par différents protocoles d'interopérabilité. L'objectif est d'évaluer leurs caractéristiques uniques, leurs forces et leurs compromis pour aider les équipes à choisir la meilleure solution pour émettre des jetons nativement multi-chaînes.

Nous explorerons les cadres suivants:

• Service de jeton inter-chaîne (ITS) d'Axelar
• Transferts de jetons natifs de Wormhole (NTT)
• Le jeton fongible Omnichain de LayerZero (OFT)
• Jeton Warp de Hyperlane
• xERC20 (EIP 7281: Jetons Pontifiants Souverains)

Plongeons-y.

Comment fonctionnent les cadres Token

Les frameworks de jetons fonctionnent de deux manières principales, selon que vous rendiez un jeton existant multi-chaîne ou que vous lanciez un jeton nativement multi-chaîne dès le départ.

Brûler-et-Mint: Pour les jetons nativement multi-chaînes

Lorsqu'un jeton est émis de manière native sur plusieurs chaînes dès le premier jour, son offre est répartie sur ces chaînes. Lorsque les jetons sont déplacés entre les chaînes, ils sont brûlés sur la chaîne source et émis sur la chaîne de destination, ce qui garantit que l'offre totale reste constante.

Pensez-y comme un système de comptabilité (comme l'ont expliqué de nombreuses équipes d'interopérabilité). Voici un exemple : considérez le Jeton X avec un approvisionnement total de 1000 jetons, distribués en fonction de la demande sur cinq chaînes :

• Chaîne A: 400 jetons
• Chain B: 200 jetons
• Chaîne C: 200 jetons
• Chaîne D: 100 jetons
• Chaîne E: 100 jetons

Si un utilisateur transfère 50 jetons de la chaîne E à la chaîne A, ces jetons sont brûlés sur la chaîne E et émis sur la chaîne A. La distribution mise à jour serait :

• Chaîne A: 450 jetons
• Chaîne B: 200 jetons
• Chaîne C: 200 tokens
• Chain D: 100 jetons
• Chaîne E: 50 jetons

Ce processus garantit que l'offre totale reste à 1000 tokens, facilitant les transferts sans glissement entre les chaînes.

Lock-and-Mint: Pour les jetons existants

Pour les jetons déjà existants qui ont été initialement déployés sur une seule chaîne, le processus est légèrement différent. L'ensemble de l'approvisionnement existe sur une chaîne, et lors du transfert vers une autre chaîne, une partie de l'approvisionnement est verrouillée dans un contrat intelligent sur la chaîne source, tandis qu'une quantité équivalente est émise sur la chaîne de destination.

Cette méthode est similaire à celle utilisée par les jetons enveloppés. Les jetons verrouillés sur la chaîne A peuvent ensuite avoir une version enveloppée émise sur la chaîne B. Cependant, ces jetons peuvent désormais également passer de la chaîne B à la chaîne C en utilisant la méthode de gravure-émission, sans avoir besoin d'être verrouillés sur plusieurs chaînes. L'offre initiale reste sur la chaîne A, garantissant que les transferts entre les chaînes impliquent simplement de vérifier que les jetons gravés correspondent à ceux émis.

Pourquoi les cadres de jetons sont importants

Voici pourquoi disposer d'un jeton échangeable sur un marché unifié couvrant plusieurs chaînes est bénéfique pour les équipes :

• Liquidité - Un marché unique attire plus de traders, augmentant la liquidité.
• Notre reconnaissance de la marque — Les jetons deviennent accessibles à travers divers écosystèmes DeFi, ce qui augmente la demande et la reconnaissance de la marque.
• La simplicité — La gestion des jetons devient plus facile, réduisant la complexité.
• Redondance — Si une chaîne échoue, les jetons peuvent toujours fonctionner sur d'autres, offrant ainsi un filet de sécurité.
• Expansion du marché — Le token peut être déployé plus rapidement à travers les chaînes, stimulant l'adoption. De plus, des écosystèmes interconnectés signifient plus de place pour l'expérimentation à travers la DeFi.
• Effets de réseau - La collaboration avec d'autres projets augmente l'adoption et la valeur.

Considérer Protocole de transfert inter-chaînes de Circle (CCTP)En lançant CCTP, Circle a permis à USDC d'être échangé de manière transparente sur les chaînes prises en charge, en abordant des problèmes clés:

• Pas de liquidité fragmentée - Auparavant, vous aviez différentes versions de USDC sur chaque chaîne, ce qui entraînait une inefficacité. Maintenant, USDC est le même sur toutes les chaînes.
• Expansion du marché - Le déploiement de l'USDC sur plusieurs chaînes leur permet d'accéder à plus d'utilisateurs et de marchés.
• Efficacité du capital - Les utilisateurs peuvent créer un pont entre de grandes quantités de USDC sans avoir besoin de pools de liquidités ou d'envelopper.
• Frais minimes — Les transferts coûtent peu au-delà des frais de gaz.
• Pas de glissement — Les transferts sont directs et éliminent le risque de glissement.

L'ensemble de fonctionnalités uniques de Circle pour USDC est dû à leur pont sur mesure, CCTP, un luxe que la plupart des projets n'ont pas. C'est là que les cadres de jetons maintenus par des protocoles d'interopérabilité entrent en jeu. Ces cadres fournissent une solution similaire à ce que CCTP offre pour USDC, mais pour n'importe quel jeton. En émettant un jeton via ces cadres, les projets peuvent créer un marché unifié sur plusieurs chaînes prises en charge, permettant des transferts faciles en utilisant des mécanismes de gravure, de verrouillage et de frappe.

Comparaison des cadres de jetons

Maintenant que nous comprenons comment fonctionnent les cadres de jetons et leurs avantages, comparons les différentes solutions disponibles sur le marché pour les équipes souhaitant émettre leurs jetons.

Sécurité

Voici une explication des aspects de sécurité critiques couverts dans le tableau :

1. Mécanisme de vérification

Le mécanisme de vérification est au cœur de la validation des transferts entre les chaînes. Il fait référence à la façon dont les messages sont vérifiés et au type de configuration en termes de mécanismes de vérification fournis par chaque framework - qu’il s’agisse d’une option unique, d’un système modulaire avec plusieurs options ou d’une conception flexible compatible avec n’importe quel pont - permettant aux émetteurs de jetons de sélectionner la solution la plus appropriée en fonction de leurs exigences en matière de sécurité.

Bien que les mécanismes de vérification personnalisés offrent des avantages, ce sont les configurations par défaut qui ...reste le plus largement utiliséPar conséquent, il est important de se concentrer sur la sécurité des schémas de vérification par défaut. Il est recommandé aux équipes d'utiliser des schémas de vérification supplémentaires en plus des paramètres par défaut pour renforcer leur configuration de sécurité.

En ce qui concerne la vivacité, compter sur plusieurs schémas de vérification comporte à la fois des avantages et des inconvénients. Du côté positif, il y a une meilleure tolérance aux pannes : si un fournisseur connaît une période d'inactivité, d'autres peuvent assurer des opérations continues, améliorant ainsi la fiabilité du système. Cependant, cela augmente également la complexité du système. Chaque schéma supplémentaire introduit un point de défaillance potentiel, augmentant le risque de perturbations opérationnelles.

2. Flexibilité sur la vérification

Met en évidence la flexibilité de chaque cadre dans la personnalisation de son mécanisme de vérification - en particulier, si les émetteurs de jetons peuvent choisir parmi différentes options ou sont limités aux paramètres par défaut.

3.Schémas de vérification prédéfinis notables

Les schémas pré-construits sont des mécanismes de vérification prêts à l'emploi que les émetteurs de jetons peuvent utiliser pour la vérification des messages, ce qui facilite le déploiement. Un cadre offrant un plus large choix d'options pré-construites fiables est généralement un signe positif.

Alors que certains cadres offrent plus de schémas de vérification que d'autres, il est essentiel de évaluez-les en fonction de leur spectre de sécurité, qui peut aller d'un simple validateur à des ensembles complets de validateurs.

Par exemple, les OFTs offrent des options DVN qui sont des validateurs uniques ainsi que des choix plus robustes comme CCIP ou Axelar, qui utilisent des ensembles complets de validateurs. De même, Warp Token offre des ISM comme le Multisig ISM qui inclut des validateurs gérés par la communauté Hyperlane et en même temps, il existe des options comme l'ISM d'agrégation qui permet aux équipes de combiner la sécurité de plusieurs ISM.

De plus, bon nombre de ces schémas de vérification peuvent ne pas encore être largement adoptés ou suffisamment testés dans des scénarios réels. Ainsi, les équipes doivent évaluer attentivement la qualité des schémas de vérification disponibles et choisir celui qui correspond à leur niveau de sécurité souhaité. Nous recommandons vivement de tirer parti des options disponibles pour créer une configuration de vérification de jetons sûre et résiliente. Dans un futur article de recherche, nous approfondirons les propriétés de sécurité des différents schémas de vérification offerts par chaque cadre de jeton.

4. Schéma de vérification par défaut

Indique si le cadre fournit un mécanisme de vérification par défaut. C'est important car la plupart des équipes optent généralement pour les options par défaut par commodité. Si un émetteur de jetons choisit l'option par défaut, il est crucial d'évaluer sa sécurité et de considérer l'utilisation des fonctionnalités de personnalisation offertes pour améliorer la sécurité de la configuration.

5. Participation à la vérification de l'application

Met en évidence si les équipes ont la possibilité de participer au processus de vérification, en ajoutant une couche de sécurité supplémentaire ou en leur permettant de prendre le contrôle de leur sécurité. C'est important car cela permet aux équipes d'améliorer la sécurité en incorporant leur propre configuration de vérification aux mécanismes existants. De cette façon, si d'autres méthodes de vérification échouent, ils peuvent compter sur leurs propres garde-fous pour éviter d'éventuels problèmes.

Par exemple, des équipes telles que StarGate, Tapioca, BitGo, Cluster et Abracadabra exécutent leurs propres DVN sur LayerZero, montrant comment d'autres équipes peuvent tirer parti des personnalisations disponibles.

Plus d'équipes devraient profiter de cette couche de sécurité supplémentaire, malgré l'effort supplémentaire requis. Lorsqu'il est mis en œuvre de manière efficace, cette fonctionnalité peut être cruciale pour prévenir les problèmes majeurs lors de pannes critiques.

6. Résistance à la censure

Définit si et comment les messages peuvent être censurés, ce qui peut désactiver les applications et causer des problèmes de vivacité pour les équipes. Dans la plupart des cas, même si les applications sont censurées, elles peuvent passer à différents mécanismes de vérification ou relais dans le même cadre. Cependant, cela nécessite des efforts supplémentaires et peut ne pas être une solution pratique pour les problèmes à court terme.

7. Open-Sourceness

Les bases de code open source permettent aux développeurs d'auditer les fonctionnalités de sécurité et la configuration globale d'un framework, garantissant ainsi la transparence du code exécuté.

Frais

Ce tableau compare les structures de frais de plusieurs frameworks de jetons, en se concentrant sur la façon dont chacun gère les coûts des opérations de protocole, de la messagerie et des frais supplémentaires. Il est important de noter que tous les frameworks permettent d’ajouter des frais personnalisés et spécifiques à l’application au niveau de l’application. De plus, il y a un coût associé au processus de vérification et de transfert, y compris les frais payés aux relayeurs, aux émetteurs-récepteurs ou à des entités similaires, dans tous les cadres.

Actuellement, la plupart des frais sont associés à la vérification et la transmission des messages. Comme mentionné précédemment, tous les cadres de jetons offrent la possibilité d'utiliser plusieurs mécanismes pour vérifier les messages. Bien que chaque schéma de vérification supplémentaire renforce la sécurité du système, il augmente également les frais et les coûts pour les utilisateurs.

1. Frais de protocole

Cela fait référence aux frais de niveau de protocole que chaque framework facture pour l'exécution de transferts ou d'autres opérations.

La présence d’un commutateur de frais régi par la DAO signifie que les émetteurs de tokens peuvent avoir besoin de payer des frais supplémentaires aux protocoles d’interopérabilité derrière les frameworks de tokens (par exemple, LayerZero pour les OFT ou Hyperlane pour Warp Token). Cela introduit une dépendance vis-à-vis de la gouvernance de la DAO, car toute modification du changement de frais affecte directement les jetons émis par le biais de ces cadres, les rendant soumis aux décisions de la DAO sur les structures de frais.

Contrats intelligents

Ce tableau met en évidence les principales propriétés des contrats intelligents de chaque cadre, mettant en évidence leurs degrés variables de flexibilité, de sécurité et de personnalisation avec un accent sur l'historique de déploiement, les audits de sécurité, les primes offertes et les personnalisations notables pour un contrôle granulaire.

Il est important de noter que tous les cadres permettent aux applications de définir des limites de taux et des listes noires, des fonctionnalités de sécurité cruciales qui, lorsqu'elles sont utilisées efficacement, peuvent éviter des pertes financières importantesDe plus, chaque framework offre la flexibilité de déployer des smart contracts de manière immuable ou évolutif, en fonction des besoins spécifiques de l'application.

1.Déployé depuis

Ce champ indique quand les contrats intelligents de chaque framework ont été déployés. Cela donne un aperçu de la durée de fonctionnement du framework.

2. Audits

Le nombre d'audits est une mesure cruciale de sécurité. Les audits valident l'intégrité des contrats intelligents d'un cadre, identifiant les vulnérabilités ou les problèmes qui pourraient compromettre le système.

3. Primes

Les primes reflètent les incitations financières offertes par les frameworks pour encourager les chercheurs en sécurité externes à découvrir et signaler les vulnérabilités.

4. Caractéristique notable pour un contrôle granulaire

Les cadres de contrats intelligents permettent aux applications de mettre en œuvre une variété de fonctionnalités de sécurité personnalisables, en fonction de leurs besoins spécifiques. Ce domaine met en évidence quelques fonctionnalités de sécurité clés que chaque cadre offre pour garantir la sécurité.

Adoption et Expansion

Chaque cadre apporte des caractéristiques uniques et a connu des niveaux d'engagement variables de la part des développeurs, des protocoles et des plates-formes, en fonction de leur orientation technique, de leurs intégrations et de leurs garanties de sécurité.

1.Contributeurs principaux

Cette section met en évidence les différentes équipes impliquées activement dans la construction et la maintenance de chaque infrastructure. Un ensemble diversifié de contributeurs, au-delà de l'équipe de développement originale, est un indicateur positif de plusieurs facteurs: (1) une demande plus large pour l'infrastructure et (2) l'accessibilité et la facilité d'utilisation de l'infrastructure, que ce soit de manière sans permission ou par le biais d'une collaboration générale.

2.Adoption

L'adoption reflète le niveau d'utilisation et de traction de chaque cadre, mesuré par le nombre de jetons déployés et la valeur totale sécurisée. Cela donne un aperçu de la façon dont le cadre a été largement adopté par les développeurs et les protocoles, ainsi que de sa fiabilité dans la sécurisation des actifs.

3. Équipes Notables

Cette section met en évidence les principales équipes et protocoles qui ont adopté chaque cadre, reflétant ainsi leur confiance dans l'industrie et leur attrait global.

4. Couverture VM

La couverture VM fait référence à la gamme de machines virtuelles prises en charge par chaque cadre. Un plus grand nombre de VM offre plus de flexibilité et de compatibilité dans différents environnements blockchain. Cela donne aux applications et aux émetteurs de jetons une plus grande variété en termes de communautés diverses auxquelles ils peuvent s'adresser.

5. Chaînes Déployées Sur

Ce champ reflète le nombre de chaînes sur lesquelles chaque framework est déployé, c’est-à-dire le nombre de chaînes que chaque émetteur d’applications ou de tokens pourrait prendre en charge s’il décidait d’utiliser un framework particulier. Cela est directement lié au nombre de marchés et d’écosystèmes DeFi que les applications peuvent exploiter. Un déploiement plus élevé de la chaîne signifie un accès plus large à la liquidité.

De plus, bien que la capacité d'étendre une infrastructure de manière permissionless sur différentes chaînes présente un grand potentiel, cela peut également être difficile si les développeurs doivent construire et maintenir eux-mêmes des infrastructures critiques. Pour certains, comme les équipes cherchant à établir un support de pont pour une nouvelle chaîne, cet effort peut en valoir la peine. Mais pour les émetteurs de jetons qui cherchent simplement à ajouter une autre chaîne à la portée de leur jeton, cela peut sembler inutilement complexe et exigeant en ressources.

6. Différentiateurs uniques

Chaque framework apporte des différenciateurs uniques, souvent sous la forme de fonctionnalités spéciales, d'outils ou d'intégrations qui le distinguent des autres. Ces différenciateurs attirent généralement les développeurs et les protocoles à la recherche de fonctionnalités spécifiques, de facilité d'utilisation ou simplement d'une plus grande distribution pour leur jeton.

Expérience de développeur

Avis de non-responsabilité : Cette section reflète les @SlavaOnChain(Responsable des relations avec les développeurs chez LI.FI) et des discussions avec des développeurs familiers avec divers cadres. L'expérience des développeurs peut varier en fonction de leur formation et de leur cas d'utilisation.

1. Facilité d'intégration

Fait référence à la facilité avec laquelle il était possible de déployer des jetons en utilisant le cadre basé sur l'expérience de première utilisation sans le soutien de l'équipe.

2. Documentation

Évalue la qualité des guides, des exemples et des références du cadre de travail pour aider les développeurs à comprendre et à utiliser la plateforme.

3. Outils de développement

Considère l'ensemble des bibliothèques, des SDK et des utilitaires qui facilitent la création, le test et le déploiement de jetons à l'aide du framework.

Points clés

A. Tendances en matière d’interopérabilité

1. Mécanismes de personnalisation et de vérification : tous les frameworks offrent une personnalisation des mécanismes de vérification, marquant ainsi une nouvelle tendance dans les protocoles d’interopérabilité. La discussion sur le forum de gouvernance de Lido DAO concernant wstETH a été un moment charnière qui a mis en évidence la demande pour cette fonctionnalité.
2. Pratiques de sécurité : des fonctionnalités telles que les limites de débit, les listes d’autorisation/listes noires et la possibilité pour les émetteurs de jetons de participer à la vérification des messages et à la configuration de la sécurité par le biais de politiques et de rôles personnalisés sont devenues des pratiques standard dans tous les frameworks, indiquant une direction positive pour la sécurité dans l’espace d’interopérabilité.
3. Défis liés à l'adoption au-delà des paramètres par défaut - Bien que les mécanismes de vérification personnalisés soient bénéfiques, l'adoption au-delà des paramètres par défaut reste faible, ce qui nécessite une meilleure sensibilisation aux options de sécurité. Il est essentiel de se concentrer sur la garantie que les schémas de vérification par défaut sont très sécurisés, car ils sont les plus couramment utilisés.
4. Les mécanismes de vérification - l'ensemble de validateurs d'Axelar et le réseau Guardian de Wormhole sont largement adoptés, proposés dans divers cadres.

B. Cadres de jetons leaders

1. OFT by LayerZero : mène à l’adoption, à la fois pour les tokens déployés et pour la valeur totale sécurisée. Ils ont été les premiers à déployer des cadres de jetons avec OFT (V1) en 2022, et ils ont continué à renforcer leur position, avec des actifs majeurs comme WBTC qui ont récemment adopté le cadre OFT. Ils offrent également un support étendu pour la plupart des chaînes et des ressources complètes pour les développeurs.
2. Warp Token par Hyperlane - L'équipe est fortement axée sur la convivialité du framework et des outils de développement pour les opérations sans autorisation. Cela est démontré par les multiples mises en œuvre de VM construites et maintenues par des équipes externes, montrant la facilité de travailler avec le framework de manière sans autorisation.
3. NTT by Wormhole - A rapidement été adopté avec des jetons de grande valeur déployés sur toutes les chaînes et offre plusieurs propriétés uniques dans sa conception, telles que l’absence de changement de frais au niveau du protocole. Il s’agit d’une option populaire pour les équipes qui cherchent à étendre leurs jetons à Solana ou les jetons Solana à l’écosystème EVM.
4. ITS par Axelar — Avec une TVL supérieure à 400 millions de dollars, Axelar se classe parmi les 25 premières chaînes de points de vente. Le cadre ITS est un moteur de croissance clé, contribuant à la fois à la TVL et au volume de messages envoyés via le réseau Axelar.
5. xERC20 Framework — Le seul framework entièrement indépendant des ponts, contrairement à d’autres qui ressemblent davantage à des produits. De nombreux protocoles d’interopérabilité qui n’ont pas leurs propres frameworks encouragent les équipes à utiliser xERC20 pour déployer des jetons, certains proposant des modèles prédéfinis pour l’intégration.
6. Différences de structure de frais — xERC20 et NTT sont deux cadres qui n'ont pas de commutateur de frais au niveau du protocole.

Réflexions finales

Les frameworks de tokens ont le vent en poupe, et ils pourraient finir par tout changer sur la façon dont la valeur se déplace dans un monde multi-chaînes. À l’heure actuelle, le transfert d’actifs entre chaînes nécessite souvent des pools de liquidité ou des résolveurs, mais les frameworks de jetons éliminent ces besoins. Au lieu de cela, les actifs peuvent être émis directement sur la chaîne souhaitée via des protocoles d'interopérabilité.

En fait, les cadres de jetons pourraient être le glas des actifs enveloppés. La liquidité n'aurait plus besoin d'être fragmentée entre les chaînes. Vous pourriez créer des actifs fongibles sur n'importe quelle chaîne, et ils seraient échangeables entre les chaînes pour le coût du gaz. Nous voyons déjà des signes de ce changement. Circle a lancé CCTP pour contourner le problème des jetons enveloppés pour USDC et de nombreuses équipes importantes et des jetons de grande valeur adoptent maintenant des cadres de jetons. C'est un signe que les choses s'accélèrent.

Cependant, il existe des préoccupations légitimes concernant le risque de contagion par des tiers... si les protocoles d'interopérabilité échouent, ils pourraient avoir un impact sur tous les projets construits sur eux. Malgré ces risques, l'adoption continue de croître.

Autre point de vue : dans un avenir abstrait par la chaîne, les frameworks de tokens n’auront plus d’importance car les solveurs échangeront des tokens natifs pour les utilisateurs en arrière-plan. Et bien qu’il y ait une part de vérité à cela – les utilisateurs n’auront pas besoin de penser aux jetons – il manque un angle critique. Qu’en est-il des solveurs eux-mêmes ? Pour eux, les frameworks de tokens pourraient être très utiles. Ils résolvent les maux de tête liés aux stocks et au rééquilibrage, car ils n’ont pas besoin de liquidités pour passer d’une chaîne à l’autre. C’est pourquoi les solveurs aiment utiliser des frameworks comme CCTP pour déplacer l’USDC - c’est bon marché, efficace et parfait pour le rééquilibrage inter-chaînes.

Comment tout cela va se dérouler est encore un mystère pour tous. Peut-être n'aurons-nous besoin que de cadres de jetons pour un petit groupe de chaînes marginales ou peut-être deviendront-ils la norme pour le déploiement de jetons dans la cryptomonnaie. Ce que nous savons aujourd'hui, c'est que l'adoption de cadres d'interopérabilité est en croissance, tout comme la concurrence. Le problème avec cette croissance ? La fragmentation. Les cadres concurrents vont diviser les actifs et la liquidité, et nous ne verrons pas de solution universelle. Les incitations ne le permettront tout simplement pas.

Avertissement :

1. Cet article est repris de [ LI.FI]. Tous les droits d'auteur appartiennent à l'auteur original [Arjun Chand]. S’il y a des objections à cette réimpression, veuillez contacter le Gate Learn 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 aucun conseil en matière d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.